path: root/src/daemon/https/lgl/gc.h
diff options
Diffstat (limited to 'src/daemon/https/lgl/gc.h')
1 files changed, 0 insertions, 140 deletions
diff --git a/src/daemon/https/lgl/gc.h b/src/daemon/https/lgl/gc.h
index dc873a54..30c4e45b 100644
--- a/src/daemon/https/lgl/gc.h
+++ b/src/daemon/https/lgl/gc.h
@@ -169,144 +169,4 @@ Gc_rc MHD_gc_pbkdf2_sha1 (const char *P,
169 size_t Slen, unsigned int c, char *DK, 169 size_t Slen, unsigned int c, char *DK,
170 size_t dkLen); 170 size_t dkLen);
171 171
173 TODO:
175 From: Simon Josefsson <jas@extundo.com>
176 Subject: Re: generic crypto
177 Newsgroups: gmane.comp.lib.gnulib.bugs
178 Cc: bug-gnulib@gnu.org
179 Date: Fri, 07 Oct 2005 12:50:57 +0200
180 Mail-Copies-To: nobody
182 Paul Eggert <eggert@CS.UCLA.EDU> writes:
184 > Simon Josefsson <jas@extundo.com> writes:
185 >
186 >> * Perhaps the /dev/?random reading should be separated into a separate
187 >> module? It might be useful outside of the gc layer too.
188 >
189 > Absolutely. I've been meaning to do that for months (for a "shuffle"
190 > program I want to add to coreutils), but hadn't gotten around to it.
191 > It would have to be generalized a bit. I'd like to have the file
192 > descriptor cached, for example.
194 I'll write a separate module for that part.
196 I think we should even add a good PRNG that is re-seeded from
197 /dev/?random frequently. GnuTLS can need a lot of random data on a
198 big server, more than /dev/random can supply. And /dev/urandom might
199 not be strong enough. Further, the security of /dev/?random can also
200 be questionable.
202 >> I'm also not sure about the names of those functions, they suggest
203 >> a more higher-level API than what is really offered (i.e., the
204 >> names "nonce" and "pseudo_random" and "random" imply certain
205 >> cryptographic properties).
206 >
207 > Could you expand a bit more on that? What is the relationship between
208 > nonce/pseudorandom/random and the /dev/ values you are using?
210 There is none, that is the problem.
212 Applications generally need different kind of "random" numbers.
213 Sometimes they just need some random data and doesn't care whether it
214 is possible for an attacker to compute the string (aka a "nonce").
215 Sometimes they need data that is very difficult to compute (i.e.,
216 computing it require inverting SHA1 or similar). Sometimes they need
217 data that is not possible to compute, i.e., it wants real entropy
218 collected over time on the system. Collecting the last kind of random
219 data is very expensive, so it must not be used too often. The second
220 kind of random data ("pseudo random") is typically generated by
221 seeding a good PRNG with a couple of hundred bytes of real entropy
222 from the "real random" data pool. The "nonce" is usually computed
223 using the PRNG as well, because PRNGs are usually fast.
225 Pseudo-random data is typically used for session keys. Strong random
226 data is often used to generate long-term keys (e.g., private RSA
227 keys).
229 Of course, there are many subtleties. There are several different
230 kind of nonce:s. Sometimes a nonce is just an ever-increasing
231 integer, starting from 0. Sometimes it is assumed to be unlikely to
232 be the same as previous nonces, but without a requirement that the
233 nonce is possible to guess. MD5(system clock) would thus suffice, if
234 it isn't called too often. You can guess what the next value will be,
235 but it will always be different.
237 The problem is that /dev/?random doesn't offer any kind of semantic
238 guarantees. But applications need an API that make that promise.
240 I think we should do this in several steps:
242 1) Write a module that can read from /dev/?random.
244 2) Add a module for a known-good PRNG suitable for random number
245 generation, that can be continuously re-seeded.
247 3) Add a high-level module that provide various different randomness
248 functions. One for nonces, perhaps even different kind of nonces,
249 one for pseudo random data, and one for strong random data. It is
250 not clear whether we can hope to achieve the last one in a portable
251 way.
253 Further, it would be useful to allow users to provide their own
254 entropy source as a file, used to seed the PRNG or initialize the
255 strong randomness pool. This is used on embedded platforms that
256 doesn't have enough interrupts to hope to generate good random data.
258 > For example, why not use OpenBSD's /dev/arandom?
260 I don't trust ARC4. For example, recent cryptographic efforts
261 indicate that you must throw away the first 512 bytes generated from
262 the PRNG for it to be secure. I don't know whether OpenBSD do this.
263 Further, I recall some eprint paper on RC4 security that didn't
264 inspire confidence.
266 While I trust the random devices in OpenBSD more than
267 Solaris/AIX/HPUX/etc, I think that since we need something better on
268 Solaris/AIX/HPUX we'd might as well use it on OpenBSD or even Linux
269 too.
271 > Here is one thought. The user could specify a desired quality level
272 > range, and the implementation then would supply random data that is at
273 > least as good as the lower bound of the range. I.e., ihe
274 > implementation refuses to produce any random data if it can't generate
275 > data that is at least as good as the lower end of the range. The
276 > upper bound of the range is advice from the user not to be any more
277 > expensive than that, but the implementation can ignore the advice if
278 > it doesn't have anything cheaper.
280 I'm not sure this is a good idea. Users can't really be expected to
281 understand this. Further, applications need many different kind of
282 random data. Selecting the randomness level for each by the user will
283 be too complicated.
285 I think it is better if the application decide, from its cryptographic
286 requirement, what entropy quality it require, and call the proper API.
287 Meeting the implied semantic properties should be the job for gnulib.
289 >> Perhaps MHD_gc_dev_random and MHD_gc_dev_urandom?
290 >
291 > To some extent. I'd rather insulate the user from the details of
292 > where the random numbers come from. On the other hand we need to
293 > provide a way for applications to specify a file that contains
294 > random bits, so that people can override the defaults.
296 Agreed.
298 This may require some thinking before it is finalized. Is it ok to
299 install the GC module as-is meanwhile? Then I can continue to add the
300 stuff that GnuTLS need, and then come back to re-working the
301 randomness module. That way, we have two different projects that use
302 the code. GnuTLS includes the same randomness code that was in GNU
303 SASL and that is in the current gc module. I feel much more
304 comfortable working in small steps at a time, rather then working on
305 this for a long time in gnulib and only later integrate the stuff in
306 GnuTLS.
308 Thanks,
309 Simon
310 */
312#endif /* GC_H */ 172#endif /* GC_H */