Friday Apr 18, 2008

Sala Radia Perlman

Had to get a shot of this - Radia was my SEED mentor a little while ago - now she's been commemorated in the naming of the press room here at FISL. Kind of appropriate for a pioneer in communications

Friday Mar 23, 2007

Chatting with Radia

One thing I've been meaning to blog about for weeks is my participation in Sun's Engineering Enrichment and Development (SEED) mentoring program. Katy Dickinson runs SEED - she recently posted this compendium of articles - everything you need to know about SEED is there.

Anyway - I hit the jackpot with my mentor - Sun Fellow Dr Radia Perlman. You may know Radia as 'Mother of the Internet', inventor of the Spanning Tree algorithm and author of Interconnections: Bridges, Routers, Switches, and Internetworking Protocols. SEED participants have to select several potential mentors, writing a few sentences about each one. Here is what I wrote about Radia:

I started the current arc of my career in 1997, implementing SSL in Java and contributing to a 'clean room' implementation of JCA/JCE. Radia Perlman has been a familiar name to me since that time, given the security aspects of her work.

Not only does Radia have DEEP technical knowledge, she combines this with a refreshing willingness to speak her mind. When I received a comment on my blog asking about 'Identity Based Encryption', I fired off an email to Sun's internal security mailing list to find out more. Radia gave a detailed and comprehensive reply, with permission to quote her on my blog.

Since security is an essential part of my work, and identity is a key consumer of Radia's work, there is a certain synergy possible in Radia mentoring me.

Our mentoring relationship comprises a phone call every couple of weeks and face-to-face meetings if we ever end up in the same city at the same time. I have to admit, I was pretty intimidated the first time I called Radia - she is not exactly a shrinking violet - but we seemed to hit it off and have spent several hours - well - chatting, basically.

Chatting about her work, my work, career progression at Sun and anything else that's on our minds. I get a lot out of it, I hope Radia does too, and it's fun. And, let's face it, that's about 50% of Sun's unofficial mission statement

Thursday Jul 13, 2006

Identity-Based Encryption revisited

After my earlier post on Identity-Based Encryption, I promised James McGovern that I'd ping our security folks for their take on IBE. I did so and Radia Perlman was kind enough to reply and gave me permission to quote her in full:

Identity based encryption.

This is something that some people in the research community have gotten all excited about, and I really think there's nothing there. It might be cute math, and even a cute concept. The hype is that it makes "all the problems of PKI go away".

The basic idea is that you can use your name as your public key. The private key is derived from the public key based on a domain secret, known to a special node called the PKG (private key generator), which is like a KDC, or an NT domain controller.

Some of the problems I see with it:

a) public key stuff is so nice because nobody needs to know your secret, and the trusted party (the CA) need not be online. The PKG obviously needs to be online, and knows everyone's secrets

b) If Alice is in a different trust domain than Bob, she has to somehow securely find out Bob's PKG's public parameters (which enable her to turn Bob's name into a public key IN THAT DOMAIN).

c) Bob has to somehow authenticate to the PKG to get his own private key

d) There is no good answer to revocation, in case someone steals Bob's private key

e) There is no good answer to revocation, in case someone steals the PKG's domain secret.

I've seen hype slides about identity based encryption saying "which identity is easier to remember?

In PKI: 237490798271278094178034612638947182748901728394078971890468193707

This is such ill-conceived hype. In PKI no human needs to see an RSA key. The RSA key is not your identity. Your identity is still something like

So, it looks like IBE gives with one hand (sender can create a public key without the recipient's involvement) but takes much more away with the other (key secrecy, PKG has to be online, revocation issues). I guess there is no such thing as a free lunch...




« June 2016