-
Notifications
You must be signed in to change notification settings - Fork 6
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
CocoaPods support #5
Comments
Related issue: jedisct1/swift-sodium#173 |
@aidantwoods Do you have any thought about this? It looks like specifying nonces when performing AEAD has been made optional in |
Apologies for letting this linger a little. I think your assessment in 517624c#commitcomment-31681166 is correct: I had actually missed that the RFC text changed to make this optional, so yes I think we could drop I also would prefer not to depend on One thing dropping |
So I'm just taking another look at this. Issues with unit testing aside, there's actually a blocking issue: the PASETO spec essentially requires deterministic encryption to be available via the necessity that the nonce that will be used for encryption is known prior to providing the additional data (used to calculate the value returned by swift-paseto/Sources/Paseto/Implementations/Version2/V2Local.swift Lines 36 to 41 in 517624c
This obviously means that (using what's available in the swift-sodium API), something like let (cipherText, nonce) = sodium.aead.xchacha20poly1305ietf.encrypt(
message: message,
secretKey: key.material,
additionalData: ...
) isn't going to work: since we can't yet calculate the value for the |
@aidantwoods You don't need the nonce, you can use random bytes as defined in
The confusing part is "If this step is omitted, the output of step 2 is "n" instead." This simply means that "n" is a nonce, not the nonce used to encrypt the payload. @paragonie Could you rewrite steps 2-3 and merge these two options together to make this more obvious? |
This still won't work because I need to use the same random bytes for the value of |
Could you open an issue on PASETO's repository? You might be able to better describe the problem than me. |
Thanks for opening that—I'm not entirely sure if the revised wording in |
Oops, I didn't mean to let this sit for so long. I think we should presume that the spec won't change to accommodate using non-deterministic aead variants. I noticed you added a |
Have you already tried supporting CocoaPods?
As far as I have tested, the only complicated point is the direct dependency on Clibsodium which is needed for 2 functions:
crypto_aead_xchacha20poly1305_ietf_encrypt
andcrypto_aead_xchacha20poly1305_ietf_decrypt
.Is there a reason why the
Aead
extensions from Swift-Sodium could not be used in place of these 2 functions?The text was updated successfully, but these errors were encountered: