On 4 May 2017 at 17:21, Brian Smith <[email protected]> wrote: > 3. As RFC 6979 notes, RFC 6979 invalidates the proof of security for > ECDSA. This is a step backward from recent progress towards provable > security of internet protocols.
I just want to make sure I understand this point. Skimming the draft I gather this is because the proof of ECDSA relies on k being indistinguishable from the output of a Random Oracle? Deterministic generation of k uses HMAC_DRBG which sure looks like the ROM, but isn't (?) provably so? Assuming I understand - when you implement ECDSA you don't get to use a RO, you use a CSPRNG which also doesn't count as a RO so that probably invalidates the proof. So one assumes the CSPRNG behaves like the ROM, so why don't you just assume HMAC-DRBG behaves like the ROM and your proof is repaired! On 5 May 2017 at 04:02, Eran Messeri <[email protected]> wrote: > I'd like to hear the opinion of people who've worked on the Gossip protocol > - as Brian said, the purpose behind deterministic signatures is to make it > difficult to fingerprint individual clients. However, the only gossip that's > taking place right now is STH exchange between monitors, where this is not a > concern, All of Brian's points are strong points. My concern with fingerprinting still stands though. While not Gossip - Google plans to resolve inclusion proofs for SCTs via DNS. The end DNS server for this is their own log mirror - but I believe this is for scaling, not privacy. If a log and server colluded to issue and serve different SCT signatures for the same SCT, there are no great options to detect it: - very complicated logic in the client - auditors performing aggressive fake-client spidering from multiple network vantage points combined with significant refactoring and data storage requirements - the SCT Feedback part of the Gossip draft combined with the auditor changes As far as the concern of this attack goes: without long-term storage of the SCT (such as that in SCT Feedback) - the impact is minimal when it comes to log+webserver-collaboration-for-tracking. But the log is still able to send different SCTs out and can do this without the server participating. With the distribution part outside the log's control it's not as effective, and more turns into a game of "I wonder what happens...". (I think.) Anyway, so I still think there's fingerprinting concerns. But even if we require deterministic signatures - if the log *wants* to be malicious, it can still issue non-deterministic signatures, and there's no way to know, because as I said above - detection is hard. So I think Eran's suggested changes are okay. -tom _______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
