0

When creating a SealedBox, one of the parameters which needs to be passed is an authentication tag:

https://developer.apple.com/documentation/cryptokit/aes/gcm/sealedbox/init(nonce:ciphertext:tag:)

I have 2 questions about this:

  1. What should this authentication tag be? I have seen quite a few examples online where they simply pass an empty data buffer: Data(). For example here:

https://stackoverflow.com/questions/75916728/getting-authentcationfailure-with-nonce-and-tag-using-cryptokit

they say: "You should not provide a pre determined tag while encrypting."

Is passing an empty data buffer okay from a security point of view?

  1. If I pass something else - lets say some random data - as the authentication tag, how would the person decrypting it know about this tag? Can it be safely sent publicly? How should both parties come up with the same authentication tag?

EDIT:

Here's my encryptedData function which has an authenticating parameter.

func encryptedData(decryptedData : Data, key : SymmetricKey) throws -> Data {
    let sealedMessage = try AES.GCM.seal(decryptedData, using: key, nonce: AES.GCM.Nonce(), authenticating: Data())

guard let encryptedData = sealedMessage.combined else {
    throw "Error in sealedMessage"
}

return encryptedData



}
sudoExclamationExclamation
  • 165
  • 7
  • 1
    The authentication tag is an output in an AEAD scheme that's normally appended to the ciphertext. You send the ciphertext concatenated with the authentication tag. When decryption is performed, the authentication tag will be verified prior to decrypting the ciphertext to check for tampering. Now I don't know anything about Apple CryptoKit, but it looks like you shouldn't be using the Init function but the Seal function for encryption and Open for decryption, as stated here. Seal produces a sealed box. – samuel-lucas6 Feb 01 '24 at 22:47
  • @samuel-lucas6 I have updated my question with my current code for encryptedData. I am using the seal function yes. Apple describes it here. The sealedMessage.combined combines the nonce, authentication tag and the cipher in one. However, I still don't know if passing an empty data buffer to the authenticating is okay? – sudoExclamationExclamation Feb 01 '24 at 22:55
  • 1
    The authenticatedData is the AD part of Authenticated Encrypted with Associated Data (AEAD). Again a stupid naming by Apple people. Look at this picture and search for Auth Data 1. This data is not encrypted however authenticated. Can be used in protocols to clarify the data without decryption. – kelalaka Feb 01 '24 at 23:25
  • See What do associated data and message numbers mean? and What is Associated Data in AEAD? – kelalaka Feb 01 '24 at 23:31
  • 1
    @kelalaka so, if I understand correctly, the authenticationData is actually some additional data which can be authenticated? Can I use it to pass additional information such as "chunk number" and "total number of chunks" when encrypting large files by breaking into smaller chunks? That way, can I use it to ensure order and size of the large file? – sudoExclamationExclamation Feb 02 '24 at 00:00
  • 1
    Yes, that would be one way, as long as nonce / key combination is not reused of course. The nonce does need to change for each chunk anyway otherwise the ciphertext will leak information (CTR may create a many time OTP). – Maarten Bodewes Feb 02 '24 at 01:38
  • @MaartenBodewes I'm thinking of calling this a dupe of the two posts, however, it has two similar questions, one is the authentication tag and the other is the Associated Data ( named authenticatedData by Apple's developers). Couldn't decide.. – kelalaka Feb 02 '24 at 09:46
  • @kelalaka I don't think it's a duplicate. This question arose from the other post. Previously, on a different topic, I was told to start a new question for a new issue. That's what I did. – sudoExclamationExclamation Feb 02 '24 at 13:45
  • Having two questions prevents the duplication as of now! – kelalaka Feb 02 '24 at 13:53
  • @MaartenBodewes Yes, a new nonce will be created for each chunk. This will allow me to ensure the order and total number of chunks. However, I can still think of one remaining problem. Let's say 2 identical sized large files are encrypted this way using chunks. Someone could replace the first chunk of first file with the first chunk of second file as order and number of chunks are the same. How can I prevent that? Can I include the hash of the entire large file in the authenticationData of the last chunk maybe? Or is there a better way? – sudoExclamationExclamation Feb 02 '24 at 14:27
  • 1
    Different keys could be derived for each file. – Maarten Bodewes Feb 02 '24 at 17:57

0 Answers0