Re: [GNU Crypto] AES (Rijndael) for J2ME

[Casey Marshall]

>>>>> "Wes" == Wes Biggs <address@hidden> writes:

Wes> Casey Marshall wrote:
Wes> I converted a minimal version of the Rijndael cipher for use with
Wes> J2ME MIDP, with an emphasis on reducing bytecode size (it assumes
Wes> AES, i.e. 128-bit key/blocksize, and uses none of the rest of the
Wes> gnu.crypto framework).  It ends up at about 4.5K when compiled
Wes> without debug.  I can post or email it if it's useful to others.
>> 
>> No 192- or 256-bit keys, though? I seem to recall that key size
>> influenced the number of rounds; is it possible to squeeze AES down
>> with all three key sizes?
>> 
Wes> Sorry, I misspoke.  I did indeed keep the logic for all three key
Wes> sizes.  I just ripped out the aesEncrypt and aesDecrypt functions
Wes> and slapped them (with some simplified keymaking logic that
Wes> assumes blocksize) into a new class, so it works with
Wes> 128/192/256.

Ok. One thing that I eventually wanted to do was optimize AES, instead
of making it an alias for "Rijndael". Since it only needs to support
one block size and three key sizes, I'm sure that omitting multiple
block sizes would allow big speed/space improvements.

>> But regardless I think we'd like to see this implementation.
>> 
Wes> I'll make some mods aimed at reconciling it with Rijndael.java and post it.

Wes> Of course AES by itself is not too useful without PKI for key
Wes> exchange, and it will be harder to convert an asymmetric
Wes> algorithm that relies on BigInteger arithmetic (BouncyCastle has
>> 
>> Is it possible to trim down a mp-int implementation? I mean, I don't
>> think many public-key crypto algorithms need anything besides
>> arithmetic and modpow.
>> 
Wes> This might be useful.  BC implements the entire BigInteger class,
Wes> which is probably overkill (though perhaps it obfuscates well for
Wes> J2ME).  Do you have a candidate MPInt class I can take a look at?  If
Wes> we could get a ME version of RSA to work, that would make a useful
Wes> little bundle.

The one I'd look at first is Classpath's BigInteger/gnu.java.math.MPN
classes. The latter is basically a Java implementation of some basic
low-level functions in GMP. Figuring out what things like RSA, DSA,
and DH would need (or only one of them, if you aren't supporting them
all) and stripping out everything else should compress it down fairly
nicely.

Wes> done this for the lightweight crypto package and the resulting
Wes> classes are quite large).  But AES with key delivery via a push
Wes> mechanism like SMS approximates the security environment of OMA
Wes> DRM 1.0 separate delivery, which was my immediate goal.
>> 
>> I'm not familiar with that. Is it a (somewhat) generic key-exchange?
>> 
Wes> Not really.  The idea is that encrypted content is downloaded (HTTP
Wes> pull) and then the key is wrapped in a WBXML message and delivered via
Wes> a push mechanism (SMS).  The security of this scheme is solely
Wes> dependent on the SMS channel being difficult to intercept.  Anyone
Wes> able to piece together both messages can reclaim the plaintext.  OMA
Wes> (Open Mobile Alliance) DRM 2.0 is much more complex (and
Wes> satisfactory), relying on device manufacturers to embed client
Wes> certificates.

>> If so it may be nice to have an implementation using GNU Crypto's key
>> agreement API.
>> 
Wes> It's possible, but because the communication methods are not the
Wes> same, I'm not sure how useful it would be.  I may not be
Wes> understanding the key agreement API, though.

It's fairly simple, it uses a "phased-message" API -- you update a key
agreement object with an "incoming message" (not much more than a byte
array) and get an "outgoing message" from it. Each side repeats those
calls and sends each other the outgoing message until the key is
exchanged.

-- 
Casey Marshall || address@hidden