Cryptographic Libraries | Hacker News Reader

Cryptographic Libraries

developer.apple.com

57 pointsFredericJ13 comments

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.

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.

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

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

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.

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.

Especially since a few implementations are actually borrowed from open-source projects. The 25519 implementations are from DJB's supercop for signing and Adam Langley's Donna for ECDH, both available online with open source licenses.

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.

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

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.

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.

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.

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;...

> 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.

Reply on news.ycombinator.com