Hello all,

A few questions from a PGP newbie.

I'm curious why GnuPG (and presumably PGP) uses only a passphrase for
traditional symmetric encryption. As I understand it, this means that you ha
ve
to be very careful to choose a passphrase with enough entropy, and then the
passphrase has to be hashed to generate a key. Why not do things the same wa
y
as PGP does asymmetric encryption? Use /dev/random or another good random
source to directly generate a private key of the right length, then protect
that key with a passphrase. This would mean rock-solid encryption as long as
your private key is not compromised, with a second tier of protection via th
e
passphrase. I can't find any way to tell GnuPG to do this :-(

My wish here is to encrypt off-site backups in a way that is lastingly secur
e.
I trust my own machine not to get hacked (all ports closed), others not so
much. I could just use public key encryption, but from the research I've bee
n
doing on sci.crypt, it sounds like symmetric encryption is generally regarde
d
as faster and tighter. (is assymetric encryption just as good if no one
actually knows the "public" key?)

On a related note, I'm wondering whether the use of 160-bit SHA-1 hashing
effectively truncates the power of a symmetric cipher. If I use cipher-algo
AES256 with a SHA-1 hashed passphrase, am I really only getting 160 bits of
effective encryption?

Thanks!
Suzanne

--
tril@igs.net - http://www.igs.net/~tril/
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"If you want a vision of the future, it is a wireless broadband network
feeding requests for foreign money-laundering assistance into a human
temporal lobe, forever. With banner ads."   -- John M. Ford
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

[ Post a follow-up to this message ]

Suzanne Skinner wrote:
>
> My wish here is to encrypt off-site backups in a way that is lastingly sec
ure.
> I trust my own machine not to get hacked (all ports closed), others not so
> much. I could just use public key encryption, but from the research I've b
een
> doing on sci.crypt, it sounds like symmetric encryption is generally regar
ded
> as faster and tighter. (is asymetric encryption just as good if no one
> actually knows the "public" key?)

Public key encryption is great for off-site backups. I use it all the
time. The public key crypto is only used to hide the random symmetric
encryption and authentication keys. Note: I have no idea how to use PGP.

> On a related note, I'm wondering whether the use of 160-bit SHA-1 hashing
> effectively truncates the power of a symmetric cipher. If I use cipher-alg
o
> AES256 with a SHA-1 hashed passphrase, am I really only getting 160 bits o
f
> effective encryption?

If the AES key is SHA-1("A" || passphrase) || 96-bits-of-SHA-1("B" ||
passphrase), and you've selected the passphrase uniformly from among
2**256 different passphrases, you've got practically 256 bits of entropy
in the AES key.

--Mike Amling

[ Post a follow-up to this message ]

Hi,

"Suzanne Skinner" <tril@igs.net> wrote in message
news:slrncjiabb.b8c.tril@miranda.igs.net...
> Hello all,
>
> A few questions from a PGP newbie.
>
> I'm curious why GnuPG (and presumably PGP) uses only a passphrase for
> traditional symmetric encryption. As I understand it, this means that you
have
> to be very careful to choose a passphrase with enough entropy, and then
the
> passphrase has to be hashed to generate a key. Why not do things the same
way
> as PGP does asymmetric encryption? Use /dev/random or another good random
> source to directly generate a private key of the right length, then
protect
> that key with a passphrase. This would mean rock-solid encryption as long
as
> your private key is not compromised, with a second tier of protection via
the
> passphrase. I can't find any way to tell GnuPG to do this :-(

Well, I think I understand what your saying.  PGP/GPG does generate a random
symmetric session (only used for that message/file) key, and your passphrase
is used to protect it.  PGP asks you to move your mouse around to help
generate random data.  As long as the random data is good, then it should be
a really strong key, and would be 256 bits for Twofish for example.  That
strong randomly generated key is used to protect your data, and then your
passphrase derived key encrypts that strong 256 bit key.  So you still need
a good passphrase.


