Beyond public key encryption | Hacker News Reader

Beyond public key encryption

blog.cryptographyengineering.com

105 pointswglb12 comments

If crypto researchers would try working on actual user facing software they would probably come up with more useful designs. As the moment (1) you have to be insanely smart and careful to implement any reliable crypto (2) the crypto needs constant updates because researchers initial ideas are always full of weird unexpected holes (3) virtually all proposed crypto comes with multiple human interaction fails.

I wish it were better, and I completely understand that it's tough to both research higher order mathematics and keep in mind human level interactions, but without something like that , I think we're going to stay stuck with the current state of overly technical, fragile, normal-user-hostile tech.

Using something unchangeable (such as one's retina) to derive a key for encryption sounds like a great idea, until the key must change.

You can't change your retina so easily.

The problem is that you don't want something too unchangeable because if the derived key is somehow discovered (or you get your retina scanned when entering a country -- which happens in Australia, the US, Japan and quite a few other places) then you cannot change your keys and you're stuck with useless keys. To resolve this you have to devolves it an elaborate PBKDF using your retina as a salt.

Personally I really dislike the concept of identity-based crypto, mainly because it make anonymity much harder. Keybase is very clever in how they attempt to solve the identity-based problem, but I'm not convinced if it actually makes this any more secure than just using WoT.

And then there's the part where people lose or damage fingers or retinas. Accidents happen. Your crypto may not be the first thing that comes to mind when you suffer injury, but it's a real problem in any population large enough.

The key (literally and figuratively) is in the trust of the biometric reader.

Not only that... everyone in the street can see your eye, and high quality photo's might provide enough data to leak the key without you knowing. Same goes for stuff like fingerprints, you leave them everywhere you go.

Edit: typo

The exactly implementation doesn't seem clear, but looks to my uneducated eye like this is still an oracle, but one that could be replicated rather than requiring key escrow with an intermediate knowing the keys. I'd assume that you could add salt & pepper (as with password generators) to create new keys... but then you would still have to pass those to the oracle (e.g. using the oracle's public key, which you could reasonably know) and trust the oracle to generate them correctly.

Like password generators you could have many public keys (eg one for each recipient's public key and an advertised pepper that increments with each message) from your single biometric or even including adress, time, or place.

I just don't see how any oracle that you don't control access to isn't susceptible to compromise. I also don't see how the biometric is better than a memorized public key (or salt) other than you can't lose it, since spoofing the biometric will still be possible.

Correct me if I'm off base here.

Some people can

Isn't Keybase basically exactly identity-based cryptography?

Not in academic terms, no. tl;dr IBE refers to a specific process of mathematically using identifying data as a public key like a phone number or email.

As always with cryptography you have a key exchange/identity binding problem: if you receive my public key, how do you know it actually came from me? There are a few solutions to this problem:

1. Certificate authorities do an ID check (domain or extended validation). You know the cert is valid because (in theory) the CA doesn't sign unless it too is convinced and you trust them to do a good job (there's a whole history of CA issues and implementation problems I won't discuss further here - this is by and large the concept). 2. Web-of-Trust/Keybase - the valid key is signed by enough other people you trust / signs enough other public statements from accounts you trust you don't think MITM can happen. 3. Compare hashes (fingerprints) - OTR, OMEMO, Signal, WhatsApp, ZRTP et al. You have the right key because you trust the digest function. 4. Authenticated Key Exchange e.g. PAKE, SPAKE, NAXOS etc.

IBE solves the key exchange problem a different way - what if your public key was some identifiable piece of information (not necessarily biometric as others have suggested, but) e.g. an email address or telephone number? To realise this you need a key management server to go from these public keys to a private key, via a protected master secret and other global parameters, see https://crypto.stanford.edu/~dabo/papers/bfibe.pdf , https://crypto.stanford.edu/~xb/ab09/latticeibe.pdf, https://eprint.iacr.org/2014/794.pdf for example (Boneh's was the first discovered IBE scheme). In this system, you transform the identity piece of data into a public key and only the user in possession of the private key from the master authority/key management server should be able to decrypt it, assuming they global domain parameters are trusted.

The advantage here is that assuming, for example, you work in a government department and have a government supplied telephone you do not also need to verify key material for the user at the other end - you can derive an appropriate public key simply by typing in their telephone number, which you do when you initiate a call. Users no longer need to think about key material or activating "secure mode" or whatever might be required to make an encrypted telephone function. So far as I know at least the UK's GCHQ are keen: https://www.ncsc.gov.uk/articles/using-mikey-sakke-building-... but their scheme has been criticised: https://www.benthamsgaze.org/2016/01/19/insecure-by-design-p...

The downside from everyone else's point of view is that the key management server / master authority can derive private keys for all users of the system. The article mentions certificate-less cryptography as a potential solution, however, you need to distribute (the non-IBE) part of the key, bringing you back to 1-4 above.

Ah, I see, so it's a defined term. Makes sense now, thank you.

Thanks, that's helpful. There is, in fact, still a trusted (e.g. gov) oracle required. If you could somehow calculate in an open trusted way without giving away the actual keys (and you trusted the original key generation), perhaps you could have a public oracle.

Reply on news.ycombinator.com