Mailing List Archive

I will release tomorrow, if time permits, the GUI based versions,
on GitHUb, created with the help of the fyne toolkit.

https://ibb.co/rxYcXvq

Regards
Stefan

On Thu, Dec 10, 2020 at 4:11 PM Stefan Claas
<spam.trap.mailing.lists@gmail.com> wrote:
>
> Hi all,
>
> while playing with hashcat, diceware passphrases and entropy
> checkers I thought why not try to create a little program that
> you can input your passphrase and it gets converted to a random
> chars string (40 chars), based either on sha256+base91 or
> ripemd-160 output.
>
> The idea here is to use phrases which makes no sense but
> can easily been remembered and then get converted so that
> you always have IMHO good random input for GnuPG.
>
> For that task I created two little Golang programs which
> asks the user to input a phrase that makes no sense and
> while the user is typing in his passphrase bullets are
> displayed, like in pinentry, and then the random 40 chars
> get copied to the clipboard, so that users can paste
> the passphrase into GnuPG.
>
> In order that this works under Linux/Unix too you need
> to install xclip or xsel and don't forget to clear the
> clipboard after usage.
>
> Example #1
>
> Input: Alice+eats&red+stones
>
> Output program #1: 8rW3<HnS!UCQ)83@(|t{QRR<KDhJ$`]&k(b;yJjE
> Output program #2 a6a549d45f1e5c3fabfba37003541c3fa7f26d13
>
> Exampl #2
>
> Input: grüne-Füchse-fliegen#weich (= green-foxes-flying#soft)
>
> Output program #1: $j{hDH!5m4O[9JcPVBbHLlM^]R]RJ%yJoPr:IxAD
> Output program #2: 89216958ceed145dd03a6d23afa7ae93b27457e9
>
> Example #3
>
> Input mixed languages question: has*Bob*deutsche*ÄÖÜs?
>
> Output program #1 fq7Mr469cU#d%uOIX?zG?:^@^y[n152_OUvp8|gB
> Output program #2 9f770781c96d72b9974421ea72b523c019714a1f
>
> Hope you like the idea and maybe others come up with better
> solutions.
>
> Attached are the two programs as Golang source code.
>
> Please note I am only noodling around with Golang and I am
> not a programmer!
>
> Regards
> Stefan
>
> Resources:
>
> https://www.gnupg.org/gph/en/manual/c481.html
> https://www.armourinfosec.com/password-cracking-with-hashcat/
> http://passwordstrengthcalculator.com/index.php
> http://rumkin.com/tools/password/passchk.php

_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

On Sonntag, 13. Dezember 2020 22:20:04 CET Stefan Claas via Gnupg-users wrote:
> I will release tomorrow, if time permits, the GUI based versions,
> on GitHUb, created with the help of the fyne toolkit.

I'm sorry, but in my opinion this is snake oil.

If you think that you can increase entropy ("randomness") by hashing a
passphrase a user came up with, then you should really take a basic course on
information theory.

If the user comes up with an easy-to-guess passphrase and runs it through your
program, then s:he will get a hashed easy-to-guess passphrase with a little
bit security-by-obscurity sugar on top. But this doesn't add any real
security. It only adds complexity (which often means less security; I mean you
are putting the passphrase on the clipboard from where it can be grabbed by
any other application) because now one needs to use two programs to decrypt
something. First your program to calculate the actual passphrase to feed into
gpg and then gpg to perform the actual decryption.

Why do you think you need "good random input for GnuPG"? GnuPG does have a
state-of-the-art key derivation function.

If people want to generate a secure random passphrase for gpg, then they
should use a secure password generator.

Regards,
Ingo

On Sun, Dec 13, 2020 at 10:49 PM Ingo Klöcker <kloecker@kde.org> wrote:
>
> On Sonntag, 13. Dezember 2020 22:20:04 CET Stefan Claas via Gnupg-users wrote:
> > I will release tomorrow, if time permits, the GUI based versions,
> > on GitHUb, created with the help of the fyne toolkit.
>
> I'm sorry, but in my opinion this is snake oil.
>
> If you think that you can increase entropy ("randomness") by hashing a
> passphrase a user came up with, then you should really take a basic course on
> information theory.

I guess you have not read my initial posting ... otherwise you would think
different and would not say so ...

