Fwd: [IP] A Simpler, More Personal Key to Protect Online Messages

[Anton Stiglic]

----- Original Message ----- 
From: "Whyte, William" <WWhyte at ntru.com>

[...]
> But you don't have to contact the CA to get someone's certificate.
> A standard way is to send them an email saying "can you send me
> a signed message?"

Yes, that works.  When I want someone to send me confidential
email, and that someone doesn't know much or anything about crypto, 
I usually just send an S/MIME signed email, and let his MUA (usually
Outlook or Outlook Express) do the work of saving the certificate
and all.

> This also ensures you have the right public key. I haven't
> studied the details of IBE, but I assume that (a) there may
> be multiple IBE-based "CA"s, with different parameters, and

The way I see IBE being useful is as a corporate solution for
encrypting messages.  Inside a corporation everyone will use 
the same public parameter (which could probably come with 
the software installation).  And in most corporate crypto solutions
you want key escrow, which IBE gives you as well for free :)
The benefit is that you don't need to deal with users public keys:
you don't need to get them from some repository or ask the
person to send it to you by email and stuff.  So say that you are
with your laptop away, and don't have the persons public key
certificate, you can still send him/here email directly (without asking
anyone to send you his/her public key).  I admit the feature is
of limted value however.

> (b) the identity that's used to encrypt will be not just a 
> name, but a name and a date (to ensure that some revocation-like
> capability exists). In either case, you can't simply pick the
> email address and use it as the public key; you need to establish
> some additional information first. This seems to put us back 
> in the same place as with standard PKI, usability-wise. (Or,
> rather, there may be a usability delta for IBE, but it's very
> small).

In the Boneh-Franklin paper one suggestion is to use
bob at company.com || current-year
which would make public keys good for one year (which sounds
reasonable, especially within a corporation).   Of course, the software 
will include the year when creating the public key, the users wouldn't 
need to do it explicitly.  If you really want to be able to revoke
public keys, you need more granularity and use something like
bob at company.com || current-date, and that does become
anoying for the users (need to fetch your private key everyday).

One interesting thing about IBE is that you can transform any such 
scheme into a Non-interactive forward-secret cryptosystem as
Adam Back pointed out:
http://www.cypherspace.org/~adam/nifs/
(his web server might be down, but you can look at the cached version
on Google...).

--Anton


 


---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com