Skip to content

shred: number of random passes is wrong #7823

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
Qelxiros opened this issue Apr 22, 2025 · 1 comment · Fixed by #7847
Closed

shred: number of random passes is wrong #7823

Qelxiros opened this issue Apr 22, 2025 · 1 comment · Fixed by #7847

Comments

@Qelxiros
Copy link
Contributor

Currently, we approximate the number of passes that use random data to be 3 + x/10 (pending #7822), where x is the total number of passes. However, GNU shred output differs:

$ for x in {0..200}; do echo -n "$x "; shred -vn$x foo.txt |& grep random | wc -l; done
0 0
1 1
2 2
3 3
4 2
5 3
6 2
7 3
8 4
9 3
10 3
11 3
12 3
13 3
14 4
15 5
16 6
17 3
18 3
19 3
20 3
21 3
22 3
23 3
24 3
25 3
26 4
27 5
28 6
29 4
30 4
31 4
32 4
33 4
34 4
35 5
36 6
37 7
38 8
39 4
40 4
41 4
42 4
43 4
44 4
45 4
46 4
47 4
48 4
49 5
50 6
51 7
52 8
53 7
54 8
55 7
56 8
57 9
58 8
59 8
60 8
61 8
62 8
63 9
64 10
65 11
66 8
67 8
68 8
69 8
70 8
71 8
72 8
73 8
74 8
75 9
76 10
77 11
78 9
79 9
80 9
81 9
82 9
83 9
84 10
85 11
86 12
87 13
88 9
89 9
90 9
91 9
92 9
93 9
94 9
95 9
96 9
97 9
98 10
99 11
100 12
101 13
102 12
103 13
104 12
105 13
106 14
107 13
108 13
109 13
110 13
111 13
112 14
113 15
114 16
115 13
116 13
117 13
118 13
119 13
120 13
121 13
122 13
123 13
124 14
125 15
126 16
127 14
128 14
129 14
130 14
131 14
132 14
133 15
134 16
135 17
136 18
137 14
138 14
139 14
140 14
141 14
142 14
143 14
144 14
145 14
146 14
147 15
148 16
149 17
150 18
151 17
152 18
153 17
154 18
155 19
156 18
157 18
158 18
159 18
160 18
161 19
162 20
163 21
164 18
165 18
166 18
167 18
168 18
169 18
170 18
171 18
172 18
173 19
174 20
175 21
176 19
177 19
178 19
179 19
180 19
181 19
182 20
183 21
184 22
185 23
186 19
187 19
188 19
189 19
190 19
191 19
192 19
193 19
194 19
195 19
196 20
197 21
198 22
199 23
200 22
$ for x in {0..200}; do echo -n "$x "; target/release/shred -vn$x foo.txt |& grep random | wc -l; done
0 0
1 1
2 2
3 3
4 3
5 3
6 3
7 3
8 3
9 3
10 4
11 4
12 4
13 4
14 4
15 4
16 4
17 4
18 4
19 4
20 5
21 5
22 5
23 5
24 5
25 5
26 5
27 5
28 5
29 5
30 6
31 6
32 6
33 6
34 6
35 6
36 6
37 6
38 6
39 6
40 7
41 7
42 7
43 7
44 7
45 7
46 7
47 7
48 7
49 7
50 8
51 8
52 8
53 8
54 8
55 8
56 8
57 8
58 8
59 8
60 9
61 9
62 9
63 9
64 9
65 9
66 9
67 9
68 9
69 9
70 10
71 10
72 10
73 10
74 10
75 10
76 10
77 10
78 10
79 10
80 11
81 11
82 11
83 11
84 11
85 11
86 11
87 11
88 11
89 11
90 12
91 12
92 12
93 12
94 12
95 12
96 12
97 12
98 12
99 12
100 13
101 13
102 13
103 13
104 13
105 13
106 13
107 13
108 13
109 13
110 14
111 14
112 14
113 14
114 14
115 14
116 14
117 14
118 14
119 14
120 15
121 15
122 15
123 15
124 15
125 15
126 15
127 15
128 15
129 15
130 16
131 16
132 16
133 16
134 16
135 16
136 16
137 16
138 16
139 16
140 17
141 17
142 17
143 17
144 17
145 17
146 17
147 17
148 17
149 17
150 18
151 18
152 18
153 18
154 18
155 18
156 18
157 18
158 18
159 18
160 19
161 19
162 19
163 19
164 19
165 19
166 19
167 19
168 19
169 19
170 20
171 20
172 20
173 20
174 20
175 20
176 20
177 20
178 20
179 20
180 21
181 21
182 21
183 21
184 21
185 21
186 21
187 21
188 21
189 21
190 22
191 22
192 22
193 22
194 22
195 22
196 22
197 22
198 22
199 22
200 23

The GNU output is not random. When comparing marginal differences (i.e. each term minus the one before it), there appears to almost be a pattern, but I'm not sure that it holds for larger numbers. I have no idea where to go with this since we can't consult the GNU source code. The man page doesn't describe the algorithm in use here, and I can't find another shred spec.

@BenWiederhake
Copy link
Collaborator

Looks like the number of random passes in GNU shred is deterministic and repeats:

Image

And it smooths out to juuuuust a bit more than x/10, i.e. 1022 random passes for -n 10000:

Image

I think it's a good idea to keep it simple with our x / 10 approach. (Btw, you implemented it as (x / 10).max(3), not x / 10 + 3, which makes sense to me.)

Because of that, I'm about to open a PR to declare this our custom "extension", which would close this issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants