On 1/21/19 4:46 PM, Martijn Dekker wrote:
> So I think SRANDOM is the best name (or SECURE_RANDOM, though that is a
> bit long).
I'm OK with SRANDOM.
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU
On January 20, 2019 2:39:45 PM UTC, Martijn Dekker wrote:
>filename_suffix() {
> chars=ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789
>length=${#chars}
>for ((i=0; i<10; i++)) do
>printf '%s' "${chars:$(( SECURE_RANDOM % length + 1 )):1}"
>done
>}
The char
Op 21-01-19 om 20:12 schreef Chet Ramey:
> On 1/20/19 9:04 PM, Rawiri Blundell wrote:
>> For what it's worth I did consider suggesting URANDOM, however I
>> figured some users may confuse it like this:
>>
>> RANDOM -> /dev/random
>> URANDOM -> /dev/urandom
>>
>> Couple that with an established base
On 1/20/19 9:04 PM, Rawiri Blundell wrote:
> On Mon, Jan 21, 2019 at 10:54 AM Chet Ramey wrote:
>>
>> On 1/20/19 7:52 AM, Rawiri Blundell wrote:
>>
>>> So it might be a case of restricting the usability of this change to
>>> newer kernels that have dedicated calls like getrandom() or
>>> getentrop
Date:Mon, 21 Jan 2019 09:43:17 -0500
From:Chet Ramey
Message-ID: <94f6225c-8de2-cd3d-c83e-0d061c8b0...@case.edu>
| Take the linux mktemp, add the -c option,
Please don't, or at least not the -c option (I don't care if mktemp
is made into a builtin, seems unnecessar
On 1/21/19 8:48 AM, Greg Wooledge wrote:
> On Sun, Jan 20, 2019 at 03:39:45PM +0100, Martijn Dekker wrote:
>> E.g. to create a random character string for a temporary
>> file name, you could do
>>
>> filename_suffix() {
>> chars=ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789
>>
On Sun, Jan 20, 2019 at 03:39:45PM +0100, Martijn Dekker wrote:
> E.g. to create a random character string for a temporary
> file name, you could do
>
> filename_suffix() {
> chars=ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789
> length=${#chars}
> for ((i=0; i<10; i++)
On Mon, Jan 21, 2019 at 10:54 AM Chet Ramey wrote:
>
> On 1/20/19 7:52 AM, Rawiri Blundell wrote:
>
> > So it might be a case of restricting the usability of this change to
> > newer kernels that have dedicated calls like getrandom() or
> > getentropy(), and having to handle detecting/selecting th
On 1/20/19 8:07 PM, Rawiri Blundell wrote:
> */snip*
>
> So it looks like problem solved?
There never was a problem.
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRUc...@case.eduhttp://tisww
On Mon, Jan 21, 2019 at 1:36 PM Eduardo A. Bustamante López
wrote:
>
> On Sun, Jan 20, 2019 at 05:22:12PM -0500, Chet Ramey wrote:
> > On 1/20/19 4:54 PM, Chet Ramey wrote:
> >
> > >> As an aside, I can confirm the findings of a performance difference
> > >> between 4.4 and 5.0 when running the sc
On Sun, Jan 20, 2019 at 05:22:12PM -0500, Chet Ramey wrote:
> On 1/20/19 4:54 PM, Chet Ramey wrote:
>
> >> As an aside, I can confirm the findings of a performance difference
> >> between 4.4 and 5.0 when running the script provided earlier in the
> >> discussion. At first glance it seems to be du
On 1/20/19 4:54 PM, Chet Ramey wrote:
>> As an aside, I can confirm the findings of a performance difference
>> between 4.4 and 5.0 when running the script provided earlier in the
>> discussion. At first glance it seems to be due to the switch from the
>> old LCG to the current MINSTD RNG,
>
> T
On 1/20/19 7:52 AM, Rawiri Blundell wrote:
> So it might be a case of restricting the usability of this change to
> newer kernels that have dedicated calls like getrandom() or
> getentropy(), and having to handle detecting/selecting those?
>
> So if this is an exercise that you're happy to entert
Op 19-01-19 om 23:10 schreef Chet Ramey:
> On 1/19/19 2:45 PM, Martijn Dekker wrote:
>> Op 16-01-19 om 02:21 schreef Quentin:
>>> If you really need some quality CSPRNG values, I'd suggest adding a
>>> $SECURE_RANDOM variable that just reads from /dev/urandom.
>>
>> IMHO, this would clearly be the
> OK, this is a reasonable approach. Since /dev/urandom just generates
> random bytes, there's a lot of flexibility and we're not subject to
> any kind of backwards compatibility constraints, especially not the
> 16-bit limit. What do you think would be the best way to present that
> to a user? As
On 1/19/19 2:45 PM, Martijn Dekker wrote:
> Op 16-01-19 om 02:21 schreef Quentin:
>> If you really need some quality CSPRNG values, I'd suggest adding a
>> $SECURE_RANDOM variable that just reads from /dev/urandom.
>
> IMHO, this would clearly be the correct approach. I don't know of any
> 21st ce
Op 16-01-19 om 02:21 schreef Quentin:
> If you really need some quality CSPRNG values, I'd suggest adding a
> $SECURE_RANDOM variable that just reads from /dev/urandom.
IMHO, this would clearly be the correct approach. I don't know of any
21st century Unix or Unix-like system that doesn't have /de
Hello there,
I've reviewed both patches and found some things that should be either
greatly improved, or buried some place very deep. :-p
On 2019-01-07 08:15, Ole Tange wrote:
On Mon, Jan 7, 2019 at 12:08 AM Chet Ramey wrote:
On 1/5/19 3:12 PM, Eduardo A. Bustamante López wrote:
> On Fri,
On Mon, Jan 7, 2019 at 9:37 AM Eduardo A. Bustamante López
wrote:
> On Mon, Jan 07, 2019 at 08:15:12AM +0100, Ole Tange wrote:
> > On Mon, Jan 7, 2019 at 12:08 AM Chet Ramey wrote:
> > > On 1/5/19 3:12 PM, Eduardo A. Bustamante López wrote:
> > > > On Fri, Dec 28, 2018 at 10:24:50AM +0100, Ole Ta
On Mon, Jan 07, 2019 at 08:15:12AM +0100, Ole Tange wrote:
> On Mon, Jan 7, 2019 at 12:08 AM Chet Ramey wrote:
> >
> > On 1/5/19 3:12 PM, Eduardo A. Bustamante López wrote:
> > > On Fri, Dec 28, 2018 at 10:24:50AM +0100, Ole Tange wrote:
> > > (...)
> > >> Patch attached.
> :
> > > - Does the new
On Mon, Jan 7, 2019 at 12:08 AM Chet Ramey wrote:
>
> On 1/5/19 3:12 PM, Eduardo A. Bustamante López wrote:
> > On Fri, Dec 28, 2018 at 10:24:50AM +0100, Ole Tange wrote:
> > (...)
> >> Patch attached.
:
> > - Does the new RNG generate uniformly distributed numbers? (Yes)
> > - What is the perform
On Sat, Jan 5, 2019 at 9:14 PM Eduardo A. Bustamante López
wrote:>
> On Fri, Dec 28, 2018 at 10:24:50AM +0100, Ole Tange wrote:
> (...)
> > Patch attached.
:
> I applied the Salsa20 RNG patch (slightly modified due to the recent changes
> in
> variables.c, attached [1]) to the tip of `devel`
> (8
On 1/5/19 3:12 PM, Eduardo A. Bustamante López wrote:
> On Fri, Dec 28, 2018 at 10:24:50AM +0100, Ole Tange wrote:
> (...)
>> Patch attached.
>>
>> It is basically a copy of the code snippet from Wikipedia with a few
>> trivial wrappers.
>>
>> Apart from using Salsa20 the biggest change is that you
On Sat, Jan 5, 2019 at 12:12 PM Eduardo A. Bustamante López
wrote:
(...)
> 2. Performance impact
>
> The new RNG does more work, and thus, it is expected to have a performance
> impact when generating lots of random numbers. I tested 3 systems (2 amd64
> and 1
> armhf) and include the results bel
On 2-1-2019 02:29, Ole Tange wrote:
On Mon, Dec 31, 2018 at 8:12 PM Chet Ramey wrote:
:
Thanks for the patch. I'll take a look after I release bash-5.0. One
question: can you reproduce the same random sequence by using the same
seed? That's for backwards compatibility, even if the sequences the
On Mon, Dec 31, 2018 at 8:12 PM Chet Ramey wrote:
:
> Thanks for the patch. I'll take a look after I release bash-5.0. One
> question: can you reproduce the same random sequence by using the same
> seed? That's for backwards compatibility, even if the sequences themselves
> differ.
Yes. Seeding w
On 12/28/18 4:24 AM, Ole Tange wrote:
> On Sun, Dec 16, 2018 at 6:41 AM Eduardo Bustamante wrote:
> :
>> You know no one is stopping you from submitting a patch to actually
>> fix the documentation right? (or maybe, you know, submitting an actual
>> working patch to change the random generator, no
On Sun, Dec 16, 2018 at 6:41 AM Eduardo Bustamante wrote:
:
> You know no one is stopping you from submitting a patch to actually
> fix the documentation right? (or maybe, you know, submitting an actual
> working patch to change the random generator, not just drop some
> irrelevant code snippet yo
On 12/15/18 5:22 PM, Ole Tange wrote:
>>> The reason for my submission was that I needed a bunch of random
>>> numbers in a shell script, but I needed them to be high quality.
>>> Luckily I did not just assume that Bash delivers high quality random
>>> numbers, but I read the source code, and then
On Sat, Dec 15, 2018 at 6:08 PM Ole Tange wrote:
(...)
> But your comment actually emphasizes my point: We _will_ have users
> who are naive enough to use $RANDOM in ways you and I would not do,
> because we know it is unsafe.
>
> Let's make those usages a little safer.
You know no one is stoppin
On Mon, Dec 3, 2018 at 9:18 PM Chet Ramey wrote:
> On 12/3/18 11:31 AM, Ole Tange wrote:
> > On Mon, Dec 3, 2018 at 3:56 PM Chet Ramey wrote:
> >
> >> There has to be a compelling reason to change this, especially at a point
> >> so close to a major release.
I would think that a major release wo
On 12/3/18 11:31 AM, Ole Tange wrote:
> On Mon, Dec 3, 2018 at 3:56 PM Chet Ramey wrote:
>
>> There has to be a compelling reason to change this, especially at a point
>> so close to a major release.
>
> The reason for my submission was that I needed a bunch of random
> numbers in a shell script
On Mon, Dec 3, 2018 at 9:36 AM Greg Wooledge wrote:
>
> On Mon, Dec 03, 2018 at 05:31:18PM +0100, Ole Tange wrote:
> > Luckily I did not just assume that Bash delivers high quality random
> > numbers, but I read the source code, and then found that the quality
> > was low. I do not think must user
On Mon, Dec 03, 2018 at 05:31:18PM +0100, Ole Tange wrote:
> Luckily I did not just assume that Bash delivers high quality random
> numbers, but I read the source code, and then found that the quality
> was low. I do not think must users would do that.
You're correct. Most users would not have to
On Mon, Dec 3, 2018 at 3:56 PM Chet Ramey wrote:
> There has to be a compelling reason to change this, especially at a point
> so close to a major release.
The reason for my submission was that I needed a bunch of random
numbers in a shell script, but I needed them to be high quality.
Luckily I
On Mon, Dec 03, 2018 at 09:56:33AM -0500, Chet Ramey wrote:
> There has to be a compelling reason to change this, especially at a point
> so close to a major release.
>
> You might be expecting too much from bash's random number generator. Is
> the problem that its period is at most 2**16? For its
On 12/2/18 6:13 PM, Ole Tange wrote:
> On Wed, Nov 21, 2018 at 11:45 PM Chet Ramey wrote:
>> On 11/21/18 3:07 PM, Ole Tange wrote:
>>> 'brand' in variables.c is comparable in size to ChaCha20 and ChaCha20
>>> is not completely broken:
>>> https://en.wikipedia.org/wiki/Salsa20
>>>
>>> Could we plea
On Sun, Dec 2, 2018 at 3:14 PM Ole Tange wrote:
(...)
> Git's use of SHA1 seems to be a prime example of what can go wrong:
> https://shattered.io/
What does a PRNG have to do with a hashing function?
> Can you elaborate on why you think it is a bad idea to change an
> insecure PRNG into a non-b
On Wed, Nov 21, 2018 at 11:45 PM Chet Ramey wrote:
> On 11/21/18 3:07 PM, Ole Tange wrote:
> > 'brand' in variables.c is comparable in size to ChaCha20 and ChaCha20
> > is not completely broken:
> > https://en.wikipedia.org/wiki/Salsa20
> >
> > Could we please replace 'brand' with ChaCha20?
>
> Wh
On 11/21/18 3:07 PM, Ole Tange wrote:
> 'brand' in variables.c is comparable in size to ChaCha20 and ChaCha20
> is not completely broken:
> https://en.wikipedia.org/wiki/Salsa20
>
> Could we please replace 'brand' with ChaCha20?
What is your application that you need something more complicated th
'brand' in variables.c is comparable in size to ChaCha20 and ChaCha20
is not completely broken:
https://en.wikipedia.org/wiki/Salsa20
Could we please replace 'brand' with ChaCha20?
/Ole
41 matches
Mail list logo
