Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #103349 > unrolled thread

Re: Make a unique filesystem path, without creating the file

Back to article view | Back to comp.lang.python

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: Make a unique filesystem path, without creating the file Ethan Furman <ethan@stoneleaf.us> - 2016-02-22 10:11 -0800
    Re: Make a unique filesystem path, without creating the file Jon Ribbens <jon+usenet@unequivocal.co.uk> - 2016-02-22 18:17 +0000
      Re: Make a unique filesystem path, without creating the file Chris Angelico <rosuav@gmail.com> - 2016-02-23 05:25 +1100
        Re: Make a unique filesystem path, without creating the file Jon Ribbens <jon+usenet@unequivocal.co.uk> - 2016-02-22 18:39 +0000
          Re: Make a unique filesystem path, without creating the file Marko Rauhamaa <marko@pacujo.net> - 2016-02-22 20:48 +0200
            Re: Make a unique filesystem path, without creating the file Steven D'Aprano <steve@pearwood.info> - 2016-02-23 10:37 +1100
              Re: Make a unique filesystem path, without creating the file Jon Ribbens <jon+usenet@unequivocal.co.uk> - 2016-02-23 00:08 +0000
                Re: Make a unique filesystem path, without creating the file Chris Angelico <rosuav@gmail.com> - 2016-02-23 11:18 +1100
                  Re: Make a unique filesystem path, without creating the file Jon Ribbens <jon+usenet@unequivocal.co.uk> - 2016-02-23 00:26 +0000
                    Re: Make a unique filesystem path, without creating the file Chris Angelico <rosuav@gmail.com> - 2016-02-23 11:33 +1100
                      Re: Make a unique filesystem path, without creating the file Jon Ribbens <jon+usenet@unequivocal.co.uk> - 2016-02-23 00:44 +0000
                        Re: Make a unique filesystem path, without creating the file Chris Angelico <rosuav@gmail.com> - 2016-02-23 11:56 +1100
          Re: Make a unique filesystem path, without creating the file Chris Angelico <rosuav@gmail.com> - 2016-02-23 06:04 +1100
            Re: Make a unique filesystem path, without creating the file Paul Rubin <no.email@nospam.invalid> - 2016-02-22 11:22 -0800
              Re: Make a unique filesystem path, without creating the file Steven D'Aprano <steve@pearwood.info> - 2016-02-23 10:45 +1100
            Re: Make a unique filesystem path, without creating the file Jon Ribbens <jon+usenet@unequivocal.co.uk> - 2016-02-22 19:22 +0000
              Re: Make a unique filesystem path, without creating the file Marko Rauhamaa <marko@pacujo.net> - 2016-02-22 21:32 +0200
                Re: Make a unique filesystem path, without creating the file Random832 <random832@fastmail.com> - 2016-02-22 14:41 -0500
                  Re: Make a unique filesystem path, without creating the file Marko Rauhamaa <marko@pacujo.net> - 2016-02-22 22:41 +0200
                    Re: Make a unique filesystem path, without creating the file Paul Rubin <no.email@nospam.invalid> - 2016-02-22 13:05 -0800
                      Re: Make a unique filesystem path, without creating the file Marko Rauhamaa <marko@pacujo.net> - 2016-02-22 23:22 +0200
                        Re: Make a unique filesystem path, without creating the file Paul Rubin <no.email@nospam.invalid> - 2016-02-22 15:26 -0800
                Re: Make a unique filesystem path, without creating the file Steven D'Aprano <steve@pearwood.info> - 2016-02-23 11:33 +1100
                  Re: Make a unique filesystem path, without creating the file Marko Rauhamaa <marko@pacujo.net> - 2016-02-23 08:54 +0200
                    Re: Make a unique filesystem path, without creating the file Paul Rubin <no.email@nospam.invalid> - 2016-02-22 23:18 -0800
                      Re: Make a unique filesystem path, without creating the file Marko Rauhamaa <marko@pacujo.net> - 2016-02-23 21:04 +0200
                    Re: Make a unique filesystem path, without creating the file Steven D'Aprano <steve@pearwood.info> - 2016-02-24 12:40 +1100
                      Re: Make a unique filesystem path, without creating the file Marko Rauhamaa <marko@pacujo.net> - 2016-02-24 09:20 +0200
                        Re: Make a unique filesystem path, without creating the file Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2016-02-25 16:38 +1100
                          Re: Make a unique filesystem path, without creating the file Marko Rauhamaa <marko@pacujo.net> - 2016-02-25 08:54 +0200
                            Re: Make a unique filesystem path, without creating the file Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2016-02-25 19:21 +1100
                          Re: Make a unique filesystem path, without creating the file Jon Ribbens <jon+usenet@unequivocal.co.uk> - 2016-02-25 10:05 +0000
              Re: Make a unique filesystem path, without creating the file Chris Angelico <rosuav@gmail.com> - 2016-02-23 06:37 +1100
              Re: Make a unique filesystem path, without creating the file Steven D'Aprano <steve@pearwood.info> - 2016-02-23 11:03 +1100
                Re: Make a unique filesystem path, without creating the file Jon Ribbens <jon+usenet@unequivocal.co.uk> - 2016-02-23 00:11 +0000
                Re: Make a unique filesystem path, without creating the file Paul Rubin <no.email@nospam.invalid> - 2016-02-22 18:27 -0800
                  Re: Make a unique filesystem path, without creating the file Chris Angelico <rosuav@gmail.com> - 2016-02-23 13:53 +1100
                    Re: Make a unique filesystem path, without creating the file Paul Rubin <no.email@nospam.invalid> - 2016-02-22 19:26 -0800
                  Re: Make a unique filesystem path, without creating the file Mark Lawrence <breamoreboy@yahoo.co.uk> - 2016-02-23 08:09 +0000
                    Re: Make a unique filesystem path, without creating the file Paul Rubin <no.email@nospam.invalid> - 2016-02-23 00:22 -0800
                      Re: Make a unique filesystem path, without creating the file Peter Otten <__peter__@web.de> - 2016-02-23 09:40 +0100
                      Re: Make a unique filesystem path, without creating the file Mark Lawrence <breamoreboy@yahoo.co.uk> - 2016-02-23 09:00 +0000
                        Re: Make a unique filesystem path, without creating the file Grant Edwards <invalid@invalid.invalid> - 2016-02-23 15:14 +0000
                      Re: Make a unique filesystem path, without creating the file Steven D'Aprano <steve@pearwood.info> - 2016-02-25 11:41 +1100
                      Re: Make a unique filesystem path, without creating the file Random832 <random832@fastmail.com> - 2016-02-25 10:03 -0500
      Re: Make a unique filesystem path, without creating the file Steven D'Aprano <steve@pearwood.info> - 2016-02-23 11:18 +1100

