2007 Reports : Cryptology ePrint Archive Forum

**Re: The paper 07-217 seems interesting.**

**Re: The paper 2007/217 seems interesting.**

**Re: The paper 07-217 seems interesting.**

**Re: The paper 07-217 seems interesting.**

**Re: The paper 2007/217 seems interesting.**

**Re: The paper 07-217 seems interesting.**

Discussion forum for Cryptology ePrint Archive reports posted in 2007.
Please put the report number in the subject.

The paper 07-217 seems interesting.

Posted by: **otto** (IP Logged)

Date: 26 June 2007 09:11

This topic is only a first trial of this forum.

Thank you Anna for your great effort!

OK.

I did a brief reading of the paper 07-217:"Identity-Based Broadcast Encryption", which was written by Ryuichi Sakai and Jun Furukawa from Japan.

I think the paper is interesing.

We should say the proposed scheme is noval.

Does anybody agree with me? ^^

Thank you Anna for your great effort!

OK.

I did a brief reading of the paper 07-217:"Identity-Based Broadcast Encryption", which was written by Ryuichi Sakai and Jun Furukawa from Japan.

I think the paper is interesing.

We should say the proposed scheme is noval.

Does anybody agree with me? ^^

Posted by: **Shengbao Wang** (IP Logged)

Date: 27 June 2007 01:56

A-ha! I agree with you. Prof. Sakai is a BIG name in IBC!

Seems the paper is in an anonymous submission, the authors forgot to add their names into the paper^_^

BTW, I also want to thank Anna for her great work. I love this forum!

Seems the paper is in an anonymous submission, the authors forgot to add their names into the paper^_^

BTW, I also want to thank Anna for her great work. I love this forum!

Posted by: **Shengbao Wang** (IP Logged)

Date: 27 June 2007 02:25

Paper number shoud be in the form of 2007/217, i.e. Year/XXX.

Posted by: **pascal.paillier** (IP Logged)

Date: 02 August 2007 16:25

This forum is really an excellent idea... bravo Anna

I had a quick look at the paper. It seems at first look that the paper shares the same underlying mechanism with a recent paper by Cecile Delerablee, David Pointcheval and myself recently published at Pairing 07 (I may be wrong though, have to dig deeper to see what they do).

I had a quick look at the paper. It seems at first look that the paper shares the same underlying mechanism with a recent paper by Cecile Delerablee, David Pointcheval and myself recently published at Pairing 07 (I may be wrong though, have to dig deeper to see what they do).

Posted by: **tedd** (IP Logged)

Date: 05 August 2007 11:37

em..

Thank Anna for her great work............ I love this forum!

Thank Anna for her great work............ I love this forum!

Posted by: **Brent Waters** (IP Logged)

Date: 13 August 2007 00:17

Pascal, I briefly looked over your paper and I am not sure that your comment applies here. Please let me know if I am missing something.

If one reads the Delerablee et al. paper it seems to me that the encryption algorithm takes as input a set of **revoked** users R. To broadcast to a set S of identities, the encryptor will need to know revoke every identity that has been given out by the authority and not in S. Moreover, if some user is later given a private key for identity, ID, that the encryptor did not have the foresight to revoke then he can decrypt the ciphertext.

Unless I am misunderstanding the Delerablee et al. paper, it seems to clearly not imply Identity-Based Encryption scheme (broadcast or otherwise). When the set of possible identities, M, is bounded ahead of time (to a reasonable size set) one can talk interchangeably to encrypting to a set S, or a revoked set R; however, this is not the case when one considers an exponential size pool of identities as in IBE.

P.S. Is it mandatory for me to thank Anna in every post I make or can I just do it once? I didn't read the rules thoroughly yet.

If one reads the Delerablee et al. paper it seems to me that the encryption algorithm takes as input a set of **revoked** users R. To broadcast to a set S of identities, the encryptor will need to know revoke every identity that has been given out by the authority and not in S. Moreover, if some user is later given a private key for identity, ID, that the encryptor did not have the foresight to revoke then he can decrypt the ciphertext.

Unless I am misunderstanding the Delerablee et al. paper, it seems to clearly not imply Identity-Based Encryption scheme (broadcast or otherwise). When the set of possible identities, M, is bounded ahead of time (to a reasonable size set) one can talk interchangeably to encrypting to a set S, or a revoked set R; however, this is not the case when one considers an exponential size pool of identities as in IBE.

P.S. Is it mandatory for me to thank Anna in every post I make or can I just do it once? I didn't read the rules thoroughly yet.

Posted by: **pascal.paillier** (IP Logged)

Date: 13 August 2007 15:02

Hey Brent,

you are definitely right, the Delerablee et al. broadcast scheme does not yield IB encryption at all since there are exponentially many identities. It doesn't seem trivial to extend it to IB broadcast either...

It seemed to me that the mechanism was similar just because the derivation of private decryption keys looked pretty much the same. However encryption and decryption are different, even though the proof also makes use of the generalized bilinear DH exponent framework (with polynomials P, Q, etc.). Btw, I found the proof in section 5 very unclear, the problem instance taken as input by the security reduction is not even properly described...

you are definitely right, the Delerablee et al. broadcast scheme does not yield IB encryption at all since there are exponentially many identities. It doesn't seem trivial to extend it to IB broadcast either...

It seemed to me that the mechanism was similar just because the derivation of private decryption keys looked pretty much the same. However encryption and decryption are different, even though the proof also makes use of the generalized bilinear DH exponent framework (with polynomials P, Q, etc.). Btw, I found the proof in section 5 very unclear, the problem instance taken as input by the security reduction is not even properly described...

Please log in for posting a message. Only registered users may post in this forum.