* PolarSSL is dual-licensed (GPL + commercial) --> nope
* the Crypto++ is licensed via Boost ( a C++ library license)
I am not sure if for JBoss the license is OK, but.... the ASF is OK with
using that license..... (see  and ).
regardless the _technical_ issue is: C++ based... so the integration is odd;
On Fri, Oct 11, 2013 at 11:24 AM, Corinne Krych <corinnekrych(a)gmail.com>wrote:
Discussing with iOS team with all possible options taking into account OS
licenses and encryption algorithms coverage, we'd like to move forward
investigating openSSL srtarting with this interesting entry point:
We'll tell you more soon.
On Oct 10, 2013, at 9:36 PM, Corinne Krych <corinnekrych(a)gmail.com> wrote:
> According to
> CBC is supported.
> Maybe it's worth investigating OpenSSL vs PolarSSL iOS support.
> Interesting work dto dig further
> On Oct 10, 2013, at 8:39 PM, Bruno Oliveira <bruno(a)abstractj.org> wrote:
>> Aloha, looks like Apple wants to hide all the good crypto! Have you got
>> the chance to look at this? https://github.com/rnapier/RNCryptor
>> see some developers using OpenSSL as an alternative. My suggestion:
>> a) If you think this item is tricky to implement atm consider AES with
>> CBC or AES with CCM (We can support it on the server if necessary). I
>> was trying to find which modes is currently supported but looks like the
>> documentation is super safe, because I can't find it
>> b) It can be done with OpenSSL in the worst case scenario (not saying is
>> a piece of cake to do, just possible). Let's start simple first.
>> Regarding http://www.cryptopp.com/
looks like they have all that we
>> need, maybe worth to take a look at this. What do you think? Off the top
>> of my head I only can see 3 alternatives:
>> 1- Implement encryption with what CommonCrypto provides
>> 2- Try cryptopp or another alternative
>> 3- Implement it with OpenSSL. For example SilentCircle make use of
>> not saying to do the same, just an example.
>>> Christos Vasilakis <mailto:email@example.com>
>>> October 10, 2013 2:29 PM
>>> Hi team,
>>> I am digging on the CommonCrypto API and I found some issues.
>>> a) GCM mode for AES symmetric encryption is part of a private API.
>>> See  the public interface of the current definitions of supported
>>> modes of operation. 'kCCModeGCM' is missing _although_ digging on
>>> source code of the apple's web site it is defined in 
>>> (The file is included from a private interface here ). Also here
>>> is the implementation of the GCM mode in  and test cases that
>>> exercise it . Not sure why Apple left it out in public. On my
>>> search, one area in which they use this mode is on the KeyChain from
>>> iOS 5 onwards, see 'KeyChain' section here 
>>> b) Generation of asymmetric ECC keys and encryption is supported by
>>> CommonCrypto but _again_ under a private interface, see  and .
>>> ECC is used in the protection class
>>> 'NSFileProtectionCompleteUnlessOpen' according to the iOS Security
>>> here . In the meeting there was a plan B for it, RSA with Diffie
>>> Hellman. I am looking at it, but to my current knowledge is supported
>>> if you trust the apple docs here 
>>> My worry is how can we proceed with the first issue.
>>> As a side note, during my search I discovered Crypto++  , which
>>> seems to offer many of the features we are trying to support. Con is a
>>> C++ interface although an iOS distribution of it exists (see ),
>>> and there is an iOS wiki page in the library home page . Needs
>>> more research.
>>>  http://esec-lab.sogeti.com/post/iOS-5-data-protection-updates
>>>  http://www.apple.com/ipad/business/docs/iOS_Security_Oct12.pdf
>>>  http://www.cryptopp.com
>>>  https://github.com/noloader/cryptopp-5.6.2-ios
>>>  http://www.cryptopp.com/wiki/IOS_(Xcode)
>>> aerogear-dev mailing list
>> aerogear-dev mailing list
aerogear-dev mailing list