Page 1 of 3  [1] 2 3  Next page →

#103349 — Re: Make a unique filesystem path, without creating the file

On 02/14/2016 04:08 PM, Ben Finney wrote:

> I am unconcerned with whether there is a real filesystem entry of that
> name; the goal entails having no filesystem activity for this. I want a
> valid unique filesystem path, without touching the filesystem.

This is impossible.  If you don't touch the file system you have no way 
to know if the path is unique.

--
~Ethan~

[toc] | [next] | [standalone]

#103350

On 2016-02-22, Ethan Furman <ethan@stoneleaf.us> wrote:
> On 02/14/2016 04:08 PM, Ben Finney wrote:
>> I am unconcerned with whether there is a real filesystem entry of that
>> name; the goal entails having no filesystem activity for this. I want a
>> valid unique filesystem path, without touching the filesystem.
>
> This is impossible.  If you don't touch the file system you have no way 
> to know if the path is unique.

Weeeeeell, I have a lot of sympathy for that point, but on the other
hand the whole concept of UUIDs ("import uuid") is predicated on the
opposite assumption.

[toc] | [prev] | [next] | [standalone]

#103351

On Tue, Feb 23, 2016 at 5:17 AM, Jon Ribbens
<jon+usenet@unequivocal.co.uk> wrote:
> On 2016-02-22, Ethan Furman <ethan@stoneleaf.us> wrote:
>> On 02/14/2016 04:08 PM, Ben Finney wrote:
>>> I am unconcerned with whether there is a real filesystem entry of that
>>> name; the goal entails having no filesystem activity for this. I want a
>>> valid unique filesystem path, without touching the filesystem.
>>
>> This is impossible.  If you don't touch the file system you have no way
>> to know if the path is unique.
>
> Weeeeeell, I have a lot of sympathy for that point, but on the other
> hand the whole concept of UUIDs ("import uuid") is predicated on the
> opposite assumption.

