TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

Intuiting TLS

34 点作者 azhenley大约 1 个月前

5 条评论

gcp123大约 1 个月前
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.
jedisct1大约 1 个月前
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>
PeterWhittaker大约 1 个月前
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 未加载
polotics大约 1 个月前
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_b大约 1 个月前
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.