
Beyond public key encryption - wglb
https://blog.cryptographyengineering.com/2017/07/02/beyond-public-key-encryption/
======
grandinj
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.

------
whatnotests
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.

~~~
cyphar
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.

~~~
Tharkun
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.

------
StavrosK
Isn't Keybase basically exactly identity-based cryptography?

~~~
zahllos
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/~dabo/papers/bfibe.pdf)
,
[https://crypto.stanford.edu/~xb/ab09/latticeibe.pdf](https://crypto.stanford.edu/~xb/ab09/latticeibe.pdf),
[https://eprint.iacr.org/2014/794.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-...](https://www.ncsc.gov.uk/articles/using-mikey-sakke-building-
secure-multimedia-services) but their scheme has been criticised:
[https://www.benthamsgaze.org/2016/01/19/insecure-by-
design-p...](https://www.benthamsgaze.org/2016/01/19/insecure-by-design-
protocols-for-encrypted-phone-calls/)

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.

~~~
kurthr
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.