Not quite opposite. Ethan is asserting that you cannot be *certain*
without actually checking the FS; the point of UUIDs is that you can
be fairly *confident* that there won't be a collision. There is a
nonzero probability of accidental collisions, and if an attacker is
deliberately trying to _force_ a collision, it's most definitely
possible. So both views are correct.

ChrisA

[toc] | [prev] | [next] | [standalone]

#103352

On 2016-02-22, Chris Angelico <rosuav@gmail.com> wrote:
> On Tue, Feb 23, 2016 at 5:17 AM, Jon Ribbens
><jon+usenet@unequivocal.co.uk> wrote:
>> Weeeeeell, I have a lot of sympathy for that point, but on the other
>> hand the whole concept of UUIDs ("import uuid") is predicated on the
>> opposite assumption.
>
> Not quite opposite. Ethan is asserting that you cannot be *certain*
> without actually checking the FS; the point of UUIDs is that you can
> be fairly *confident* that there won't be a collision. There is a
> nonzero probability of accidental collisions, and if an attacker is
> deliberately trying to _force_ a collision, it's most definitely
> possible. So both views are correct.

I was under the impression that the point of UUIDs is that you can be
*so* confident that there won't be a collision that for all practical
purposes it's indistinguishable from being certain.

[toc] | [prev] | [next] | [standalone]

#103353

Jon Ribbens <jon+usenet@unequivocal.co.uk>:

> I was under the impression that the point of UUIDs is that you can be
> *so* confident that there won't be a collision that for all practical
> purposes it's indistinguishable from being certain.

Yes, if you generate a random 128-bit number, it will be unique --
unless someone clones it.

Cloning will be a practical issue when you clone virtual machines, for
example.


Marko

[toc] | [prev] | [next] | [standalone]

#103372

On Tue, 23 Feb 2016 05:48 am, Marko Rauhamaa wrote:

> Jon Ribbens <jon+usenet@unequivocal.co.uk>:
> 
>> I was under the impression that the point of UUIDs is that you can be
>> *so* confident that there won't be a collision that for all practical
>> purposes it's indistinguishable from being certain.
> 
> Yes, if you generate a random 128-bit number, it will be unique --


If you generate a second random 128 bit number, you have a chance of 1 in
2**128 of a collision. All you can say is that it will be *very probably*
unique. (I might even allow "almost certainly" unique.)

If you generate 2**128 + 1 such numbers, you are *guaranteed* to have at
least one collision.

If I can arrange matters so that I am using the same seed as you, then I can
generate the same UUIDs as you.

If I know you are using the Mersenne Twister PRNG, and I can get hold of (by
memory) 128 consecutive UUIDs, I can reconstruct the seed you are using and
generate all future (and past) UUIDs the same as yours. (Well, when I
say "I can", I don't mean *me*, I mean some attacker who is smarter than
me, but not that much smarter.)



> unless someone clones it.
> 
> Cloning will be a practical issue when you clone virtual machines, for
> example.

This is certainly a practical issue that people have to be aware of.




-- 
Steven

[toc] | [prev] | [next] | [standalone]

#103376

On 2016-02-22, Steven D'Aprano <steve@pearwood.info> wrote:
> On Tue, 23 Feb 2016 05:48 am, Marko Rauhamaa wrote:
>> Jon Ribbens <jon+usenet@unequivocal.co.uk>:
>>> I was under the impression that the point of UUIDs is that you can be
>>> *so* confident that there won't be a collision that for all practical
>>> purposes it's indistinguishable from being certain.
>> 
>> Yes, if you generate a random 128-bit number, it will be unique --
>
> If you generate a second random 128 bit number, you have a chance of 1 in
> 2**128 of a collision. All you can say is that it will be *very probably*
> unique. (I might even allow "almost certainly" unique.)

If you are not prepared to say that something with a
340282366920938463463374607431768211455 /
340282366920938463463374607431768211456 chance of being true
is not "certainly true" then I'm not sure how you would not
be too scared to ever leave the house. Or not leave the house.
I mean, you're probably going to be hit by 10^25 meteorites,
which sounds painful.

> If you generate 2**128 + 1 such numbers, you are *guaranteed* to

... have expired due to the heat death of the universe.

[toc] | [prev] | [next] | [standalone]

#103379

