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

[Wes Biggs]

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