> My wish here is to encrypt off-site backups in a way that is lastingly
secure.
> I trust my own machine not to get hacked (all ports closed), others not so
> much. I could just use public key encryption, but from the research I've
been
> doing on sci.crypt, it sounds like symmetric encryption is generally
regarded
> as faster and tighter. (is assymetric encryption just as good if no one
> actually knows the "public" key?)

Well, even if someone got a hold of your private key, they would still need
to know your passphrase.  So if you have users that probably wont come up
with good passphrases, maybe you should use public key encryption, since the
only thing their bad passphrase is protecting is the private key on their
hard drive, and not a session key that is included with the file, which
would  be offsite).You should try to get them to use better passphrases (see
Diceware @ http://world.std.com/~reinhold/diceware.html ). But even if they
aren't using really secure passphrases, you can always do a better job of
securing the users machines. Public key encryption is slower, but it doesn't
really matter, because your message isn't encrypted with the private key.
It is still encrypted using a symmetric key, its only the symmetric session
key that gets encrypted by the public key.  This all really depends on the
type of data your trying to protect.  You have to think of who would try to
get a hold of this data.  Then you basically make it secure from them.  Even
if you have a really good passphrase with full entropy, there can still be a
keylogger on the computer.


> On a related note, I'm wondering whether the use of 160-bit SHA-1 hashing
> effectively truncates the power of a symmetric cipher. If I use
cipher-algo
> AES256 with a SHA-1 hashed passphrase, am I really only getting 160 bits
of
> effective encryption?

No, The passphrase is combined with a salt (a random value to help deter
dictionary attacks) and it is hashed. The salt and the passphrase is
repeatedly hashed until it has enough data to make a full key.  So for 256
Twofish, it would have to hash it once (160 bits), then again, but only the
second time it would only use the first (most significant) 96 bits of the
second hashing.(160 + 96 bits - 256 bit key)

This is explained in detail in RFC 2440
http://www.faqs.org/rfcs/rfc2440.html
Check section 3.6. String-to-key (S2K) specifiers

There is a lot to know when it comes to PGP and Cryptography in general, so
I am positive I haven't answered all your question. Hopefully I helped you
though, and if you still don't understand something, just write back.  Ill
check back tomorrow.  I would suggest reading the GNU Privacy Handbook (
http://www.gnupg.org/gph/en/manual.html ) and the intro to crypto PDF that
comes with PGP (probably free online somewhere). Also, you might want to
purchase Secrets and Lies by Bruce Scneier to get a better idea of
cryptography and how to use it properly.  It also covers security in
general, which is necessary if you are going to use encryption.

Kevin

[ Post a follow-up to this message ]

On 2004-09-04, Kevin Fourtwenty <Kevin@Fourtwenty> wrote:

> Well, I think I understand what your saying.  PGP/GPG does generate a rand
om
> symmetric session (only used for that message/file) key, and your passphra
se
> is used to protect it.

I'm referring to GPG's behavior when the -c option (as opposed to -e) is use
d
to select traditional symmetric encryption. In this case, the only option fo
r
key generation seems to be to hash a user-entered passphrase. I'd prefer it 
to
do something similar to what it does for -e: generate a symmetric key with
good entropy, store it in the secret keyring and protect it with a passphras
e.
This way dictionary attacks wouldn't be possible unless the attacker got
access to the keyring.

> No, The passphrase is combined with a salt (a random value to help deter
> dictionary attacks) and it is hashed. The salt and the passphrase is
> repeatedly hashed until it has enough data to make a full key.  So for 256
> Twofish, it would have to hash it once (160 bits), then again, but only th
e
> second time it would only use the first (most significant) 96 bits of the
> second hashing.(160 + 96 bits - 256 bit key)

Okay. Intuitively, though, this sounds a bit suspect. Will this process of
repeated hashing using a 160-bit hash really preserve 256 bits of entropy?

[Snip more informative stuff]

Thanks for taking the time out to post such a long and helpful reply, I
appreciate it!

Suzanne

--
tril@igs.net - http://www.igs.net/~tril/
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"If you want a vision of the future, it is a wireless broadband network
feeding requests for foreign money-laundering assistance into a human
temporal lobe, forever. With banner ads."   -- John M. Ford
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

[ Post a follow-up to this message ]

On Sat, 04 Sep 2004 14:39:48 -0500, Suzanne Skinner <tril@igs.net> wrote:

>On 2004-09-04, Kevin Fourtwenty <Kevin@Fourtwenty> wrote:

<snip>

>I'm referring to GPG's behavior when the -c option (as opposed to -e) is us
ed
>to select traditional symmetric encryption. In this case, the only option f
or
>key generation seems to be to hash a user-entered passphrase. I'd prefer it
 to
>do something similar to what it does for -e: generate a symmetric key with
>good entropy, store it in the secret keyring and protect it with a passphra
se.
>This way dictionary attacks wouldn't be possible unless the attacker got
>access to the keyring.
>
<snip>

So why don't you just use the -e option? The -c option is there for a reason
. So
one can encrypt files and not need to retain any keys.

Symmetric encryption is just that.. symmetric.. If it used a "key" it wouldn
't
be symmetric, it would be asymmetric.

And with a password/phrase of sufficient length, a successful dictionary att
ack
isn't possible.

[ Post a follow-up to this message ]

On 2004-09-05, Beretta <invalid@invalid.org> wrote:

> Symmetric encryption is just that.. symmetric.. If it used a "key" it woul
dn't
> be symmetric, it would be asymmetric.

Eh? This sentence makes no sense. "Symmetric" means that the same key is use
d
to encrypt and decrypt, not that no key is used at all.

Suzanne

--
tril@igs.net - http://www.igs.net/~tril/
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"If you want a vision of the future, it is a wireless broadband network
feeding requests for foreign money-laundering assistance into a human
temporal lobe, forever. With banner ads."   -- John M. Ford
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

[ Post a follow-up to this message ]

Suzanne Skinner <tril@igs.net> wrote:
> On 2004-09-04, Kevin Fourtwenty <Kevin@Fourtwenty> wrote:
> 
>
> I'm referring to GPG's behavior when the -c option (as opposed to -e) is u
sed
> to select traditional symmetric encryption. In this case, the only option 
for
> key generation seems to be to hash a user-entered passphrase. I'd prefer i
t to
> do something similar to what it does for -e: generate a symmetric key with
> good entropy, store it in the secret keyring and protect it with a passphr
ase.
> This way dictionary attacks wouldn't be possible unless the attacker got
> access to the keyring.

It sounds rather like you are describing public key cryptography.
Using public key crypto, both GnuPG and PGP generate a session key to
encrypt the data, then encrypt the session key using a different key.
You need the secret keyring plus passphrase to decrypt.

David

[ Post a follow-up to this message ]

Suzanne Skinner <tril@igs.net> wrote in message news:<slrncjk6f8.dm.tril@mir
anda.igs.net>...

> I'm referring to GPG's behavior when the -c option (as opposed to -e) is u
sed
> to select traditional symmetric encryption. In this case, the only option 
for
> key generation seems to be to hash a user-entered passphrase. I'd prefer i
t to
> do something similar to what it does for -e: generate a symmetric key with
> good entropy, store it in the secret keyring and protect it with a passphr
ase.
> This way dictionary attacks wouldn't be possible unless the attacker got
> access to the keyring.


ok,

if you want gnupg to generate a random passphrase for you to use for
symmetric encryption,

then there is an effective, simple [although inelegant ;-) ]
workaround:

[1] use the option of 'show-session-key' in gnupg

[2] encrypt the message first to any keypair that you have

[3] decrypt the message in gnupg

[4] use the randomly generated session key that gnupg displays for
you, as your passphrase for the symmetric encryption

(1t will be 32 characters long if you use idea, or cast,
48 characters if you use 3-des
and 64 characters if you use twofish or aes-256)

it doesn't matter which one you use, since the session key will be
truncated anyway, to whatever length of passphrase you consider
sufficient.

i imagine that 12 to 16 characters is more than sufficient,

but invite the crypto experts to give their opinions on the
appropriate lengths,
and if the gnupg randomly generated session key, is 'random enough',

(and also, btw, if this is a reasonable way to use computers to
generate random strings [with the understanding that it is limited to
the hexadecimal characters]).

(it is, in any case, 'as random' as the gnupg public key encryption
that you prefer)


hth,
vedaal

[ Post a follow-up to this message ]

On 2004-09-05, David Shaw <dshaw@example.com> wrote:

> It sounds rather like you are describing public key cryptography.
> Using public key crypto, both GnuPG and PGP generate a session key to
> encrypt the data, then encrypt the session key using a different key.

Goodness, who thought this would be so hard to explain. No, I'm looking to u
se
a plain old symmetric cipher, with a plain old persistent symmetric cipher
key--just *not* generated from a passphrase! (It's becoming clear that GnuPG
won't do this, so I'll call it a wishlist item.)

A passphrase *could* be used to protect the secret key on disk. Myself, i
don't need this, because anyone who gains access to that system can already
access the unencrypted versions of the files. This is for protecting off-sit
e
files.

Why not use public-key encryption? Well, because to my (novice) mind, it add
s
unneeded complexity, and complexity means more breaking points. A
public-key-encoded file has several possible breaking points. If they can
break the symmetric encryption of the body of the file, it's broken. If they
can break the assymetric encryption used to encode the in-file session key,
it's also broken.

A file encoded with pure symmetric encryption, without a session key, has on
ly
one breaking point. And because I don't need to communicate a key with anyon
e
else, it is sufficient.

Here's a posting to lucky.openbsd.misc from someone who was looking for the
same feature. Maybe he explained it better than I can:

http://groups.google.com/groups?hl=...%40ghostitm.com

"I just want to encrypt a file with a specific key without
a passphrase, the way symmetric encryption was meant to
be done (and without storing the key in the file).

Otherwise, with a password the keyspace of the
cipher gets reduced to whatever the size is of the passphrase,
and what's the point of that? I want to rely on the secrecy
of the actual key file, rather than a passphrase."

Suzanne

--
tril@igs.net - http://www.igs.net/~tril/
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"If you want a vision of the future, it is a wireless broadband network
feeding requests for foreign money-laundering assistance into a human
temporal lobe, forever. With banner ads."   -- John M. Ford
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

[ Post a follow-up to this message ]

On 2004-09-05, vedaal@hush.com <vedaal@hush.com> wrote:

> [1] use the option of 'show-session-key' in gnupg
>
> [2] encrypt the message first to any keypair that you have
>
> [3] decrypt the message in gnupg
>
> [4] use the randomly generated session key that gnupg displays for
> you, as your passphrase for the symmetric encryption

Thanks. Of course, I could always just read random bytes from /dev/random
myself :-)

The thing is, GnuPG will still insist on hashing whatever passphrase I provi
de
using SHA-1--AFAIK there's no way to disable it. But since someone else
assured me that SHA-1 will not actually truncate key strength to 160-bits, I
'm
just going to go on with my current setup and not worry about it. I'm pretty
sure the passphrase I have (read from disk) contains plenty of entropy.

Suzannne

--
tril@igs.net - http://www.igs.net/~tril/
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"If you want a vision of the future, it is a wireless broadband network
feeding requests for foreign money-laundering assistance into a human
temporal lobe, forever. With banner ads."   -- John M. Ford
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

[ Post a follow-up to this message ]