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 | 17 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 6 of 6 — ← Prev page 1 2 3 4 5 [6]
| From | Brian <ad44@cityscape.co.uk> |
|---|---|
| Date | 2017-08-27 16:00 +0200 |
| Message-ID | <uj6gx-8rz-13@gated-at.bofh.it> |
| In reply to | #186006 |
On Sat 26 Aug 2017 at 21:14:35 -0500, Mario Castelán Castro wrote: > On 26/08/17 13:25, Brian wrote: > > How does this > > > > echo 'secretpassword' | sha256sum - | base64 | cut -c -30 | head -1 > > > > compare with your recommendation? > > I do not see the point in this post-processing. > > It seems that you have a very wrong impression of what makes a password > generation scheme be a good password generation scheme. I'd be prepared to accept lacking :). But that's inevitable when dealing with the innards of an unfamiliar topic. I'm getting better, though. > For any probability distribution fixed in advanced, the *expected* (in > the sense used in probability theory) entropy of a password generated > with my scheme is well defined and at least 132 bits (I wanted 128 bits, > but using Base64 the choice is between 132 bits and 126 bits because 132 > is not a multiple of 6). In other words, if you take a probability > distribution and keep if fixed while generating a big amount of > passwords with my scheme, the average entropy under that probability > distribution will be at least (within sampling error) 132 bits. > > This property is achieved *because* there is a source of randomness > (that we can assume, has uniform distribution and thus maximal entropy > per byte) in my generation scheme, not because of Base64. Base64 is > there just to turn the random bytes into a *short* human-readable > string. One could turn the random bytes instead into a list of words (as > long as the mapping is one-to-one) and the same property about expected > entropy would hold, but then the password would be *much* longer. > > Length is the *only* reason to use Base64 here instead of using the > random bytes to choose words at random. > > By contrast, your “scheme” has no systematic source of randomness. It > requires that one has already decided for a “randompassword”, and then > post-process it. If the attacker knows the post-processing, guessing > this password is at least as easy than guessing the input to the > post-processing step (plus computing the hash and encoding, but this is > negligible). Moreover, your post-processing stage loses information, as > another user has already noted. If the attacker knows your > post-processing method, he can speed the search by avoid trying the > passwords that could not be possibly generated with your method because > of this loss of information. > > For example, your method will never generate a string of '0000...' > because the input to Base64 are hex digits in ASCII, which never have > the byte value 0 (0 is unprintable). > > If the attacker does not know the post-processing stage, then maybe he > will eventually begin to guess that your password is an human-generated > password ran through a post-processing stage. Then very possibly your > post-processing adds security (because the attacker has to guess the > post-processing method too), but how much? *It is not well defined*. We > already talked about non-well-defined probabilities, so I will not > repeat that fragment. Thank you for the detailed explanation. I had already come to some of the conclusions in your account but it is good to have them firmly and succinctly laid out. -- Brian.
[toc] | [prev] | [next] | [standalone]
| From | Mario Castelán Castro <marioxcc.MT@yandex.com> |
|---|---|
| Date | 2017-08-27 16:40 +0200 |
| Message-ID | <uj6Tf-u9-7@gated-at.bofh.it> |
| In reply to | #186015 |
[Multipart message — attachments visible in raw view] — view raw
On 27/08/17 08:55, Brian wrote: > Thank you for the detailed explanation. I had already come to some of > the conclusions in your account but it is good to have them firmly and > succinctly laid out. You are welcome. -- Do not eat animals, respect them as you respect people. https://duckduckgo.com/?q=how+to+(become+OR+eat)+vegan
[toc] | [prev] | [next] | [standalone]
| From | Mario Castelán Castro <marioxcc.MT@yandex.com> |
|---|---|
| Date | 2017-09-01 17:00 +0200 |
| Message-ID | <ukVAm-6tL-9@gated-at.bofh.it> |
| In reply to | #185717 |
[Multipart message — attachments visible in raw view] — view raw
On 22/08/17 10:04, Mario Castelán Castro wrote: > I have the following line in my Bash init file: > > “alias gen-password="head -c 16 /dev/urandom | base64 | head -c 22 && echo"” > > This generates a password with just above 128 bits of entropy. You may > find it useful. A slight simplification: alias gen-password="head -c 16 /dev/urandom | base64 | cut -c -22" -- Do not eat animals; respect them as you respect people. https://duckduckgo.com/?q=how+to+(become+OR+eat)+vegan
[toc] | [prev] | [next] | [standalone]
| From | Brian <ad44@cityscape.co.uk> |
|---|---|
| Date | 2017-09-01 21:50 +0200 |
| Message-ID | <ul070-15q-19@gated-at.bofh.it> |
| In reply to | #186279 |
On Fri 01 Sep 2017 at 09:58:19 -0500, Mario Castelán Castro wrote: > On 22/08/17 10:04, Mario Castelán Castro wrote: > > I have the following line in my Bash init file: > > > > “alias gen-password="head -c 16 /dev/urandom | base64 | head -c 22 && echo"” > > > > This generates a password with just above 128 bits of entropy. You may > > find it useful. > > A slight simplification: > > alias gen-password="head -c 16 /dev/urandom | base64 | cut -c -22" I too would like to adjust some of my arguments to meet the many good points which have been raised in this thread. Here is a password F!Vz5s19WuXa61PaA"+5 for my bank. Where does the password come from? It doesn't matter. Let us say I wrote down as I sat and watched TV. It is not a result of the what is above. Is this going to be guessed in any reasonable time by being attacked online? I would say not. It actually fulfills all the conditions that many banking sites advise. Numerals, upper and lower case letters and symbols and no dictionary words. Plus it has length. A star example, in other words. Unbeknownst to me (and totally outside my area of responsibility) the bank's database is seriously compromised; an attack on its structure (or a disgruntled employee) leads to the hashed passwords being leaked. How safe is the password above? Word lists would not seem to dint it. Patterns? There do not appear to be any. For all intents and purposes, when it comes to cracking it, it would have to be treated as a randomly produced password. It looks like brute force is the only way to go. That is an awfully long time to crack it; just like passwords produced from those generated by the function above. Meanwhile, the breach has been discovered and an alert sent to affected people. I can change my password. It is not all bad news. -- Brian.
[toc] | [prev] | [next] | [standalone]
| From | "Thomas Schmitt" <scdbackup@gmx.net> |
|---|---|
| Date | 2017-09-01 23:50 +0200 |
| Message-ID | <ul1Z8-2jb-21@gated-at.bofh.it> |
| In reply to | #186285 |
Hi, Brian wrote: > Here is a password > F!Vz5s19WuXa61PaA"+5 > Where does the password come from? It doesn't matter. But that's the cardboard backplane of the passwords which a human brain can memorize: They have an origin or a memory hook. Long passwords from a good random number generator are rock solid. But you have to store them in an information technology device or write them down on paper and toggle them correctly each time you use them. > It looks like brute force is the only way to go. Yes. Enumeration is brute force. But the skilled enumerator will try to skip the wide areas of really strong passwords in favor of those narrow ones which a human can remember. You need to be a very unusual person with an unusual memory to quite surely beat the computing power of our days. As a litmus test, i propose you google each of the ideas in the memory hook of your password. If they all yield some valid hits, then you can expect them to be in the enumeration pool of big attackers. That's what fascinates me with the idea of a super slow publicly known hash algorithm. It would annoy enumerators where it hurts them most: time. If you at home spend 4 seconds once per login, they might have to spend with their million CPU machine 4 microseconds a quadrillion times, just to try the passwords that are weaker than yours. 136 years if they don't upgrade their hardware in that time. (90 Moore's Law periods. Hopeless to defend against the expectable progress in computation power.) 1 Quadrillion = 10 exp 15 = 2 exp 49, which i estimate is less than the number of tries in the first article brought by Curt: https://arstechnica.com/information-technology/2013/05/how-crackers-make-minced-meat-out-of-your-passwords/ Have a nice day :) Thomas
[toc] | [prev] | [next] | [standalone]
| From | Jude DaShiell <jdashiel@panix.com> |
|---|---|
| Date | 2017-09-02 11:50 +0200 |
| Message-ID | <ulddU-1hb-3@gated-at.bofh.it> |
| In reply to | #186287 |
We have a 20 character password here with at least two of each kind of symbol in it lowers uppers numbers and symbols. One suggestion I had read about password composition to increase the difficulty slightly was to do all of this and make sure the password starts with a letter either upper or lower case and also ends with an upper case or lower case letter. Given the printable character set of 94 characters excluding spaces the characters being letters come from a potential character set of 52 rather than at best a combined numbers and symbols set of 42 at most. I don't know that this would be effective, but it does seem plausible. On Fri, 1 Sep 2017, Thomas Schmitt wrote: > Date: Fri, 1 Sep 2017 17:44:09 > From: Thomas Schmitt <scdbackup@gmx.net> > To: debian-user@lists.debian.org > Subject: Re: One-line password generator > Resent-Date: Fri, 1 Sep 2017 21:44:44 +0000 (UTC) > Resent-From: debian-user@lists.debian.org > > Hi, > > Brian wrote: >> Here is a password >> F!Vz5s19WuXa61PaA"+5 >> Where does the password come from? It doesn't matter. > > But that's the cardboard backplane of the passwords which a human brain > can memorize: They have an origin or a memory hook. > > Long passwords from a good random number generator are rock solid. > But you have to store them in an information technology device or write > them down on paper and toggle them correctly each time you use them. > > >> It looks like brute force is the only way to go. > > Yes. Enumeration is brute force. But the skilled enumerator will try > to skip the wide areas of really strong passwords in favor of those narrow > ones which a human can remember. > > You need to be a very unusual person with an unusual memory to quite > surely beat the computing power of our days. > As a litmus test, i propose you google each of the ideas in the memory > hook of your password. If they all yield some valid hits, then you can > expect them to be in the enumeration pool of big attackers. > > > That's what fascinates me with the idea of a super slow publicly known > hash algorithm. It would annoy enumerators where it hurts them most: time. > If you at home spend 4 seconds once per login, they might have to spend > with their million CPU machine 4 microseconds a quadrillion times, just > to try the passwords that are weaker than yours. 136 years if they don't > upgrade their hardware in that time. (90 Moore's Law periods. Hopeless to > defend against the expectable progress in computation power.) > > 1 Quadrillion = 10 exp 15 = 2 exp 49, which i estimate is less than the > number of tries in the first article brought by Curt: > https://arstechnica.com/information-technology/2013/05/how-crackers-make-minced-meat-out-of-your-passwords/ > > > Have a nice day :) > > Thomas > > --
[toc] | [prev] | [next] | [standalone]
| From | "Thomas Schmitt" <scdbackup@gmx.net> |
|---|---|
| Date | 2017-09-02 13:00 +0200 |
| Message-ID | <ulejD-1Wa-5@gated-at.bofh.it> |
| In reply to | #186295 |
Hi,
Jude DaShiell wrote:
> We have a 20 character password here with at least two of each kind of
> symbol in it lowers uppers numbers and symbols.
If you produced it by a quite random method then my only potential
criticism would be the question how you memorize it without the risk
that it gets stolen.
(You should refuse to give any detail, of course.)
The problem with memorizable passwords is usually (*) that they stem from
a guessable base secret and then got modified by applying various good
advise, but without losing their property to be easily memorized.
This good advise is known to the attacker, too. The number of different
such advised methods is then an obstacle for enumeration.
The attacker has to try them, as he tries the guessable base secrets.
But that number is not large, compared to affordable computing power.
After all, one must be able to memorize the method which one used.
So it must be quite simple. Simple means few variations.
(*) If you have a very unusual mindset, then your memorizable passwords
might be separate enough from the clusters of other people's memorizable
passwords. Attackers try the most rewarding guesses first.
If you are a plain memory genius:
Congrats. Make a good random password and be safe.
Have a nice day :)
Thomas
[toc] | [prev] | [next] | [standalone]
| From | Brian <ad44@cityscape.co.uk> |
|---|---|
| Date | 2017-09-02 19:20 +0200 |
| Message-ID | <ulkfn-5Iy-3@gated-at.bofh.it> |
| In reply to | #186296 |
On Sat 02 Sep 2017 at 12:52:32 +0200, Thomas Schmitt wrote: > Jude DaShiell wrote: > > We have a 20 character password here with at least two of each kind of > > symbol in it lowers uppers numbers and symbols. > > If you produced it by a quite random method then my only potential > criticism would be the question how you memorize it without the risk > that it gets stolen. > (You should refuse to give any detail, of course.) > > The problem with memorizable passwords is usually (*) that they stem from > a guessable base secret and then got modified by applying various good > advise, but without losing their property to be easily memorized. > > This good advise is known to the attacker, too. The number of different > such advised methods is then an obstacle for enumeration. > The attacker has to try them, as he tries the guessable base secrets. > But that number is not large, compared to affordable computing power. > After all, one must be able to memorize the method which one used. > So it must be quite simple. Simple means few variations. I think you had a provider's compromised database in mind when you wrote this. An attacker would be limited by his imagination and monetary and time costs but, in the end, it could be assumed he would get something out of it. The compromise is also not the user's responsibilty and it is unfair to put the burden for mitigating it on him Jude DaShiell's 20 character password is good enough for online logins to web accounts. The provider should have some type of account lockout in place for failed logins (Facebook and Twitter do this) and 10,000 tries per second would surely be seen as a DoS attack, if not. Guessable? Is this the type of guessing done by friends, acquaintances and close family members to try to get at your gmail or bank account? That is more likely to succeed than the efforts of a criminal mind. > (*) If you have a very unusual mindset, then your memorizable passwords > might be separate enough from the clusters of other people's memorizable > passwords. Attackers try the most rewarding guesses first. > If you are a plain memory genius: > Congrats. Make a good random password and be safe. Random is excellent; write it down or use a password manager. Not so random is less than excellent, but needn't be atrocious (a 20 character password isn't) for an online login, memorable or not. -- Brian.
[toc] | [prev] | [next] | [standalone]
| From | Jude DaShiell <jdashiel@panix.com> |
|---|---|
| Date | 2017-09-02 20:30 +0200 |
| Message-ID | <ulll7-6lO-3@gated-at.bofh.it> |
| In reply to | #186303 |
That was not my password, I only analyzed what was provided earlier and examined it in the way a Federal employee would have analyzed it who worked for the Navy a few years ago. I will not pass on memorable or non-memorable status here either. A couple practices for concealing written passwords may be useful to share here. A site usually has a user and password. With three sheets of paper a numbered list of sites could be on one page. A numbered list of user names could be on a second sheet. A numbered list of passwords could be on a third sheet. Each sheet would have a matching number and that single credential written beside it. Maybe all three sheets could be stored in different places with none of them having any kind of title information on them. Finally, passwords could be written on the third sheet say that are twice as long as what's used. Finally passwords could be written in reverse order with last character first and first character last. Now which half of which password is used and what order are characters properly keyed in? People are getting older and will need to do writing of passwords at some ages to keep functioning. That doesn't necessarily mean any of them need write passwords in the clear though. The important thing is to come up with a system and stick with that system. On Sat, 2 Sep 2017, Brian wrote: > Date: Sat, 2 Sep 2017 13:10:47 > From: Brian <ad44@cityscape.co.uk> > To: debian-user@lists.debian.org > Subject: Re: One-line password generator > Resent-Date: Sat, 2 Sep 2017 17:11:08 +0000 (UTC) > Resent-From: debian-user@lists.debian.org > > On Sat 02 Sep 2017 at 12:52:32 +0200, Thomas Schmitt wrote: > >> Jude DaShiell wrote: >>> We have a 20 character password here with at least two of each kind of >>> symbol in it lowers uppers numbers and symbols. >> >> If you produced it by a quite random method then my only potential >> criticism would be the question how you memorize it without the risk >> that it gets stolen. >> (You should refuse to give any detail, of course.) >> >> The problem with memorizable passwords is usually (*) that they stem from >> a guessable base secret and then got modified by applying various good >> advise, but without losing their property to be easily memorized. >> >> This good advise is known to the attacker, too. The number of different >> such advised methods is then an obstacle for enumeration. >> The attacker has to try them, as he tries the guessable base secrets. >> But that number is not large, compared to affordable computing power. >> After all, one must be able to memorize the method which one used. >> So it must be quite simple. Simple means few variations. > > I think you had a provider's compromised database in mind when you wrote > this. An attacker would be limited by his imagination and monetary and > time costs but, in the end, it could be assumed he would get something > out of it. The compromise is also not the user's responsibilty and it is > unfair to put the burden for mitigating it on him > > Jude DaShiell's 20 character password is good enough for online logins > to web accounts. The provider should have some type of account lockout > in place for failed logins (Facebook and Twitter do this) and 10,000 > tries per second would surely be seen as a DoS attack, if not. > > Guessable? Is this the type of guessing done by friends, acquaintances > and close family members to try to get at your gmail or bank account? > That is more likely to succeed than the efforts of a criminal mind. > >> (*) If you have a very unusual mindset, then your memorizable passwords >> might be separate enough from the clusters of other people's memorizable >> passwords. Attackers try the most rewarding guesses first. >> If you are a plain memory genius: >> Congrats. Make a good random password and be safe. > > Random is excellent; write it down or use a password manager. Not so > random is less than excellent, but needn't be atrocious (a 20 character > password isn't) for an online login, memorable or not. > > --
[toc] | [prev] | [next] | [standalone]
| From | "Thomas Schmitt" <scdbackup@gmx.net> |
|---|---|
| Date | 2017-09-02 21:00 +0200 |
| Message-ID | <ullO9-6x3-1@gated-at.bofh.it> |
| In reply to | #186303 |
Hi, Brian wrote: > I think you had a provider's compromised database in mind when you wrote > this. Yes. That's the way how an attacker can get the biggest harvest and also the risk which you cannot influence from remote. > An attacker would be limited by his imagination and monetary and > time costs but, in the end, it could be assumed he would get something > out of it. It would be desirable if he could not get your password before the service provider takes notice of the theft and decides to take action. > The compromise is also not the user's responsibilty and it is > unfair to put the burden for mitigating it on him If suddenly money vanishes from your account or luxury goods get ordered at your expense, then it will possibly be seen as lame excuse if you point to a possible password theft. > Guessable? Is this the type of guessing done by friends, acquaintances > and close family members to try to get at your gmail or bank account? I rather think of web crawlers, statistical tools, and artificial intelligence on the field of human psychology. The goal is to avoid most of the tries with passwords which a human is very unlikely create. > Random is excellent; write it down or use a password manager. The first advice was deprecated for a long time but seems now to be revived by the necessity to use superhumanly safe passwords. Need makes courageous. The second way means that you give all your passwords to one or a few pieces of software, which might be safe, maybe. You still need to memorize at least one password that is good enough to guard all the others. As for allowing only a limited frequency of tries: If the attacker can steal the encrypted passwords, then he can probably create a version of the password manager software which makes as many tries as fast as the CPU can do. It would help a lot if nobody knows how to make the tries fast. Have a nice day :) Thomas
[toc] | [prev] | [next] | [standalone]
| From | Brian <ad44@cityscape.co.uk> |
|---|---|
| Date | 2017-09-02 22:00 +0200 |
| Message-ID | <ulmKe-74M-37@gated-at.bofh.it> |
| In reply to | #186311 |
On Sat 02 Sep 2017 at 20:58:13 +0200, Thomas Schmitt wrote: > Brian wrote: > > I think you had a provider's compromised database in mind when you wrote > > this. > > Yes. That's the way how an attacker can get the biggest harvest > and also the risk which you cannot influence from remote. True. I'm glad you ackowledged the user has no control over a breaching of the provider's system. > > An attacker would be limited by his imagination and monetary and > > time costs but, in the end, it could be assumed he would get something > > out of it. > > It would be desirable if he could not get your password before the service > provider takes notice of the theft and decides to take action. Very desirable. > > The compromise is also not the user's responsibilty and it is > > unfair to put the burden for mitigating it on him > > If suddenly money vanishes from your account or luxury goods get ordered > at your expense, then it will possibly be seen as lame excuse if you point > to a possible password theft. We are talking here about a provider's system being penetrated and a number of password thefts happening, It is hardly a "lame excuse" if the user uses this in a claim for compensation, so I do not know where you are coming from. The provider is responsible for the information being held on its systems, even if the user has used "password" for the password. > > Guessable? Is this the type of guessing done by friends, acquaintances > > and close family members to try to get at your gmail or bank account? > > I rather think of web crawlers, statistical tools, and artificial > intelligence on the field of human psychology. > The goal is to avoid most of the tries with passwords which a human is > very unlikely create. You would be better off thinking in terms of close family members. They are the ones to beware of. > > Random is excellent; write it down or use a password manager. > > The first advice was deprecated for a long time but seems now to be > revived by the necessity to use superhumanly safe passwords. > Need makes courageous. > > The second way means that you give all your passwords to one or a few pieces > of software, which might be safe, maybe. > You still need to memorize at least one password that is good enough to > guard all the others. > As for allowing only a limited frequency of tries: If the attacker can > steal the encrypted passwords, then he can probably create a version of the > password manager software which makes as many tries as fast as the CPU > can do. > It would help a lot if nobody knows how to make the tries fast. We are back to the offline cracking. It is interesting and mesmorises us because of its technological import but is of zero consequence for online cracking. Do you want to be safe online? Choose a good password and store it safely, Do you want to pre-empt your provider being breached and get ahead of the game? Forget about it. Que Sera, Sera. -- Brian.
[toc] | [prev] | [next] | [standalone]
| From | Zenaan Harkness <zenaan@freedbms.net> |
|---|---|
| Date | 2017-09-02 01:50 +0200 |
| Message-ID | <ul3Rg-3zC-5@gated-at.bofh.it> |
| In reply to | #186285 |
On Fri, Sep 01, 2017 at 08:46:33PM +0100, Brian wrote: > On Fri 01 Sep 2017 at 09:58:19 -0500, Mario Castelán Castro wrote: > > > On 22/08/17 10:04, Mario Castelán Castro wrote: > > > I have the following line in my Bash init file: > > > > > > “alias gen-password="head -c 16 /dev/urandom | base64 | head -c 22 && echo"” > > > > > > This generates a password with just above 128 bits of entropy. You may > > > find it useful. > > > > A slight simplification: > > > > alias gen-password="head -c 16 /dev/urandom | base64 | cut -c -22" > > I too would like to adjust some of my arguments to meet the many good > points which have been raised in this thread. Here is a password > > F!Vz5s19WuXa61PaA"+5 > > for my bank. Where does the password come from? It doesn't matter. Let > us say I wrote down as I sat and watched TV. It is not a result of the > what is above. Is this going to be guessed in any reasonable time by > being attacked online? I would say not. It actually fulfills all the > conditions that many banking sites advise. Numerals, upper and lower > case letters and symbols and no dictionary words. Plus it has length. A > star example, in other words. > > Unbeknownst to me (and totally outside my area of responsibility) the > bank's database is seriously compromised; an attack on its structure (or > a disgruntled employee) leads to the hashed passwords being leaked. > > How safe is the password above? Once you've published a so-called password, it's security value approaches something much closer to "none" than whatever value it used to have - even if it is some fancy hash. Good luck,
[toc] | [prev] | [next] | [standalone]
| From | Zenaan Harkness <zenaan@freedbms.net> |
|---|---|
| Date | 2017-09-02 01:50 +0200 |
| Message-ID | <ul3Rg-3zC-7@gated-at.bofh.it> |
| In reply to | #186279 |
On Fri, Sep 01, 2017 at 09:58:19AM -0500, Mario Castelán Castro wrote: > On 22/08/17 10:04, Mario Castelán Castro wrote: > > I have the following line in my Bash init file: > > > > “alias gen-password="head -c 16 /dev/urandom | base64 | head -c 22 && echo"” > > > > This generates a password with just above 128 bits of entropy. You may > > find it useful. > > A slight simplification: > > alias gen-password="head -c 16 /dev/urandom | base64 | cut -c -22" > > -- > Do not eat animals; respect them as you respect people. > https://duckduckgo.com/?q=how+to+(become+OR+eat)+vegan pwgen is rather convenient too: pwgen -sy 100 (Probably obvious, but as long as you're reading from urandom, "entropy" is the wrong word, in this context, better to say "128 bits of crytographically secure numbers" as that which has been said e.g. by the Linux kernel urandom developers as being "crypographically secure" has changed a few times, and may change again in the future - it it truly were entropy (as /dev/random suggests it provides), the ongoing changes for "security" would not be necessary.) Good luck,
[toc] | [prev] | [next] | [standalone]
| From | Mario Castelán Castro <marioxcc.MT@yandex.com> |
|---|---|
| Date | 2017-09-02 04:40 +0200 |
| Message-ID | <ul6vL-5tq-1@gated-at.bofh.it> |
| In reply to | #186290 |
[Multipart message — attachments visible in raw view] — view raw
On 01/09/17 18:43, Zenaan Harkness wrote: > (Probably obvious, but as long as you're reading from urandom, > "entropy" is the wrong word, in this context, better to say "128 bits > of crytographically secure numbers" as that which has been said e.g. > by the Linux kernel urandom developers as being "crypographically > secure" has changed a few times, and may change again in the future - > it it truly were entropy (as /dev/random suggests it provides), the > ongoing changes for "security" would not be necessary.) No. Entropy is the appropriate word. Please recall that “entropy” is just a different scale for probability and quantities comparable to probability (like expected probability). Nothing more, nothing less. Also note that all the theoretical (and very unrealistic) attacks on /dev/urandom apply only when the attacker knows part of the *past* output of /dev/urandom, and he uses this to predict the *current* and *future* output of /dev/urandom. This is not applicable in our scenario. In short: Given that the state of the CSPRNG is larger than the amount of bits read[1], the bits can be assumed to be distributed at random. Longer answer: According to my reading of <https://github.com/torvalds/linux/blob/master/drivers/char/random.c>, /dev/urandom uses a variation of ChaCha20 which is periodically re-seeded from the “entropy pool”. In a reasonable scenario for password generation, the attacker does not know the state of the 512-bit CRNG state, and so the best he can do in practice is to model it with uniform probability distribution. According to my understanding, the output of /dev/urandom when reading with my command will be truncate(ChaCha20(X)) where (X) is the aforesaid 512-bit state and “truncate” is the function that returns the first 128 bits of its input. The processing with ChaCha20 and truncation skew the distribution a bit, but this is negligible. As a side note, I noticed that Linux uses weird constants in the ChaCha20 input for the aforesaid CSPRNG: the ASCII text “expand 32-byte k”. This looks like a bad choice, but I doubt that it has any security impact in practice. Anyway, they should have used the constants recommended by D, J. Bernstein (the designer of ChaCha20). [1]: 384 bits according to my understanding, since 128 of the 512 bits feed to ChaCha seem to be fixed to the ASCII “expand 32-byte k”. -- Do not eat animals; respect them as you respect people. https://duckduckgo.com/?q=how+to+(become+OR+eat)+vegan
[toc] | [prev] | [next] | [standalone]
| From | Zenaan Harkness <zenaan@freedbms.net> |
|---|---|
| Date | 2017-09-02 05:40 +0200 |
| Message-ID | <ul7rP-662-3@gated-at.bofh.it> |
| In reply to | #186292 |
On Fri, Sep 01, 2017 at 09:38:14PM -0500, Mario Castelán Castro wrote:
> On 01/09/17 18:43, Zenaan Harkness wrote:
> > (Probably obvious, but as long as you're reading from urandom,
> > "entropy" is the wrong word, in this context, better to say "128 bits
> > of crytographically secure numbers" as that which has been said e.g.
> > by the Linux kernel urandom developers as being "crypographically
> > secure" has changed a few times, and may change again in the future -
> > it it truly were entropy (as /dev/random suggests it provides), the
> > ongoing changes for "security" would not be necessary.)
>
> No. Entropy is the appropriate word. Please recall that “entropy” is
> just a different scale
Use of the word "scale" is one example of things that lead people to
use loose terms like "stretching of entropy", which, though useful in
certain contexts, not only readily give rise to imprecise
comprehension in the mind of someone who has no robust definition of
the term, but is mathematically bogus on the face of it, unless one
gets really really precise in each and every definition of every term
in ones "turtles on turtles" stack of term.
We humans are in general woefully untrained in axiomatic
communication and thus abundant confusions and misunderstandings
arise (and I'm no less guilty of misunderstandings than anyone else -
this is in the nature of human communication).
> for probability and quantities comparable to
> probability (like expected probability). Nothing more, nothing less.
https://en.wikipedia.org/wiki/Entropy_(information_theory)
"Information entropy is defined as the average amount of information
produced by a probabilistic stochastic source of data."
(See also for disambiguation:
https://en.wikipedia.org/wiki/Entropy_(disambiguation)#Information_theory_and_mathematics
)
Now let's go to that first links second sentence:
"The measure of information entropy associated with each possible
data value is the negative logarithm of the probability mass function
for the value."
I am not mathematically literate enough to even properly parse that
sentence!
The last two sentences of that first paragraph sound a little more
comprehendable/ promising:
"Generally, entropy refers to disorder or uncertainty, and the
definition of entropy used in information theory is directly
analogous to the definition used in statistical thermodynamics. The
concept of information entropy was introduced by Claude Shannon in
his 1948 paper "A Mathematical Theory of Communication"."
>From my naieve comprehension of what I read here, the term "entropy
stretching" kind of makes sense - there's a statistical "amount" of
randomness, and that randomness is "spread" over the Linux kernel's
"entropy pool" by the mixing function (ChaCha or something these
days), and so there may only be 1 bit of entropy fed into that pool
in say a 5 minute period, which could make it easier for an attacker
to reverse-calculate a primary key generated some minutes ago if say
he is able to suck out a high rate of numbers directly from the
kernel's /dev/urandom "output source".
Yet as soon as one more bit is fed ("randomly" by the mixing
function) into that pool about 5 minutes later (and thereafter
further bits each 5 minutes), the difficulty of reverse calculating
what some key-generating program may have been delivered by
/dev/urandom ~5minutes ago, steadily becomes exponentially more
difficult - even IF you were able to extract a high rate of output
from /dev/urandom.
On this basis of "understanding", I can understand why Ted Ts'o
appears to be saying "just use /dev/urandom, even when you're
generating primary keys for highly important data" - there's enough
"entropy spread 'randomly' throughout the kernel's 'entropy' pool"
that /dev/urandom is nowhere near the weak link in your security
(software) stack, let alone your hardware stack with e.g. Intel RME
etc etc.
> Also note that all the theoretical (and very unrealistic) attacks on
> /dev/urandom apply only when the attacker knows part of the *past*
> output of /dev/urandom, and he uses this to predict the *current* and
> *future* output of /dev/urandom. This is not applicable in our scenario.
In general, absolutely yes. The difficulty of extracting any rate of
numbers out of your target's remote server's /dev/urandom device, is
a significant challenge in and of itself, and if you've achieved
that, you almost certainly have 0wned the machine already, and it's
at that point one hell of a lot easier to just scan the memory of
that server to extract the keys of interest directly - thus in real
world scenarios, such /dev/urandom attacks are (have always been?)
pretty close to "entirely theoretical, no one would ever bother
anyway given any reasonable implementation of /dev/urandom".
> In short: Given that the state of the CSPRNG is larger than the amount
> of bits read[1], the bits can be assumed to be distributed at random.
Ack.
> Longer answer:
>
> According to my reading of
> <https://github.com/torvalds/linux/blob/master/drivers/char/random.c>,
> /dev/urandom uses a variation of ChaCha20 which is periodically
> re-seeded from the “entropy pool”.
>
> In a reasonable scenario for password generation, the attacker does not
> know the state of the 512-bit CRNG state, and so the best he can do in
> practice is to model it with uniform probability distribution.
Ack.
> According to my understanding, the output of /dev/urandom when reading
> with my command will be truncate(ChaCha20(X)) where (X) is the aforesaid
> 512-bit state and “truncate” is the function that returns the first 128
> bits of its input. The processing with ChaCha20 and truncation skew the
> distribution a bit, but this is negligible.
Interesting - I thought ChaCha was being used because it was such a
good (non-skewing, suitably crypto-random mixing, reasonably
performant) algorithm.
Even theoretical attacks will undoubtedly focus on this skewing, if
indeed ChaCha20, or the implementation of it in the kernel, is
actually skewing.
> As a side note, I noticed that Linux uses weird constants in the
> ChaCha20 input for the aforesaid CSPRNG: the ASCII text “expand 32-byte
> k”. This looks like a bad choice, but I doubt that it has any security
> impact in practice.
I assume the opposite - almost always, such constants will and do
effect security of the algorithm, AIUI. It may be that this constant
is a "more recent/ more recommended" constant to use over the one in
"the official ChaCha20 standard" (whatever/wherever that is), or that
ChaCha2 says something like "you can generate constants for this
constant value in the following way, and it is (or is not, or doesn't
matter) recommended to do so.
> Anyway, they should have used the constants
> recommended by D, J. Bernstein (the designer of ChaCha20).
I have not read his ChaCha paper for a long time - I don't remember
what he actually recommends in this regard. It is unwise for either
of us to express certainty on the matter when what he actually says
can be readily looked up.
> [1]: 384 bits according to my understanding, since 128 of the 512 bits
> feed to ChaCha seem to be fixed to the ASCII “expand 32-byte k”.
Good luck,
[toc] | [prev] | [next] | [standalone]
| From | Mario Castelán Castro <marioxcc.MT@yandex.com> |
|---|---|
| Date | 2017-09-02 16:40 +0200 |
| Message-ID | <ulhKy-45Y-5@gated-at.bofh.it> |
| In reply to | #186293 |
[Multipart message — attachments visible in raw view] — view raw
On 01/09/17 22:33, Zenaan Harkness wrote: > On Fri, Sep 01, 2017 at 09:38:14PM -0500, Mario Castelán Castro wrote: >> No. Entropy is the appropriate word. Please recall that “entropy” is >> just a different scale > > Use of the word "scale" is one example of things that lead people to > use loose terms like "stretching of entropy", which, though useful in > certain contexts, not only readily give rise to imprecise > comprehension in the mind of someone who has no robust definition of > the term, but is mathematically bogus on the face of it, unless one > gets really really precise in each and every definition of every term > in ones "turtles on turtles" stack of term. When I mean entropy, I say “entropy”. I mean what I say. It is not my guilt that other people misuse this word. The entropy of the random distributions in the relevant cases here are perfectly defined. From the fact that *YOU* do not understand the definition does not follow that it is “mathematically bogus”. > Now let's go to that first links second sentence: > "The measure of information entropy [...]" > > I am not mathematically literate enough to even properly parse that > sentence! Here (and through the rest of your message) you are admitting that you do not understand the meaning of entropy in probability theory. Yet you are making statements about entropy. This is intellectually dishonest, to say the least. >> According to my understanding, the output of /dev/urandom when reading >> with my command will be truncate(ChaCha20(X)) where (X) is the aforesaid >> 512-bit state and “truncate” is the function that returns the first 128 >> bits of its input. The processing with ChaCha20 and truncation skew the >> distribution a bit, but this is negligible. > > Interesting - I thought ChaCha was being used because it was such a > good (non-skewing, suitably crypto-random mixing, reasonably > performant) algorithm. Indeed, when properly used, ChaCha20 is good as far as I can tell. Roughly speaking, we are computing hash(X) to derive the 128 bits read by my one-liner. Even though we assume that “X” is uniformly distributed among a 384 bit space, we assume that “hash” will give a random result for each input, independent of the value it gives for the rest of the inputs. Thus with near certainty, some values will be more probable than other values, but (by “the law of the large numbers”) only by a tiny difference from what an uniform/unbiased distribution would require. This is a phenomenon applicable to hash-like functions in general. It is not a flaw of ChaCha20. > Even theoretical attacks will undoubtedly focus on this skewing, if > indeed ChaCha20, or the implementation of it in the kernel, is > actually skewing. This is an unjustified statement. >> As a side note, I noticed that Linux uses weird constants in the >> ChaCha20 input for the aforesaid CSPRNG: the ASCII text “expand 32-byte >> k”. This looks like a bad choice, but I doubt that it has any security >> impact in practice. > > I assume the opposite - almost always, such constants will and do > effect security of the algorithm, AIUI. This is yet another unjustified assumption. -- Do not eat animals; respect them as you respect people. https://duckduckgo.com/?q=how+to+(become+OR+eat)+vegan
[toc] | [prev] | [next] | [standalone]
| From | Zenaan Harkness <zenaan@freedbms.net> |
|---|---|
| Date | 2017-09-04 01:10 +0200 |
| Message-ID | <ulMbD-68R-7@gated-at.bofh.it> |
| In reply to | #186300 |
On Sat, Sep 02, 2017 at 09:33:10AM -0500, Mario Castelán Castro wrote: > On 01/09/17 22:33, Zenaan Harkness wrote: > > I am not mathematically literate enough to even properly parse that > > sentence! > > Here (and through the rest of your message) you are admitting that you > do not understand the meaning of entropy in probability theory. Yet you > are making statements about entropy. This is intellectually dishonest, > to say the least. Touché :)
[toc] | [prev] | [standalone]
Page 6 of 6 — ← Prev page 1 2 3 4 5 [6]
Back to top | Article view | linux.debian.user
csiph-web