The email below says that the POI only uses encryption (RC4) to read password protected workbooks . . . * Does this encrypt the password (or other file protection data) only or does it also encrypt the contents of the workbook? * What is the strength (or key length) of the algorithm as implemented . . . usually between 40 and 128 bits? * Has this use been reviewed by BIS? If so, is there a CCATS#?
In future releases of Poi, is it possible to split this functionality into a separate jar? Thanks, Rob -----Original Message----- From: Yegor Kozlov [mailto:[email protected]] Sent: Friday, January 22, 2010 1:04 PM To: POI Developers List Subject: Re: Legal concerns/questions with exporting/importing Apache Poi 3.5 > One of our product teams has expressed an interest in upgrading to Apache Poi > 3.5. I also expect other products to express an interest in future releases. > During the third party review process our Legal department expressed some > concern regarding Poi's cryptography notice > (http://poi.apache.org/legal.html) and its classification as 5D002.C.1 under > ECCN. This classification requires us to report all exports of the product > (and our products containing the product) twice each year. This is an > administratively intensive task for our Legal Department and not one we are > currently equipped to handle very efficiently. Therefore we are looking for > a solution which allows our products to upgrade to v3.5 without placing an > additional burden on our Legal department. Can you answer the following > questions which should help us decide what options we have available? > I think this Cryptography Notice is outdated. At some point we attempted to use javax.crypto and javax.xml.crypto packages for implementation of Digital Signature support in OOXML documents. The initial patch was checked-in but then reverted until we have consensus on legal and patent issues. The Java code was reverted but the notice remained. > Legal Questions: > 1) Does Apache Poi 3.5 use the java.security and javax.crypto packages > from the JRE, JCE, or a different product? If it is the JRE packages, then > why is the Apache product classified as 5D002. Based upon our legal > department's analysis the JRE is classified as 54992 (which is a more > favorable classification that does not require reporting). At the moment POI does not use any of javax.crypto classes. We have our own implementation of RC4 which is equivalent to the RC4 cypher from javax.crypto - we use RC4 to read password protected workbooks. This implementation is based on public information and was inspired by Wikipedia's RC4 article http://en.wikipedia.org/wiki/RC4. The only class that POI uses from java.security is MessageDigest. As far as I know it is not classified by the US export regulations. > 2) Has the Apache Poi product been reviewed by BIS? Does it have any > CCATS#? If Poi 3.5 has been reviewed, was any type of reporting exception > granted in the review? > > Technical Questions: > 1) Would it be possible to obtain a copy of Apache POI 3.5 that does not > have the encryption (or encryption calls)? Or could we build our own version > (without the encryption support)? Yes, it is possible. The source code of POI 3.5 ( and any other releases) is publicly available and if you want, you can root out the encryption classes, the Apache license allows you to do it. Regards, Yegor > > Thanks. > Rob > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
