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

[Casey Marshall <csm@xxxxxxx>]

>>>>> "Wes" == Wes Biggs <wes@xxxxxxxxx> writes:

Wes> Hi all,

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?

But regardless I think we'd like to see this implementation.

Wes> I haven't put a lot of thought into how the general gnu.crypto
Wes> architecture could best accommodate J2ME.  With minor compromises
Wes> it might be feasible to have the existing Rijndael class wrap the
Wes> minimal AES code, so they can both live in CVS and avoid code
Wes> duplication -- J2ME users could just grab the one class.

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> 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?
If so it may be nice to have an implementation using GNU Crypto's key
agreement API.

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.

-- 
Casey Marshall || csm@xxxxxxx


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