The program is not only for GnuPG usage and if you refer to bcrypt and the likes
you are aware that due to salting you always get a different hash result, thus
you would have problems to input your passphrase into web forms etc. with such
standalone programs.

Regarding entropy, like I said, I suggest you read my intitial posting, try out
the programs from my initial posting and then check the entropy of the output.

BTW. Nobody is forced to use my programs and real cryptographers, I have shown
my humble approach, liked it also and they are aware that the software
which receives
such input from my programs are doing additional salting and/or stretching.

Regards
Stefan

_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

On Sun, 2020-12-13 at 22:20 +0100, Stefan Claas via Gnupg-users wrote:
> I will release tomorrow, if time permits, the GUI based versions,
> on GitHUb, created with the help of the fyne toolkit.
>
> https://ibb.co/rxYcXvq

This is snake oil. Please do not use it. Stefan's claims are not
rooted in mathematics. Ingo's criticism is bang-on accurate.

> > checkers I thought why not try to create a little program that
> > you can input your passphrase and it gets converted to a random
> > chars string (40 chars), based either on sha256+base91 or
> > ripemd-160 output.

Digest algorithms do not produce random output.

They do not even produce cryptographically secure pseudorandom output.

A digest algorithm is not a CSPRNG. The construction Stefan is using
here is known to fail many important tests of a CSPRNG.

> > The idea here is to use phrases which makes no sense but
> > can easily been remembered and then get converted so that
> > you always have IMHO good random input for GnuPG.

Don't do this. The entire step is unnecessary and adds literally zero
security to GnuPG.

> > Please note I am only noodling around with Golang and I am
> > not a programmer!

Nor is he a cryptographic engineer.

Please do not use this, or if you do, use it at your own risk.



_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

> I guess you have not read my initial posting ... otherwise you would
> think different and would not say so ...

Stefan, I read your original posting and I completely concur with Ingo.

> The program is not only for GnuPG usage

Please explain to me who might benefit from this.

Seriously. If people want CSPRNG output, this is not CSPRNG output.
If people want a key derivation function, this is a *really bad* key
derivation function: you should've used PBKDF2 or Argon2.

What's your use case? Who might benefit?

> try out
> the programs from my initial posting and then check the entropy of
> the output.

No, Stefan, that's not how it works. It is flat impossible to, by any
deterministic means, increase the entropy of a function's output over
the function of the input. Deterministic functions only ever reduce
entropy: there exist no deterministic functions that increase it.

Imagine I have a 'Gender' field on a driver's license, and it can take
three values: 'Male', 'Female', and 'Nonbinary'. There are three
states there, meaning there are (log-2 of 3 = ) 1.58 shannons of
entropy present. If I feed one of those three fields into SHA256 and
get 'fceea935c627080824b44df8f222631d39e6f705b307be1fc80f36769ade230c'
I'm not increasing the entropy, I'm only spreading 1.58 shannons out
over a larger region of text.

"But if I feed this into an entropy estimator it comes back high!"
Yes, because entropy estimators are like any other tool: they need to
be used with insight. If the entropy estimator knew the universe of
possibilities was only 'Male', 'Female', and 'Nonbinary', and the
algorithm used was SHA256, it could then say "oh yeah, 1.58 shannons of
entropy, boss."

But when you naïvely run an entropy estimator and *deny it information
about the possibility set or algorithms used*, you're violating
Kerckhoff's Principle and of course you're going to get wildly
incorrect results.

> BTW. Nobody is forced to use my programs and real cryptographers, I
> have shown
> my humble approach, liked it also...

Then I invite them to come here and explain to me where I'm wrong.

So far in the last week you've advocated Bitcoin scams on this list and
hyped your own snake oil.

In just the last week.

Please stop.

On Mon, Dec 14, 2020 at 5:35 AM Robert J. Hansen <rjh@sixdemonbag.org> wrote:
>
> > I guess you have not read my initial posting ... otherwise you would
> > think different and would not say so ...
>
> Stefan, I read your original posting and I completely concur with Ingo.
>
> > The program is not only for GnuPG usage
>
> Please explain to me who might benefit from this.

People who have difficulties to create a long passphrase and
remembering those, when using differrent ones for different use cases.
>
> Seriously. If people want CSPRNG output, this is not CSPRNG output.
> If people want a key derivation function, this is a *really bad* key
> derivation function: you should've used PBKDF2 or Argon2.

