Multiple symetric cyphers
-----BEGIN PGP SIGNED MESSAGE----- - -----BEGIN PGP SIGNED MESSAGE----- One of the possible weaknesses in public-key messages is their dependence upon a particular symetric cypher for the message with the session key being contained in the block encrypted by the antisymetric cypher. IE, if a weakness in IDEA is discovered, it can be exploited against all PGP messages. I'm wondering: would the strength be increased by using a randomly selected symetric cypher? IE, as PGP uses IDEA and RIPEM uses DES/3DES, what if a random cypher were selected from a set of cryptographically strong symetric cyphers and information about the cypher selected were encrypted in the RSA-encrypted block? I guess this reduces to: do strong cyphers have "signatures" of some sort, by which the type of encryption can be derived? And if so, can this "signature" be reduced by including part (eg, the first and last bytes) of the ciphertext in the RSA block rather than the "clear" cyphertext block? Just a thought, - - -- Todd Masco | "life without caution/ the only worth living / love for a man/ cactus@hks.net | love for a woman/ love for the facts/ protectless" - A Rich Cactus' Homepage - -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBLxQorxNhgovrPB7dAQF+HgP/b6RVkLS0vyjpVoHy1iF8IDgH1VFwci03 ZpD4tvQ+amZ3OLfMPNvM3jV3br6+/xVKax07yP0r26jbqV3T0RCNMzKLrQjnoyep /h+DBNfboeU4BkhhJFIayLp0w+ykJRvzWoa72l4Uzos66Nu9n/spXwBbrGYD3awe dUUr4YzLnhU= =xON2 - -----END PGP SIGNATURE----- - --- [This message has been signed by an auto-signing service. A valid signature means only that it has been received at the address corresponding to the signature and forwarded.] -----BEGIN PGP SIGNATURE----- Version: 2.6.2 Comment: Gratis auto-signing service iQBFAwUBLxRjjSoZzwIn1bdtAQEt2gF/bnrL7r8CycdWz5H80DLpEFGRvDFy7zfF OQQjnGTDmdSv+d3lQOfnqP7mKJJbyqo4 =QXEU -----END PGP SIGNATURE-----
From: cactus@seabsd.hks.net (L. Todd Masco) I'm wondering: would the strength be increased by using a randomly selected symetric cypher? Strength is not right aspect. Global risk is reduced, simply because the aggregate cost of a breach is reduced. But selecting a single cipher is just as much a fixed policy as a randomly selected one is. Far better to let the user pick a policy, both about sent and accepted ciphers. I guess this reduces to: do strong cyphers have "signatures" of some sort, by which the type of encryption can be derived? If they do, they're likely not _strong_ ciphers. Eric
But selecting a single cipher is just as much a fixed policy as a randomly selected one is. Far better to let the user pick a policy, both about sent and accepted ciphers.
If you do give the user control, what is an acceptable mechanical implementation? Let's say I have a file encryptor which allows the user to choose between DES, 3DES, IDEA, Diamond, and RC5. Must I require the user to tell that program what cypher was used to encrypt the file she wishes to decrypt? Is storing the cypher type as part of the encrypted file a weakness? -Paul -- Paul Robichaux, KD4JZG | Good software engineering doesn't reduce the perobich@ingr.com | amount of work you put into a product; it just Not speaking for Intergraph. | redistributes it differently. ### http://www.intergraph.com ###
On Thu, 12 Jan 1995, Paul Robichaux wrote:
But selecting a single cipher is just as much a fixed policy as a randomly selected one is. Far better to let the user pick a policy, both about sent and accepted ciphers.
If you do give the user control, what is an acceptable mechanical implementation? Let's say I have a file encryptor which allows the user to choose between DES, 3DES, IDEA, Diamond, and RC5. Must I require the user to tell that program what cypher was used to encrypt the file she wishes to decrypt?
Is storing the cypher type as part of the encrypted file a weakness?
Perhaps it is. The algorithm set could be part of the key, though...
From: paul@poboy.b17c.ingr.com (Paul Robichaux) Must I require the user to tell that program what cypher was used to encrypt the file she wishes to decrypt? Only if you don't want to store the type alongside. See below. Is storing the cypher type as part of the encrypted file a weakness? Well, it's no weaker than current systems. PGP stores the cipher type in the source code: it's always IDEA. One should allow, however, the cipher type to be empty alongside the data so that another tool can store cipher information. Eric
Well, it's no weaker than current systems. PGP stores the cipher type in the source code: it's always IDEA. One should allow, however, the cipher type to be empty alongside the data so that another tool can store cipher information.
Actually, a slight correction. PGP does have an algorithm byte for the encryption algorithm; this byte is inside the RSA block. (It doesn't have to be RSA, either, but thats a different story). So long as you use a public key to encrypt, you get this byte. If you just use PGP -c, using the current implementation, you do not get a type byte. Oops. My point is that although the current implementation doesn't have multiple encryption schemes, that doesn't mean that it can't have them... -derek
participants (5)
-
cactus＠seabsd.hks.net -
Derek Atkins -
eric＠remailer.net -
Mike Johnson second login -
paul＠poboy.b17c.ingr.com