TE
TechEcho
Home24h TopNewestBestAskShowJobs
GitHubTwitter
Home

TechEcho

A tech news platform built with Next.js, providing global tech news and discussions.

GitHubTwitter

Home

HomeNewestBestAskShowJobs

Resources

HackerNews APIOriginal HackerNewsNext.js

© 2025 TechEcho. All rights reserved.

Intuiting TLS

34 pointsby azhenleyabout 1 month ago

5 comments

gcp123about 1 month ago
The author did a fantastic job explaining complex cryptographic concepts in accessible terms. I particularly appreciate how it builds up the problem space before introducing solutions.<p>I spent several years implementing TLS in embedded systems, and I&#x27;ve never seen the intuition behind authenticated key exchange explained this clearly. The author manages to capture both the &quot;why&quot; and the &quot;how&quot; without getting bogged down in mathematical notation.<p>The explanation of the man-in-the-middle vulnerability was especially well-done - most articles either skip over this crucial weakness or explain it so technically that newcomers get lost. The starbucks router example makes it immediately obvious why key authenticity matters.<p>One tiny nitpick: the article simplifies by saying &quot;you can&#x27;t know you&#x27;re talking to someone if you don&#x27;t already know who they are&quot; - but this overlooks the role of certificate transparency logs and OCSP, which add significant layers of protection beyond just trusting certificate authorities.<p>For anyone wanting to learn more, I&#x27;d second the recommendation of Julia Evans&#x27; materials. Her zines explain these concepts visually in ways that make this stuff click for many engineers.
jedisct1about 1 month ago
To quickly build something with signatures, key exchange and encryption, I&#x27;d recommend starting with libhydrogen: <a href="https:&#x2F;&#x2F;github.com&#x2F;jedisct1&#x2F;libhydrogen">https:&#x2F;&#x2F;github.com&#x2F;jedisct1&#x2F;libhydrogen</a>
PeterWhittakerabout 1 month ago
Interest article, but overlooks SPEKE, which solves problem #1.<p>There is another protocol for authenticated and integrity protected key exchange, one that solved both the problem of authenticity and integrity attacks, but I cannot recall it.<p>Hoping someone else remembers it.
评论 #43590021 未加载
评论 #43589977 未加载
poloticsabout 1 month ago
the jump between paragraphs 2 and 3 of the &quot;key exchange&quot; section totally lost me, as it does not explain how (K1 op P2) and (K2 op P1) produce a shared secret...
评论 #43591908 未加载
adrian_babout 1 month ago
Nitpick: the claim that digital signatures and certificates are necessary because otherwise &quot;it requires a PSK per website which is impractical&quot;, is false.<p>This claim is very frequently heard, but repeating it does not make it any truer.<p>There are advantages in using digital signatures and certificates, but this is not among them. The main advantage of digital signatures and certificates is that they allow semi-authenticated connections, where only the server is authenticated, but the client is not authenticated.<p>When pre-shared keys (PSK) are used instead of digital signatures and certificates, the pre-shared keys must be used only for the authentication of the key-exchange messages, which are used to establish fresh session keys, exactly like when using certificates instead of PSK.<p>While one implementation option is to store PSKs for all the systems with whom one may want to establish connections, the other option is to store the PSKs on one central server (or on a few servers).<p>When establishing a connection, the two parties interrogate the central server to get the authentication keys that must be used for this pair of communicating parties. While this adds overhead to connection establishment, the overhead is less than checking for certificate revocation.<p>The overhead can be reduced by standard techniques, i.e. caching the authentication keys of frequent communication partners. When done correctly, using PSKs instead of certificates always results in much less overhead for connection establishment.<p>However, as I have mentioned before, while PSKs can be superior for communication inside a closed organization, on the public Internet certificates provide the desirable feature of semi-authenticated connections, where a previously unknown client can still connect securely to an authenticated server.<p>Because all Web browsers must implement certificate-based authentication for communication with public websites, it becomes more convenient to use the same authentication method even inside closed organizations, where using PSKs might have been more efficient.<p>A database with PSKs for pairs of communicating computers is much smaller than a database with certificates when the number of communicating computers is small. Because the number of entries grows with the square of the number of communicating parties, the size of the PSK database will become too large at some threshold, which is the second reason why certificates are better for the public Internet.<p>However, this database size problem exists only when the PSKs are stored centrally. If a computer would store locally either the PSKs or the certificates for all possible communication partners, PSKs would need the same number of entries as certificates, but much less storage, regardless of the number of communication partners.<p>Certificates avoid the storage problem by using a hierarchy of certificates. Similarly, a hierarchical organization of PSK-providing servers could reduce the requirements for storing PSKs in the centralized variant. There is also the variant where the central server does not store PSKs for each pair of communicating nodes, but it generates new authentication keys for that pair, at each request. In general, there are workarounds for any of the possible advantages of certificates vs. PSKs, except for the implementation of semi-authenticated connections.