An Overview of Cryptography
garykessler.net
garykessler.net
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 signature schemes, if Bob makes a signature using their public/private key, Alice can produce a different private/public key such that Bob's signature will verify under Alice's key.
Paper (we) wrote on the impacts of this: https://eprint.iacr.org/2019/779
EDIT: Looks like this paper is also already included in the list of citations for the 2019 paper :)
https://www.agwa.name/blog/post/duplicate_signature_key_sele...
IIRC: it was missed by both an academic analysis of LE and a 3rd party audit of their crypto design. Thankfully Andrew spotted it a few weeks before they went live in major browsers!
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, this gets a bit more confusing with message key substitution (two public keys, two messages, one signature) or colliding signature (one public key, any number of messages, one signature). For example, a malicious party might produce a signature which is valid for any message. Does the fact that they've "signed everything" mean they can repudiate having signed anything? (The connection between intent to sign and the signature has arguably been lost).
We do discuss these other properties in the paper, but we don't really delve into non-repudiation in the informal sense.
If you really want non-repudiation then you have to have hardware, legal, and procedural controls in place.
Does that mean the previous proofs were wrong? or that they proved a narrower version of "secure" that didn't include those particular attacks?
> 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.
I don't know in what context it would be reasonable even as a simplification to say that block ciphers are semantically insecure like that. Anyone who listed that as a disadvantage to block ciphers should be regarded as confused, not speaking from a big picture perspective.
Furthermore, even if you're going to explain it that way as a result of building up the complexity gradually, you need to explicitly "unring" that bell, e.g. "Earlier I said X, but actually Y...". This author didn't.
I really love this naming system.
And then I chance upon it being talked about on HN. Small world and maybe the universe is telling me something ;-)
Today, I'd expect less focus on RSA and PGP, and instead a mention of elliptic curves, the Signal protocol (double ratchet), etc.
Example: A textbook from '95 had a pretty large section on "the future" of ECC and "current" trends in research. It was interesting seeing what came true, or what was still being worked on.
Could be more appealing if the vanilla html was properly styled though.
How would you improve the page?
body { font-size: 19px; width: 72ch; font-family: Charter; margin: 0 auto; line-height: 1.4; }
and then remove the size= option on the <font> element.