[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [GNU Crypto] AES (Rijndael) for J2ME
From: |
Casey Marshall |
Subject: |
Re: [GNU Crypto] AES (Rijndael) for J2ME |
Date: |
Tue, 28 Dec 2004 12:09:26 -0800 |
User-agent: |
Gnus/5.1002 (Gnus v5.10.2) Emacs/21.3 (gnu/linux) |
>>>>> "Wes" == Wes Biggs <address@hidden> 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 || address@hidden