I recently posted here, in the Governikus thread, that I used PBKDF2
along with NIST guidelines to create a secure key for a GnuPG key of
mine, for UID purposes ...

Had I used PBKDF2 for my litle program people would have a key which
they need to store somewhere, while my program does not store keys,
instead one types in his no sense making passphrase, which then gets
converted.

> What's your use case? Who might benefit?

We all have probably read that servers often gets hacked or otherwise
compromised and crackers and law enforcement are using software like
hashcat or John the Ripper etc. to crack peoples passwords. Lists of
used passwords are available on the net. Lists of MD5 and SHA1 hashes
etc. as well. We are also aware of brute-force or dictionary attacks
etc.

One would think that nowadays passwords with all online services are
properly salted and hashed, in order to protect peoples passphrases,
but why are then password crackers, used by crackers and law
enforcemnet are often successful? We could probably agree that then a
weak password was used and no salt, so that the stored hashes in
databases from online services makes it easier to crack passwords. Or
do we have NIST/BSI certified consumer online services, when it comes
to security ...

With that said would you say that when one inputs his password into an
online form that it is equally secure than if one would use my program
and use an easy to remember nonsense phrase which gets convert?

Regards
Stefan

_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Robert,

you are one hundred percent correct that the output of my programs are *not*
random and that they do not generate random output like a CSPRNG does.

So, once again, I appologize for my wrong wording and should had better used
garbled looking output, compared to a regular users passphrase input.

With all fairness you should also tell people that if they use a
CSPRNG for password generation and the password is long or is a
passphrase that then again they have to store the key because it is
unlikely that they can remember such passwords/passphrases. My humble
approach does *not* store keys and I also said that users need to
clear their clipboard after usage.

Regards
Stefan

On Mon, Dec 14, 2020 at 5:15 AM Robert J. Hansen <rjh@sixdemonbag.org> wrote:
>
> On Sun, 2020-12-13 at 22:20 +0100, Stefan Claas via Gnupg-users wrote:
> > I will release tomorrow, if time permits, the GUI based versions,
> > on GitHUb, created with the help of the fyne toolkit.
> >
> > https://ibb.co/rxYcXvq
>
> This is snake oil. Please do not use it. Stefan's claims are not
> rooted in mathematics. Ingo's criticism is bang-on accurate.
>
> > > checkers I thought why not try to create a little program that
> > > you can input your passphrase and it gets converted to a random
> > > chars string (40 chars), based either on sha256+base91 or
> > > ripemd-160 output.
>
> Digest algorithms do not produce random output.
>
> They do not even produce cryptographically secure pseudorandom output.
>
> A digest algorithm is not a CSPRNG. The construction Stefan is using
> here is known to fail many important tests of a CSPRNG.
>
> > > The idea here is to use phrases which makes no sense but
> > > can easily been remembered and then get converted so that
> > > you always have IMHO good random input for GnuPG.
>
> Don't do this. The entire step is unnecessary and adds literally zero
> security to GnuPG.
>
> > > Please note I am only noodling around with Golang and I am
> > > not a programmer!
>
> Nor is he a cryptographic engineer.
>
> Please do not use this, or if you do, use it at your own risk.
>
>

_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Hi!

Let me also add that the private key protection mechanism of OpenPGP
does not work like we would do it these days. Thus my suggestion has
always been: If you need to convey a private key over a public channel
do not rely on the passphrase protection [1] but wrap the backuped key
in a proper OpenPGP encryption message (public key or symmetric with a
good and different passphrase) for transport. For backup purposes the
passphrase protection system is okay.


Shalom-Salam,

Werner


[1] Even if the passphrase is strong enough to be published in the NYT.

--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.

> People who have difficulties to create a long passphrase and
> remembering those, when using differrent ones for different use cases.

Then why aren't you using PBKDF2 or Argon2?

If you're writing a key derivation app -- use a key derivation function.

> Had I used PBKDF2 for my litle program people would have a key which
> they need to store somewhere, while my program does not store keys,

What are you talking about? Here's the signature for PBKDF2 in Golang's
crypto library:

func Key(password []byte,
salt []byte,
iterations int,
keyLength int,
hashFunction func() hash.Hash) []byte

If you need to generate the same key again later, just feed in the same
inputs. You have nothing to keep track of so long as you remember the
passphrase.

