7 ms·

Citation?

• dozzie 9y ago
  Have you read the protocol and compared it with techniques used to build any widely used cryptographic transport? I did. Given that this is not point to point protocol, you cannot just assume that the author used stock protocol (TLS or IPsec), because there's no such thing. And unless there was an analysis that confirmed the protocol's strength or the author is a recognized cryptographer, you cannot assume he did a good job.
  • avtar 9y ago
    The parent rightfully asked for a citation for your claim: > hand-rolled protocol riddled with cryptographic errors It's fine if you know of examples but even better if you can provide them so others benefit.
    • dozzie 9y ago
      It was a few years ago, so I don't remember the details, but there were things like lack of integrity protection for control messages sent between nodes or keys with a very long life time shared by all the nodes.
  • cat199 9y ago
    > And unless there was an analysis that confirmed the protocol's strength or the author is a recognized cryptographer, you cannot assume he did a good job. nor can you assume he did a bad job..
    • dozzie 9y ago
      It's a cryptographic product. You have to assume he did a bad job unless proven otherwise.
      • cat199 9y ago
        Assuming a bad job for auditing purposes is not anywhere near the same thing as making a direct assertion that the protocol is 'riddled with holes'
• scottlamb 9y ago
  No citation, but IIRC the tinc 1.0 branch has little/no protection against replay attacks, at least in UDP mode. I recall the 1.1 branch improving the protocol in this regard, though it's been a long time since I looked, and I can't vouch for its overall security. I'm surprised it hasn't been officially released yet; the branch was cut over a decade ago! (Also a little annoyed; I contributed improvements to tincctl back then, and they still haven't been released...)