Symmetric encryption: why not use private keys? - PGP

This is a discussion on Symmetric encryption: why not use private keys? - PGP ; 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 ...

Symmetric encryption: why not use private keys?

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 :-(

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?)

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
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~

Re: Symmetric encryption: why not use private keys?

Suzanne Skinner wrote:
>
> 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 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-algo
> AES256 with a SHA-1 hashed passphrase, am I really only getting 160 bits of
> 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

Re: Symmetric encryption: why not use private keys?

Hi,

"Suzanne Skinner" 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)

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

Re: Symmetric encryption: why not use private keys?

>I'm referring to GPG's behavior when the -c option (as opposed to -e) is used
>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 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 passphrase.
>This way dictionary attacks wouldn't be possible unless the attacker got
>access to the keyring.
>

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 attack
isn't possible.

Re: Symmetric encryption: why not use private keys?

Suzanne Skinner wrote:
> On 2004-09-04, Kevin Fourtwenty wrote:
>
>> 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.
>
> I'm referring to GPG's behavior when the -c option (as opposed to -e) is used
> 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 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 passphrase.
> 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

Re: Symmetric encryption: why not use private keys?

Suzanne Skinner wrote in message news:...
> I'm referring to GPG's behavior when the -c option (as opposed to -e) is used
> 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 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 passphrase.
> 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

Re: Symmetric encryption: why not use private keys?

On 2004-09-05, David Shaw 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 use
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-site
files.

Why not use public-key encryption? Well, because to my (novice) mind, it adds
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 only
one breaking point. And because I don't need to communicate a key with anyone
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:

"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
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~

Re: Symmetric encryption: why not use private keys?

On 2004-09-05, 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 provide
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
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~

Re: Symmetric encryption: why not use private keys?

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Suzanne Skinner writes:
>On 2004-09-05, David Shaw 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.

I thought you explained it well.

If I understood you, what you want is:

(a) generate a random key.
(b) encrypt the random key with a pass phrase
(c) encrypt the file with the random key. You probably have to
insert the encrypted random key (result of (b)) in the file
or record it somewhere else.

Presumably the idea is that the pass phrase is weaker than a random
key. So you only give a small amount of data to people trying to
break the pass phrase, making it harder to break. Most of the data
is encrypted with the random key, which one hopes is resistent to
breaking.

Still, this only slightly increases the cost of a dictionary attack,
so might not be much better than a direct symmetric encryption as
with "gpg --symmetric".

Possibly a script could be pieced together to do this with gnupg. I
am not planning to spend time on working out how.
>Why not use public-key encryption? Well, because to my (novice) mind, it adds
>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.

In some ways, your desired scheme is more complex. Public key
encryption is less complex in the sense that it is standardized.
Moreover, public key encryption has the advantage of having been well
studied with the weaknesses pretty well understood.

Re: Symmetric encryption: why not use private keys?

On 2004-09-05, Neil W Rickert wrote:
> If I understood you, what you want is:
>
> (a) generate a random key.
> (b) encrypt the random key with a pass phrase
> (c) encrypt the file with the random key. You probably have to
> insert the encrypted random key (result of (b)) in the file
> or record it somewhere else.
------------------------

Yes, that's exactly it (using the option I underlined).
> Still, this only slightly increases the cost of a dictionary attack,
> so might not be much better than a direct symmetric encryption as
> with "gpg --symmetric".

Yes, you're probably right. My biggest concern was whether the use of 160-bit
hashing on the passphrase was effectively limiting me to 160-bit encryption,
which several people have assured me is not the case.

I do seriously doubt whether people who use typed-in passphrases for gpg
--symmetric (I read it from a file via -passphrase-fd 0) are getting anywhere
near the kind of keyspace that they think they are. Imagine using Diceware for
AES 256--judging by the FAQ you'd have to memorize 20 random words!

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
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~

Re: Symmetric encryption: why not use private keys?

