
Cryptographic Libraries - FredericJ
https://developer.apple.com/cryptography/
======
tptacek
Don't use these libraries for new cryptosystems. They're low-level, and so
very easy to get wrong. And the primitives they expose are mostly outmoded.
Your code will be safer, your crypto will be stronger, and your website will
look cooler if you can tell people you used Nacl/libsodium instead of Common
Crypto.

~~~
FredericJ
Isn't it ironic to see so much inline assembly while Apple is telling third
party devs that they can't distribute binaries on WatchOS and that iOS apps
are moving towards Bitcode too?

Apple's crypto people definitely know that assembly is key in performance and
side-channel resistance of cryptographic implementations. They use it
constantly. I guess at some point they will just ask 3rd party devs to call
corecrypto methods if they want to use encryption in Bitcode apps.

But this means that you'll have to wait for Apple to implement whatever
primitive you need for your app. Good enough in most cases but encryption apps
with special needs will find this annoying.

~~~
tptacek
So far as I can tell, libsodium works on iOS.

Don't write crypto for watches, is what I think.

------
comex
So, Security and CommonCrypto were already open source. The new thing here is
corecrypto - but it has _not_ been made open source! If you click the download
link, you get a license agreement authorizing you to use it only "for the sole
purpose of verifying the security characteristics and correct functioning of
the Apple Software".

I don't really understand the point of not just publishing it under a regular
open source license, since it's hardly some big competitive advantage for
Apple when there are plenty of other libraries to do the same thing.

Still, nice to be able to audit it.

~~~
revelation
Particularly since parts of it are just scavenged together from random other
crypto libraries. A bunch of libtomcrypt code in there.

That's why people use the GPL.

------
mtgx
They didn't bother to remove RC4 from it before doing that? I wonder if they
did any cleanup at all or just released it before the current encryption
backdoor trial concludes.

------
signaler
A mental inventory of bloggers who routinely say they did not hand over their
HD unlock keys to Apple haunts my mind after reading this. Apple are one of
the few tech companies who could throw money at the crypto debate and win some
Internet Points, but they would have to counter the claims of many bloggers
who said they don't trust Apple to guard their unlock keys

~~~
JonathonW
Trusting a company to provide a good client-side encryption implementation and
trusting a company to safely hold encryption keys in escrow are two completely
different issues.

I wouldn't hand over disk encryption keys to Apple no matter how much I
trusted them, purely because they're in a form where Apple could access them
without my intervention, and they could conceivably be legally forced to hand
over those keys by some government entity in the future.

Apple's argument against decrypting iOS devices hinges on the fact that they
_don 't_ retain those keys, and therefore can't decrypt them for the
government.

~~~
signaler
It depends on what you mean by 'key' though. In escrow situations, there is
the likelihood of a very strong key provided by Apple, and a horrendously weak
key provided by the person. What gets a pickle from me is that Apple have some
carte blanche reason to involve themselves remotely in U.S sanctioned soil to
then intermediate the decryption.

~~~
JonathonW
Huh? AFAIK, the only keys which Apple currently holds in escrow are FileVault
2 recovery keys, and those keys are normally only released by request of the
user, in the event of a lost local password (the recovery key's used in place
of the user's key, not in addition to it). Apple isn't "intermediating" any
decryption at any time, because that happens locally on the end user's
machine.

FileVault 2 recovery key escrow is also completely optional-- you don't have
to send a key to Apple at all.

------
FredericJ
Important: The headline was modified since I submitted this. Apple didn't
actually open-source the code. They give you a 90-day licence to read the
code.

> Apple grants you, for a period of ninety days from the date you downloaded
> the Apple Software, a limited, non-exclusive, non-licensable license under
> Apple's copyrights in the Apple Software to make a reasonable number of
> copies of, compile and run the Apple Software internally within your
> organization only on devices and computers you own or control for the sole
> purpose of verifying the security characteristics and correct functioning of
> the Apple Software;...

~~~
dang
> _Apple didn 't actually open-source the code._

In that case you shouldn't have said they did in the title.

We changed the title from "Apple open-sources cryptography library (limited,
see license)". If there's an issue with the license, by all means point this
out, but please use a comment in the thread to do so. Using the story title to
point out what you think is the most important bit breaks the HN rule against
editorializing.

