|[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]|
Casey Marshall wrote:
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.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.
I'll make some mods aimed at reconciling it with Rijndael.java and post it.
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> 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.
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.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 keyIt'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.
_______________________________________________ gnu-crypto-discuss mailing list gnu-crypto-discuss@xxxxxxx http://lists.gnu.org/mailman/listinfo/gnu-crypto-discuss
[Home] [Gnu Classpath] [Linux Kernel] [Linux Cryptography] [Fedora] [Fedora Directory] [Red Hat Development] [Red Hat 9 Bible] [Fedora Bible] [Red Hat 9] [Network Security Reading]