Hacker News new | past | comments | ask | show | jobs | submit login
Blind Signature (wikipedia.org)
57 points by rfreytag on Feb 9, 2018 | hide | past | favorite | 9 comments



The "blind ECDSA" in that article is not an ECDSA signature at all. It's a blind schnorr signature.

The article does not mention that the construction there (and ones like it) are vulnerable to a one-more-signature attack if parallel queries are possible-- which is easily a fatal vulnerability in the headline digital cash application for blind signatures.


Please update the Wikipedia article!


That's a good opportunity to update the wikipedia entry :)


It occurred to be that with 2 factor authentication, the server needs to hold on the the secret key. If that is leaked, the 2 factor is useless.[1]

Contrast this with salted hashing where leaking the hash doesn't directly lead to compromise.

Could you use a blind signature to construct a rotating code 2 factor scheme where leaking the server credential doesn't lead to complete compromise?

https://rcoh.me/posts/two-factor-auth


The reason a leaked password is devastating is that passwords are reused, both on the site itself (people will select variants of their old passwords when changes are demanded, and eventually rotate back to the original), and, more importantly, on other sites. This means that a compromise of a database of passwords endangers not just that site but many other unrelated sites.

TOTP and U2F keys aren't cross-site, and they don't occupy any space in the user's brain. They can be treated as ephemeral and effaced and regenerated. So we're not generally that alarmed at the prospect of them appearing on Pastebin, modulo of course the implications that has for the rest of our security.

Almost every realistic scenario in which TOTP/U2F keys are leaked implies that all serverside security has been lost anyways, so protecting the keys themselves is a secondary concern. Any reasonable site operator would invalidate all stored keys after such a compromise.

By the way: salting hashes doesn't really protect against password recovery. In modern systems, it's "stretching" that does the real work. You should be using a modern password hash like bcrypt or scrypt, not simply randomizing a standard cryptographic hash.


I don't agree with the de-emphasis of salting. Salt eradicates time-space tradeoffs. Any successful scheme is going to get used by lots of people which means a time-space tradeoff would be hugely valuable even if you have GPUs or even ASICs on your side.

Even an eyeball test shows the value of salt. Here are 4 million usernames and hashed passwords. Oh, 86000 of them have the same hash. Ok, those 86000 users have some easy to guess password, we'll break that first.


It doesn't really eradicate time-space tradeoffs. It only mildly alleviates them. Please look up bcrypt and why it's better than a simple salt. Noone proposed getting rid of salting without another measure.

And you don't "break a password first". You brute-force and compare against all of the hashes.


bcrypt and scrypt are inherently salted.


> Could you use a blind signature to construct a rotating code 2 factor scheme where leaking the server credential doesn't lead to complete compromise?

Off hand I don't imagine it's possible to do that this way, but there is a challenge-response authentication scheme that does guarantee (if you use it correctly) that compromise of the server credentials does not allow you to impersonate clients to the server. It's called SCRAM-SHA (RFC 5802, RFC 7677) and uses client and server nonces to provide the session uniqueness property (authentications can't be replayed).

Leaking the server credentials (StoredKey, ServerKey) does not lead to compromise (obtaining the ClientKey) under this scheme because StoredKey = H(ClientKey) and reversing H() is hard.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: