[Gen-art] RE: Gen-ART review of draft-martin-ibcs-03

["Luther Martin" <[e-mail]>]

David,
David,

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. 

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

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

I have a draft that includes the above comments; let me know what
additional points need to be addressed.

Luther



_______________________________________________
Gen-art mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/gen-art