Hacker News new | ask | show | jobs
by defiancedigital 3728 days ago
I'm looking at libaxolotl-c. I'm a little bit disturbed about perfect forward/future secrecy. Perfect forward secrecy ensure that a session key cannot be compromised if a long-term key is compromised in future. With something like OTR even if a session key is compromised at n, session key at n-1 or n+1 will not be compromised. Here, we got perfect forward/future secrecy.

If i take a look at axolotl, in scenario Alice send message to bob when Bob is offline:

(1) , (2)

MK = HMAC-HASH(CKs, "0") // (3)

msg = Enc(HKs, Ns || PNs || DHRs) || Enc(MK, plaintext)

Ns = Ns + 1

CKs = HMAC-HASH(CKs, "1") // (4)

return msg

We can see that Alice re-use CKs to get a new symmetric key. So if an attacker get CKs(n) he could easily compute CKs(n+1) CKs is not a long term key, but we cannot honestly call this _perfect_ futur secrecy... One more thing, if I remember correctly, according of perfect forward secrecy definition, an implementation must NOT re-use previous session key to derive a new one ...

I'm wrong ?

(1) Quoted from https://github.com/trevp/axolotl/wiki

(2) see session_cipher_get_or_create_message_keys (https://github.com/WhisperSystems/libaxolotl-c/blob/0640b5ac...)

(3) i think we should read MK = HKDF(HMAC-HASH(CKs, 0x00) see ratchet_chain_key_get_message_keys (https://github.com/WhisperSystems/libaxolotl-c/blob/0640b5ac...)

(4) i think we should read MK = HMAC-HASH(CKs, 0x02) see ratchet_chain_key_create_next (https://github.com/WhisperSystems/libaxolotl-c/blob/0640b5ac...)

2 comments

"Perfect forward secrecy" requires synchronous key exchange. The compromise that signal protocol makes is for forward secrecy to "eventually repair" itself while in the meanwhile a limited number of messages are potentially vulnerable. That is one of the novel feature of the protocol and it is what allows for async communication without some central server doing all the key mgmt (central key mgmt doesn't have this problem because it's actually synchronous).

I am not a cryptographer.

"Eventual forward secrecy"?
Perfect forward secrecy is actually the opposite of what you mentioned.

"In cryptography, forward secrecy is a property of secure communication protocols in which compromise of long-term keys does not compromise past session keys."

https://www.wikiwand.com/en/Forward_secrecy

If someone were to compromise your key and they had a packet log of all your communication then PFS, which Signal has, guarantees that they wouldn't be able to derive previous keys from the current key to decrypt previous messages from the packet log that came before the key compromise.

The thing you're talking about can be resolved by revoking compromised keys but knowing when to revoke those keys is a whole other problem that hasn't been solved by anyone to my knowledge...