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

+ Reply to Thread
Page 1 of 2 1 2 LastLast
Results 1 to 20 of 22

Thread: Symmetric encryption: why not use private keys?

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

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

  3. 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)

    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




  4. Re: Symmetric encryption: why not use private keys?

    On Sat, 04 Sep 2004 14:39:48 -0500, Suzanne Skinner wrote:

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




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



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

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

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

    http://groups.google.com/groups?hl=e...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
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~

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

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

    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.2.6 (SunOS)

    iD8DBQFBO2hmvmGe70vHPUMRAt/KAJ4qL2NptN1D02Jil9SWSZNhv2bCbwCg1FH7
    6T0EtVYAzG6xnygOd9jZTLY=
    =YqXE
    -----END PGP SIGNATURE-----


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

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



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



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

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

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

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

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

  18. 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"

  19. 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 see
    http://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.





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

    But anyhow, I was just curious.

+ Reply to Thread
Page 1 of 2 1 2 LastLast