Java Forum / Security / June 2004
symmetric cipher
Roedy Green - 23 Jun 2004 20:03 GMT I have written a package that does RSA-style signing, encryption, compression, serialization, and armouring using nothing more exotic than BigInteger.
The only catch is decryption is very slow, and is not suitable for all but the smallest files, about 500 bytes a second with 1024 bit keys.
I would like to add another layer to this, where I use the RSA code to encrypt a session key so that I could handle larger files.
I have been asked to create product for transcriptionists to use to deliver their results confidentially via a website.
So the question.
What algorithm should I use?
The characteristics:
1. reasonably fast.
2. reasonably secure.
3. free code or decent algorithm descriptions exist.
4. Ideally can be implemented without JCE though that is of lesser importance.
There are many choices, but I have never seen an explanation on how you go about choosing the best one for a given application.
 Signature Canadian Mind Products, Roedy Green. Coaching, problem solving, economical contract programming. See http://mindprod.com/jgloss/jgloss.html for The Java Glossary.
Michael Amling - 24 Jun 2004 14:54 GMT > I have written a package that does RSA-style signing, encryption, > compression, serialization, and armouring using nothing more exotic > than BigInteger. What kind of padding are you using? OAEP, SAEP+, or what?
> The only catch is decryption is very slow, and is not suitable for all > but the smallest files, about 500 bytes a second with 1024 bit keys. [quoted text clipped - 8 lines] > > What algorithm should I use? Use AES. It's not that hard to implement from scratch, although many people prefer not to. www.bouncycastle.org has an implementation in Java (I presume; I've never used or looked at it.), and there are some public C implementations that could be easily recoded in Java. Be sure to test the implementation you're using against the test vectors at http://csrc.nist.gov/encryption/aes/rijndael/rijndael-vals.zip before relying on it. I prefer CTR mode, but there are many who prefer CBC. Be sure to use a MAC, such as HMAC-SHA1 or NMAC-SHA1. Choose the AES key and the MAC key(s) at random (which is a challenge in itself), and pad them with OAEP or equivalent before encrypting with the RSA public key. The IV doesn't have to be secret, but if you've got the room (which you probably will with even a 1024-bit modulus), it doesn't hurt.
> The characteristics: > [quoted text clipped - 9 lines] > There are many choices, but I have never seen an explanation on how > you go about choosing the best one for a given application.
 Signature --Mike Amling
Roedy Green - 24 Jun 2004 20:08 GMT >> I have written a package that does RSA-style signing, encryption, >> compression, serialization, and armouring using nothing more exotic >> than BigInteger. > > What kind of padding are you using? OAEP, SAEP+, or what nothing. It is a self-contained system. The armouring is Base64u, a variant of Base64 that is url-encoding safe.
 Signature Canadian Mind Products, Roedy Green. Coaching, problem solving, economical contract programming. See http://mindprod.com/jgloss/jgloss.html for The Java Glossary.
Michael Amling - 25 Jun 2004 04:15 GMT >>>I have written a package that does RSA-style signing, encryption, >>>compression, serialization, and armouring using nothing more exotic [quoted text clipped - 3 lines] > > nothing. Naive RSA is not secure. Even with some kinds of padding, it's not secure. Allow me to quote from Bodo Muller's recent posting on sci.crypt: --------- A padding scheme that is deterministic cannot be secure even against passive adversaries (assuming that you want at least semantic security): If the adversary can guess what the plaintext might be, then he can easily verify if this guess is true just by encrypting the message himself and comparing the result with a given ciphertext.
So there are probabilistic padding schemes such as the one from PKCS v#1.5 that add a large number of random bits and some fixed bits. But even these have vulnerabilities in the presence of active adversaries: For example, Bleichenbacher's attack on RSA with PKCS #v1.5 can decrypt arbitrary ciphertexts; it requires just an oracle that tries to decrypt queries and merely reveals if this decryption attempt succeeded or not (i.e., whether the result of the exponentiation with the RSA private key did contain the expected fixed bits specified by the padding scheme).
Thus more sophisticated padding schemes are called for.
OAEP, "Optimal Asymmetric Encryption Padding", was the first one with a security proof. The proof later turned out not to prove what it was expected to prove, but RSA-OAEP was later proven secure anyway. The remaining problem is that the RSA-OAEP security proof isn't really all that meaningful: It says essentially "if you can break RSA-OAEP, then with some effort you can compute e-th roots modulo n" (presumably the latter is hard, which would appear to imply that RSA-OAEP must be secure). But at typical key sizes, the specific effort needed here is more than would be required to go straight ahead and factor n and break RSA that way instead.
But OAEP led to further padding schemes: by now we have OAEP+, SAEP, and SAEP+. ---------
> It is a self-contained system. Meaning, it need not interoperate with other encryption applications?
> The armouring is Base64u, a > variant of Base64 that is url-encoding safe. If that's a deterministic transformation of the ciphertext, it doesn't affect security.
--Mike Amling
Roedy Green - 25 Jun 2004 06:10 GMT > Meaning, it need not interoperate with other encryption applications? No it does not. It is simply a way of delivering a Java object via CGI, email etc via a chain of servers over unsecure channels, e.g. to deliver credit card info.
I guess I have to read up on what this padding stuff is about. I figured it was enough it you arrange that the same encrypted string were very unlikely to ever be sent more than once, even if the data were identical.
 Signature Canadian Mind Products, Roedy Green. Coaching, problem solving, economical contract programming. See http://mindprod.com/jgloss/jgloss.html for The Java Glossary.
