On Jun 11, 2014, at 8:01 PM, Devarshi Kulshreshtha
wrote:
> Because of all the problems I faced I finally decided to use a third
> party library - Chilkat
I’m skeptical of using any non-open-source crypto code, since there’s no way to
do peer review on it, and that kind of auditing is pretty
Because of all the problems I faced I finally decided to use a third
party library - Chilkat
Here is the link: http://www.chilkatsoft.com/crypt-objc.asp
On Mon, May 19, 2014 at 10:56 PM, Jens Alfke wrote:
>
> On May 19, 2014, at 3:06 AM, Devarshi Kulshreshtha
> wrote:
>
> 5. Used - wrapSymmetri
On May 19, 2014, at 3:06 AM, Devarshi Kulshreshtha
wrote:
> 5. Used - wrapSymmetricKey:keyRef: method defined in SecKeyWrapper
> class (CryptoExercise example) for encryption, and passed key obtained
> from step 3 and data to encrypt obtained from step 4 to it
I think you’re misusing wrapSymme
This is what I am trying to achieve from some days now:
Approach #1:
~ Android End ~
1. Generated public and private key at an android device (using an
openssl wrapper)
2. Got modulus and exponent from the generated public key
~ iOS End ~
3. Generated public key from modulus and exponent, at ios
Keychain is okay, I just cannot bear the crypto libraries.
Sent from my iPhone
> On May 17, 2014, at 1:08 AM, Jens Alfke wrote:
>
>
>> On May 16, 2014, at 12:37 AM, ChanMaxthon wrote:
>>
>> I got fed up by Apple already and found a little BSD-licensed CXX crypto
>> library called Botan. I w
On May 16, 2014, at 12:37 AM, ChanMaxthon wrote:
> I got fed up by Apple already and found a little BSD-licensed CXX crypto
> library called Botan. I will either wrap it in Objective-C or rewrite it for
> my later projects.
I’m cautious of ‘alternative’ crypto implementations; there’s a lot o
I got fed up by Apple already and found a little BSD-licensed CXX crypto
library called Botan. I will either wrap it in Objective-C or rewrite it for my
later projects.
Sent from my iPhone
> On May 15, 2014, at 8:00 PM, Roland King wrote:
>
> I try not to 'screw' the Apple crypto libraries, I
I try not to 'screw' the Apple crypto libraries, I use them where possible and
file bug reports to improve them where they are lacking.
Lots of people do end up embedding OpenSSL, a fact not lost on the recipients
of bug reports I'm sure, I've thus far managed not to have to. I'd prefer Apple
* Correction: GNUTLS depends on GNU MP which is already included.
Sent from my iPad
> On May 15, 2014, at 7:46 PM, ChanMaxthon wrote:
>
> Eh screw the OS X/iOS crypto libraries... I would just embed my own copy of
> OpenSSL or GNUTLS myself. (My toolkit library have already included GNU MP,
>
Eh screw the OS X/iOS crypto libraries... I would just embed my own copy of
OpenSSL or GNUTLS myself. (My toolkit library have already included GNU MP, the
library GNUTLS is based on) Or if I really have the time reimplement RSA
algorithms and key generation using Acceleration.framework
Sent fr
On 15 May, 2014, at 7:25 am, Jens Alfke wrote:
>
> On May 14, 2014, at 3:48 PM, Roland King wrote:
>
>> I'm just pointing out the advice which is constantly and consistently given
>> by Apple (particularly Quinn) on the developer forum that getting the bits
>> of a private key on iOS is uns
On May 14, 2014, at 3:48 PM, Roland King wrote:
> I'm just pointing out the advice which is constantly and consistently given
> by Apple (particularly Quinn) on the developer forum that getting the bits of
> a private key on iOS is unsupported and subject to change, and to do the job
> on a s
I'm just pointing out the advice which is constantly and consistently given by
Apple (particularly Quinn) on the developer forum that getting the bits of a
private key on iOS is unsupported and subject to change, and to do the job on a
server which you trust and return the information. Here's on
I agree with Jens, that's why we opted for creating public-private key
pair on device itself.
On Wed, May 14, 2014 at 8:02 PM, Jens Alfke wrote:
>
> On May 14, 2014, at 7:15 AM, Roland King wrote:
>
>> If you ask a similar question to the original poster on any of the Apple
>> Developer Forums
On May 14, 2014, at 7:15 AM, Roland King wrote:
> If you ask a similar question to the original poster on any of the Apple
> Developer Forums you'll be advised not to generate key pairs on a device but
> to do it on a server (the advice will probably come from Quinn)
That’s a weird idea. If t
On 14 May, 2014, at 9:55 pm, Jens Alfke wrote:
>
> On May 13, 2014, at 9:20 PM, Maxthon Chan wrote:
>
>> I am saying ignore the details of the format, treat certificates as binary
>> blobs or plain strings or whatever that is opaque, and let crypto API parse
>> it.
>
> And I am saying that
On May 13, 2014, at 8:47 PM, Devarshi Kulshreshtha
wrote:
> if CryptoExample is out of date, then what is the other best other
> option for me,
I don’t know, actually; it doesn’t look like they replaced it with any newer
iOS-compatible sample. :(
> from the previous discussion I am unable t
On May 13, 2014, at 9:20 PM, Maxthon Chan wrote:
> I am saying ignore the details of the format, treat certificates as binary
> blobs or plain strings or whatever that is opaque, and let crypto API parse
> it.
And I am saying that’s naïve, at least where Apple’s crypto API is concerned.
I’ve
Or if you don;t mind GNU, you have GNUTLS package that is just as good. GPG can
be dissected and used if you understand how licensing works there.
On May 14, 2014, at 0:56, Jens Alfke wrote:
>
> On May 13, 2014, at 9:33 AM, Maxthon Chan wrote:
>
>> Whatever that is there is, for 100% sure, s
I am saying ignore the details of the format, treat certificates as binary
blobs or plain strings or whatever that is opaque, and let crypto API parse it.
You can ditch Apple API entirely and compile your own OpenSSL if you find it
difficult to use.
On May 14, 2014, at 0:56, Jens Alfke wrote:
@Jens thanks for informing about apple_cdsa list, I am definitely
going to trouble guys over there ;)
I am correcting the steps which I wrote before:
1. SecKeyWrapper *keyWrapper = [SecKeyWrapper sharedWrapper];
2. [keyWrapper generateKeyPair];
2. NSData *publicKeyData = [keyWrapper getPublicKeyB
On May 13, 2014, at 9:33 AM, Maxthon Chan wrote:
> Whatever that is there is, for 100% sure, some form of standardised format
> that iOS, Android and your Java server will be able to deal with with higher
> level API.
*hollow laugh*
There are lots of different standardized formats. It’s just
On May 13, 2014, at 22:20, Devarshi Kulshreshtha
wrote:
> In CyrptoExercise sample provided by apple, we have a wrapper class:
> SecKeyWrapper.
First, I think CryptoExercise is out of date. It’s not included in Xcode 5.1’s
doc set. I found it on Apple’s website, but it looks like it was last
Whatever that is there is, for 100% sure, some form of standardised format that
iOS, Android and your Java server will be able to deal with with higher level
API.
You can just send PEM over and let higher-level API handle it.
On May 14, 2014, at 0:29, Jens Alfke wrote:
>
> On May 13, 2014, a
On May 13, 2014, at 8:55 AM, Maxthon Chan wrote:
> I am not exactly familiar with using RSA but as long as the format is
> followed I believe whatever mechanism here is okay.
This is actually kind of problematic. There are a number of formats for
encoding public keys, and of course they vary
I am not exactly familiar with using RSA but as long as the format is followed
I believe whatever mechanism here is okay. Also if I didn’t made it wrong DER
certificates are text files. Try to dump the NSData and try your Android device
if it can directly recognise it.
On May 13, 2014, at 22:20
Thanks for your suggestions.
I have one specific question:
In CyrptoExercise sample provided by apple, we have a wrapper class:
SecKeyWrapper. In this class we have one method: - (NSData
*)getPublicKeyBits. Shall I use below code to create and send an
encoded string to server:
1. SecKeyWrapper *
Rounding stuff up, there are two broadly-implemented systems: PKCS and PGP.
If you are using PKCS system, you need to operate a CA that your app trusts.
Your server issue issue new keys as certificates signed by your CA. Clients
provide keys using CSR which is confirmed when signed by the server
There are many good container formats for asymmetric keys and public keys can
be handled in plain.
Good formats to use: Certificate Signing Request, self-signed certificate, PGP,
some form of archive formats can also be used like tar(1) or ar(1).
You can also integrate this key exchange into pu
29 matches
Mail list logo