> With that said would you say that when one inputs his password into an
> online form that it is equally secure than if one would use my program
> and use an easy to remember nonsense phrase which gets convert?

I'd advise people to use Firefox's password safe and ability to generate
pseudorandom keys for each site you visit. KeePassX is a good
open-source alternative for people who want to keep passwords on their
desktop machine instead of encrypted in the cloud.

> you are one hundred percent correct that the output of my programs are *not*
> random and that they do not generate random output like a CSPRNG does.

I'm not going to discuss this with you further. It's clear you don't
know what you're doing, and I trust that's been made clear to the
mailing list.

On 2020-12-14 12:26, Robert J. Hansen via Gnupg-users wrote:
>> People who have difficulties to create a long passphrase and
>> remembering those, when using differrent ones for different use cases.
>
> Then why aren't you using PBKDF2 or Argon2?
>
> If you're writing a key derivation app -- use a key derivation function.
>
>> Had I used PBKDF2 for my litle program people would have a key which
>> they need to store somewhere, while my program does not store keys,
>
> What are you talking about? Here's the signature for PBKDF2 in
> Golang's crypto library:
>
> func Key(password []byte,
> salt []byte,
> iterations int,
> keyLength int,
> hashFunction func() hash.Hash) []byte
>
> If you need to generate the same key again later, just feed in the
> same inputs. You have nothing to keep track of so long as you
> remember the passphrase.

I said that my program does *not* store any *keys* and the *required*
parameters (which can be set manually and individually, in order
to use the same passphrase again) ...

Regards
Stefan

_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

On Thu, Dec 10, 2020 at 4:11 PM Stefan Claas
<spam.trap.mailing.lists@gmail.com> wrote:
>
> Hi all,
>
> while playing with hashcat, diceware passphrases and entropy
> checkers I thought why not try to create a little program that
> you can input your passphrase and it gets converted to a random
> chars string (40 chars), based either on sha256+base91 or
> ripemd-160 output.
>
> The idea here is to use phrases which makes no sense but
> can easily been remembered and then get converted so that
> you always have IMHO good random input for GnuPG.
>
> For that task I created two little Golang programs which
> asks the user to input a phrase that makes no sense and
> while the user is typing in his passphrase bullets are
> displayed, like in pinentry, and then the random 40 chars
> get copied to the clipboard, so that users can paste
> the passphrase into GnuPG.
>
> In order that this works under Linux/Unix too you need
> to install xclip or xsel and don't forget to clear the
> clipboard after usage.
>
> Example #1
>
> Input: Alice+eats&red+stones
>
> Output program #1: 8rW3<HnS!UCQ)83@(|t{QRR<KDhJ$`]&k(b;yJjE
> Output program #2 a6a549d45f1e5c3fabfba37003541c3fa7f26d13
>
> Exampl #2
>
> Input: grüne-Füchse-fliegen#weich (= green-foxes-flying#soft)
>
> Output program #1: $j{hDH!5m4O[9JcPVBbHLlM^]R]RJ%yJoPr:IxAD
> Output program #2: 89216958ceed145dd03a6d23afa7ae93b27457e9
>
> Example #3
>
> Input mixed languages question: has*Bob*deutsche*ÄÖÜs?
>
> Output program #1 fq7Mr469cU#d%uOIX?zG?:^@^y[n152_OUvp8|gB
> Output program #2 9f770781c96d72b9974421ea72b523c019714a1f
>
> Hope you like the idea and maybe others come up with better
> solutions.

Did some calculations with these simple example mini-passphrases above
compared to diceware sixword word passphrases and decided to rename
my programs to passphrase hasher, so that people do not follow these
simple examples. Also added an clipboard overwrite button.

https://ibb.co/VYkDN20

Regards
Stefan

_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

On Tue, Dec 15, 2020 at 5:04 PM Stefan Claas
<spam.trap.mailing.lists@gmail.com> wrote:

> Did some calculations with these simple example mini-passphrases above
> compared to diceware sixword word passphrases and decided to rename
> my programs to passphrase hasher, so that people do not follow these
> simple examples. Also added an clipboard overwrite button.
>
> https://ibb.co/VYkDN20

Decided, as little exercise, to use Argon2id, with fixed parameters,
which users can change to their liking.

https://github.com/sac001/Argon2id/

Merry Christmas to all of you!

Regards
Stefan

_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users