Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
HomeAnnouncementsWhite Papers
Discussion GroupsFirst AidDatabasesJavaBeansGUIJava 3DVirtual MachineCORBASecurityToolsGeneral
Java DirectoryOpen Source ProjectsSample Book ChaptersUser GroupsWeb Resources
Related Topics
Databases.NETMore Topics ...

Java Forum / Security / June 2004

Tip: Looking for answers? Try searching our database.

symmetric cipher

Thread view: 
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 Magazines

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

Oracle MagazineNetwork ComputingComputer WorldBio-IT WorldeWeekInformation WeekInfosecurity
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2008 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.