On Sat, 04 Sep 2004 19:53:57 -0500, Suzanne Skinner wrote:
>On 2004-09-05, Beretta wrote:
>
>> Symmetric encryption is just that.. symmetric.. If it used a "key" it wouldn't
>> be symmetric, it would be asymmetric.
>
>Eh? This sentence makes no sense. "Symmetric" means that the same key is used
>to encrypt and decrypt, not that no key is used at all.
>
>Suzanne

Literally true. However, in the context of PGP/GPG I meant that a keypair isn't
used. A password/phrase is used.

Re: Symmetric encryption: why not use private keys?

On Sun, 05 Sep 2004 11:56:52 -0500, Suzanne Skinner wrote:

>
>The thing is, GnuPG will still insist on hashing whatever passphrase I provide
>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.
>

I'm rather curious, as to why trunacating something to 160 bits would be
worrisome?

160 bits and 256 bits, etc are all out of the reach of even the fastest
computers on the planet for decades (maybe centuries) to come.

Re: Symmetric encryption: why not use private keys?

Suzanne Skinner writes:
> The thing is, GnuPG will still insist on hashing whatever passphrase
> I provide 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,

SHA1 has 160 output bits. The output entropy can't possibly be any
higher than that. However, 160 bits is more than enough.

Re: Symmetric encryption: why not use private keys?

In comp.security.pgp.discuss Suzanne Skinner wrote:
> On 2004-09-05, 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 provide using SHA-1--AFAIK there's no way to disable it.

--s2k-digest

where is whatever hash you prefer, so long as GnuPG supports
it (use gpg --version to see a list of supported hashes).

In general, it pays to be careful when messing about with settings
like this. There are many ways to shoot yourself in the foot. In
this particular case, if you pick a digest that isn't widely
supported, then you can easily make a file that isn't decryptable by
the recipient. If the recipient is yourself, then obviously this
doesn't matter as much.

David

Re: Symmetric encryption: why not use private keys?

Suzanne Skinner wrote:
> On 2004-09-05, David Shaw 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 use 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.)

Actually, GnuPG can do this, but it is disabled for compatibility
reasons. In the file encode.c, there is a function called
encode_symmetric(). That function just calls
encode_simple(filename,1,0); Change that last 0 to a 1, and recompile.
Now GnuPG will generate a random session key like you want.

Do a regular gpg -c and encrypt your file. Once you are done, run
gpgsplit on the result. You will end up with two files
("000001-003.sym_enc" and "000002-009.encrypted"). The 000001 file is
your "secret key". It contains the random session key encrypted to
your passphrase. Save it somewhere safe. The 000002 file is your
data, encrypted to the random session key. Save it wherever you want.

When you want to decrypt, cat the files back together again, and run
gpg on the result.

Not that I'm recommending you do this - it's a lot of manual labor for
little gain, but it is what you were asking for.

David

Re: Symmetric encryption: why not use private keys?

On 2004-09-05, Beretta wrote:
> I'm rather curious, as to why trunacating something to 160 bits would be
> worrisome?

Because I'd like my private files to be just as private 20 years from now :-)
> 160 bits and 256 bits, etc are all out of the reach of even the fastest
> computers on the planet for decades (maybe centuries) to come.

So you say. But within my lifetime, DES went from becoming the official
government standard, to being breakable in 24 hours. What's to stop that from
happening to AES 128? It's not that I think there's a vast conspiracy out to
get me. I just don't want to be susceptible to casual snooping, now or later.

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
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~

Re: Symmetric encryption: why not use private keys?

Suzanne Skinner writes:
> > 160 bits and 256 bits, etc are all out of the reach of even the fastest
> > computers on the planet for decades (maybe centuries) to come.
>
> So you say. But within my lifetime, DES went from becoming the
> official government standard, to being breakable in 24 hours.

There was huge controversy about DES's key size back when it first
became a standard, since it was feasible even at that time to build
enough hardware to break it by brute force. The surprise is that it
lasted as long as it did, not that it eventually became breakable.
> What's to stop that from happening to AES 128? It's not that I think
> there's a vast conspiracy out to get me. I just don't want to be
> susceptible to casual snooping, now or later.

