3

The iOS version of Signal application (not the protocol) includes a form of key wrap that I've never seen elsewhere: SHA256-HMAC-SIV.

It's used to encrypt your master key with your pwHash(PIN) before sending it to signal.org's Key Backup Service.

So far as I can tell, it does the following:

SHA256-HMAC-SIV(kek, raw)
kek: key encryption key
raw: original master key bytes

key_auth = HMAC(kek, "auth")
key_enc  = HMAC(kek, "enc")
iv       = Truncate(HMAC(key_auth, raw), 16 bytes)
key_xor  = HMAC(iv, key_enc)


output   = key_xor ^ raw

It derives 2 subkeys, for auth & encryption, like many approaches do. Then it creates a truncated MAC over the raw key for the deterministic IV.

But then it uses the IV as an HMAC key, and the encryption key as the HMAC message to produce a single "block" that they XOR with the raw key.

It seems very clever, but what's the right way to reason about the security overall?

Tim Shadel
  • 161
  • 5
  • 3
    Are you asking why a stream cipher based on HMAC can be considered secure? – forest Jan 13 '23 at 00:45
  • 1
    Yeah, that’s essentially what it is, right? (Wouldn’t have found the words for it without your comment, but it seems obvious now…) It seems fine, but I’m not a cryptographer so I don’t know the model that would be used to show it. – Tim Shadel Jan 13 '23 at 18:02

1 Answers1

3

Yes, it is.

After the comment by forest, I found this other question about building a stream cipher from HMAC in CTR mode. One answer gives a detailed explanation of using any one-way hash function as a stream cipher. Another answer gives quotes from Applied Cryptography about using such a cipher in CFB mode.

See the full discussion here:

Can I use HMAC-SHA1 in counter mode to make a stream cipher?

Tim Shadel
  • 161
  • 5