Re: [Gzz] Re: [Gzz-commits] journals hemppah

[Hermanni Hyytiälä]

On Fri, 2003-07-25 at 02:41, Benja Fallenstein wrote:
> Hi,
> 
> Hermanni Hyytiälä wrote:
> > +    - Identity Based Cryptography
> > +      - IBC has had much attention in cryptography domain very recently
> 
> I've read a bit about this recently, too.


Me too, i.e., couple of papers (however, I omitted proofs :)).


> 
> > +      - a public key can be e.g. person's e-mail, ip-address etc
> 
> I.e. the point is: You have an *existing* identifier for a person, and 
> want to use this identifier as their public key.


True. Because of this requirement, I have a feeling that first
deployments based on IBC are mainly focused on business communications
between companies (as Voltage Security's procucts) because people have
identifiers assigned by a employer, i.e., e-mails.


> 
> > +      - no more randomly generated keys
> 
> I'm not sure what the point is, here? The 'random' key resides with the 
> Trusted Third Party.


Ok, I meant random *looking* versus IBC's *less* random looking identier
(e.g., an e-mail).


> 
> > +      - no more certificate - key binding problems
> 
> I.e., a verifier doesn't need a way to obtain (and verify) a certificate 
> for a given public key.


True.


> 
> > +      - no more certificate revokations, revokation lists etc
> 
> Um, this simply means that you cannot revoke a key. Then, of course, you 
> don't need CRLs either. You can also omit CRLs from a classic PKI if you 
> don't think you need to revoke keys.

Ditto.

> 
> > +      - private keys are provided by a key server
> 
> I.e.: There is a single, central, trusted third party (TTP). To obtain a 
> private key for <address@hidden>, I would authenticate myself to 
> the TTP by proving that I'm really the owner of this address; the TTP 
> would then generate my private key and send it to me.
> 
> The TTP is in the possession of a "master key," a private key that 
> enables it to generate everybody else's private key. If this master key 
> is exposed, all private keys would have to be invalidated and new 
> private keys generated for everybody.

> It's noteworthy that IBC has built-in key escrow: The TTP has (or can 
> generate) the private key of every participant in the system.
> 


Yes, the one you described is the original scheme my Boneh and Franklin.
However, Gentry and Silverberg
(http://camars.kaist.ac.kr/~ec/id_based/%5B7%5DHierIBE02.pdf) have
extended the original scheme to obtain a fully scalable hierarchical
ID-based encryption scheme: there is a hierarchical tree and upper level
of PKGs (Private Key Generator, as the authors call it) generate private
keys immediately below them in the hierarchy. In their proposal,
entity's ID is a tuple of IDs containing the ID of each of their
ancestors in the hierarchy (and, thus, could be used of signatures). The
two schemes are identical if there is only one level in a system.

Additionally, a paper by Boyen
(http://robotics.stanford.edu/%7Exb/crypto03/crypto03online.pdf)
proposes a practical scheme that combines (current and future) IB-based
signature and encryption algorithms in a practical way. Since the author
works for Voltage Security (at least author's e-mail suggests so;)) we
could imagine that this scheme has influenced somehow to Voltage
Security's products.

I plan to read Boyen's paper today more carefully.



> > +      - looks promising w.r.t. Storm's pointer authentication
> 
> Why?

As said IBC looks, at first sight, promising: for instance, because of
PKI's lifecycle management/scalability issues (management of identity
binding issues &c) and the lack of offline use (AFAIK). OTOH, IBC can be
used anywhere (even offline) and it's appears to be more simple than
PKI. Thus, IBC seems to suit well in a dynamic systems (e.g. a P2P
network).


> 
> What do you intend to use as the public keys? (Email addresses or IPs or 
> telephone numbers or domain names would not work, because they can 
> change possession over time.)

A tuple of IDs (as described above).



-Hermanni