Joseph Daniel Zukiger - 29 Jun 2004 09:04 GMT > > Meaning, it need not interoperate with other encryption applications? > [quoted text clipped - 6 lines] > were very unlikely to ever be sent more than once, even if the data > were identical. Yeah, you want to basically munge away any patterns that the attacer (or his software) can grab hold of. Which means for instance, that you want to avoid an encrypted length that is very closely related to the plaintext length. If the attacker can feed a fake credit card number through your encryption page, for instance, and see that it produces a field the same length as fields that every query on that page produces, then the attacker can go ahead and assume that the field with the matching length is a credit card number field. That's two huge clues.
In fact, if there are patterns that let the attacker see where the individual fields of the query start and end, he or she already knows more than you want him or her to.
So one strategy is to increase the data entropy by interleaving the data with something that is distracting, is not depedent on the data sent, is variable in length, and is not going to make it any easier to decrypt the real data. And, of course, your decryption tools have to be able to strip out the decoy stuff. It works best if the interleaving is at the bit level, of course.
Incidentally, converting to base64 before you ship may seem to have an advantage with http basic authentication, but it could well reduce the domain the attacker has to work against.
Michael Amling - 29 Jun 2004 14:54 GMT >> It is simply a way of delivering a Java object via >>CGI, email etc via a chain of servers over unsecure channels, e.g. to [quoted text clipped - 25 lines] > be able to strip out the decoy stuff. It works best if the > interleaving is at the bit level, of course. Message systems that achieve confidentiality and authenticity usually allow an attacker to see the message lengths. SSL, for instance, does not hide message lengths. OCB does not hide message lengths. The attacker is allowed to know a credit card number is being sent, and to know the ciphertext of the credit card number. It doesn't help her because she can't use that information to conclude any credit card number is more likely to have been sent than any other. And the system provides authenticity in that any message that is modified by an attacker will be rejected by the receiver. I believe the property you want to get is IND-CCA2.
> Incidentally, converting to base64 before you ship may seem to have an > advantage with http basic authentication, but it could well reduce the > domain the attacker has to work against. Converting to base 64 would not affect security. At most an attacker would just have to convert back.
--Mike Amling
Roedy Green - 29 Jun 2004 17:27 GMT > Message systems that achieve confidentiality and authenticity usually >allow an attacker to see the message lengths. In diplomatic communication they tackle that problem by padding messages to standard lengths. Further, they send the same amount of traffic each day, padding as necessary, so that increased flurry of activity does not give them away.
It would be pretty easy to add a variable amount of salt to the head/tail/middle of a unencrypted record to pad it to an even multiple of say 1024 bytes to help bust up that clue.
 Signature Canadian Mind Products, Roedy Green. Coaching, problem solving, economical contract programming. See http://mindprod.com/jgloss/jgloss.html for The Java Glossary.
