Hi Audrey,
I wanted to thank you about the article and also answering my question. It helped me write my master thesis, where I had to create a Blockchain exchange of data with Swift. I used the cryptokit library and your explanation helped me solve it. Thank you once more.
Hi Dakota, thatās wonderful news. Congratulations!
Hi Audrey
I like your course very much. It helps me. In using the playground I run into an error.
The statement:
let digest = SHA256.hash(data: data)
I receive the following error:
error: Couldnāt lookup symbols:
static CryptoKit.HashFunction.hash<Ļ_0_0 where Ļ_1_0: Foundation.DataProtocol>(data: Ļ_1_0) ā Ļ_0_0.Digest
static CryptoKit.HashFunction.hash<Ļ_0_0 where Ļ_1_0: Foundation.DataProtocol>(data: Ļ_1_0) ā Ļ_0_0.Digest
So, what did I wrong?
Iām using Xcode Version 13.1 (13A1030d) and macOS Monterey Version 13.1 (13A1030d)
Best regards
Urs
thanks Urs! Iām getting the same problem. āCouldnāt lookup symbolsā seems to happen sometimes with 3rd party frameworks or packages, but shouldnāt happen with CryptoKit.
Iām downloading the latest Xcode beta to see if it helps.
update: nope, still canāt lookup symbols
later: doesnāt work in a macOS playground either
In Add Playground to Swift Package - ⦠| Apple Developer Forums
possibly related to having a C package somewhere in the dependency chain
CryptoKit wraps the old C code, so maybe Xcode 13 broke something that interfaces with C modules?
Try going back to Xcode 12? If youāre in the paid developer program, go to the Downloads page and click the More button in the upper right corner. Scroll down to Xcode 12.5. Link I copied from there: Unauthorized - Apple Developer
So it is a problem with the Crypto library ( then I am relieved). I assume that Apple will surely solve this problem.
Thanks for the tip with Xcode 12, I will try it.
This was an extraordinary helpful tutorial. Bravo. And entertaining as well.
I have a question though: Cryptokit distinguishes between EC private keys for signing and key agreement and I canāt see a reason for that. Why is that? The private key is just a big integer in both cases, like with RSA EC public key cryptography works with the same set of public and private key for both use cases, signing and key agreement.
hi Schlueter, glad you enjoyed it :]
I found this explanation about RSA vs EC (Curve 25519 is an implementation of Elliptic-curve Diffie-Hellman):
The nature of the Diffie-Hellman key exchange, however, makes it susceptible to man-in-the-middle (MITM) attacks, since it doesnāt authenticate either party involved in the exchange. The MITM maneuver can also create a key pair and spoof messages between the two parties, who think theyāre both communicating with each other. This is why Diffie-Hellman is used in combination with an additional authentication method, generally digital signatures.
Unlike Diffie-Hellman, the RSA algorithm can be used for signing digital signatures as well as symmetric key exchange, but it does require the exchange of a public key beforehand. However, recent research has demonstrated that even 2048-bits long RSA keys can be effectively downgraded via either man-in-the-browser or padding oracle attacks. The report suggests that the safest countermeasure is to deprecate the RSA key exchange and switch to (Elliptic Curve) Diffie-Hellman key exchanges.