Protecting your private key - passphrase

[Stefan Claas]

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 at 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.
>
>