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 3 of 6 — ← Prev page 1 2 [3] 4 5 6 Next page →
| From | Aaron Toponce <aaron.toponce@gmail.com> |
|---|---|
| Date | 2017-08-23 21:40 +0200 |
| Message-ID | <uhJFo-4ES-13@gated-at.bofh.it> |
| In reply to | #185790 |
[Multipart message — attachments visible in raw view] — view raw
On Wed, Aug 23, 2017 at 03:23:50PM -0400, Greg Wooledge wrote:
> On Wed, Aug 23, 2017 at 01:16:56PM -0600, Aaron Toponce wrote:
> > Three POSIX-compliant shell functions that rely on no extra utilities
> > shuff () {
> > if [ $(command -v shuf) ]
>
> Needs quotes.
Good catch.
> > shuffle -f /dev/stdin -p "$1"
>
> /dev/stdin is not POSIX-compliant.
Interesting. I was not aware of that.
> > else
> > awk 'BEGIN{
> > "od -tu4 -N4 -A n /dev/urandom" | getline
>
> /dev/urandom is not POSIX-compliant. Then again, I don't believe there
> is *any* POSIX-compliant source of randomness available to shell scripts
> other than awk's srand and rand.
>
> Emulating /dev/urandom in awk is left as an exercise. ;-)
>
> > [ $(uname) = "SunOS" ] && FILE="/usr/dict/words" || FILE="/usr/share/dict/words"
>
> It'd be better to list all the possible places the dict file may exist,
> and iterate through them until you find it, regardless of uname.
Agreed. I tested this on the BSDs, GNU/Linux, and Solaris/OmniOS/SmartOS. I
don't have access to HP-UX, IBM AIX, True64, and some of the other Unices. Is
Plan9 still a thing?
> Also, don't use all-caps shell variable names. All-caps names are
> reserved for special internal variables, and environment variables.
I've gone back and forth on this. I'd be interested to see a standard
specification on this, if such exists. It seems convention that uppercase is
used more frequently for shell variables than lowercase. I've tended to lean on
uppercase more frequently as a result. Just so long as it doesn't clash with
existing variables, I don't see the reason not to.
--
. o . o . o . . o o . . . o .
. . o . o o o . o . o o . . o
o o o . o . . o o o o . o o o
[toc] | [prev] | [next] | [standalone]
| From | Fungi4All <fungilife@protonmail.com> |
|---|---|
| Date | 2017-08-23 22:50 +0200 |
| Message-ID | <uhKL9-5jQ-31@gated-at.bofh.it> |
| In reply to | #185791 |
[Multipart message — attachments visible in raw view] — view raw
One thing is for sure, with the good ol'boyz club of developers and ex-developers there is no room on this list for /users Which proves my theory that it is insiders of the linux community that make it so hostile for the rest of the world, due to their insecurity their good ol'boy club will collapse. At least non-free systems maintain a distance between the psycho bunch called devs and the public. It may be worth paying to keep them isolated. I wonder, without knowing so much, would a tiny little script of a daemon record this long password whether you typed it in or a randomizing engine produced it, internally? Your dear and beloved init system can always escape with it. And you can not tell me it is not true unless you go through a few miles of code produced each week, and that makes it randomly likely that you would miss it anyway thinking it is something else. I am out of here, out of this hell hole you pretend is a support group for users. Sorry if I upset anyone's dinner appetite.
[toc] | [prev] | [next] | [standalone]
| From | Terence <terence.john@gmail.com> |
|---|---|
| Date | 2017-08-23 23:40 +0200 |
| Message-ID | <uhLxw-5QD-17@gated-at.bofh.it> |
| In reply to | #185795 |
[Multipart message — attachments visible in raw view] — view raw
You certainly didn't upset my appetite! As a Linux user since the mid-Ninties I can only say how on a daily basis I am increasingly impressed by, and grateful for, the very supportive Linux (in particular the Debian - since that is my favourite distribution) community. In particular I understand just how much all the "the good ol'boyz club of developers and ex-developers" who have contributed to the GNU/Linux eco-structure over this period have given us, and how this has changed the world for the better "miles of code" by "miles of code" as you so crudely put it. Your offensive trolling will not upset debian-users, but will no doubt please many that will regard your withdrawal from this "hell hole" to the one of your own devising as a blessing. Mushrooms grow best without light, and when fertilised with sh-t. Goodbye, Fungi$All. On 23 August 2017 at 21:47, Fungi4All <fungilife@protonmail.com> wrote: > One thing is for sure, with the good ol'boyz club of developers and > ex-developers there is > no room on this list for /users > > Which proves my theory that it is insiders of the linux community that > make it so hostile > for the rest of the world, due to their insecurity their good ol'boy club > will collapse. > At least non-free systems maintain a distance between the psycho bunch > called devs > and the public. It may be worth paying to keep them isolated. > > I wonder, without knowing so much, would a tiny little script of a daemon > record this > long password whether you typed it in or a randomizing engine produced it, > internally? > Your dear and beloved init system can always escape with it. And you can > not tell > me it is not true unless you go through a few miles of code produced each > week, > and that makes it randomly likely that you would miss it anyway thinking > it is something > else. > > I am out of here, out of this hell hole you pretend is a support group for > users. > Sorry if I upset anyone's dinner appetite. > >
[toc] | [prev] | [next] | [standalone]
| From | Brian <ad44@cityscape.co.uk> |
|---|---|
| Date | 2017-08-26 20:30 +0200 |
| Message-ID | <uiO0i-4Ek-3@gated-at.bofh.it> |
| In reply to | #185717 |
On Tue 22 Aug 2017 at 10:04:59 -0500, 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. How does this echo 'secretpassword' | sha256sum - | base64 | cut -c -30 | head -1 compare with your recommendation? -- Brian.
[toc] | [prev] | [next] | [standalone]
| From | Nicolas George <george@nsup.org> |
|---|---|
| Date | 2017-08-26 20:40 +0200 |
| Message-ID | <uiO9Y-4IU-11@gated-at.bofh.it> |
| In reply to | #185994 |
[Multipart message — attachments visible in raw view] — view raw
Le nonidi 9 fructidor, an CCXXV, Brian a écrit : > echo 'secretpassword' | echo 'secretpassword site-name' > sha256sum - | base64 Very bad: since sha256sum outputs its result in hexadecimal, it only has half the entropy it seems to have. The same thing with Perl's Digest::b64digest would be much better. Regards, -- Nicolas George
[toc] | [prev] | [next] | [standalone]
| From | Brian <ad44@cityscape.co.uk> |
|---|---|
| Date | 2017-08-26 21:10 +0200 |
| Message-ID | <uiOCZ-59y-3@gated-at.bofh.it> |
| In reply to | #185996 |
On Sat 26 Aug 2017 at 20:37:01 +0200, Nicolas George wrote: > Le nonidi 9 fructidor, an CCXXV, Brian a écrit : > > echo 'secretpassword' | > > echo 'secretpassword site-name' > > > sha256sum - | base64 > > Very bad: since sha256sum outputs its result in hexadecimal, it only has > half the entropy it seems to have. The same thing with Perl's > Digest::b64digest would be much better. Thanks. That is the sort of analysis I was after, (Although I will have to work out why hexadecimal matters). May I impose and ask how Digest::b64digest would be used in a command line string of commands? -- Brian.
[toc] | [prev] | [next] | [standalone]
| From | Brian <ad44@cityscape.co.uk> |
|---|---|
| Date | 2017-08-27 16:00 +0200 |
| Message-ID | <uj6gx-8rz-15@gated-at.bofh.it> |
| In reply to | #185998 |
On Sat 26 Aug 2017 at 20:07:34 +0100, Brian wrote: > On Sat 26 Aug 2017 at 20:37:01 +0200, Nicolas George wrote: > > > Le nonidi 9 fructidor, an CCXXV, Brian a écrit : > > > echo 'secretpassword' | > > > > echo 'secretpassword site-name' > > > > > sha256sum - | base64 > > > > Very bad: since sha256sum outputs its result in hexadecimal, it only has > > half the entropy it seems to have. The same thing with Perl's > > Digest::b64digest would be much better. > > Thanks. That is the sort of analysis I was after, (Although I will have > to work out why hexadecimal matters). > > May I impose and ask how Digest::b64digest would be used in a command > line string of commands? The libdigest-sha-perl package appears to be what I want. I've avoided any serious contact with Perl for many, many years. -- Brian.
[toc] | [prev] | [next] | [standalone]
| From | "Thomas Schmitt" <scdbackup@gmx.net> |
|---|---|
| Date | 2017-08-26 21:20 +0200 |
| Message-ID | <uiOMF-5cF-5@gated-at.bofh.it> |
| In reply to | #185994 |
Hi, Brian wrote: > echo 'secretpassword' | sha256sum - | base64 | cut -c -30 | head -1 The quality criterion is the ease or difficulty to guess the 'secretpassword' by a skilled enumerator and the fact whether your attacker knows the rest of your processing pipeline. If your secretpassword itself is enumerated late, then the attacker needs a lot of tries. If you keep the further processing secret, then the attacker will have to try several hash algorithms with each enumerated input string. Quite hard to guess would be if you replace sha256sum by an encryption program with a key which you successfully keep secret. If you stay with sha512sum: The combination of sha256sum and base64 inflates the string length before it gets cut to 30 characters length. So you actually throw away good bits which would elsewise fit into the 30 characters. It would be better to convert sha512sum output from hex to binary before applying base64 to make it printable. This brings a maximum of sha256sum bits into the 30 character result. Have a nice day :) Thomas
[toc] | [prev] | [next] | [standalone]
| From | Brian <ad44@cityscape.co.uk> |
|---|---|
| Date | 2017-08-27 16:00 +0200 |
| Message-ID | <uj6gx-8rz-11@gated-at.bofh.it> |
| In reply to | #185999 |
On Sat 26 Aug 2017 at 21:15:37 +0200, Thomas Schmitt wrote: > Hi, > > Brian wrote: > > echo 'secretpassword' | sha256sum - | base64 | cut -c -30 | head -1 > > The quality criterion is the ease or difficulty to guess the 'secretpassword' > by a skilled enumerator and the fact whether your attacker knows the rest > of your processing pipeline. > > If your secretpassword itself is enumerated late, then the attacker needs > a lot of tries. > > If you keep the further processing secret, then the attacker will have to > try several hash algorithms with each enumerated input string. Quite hard > to guess would be if you replace sha256sum by an encryption program with > a key which you successfully keep secret. Increasing difficulty in this way looks good to me. Thanks. I would most certainly hope I could keep the key secret. > If you stay with sha512sum: > The combination of sha256sum and base64 inflates the string length before > it gets cut to 30 characters length. So you actually throw away good bits > which would elsewise fit into the 30 characters. > It would be better to convert sha512sum output from hex to binary before > applying base64 to make it printable. This brings a maximum of sha256sum > bits into the 30 character result. Ok, I think I've got the idea here. xxd looks a useful utility for the conversion. -- Brian.
[toc] | [prev] | [next] | [standalone]
| From | "Thomas Schmitt" <scdbackup@gmx.net> |
|---|---|
| Date | 2017-08-27 17:10 +0200 |
| Message-ID | <uj7mh-Vo-1@gated-at.bofh.it> |
| In reply to | #186014 |
Hi, i wrote: > > Quite hard > > to guess would be if you replace sha256sum by an encryption program with > > a key which you successfully keep secret. Brian wrote: > Increasing difficulty in this way looks good to me. Thanks. I would most > certainly hope I could keep the key secret. Now you would have a human memorizable password in your mind and a strong encryption key which you hopefully can keep secret on a storage device. (The key is not strong if you can memorize it in your wetware.) The password known to the remote service would be generated by the script which combines the secrets from your brain and the storage device to one that is supposed to be very hard to crack. You would best avoid to store this remote password permanently on your computer. I.e. let the machine forget it as early as possible. Just in case you get unfriendly visitors. If your encryption key gets stolen, then your brain stored password will still impose some obstacle, which could give you some time to react. If you notice the breach, that is, and if your password is already quite hard to guess. Each password should have its own encryption key, so that one stolen and cracked password does not weaken the encryption of other passwords. If your password is not that strong, then you are probably better off with Mario Castelán Castro's approach modified by use of /dev/random instead of /dev/urandom. https://lists.debian.org/debian-user/2017/08/msg01260.html head -c 16 /dev/random | base64 | head -c 22 Reading 16 bytes of good random yields up to 128 bit of secret information. Making it printable by base64 does not change the information content. Cutting off the last two characters of the base 64 result does not reduce the secret, because any run of head -c 16 some_file | base64 yields "==" at these positions. It's a consequence of base64 converting groups of 3 bytes to groups of 4 bytes. See https://en.wikipedia.org/wiki/Base64#Output_padding This password would have to be stored entirely on a storage device because it is not human memorizable. > > If you stay with sha512sum: [Duh ... that should have been 256] > > ... > > It would be better to convert sha512sum output from hex to binary before > > applying base64 to make it printable. > Ok, I think I've got the idea here. xxd looks a useful utility for the > conversion. I had no success with looking for such a thing. But be aware that the combination of a human memorizable password and an easy to guess hashing algorithm is much weaker than the two methods mentioned above. There is few chance that your brain can hide a secret from a bunch of high end processors, if they have a final goal to which they can compare the results of their tries. That final goal would be the stolen list of usernames and password hashes and the stolen info how the hashes get generated by the service from your remote password. ------------------------------------------------------------------------- This all is theory. In practice, you can fall victim to small loopholes in the way you use or store the highly armored passwords. For real security concerns, consider to look for a password management system from people who have experience with real attacks. Have a nice day :) Thomas
[toc] | [prev] | [next] | [standalone]
| From | Curt <curty@free.fr> |
|---|---|
| Date | 2017-08-27 20:10 +0200 |
| Message-ID | <ujaat-2MR-9@gated-at.bofh.it> |
| In reply to | #186019 |
On 2017-08-27, Thomas Schmitt <scdbackup@gmx.net> wrote: > > > If your password is not that strong, then you are probably better off with > Mario Castelán Castro's approach modified by use of /dev/random instead of > /dev/urandom. > https://lists.debian.org/debian-user/2017/08/msg01260.html > > head -c 16 /dev/random | base64 | head -c 22 > So this is wrong: https://www.2uo.de/myths-about-urandom/ (Not a rhetorical question). -- "The purpose of art is to lay bare the questions that have been hidden by the answers." — James Baldwin
[toc] | [prev] | [next] | [standalone]
| From | Brian <ad44@cityscape.co.uk> |
|---|---|
| Date | 2017-08-27 20:10 +0200 |
| Message-ID | <ujaau-2MR-13@gated-at.bofh.it> |
| In reply to | #186019 |
On Sun 27 Aug 2017 at 17:08:16 +0200, Thomas Schmitt wrote: > Hi, > > i wrote: > > > Quite hard > > > to guess would be if you replace sha256sum by an encryption program with > > > a key which you successfully keep secret. > > Brian wrote: > > Increasing difficulty in this way looks good to me. Thanks. I would most > > certainly hope I could keep the key secret. > > Now you would have a human memorizable password in your mind and a strong > encryption key which you hopefully can keep secret on a storage device. > (The key is not strong if you can memorize it in your wetware.) > > The password known to the remote service would be generated by the script > which combines the secrets from your brain and the storage device to one > that is supposed to be very hard to crack. > > You would best avoid to store this remote password permanently on your > computer. I.e. let the machine forget it as early as possible. Just in case > you get unfriendly visitors. > > If your encryption key gets stolen, then your brain stored password will > still impose some obstacle, which could give you some time to react. > If you notice the breach, that is, and if your password is already quite > hard to guess. > > Each password should have its own encryption key, so that one stolen and > cracked password does not weaken the encryption of other passwords. Nothing significant to argue with here. > If your password is not that strong, then you are probably better off with > Mario Castelán Castro's approach modified by use of /dev/random instead of > /dev/urandom. > https://lists.debian.org/debian-user/2017/08/msg01260.html > > head -c 16 /dev/random | base64 | head -c 22 > > Reading 16 bytes of good random yields up to 128 bit of secret information. /dev/random versus /dev/urandom appears to be one of those Holy Wars topics. I'll stay as a bystander. > Making it printable by base64 does not change the information content. > Cutting off the last two characters of the base 64 result does not reduce > the secret, because any run of > > head -c 16 some_file | base64 > > yields "==" at these positions. It's a consequence of base64 converting > groups of 3 bytes to groups of 4 bytes. See > https://en.wikipedia.org/wiki/Base64#Output_padding Ah! That's the origin of the 3/4 I've seen in entropy calculations. > This password would have to be stored entirely on a storage device because > it is not human memorizable. Yep. > > > If you stay with sha512sum: [Duh ... that should have been 256] Thanks for the correction. > > > ... > > > It would be better to convert sha512sum output from hex to binary before > > > applying base64 to make it printable. > > > Ok, I think I've got the idea here. xxd looks a useful utility for the > > conversion. > > I had no success with looking for such a thing. It is in stretch, buster and sid. > But be aware that the combination of a human memorizable password and > an easy to guess hashing algorithm is much weaker than the two methods > mentioned above. > There is few chance that your brain can hide a secret from a bunch of > high end processors, if they have a final goal to which they can compare > the results of their tries. > > That final goal would be the stolen list of usernames and password hashes > and the stolen info how the hashes get generated by the service from your > remote password. > > ------------------------------------------------------------------------- > > This all is theory. In practice, you can fall victim to small loopholes > in the way you use or store the highly armored passwords. > > For real security concerns, consider to look for a password management > system from people who have experience with real attacks. I am trying to avoid password management schemes (wallets etc). Also, I am still firm in my view that passwords for online logins can be very safe and memorable. It is the leaking of databases and offline cracking which has my attention now (but I am not losing any sleep over it). To some extent, I'm with David Wright https://lists.debian.org/debian-user/2017/08/msg01417.html I do not have to run faster than the bear, just faster than anyone else. -- Brian.
[toc] | [prev] | [next] | [standalone]
| From | "Thomas Schmitt" <scdbackup@gmx.net> |
|---|---|
| Date | 2017-08-27 21:10 +0200 |
| Message-ID | <ujb6x-3q9-1@gated-at.bofh.it> |
| In reply to | #186030 |
Hi, Curt wrote: > So this is wrong: > https://www.2uo.de/myths-about-urandom/ Dunno. I took my info from the man page. This article is, at least at its beginnings, very affirmative and fewly equipped with supporting facts. Mainly "Believe Me !". The author is a proselyte of urandom, as he confesses openly. Of course, if you are lucky, urandom gives you 8 bit entropy per byte read. But as all diagrams in the article say: Entropy can be lower and urandom will still hand out the bytes. The whole article is about why this shall not be of concern. Why is the potentially missing stuff considered to be entropy then ? Verifying the statements about the way how random and urandom correspond in the Linux kernel would last a few weeks. Why was it changed so often ? Further i'd need to wrap my head around the topic whether this really yields the properties claimed by the author. Compared to that, what is the penalty if i do not join the urandom church ? I might be doomed to wait a few seconds before my password is generated. Maybe a mass generator of random numbers, which relies on /dev/random against the advise of the man page, will have to wait too. Serves him right. If i get bored, i can speed it up by doing things on mouse and keyboard. But it's not necessary for me. I just read 5 times 16 bytes. No waiting, no lightning strike from heaven. Am i stupid to go any risk and reject the offer of the kernel to test my random bytes before i get them ? Just because people with undisclosed interests tell me ? The term for this is "social engineering". Have a nice day :) Thomas
[toc] | [prev] | [next] | [standalone]
| From | Andy Smith <andy@strugglers.net> |
|---|---|
| Date | 2017-08-28 00:00 +0200 |
| Message-ID | <ujdL3-54l-3@gated-at.bofh.it> |
| In reply to | #186033 |
Hello, On Sun, Aug 27, 2017 at 09:05:41PM +0200, Thomas Schmitt wrote: > Curt wrote: > > So this is wrong: > > https://www.2uo.de/myths-about-urandom/ > > Dunno. I took my info from the man page. The article at 2uo.de is correct. The relevant Linux man pages were recently updated to clarify that once seeded, /dev/urandom is sufficient for any use and that /dev/random is a legacy interface for callers that may require it during early boot before the pool is initialised. The non-legacy interface for such callers is proper use of getrandom() which will block until the pool is initialised. https://bugzilla.kernel.org/show_bug.cgi?id=71211 Cheers, Andy -- https://bitfolk.com/ -- No-nonsense VPS hosting
[toc] | [prev] | [next] | [standalone]
| From | "Thomas Schmitt" <scdbackup@gmx.net> |
|---|---|
| Date | 2017-08-28 09:40 +0200 |
| Message-ID | <ujmOl-2GD-1@gated-at.bofh.it> |
| In reply to | #186045 |
Hi, Andy Smith wrote: > The relevant Linux man pages were > recently updated to clarify that once seeded, /dev/urandom is > sufficient for any use > [...] > https://bugzilla.kernel.org/show_bug.cgi?id=71211 Maybe there are stronger reasons to abandon /dev/random. But that thread states as only other motivation besides "It's safe, stupid" this observation of Laurent Georget: "[...] as long as you use /dev/urandom for cryptographic purposes only, you should be ok, because you will never need *a lot* of random data anyway in any sensible program." But this also implies that /dev/random will not block because there is always more entropy in the pool than can reasonably be drained. Plausible under normal circumstances, but also easy to sabotage if you have an account on that machine or can get people to running a program of yours. > and that /dev/random is a legacy interface I can read this only from half of the new man pages which are referred in the thread. http://man7.org/linux/man-pages/man7/random.7.html does not call it legacy but still gives it a job: "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 device or employing getrandom(2) with the GRND_RANDOM flag." We are discussing exactly this: Long-term key generation. In http://man7.org/linux/man-pages/man4/random.4.html it is indeed labeled "legacy", but still with a job: "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. Again, this is the situation we discuss: Non-expert trust and enough time to wait for the coward's random numbers. So yes, the experts tend towards deeming obsolete the extra entropy test and the consequential blocking. But i myself have two use cases for (pseudo-)random numbers: - Small but hard secrets which i need for security purposes. - 3 times 25 GB of random stream to surely shake up the bits on a BD-RE medium which previously contained embarassing data. The first purpose is still assigned to /dev/random, according to the new man pages (at least if one is committed by one's first name to be a disbeliever). The second one is not a job for /dev/urandom either. It does not even need a strong seed, because the data do not have to be secret. In fact they are intended to be readable instead of the original data which i want to destroy. Have a nice day :) Thomas
[toc] | [prev] | [next] | [standalone]
| From | Curt <curty@free.fr> |
|---|---|
| Date | 2017-08-28 11:40 +0200 |
| Message-ID | <ujoGt-3Tj-5@gated-at.bofh.it> |
| In reply to | #186061 |
On 2017-08-28, Thomas Schmitt <scdbackup@gmx.net> wrote: > > But i myself have two use cases for (pseudo-)random numbers: > - Small but hard secrets which i need for security purposes. > - 3 times 25 GB of random stream to surely shake up the bits on a BD-RE > medium which previously contained embarassing data. Here's a fresh (20 July of this year) view by Theodore Ts'o: https://lkml.org/lkml/2017/7/20/993 Practically no one uses /dev/random. It's essentially a deprecated interface; the primary interfaces that have been recommended for well over a decade is /dev/urandom, and now, getrandom(2). We only need 384 bits of randomness every 5 minutes to reseed the CRNG, and that's plenty even given the very conservative entropy estimation currently being used. > The first purpose is still assigned to /dev/random, according to the > new man pages (at least if one is committed by one's first name to be > a disbeliever). > > The second one is not a job for /dev/urandom either. It does not even > need a strong seed, because the data do not have to be secret. In fact > they are intended to be readable instead of the original data which i > want to destroy. > > > Have a nice day :) > > Thomas > > -- "The purpose of art is to lay bare the questions that have been hidden by the answers." — James Baldwin
[toc] | [prev] | [next] | [standalone]
| From | "Thomas Schmitt" <scdbackup@gmx.net> |
|---|---|
| Date | 2017-08-28 12:10 +0200 |
| Message-ID | <ujp9y-4iA-75@gated-at.bofh.it> |
| In reply to | #186068 |
Hi, Curt wrote: > Here's a fresh (20 July of this year) view by Theodore Ts'o: > https://lkml.org/lkml/2017/7/20/993 An opinion of substantial weight, indeed. Nevertheless it would be more interesting to learn the reason why Linux did not simply make /dev/random behave like /dev/urandom long ago. And again, the argumentation of Theodore is that there is always enough entropy at hand. I understand that in this situation there is no difference between /dev/random and /dev/urandom. The difference appears only when the assumption of wealth is not fulfilled. Also one should note that Theodore uses the argument of a deprecated /dev/random as answer to a side note of his discussion partner, not as general statement. The main point of Stephan Müller is that the system could collect more entropy. The answer of Theodore is that it already collects more than enough and does not have to care about being drained by /dev/random because that draining is deprecated. So one would have to ask him, whether this opinion does not hold under all circumstances or what else blocks him from just making both mechanisms equal. (Normally i would dare to approach him. But i guess he is already annoyed by the topic and man page reading cowards like me.) Have a nice day :) Thomas
[toc] | [prev] | [next] | [standalone]
| From | Andy Smith <andy@strugglers.net> |
|---|---|
| Date | 2017-08-28 13:50 +0200 |
| Message-ID | <ujqIh-55M-9@gated-at.bofh.it> |
| In reply to | #186071 |
Hello, On Mon, Aug 28, 2017 at 12:04:51PM +0200, Thomas Schmitt wrote: > And again, the argumentation of Theodore is that there is always enough > entropy at hand. I understand that in this situation there is no difference > between /dev/random and /dev/urandom. > The difference appears only when the assumption of wealth is not fulfilled. It cannot be "not fulfilled" except in the very early boot sequence. The ChaCha20 PRNG in Linux only needs about 256 bits of entropy to then generate as much as you like from that point forwards. Some data is saved on shutdown to /var/lib/urandom/random-seed and very early on is fed back in to seed the PRNG. It's only in the small window between boot and feeding in that data where the PRNG might not have enough entropy. Cheers, Andy -- https://bitfolk.com/ -- No-nonsense VPS hosting
[toc] | [prev] | [next] | [standalone]
| From | "Thomas Schmitt" <scdbackup@gmx.net> |
|---|---|
| Date | 2017-08-28 15:20 +0200 |
| Message-ID | <ujs7p-62E-25@gated-at.bofh.it> |
| In reply to | #186075 |
Hi, i wrote: > > I understand that in this situation there is no difference > > between /dev/random and /dev/urandom. > > The difference appears only when the assumption of wealth is not fulfilled. Andy Smith wrote: > It cannot be "not fulfilled" except in the very early boot sequence. Well, then there remains few difference to discuss. Have a nice day :) Thomas
[toc] | [prev] | [next] | [standalone]
| From | Zenaan Harkness <zenaan@freedbms.net> |
|---|---|
| Date | 2017-08-29 04:40 +0200 |
| Message-ID | <ujEBz-5eu-7@gated-at.bofh.it> |
| In reply to | #186071 |
On Mon, Aug 28, 2017 at 12:04:51PM +0200, Thomas Schmitt wrote: > Hi, > > Curt wrote: > > Here's a fresh (20 July of this year) view by Theodore Ts'o: > > https://lkml.org/lkml/2017/7/20/993 > > An opinion of substantial weight, indeed. > > Nevertheless it would be more interesting to learn the reason why > Linux did not simply make /dev/random behave like /dev/urandom long > ago. Because that would obfuscate the difference in nature between the two. AIUI /dev/random is simply the input feed to /dev/urandom and the fact /dev/random is world readable is now an historic artifact, but also quite possibly still useful in certain, very specific/ narrow, circumstances. The main problem is folks not knowing which one to use. There are no shortcuts in the world of secure algorithms - that is, if you want security/ secure software, you -must- know the nature of your inputs, and /dev/random vs /dev/urandom provides this (essential) distinction. > And again, the argumentation of Theodore is that there is always > enough entropy at hand. Unclear wording. I would say Ted Ts'o is making sure that /dev/urandom delivers on its API promise/ expectation, which is really important, and great to know that Ts'o is on this! > I understand that in this situation there is no difference > between /dev/random and /dev/urandom. No. Here's Ted Ts'o (from above link): "I don't really care about /dev/random performance. What's is **far** more important is that the entropy estimations behave correctly, across all of Linux's architectures, while the kernel is going through startup, before CRNG is declared initialized." /dev/random performance/ api promise is "deliver truly random bits, even if this is slow to do so, since we'll be using these bits in absolutely critical places, such as seeding /dev/urandom" > The difference appears only when the assumption of wealth is not > fulfilled. ... parse fail > Also one should note that Theodore uses the argument of a > deprecated /dev/random as answer to a side note of his discussion > partner, not as general statement. But see his general statement above, which is almost the same thing as "if you want performance, consider /dev/random deprecated", i.e. he said "I don't really care about /dev/random performance." > The main point of Stephan Müller is that the system could collect > more entropy. The answer of Theodore is that it already collects > more than enough and does not have to care about being drained by > /dev/random because that draining is deprecated. Exactly - don't use /dev/random, use /dev/urandom instead, as designed, and as has been made publicly clear for ~10 years now. > So one would have to ask him, whether this opinion does not hold > under all circumstances or what else blocks him from just making > both mechanisms equal. Hopefully the above explains the principles involved. If for any reason you want high speed "hardware/ physical random" number stream, then you will have to go for a HRNG, and as Ted points out in the above link, there are many drivers for these in the kernel already - in other words, EVERY use case is abundantly provided for by the Linux kernel. Causing /dev/random to be the same as /dev/urandom would only make sense if the current /dev/random implementation were made completely private i.e. "internal to the kernel and not accessible by userspace" - then /dev/random could simply be a symlink to /dev/urandom - but there are disadvantages to doing this, not the least of which would be certain very specific yet limited use cases for which the existing /dev/random is an essential dependency! > (Normally i would dare to approach him. But i guess he is already > annoyed by the topic and man page reading cowards like me.) Confront the man page! And Wikipedia too ... Then write, your Haiku :) > Have a nice day :) You too, and a Haiku new.
[toc] | [prev] | [next] | [standalone]
Page 3 of 6 — ← Prev page 1 2 [3] 4 5 6 Next page →
Back to top | Article view | linux.debian.user
csiph-web