On Tue, Feb 23, 2016 at 11:08 AM, Jon Ribbens
<jon+usenet@unequivocal.co.uk> wrote:
> On 2016-02-22, Steven D'Aprano <steve@pearwood.info> wrote:
>> On Tue, 23 Feb 2016 05:48 am, Marko Rauhamaa wrote:
>>> Jon Ribbens <jon+usenet@unequivocal.co.uk>:
>>>> I was under the impression that the point of UUIDs is that you can be
>>>> *so* confident that there won't be a collision that for all practical
>>>> purposes it's indistinguishable from being certain.
>>>
>>> Yes, if you generate a random 128-bit number, it will be unique --
>>
>> If you generate a second random 128 bit number, you have a chance of 1 in
>> 2**128 of a collision. All you can say is that it will be *very probably*
>> unique. (I might even allow "almost certainly" unique.)
>
> If you are not prepared to say that something with a
> 340282366920938463463374607431768211455 /
> 340282366920938463463374607431768211456 chance of being true
> is not "certainly true" then I'm not sure how you would not
> be too scared to ever leave the house. Or not leave the house.
> I mean, you're probably going to be hit by 10^25 meteorites,
> which sounds painful.
>
>> If you generate 2**128 + 1 such numbers, you are *guaranteed* to
>
> ... have expired due to the heat death of the universe.

Maybe... but by the time you get to 2**64 of them, you have a 50%
chance of a collision. (That's either utterly intuitive or completely
counter-intuitive, depending on who you are.)

ChrisA

[toc] | [prev] | [next] | [standalone]

#103380

On 2016-02-23, Chris Angelico <rosuav@gmail.com> wrote:
> On Tue, Feb 23, 2016 at 11:08 AM, Jon Ribbens
><jon+usenet@unequivocal.co.uk> wrote:
>>> If you generate 2**128 + 1 such numbers, you are *guaranteed* to
>>
>> ... have expired due to the heat death of the universe.
>
> Maybe... but by the time you get to 2**64 of them, you have a 50%
> chance of a collision. (That's either utterly intuitive or completely
> counter-intuitive, depending on who you are.)

Um, did you mean to say 2**127? Are you thinking of the
birthday paradox or something, which doesn't apply here?

[toc] | [prev] | [next] | [standalone]

#103383

On Tue, Feb 23, 2016 at 11:26 AM, Jon Ribbens
<jon+usenet@unequivocal.co.uk> wrote:
> On 2016-02-23, Chris Angelico <rosuav@gmail.com> wrote:
>> On Tue, Feb 23, 2016 at 11:08 AM, Jon Ribbens
>><jon+usenet@unequivocal.co.uk> wrote:
>>>> If you generate 2**128 + 1 such numbers, you are *guaranteed* to
>>>
>>> ... have expired due to the heat death of the universe.
>>
>> Maybe... but by the time you get to 2**64 of them, you have a 50%
>> chance of a collision. (That's either utterly intuitive or completely
>> counter-intuitive, depending on who you are.)
>
> Um, did you mean to say 2**127? Are you thinking of the
> birthday paradox or something, which doesn't apply here?

By the time you generate 2**64 of them, you have a 50% chance that
some pair of them collides. Yes, the birthday paradox does apply here.

ChrisA

[toc] | [prev] | [next] | [standalone]

#103384

On 2016-02-23, Chris Angelico <rosuav@gmail.com> wrote:
> On Tue, Feb 23, 2016 at 11:26 AM, Jon Ribbens
><jon+usenet@unequivocal.co.uk> wrote:
>> On 2016-02-23, Chris Angelico <rosuav@gmail.com> wrote:
>>> On Tue, Feb 23, 2016 at 11:08 AM, Jon Ribbens
>>><jon+usenet@unequivocal.co.uk> wrote:
>>>>> If you generate 2**128 + 1 such numbers, you are *guaranteed* to
>>>>
>>>> ... have expired due to the heat death of the universe.
>>>
>>> Maybe... but by the time you get to 2**64 of them, you have a 50%
>>> chance of a collision. (That's either utterly intuitive or completely
>>> counter-intuitive, depending on who you are.)
>>
>> Um, did you mean to say 2**127? Are you thinking of the
>> birthday paradox or something, which doesn't apply here?
>
> By the time you generate 2**64 of them, you have a 50% chance that
> some pair of them collides. Yes, the birthday paradox does apply here.

