Reposting the following questions since I have not seen a follow up response yet.
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# Thanks, Rob -----Original Message----- From: David Fisher [mailto:[email protected]] Sent: Thursday, February 04, 2010 12:16 PM To: Robert Hafner Subject: Re: Legal concerns/questions with exporting/importing Apache Poi 3.5 Rob, We, the POI developers, are rather busy with our day jobs at the moment plus Yegor is off to Bavaria for a cross-country ski marathon. I expect that we will have clarification by next Tuesday at the latest. Sorry for the delays. Regards, Dave On Feb 4, 2010, at 8:35 AM, Robert Hafner wrote: > > 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# > > 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] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
