Neither (A) nor (B) are concerns. In (B), the authors are just unfamiliar with HKDF. HKDF is a standard way to use HMAC for key derivation (RFC 5869). (C) is the observation that you could lie and claim someone else's…
Performance should be in the same ballpark, but I'd rather go with whichever achieves its security level most efficiently. Goldilocks looks good by that metric [1], so I'm curious how a Curve41417 implementation…
Probably a good curve too (nice Mersenne prime, so fast reduction). But I'm not sure it fits into processor words as efficiently as Goldilocks (I'm not an expert here, but someone was trying to explain this to me). But…
FWIW this is on hold until I know for sure what high-security-margin curve to use. I'd like this to be a "one-ciphersuite-fits-all" protocol, which puts a lot of pressure on getting that choice right. In addition to…
"Group messaging" can be done by separately encrypting a message to each member of a group. If you want resistance to traffic analysis check out Pond, which is also using this ratchet: https://pond.imperialviolet.org
Re "become your own CA" - that's basically the idea. The "pin activation" algorithm is intended to make it difficult for a MITM to foist bad pins on clients, and to limit the lifetime of such pins.
Don't think they do that with new features, but not totally sure.
That would be great, we have a mailing list interested people should monitor, we'll definitely let people know once things get far enough for sites to start testing the waters. https://lists.riseup.net/www/arc/tack…
We have support for a"ServerInfo" file checked into OpenSSL. This is a file with PEM blobs that can specify TACK and similar data (e.g. Certificate Transparency) that an OpenSSL server will return to clients if…
Neither (A) nor (B) are concerns. In (B), the authors are just unfamiliar with HKDF. HKDF is a standard way to use HMAC for key derivation (RFC 5869). (C) is the observation that you could lie and claim someone else's…
Performance should be in the same ballpark, but I'd rather go with whichever achieves its security level most efficiently. Goldilocks looks good by that metric [1], so I'm curious how a Curve41417 implementation…
Probably a good curve too (nice Mersenne prime, so fast reduction). But I'm not sure it fits into processor words as efficiently as Goldilocks (I'm not an expert here, but someone was trying to explain this to me). But…
FWIW this is on hold until I know for sure what high-security-margin curve to use. I'd like this to be a "one-ciphersuite-fits-all" protocol, which puts a lot of pressure on getting that choice right. In addition to…
"Group messaging" can be done by separately encrypting a message to each member of a group. If you want resistance to traffic analysis check out Pond, which is also using this ratchet: https://pond.imperialviolet.org
Re "become your own CA" - that's basically the idea. The "pin activation" algorithm is intended to make it difficult for a MITM to foist bad pins on clients, and to limit the lifetime of such pins.
Don't think they do that with new features, but not totally sure.
That would be great, we have a mailing list interested people should monitor, we'll definitely let people know once things get far enough for sites to start testing the waters. https://lists.riseup.net/www/arc/tack…
We have support for a"ServerInfo" file checked into OpenSSL. This is a file with PEM blobs that can specify TACK and similar data (e.g. Certificate Transparency) that an OpenSSL server will return to clients if…