Live data from Hacker News

An Overview of Cryptography

garykessler.net

21–30 of 34 posts

Re: An Overview of Cryptography

#21
post #6

"This scheme also provides nonrepudiation since it proves that Alice sent the message; if the hash value recovered by Bob using Alice's public key proves that the message has not been altered, then only Alice could have created the digital signature." This is a common misconception. Just because a signature verifies under Alice's public key, it does not necessarily imply Alice generated the signature. For many common…

> In the process, we find new attacks on DRKey and SOAP's WS-Security, both protocols which were previously proven secure in traditional symbolic models.

Does that mean the previous proofs were wrong? or that they proved a narrower version of "secure" that didn't include those particular attacks?

Re: An Overview of Cryptography

#22
post #21
post #6

"This scheme also provides nonrepudiation since it proves that Alice sent the message; if the hash value recovered by Bob using Alice's public key proves that the message has not been altered, then only Alice could have created the digital signature." This is a common misconception. Just because a signature verifies under Alice's public key, it does not necessarily imply Alice generated the signature. For many common…

> In the process, we find new attacks on DRKey and SOAP's WS-Security, both protocols which were previously proven secure in traditional symbolic models. Does that mean the previous proofs were wrong? or that they proved a narrower version of "secure" that didn't include those particular attacks?

The latter. The tools in question (Tamarin and ProVerif) use a model of signatures that goes back to 2000/2001 which is around when these key substitution properties were discovered. Consequently, they were missed from the models and because the properties themselves aren't that well known, it took a while before it was noticed.

Re: An Overview of Cryptography

#23
post #18

Earlier quoted context omitted.

Btw you don’t mention repudiation in there, but would you say it makes sense to say that most signature scheme actually don’t provide non-repudiation?

It depends what you consider to be non-repudiation! With key substitution, you have a signature that can verify under multiple public keys. However, each key was either honestly generated and used to sign the message, or was maliciously generated and intended to appear to have signed the message. In this sense, the party associated with each public is indisputably associated with the corresponding signature. However,…

It’s also worth pointing out that non-repudiation requires stronger properties than cryptography alone can guarantee. If I surreptitiously leak my private key onto the internet I can later plausible deny that I signed messages. (The Signal protocol deliberately leaks old MAC keys for this reason).

If you really want non-repudiation then you have to have hardware, legal, and procedural controls in place.

Re: An Overview of Cryptography

#24
This is an awesome resource. I am definitely going to bookmark this for future reference. I would also recommend reading Applied Cryptography by Bruce Scheneier. You can pick it up in hard copy or kindle on amazon. This book is considered the most definitive reference on cryptographic techniques ever produced.

Re: An Overview of Cryptography

#25
post #10

I strongly recommend “The Code Book” by Simon Singh. Really readable and very informative!

It's a great read if you're not too in depth on the topic and want an overview, but it is badly in need of a modern revision that removes some of the more speculative parts of the last chapter and replaces it with what actually happened in the last 20 years.

Re: An Overview of Cryptography

#26
"In many of the descriptions below, two communicating parties will be referred to as Alice and Bob; this is the common nomenclature in the crypto field and literature to make it easier to identify the communicating parties. If there is a third and fourth party to the communication, they will be referred to as Carol and Dave, respectively. A malicious party is referred to as Mallory, an eavesdropper as Eve, and a trusted third party as Trent."

I really love this naming system.

Re: An Overview of Cryptography

#27
I may be misunderstanding the author's use of terms here, but this seems wrong (section 3.1):

> A block cipher is so-called because the scheme encrypts one block of data at a time using the same key on each block. In general, the same plaintext block will always encrypt to the same ciphertext when using the same key in a block cipher whereas the same plaintext will encrypt to different ciphertext in a stream cipher.

A block cipher will turn the same plaintext into the same ciphertext only if you're using it with the ECB mode; otherwise, the same plaintext in different places with the same key will encrypt into different ciphertext.

If he means "key" in the sense of "final thing that gets XORed to make the ciphertext", then that's true, but then it's equally true of stream ciphers as well.

Re: An Overview of Cryptography

#28
post #27

I may be misunderstanding the author's use of terms here, but this seems wrong (section 3.1): > A block cipher is so-called because the scheme encrypts one block of data at a time using the same key on each block. In general, the same plaintext block will always encrypt to the same ciphertext when using the same key in a block cipher whereas the same plaintext will encrypt to different ciphertext in a stream cipher.…

I took this to mean "in the simple case" (which would be ECB), but the wording could be improved here to make that clearer.

Re: An Overview of Cryptography

#29
post #28
post #27

I may be misunderstanding the author's use of terms here, but this seems wrong (section 3.1): > A block cipher is so-called because the scheme encrypts one block of data at a time using the same key on each block. In general, the same plaintext block will always encrypt to the same ciphertext when using the same key in a block cipher whereas the same plaintext will encrypt to different ciphertext in a stream cipher.…

I took this to mean "in the simple case" (which would be ECB), but the wording could be improved here to make that clearer.

Right, especially since a few paragraphs down, he introduces all the different modes, including ECB.

Re: An Overview of Cryptography

#30
post #29
post #28

Earlier quoted context omitted.

I took this to mean "in the simple case" (which would be ECB), but the wording could be improved here to make that clearer.

Right, especially since a few paragraphs down, he introduces all the different modes, including ECB.

To me at least, it makes sense to introduce a complex topic gradually, in stages. But regardless, I still agree that the wording in the paragraph you called out could be improved for better clarity.
Post reply on HN