61–70 of 70 posts
Earlier quoted context omitted.
Why should it be made non-blocking? If you want a large string with little entropy just use /dev/urandom. The political/dogmatic argument is that is should be made non-blocking. The process of acquiring entropy in typical computers is definitely blocking.
What does "acquiring entropy" mean here? There is no reason a properly seeded CSPRNG should ever need to block.
Earlier quoted context omitted.
But you can't do this "those 128 bits are used but are kept not known" thing with software. Sure, it is being tried again and again, and it fails every time. You need separate hardware to safely prevent these 128bits from leaking.. but then why don't we ditch whole idea and implement true HW RNG instead?
I don't think you understood what he was saying, because if you think "you can't protect 128 bits in software" rebuts it, you also don't believe that any software cryptography works, in any setting; virtually all of it involves managing secret or unpredictable 128 bit values. His point is that the mechanism used to generate random bytes by a modern CSPRNG is virtually identical to the mechanism that encrypts the appl…
Mechanism can be identical, but the stakes are definitely not.
Earlier quoted context omitted.
Well, man, that's not the debate. As so often in these conversations, you're running away with the goalposts. If I may advise: these are exactly the antics that are costing you credibility with those of us out here in the field actually building cryptographic systems. Good day.
I don't understand your objections, like, at all. Every "concession" you think you're extracting is right there, in a blog post I wrote 4 years ago. Those are the goalposts. They haven't moved since 2014. Everything else you have to say just reads like word salad. I should be concerned about container RNGs, but not Linux containers, unless they're the Linux containers that don't share the KRNG? Or the IOT devices whe…
As for community communication and understanding: I really don't think there's any good reason that we all have to lock horns all the time. I do think that you'll find more joy in these sorts of discussions if you can be less caustic and more deliberative. It's no more difficult to be nice than it is to be mean; give it a try. And if you get to the edge of your knowledge (and, it seems to me that you do, fairly frequently, which is great - you are obviously interested in a wide variety of societal topics just like I am), don't just keep marching. Stop and acknowledge your short-comings and recognize that there are others who might have had some original / compelling / correct thoughts on these matters also.
Again, this is no skin off my nose. My current project is python, and python has wisely decided to stop using urandom in favor of getrandom(flags=0), so this is a non-issue.
But won't it be nice if the next non-issue can be handled with greater ease and less toxicity?
Earlier quoted context omitted.
I don't understand your objections, like, at all. Every "concession" you think you're extracting is right there, in a blog post I wrote 4 years ago. Those are the goalposts. They haven't moved since 2014. Everything else you have to say just reads like word salad. I should be concerned about container RNGs, but not Linux containers, unless they're the Linux containers that don't share the KRNG? Or the IOT devices whe…
Well look, the problem is solved, at least for people using python. So there's really no need on my end to discuss it further. As for community communication and understanding: I really don't think there's any good reason that we all have to lock horns all the time. I do think that you'll find more joy in these sorts of discussions if you can be less caustic and more deliberative. It's no more difficult to be nice th…
Earlier quoted context omitted.
I don't understand your objections, like, at all. Every "concession" you think you're extracting is right there, in a blog post I wrote 4 years ago. Those are the goalposts. They haven't moved since 2014. Everything else you have to say just reads like word salad. I should be concerned about container RNGs, but not Linux containers, unless they're the Linux containers that don't share the KRNG? Or the IOT devices whe…
Well look, the problem is solved, at least for people using python. So there's really no need on my end to discuss it further. As for community communication and understanding: I really don't think there's any good reason that we all have to lock horns all the time. I do think that you'll find more joy in these sorts of discussions if you can be less caustic and more deliberative. It's no more difficult to be nice th…
Wait a minute, you have made nasty insinuation after nasty insinuation in just about every single comment you've written on this thread and then sprinkled them liberally with finely ground condescension. That's where the toxicity is coming from.
Earlier quoted context omitted.
Well look, the problem is solved, at least for people using python. So there's really no need on my end to discuss it further. As for community communication and understanding: I really don't think there's any good reason that we all have to lock horns all the time. I do think that you'll find more joy in these sorts of discussions if you can be less caustic and more deliberative. It's no more difficult to be nice th…
getrandom(...,0) isn't the blocking version of getrandom, nor is it equivalent to /dev/random. I'm not sure you're even clear what you've been arguing about.
> getrandom(...,0) isn't the blocking version of getrandom
As I have pointed out, and Cory pointed out in that thread - getrandom(flags=0) does block in the rare occasion that blocking is needed and at no subsequent time. That's all I said.
> nor is it equivalent to /dev/random
When did I say that is was? When did I ever even mention /dev/random?
You are the only one that keeps bringing up /dev/random. Instead of refactoring my statements and then taking a nugget of knowledge in an effort to disagree with me and win a point: read what I have actually written. Please. Just slow down a little.
I really don't want to argue with you any more. I do hope that you stop hammering the "use urandom use urandom use urandom waaaahh" thing, but I can't control you.
The right answer moving forward, for almost everyone, is getrandom, not urandom.
The truth is: before I opened that stackexchange question, I was only 90% sure. But now I'm confident I have the right answer. If I'm still wrong, then by all means correct me - you have a link to the open stackexchange question.
Python has done the right thing. So have other toolchains. As far as I can tell, everything is good. We can all just chill.
Earlier quoted context omitted.
Well look, the problem is solved, at least for people using python. So there's really no need on my end to discuss it further. As for community communication and understanding: I really don't think there's any good reason that we all have to lock horns all the time. I do think that you'll find more joy in these sorts of discussions if you can be less caustic and more deliberative. It's no more difficult to be nice th…
and less toxicity? Wait a minute, you have made nasty insinuation after nasty insinuation in just about every single comment you've written on this thread and then sprinkled them liberally with finely ground condescension. That's where the toxicity is coming from.
But insinuation? I think I've been very clear and explicit about my criticisms rather than insinuating anything. Is there something about which I can be more transparent that will increase the quality of this and similar discussions?
I also don't mean to condescend, and I can understand from my writings how my tone might be interpreted that way. But what is the right thing to do in these situations? Discussions on HN of security and the political ramifications are dominated by the volume and aggression of this person and s73v3r_ and others of similar style, and it is taking a toll - people who are quiter but more knowledgeable (and to be clear: I'm not saying I'm either of those things) are being shut out. Can't you see it?
It reminds me of far-right AM radio. I don't want to find myself just tuning out of HN entirely, so I'm trying to be a little more proactive.
On the other hand, I certainly don't want to respond to vitriol with vitriol, but I do want to try to find common ground so we can all learn from each other instead of bark about who's right and who's wrong on these minuscule, mundane points.
Again: Although I think I've been quite explicit rather than lean on insinuation, I apologize for portions of my tone. I'm not a mean person; I'm just trying something new in an effort to change the direction of these things.
Earlier quoted context omitted.
getrandom(...,0) isn't the blocking version of getrandom, nor is it equivalent to /dev/random. I'm not sure you're even clear what you've been arguing about.
Dude... Come on - why does everything have to be a ridiculous tug of war? > getrandom(...,0) isn't the blocking version of getrandom As I have pointed out, and Cory pointed out in that thread - getrandom(flags=0) does block in the rare occasion that blocking is needed and at no subsequent time. That's all I said. > nor is it equivalent to /dev/random When did I say that is was? When did I ever even mention /dev/rando…
This article naturally leads to a question that I didn’t see addressed, perhaps you can answer it here: If it’s unnecessary to ever prefer /dev/random to urandom, then why does /dev/random’s current blocking implementation still exist? Surely between all of the kernel developers, between all of the Unix-ish OS’s, over the last couple of decades would have realized that /dev/random should simply act like /dev/urandom?
Because Theodore Ts'o, a major Linux contributor and maintainer, created and maintains /dev/random and blocks attempts to make it nonblocking like every other cryptographically secure random source. It's a political problem, not a technical one. See https://news.ycombinator.com/item?id=6550256 for a much longer argument about it.
If it's still not blocking, it seems that still the best thing to do is using getrandom( ..., 0 )?