Oh, I see, you're thinking of it differently. I was thinking of it as
Alice is choosing a filename and Mallet is trying to guess it, in which
case the birthday paradox doesn't apply. You're thinking of it as Alice
is generating many random filenames and, even though she could avoid
collisions with 100% certainty by remembering what she's already had,
isn't doing so, and must avoid colliding with herself. I don't think
your version makes has much relevance as an attack model.

[toc] | [prev] | [next] | [standalone]

#103386

On Tue, Feb 23, 2016 at 11:44 AM, Jon Ribbens
<jon+usenet@unequivocal.co.uk> wrote:
> On 2016-02-23, Chris Angelico <rosuav@gmail.com> wrote:
>> On Tue, Feb 23, 2016 at 11:26 AM, Jon Ribbens
>><jon+usenet@unequivocal.co.uk> wrote:
>>> On 2016-02-23, Chris Angelico <rosuav@gmail.com> wrote:
>>>> On Tue, Feb 23, 2016 at 11:08 AM, Jon Ribbens
>>>><jon+usenet@unequivocal.co.uk> wrote:
>>>>>> If you generate 2**128 + 1 such numbers, you are *guaranteed* to
>>>>>
>>>>> ... have expired due to the heat death of the universe.
>>>>
>>>> Maybe... but by the time you get to 2**64 of them, you have a 50%
>>>> chance of a collision. (That's either utterly intuitive or completely
>>>> counter-intuitive, depending on who you are.)
>>>
>>> Um, did you mean to say 2**127? Are you thinking of the
>>> birthday paradox or something, which doesn't apply here?
>>
>> By the time you generate 2**64 of them, you have a 50% chance that
>> some pair of them collides. Yes, the birthday paradox does apply here.
>
> Oh, I see, you're thinking of it differently. I was thinking of it as
> Alice is choosing a filename and Mallet is trying to guess it, in which
> case the birthday paradox doesn't apply. You're thinking of it as Alice
> is generating many random filenames and, even though she could avoid
> collisions with 100% certainty by remembering what she's already had,
> isn't doing so, and must avoid colliding with herself. I don't think
> your version makes has much relevance as an attack model.

Ah. Steven was talking about collisions; once you have 2**128+1 of
them, you're guaranteed a collision (pigeonhole principle). What
you're talking about gives certainty slightly sooner - specifically,
once you've tried 2**128 of them, you're guaranteed to have hit it :)

ChrisA

[toc] | [prev] | [next] | [standalone]

#103355

On Tue, Feb 23, 2016 at 5:39 AM, Jon Ribbens
<jon+usenet@unequivocal.co.uk> wrote:
> On 2016-02-22, Chris Angelico <rosuav@gmail.com> wrote:
>> On Tue, Feb 23, 2016 at 5:17 AM, Jon Ribbens
>><jon+usenet@unequivocal.co.uk> wrote:
>>> Weeeeeell, I have a lot of sympathy for that point, but on the other
>>> hand the whole concept of UUIDs ("import uuid") is predicated on the
>>> opposite assumption.
>>
>> Not quite opposite. Ethan is asserting that you cannot be *certain*
>> without actually checking the FS; the point of UUIDs is that you can
>> be fairly *confident* that there won't be a collision. There is a
>> nonzero probability of accidental collisions, and if an attacker is
>> deliberately trying to _force_ a collision, it's most definitely
>> possible. So both views are correct.
>
> I was under the impression that the point of UUIDs is that you can be
> *so* confident that there won't be a collision that for all practical
> purposes it's indistinguishable from being certain.

Maybe, if everyone's cooperating. I'm not sure how they fare in the
face of malice though.

ChrisA

[toc] | [prev] | [next] | [standalone]

#103357

Chris Angelico <rosuav@gmail.com> writes:
>> I was under the impression that the point of UUIDs is that you can be
>> *so* confident that there won't be a collision that for all practical
>> purposes it's indistinguishable from being certain.
> Maybe, if everyone's cooperating. I'm not sure how they fare in the
> face of malice though.

There are different UUID algorithms, some of which have useful syntax
but are easy to spoof.  Uuid4 is random and implemented properly, should
be hard to spoof.

[toc] | [prev] | [next] | [standalone]

#103373

On Tue, 23 Feb 2016 06:22 am, Paul Rubin wrote:

