5 ms·

The article is not that different than "don't invent your own cryptography". It's hard to understand for non-crypto specialists. It uses notions which are unkn

The article is not that different than "don't invent your own cryptography". It's hard to understand for non-crypto specialists. It uses notions which are unknown to most programmers like MAC or other *MACs. So not sure who is the target audience for this.

olliej 2y ago
It is essentially “don’t roll your own crypto”, but instead being screeds of complexity it just highlights a few very basic and simple things that seem “obviously fine” to folk that are unfamiliar (eg doesn’t touch on any complex reasons for it being bad, and doesn’t just say “you’re stupid”). It then gives examples of these basic problems causing real world failures, and it then just says “this is what you should use instead”. Eg it’s very to-the-point, doesn’t spend all its time talking about how the professionals are awesome and better than you, and gives actionable recommendations. Most “don’t roll your own crypto” articles don’t do that and just come off as being elitist, and don’t actually _help_ the reader.
tptacek 2y ago
Trail runs a cryptography practice that does assurance work for cryptography engineers. They're not writing to encourage randomly-selected HN readers to design their own cryptosystems.
yarg 2y ago
It was simple enough for me as a non-crypto guy - in fact, it seemed mostly obvious.
deleted 2y ago
[deleted]
inopinatus 2y ago
The problem with the general assertion, "don't roll your own crypto", is the potential for implicit-misconstruction-by-contrast of professionally rolled cryptography being a pluggable, install-and-forget black box solution. This is of course bunk, because the boundary layer and level of abstraction matters, and the apparent target audience for this content marketing piece is any developer that might fall into the trap of assuming otherwise. The selection, integration, and configuration of cryptographic elements into an application carries as much significance for the strength of the resulting cryptosystem as the cryptographic qualities of the elements themselves, especially when considered by an attacker that seeks to drive a wedge into any gap available. The article is obviously far from a comprehensive survey on the topic but does zero in on a few of the practical cases for hash functions, although you're not obliged to necessarily draw the same conclusions since (as the comments in these threads reveal) there are more alternatives than those directly discussed.

olliej 2y ago

It is essentially “don’t roll your own crypto”, but instead being screeds of complexity it just highlights a few very basic and simple things that seem “obviously fine” to folk that are unfamiliar (eg doesn’t touch on any complex reasons for it being bad, and doesn’t just say “you’re stupid”). It then gives examples of these basic problems causing real world failures, and it then just says “this is what you should use instead”. Eg it’s very to-the-point, doesn’t spend all its time talking about how the professionals are awesome and better than you, and gives actionable recommendations. Most “don’t roll your own crypto” articles don’t do that and just come off as being elitist, and don’t actually _help_ the reader.

tptacek 2y ago

Trail runs a cryptography practice that does assurance work for cryptography engineers. They're not writing to encourage randomly-selected HN readers to design their own cryptosystems.

yarg 2y ago

It was simple enough for me as a non-crypto guy - in fact, it seemed mostly obvious.

deleted 2y ago

[deleted]

inopinatus 2y ago

The problem with the general assertion, "don't roll your own crypto", is the potential for implicit-misconstruction-by-contrast of professionally rolled cryptography being a pluggable, install-and-forget black box solution. This is of course bunk, because the boundary layer and level of abstraction matters, and the apparent target audience for this content marketing piece is any developer that might fall into the trap of assuming otherwise. The selection, integration, and configuration of cryptographic elements into an application carries as much significance for the strength of the resulting cryptosystem as the cryptographic qualities of the elements themselves, especially when considered by an attacker that seeks to drive a wedge into any gap available. The article is obviously far from a comprehensive survey on the topic but does zero in on a few of the practical cases for hash functions, although you're not obliged to necessarily draw the same conclusions since (as the comments in these threads reveal) there are more alternatives than those directly discussed.