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

Wes Biggs <wes@xxxxxxxxx> · Tue, 28 Dec 2004 18:10:32 -0800

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?

Sorry, I misspoke.  I did indeed keep the logic for all three key 
sizes.  I just ripped out the aesEncrypt and aesDecrypt functions and 
slapped them (with some simplified keymaking logic that assumes 
blocksize) into a new class, so it works with 128/192/256.
But regardless I think we'd like to see this implementation.

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.

This might be useful.  BC implements the entire BigInteger class, which 
is probably overkill (though perhaps it obfuscates well for J2ME).  Do 
you have a candidate MPInt class I can take a look at?  If we could get 
a ME version of RSA to work, that would make a useful little bundle.
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?

Not really.  The idea is that encrypted content is downloaded (HTTP 
pull) and then the key is wrapped in a WBXML message and delivered via a 
push mechanism (SMS).  The security of this scheme is solely dependent 
on the SMS channel being difficult to intercept.  Anyone able to piece 
together both messages can reclaim the plaintext.  OMA (Open Mobile 
Alliance) DRM 2.0 is much more complex (and satisfactory), relying on 
device manufacturers to embed client certificates.
If so it may be nice to have an implementation using GNU Crypto's key

agreement API.

It's possible, but because the communication methods are not the same, 
I'm not sure how useful it would be.  I may not be understanding the key 
agreement API, though.
Wes> I didn't see this discussed in the archives so I apologize if
Wes> this is well-trodden ground.
I don't recall discussing this, or seeing it discussed, but I do think

the factory pattern of GNU Crypto is underused currently. One thing I

had in mind was compile- or run-time configurable algorithm

implementations, so you could choose a particular version that suited

whatever local configuration. The obvious one to me was an optimized

implementation of a cipher or hash in assembler, and a

space-constrained version could fit that bill, too.

Yes, it would make sense for that to be a ./configure or make option.
Cheers,
Wes

_______________________________________________
gnu-crypto-discuss mailing list
gnu-crypto-discuss@xxxxxxx
http://lists.gnu.org/mailman/listinfo/gnu-crypto-discuss