Luther, > Some comments are in-line below. > > We've added hash agility, specifying a different hash algorithm for each > of the defined levels of bit security as well as including an additional > parameter that defines the hash function used in each of the relevant > algorithms. > > We've also added the longer key lengths that the extremely > security-conscious might want - now specifying parameters for up to and > including the equivalent of 256 bits of symmetric strength.
Ok. > > > Next, regarding point [3], the algorithms described in this draft are > > > public-key algorithms and are definitely not stream ciphers. > > > > I stand behind point [3], here's a longer explanation and example: > > > > At least Section 8.4 and 8.5 perform encryption and decryption by > > XOR-ing a keystream with the plaintext or ciphertext (Sections > > 5.4 and 5.5 appear to do likewise, but there are potential mistakes > > in those sections that make this somewhat unclear). While "stream > > cipher" may not be a precise term for these constructs, they are > > at least a stream-cipher-like operating mode for the public key > > algorithms. In particular, they are subject to <key,IV> reuse > > concerns that apply to stream ciphers. > > > > Specifically, for section 8.4, the actual encryption step for the > > message m is: > > y = HashStream(|m|, h') XOR m > > where h' does not depend on m, so if the same s (effectively an IV) > > is ever used twice with the same identity and public parameters for > > different messages that have the same length (e.g., m1 and m2), the > > HashStream element will be the same, so one can obtain the XOR of > > the plaintext messages by XORing the corresponding ciphertexts, i.e.: > > y1 XOR y2 = m1 XOR m2 > > This is usually considered undesirable, as it tends to leak information > > about m1 and m2. At a minimum, this needs to be discussed in the > > security considerations section, even if the countermeasures to > > prevent this from happening are left to other documents that apply > > these algorithms to particular contexts. > > We've added text that says that users SHOULD use a PRNG like those > specified in FIPS 186-2 or X9.62. I believe that the definition of > "random" should take care of this. After all, if your source of entropy > is random enough, then the probability of generating the same random > value twice is cryptographically small. Ok, please add a discussion to the security considerations section about the consequences of ever using the same s value twice with the same key as a reason why strong random numbers are needed. > > > Are architectural issues, like the restrictions on letting arbitrary > > > clients decrypt on behalf of an arbitrary identity, more suitable for > > > other documents? After all, this document just describes two > > > cryptographic algorithms. Are issues surrounding their applications > > > better described elsewhere? > > > > Yes and no. Let me start with an apology. The following text from > > my review is not correct: > > > > -> It is *very* important to understand that the ability to encrypt > > -> or decrypt on behalf of an identity is not proof of that identity, > > -> and hence the mechanisms described in this draft MUST NOT be used > > -> for authentication purposes, and any identity used with these > > -> mechanisms MUST be authenticated or verified by other means. > > > > With a suitably configured key server including proper use of > > authentication with key server clients, proof of possession of > > the private key for an identity could be used as proof of that > > identity (i.e., authentication), but the configuration restrictions > > are important. In any case, the above text is wrong as written, > > and I apologize for that mistake. > > > > At the very least, the draft needs an architectural diagram showing > > the key server and the clients showing which keys flow where for > > at least one example - that would have saved me from this mistake, > > and the fact that I made it is a backhanded indication that such > > a diagram and associated discussion is needed. I think that > > discussion also needs to bring out the dependence on the key > > server and authentication to the key server in restricting > > availability of private keys to their corresponding identities > > if one intends to use them for authentication. > > > > There is another draft that gives an overall description of a complete > IBE system. We've added a reference to that document. There should be a diagram and a summary of the roles of the components in this draft. > I have a draft that includes the above comments; let me know what > additional points need to be addressed. See the original review at: http://www.alvestrand.no/ietf/gen/reviews/draft-martin-ibcs-03-black.txt There are a number of additional comments on the body of the draft in that review which should be addressed. Thanks, --David ---------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 [EMAIL PROTECTED] Mobile: +1 (978) 394-7754 ---------------------------------------------------- _______________________________________________ Gen-art mailing list [email protected] https://www1.ietf.org/mailman/listinfo/gen-art
