5

Identity-based encryption schemes[*] seem to have great potential in high-latency, delay-tolerant and mobile, ad-hoc networks since they apparently seem to avoid the need for key negotiation and exchanges. Used solely for key exchange, they allow any pair of members in the same group (however you choose to define it) to establish a unique pairwise secret that can be computed by each member up-front and as a function of their respective identities.

However, since each pairing based scheme - that I'm aware of - is predicated on a pre-distribution of some shared secret (e.g., the hashed ID of the agent raised to some secret integer), do any of these schemes offer any significant advantages over, let's say, a simple authenticated Diffie-Hellman (at least for purposes of symmetric key establishment)?

[*] Including pairing-based symmetric-key establishment schemes.

Patriot
  • 3,087
  • 3
  • 16
  • 63
Bill VB
  • 283
  • 2
  • 5

1 Answers1

5

IBE is advantageous over standard asymmetric methods in one aspect, and that doesn't appear to apply in the case you're interested in.

In both cases, IBE and asymmetric methods require an enrollment process (whether to distribute secrets, or authentication data), so there's no real difference there.

However, when Alice wants to send a message to Bob, with standard asymmetric cryptography, Alice and Bob needs to exchange messages (whether to perform a DH exchange, or for Bob to send Alice his certificate). In contrast, with IBE, Alice just encrypts the message with Bob's public id, and sends that message to Bob; Bob doesn't need to send a message to Alice.

So, that is the advantage of IBE; if you are sending unidirectional messages, you don't need a back channel to complete the exchange. If this is important for you (for example, if you are sending encrypted emails; the store-and-forward email architecture doesn't allow a back channel), this is quite useful. If you do have a convenient back channel (as in your case; you're going to exchange messages encrypted with a symmetric key anyways), it doesn't gain you anything.

poncho
  • 138,335
  • 11
  • 217
  • 344
  • But where is the difference between Alice needing Bob's DH key or Bob's certificate versus needing (in an authenticated way) Bob's ID? I only see that the ID might be shorter and thus is easier written down on paper (and typed from this). – Paŭlo Ebermann Jun 18 '12 at 19:53
  • The difference is that Alice already has Bob's ID (in this case, "Bob"). $\:$ –  Jun 18 '12 at 20:01
  • @PaŭloEbermann: when Alice sends the message to Bob, she needs identify how the message gets to Bob. For example, if she sends it via email, she needs Bob's email address (bob@foo.com). Since she has that already, that can be used as the ID. – poncho Jun 18 '12 at 20:25
  • @RickyDemer: How does Alice know that the person known to her as "Bob" is the same person as the one known to the IBE central (or whoever provides the private keys) as "Bob"? – Paŭlo Ebermann Jun 18 '12 at 20:28
  • @poncho: So this only helps when the central can identify Bob by his address? – Paŭlo Ebermann Jun 18 '12 at 20:30
  • @PaŭloEbermann: for Alice to communicate securely with Bob, she needs to know how to get messages to Bob (be it via an email address, an IP address or a phone number), and she needs to be able to distinguish this Bob from anyone else who might be listening in. What IBE attempts to do is try to allow those two things to be the same. To do this, yes, the central authority does need to give the private key to "bob@foo.com" only to the real Bob, and not just anyone who asks. – poncho Jun 18 '12 at 20:55
  • @PaŭloEbermann: $\:$ The same way that Alice would "know that ... same person ... known to" $\hspace{0.8 in}$ a CA central as "Bob". $\;\;$ –  Jun 18 '12 at 21:14
  • Most IBE system are glorified webmail systems with authentication by email answerback. They know that bob@foo.com is Bob because Bob can receive email at bob@foo.com – vy32 Jan 25 '16 at 20:36