Re: [PATCH v2 00/11] introduce random32_get_bytes() and random32_get_bytes_state()
2012/11/6 David Laight : >> On Sun, 04 Nov 2012 00:43:31 +0900, Akinobu Mita said: >> > This patchset introduces new functions into random32 library for >> > getting the requested number of pseudo-random bytes. >> > >> > Before introducing these new functions into random32 library, >> > prandom32() and prandom32_seed() with "prandom32" prefix are >> > renamed to random32_state() and srandom32_state() respectively. >> > >> > The purpose of this renaming is to prevent some kernel developers >> > from assuming that prandom32() and random32() might imply that only >> > prandom32() was the one using a pseudo-random number generator by >> > prandom32's "p", and the result may be a very embarassing security >> > exposure. >> >> Out of curiosity, why the '32'? I'm just waiting for some kernel developer >> to >> do something stupid with this on a 64-bit arch because they think it's a >> 32-bit API. ;) >> >> Should we bite the bullet and lose the 32, as long as we're churning the >> code *anyhow*? > > Also why remove the 'pseudo' part of the name? > It is an important part of the name. Thanks for the heads-up. Then, what is the ideal function name for pseudo-random library? I propose the following renaming, 'p' prefix is restored and '32' is removed for not returning 32bit pseudo-random number functions. void prandom_seed(u32 seed);/* rename from srandom32() */ u32 prandom32(void);/* rename from random32() */ void prandom_get_byte(void *buf, int bytes); void prandom_seed_state(struct rnd_state *state, u64 seed); /* rename from prandom32_seed() */ u32 prandom32_state(struct rnd_state *state); /* rename from prandom32() */ void prandom_get_byte_state(struct rnd_state *state, void *buf, int bytes); -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH v2 00/11] introduce random32_get_bytes() and random32_get_bytes_state()
> On Sun, 04 Nov 2012 00:43:31 +0900, Akinobu Mita said: > > This patchset introduces new functions into random32 library for > > getting the requested number of pseudo-random bytes. > > > > Before introducing these new functions into random32 library, > > prandom32() and prandom32_seed() with "prandom32" prefix are > > renamed to random32_state() and srandom32_state() respectively. > > > > The purpose of this renaming is to prevent some kernel developers > > from assuming that prandom32() and random32() might imply that only > > prandom32() was the one using a pseudo-random number generator by > > prandom32's "p", and the result may be a very embarassing security > > exposure. > > Out of curiosity, why the '32'? I'm just waiting for some kernel developer to > do something stupid with this on a 64-bit arch because they think it's a > 32-bit API. ;) > > Should we bite the bullet and lose the 32, as long as we're churning the code > *anyhow*? Also why remove the 'pseudo' part of the name? It is an important part of the name. David -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH v2 00/11] introduce random32_get_bytes() and random32_get_bytes_state()
On Sun, 04 Nov 2012 00:43:31 +0900, Akinobu Mita said: This patchset introduces new functions into random32 library for getting the requested number of pseudo-random bytes. Before introducing these new functions into random32 library, prandom32() and prandom32_seed() with prandom32 prefix are renamed to random32_state() and srandom32_state() respectively. The purpose of this renaming is to prevent some kernel developers from assuming that prandom32() and random32() might imply that only prandom32() was the one using a pseudo-random number generator by prandom32's p, and the result may be a very embarassing security exposure. Out of curiosity, why the '32'? I'm just waiting for some kernel developer to do something stupid with this on a 64-bit arch because they think it's a 32-bit API. ;) Should we bite the bullet and lose the 32, as long as we're churning the code *anyhow*? Also why remove the 'pseudo' part of the name? It is an important part of the name. David -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 00/11] introduce random32_get_bytes() and random32_get_bytes_state()
2012/11/6 David Laight david.lai...@aculab.com: On Sun, 04 Nov 2012 00:43:31 +0900, Akinobu Mita said: This patchset introduces new functions into random32 library for getting the requested number of pseudo-random bytes. Before introducing these new functions into random32 library, prandom32() and prandom32_seed() with prandom32 prefix are renamed to random32_state() and srandom32_state() respectively. The purpose of this renaming is to prevent some kernel developers from assuming that prandom32() and random32() might imply that only prandom32() was the one using a pseudo-random number generator by prandom32's p, and the result may be a very embarassing security exposure. Out of curiosity, why the '32'? I'm just waiting for some kernel developer to do something stupid with this on a 64-bit arch because they think it's a 32-bit API. ;) Should we bite the bullet and lose the 32, as long as we're churning the code *anyhow*? Also why remove the 'pseudo' part of the name? It is an important part of the name. Thanks for the heads-up. Then, what is the ideal function name for pseudo-random library? I propose the following renaming, 'p' prefix is restored and '32' is removed for not returning 32bit pseudo-random number functions. void prandom_seed(u32 seed);/* rename from srandom32() */ u32 prandom32(void);/* rename from random32() */ void prandom_get_byte(void *buf, int bytes); void prandom_seed_state(struct rnd_state *state, u64 seed); /* rename from prandom32_seed() */ u32 prandom32_state(struct rnd_state *state); /* rename from prandom32() */ void prandom_get_byte_state(struct rnd_state *state, void *buf, int bytes); -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 00/11] introduce random32_get_bytes() and random32_get_bytes_state()
On Sun, 04 Nov 2012 00:43:31 +0900, Akinobu Mita said: > This patchset introduces new functions into random32 library for > getting the requested number of pseudo-random bytes. > > Before introducing these new functions into random32 library, > prandom32() and prandom32_seed() with "prandom32" prefix are > renamed to random32_state() and srandom32_state() respectively. > > The purpose of this renaming is to prevent some kernel developers > from assuming that prandom32() and random32() might imply that only > prandom32() was the one using a pseudo-random number generator by > prandom32's "p", and the result may be a very embarassing security > exposure. Out of curiosity, why the '32'? I'm just waiting for some kernel developer to do something stupid with this on a 64-bit arch because they think it's a 32-bit API. ;) Should we bite the bullet and lose the 32, as long as we're churning the code *anyhow*? pgpJAuZEgbFx9.pgp Description: PGP signature
Re: [PATCH v2 00/11] introduce random32_get_bytes() and random32_get_bytes_state()
On Sun, 04 Nov 2012 00:43:31 +0900, Akinobu Mita said: This patchset introduces new functions into random32 library for getting the requested number of pseudo-random bytes. Before introducing these new functions into random32 library, prandom32() and prandom32_seed() with prandom32 prefix are renamed to random32_state() and srandom32_state() respectively. The purpose of this renaming is to prevent some kernel developers from assuming that prandom32() and random32() might imply that only prandom32() was the one using a pseudo-random number generator by prandom32's p, and the result may be a very embarassing security exposure. Out of curiosity, why the '32'? I'm just waiting for some kernel developer to do something stupid with this on a 64-bit arch because they think it's a 32-bit API. ;) Should we bite the bullet and lose the 32, as long as we're churning the code *anyhow*? pgpJAuZEgbFx9.pgp Description: PGP signature