The issue is that there are likely to be far easier methods than
cryptanalysis for some attacker to get your data; they'll go after the
weakest part of the system, not the strongest part. So you should be
concerned about the security of your whole system, not just a key length.

Re: Symmetric encryption: why not use private keys?

Suzanne Skinner wrote:
[snip]
> So you say. But within my lifetime, DES went from becoming the official
> government standard, to being breakable in 24 hours. What's to stop that from
> happening to AES 128? It's not that I think there's a vast conspiracy out to
> get me. I just don't want to be susceptible to casual snooping, now or later.

there is no encryption algorithm (short of an OTP, and that has other
issues) for which there is a guarantee that some future breakthrough
won't break the encryption algorithm... and increasing the keysize
doesn't really prevent this...

--
"maxwell can tell he's in hell
just wants you to visit him there
same old game that he's playin'
his rules are never fair"

Re: Symmetric encryption: why not use private keys?

"Suzanne Skinner" wrote in message
news:slrncjnubl.9i.tril@miranda.igs.net...
> On 2004-09-05, Beretta wrote:
>
>> I'm rather curious, as to why trunacating something to 160 bits would be
>> worrisome?
>
> Because I'd like my private files to be just as private 20 years from now
> :-)
>
>> 160 bits and 256 bits, etc are all out of the reach of even the fastest
>> computers on the planet for decades (maybe centuries) to come.
>
> So you say. But within my lifetime, DES went from becoming the official
> government standard, to being breakable in 24 hours. What's to stop that
> from
> happening to AES 128? It's not that I think there's a vast conspiracy out
> to
> get me. I just don't want to be susceptible to casual snooping, now or
> later.
If Moore's law will hold for another 20 years, then 2-3 nanometer technology
will be delivered in that time (it was less than a week ago, when intel
announced 65 nanometer technology seehttp://www.intel.com/labs/features/si08042.htm).
Electrical signal is conveyed with the speed about 70% of speed of the
light. i.e. 210000000 meters per second.
That means that just for electrical signal being able to pass between two
transistors placed on a dinstance of 2 nanometers 2^160 times would take:
10^(160/log2(10)+log10(0.000000002)-log10(210000000))=13919063212675265887654141263964 .60
seconds = 161100268665222984810811820.184775465 days =
441370599082802698111813.2059856862 years.
If we run electrical signal in parallel between 8.8*10^23 transistors, then
we could reduce time for electrical signal being conveyed between all these
pairs 2^160 times to about one year. However 8.8*10^23 transistors is many
orders more than total amount of transistors that exists today (or will
exist in 20 years). If you add that to brute force 2^160 combination would
require much more than single pass of electrical signal between a pair of
transistors. means that the only way to try all 2^160 combinations in
reasonable time is either to invent time machine or use faster than light
quantum teleportation in some futuristic quantum computers.

-Valery.

Re: Symmetric encryption: why not use private keys?

On Mon, 06 Sep 2004 00:45:53 -0500, Suzanne Skinner wrote:
>On 2004-09-05, Beretta wrote:
>
>> I'm rather curious, as to why trunacating something to 160 bits would be
>> worrisome?
>
>Because I'd like my private files to be just as private 20 years from now :-)
>
>> 160 bits and 256 bits, etc are all out of the reach of even the fastest
>> computers on the planet for decades (maybe centuries) to come.
>
>So you say. But within my lifetime, DES went from becoming the official
>government standard, to being breakable in 24 hours. What's to stop that from
>happening to AES 128? It's not that I think there's a vast conspiracy out to
>get me. I just don't want to be susceptible to casual snooping, now or later.

The only way a 160 bit AES key is gonna be broken is for some revolution to
occur in mathematics or for a flaw to be found in AES, in both scenarios having
a 256 bit key is going to do you no good.

As a side note, even DES isn't susceptible to "casual" snooping. The machine the
EFF built to break it cost around $200,000US.