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

[Benja Fallenstein]

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.

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

> +      - no more randomly generated keys

I'm not sure what the point is, here? The 'random' key resides with the 
Trusted Third Party.

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

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

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

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

Why?

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

- Benja