> Chris Angelico <rosuav@gmail.com> writes:
>>> I was under the impression that the point of UUIDs is that you can be
>>> *so* confident that there won't be a collision that for all practical
>>> purposes it's indistinguishable from being certain.
>> Maybe, if everyone's cooperating. I'm not sure how they fare in the
>> face of malice though.
> 
> There are different UUID algorithms, some of which have useful syntax
> but are easy to spoof.  Uuid4 is random and implemented properly, should
> be hard to spoof.

I'm not sure what you mean by "spoof" in this context. Do you mean generate
collisions?

Do you mean "pretend to generate a UUID, but without actually doing so"?
That's how I interpret "spoof", but I don't quite understand why that would
be difficult. Here's one I just made now:

{00010203-0405-0607-0809-0a0b0c0d0e0f}

And another:

{836313e2-3b8a-53f2-9b90-0c9ade199e5d}

They weren't hard to spoof :-)


-- 
Steven

[toc] | [prev] | [next] | [standalone]

#103358

On 2016-02-22, Chris Angelico <rosuav@gmail.com> wrote:
> On Tue, Feb 23, 2016 at 5:39 AM, Jon Ribbens
><jon+usenet@unequivocal.co.uk> wrote:
>> On 2016-02-22, Chris Angelico <rosuav@gmail.com> wrote:
>>> On Tue, Feb 23, 2016 at 5:17 AM, Jon Ribbens
>>><jon+usenet@unequivocal.co.uk> wrote:
>>>> Weeeeeell, I have a lot of sympathy for that point, but on the other
>>>> hand the whole concept of UUIDs ("import uuid") is predicated on the
>>>> opposite assumption.
>>>
>>> Not quite opposite. Ethan is asserting that you cannot be *certain*
>>> without actually checking the FS; the point of UUIDs is that you can
>>> be fairly *confident* that there won't be a collision. There is a
>>> nonzero probability of accidental collisions, and if an attacker is
>>> deliberately trying to _force_ a collision, it's most definitely
>>> possible. So both views are correct.
>>
>> I was under the impression that the point of UUIDs is that you can be
>> *so* confident that there won't be a collision that for all practical
>> purposes it's indistinguishable from being certain.
>
> Maybe, if everyone's cooperating. I'm not sure how they fare in the
> face of malice though.

Suppose you had code like this:

  filename = binascii.hexlify(os.urandom(16)).decode("ascii")

Do we really think that is insecure or that there are any practical
attacks against it? It would be basically the same as saying that
urandom() is broken, surely?

[toc] | [prev] | [next] | [standalone]

#103359

Jon Ribbens <jon+usenet@unequivocal.co.uk>:

> Suppose you had code like this:
>
>   filename = binascii.hexlify(os.urandom(16)).decode("ascii")
>
> Do we really think that is insecure or that there are any practical
> attacks against it? It would be basically the same as saying that
> urandom() is broken, surely?

urandom() is not quite random and so should not be considered
cryptographically airtight.

Under Linux, /dev/random is the way to go when strong security is
needed. Note that /dev/random is a scarce resource on ordinary systems.


Marko

[toc] | [prev] | [next] | [standalone]

#103361

On Mon, Feb 22, 2016, at 14:32, Marko Rauhamaa wrote:
> urandom() is not quite random and so should not be considered
> cryptographically airtight.
> 
> Under Linux, /dev/random is the way to go when strong security is
> needed. Note that /dev/random is a scarce resource on ordinary systems.

http://www.2uo.de/myths-about-urandom/

[toc] | [prev] | [next] | [standalone]

#103362

Random832 <random832@fastmail.com>:

> On Mon, Feb 22, 2016, at 14:32, Marko Rauhamaa wrote:
>> urandom() is not quite random and so should not be considered
>> cryptographically airtight.
>> 
>> Under Linux, /dev/random is the way to go when strong security is
>> needed. Note that /dev/random is a scarce resource on ordinary
>> systems.
>
> http://www.2uo.de/myths-about-urandom/

Did you post the link because you agreed with the Web pamphlet?


Marko

[toc] | [prev] | [next] | [standalone]

#103363

Marko Rauhamaa <marko@pacujo.net> writes:
>> http://www.2uo.de/myths-about-urandom/
> Did you post the link because you agreed with the Web pamphlet?

I don't know what web pamphlet you mean, but the right thing to use now
is getrandom(2).  The random/urandom interface was poorly designed and
misleadingly documented.

[toc] | [prev] | [next] | [standalone]

Page 1 of 3  [1] 2 3  Next page →

Back to top | Article view | comp.lang.python

csiph-web