Re: IBC (Re: [Gzz] Re: [Gzz-commits] journals hemppah)

[Hermanni Hyytiälä]

On Fri, 2003-07-25 at 09:55, Tuukka Hastrup wrote:
> On Fri, 25 Jul 2003, Benja Fallenstein wrote:
> 
> [on Identity Based Cryptography]
> 
> > > +      - 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.
> 
> When you revoke a key, aren't you telling "you're not supposed to use this 
> public key anymore"? In IBC, you can include a time perioid in the 
> identity. Doesn't that implicitly revoke the key after that time perioid?


Yes. Additional property of IBC is that Alice can send a message to Bob
*before* Bob has ever acquired his private key.


> 
> > > +      - private keys are provided by a key server
> > 
> > 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.

True: for the original Boneh-Franklin scheme.
Not true: in general case (see my previous mail about hierarchical
IB-based system) ;).

> 
> You can distribute the trust among several TTP's: I guess the simplest 
> would be to always encrypt several times, using different TTP's. It was 
> also mentioned that the secret can be distributed so that no single TTP 
> ever has the complete secret or any complete private key.
> 
> http://crypto.stanford.edu/ibe/

More efficient approach would be the use of erasure code (or similar
approaches): a block (a key) is divided into m identically-sized
fragments, which are then encoded into n fragments (where n > m). Now,
the original block (the key) can be reconstructed from any m fragments,
depending on the quantity r = m/n ( < 1).

Anyhow, I think the hierarchical IBC scheme is still more scalable than
a scheme based on erasure codes.

> 
> > > +      - looks promising w.r.t. Storm's pointer authentication
> 
> > 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.)
> 
> I don't know if this brainstorming is any use, but I could imagine some 
> scheme where the identity and thus the public key is a Storm pointer name. 
> Valid pointer blocks could only be issued with the secret key.

Hm, I'm not sure this would work right with IBC since the key idea
behind the IBC is that public key is a valid, "real life", identifier
that is directly related to an entity (i.e. a person). With Storm,
anybody (AFAIK) is able to create pointers as much as one wants. Thus,
the possession rate of identifier could be very high and the use of a
pointer for identifying an entity may be flawed.



-Hermanni