I'm not even sure the block chaining method counts. The 8-bit Cipher Feedback (CFB) might not matter either, though that is probably obtained from a library anyhow.
- Dennis -----Original Message----- From: Dennis E. Hamilton [mailto:[email protected]] Sent: Monday, January 23, 2012 17:35 To: [email protected] Subject: RE: Let's discussion on the next release I don't think PBKDF2, SHA1, and HMAC are considered encryption methods. That should be checked but it may be that the encryption algorithms are only the ones that are used with the derived key (Blowfish, AES, etc.). -----Original Message----- From: Rob Weir [mailto:[email protected]] Sent: Monday, January 23, 2012 17:30 To: [email protected] Subject: Re: Let's discussion on the next release On Tue, Jan 17, 2012 at 5:58 AM, Nick Burch <[email protected]> wrote: > On Tue, 17 Jan 2012, Devin Han wrote: >> >> Yes, but we can't do it parallel, as before complete (1) we can't commit >> the code to the master repository. >> see: http://www.apache.org/dev/crypto.html > > > If some pulls together the info needed for the notification, and confirms > that it's going to be covered by ECCN 5D002 (mostly confirming that we're > using someone else's crypto, rather than writing our own, but check!), then > I'll do the notification and listing for this. > I think Devin's encryption code is a mix. It calls into the Java crypto API for most stuff, but there was one particular algorithm that ODF requires that Java did not have in a form we could use. ODF required that a SHA1 digest of the password (a byte array) be run through the PBKDF2 algorithm to generate the key. Java crypto does have the PBEKeySpec class, but it takes a character array, not a byte array. If you try to convert the byte array to a char array you'll get random encoding errors since in the general case the byte array has combinations that are not legal Unicode characters. So, Devin ended up writing his own PBKDF2 routine per RFC 2898. > Nick
