Hacker News Reader

Comment by James_K | Hacker News Reader

> A rather delightful property if you want to attack anonymity in some proposed “everybody just uses cryptographic signatures for everything” scheme.

I don't follow. Surely the entire point of a public key is that it's public, and the point of signatures is to show that something belongs to you. An anonymous signature makes no sense, because signing something is putting your name on it. If you wanted to be anonymous in the sense that your public key cannot be recovered from a message, you wouldn't sign the message.

View on HN

> the point of signatures is to show that something belongs to you

Which is exactly the point. Since a signing public key is (somehow) tied to an identity, then being able to recover a public key from signatures means that if you can read signatures then you can know who is sending messages.

Consider a scenario: I send my girlfriend secret encrypted messages in the middle of the night that look like this: [encrypted message | ECDSA signature]. My messages are a secret, and my girlfriend can know that they are definitely from me. But my wife captures a bunch of messages and uses Sophie's handy decoder ring to see that - oh hey - it's me sending those messages!

There were a few mistakes made in this scenario - one of which was some protocol designer leaving a vulnerable signature on the outside of the encrypted message, leaking the sender's identity to anyone that can see the message.

Sounds like the problem here is using the wrong tool for the job. Signatures are designed to prove who sent the message. If you want to hide who sent the message, you need something else. In your example, you would take an extra step of encrypting the message with your girlfriend’s public key so only she can decrypt it and then verify it came from you.

Well, the problem could be that you are taking a less useful definition of the purpose of a signature.

Definition 1 (yours): given a message and a signature, you can derive the signing key and prove whether that key signed the message.

Definition 2 (sophie's): given a message and a putative signing identity, you can prove whether the given ID signed the message.

Since you are always free to include identity with the message, the second definition has a strictly greater scope of application.

Okay, but suppose the signature wasn't reversible, you can still just run the signature against your public key to check. The nature of a signature is that it can be easily identified as originating from you.

Yes, but the public key does not actually, contrary to its name, have to be known to the entire world.

As the article shows, in many signature primitives it's necessary to assume it is (or at least visible to everybody able to view plaintext message-signature pairs signed by the corresponding private key), but primitives that don't have this property might be usable as native (and by extension more efficient) designated verifier signature schemes.

Strictly speaking, as normally used, the nature of a signature is that given a message, a public key and a signature, you can determine whether that public key produced that signature for that message. The public key is an input.

For some algorithms, as Sophie described, the public key is a redundant input.

But it is reasonable to use the more strict definition and ask when the public key is redundant.

For many current applications, the input is really a message, a signature and the identity of the sender. You are expected to look up the public key with the identity in a global table and follow a chain of signatures back to one of a few trusted roots. In such applications, the public key is obviously apparent in the message itself, but there are many applications where you would like some measure of anonymity. In those cases, all you get is a proof that SOME valid key signed the message in question, but you can't know WHICH key.

An anonymous signature indeed makes no sense, but not everything needs a signature. Identification is an example for that:

In many scenarios, you (Alice) want to identify yourself to somebody (Bob), but you don't necessarily want Bob (or somebody hacking their database!) to be able to go to an unrelated third party (Charlie) and prove to them that Alice transacted with Bob.

The technical term for that property of digital signatures is non-repudiation, and some schemes go to some lengths to specifically avoid it, e.g. by using Diffie-Hellman key exchanges to prove ownership of a key without yielding a third-party verifiable proof of that exchange having happened.

For example, ICAO biometric passports specifically switched from public key cryptography and challenges (Active Authentication) to a Diffie-Hellman based scheme (Chip Authentication) because non-repudiation was considered a privacy risk as biometric passports were never intended as a signature mechanism.

Well in that case, Alice still needs a public key. The real issue is if the plain text of the signed message is leaked, at which point someone interested in Alice's message history can just go through the leaked messages and see which ones correspond to Alice's key. No need to reverse engineer the key from the message.

Yeah, one should definitely not assume that any signature scheme yields signer confidentiality out of the box, nor a non-signature-based, repudiable authentication scheme for that matter.

Some systems require things being signed, but don't care for who signed it. E.g. the open source pro bono Maven/Java library repository.

I think it serves the purpose of ensuring integrity with no requirement for revamping revealing the identity.

Not sure about that exact scenario, but a digital signature scheme without a set of trusted keys/signers seems pretty useless: If it's about e.g. detecting tampering of large files, a hash function achieves the same result much more efficiently.

One thing it can be used for is continuity of authorship, though, I suppose: “v2 is by the same pseudonymous person that published v1”.

I believe that was the point they were making.

That's not the same as "not caring for who signed something" though, if you think about it: "Whoever holds the same key that signed this package" is still an identity, if a pseudonymous one.

But if you don't care who signed it, then you won't even notice if it was/wasn't signed by the same key. That's what I got out of what they were saying. As in, 'this whole charade is pointless ... but it does solve this somewhat tangentially related problem ... kinda'.

> "Whoever holds the same key that signed this package"

This only matters if you care or know what the keys are. If your guards let anyone in with a blue pass, it doesn't matter what the name is on the pass or if it even matches the name of the person.

If nobody cares at all who signed a message, you don't need a signature scheme.

> 'this whole charade is pointless ... but it does solve this somewhat tangentially related problem ... kinda'.

I'd assume it isn't – why else would they be doing it (other than for compatibility with some package distribution scheme that, for other use cases, enforces the existence of a signature, which is arguably just a special case of "you don't need a signature scheme").

I don't think that works.

Attackers could generate a key and sign a hacked artifact. Yes, somebody signed that artifact you might say, but I would worry who signed it and how much I should trust them.

> An anonymous signature makes no sense, because signing something is putting your name on it

No, signing something puts a name on it.

And frankly not even a name, it just tells you whoever signed it had access to the same private key data

Reply on news.ycombinator.com