Joseph Daniel Zukiger - 30 Jun 2004 03:06 GMT > > Message systems that achieve confidentiality and authenticity usually > >allow an attacker to see the message lengths. [quoted text clipped - 7 lines] > head/tail/middle of a unencrypted record to pad it to an even multiple > of say 1024 bytes to help bust up that clue. I'm sitting here trying to remember whether it's better to pad with random bits before encrypting or pad after the encryption with random literary quotes, riddles, and standup comedy encrypted with a separate algorithm.
Joseph Daniel Zukiger - 30 Jun 2004 03:01 GMT > ... > Message systems that achieve confidentiality and authenticity usually [quoted text clipped - 7 lines] > attacker will be rejected by the receiver. > I believe the property you want to get is IND-CCA2. http://www.eviloverlord.com/lists/overlord.html
See number 11.
> > Incidentally, converting to base64 before you ship may seem to have an > > advantage with http basic authentication, but it could well reduce the > > domain the attacker has to work against. > > Converting to base 64 would not affect security. At most an attacker > would just have to convert back. For some reason, I had the idea that Roedy meant to encode base64 first and then encrypt. He cleared that up.
Michael Amling - 30 Jun 2004 17:00 GMT >>... >> Message systems that achieve confidentiality and authenticity usually [quoted text clipped - 11 lines] > > See number 11. I don't have a URL for a concise definition, but IND-CCA2 means that an attacker given two plaintexts of equal length and the ciphertext of one of them can't determine which plaintext was encrypted with a probability any greater than 0.5 plus epsilon when she's allowed to mount an adaptive chosen ciphertext attack. The probability is taken as an average over all keys. An encryption technique has (t,e) IND-CCA2 when at attacker limited to time t can do no better than an epsilon value of e. Some applications may be satisfied with (one CPU day, 2**-40). Others may want (1000 CPU-years, 2**-80).
IND-CCA1, which is implied by IND-CCA2, has the same definition but with "non-adaptive" instead of "adaptive". Either property implies IND-CPA, which is the indistinguishability of plaintexts when the attacker is allowed a chosen plaintext attack.
See, e.g., http://www.cs.berkeley.edu/~daw/cs276/ for more background. I admit it's not a real good source, as the notes have some gaps and typos.
Note: While these are desirable properties, no symmetric or public key crypto scheme (except the one time pad) has been mathematically proven to have them. Note: This is just about confidentiality and authentication. I don't know anything useful about fending off traffic analysis or denial of service.
--Mike Amling
Roedy Green - 29 Jun 2004 17:21 GMT >Incidentally, converting to base64 before you ship may seem to have an >advantage with http basic authentication, but it could well reduce the >domain the attacker has to work against. But I can't see how wrapping the final result in base64u gives away anything additional. The process is easily convertible in both directions. The argument is, if it did help, then the cracker could easily wrap it himself.
If you failed to compress before encrypting, I could see that possibly giving away some clues, or if you for some bizarre reason did the opposite, armoured BEFORE encrypting, that too could add some clues because it would make it easier to detect success on a decryption attempt. From a practical point of view, if you are trying to deter thieves, not Ashcroft, your best bet is to use something slightly non-standard, so long at is it not totally amateurish. Even if you, in theory, inadvertently reduce the strength of your encryption, in practical terms, you make cracking it less economically rewarding. Additional effort is required with a smaller universe of collectable credit cards as the reward.
The other advantage if the general scheme collapses at some point because of an advance in mathematics or say quantum computing, your variant scheme way survive a little longer, giving you time to orchestrate a replacement.
For anything that HAS to remain secret, people are overlooking the one-time pad which can be made much more convenient today than it was originally.
 Signature Canadian Mind Products, Roedy Green. Coaching, problem solving, economical contract programming. See http://mindprod.com/jgloss/jgloss.html for The Java Glossary.
Roedy Green - 24 Jun 2004 20:10 GMT > What kind of padding are you using? OAEP, SAEP+, or what? If you mean salting, I salt the start of each block with 4 bytes of random gibberish, so that the same message does not encrypt to the same value each time.
The source is not that big and is well commented. You can have a look at how it works.
See http://mindprod.com/products.html#WRAPPER
 Signature Canadian Mind Products, Roedy Green. Coaching, problem solving, economical contract programming. See http://mindprod.com/jgloss/jgloss.html for The Java Glossary.
Greg Stark - 24 Jun 2004 21:10 GMT > I would like to add another layer to this, where I use the RSA code to > encrypt a session key so that I could handle larger files.
> So the question. > [quoted text clipped - 10 lines] > 4. Ideally can be implemented without JCE though that is of lesser > importance. Roedy,
A good choice would be AES. You can follow the specs for PKCS#7 enveloped data (http://www.rsasecurity.com/rsalabs/node.asp?id=2129). If you're not worried about interoperability, you dispense with all the ASN.1 stuff, etc. But do keep in mind security-relevant aspects, such as PKCS#1 padding schemes.
You can also find the relevant PKCS specs in RFC form, as RFCs 3447 and RFC 2315. Also, the S/MIME version 2 and version 3 (CMS) standards are based on PKCS7, so you might look at them for encouragement (RFCs 2311 and 3369)
--greg
Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
|
|