Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.debian.user > #185717 > unrolled thread
| Started by | Mario Castelán Castro <marioxcc.MT@yandex.com> |
|---|---|
| First post | 2017-08-22 17:10 +0200 |
| Last post | 2017-09-04 01:10 +0200 |
| Articles | 20 on this page of 117 — 22 participants |
Back to article view | Back to linux.debian.user
One-line password generator Mario Castelán Castro <marioxcc.MT@yandex.com> - 2017-08-22 17:10 +0200
Re: One-line password generator Brian <ad44@cityscape.co.uk> - 2017-08-22 21:50 +0200
Re: One-line password generator <tomas@tuxteam.de> - 2017-08-22 22:10 +0200
Re: One-line password generator John Hasler <jhasler@newsguy.com> - 2017-08-22 22:50 +0200
Re: One-line password generator Jude DaShiell <jdashiel@panix.com> - 2017-08-23 14:40 +0200
Re: One-line password generator Mario Castelán Castro <marioxcc.MT@yandex.com> - 2017-08-22 22:20 +0200
Re: One-line password generator Mario Castelán Castro <marioxcc.MT@yandex.com> - 2017-08-22 22:20 +0200
Re: One-line password generator Mario Castelán Castro <marioxcc.MT@yandex.com> - 2017-08-22 22:30 +0200
Re: One-line password generator Glenn English <ghe2001@gmail.com> - 2017-08-23 22:40 +0200
Re: One-line password generator Brian <ad44@cityscape.co.uk> - 2017-08-23 00:40 +0200
Re: One-line password generator Lck Ras <likcoras@riseup.net> - 2017-08-23 02:30 +0200
Re: One-line password generator Brian <ad44@cityscape.co.uk> - 2017-08-23 19:20 +0200
Re: One-line password generator Lck Ras <likcoras@riseup.net> - 2017-08-24 03:00 +0200
Re: One-line password generator Mario Castelán Castro <marioxcc.MT@yandex.com> - 2017-08-23 17:20 +0200
Re: One-line password generator Brian <ad44@cityscape.co.uk> - 2017-08-23 19:00 +0200
Re: One-line password generator Mario Castelán Castro <marioxcc.MT@yandex.com> - 2017-08-23 20:00 +0200
Re: One-line password generator Brian <ad44@cityscape.co.uk> - 2017-08-23 21:20 +0200
Re: One-line password generator Mario Castelán Castro <marioxcc.MT@yandex.com> - 2017-08-24 01:10 +0200
Re: One-line password generator Brian <ad44@cityscape.co.uk> - 2017-08-24 19:50 +0200
Re: One-line password generator David Wright <deblis@lionunicorn.co.uk> - 2017-08-25 03:00 +0200
Re: One-line password generator Curt <curty@free.fr> - 2017-08-25 10:50 +0200
Re: One-line password generator "Thomas Schmitt" <scdbackup@gmx.net> - 2017-08-25 11:30 +0200
Re: One-line password generator Mario Castelán Castro <marioxcc.MT@yandex.com> - 2017-08-25 15:40 +0200
Re: One-line password generator "Thomas Schmitt" <scdbackup@gmx.net> - 2017-08-25 16:50 +0200
Re: One-line password generator Mario Castelán Castro <marioxcc.MT@yandex.com> - 2017-08-25 18:10 +0200
Re: One-line password generator "Thomas Schmitt" <scdbackup@gmx.net> - 2017-08-25 19:20 +0200
Re: One-line password generator Mario Castelán Castro <marioxcc.MT@yandex.com> - 2017-08-25 20:10 +0200
Re: One-line password generator "Thomas Schmitt" <scdbackup@gmx.net> - 2017-08-25 20:50 +0200
Re: One-line password generator Mario Castelán Castro <marioxcc.MT@yandex.com> - 2017-08-25 21:00 +0200
Re: One-line password generator Brian <ad44@cityscape.co.uk> - 2017-08-25 19:00 +0200
Re: One-line password generator Mario Castelán Castro <marioxcc.MT@yandex.com> - 2017-08-25 19:00 +0200
Re: One-line password generator Mario Castelán Castro <marioxcc.MT@yandex.com> - 2017-08-25 19:20 +0200
Re: One-line password generator Brian <ad44@cityscape.co.uk> - 2017-08-25 20:20 +0200
Re: One-line password generator Brian <ad44@cityscape.co.uk> - 2017-08-25 19:20 +0200
Re: One-line password generator Jape Person <japers@comcast.net> - 2017-08-22 22:20 +0200
Re: One-line password generator Jude DaShiell <jdashiel@panix.com> - 2017-08-23 14:40 +0200
Re: One-line password generator Mike McClain <mike.junk.46@att.net> - 2017-08-23 03:10 +0200
Re: One-line password generator Teemu Likonen <tlikonen@iki.fi> - 2017-08-23 06:10 +0200
Re: One-line password generator Aaron Toponce <aaron.toponce@gmail.com> - 2017-08-23 21:20 +0200
Re: One-line password generator Greg Wooledge <wooledg@eeg.ccf.org> - 2017-08-23 21:30 +0200
Re: One-line password generator Aaron Toponce <aaron.toponce@gmail.com> - 2017-08-23 21:40 +0200
Re: One-line password generator Fungi4All <fungilife@protonmail.com> - 2017-08-23 22:50 +0200
Re: One-line password generator Terence <terence.john@gmail.com> - 2017-08-23 23:40 +0200
Re: One-line password generator Brian <ad44@cityscape.co.uk> - 2017-08-26 20:30 +0200
Re: One-line password generator Nicolas George <george@nsup.org> - 2017-08-26 20:40 +0200
Re: One-line password generator Brian <ad44@cityscape.co.uk> - 2017-08-26 21:10 +0200
Re: One-line password generator Brian <ad44@cityscape.co.uk> - 2017-08-27 16:00 +0200
Re: One-line password generator "Thomas Schmitt" <scdbackup@gmx.net> - 2017-08-26 21:20 +0200
Re: One-line password generator Brian <ad44@cityscape.co.uk> - 2017-08-27 16:00 +0200
Re: One-line password generator "Thomas Schmitt" <scdbackup@gmx.net> - 2017-08-27 17:10 +0200
Re: One-line password generator Curt <curty@free.fr> - 2017-08-27 20:10 +0200
Re: One-line password generator Brian <ad44@cityscape.co.uk> - 2017-08-27 20:10 +0200
Re: One-line password generator "Thomas Schmitt" <scdbackup@gmx.net> - 2017-08-27 21:10 +0200
Re: One-line password generator Andy Smith <andy@strugglers.net> - 2017-08-28 00:00 +0200
Re: One-line password generator "Thomas Schmitt" <scdbackup@gmx.net> - 2017-08-28 09:40 +0200
Re: One-line password generator Curt <curty@free.fr> - 2017-08-28 11:40 +0200
Re: One-line password generator "Thomas Schmitt" <scdbackup@gmx.net> - 2017-08-28 12:10 +0200
Re: One-line password generator Andy Smith <andy@strugglers.net> - 2017-08-28 13:50 +0200
Re: One-line password generator "Thomas Schmitt" <scdbackup@gmx.net> - 2017-08-28 15:20 +0200
Re: One-line password generator Zenaan Harkness <zenaan@freedbms.net> - 2017-08-29 04:40 +0200
Re: One-line password generator "Thomas Schmitt" <scdbackup@gmx.net> - 2017-08-29 09:10 +0200
Re: One-line password generator Zenaan Harkness <zenaan@freedbms.net> - 2017-08-29 10:50 +0200
Re: One-line password generator Zenaan Harkness <zenaan@freedbms.net> - 2017-08-29 11:00 +0200
Re: One-line password generator "Thomas Schmitt" <scdbackup@gmx.net> - 2017-08-29 12:50 +0200
Re: One-line password generator Zenaan Harkness <zenaan@freedbms.net> - 2017-08-29 13:00 +0200
Re: One-line password generator "Thomas Schmitt" <scdbackup@gmx.net> - 2017-08-29 14:30 +0200
Re: One-line password generator Zenaan Harkness <zenaan@freedbms.net> - 2017-08-30 03:50 +0200
Re: One-line password generator "Thomas Schmitt" <scdbackup@gmx.net> - 2017-08-30 12:40 +0200
Re: One-line password generator Andy Smith <andy@strugglers.net> - 2017-08-29 14:10 +0200
Re: One-line password generator "Thomas Schmitt" <scdbackup@gmx.net> - 2017-08-29 15:00 +0200
Re: One-line password generator Zenaan Harkness <zenaan@freedbms.net> - 2017-08-30 03:50 +0200
Re: One-line password generator Greg Wooledge <wooledg@eeg.ccf.org> - 2017-08-30 14:20 +0200
Re: One-line password generator Gene Heskett <gheskett@shentel.net> - 2017-08-30 14:50 +0200
Re: One-line password generator "Thomas Schmitt" <scdbackup@gmx.net> - 2017-08-30 15:20 +0200
Re: One-line password generator Gene Heskett <gheskett@shentel.net> - 2017-08-30 15:30 +0200
Re: One-line password generator "Thomas Schmitt" <scdbackup@gmx.net> - 2017-08-30 15:50 +0200
Re: One-line password generator Gene Heskett <gheskett@shentel.net> - 2017-08-30 16:00 +0200
Re: One-line password generator Greg Wooledge <wooledg@eeg.ccf.org> - 2017-08-30 16:10 +0200
Re: One-line password generator Gene Heskett <gheskett@shentel.net> - 2017-08-30 18:50 +0200
Re: One-line password generator "Thomas Schmitt" <scdbackup@gmx.net> - 2017-08-30 16:30 +0200
Re: One-line password generator Gene Heskett <gheskett@shentel.net> - 2017-08-30 20:10 +0200
Re: One-line password generator "Thomas Schmitt" <scdbackup@gmx.net> - 2017-08-30 23:00 +0200
Re: One-line password generator "Thomas Schmitt" <scdbackup@gmx.net> - 2017-09-01 10:40 +0200
Re: One-line password generator "Thomas Schmitt" <scdbackup@gmx.net> - 2017-09-01 10:50 +0200
Re: One-line password generator Curt <curty@free.fr> - 2017-08-30 16:30 +0200
Re: One-line password generator "Thomas Schmitt" <scdbackup@gmx.net> - 2017-08-30 17:00 +0200
Re: One-line password generator Brian <ad44@cityscape.co.uk> - 2017-08-30 20:00 +0200
Re: One-line password generator Zenaan Harkness <zenaan@freedbms.net> - 2017-08-29 11:00 +0200
Re: One-line password generator "Thomas Schmitt" <scdbackup@gmx.net> - 2017-08-27 21:20 +0200
Re: One-line password generator Brian <ad44@cityscape.co.uk> - 2017-08-29 21:20 +0200
Re: One-line password generator Reco <recoverym4n@gmail.com> - 2017-08-29 21:40 +0200
Re: One-line password generator Brian <ad44@cityscape.co.uk> - 2017-08-29 22:00 +0200
Re: One-line password generator "Thomas Schmitt" <scdbackup@gmx.net> - 2017-08-29 23:00 +0200
Re: One-line password generator Curt <curty@free.fr> - 2017-08-30 10:50 +0200
Re: One-line password generator "Thomas Schmitt" <scdbackup@gmx.net> - 2017-08-30 12:40 +0200
Re: One-line password generator Reco <recoverym4n@gmail.com> - 2017-08-30 00:00 +0200
Re: One-line password generator Brian <ad44@cityscape.co.uk> - 2017-08-31 21:10 +0200
Re: One-line password generator Fungi4All <fungilife@protonmail.com> - 2017-08-31 21:20 +0200
Re: One-line password generator Reco <recoverym4n@gmail.com> - 2017-08-31 21:40 +0200
Re: One-line password generator Mario Castelán Castro <marioxcc.MT@yandex.com> - 2017-08-27 04:20 +0200
Re: One-line password generator Brian <ad44@cityscape.co.uk> - 2017-08-27 16:00 +0200
Re: One-line password generator Mario Castelán Castro <marioxcc.MT@yandex.com> - 2017-08-27 16:40 +0200
Re: One-line password generator Mario Castelán Castro <marioxcc.MT@yandex.com> - 2017-09-01 17:00 +0200
Re: One-line password generator Brian <ad44@cityscape.co.uk> - 2017-09-01 21:50 +0200
Re: One-line password generator "Thomas Schmitt" <scdbackup@gmx.net> - 2017-09-01 23:50 +0200
Re: One-line password generator Jude DaShiell <jdashiel@panix.com> - 2017-09-02 11:50 +0200
Re: One-line password generator "Thomas Schmitt" <scdbackup@gmx.net> - 2017-09-02 13:00 +0200
Re: One-line password generator Brian <ad44@cityscape.co.uk> - 2017-09-02 19:20 +0200
Re: One-line password generator Jude DaShiell <jdashiel@panix.com> - 2017-09-02 20:30 +0200
Re: One-line password generator "Thomas Schmitt" <scdbackup@gmx.net> - 2017-09-02 21:00 +0200
Re: One-line password generator Brian <ad44@cityscape.co.uk> - 2017-09-02 22:00 +0200
Re: One-line password generator Zenaan Harkness <zenaan@freedbms.net> - 2017-09-02 01:50 +0200
Re: One-line password generator Zenaan Harkness <zenaan@freedbms.net> - 2017-09-02 01:50 +0200
Re: One-line password generator Mario Castelán Castro <marioxcc.MT@yandex.com> - 2017-09-02 04:40 +0200
Re: One-line password generator Zenaan Harkness <zenaan@freedbms.net> - 2017-09-02 05:40 +0200
Re: One-line password generator Mario Castelán Castro <marioxcc.MT@yandex.com> - 2017-09-02 16:40 +0200
Re: One-line password generator Zenaan Harkness <zenaan@freedbms.net> - 2017-09-04 01:10 +0200
Page 4 of 6 — ← Prev page 1 2 3 [4] 5 6 Next page →
| From | "Thomas Schmitt" <scdbackup@gmx.net> |
|---|---|
| Date | 2017-08-29 09:10 +0200 |
| Message-ID | <ujIOS-7YQ-15@gated-at.bofh.it> |
| In reply to | #186107 |
Hi, Zenaan Harkness wrote: > AIUI /dev/random is simply the input feed to /dev/urandom [...] This is what the article by Thomas Huehn https://www.2uo.de/myths-about-urandom/ calls a myth, illustrated by diagram https://www.2uo.de/myths-about-urandom/structure-no.png Andy Smith stated in https://lists.debian.org/debian-user/2017/08/msg01594.html that the article is correct. > if you want security/ secure software, you -must- know the nature of > your inputs, I thought that i knew from the man page. But people with probably more knowledge than me contradict that page. I wrote: > > I understand that in this situation there is no difference > > between /dev/random and /dev/urandom. > No So this diagram about the situation before kernel 4.8 is wrong ? https://www.2uo.de/myths-about-urandom/structure-yes.png The new situation as stated in https://www.2uo.de/myths-about-urandom/structure-new.png is a bit more obscure, because it is not clear what exactly happens inside the "randomness pool". Is it only a buffer ? Does it always grow when new data arrive ? Or does it merge the new bits into a constant size pool ? > > The difference appears only when the assumption of wealth is not > > fulfilled. > ... parse fail "Wealth" = Well filled randomness pool which makes blocking unnessessary. > don't use /dev/random, use /dev/urandom instead, as designed, Urm. Your argumentation up to this point was that they differ sigificantly. > and as has been made publicly clear for ~10 years now. The kernel people won't get us users to change our behavior unless the man page gets clarified and the experts take the responsibility to teach us what https://www.2uo.de/myths-about-urandom/ tries to teach us. The current statements look like a lame compromise after some of the participating experts objected the flat deprecation of /dev/random even after the system had a few seconds of collecting erratic events. But what are these objections and why are they important enough to cause a statement like "Choice of random source Unless you are doing long-term key generation (and most likely not even then), you probably shouldn't be reading from the /dev/random [...]" in http://man7.org/linux/man-pages/man7/random.7.html The clause "most likely not" puts the whole statement in question without giving a clue about the proper answer. Further it implies a vague security difference between both devices. > Confront the man page! If only this would give more clarity ... X-| My current compilation of all info is like this: /dev/random was originally designed to possibly block, but is now said not to do this any more in practice. /dev/urandom was originally designed to hand out lower quality random if /dev/random would block, but is now said not to do this any more. Have a nice day :) Thomas
[toc] | [prev] | [next] | [standalone]
| From | Zenaan Harkness <zenaan@freedbms.net> |
|---|---|
| Date | 2017-08-29 10:50 +0200 |
| Message-ID | <ujKnF-lz-25@gated-at.bofh.it> |
| In reply to | #186110 |
On Tue, Aug 29, 2017 at 09:06:07AM +0200, Thomas Schmitt wrote: > Hi, > > Zenaan Harkness wrote: > > AIUI /dev/random is simply the input feed to /dev/urandom [...] I should have wrote "/dev/random should be treated as though it is the input feed to /dev/urandom" (sorry about that). > This is what the article by Thomas Huehn > https://www.2uo.de/myths-about-urandom/ That's a really good description of various myths. Well worth reading for those who are interested in this topic. It's first debunk is this, which is clear, certainly clearer than my attempt to communicate on this topic :) "Fact: /dev/urandom is the preferred source of cryptographic randomness on UNIX-like systems." > calls a myth, illustrated by diagram > https://www.2uo.de/myths-about-urandom/structure-no.png That diag seems sort of useful, but less clear than it could be. [edit: that diagram is what's NOT happening!] [which means: we're simply not understanding one another] The debunked myths seems much clearer to me - but that could just be because my second brain cell isn't function so well or is failing to properly cross heisenberg's uncertainty of existence threshold - either way, my first brain cell is somewhat limited in its capacity sorry. This debunk is particularly useful to a lot of straw men that get thrown about: That's all good and nice, but even the man page for /dev/(u)random contradicts you! Does anyone who knows about this stuff actually agree with you? Fact: No, it really doesn't. It seems to imply that /dev/urandom is insecure for cryptographic use, unless you really understand all that cryptographic jargon. and the subsequent paragraph is exactly what that eponymous brain cell of mine failed to clearly explain: The man page does recommend the use of /dev/random in some cases (it doesn't hurt, in my opinion, but is not strictly necessary), but it also recommends /dev/urandom as the device to use for “normal” cryptographic use. Really great myth-debunking article - it be the true go to view, to send folks to who do pursue a crypto clue, or two. > Andy Smith stated in > https://lists.debian.org/debian-user/2017/08/msg01594.html > that the article is correct. > > > > if you want security/ secure software, you -must- know the nature of > > your inputs, > > I thought that i knew from the man page. But people with probably more > knowledge than me contradict that page. Well that debunking article actually backs up the man page - if you find a particular sentence confusing, feel free to paste it here and we can all take pot shots at how shitty its wording is :D I kid, I kid! I actually have never read that man page... > I wrote: > > > I understand that in this situation there is no difference > > > between /dev/random and /dev/urandom. > > > No > > So this diagram about the situation before kernel 4.8 is wrong ? > https://www.2uo.de/myths-about-urandom/structure-yes.png Ahah! That's a better diagram - that explains why I found it confusing, because it was I guess trying to explain what does not happen :) Seems even my first brain cell needs a cup of caffeine... > The new situation as stated in > https://www.2uo.de/myths-about-urandom/structure-new.png I always thought (even pre- Kernel 4.8) that structure-new was how it worked. But on the other hand, it's just a diagram - use the source, Duke! > is a bit more obscure, because it is not clear what exactly happens inside > the "randomness pool". Is it only a buffer ? Does it always grow when new > data arrive ? Or does it merge the new bits into a constant size pool ? Use the source, and write a Haykiyui when you grok the fine differences :) > > > The difference appears only when the assumption of wealth is not > > > fulfilled. > > > ... parse fail > > "Wealth" = Well filled randomness pool which makes blocking unnessessary. That's exactly what /dev/urandom provides - so go forth in wealth :) We have awesome API/ functionality abundance in the libre software world, so you can strut around in a highly superior stance FTW (or the fall on the pride sword which would deliciously follow). > > don't use /dev/random, use /dev/urandom instead, as designed, > > Urm. Your argumentation up to this point was that they differ sigificantly. They do. And so in general, if you want cryptographically safe random numbers for user-space programs, use /dev/urandom - what's not to grok here? > > and as has been made publicly clear for ~10 years now. > > The kernel people won't get us users to change our behavior unless the > man page gets clarified and the experts take the responsibility to teach us > what https://www.2uo.de/myths-about-urandom/ tries to teach us. No, simply understanding is what's needed. "Some" users, yes, but the man pages are actually our responsibility to update - perhaps you're assuming it was the responsibility of the kernel devs? Those assumptions ... ;) > The current statements look like a lame compromise after some of the > participating experts objected the flat deprecation of /dev/random > even after the system had a few seconds of collecting erratic events. > > But what are these objections and why are they important enough to > cause a statement like > "Choice of random source > Unless you are doing long-term key generation (and most likely not > even then), you probably shouldn't be reading from the /dev/random [...]" > in > http://man7.org/linux/man-pages/man7/random.7.html > > The clause "most likely not" puts the whole statement in question without > giving a clue about the proper answer. > Further it implies a vague security difference between both devices. No doubt your man-page wording enhancement patches shall be soon forthcoming, and many future users shall explode in gratitude for your persistent diligence on a frankly vital topic of understanding for specific domains of software development and use! > > Confront the man page! > > If only this would give more clarity ... X-| > > > My current compilation of all info is like this: > > /dev/random was originally designed to possibly block, but is now said > not to do this any more in practice. No! That's the whole point of why /dev/random should in general (for user space software) not be used when you want cryptographically secure random numbers - it's returning guaranteed entropy bits, which do result in cryptographically secure numbers, and in most circumstances is not needed by end user programs. If you're not a software developer, don't worry about it. If you are, use a library that is widely used and known to have had a few (now fixed) bugs in the past. > /dev/urandom was originally designed to hand out lower quality random No. /dev/urandom was designed to hand out cryptographically secure numbers whilst not blocking. Only in rare circumstances does blocking for "#N pure entropy bits" actually gain you anything in the crypto world. If you're not gaining anything, why use it and risk blocking? > if /dev/random would block, but is now said not to do this any more. I don't know about that last bit - AIUI this is also wrong - /dev/random CAN block, which is the whole point of providing /dev/urandom. At this point, if you really want certainty, you will need to read the code, or go to someone who can speak with authority on the actual kernel code. I thought Ted Ts'o was quite clear in that email of his previously linked. I could be not understanding his words properly. Good luck,
[toc] | [prev] | [next] | [standalone]
| From | Zenaan Harkness <zenaan@freedbms.net> |
|---|---|
| Date | 2017-08-29 11:00 +0200 |
| Message-ID | <ujKxj-oP-9@gated-at.bofh.it> |
| In reply to | #186112 |
On Tue, Aug 29, 2017 at 06:49:45PM +1000, Zenaan Harkness wrote:
> I stated:
> > > https://www.2uo.de/myths-about-urandom/structure-yes.png
>
> > > The new situation as stated in
> > > https://www.2uo.de/myths-about-urandom/structure-new.png
> >
> > I always thought (even pre- Kernel 4.8) that structure-new was how it
> > worked. But on the other hand, it's just a diagram - use the source,
> > Duke!
>
> Sorry, structure-yes is what I thought it was, and thought it still
> was, but seems it may no longer be.
>
> I don't understand the difference between -yes and -new; on its face,
> "-new" looks actually wrong to me - but it's just someone's diagram,
> the source code is the truth of what happens in the kernel.
>
> Good luck,
PPS - if I were to draw what I understand "structure-new" to actually
be, I would change structure-yes as follows:
1. swap "CSPRNG" and "randomness pool" so the former now comes after
the latter.
2. connect CSPRNG (now below the pool) to /dev/urandom with the line
I have not read the code, and do not understand the change that's
happened properly though.
Good luck,
[toc] | [prev] | [next] | [standalone]
| From | "Thomas Schmitt" <scdbackup@gmx.net> |
|---|---|
| Date | 2017-08-29 12:50 +0200 |
| Message-ID | <ujMfL-1wY-7@gated-at.bofh.it> |
| In reply to | #186113 |
Hi, Zenaan Harkness wrote: > I should have wrote "/dev/random should be treated as though it is > the input feed to /dev/urandom" (sorry about that). But that it isn't. The myth model says that it would be. But the other quite credible info says that its output stems from the pseudo random number generator which is a ChaCha20 encryptor with changing key, if i got it right. As naive user with no special knowledge about ChaCha20 i would prefer to get raw random, not a strongly obfuscated but still diluted result. But it seems that this kind of random is not available from /dev/random. I understand Theodore T'so's statements in https://lkml.org/lkml/2017/7/20/993 that the key changes on slow entropy input and thus potentially more bits come out than secret bits are filled in. (Else he could not reject the proposal to collect more entropy on x86.) Originally Curt wrote: > > > https://www.2uo.de/myths-about-urandom Zenaan Harkness wrote: > Really great myth-debunking article Up to now i found no credible expert opinion which would clearly contradict it. Its language and attitude seems inappropriate for the sincere topic it discusses, though. All in all, the effort should go into the man page, even if it gets a two page discussion what the crypto jargon shall mean to the normal user. A mere imperative "use urandom unconditionally !" would be clear, too. But obviously the man page authors do not dare or cannot agree on that. One should also read the first article mentioned by Curt: https://arstechnica.com/information-technology/2013/05/how-crackers-make-minced-meat-out-of-your-passwords/ which does not discuss the properties of /dev/*random but rather illustrates the problems of human memorizable passwords together with stolen password hashes, stolen hash algorithm, and stolen salt. Other than in the /dev/*random situation, the service cannot destroy these secrets because they need to be applied each time the password gets validated. > Well that debunking article actually backs up the man page >From the view of social engineering there is a big difference. Thomas Huehn, whose competence i have no reason to doubt, is a single person delivering a mix of rant and info. The man page is reviewed in the kernel community and committed by people who have power to do harm at other places in the kernel anyways. So if i trust their code, i can also trust their man page. > We have awesome API/ functionality abundance in the libre software A single one, about which i can convince myself to trust, would be enough. At least for the case of a 128 bit secret which i would generate only a few times per year. For now i tend to stay with /dev/random, because in any halfways plausible model (wrong or right) it is not worse than /dev/urandom. > > Urm. Your argumentation up to this point was that they differ > > sigificantly. > They do. > And so in general, if you want cryptographically safe random numbers > for user-space programs, use /dev/urandom - what's not to grok here? If they differ significantly in respect to being guessed, then i'd like to have the one with the better reputation. > but the > man pages are actually our responsibility to update - perhaps you're > assuming it was the responsibility of the kernel devs? In this special case: yes. (I would raise protest if half educated users would make success-critical changes in my own man pages. They can talk to me and i will duely consider their arguments.) > If you're not a software developer, don't worry about it. First: I am software developer, albeit not directly in cryptography. Second: Why is a mere user less vulnerable to brute force attacks ? > If you are, use a library that is widely used and known to have had a > few (now fixed) bugs in the past. The original topic was about creating a single or small number of passwords. Chosing, installing, and understanding a library seems somewhat overdone. > /dev/urandom was designed to hand out cryptographically secure > numbers whilst not blocking. Why then the mumbling in the man page ? I do not doubt the intention, but obviously some author(s) had doubts about the result of the implementation. > > /dev/urandom was originally designed to hand out lower quality random > > if /dev/random would block, but is now said not to do this any more. > /dev/random CAN block, which is the whole point of providing > /dev/urandom. This statement was about /dev/urandom not blocking and possibly providing reduced quality, not about /dev/random blocking or not blocking. But a main argument of Theodore T'so and others is that there is always enough entropy in the pool. So /dev/random won't block, will it ? > I have not read the code, and do not understand the change that's > happened properly though. >From my experience with kernel code, where i have understanding of the topic, i would not expect to get decisive clarity unless i had studied the topic first. That might last some years and still not exclude the risk of shooting my foot, given the special circumstances of cryptography. Have a nice day :) Thomas
[toc] | [prev] | [next] | [standalone]
| From | Zenaan Harkness <zenaan@freedbms.net> |
|---|---|
| Date | 2017-08-29 13:00 +0200 |
| Message-ID | <ujMps-1Ae-15@gated-at.bofh.it> |
| In reply to | #186120 |
On Tue, Aug 29, 2017 at 12:40:48PM +0200, Thomas Schmitt wrote:
> Hi,
>
> Zenaan Harkness wrote:
> > I should have wrote "/dev/random should be treated as though it is
> > the input feed to /dev/urandom" (sorry about that).
>
> But that it isn't. The myth model says that it would be.
Which myth?
I can't see the myth in my words that you say is debunked - if you're
clear on it, please quote the myth.
> But the
> other quite credible info says that its output stems from the pseudo
> random number generator which is a ChaCha20 encryptor with changing key,
> if i got it right.
Exactly which part of my sentence above, do you say contradicts what
you say just here?
(If you going to say such things, please quote - for the life of me I
cannot see the contradiction you're talking about!)
> As naive user with no special knowledge about ChaCha20 i would prefer
> to get raw random,
Your preference is not relevant to the security of the result, but
you acting on your naive preference may well reduce the security, and
or the usability, of whatever software you are using.
> not a strongly obfuscated but still diluted result.
^^^^^^^^^^^^^^^^^^^^^^^^
Yes, your naivety shines through.
This is not the place to gain a deep understanding of
cryptographically secure random numbers - there are plenty of good
books, and also plenty of good sources on the web.
If you want to comprehend the significance of your naivety, find the
number of molecules in the universe, and then work out roughly how
many bits (i.e. as a power of two number) are needed to store that,
and then compare this to the number of bits of entropy Ts'o talked
about.
Seriously. As in, without doing this basic experiment, you're going
down completely non-productive rabbit holes, trying to achieve a
simplistic understanding of something that's not at all simple, and
without spending the necessary effort to learn about the maths,
the magnitudes and the other characteristics of these algorithms you
proclaim to be interested in.
There is no shortcut sorry.
Good luck, and enjoy your journey :)
[toc] | [prev] | [next] | [standalone]
| From | "Thomas Schmitt" <scdbackup@gmx.net> |
|---|---|
| Date | 2017-08-29 14:30 +0200 |
| Message-ID | <ujNOy-2zB-9@gated-at.bofh.it> |
| In reply to | #186121 |
Hi, now it's not about information technology any more but about math and the difficulty to properly discuss a mathematical opinion. Zenaan Harkness wrote: > Which myth? The one denounced by Thomas Huehn's article. Saying that /dev/random gets fed directly from the entropy pool: https://www.2uo.de/myths-about-urandom/structure-no.png Zenaan Harkness wrote: > > > I should have wrote "/dev/random should be treated as though it is > > > the input feed to /dev/urandom" (sorry about that). I wrote: > > But that it isn't. The myth model says that it would be. > I can't see the myth in my words that you say is debunked The word "myth" refers to the topic and title the article, not to your words. I apologize for any implied belittleing of your arguments. It was not intentional. > Exactly which part of my sentence above, do you say contradicts what > you say just here? The part that /dev/urandom is equivalent to stemming from /dev/random. They are more or less siblings, according to Thomas Huehn and Andy Smith. > > not a strongly obfuscated but still diluted result. > Yes, your naivety shines through. I am not alone with that https://en.wikipedia.org/wiki/Cryptographically_secure_pseudorandom_number_generator "A CSPRNG can "stretch" the available entropy over more bits." (The authors of that page throw much more math terms than have been in this thread yet. Whether this makes them more credible stays undecided.) Maybe the answer by Jalai in https://crypto.stackexchange.com/questions/1740/stretching-a-random-seed-to-maximize-entropy points out a lower limit for the loss of entropy by exploiting the key of a cipher. Maybe it's a red herring. > This is not the place to gain a deep understanding of > cryptographically secure random numbers You tell me that if i read 1024 bytes from a not very secret stream that was encrypted with a secret 384 bit key i get 1024 bytes of entropy ? I'd like to read the proof for this. > If you want to comprehend the significance of your naivety, find the > number of molecules in the universe, What does this have to do with the question whether N bits of information can give birth to more than N bits of information ? > you're going down completely non-productive rabbit holes, I would like to know how one can be so sure that the holes are not productive. > without spending the necessary effort to learn about the maths, Oh. It's not the math. It's the jumps in the argumentation and the lack of proof for strong statements. I can be convinced. Just give me links to convincing texts. Have a nice day :) Thomas
[toc] | [prev] | [next] | [standalone]
| From | Zenaan Harkness <zenaan@freedbms.net> |
|---|---|
| Date | 2017-08-30 03:50 +0200 |
| Message-ID | <uk0iJ-1Rp-11@gated-at.bofh.it> |
| In reply to | #186126 |
On Tue, Aug 29, 2017 at 02:28:01PM +0200, Thomas Schmitt wrote:
> Hi,
>
> now it's not about information technology any more but about math and the
> difficulty to properly discuss a mathematical opinion.
>
>
> Zenaan Harkness wrote:
> > Which myth?
>
> The one denounced by Thomas Huehn's article.
That's not true.
> Saying that /dev/random
> gets fed directly from the entropy pool:
> https://www.2uo.de/myths-about-urandom/structure-no.png
WHERE in the article does he say that?!!!
The article does not say that!
The image might seem to suggest that.
Once again: QUOTE THE ARTICLE!!!
Then, QUOTE ME.
Then, and only then, might you see where you are going wrong in your
understanding.
At the moment, what you keep doing is essentially handwaving,
appealing to "the article", yet in the next paragraph denouncing (or
expressing your dissatisfaction with) the article.
You cannot have it both ways - as in, either you want precision in
your own understanding, or you just want to hand wave about "that
article" and "some cryptographers" and "what Ted Ts'o said" and what
I said which you reply to.
If you want to get close to understanding that which you're not
understanding about cryptography, you MUST begin to be precise (no
more handwaving exercises).
Quote PRECISELY what someone (ANYONE!) said, and then quote, EXACTLY
what an article or someone else says, that you want to compare the
two statements with.
Frankly Mr Thomas Schmitt, you continue to completely unfairly place
a ridiculous burden upon your conversational compatriots to second-
and triple- guess whatever it is that you might possibly think that
you're trying to say, and further more guess and assume as to what it
is you might be thinking (evidently mostly erroneously) which leads
you to be trying to say whatever it is you're trying to say.
Here's another homework task for you:
Learn the art of axiomatic written communication.
> Zenaan Harkness wrote:
> > > > I should have wrote "/dev/random should be treated as though it is
> > > > the input feed to /dev/urandom" (sorry about that).
>
> I wrote:
> > > But that it isn't. The myth model says that it would be.
>
> > I can't see the myth in my words that you say is debunked
>
> The word "myth" refers to the topic and title the article, not to your words.
>
> I apologize for any implied belittleing of your arguments. It was not
> intentional.
NO!
Again you are misunderstanding me - you are failing to see that I
completely welcome "belittling" of my arguments - I'm not here to win
any cryptography awards, and if I'm wrong, I'd much rather know about
it.
Please see above for my actual points that I am raising. Your lack
of precise communication is completely unfair to put on others when
you are wanting to gain a deeper understanding of cryptography.
> > Exactly which part of my sentence above, do you say contradicts what
> > you say just here?
>
> The part that /dev/urandom is equivalent to stemming from /dev/random.
That i absolutely not what I said.
> They are more or less siblings, according to Thomas Huehn and Andy Smith.
He might have said that, and you seem to want them to be, but both
Huehn's and Smith's position, and your apparent want, are utterly
unrelated to what I said.
There's a name for this technique (unintended by you I presume) which
is called "projection" - you want something to be a certain way, or
assume it is a certain way, and so you project upon the words of
others what you believe or want to believe.
This projection is what you are doing in respect of my words.
It stems from a lack of precision in your communication technique,
and also from putting a VERY unfair burden on your co-communication
partners, and BOTH these two points demonstrate a very unfair
laziness on your part - you are wanting easy answers to difficult
concepts, and are relying upon whoever responds to you to try and
figure out what you're thinking, assuming, projecting and
misunderstanding - in the world of cryptography, that's dangerous for
you if your need for cryptography is related to your safety.
> > > not a strongly obfuscated but still diluted result.
>
> > Yes, your naivety shines through.
>
> I am not alone with that
>
> https://en.wikipedia.org/wiki/Cryptographically_secure_pseudorandom_number_generator
> "A CSPRNG can "stretch" the available entropy over more bits."
Everyone in the world can be wrong about something, or any
significant subset of the people in the world can be wrong about that
thing.
But this fact will never change the fact that they're still wrong
about it.
1. That's wikipedia, not the bible of computational crypto.
2. The term "stretching" is a convenient metaphor.
3. To understand why "stretching" is an appropriate metaphor requires
a deeper understanding of crypto than you or I seem to possess.
4. To understand why "stretching" is an inappropriate metaphor
requires only to see that people keep getting lead up the garden
path of colourful metaphors.
> (The authors of that page throw much more math terms than have been
> in this thread yet. Whether this makes them more credible stays undecided.)
Their credibility is not relevant to your lack of understanding.
You seem to be personally desiring the result of "some external
authority I can trust" vs my preferred personal approach of
"comprehend enough personally to be able to analyse what purported
authorities say on the topic, so that I don't have to rely upon
them."
Whether I have achieved my intention is completely up for debate - I
may well be utterly delusional, and frankly you ought never rely on
anything I ever say, about cryptography or otherwise. I am only an
authority on what I believe that I comprehend about something, and to
the extent that you seek any external (to yourself) authority to
"trust" in respect of computational crypography, means I must,
absolutely, distance myself from you, as any reliance you put on me
is a danger of liability to me.
You cannot rely upon what I say about crypography, so don't even
think about so relying!
> Maybe the answer by Jalai in
> https://crypto.stackexchange.com/questions/1740/stretching-a-random-seed-to-maximize-entropy
> points out a lower limit for the loss of entropy by exploiting the key
> of a cipher.
> Maybe it's a red herring.
Many possibilities, and no one you can rely upon or trust about it -
I suggest the only safe approach is being suspicious of anyone
proclaiming authority, ESPECIALLY in respect of any matter which
might effect you personally.
> > This is not the place to gain a deep understanding of
> > cryptographically secure random numbers
>
> You tell me
So you say! And so you kept implying, and now you so say explicitly!
> that if i read 1024 bytes from a not very secret stream that
> was encrypted with a secret 384 bit key i get 1024 bytes of entropy ?
You are now putting words in my mouth.
You have crossed a line.
Do not do this again.
(The way you have done this is in a way which would undermine the
separation of authority between myself, yourself, any external
authority I may otherwise to choose to trust, and vice versa for
yourself, were I to accept your projected assumptive authority!)
Take my words as you will, but this technique is completely
unacceptable to use in your conversation with me, so speak for
yourself!
I shall continue finish replying to this email, but you can expect
less responses from me foing forward.
> I'd like to read the proof for this.
Whatever proof you need for your own strawmen, is a matter for you -
attempting to extract things out of others in a way which they would
find disrespectful if they understood what you did, is something one
might consider striving to avoid.
> > If you want to comprehend the significance of your naivety, find the
> > number of molecules in the universe,
>
> What does this have to do with the question whether N bits of
> information can give birth to more than N bits of information ?
How do you expect to comprehend the security of any computational
crypto system you choose to use ("trust") if you won't even do the
most basic "cryptographic" math when it is suggested to you that
doing so may well give rise within you to the understanding you
purport to seek?
You must begin to be comfortable in your mind with certain concepts,
and the interrelation of those concepts, and thus be able to
communicate with others (if that's what you want to do) by naming and
comfortably relating those concepts to one another.
Again, how you can you possibly gain within you the understanding you
proclaim to seek, if you cannot communicate readily and freely on
various --foundational-- (to cryptography) concepts?
(This is an axiom of comprehension, also called a principle although
the latter word is overloaded with socio psychological meanings and
thus less preferable for precise communication - but hey, I might be
utterly off base on my axioms, so don't trust for a minute any axiom
that I present - you would merely be projecting authority upon an
external source (me) and failing to know from within yourself, which
(according to this incredibly humble authority) is a "dick move".)
More suggested homework if you truly wish to feel comfortable with
computer crypto (which, evidently it appears, you yet do not):
- magnitudes
- comparing magnitudes
- computational difficulty
- number spaces, and the magnitudes of number spaces
- why cryptography relies on numeric magnitudes
- what it means, computationally, to rely on a numeric magnitude
- how the magnitude relied upon in the kernel random devices
relates to the real world, in a way which is actually useful
(this is your "atoms in the universe" homework bit)
- understand the difference between the "stretching" metaphor
which was provided by the kernel and other tech heads as an
analogy to try to explain difficult concepts to those of us who
struggle to comprehend what's involved in these algorithms
- the difference between information-theoretically secure and
computationally secure
- the difference between theoretical and infeasible computational
security (protip seach term "information theoretic")
> > you're going down completely non-productive rabbit holes,
>
> I would like to know how one can be so sure that the holes are not
> productive.
Your "productivity" is a damn lazy imposition you appear to be
continue putting on those other than myself who apparently wish to
assist in your search for crypto understanding.
> > without spending the necessary effort to learn about the maths,
>
> Oh. It's not the math. It's the jumps in the argumentation and the
> lack of proof for strong statements.
Which you will always flounder around when you have such little
comprehension of the maths involved.
This is what I have termed "cotton wool" thinking - where we want all
our cake (the nice secure crypto in this example) AND to eat it too
(in this example, to understand it to a level where we feel safe in
using it, but without putting the effort in to actually bake the cake
- we just want to eat it without effort).
You can never have it both ways - either you learn, or you will
forever continue to rely on external authorities who appear to
contradict one another, and some proclaimed authorities who do
contradict one another, and many (!) proclaimed authorities who
simply have it wrong.
> I can be convinced. Just give me links to convincing texts.
You do the work - it's your journey! As I said, nothing I say
can be relied upon, so there's no use me saying anything to you,
unfortunately.
Respectfully,
Zenaan
[toc] | [prev] | [next] | [standalone]
| From | "Thomas Schmitt" <scdbackup@gmx.net> |
|---|---|
| Date | 2017-08-30 12:40 +0200 |
| Message-ID | <uk8zE-79l-3@gated-at.bofh.it> |
| In reply to | #186166 |
Hi, Zenaan Harkness wrote: > Once again: QUOTE THE ARTICLE!!! Ouch my eyes. You shout. If the article puts one of its key statements into a diagram, then i cannot quote that directly as text, but only re-narrate it. > Then, QUOTE ME. > quote PRECISELY I did this in many lines. Without shouting and with due dilligence. You just don't like what i say. That's ok. But you should not pretend that it is wrong, instead. > you continue to completely unfairly place > a ridiculous burden upon your conversational compatriots You are obviously not a compatriot of mine in an intellectual way. Mathematics is a very egalitarian science: A valid proof by a novice student is worth as much as by the dean. Both have to stand dialectic criticism rather than to succeed by "Believe Me", "Because I Say So", or "All others believe it's true". You were so unfriendly to call me "naive". Well, in the context of math it is naive to give in to unproven statements which smell like "5 is an even number". I don't have to present any credentials before i am allowed to bring a counter example to a statement. > Learn the art of axiomatic written communication. If you are willing to accept that the number of molecules in the universe is only a big one if you count it with your fingers, then i am willing to learn what you mean with "axiomatic written communication". The incomplete and suppressed physicist in me cannot keep himself from saying the following. Zenaan Harkness wanted to give a really big number: > find the > number of molecules in the universe, and then work out roughly how > many bits (i.e. as a power of two number) are needed to store that, > and then compare this to the number of bits of entropy Ts'o talked > about. I need a box with two distinguishable halves and 384 different gas molecules to represent said bits by the coarse distinction which molecule is in which half. I am sure that i can compose 384 different molecules if i use isotopes and all my chemistry set. But if i fail, i take 149 numbered dices and use them as replacement. (384*log(2)/log(6)) 2 exp 384 is not a big number compared with a BD-RE medium which has at least 2 exp 200,000,000,000 valid content states. So my number is much bigger than yours and i still can hold it by two fingers. But this does not help me with doubting the information production by a deterministicly encrypted stream. For that we need a proof by contradiction: Let us assume we can squeeze 1024 bits of entropy from a deterministic cipher stream with 2 exp 384 distinguishable starting states. So the possible streams can be enumerated by the natural numbers below 2 exp 384. This establishes a lossless compression algorithm if we replace the streams by their enumeration numbers. But entropy is a lower limit for lossless compression. So any existing lossless compression is an upper limit of entropy. So we get: 384 >= 1024. This is obviously wrong (at least in my fork of math) and thus we have a contradiction derived from our assumption, which therefore must be wrong, too. > I'm not here to win That's trivial. We have no umpire and you can't knock me out physically. > > > Exactly which part of my sentence above, do you say contradicts what > > > you say just here? > > The part that /dev/urandom is equivalent to stemming from /dev/random. > That i absolutely not what I said. If you already noted my word "equivalent" then please explain why this is a misquote of your "treated as though" statement in https://www.mail-archive.com/debian-user@lists.debian.org/msg720104.html > ... > I should have wrote "/dev/random should be treated as though it is > ... > the input feed to /dev/urandom" (sorry about that). > you are wanting easy answers to difficult concepts, No. I am demanding that your fork of math can answer some simple objections. It's your plight to prove what you state, not mine. I am in the comfortable position to only have to throw in counter examples. If the counter examples are simple, then this characterizes your statements, not my mind. > You seem to be personally desiring the result of "some external > authority I can trust" Actually not. I want to see the proofs of your courageous statements. But you rather take offense from me not seeing you as authority. > You cannot rely upon what I say about crypography, so don't even > think about so relying! Didn't you just shout at me because you hate my disbelief about your statements ? Now you agree ? > I suggest the only safe approach is being suspicious of anyone > proclaiming authority, Are you sure you are alone in your head ? > You have crossed a line. > Do not do this again. ... or else ? I wrote: > > > > not a strongly obfuscated but still diluted result. Zenaan Harkness wrote: > > Yes, your naivety shines through. > > You tell me > > that if i read 1024 bytes from a not very secret stream that > > was encrypted with a secret 384 bit key i get 1024 bytes of entropy ? > You are now putting words in my mouth. I just derive an objection from your statement that more than 384 bits from a 384 bit key do not contain less entropy than from a longer key. (Actually i wanted to write "bits" instead of "bytes" in my original statement. But my objection stays valid with 1024 bytes too.) Now it is up to you - at least in math - to prove that the objection is wrong. I doubt you can, because above i provided a proof of its correctness. (The first proof in this whole thread, btw.) > I shall continue finish replying to this email, but you can expect > less responses from me foing forward. A single one with proper proofs would be enough. > More suggested homework > - magnitudes I think i already ridiculed the size of your numbers sufficiently. :)) > - the difference between theoretical and infeasible computational > security (protip seach term "information theoretic") Well, i said a few mails ago that now it is about math, not about what you or i believe that others can do. If you create a math where "nearly true" and "true" are considered equivalent, then you will soon end up being the Pope. (See Bertrand Russel's proof that he is Pope if 2+2=5.) > myself who apparently wish to > assist in your search for crypto understanding. You assist me ? Inhowfar ? By shouting and calling yourself smarter than me ? > Respectfully, Well, you are entitled to change your attitude as often as you want. My own wish is constant and goes out to the smart and the stupid alike: Have a nice day :) Thomas
[toc] | [prev] | [next] | [standalone]
| From | Andy Smith <andy@strugglers.net> |
|---|---|
| Date | 2017-08-29 14:10 +0200 |
| Message-ID | <ujNvc-2sE-21@gated-at.bofh.it> |
| In reply to | #186120 |
Hello,
On Tue, Aug 29, 2017 at 12:40:48PM +0200, Thomas Schmitt wrote:
> Originally Curt wrote:
> > > > https://www.2uo.de/myths-about-urandom
>
> Zenaan Harkness wrote:
> > Really great myth-debunking article
>
> Up to now i found no credible expert opinion which would clearly
> contradict it. Its language and attitude seems inappropriate for the
> sincere topic it discusses, though.
It links to several cryptographers discussing the topic, though:
https://www.2uo.de/myths-about-urandom/#experts
The author of the article stated that the purpose of it was to have
something to link to when this controversy (which has been going on
for years) rears its head on social media. In that context its style
makes a lot of sense.
Cheers,
Andy
--
https://bitfolk.com/ -- No-nonsense VPS hosting
[toc] | [prev] | [next] | [standalone]
| From | "Thomas Schmitt" <scdbackup@gmx.net> |
|---|---|
| Date | 2017-08-29 15:00 +0200 |
| Message-ID | <ujOhB-2Kk-35@gated-at.bofh.it> |
| In reply to | #186125 |
Hi, Andy Smith wrote: > https://www.2uo.de/myths-about-urandom/#experts So it is about how Daniel Bernstein justifies his claim that it is wrong to say: "we can't figure out how to deterministically expand one 256-bit /dev/random output into an endless stream of unpredictable keys (this is what we need from urandom)," and right to conclude: "For a cryptographer this doesn't even pass the laugh test." How do cryptographers manage to get this miraculous growth of information if the only secret is the 256 bit of /dev/random output ? Why would i need more than 2 exp 256 tries to guess the whole stream ? (I don't point out that this refers to /dev/random as source of /dev/urandom, because i assume that this is only rethorical to illustrate the more general question. Further i understand that Linux changes the key in the time range of minutes. This seems to be a much stronger precaution than just a single key.) (And again, it's not about IT but about math. In practice 2 exp 256 or 2 exp 384 are enormous numbers. Nevertheless, being sloppy in math can bite you in practice.) Have a nice day :) Thomas
[toc] | [prev] | [next] | [standalone]
| From | Zenaan Harkness <zenaan@freedbms.net> |
|---|---|
| Date | 2017-08-30 03:50 +0200 |
| Message-ID | <uk0iJ-1Rp-7@gated-at.bofh.it> |
| In reply to | #186130 |
On Tue, Aug 29, 2017 at 02:52:10PM +0200, Thomas Schmitt wrote:
> Hi,
>
> Andy Smith wrote:
> > https://www.2uo.de/myths-about-urandom/#experts
>
> So it is about how Daniel Bernstein justifies his claim that it is
> wrong to say:
>
> "we can't figure out how to deterministically expand one 256-bit
> /dev/random output into an endless stream of unpredictable keys
> (this is what we need from urandom),"
>
> and right to conclude:
>
> "For a cryptographer this doesn't even pass the laugh test."
This is the specific use-case (generating keys) where you must use
/dev/random, "of course" ("of course" as in, that should hopefully by
now be obvious).
But most people never ever need to worry about this, only those
implementing "actually intended to be reasonably secure" crypto
software.
> How do cryptographers manage to get this miraculous growth of information
> if the only secret is the 256 bit of /dev/random output ?
They don't. You ought not use /dev/urandom for key generation, use
/dev/random instead.
> Why would i need more than 2 exp 256 tries to guess the whole stream ?
Exactly - you would not, but to get an idea of how long that would
take, work out this:
2^256 * $TIME_TO_CHECK_ONE_KEY_VALUE
Alternatively and perhaps more usefully if you are attempting to
actually calculate hardware requirements, multiply your number space
by the number of CPU cycles needed to "check one value" of your
number space.
> (I don't point out that this refers to /dev/random as source of
> /dev/urandom, because i assume that this is only rethorical to
> illustrate the more general question.
> Further i understand that Linux changes the key in the time range
> of minutes. This seems to be a much stronger precaution than
> just a single key.)
You are correct. But don't rely on a thing I say about all this - I
am not an authority on the code, nor the crypto, whatsoever ;)
> (And again, it's not about IT but about math. In practice 2 exp 256
> or 2 exp 384 are enormous numbers.
> Nevertheless, being sloppy in math can bite you in practice.)
Indeed :)
Cheers,
[toc] | [prev] | [next] | [standalone]
| From | Greg Wooledge <wooledg@eeg.ccf.org> |
|---|---|
| Date | 2017-08-30 14:20 +0200 |
| Message-ID | <uka8q-8cq-3@gated-at.bofh.it> |
| In reply to | #186165 |
On Wed, Aug 30, 2017 at 11:47:24AM +1000, Zenaan Harkness wrote:
> They don't. You ought not use /dev/urandom for key generation, use
> /dev/random instead.
The Linux man page disagrees with you. From Debian 9 urandom(4):
The /dev/random device is a legacy interface which dates back to a time
where the cryptographic primitives used in the implementation of
/dev/urandom were not widely trusted. It will return random bytes only
within the estimated number of bits of fresh noise in the entropy pool,
blocking if necessary. /dev/random is suitable for applications that
need high quality randomness, and can afford indeterminate delays.
[...]
Usage
The /dev/random interface is considered a legacy interface, and
/dev/urandom is preferred and sufficient in all use cases, with the
exception of applications which require randomness during early boot
time; for these applications, getrandom(2) must be used instead,
because it will block until the entropy pool is initialized.
[toc] | [prev] | [next] | [standalone]
| From | Gene Heskett <gheskett@shentel.net> |
|---|---|
| Date | 2017-08-30 14:50 +0200 |
| Message-ID | <ukaBr-8nI-5@gated-at.bofh.it> |
| In reply to | #186174 |
On Wednesday 30 August 2017 08:11:05 Greg Wooledge wrote: > On Wed, Aug 30, 2017 at 11:47:24AM +1000, Zenaan Harkness wrote: > > They don't. You ought not use /dev/urandom for key generation, use > > /dev/random instead. > > The Linux man page disagrees with you. From Debian 9 urandom(4): > > The /dev/random device is a legacy interface which dates back > to a time where the cryptographic primitives used in the > implementation of /dev/urandom were not widely trusted. It will > return random bytes only within the estimated number of bits of fresh > noise in the entropy pool, blocking if necessary. /dev/random is > suitable for applications that need high quality randomness, and can > afford indeterminate delays. > > [...] > > Usage > The /dev/random interface is considered a legacy > interface, and /dev/urandom is preferred and sufficient in all use > cases, with the exception of applications which require > randomness during early boot time; for these applications, > getrandom(2) must be used instead, because it will block until the > entropy pool is initialized. I hereby challenge this group to crack this passwd: Uld4dFpYSkdkV1J3ZFdOclpYSUsK And tell me how you arrived at the answer. Cheers, Gene Heskett -- "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) Genes Web page <http://geneslinuxbox.net:6309/gene>
[toc] | [prev] | [next] | [standalone]
| From | "Thomas Schmitt" <scdbackup@gmx.net> |
|---|---|
| Date | 2017-08-30 15:20 +0200 |
| Message-ID | <ukb4t-li-1@gated-at.bofh.it> |
| In reply to | #186178 |
Hi, > I hereby challenge this group to crack this passwd: > Uld4dFpYSkdkV1J3ZFdOclpYSUsK Without the claim to be able to do this again: By enumerating the name "Elmer Fudpucker" (obviously known to the internet) and applying base64 twice: $ echo "ElmerFudpucker" | base64 | base64 Uld4dFpYSkdkV1J3ZFdOclpYSUsK Have a nice day :) Thomas
[toc] | [prev] | [next] | [standalone]
| From | Gene Heskett <gheskett@shentel.net> |
|---|---|
| Date | 2017-08-30 15:30 +0200 |
| Message-ID | <ukbea-oA-21@gated-at.bofh.it> |
| In reply to | #186180 |
On Wednesday 30 August 2017 09:09:49 Thomas Schmitt wrote: > Hi, > > > I hereby challenge this group to crack this passwd: > > Uld4dFpYSkdkV1J3ZFdOclpYSUsK > > Without the claim to be able to do this again: > > By enumerating the name "Elmer Fudpucker" (obviously known to the > internet) and applying base64 twice: > > $ echo "ElmerFudpucker" | base64 | base64 > Uld4dFpYSkdkV1J3ZFdOclpYSUsK > > > Have a nice day :) > Well, that easy to remember method just went down in flames. Sigh... > Thomas Cheers Thomas, Gene Heskett -- "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) Genes Web page <http://geneslinuxbox.net:6309/gene>
[toc] | [prev] | [next] | [standalone]
| From | "Thomas Schmitt" <scdbackup@gmx.net> |
|---|---|
| Date | 2017-08-30 15:50 +0200 |
| Message-ID | <ukbxw-uZ-23@gated-at.bofh.it> |
| In reply to | #186182 |
Hi, Gene Heskett wrote: > Well, that easy to remember method just went down in flames. Sigh... That's the first diffuse but significant wisdom we found in this thread: If you can memorize it without the help of publicly knowable details of your life, then it's too easy to enumerate with nowadays' hardware. Another wisdom is that Theodore T'so, a well reputed and mindful person who is also the kernel maintainer of "RANDOM NUMBER DRIVER", flatly thinks that /dev/random is legacy as soon as the system is fully up. The reason why this is still not fully reflected by the man page is not yet uncovered. It might have its roots in the sloppy mathematical discussion style of people like those quoted in https://www.2uo.de/myths-about-urandom/#experts except, i'd say, Thomas Pornin who is quoted with "indistinguishable from true randomness, given existing technology." Probably the others have moments of more exactness, too. But at least in their quotes this is not to see. An important argument is that of the armored safe with cardboard backplane. If you have a really good password and really manage to memorize it in your brain alone, then there are other real life methods to get to your private stuff. Insofar i confess that all my resisting and objecting is more sport than real business. My aplogies to all annoyed bystanders. I will do it again. Have a nice day :) Thomas
[toc] | [prev] | [next] | [standalone]
| From | Gene Heskett <gheskett@shentel.net> |
|---|---|
| Date | 2017-08-30 16:00 +0200 |
| Message-ID | <ukbHc-yr-37@gated-at.bofh.it> |
| In reply to | #186184 |
On Wednesday 30 August 2017 09:47:35 Thomas Schmitt wrote: > Hi, > > Gene Heskett wrote: > > Well, that easy to remember method just went down in flames. > > Sigh... > > That's the first diffuse but significant wisdom we found in this > thread: > > If you can memorize it without the help of publicly knowable details > of your life, then it's too easy to enumerate with nowadays' hardware. > > > Another wisdom is that Theodore T'so, a well reputed and mindful > person who is also the kernel maintainer of "RANDOM NUMBER DRIVER", > flatly thinks that /dev/random is legacy as soon as the system is > fully up. > > The reason why this is still not fully reflected by the man page is > not yet uncovered. Maybe a wee bit of security by obscurity? There is that I think in everyones thinking on this subject. They don't want to price the farm so cheap that it will actually sell. > It might have its roots in the sloppy mathematical discussion style of > people like those quoted in > https://www.2uo.de/myths-about-urandom/#experts > except, i'd say, Thomas Pornin who is quoted with > "indistinguishable from true randomness, given existing technology." > Probably the others have moments of more exactness, too. But at least > in their quotes this is not to see. > > > An important argument is that of the armored safe with cardboard > backplane. > > If you have a really good password and really manage to memorize it in > your brain alone, then there are other real life methods to get to > your private stuff. > Insofar i confess that all my resisting and objecting is more sport > than real business. My aplogies to all annoyed bystanders. I will do > it again. > Please do. > > Have a nice day :) You too. > Thomas Cheers, Gene Heskett -- "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) Genes Web page <http://geneslinuxbox.net:6309/gene>
[toc] | [prev] | [next] | [standalone]
| From | Greg Wooledge <wooledg@eeg.ccf.org> |
|---|---|
| Date | 2017-08-30 16:10 +0200 |
| Message-ID | <ukbQU-R3-51@gated-at.bofh.it> |
| In reply to | #186185 |
On Wed, Aug 30, 2017 at 09:57:34AM -0400, Gene Heskett wrote: > On Wednesday 30 August 2017 09:47:35 Thomas Schmitt wrote: > > The reason why this is still not fully reflected by the man page is > > not yet uncovered. > > Maybe a wee bit of security by obscurity? Or you're not reading the current man pages. The man page has changed in stretch. The "legacy" wording is not in wheezy's or jessie's.
[toc] | [prev] | [next] | [standalone]
| From | Gene Heskett <gheskett@shentel.net> |
|---|---|
| Date | 2017-08-30 18:50 +0200 |
| Message-ID | <ukelH-2il-17@gated-at.bofh.it> |
| In reply to | #186186 |
On Wednesday 30 August 2017 10:07:09 Greg Wooledge wrote: > On Wed, Aug 30, 2017 at 09:57:34AM -0400, Gene Heskett wrote: > > On Wednesday 30 August 2017 09:47:35 Thomas Schmitt wrote: > > > The reason why this is still not fully reflected by the man page > > > is not yet uncovered. > > > > Maybe a wee bit of security by obscurity? > > Or you're not reading the current man pages. The man page has changed > in stretch. The "legacy" wording is not in wheezy's or jessie's. Which is wheezy's version I am reading. But you-all know how to fix that. :) Cheers, Gene Heskett -- "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) Genes Web page <http://geneslinuxbox.net:6309/gene>
[toc] | [prev] | [next] | [standalone]
| From | "Thomas Schmitt" <scdbackup@gmx.net> |
|---|---|
| Date | 2017-08-30 16:30 +0200 |
| Message-ID | <ukcad-ZN-7@gated-at.bofh.it> |
| In reply to | #186185 |
Hi, i wrote: > > The reason why this is still not fully reflected by the man page is > > not yet uncovered. Gene Heskett wrote: > Maybe a wee bit of security by obscurity? There is that I think in > everyones thinking on this subject. They don't want to price the farm > so cheap that it will actually sell. Ah no. The obscurity principle is unpopular in cryptography. The widely accepted method is to have the algorithms public, so they can be analysed and discussed, and to have the secrets separated in keys. Given that Theodore T'so can probably cause a text change in the man page if he really demands it, i rather expect to find a nitpicker like me who challenges the flat deprecation of /dev/random by some thin but valid argument. Just a gut feeling of mine. For my own decision of /dev/random against /dev/urandom: I use either of them very rarely. I have to deal with several old kernels of which i do not know how firm the opinions were when those kernels were young. So i will continue to use the legacy interface as long as it is available. But i will not raise objections if some day it becomes exactly the same as the /dev/urandom interface. This is the decision of the maintainers (Theodore T'so and Neil Horman of CRYPTOGRAPHIC RANDOM NUMBER GENERATOR), whom i deem more educated on the topic than i am. Have a nice day :) Thomas
[toc] | [prev] | [next] | [standalone]
Page 4 of 6 — ← Prev page 1 2 3 [4] 5 6 Next page →
Back to top | Article view | linux.debian.user
csiph-web