Entropy in ascii-armored output?
dshaw at jabberwocky.com
Sat Jul 30 02:56:58 CEST 2005
On Fri, Jul 29, 2005 at 03:59:16PM -0700, Chris De Young wrote:
> Some people have started to suggest that actually writing down
> passwords, if they're kept in a secure place, might not be a bad
> idea; the rationale is that passwords which can be considered "good"
> are reaching the point of being un-memorizable.
> Assuming for the moment that this is the case (whether it really is
> or not isn't clear, I think), it seems that copying some arbitrary
> chunk out of the middle of some GPG encryption output (with -a,
> e.g. "QhRuM+W4xC9qnPvn") might be a good source of password
> It's random-looking to the untrained eye, but how random is it
> really? It occurred to me that the ascii-armoring process might
> introduce weaknesses that aren't obvious, but I don't follow the
> guts of the process well enough to be sure.
ASCII armor is just a base64 transformation of some data, so if the
original data was random, then the armor is as well. If you do:
cat /good/random/source | gpg --enarmor
you'll get armored random data.
However, it takes more armor to get to the same amount of random data,
due to the expansion that base64 does. For example, 128 digits of
random data takes 171 armored digits (I'm not counting padding and
checksum for now). This means that if you take 10 digits of armor,
you're not getting 10 digits of randomness. Combine that with the
knowledge of the valid armor characters (a-z, A-Z, +, and /), and you
can set yourself up with a passphrase that is weaker than you think it
All that said, the bottom line is that if the source is random, the
armor is too.
More information about the Gnupg-users