On 12/28/2015 11:34 PM, Zhenfei Zhang wrote:
1.2 Motivation: Disaster resilience
We are really trying to protect against the disastrous situation of one key
being entirely compromised. By introducing a second cryptographic primitive,
namely, NTRUEncrypt, we ensure that the system remains secure in those
extreme scenarios.
[snipped]
2.1.1 Achieved Property:
[snipped]
2) The proposed key exchange method is disaster resilient: The protocol
depends on two cryptographic primitives. Compromising one does not break
the security of the whole system.
I'm a little confused about what exactly is meant by "disaster resilience" here.
If the disaster is that there's a major cryptanalytic breakthrough against ECC (or, more likely, against NTRU), then I think it would be better to say explicitly that a design goal is that the handshake should be no weaker than either primitive, rather than to say the threat is against "a disaster".
However, the wording in Â1.2 seems to indicate that the goal is to defend against an attacker who can, e.g., obtain a relay's ECC key without also obtaining their NTRU key. Both keys are in the same security perimeter, so I'm not sure what this really achieves in practice.
I think it would be good to remove the word 'disaster' entirely and say what exactly the threat is and what the design goal is: the threat is an attack on one of the cryptosystems, and the goal is that the handshake should be no weaker than either.
Cheers, Henry de Valence _______________________________________________ tor-dev mailing list tor-dev@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev