Re: PGP scripting...

From: Andre Mariën (andre.marienat_private)
Date: Thu Jan 23 2003 - 23:04:41 PST

  • Next message: Ogle Ron (Rennes): "RE: Standards for developing secure software"

    It may be just me, but I am getting confused.
    If we keep both private and public key secret,
    why not use plain old symmetric cryptography?
    We are talking about confidentiality I thought.
    If we take it to non-repudiation there still are some merrits.
    
    One of the things about public/private keys is,
    well, the public key can be public.
    
    -- André
    
    
    Jason Coombs wrote:
    > Interesting discussion -- just a point of clarity:
    > 
    > Glynn Clements wrote:
    > 
    >>To take an extreme (and somewhat contrived) example, suppose that you
    >>know that the message will either be "The deal is on" or "The deal is
    >>off"; although the message would occupy at least 112 bits as ASCII,
    >>you only really have one bit of data, and you would only have to
    >>encrypt the two candidate messages to determine which one was actually
    >>sent.
    > 
    > 
    > Previously Andre Marien stated:
    > 
    >>If there are n possible messgaes, it only takes at most n trials to
    >>decrypt the message, no matter your key size(if the encrypting key is
    >>known; typically it is the public key and it is known)
    > 
    > 
    > If the public key used to perform the encryption is known, then it only
    > takes at most n trials to decrypt a message encrypted with that public key.
    > Without the public key, you're still stuck brute-forcing the key length
    > because the RSA algorithm does not result in predictable placement of
    > ciphertext bits that correspond to the plaintext "n" or "f" -- you can't
    > just ignore the rest of the cryptographic transformation and concentrate on
    > scanning a single byte until it comes up "n" or "f" and then attempt to
    > transform the entire ciphertext message with the potential key until you
    > find the right one.
    > 
    > You can mount a chosen plaintext attack with "The deal is on" and one in
    > parallel with "The deal is off", but since you don't know the key your
    > attack is going to take a very long time and span a good deal of the
    > available key space.
    > 
    > Asymmetric bulk encryption can also be used with a random initialization
    > vector the same way that IVs are used in symmetric bulk encryption with
    > feedback modes like Cipher Block Chaining. You then have a secret session
    > key (the IV) that makes brute-force chosen plaintext attacks unreasonable,
    > while preserving the feature of practical unrecoverability of the plaintext
    > in the event that the secret session key is captured along with the
    > ciphertext. It is arguably more difficult for an adversary to capture [the
    > private key from an asymmetric key pair AND the IV AND the ciphertext] than
    > it is to capture [the symmetric secret key AND the IV and the ciphertext] --
    > for the simple reason that at the point of encryption the softwre that
    > implements the asymmetric bulk cipher is never in possession of the private
    > key necessary for decryption.
    > 
    > Jason Coombs
    > jasoncat_private
    > 
    > -----Original Message-----
    > From: Glynn Clements [mailto:glynn.clementsat_private]
    > Sent: Wednesday, January 22, 2003 10:06 AM
    > To: Beatie, Breck (ISSMountain View)
    > Cc: secprogat_private; Andre Marien
    > Subject: RE: PGP scripting...
    > 
    > 
    > 
    > Beatie, Breck (ISSMountain View) wrote:
    > 
    > 
    >>>Please do not use public key encryption for bulk data, even if
    >>>you accept the long times. It is a bad idea. If there are n
    >>>possible messgaes, it only takes at most n trials to decrypt
    >>>the message, no matter your key size (if the encrypting key is known;
    >>>typically it is the public key and it is known).
    >>>This problem is justification in itself to have a two stage system
    >>>for encryption of bulk data.
    >>>(there is someone at counterpane that can explain it in more detail ;-)
    >>
    >>I'm not sure I understand the point of this message.  It seems that
    >>you are saying that you can figure out the cleartext message by taking
    >>the n possible cleartext messages and encrypting with the known public
    >>key until you find the cipher text.  That much makes sense, but since
    >>we were talking about encryption of bulk data it seems that the number
    >>of possible messages would be VERY large and such an approach would
    >>not be workable.
    >>
    >>It seems that your comment would even argue AGAINST the "two stage"
    >>system that you're talking about.  The total number of possible symmetric
    >>keys would be much less than the total number of possible messages.
    >>
    >>But then I'm a bit of a crypto ignoramus.  If you (or someone) would
    >>elaborate a bit I would be grateful.
    > 
    > 
    > I think that you're misinterpreting the term "bulk data" slightly;
    > it is referring to the actual plaintext (subject to any
    > transformations such as compression), not necessarily to a *large*
    > amount of data.
    > 
    > The context may greatly reduce the set of possible plaintexts, even
    > below the size of a symmetric key. Suppose that you can guess almost
    > the entire plaintext (e.g. because it's generated automatically by a
    > specific piece of software), and the only thing which you *can't*
    > guess is a very small section e.g. a credit card number, you could
    > attempt a brute-force search of all plausible credit card numbers,
    > which is likely to be easier than brute-forcing a 128-bit symmetric
    > key.
    > 
    > To take an extreme (and somewhat contrived) example, suppose that you
    > know that the message will either be "The deal is on" or "The deal is
    > off"; although the message would occupy at least 112 bits as ASCII,
    > you only really have one bit of data, and you would only have to
    > encrypt the two candidate messages to determine which one was actually
    > sent.
    > 
    > In short, with the two-stage approach, you have a fixed lower bound on
    > the number of possible plaintexts, and for a 128-bit key, this is well
    > beyond brute-force viability with current hardware, even for the NSA.
    > OTOH, directly encrypting the plaintext provides no such lower bound.
    > 
    > --
    > Glynn Clements <glynn.clementsat_private>
    > 
    
    
    -- 
    André Mariën
    
    Ubizen  http://www.ubizen.com
    Phone   +32 16 28 70 00
    Fax     +32 16 28 71 00
    



    This archive was generated by hypermail 2b30 : Fri Jan 24 2003 - 11:23:44 PST