Hi List,

IEEE P1363 E-MOTION 2002-5 was PASSED: 8 YES, 0 N0, 0 ABSTAIN.

The voters were: Wei Dai, Don Johnson, Burt Kaliski, David
Kravitz, Pil Joong Lee, Roger Schlafly, Ari Singer, William Whyte.

Details of the motion are appended below.

Congratulations to Burt and the rest of the group -- we're ready
to move to the recirculation ballot. Details will follow shortly.

Cheers,

William

===================================
William Whyte
Chair, IEEE P1363 Working Group
NTRU Cryptosystems
5 Burlington Woods
Burlington, MA 01803
tel:  +1.781.418.2500
fax:  +1.781.418.2532


IEEE P1363 E-MOTION 2002-5: The IEEE P1363 working group authorizes the
additional changes outlined below to IEEE P1363a beyond those already
approved in E-MOTIONs 2002-1, 2002-2, and 2000-4 and at the August 2002
working group meeting, and authorizes the chair to submit a draft
implementing these changes for a recirculation ballot. Minor editorial
changes and updates to Annex G may be made if needed at the chair's
discretion without further vote.

Proposed: Burt Kaliski
Seconded: William Whyte

E-voting opens: Wednesday, November 27th, 2002, 9:00 am EST
E-voting closes: Saturday, December 7th, 2002, 9:00 am EST

Eligible e-voters: Dan Brown, Wei Dai, David Jablon, Don Johnson, Burt
Kaliski, 
Pieter Kasselman, David Kravitz, Pil Joong Lee, Tatsuaki Okamoto,
Roger Schlafly, Ari Singer, Jerry Solinas, David Stern, William Whyte (14)

A minimum of 7 votes is required for quorum with at least 2/3 YES
among YES/NO votes required for the motion to pass. Individual
votes will be distributed among the e-voters for verification, but
only the total count will be recorded in the working group's records.

===========================================================================


IEEE P1363 E-MOTION 2002-5: The IEEE P1363 working group authorizes the
additional changes outlined below to IEEE P1363a beyond those already
approved in E-MOTIONs 2002-1, 2002-2, and 2000-4 and at the August 2002
working group meeting, and authorizes the chair to submit a draft
implementing these changes for a recirculation ballot. Minor editorial
changes and updates to Annex G may be made if needed at the chair's
discretion without further vote.

Redundancy Lengths for EMSR1

TYPE: TECHNICAL

CHANGE: Correct the recommendations for EMSR1 redundancy length in D.5.2.2.2
Note 1, per a comment by Wei Dai. The note previously read:

1-Redundancy lengths for EMSR1: To maintain the security level of the
underlying hash function in general, the long redundancy length for EMSR1
should equal the output length of the hash function plus the length of any
hash function identifier. However, similar to the discussion in D.5.2.2.4
below, if there is no concern about first-party attacks, the long redundancy
length may be reduced to half the output length of the hash function plus
the length of any hash function identifier. Similarly, since hash function
collisions are not a concern in the case of total message recovery, the
short redundancy length is recommended only to be at least half the output
length of the hash function plus the length of any hash function identifier.

The suggestion that the length may equal the "half the output length of the
hash function plus the length of any hash function identifier" was
misleading. If the length were set as suggested, then the hash function
identifier would be truncated during the encoding operation as indicated in
12.3.1 Note 3. Moreover, in the case of partial message recovery, the
reduction to half the output length is inconsistent with ISO/IEC 9796-3,
which requires that the hash function be collision-resistant. Finally, since
D.5.2.2.4 is being updated (see next change), the reference to it here has
been removed.

The note has been changed as follows:

1-Redundancy lengths for EMSR1: To maintain the security level of the
underlying hash function in general, the long redundancy length for EMSR1
should equal the output length of the hash function plus the length of any
hash function identifier. Since hash function collisions are not a concern
in the case of total message recovery, the short redundancy length is
recommended to be at least half the output length of the hash function if
hash function identification is not desired. However, if hash function
identification is desired, it should also equal the output length of the
hash function plus the length of any hash function identifier.

=====
Hash Function Collisions

TYPE: TECHNICAL

CHANGE: Correct the discussion of hash function collisions in D.5.2.2.4, per
a comment by Wei Dai. The third paragraph previously read:

Typical attacks for finding a message with a given representative based on
hash function inversion involve on the order of 2^l operations assuming an
l-bit hash function; attacks for finding two messages with the same
representative based on hash function collision involve 2^{l/2} operations.
However, the actual complexity and applicability of an attack is sometimes
different. For instance, in EMSR1 and EMSR2, since the message is hashed
together with a random value (i.e., a pre-signature or a value derived from
it), hash function collisions are generally not a concern except from the
perspective of a first-party attack where the signer, given the
pre-signature, attempts to find two messages with the same signature. Thus,
if there is no concern about first-party attacks and the pre-signature is
sufficiently random, a collision-resistant hash function seems not to be
required (or, alternatively, the hash function output may be truncated to
half its length without compromising security - see D.5.2.2.2 Note 1 for
related discussion). Also, in the case of total message recovery for EMSR1
and EMSR3, collision resistance seems not to be required since even if two
messages have the same hash value, they will have different signatures. A
collision-resistant hash function is nevertheless recommended in these
various situations as it is a prudent security choice; a different choice
requires further security analysis by the implementer.

The paragraph overlooked the possibility of internal hash function
collisions. Although a message is hashed together with a random value, if
the random value is processed after the message (as in EMSR1), and the hash
function has a chained construction, then an internal collision between two
messages will result in the same hash value. Thus, the statement about EMSR1
is incorrect, and the general statement "a collision-resistant hash function
seems not to be required" is misleading. Given that the last sentence
encourages "further security analysis by the implementer" if a
collision-resistant hash function is not selected, the example and
discussion about first-party attacks can just as well be dropped. The
discussion for the case of total message recovery, meanwhile, has been
reworded to clarify that the "signature on one message part cannot be used
to recover the other".

The paragraph has been changed as follows:

Typical attacks for finding a message with a given representative based on
hash function inversion involve on the order of 2l operations assuming an
l-bit hash function; attacks for finding two messages with the same
representative based on hash function collision involve 2l/2 operations.
However, the actual complexity and applicability of an attack is sometimes
different. For instance, in the case of total message recovery for EMSR1 and
EMSR3, collision resistance seems not to be required since even if two
recoverable message parts have the same hash value, they will have different
message representatives, so the signature on one recoverable message part
cannot be used to recover the other. A collision-resistant hash function is
nevertheless recommended as it is a prudent security choice; a different
choice requires further security analysis by the implementer.

=====
Plaintext-Awareness

TYPE: TECHNICAL

CHANGE: Update the discussion of plaintext-awareness in D.5.3 and elsewhere,
per a comment by Wei Dai. Although other discussions of plaintext-awareness
(e.g., for OAEP) had been updated previously, D.5.3 had been overlooked. In
particular, D.5.3 was essentially the same as in IEEE Std 1363-2000, where
there was only one encryption scheme, IFES; but the text did not apply fully
to DL/ECIES.

Several changes have been made:

* In D.5.3, introduce a revision for the entire first paragraph of that
clause in IEEE Std 1363-2000:

Encryption schemes are generally used to provide confidentiality of data. A
theoretical definition of "semantic security" (or, equivalently,
"indistinguishability" or "polynomial security") is commonly used as the
basis for the meaning of "confidentiality" (see Goldwasser and Micali [B61],
Section 8.7 of Menezes, van Oorschot, and Vanstone [B112], Micali, Rackoff,
and Sloan [B114], and Yao [B151]). Semantic security provides that it should
be computationally infeasible to recover any information about the plaintext
(except its length) from the ciphertext without knowing the private key.
This implies, in particular, that it should also be infeasible to find out
whether two ciphertexts correspond to the same, or in some way related,
plaintexts, or whether a given ciphertext is an encryption of a given
plaintext. The encryption schemes in this standard are believed to provide
semantic security against an adaptive chosen ciphertext attack (an attack in
which the opponent requests decryptions of specially chosen ciphertexts in
order to be able to decrypt other ciphertexts) when the appropriate scheme
options are selected.

* In D.5.3.2.1 (Message-encoding methods for encryption), third bullet,
delete the text '("plaintext awareness")' since it is no longer defined in
D.5.3

* In D.5.3.2.1 Note 1, add an informal explanation of "plaintext awareness"
after the use of the term:

An attacker cannot gain any information from an implementation of IFES
decryption by observing whether a ciphertext results in an error message,
because of the "plaintext awareness" of OAEP. (Informally, the attacker
needs to "know" the plaintext in order to construct a valid ciphertext, so
the attacker will already know whether a ciphertext will result in an error
message.)
 
* In D.5.3 Note 1, add an informal explanation of how malleability relates
to CCA2, supporting the new text in D.5.3 about "appropriate scheme options"
for DL/ECIES:

(If a scheme is malleable, then formally it is not secure against an
adaptively chosen ciphertext attack.)

=====
Bit and Octet Strings (updated)

TYPE: EDITORIAL

ADDITIONAL CHANGE: For precision, the OS2BP primitive is specifically called
in the several places where bit strings and octet strings are concatenated:
12.3.1.1 step 5, 12.3.1.2 step 7, and 14.4.1 step 6. In the third case, the
text "(where the octet string and the bit string are concatenated in the
natural way)" has been dropped, as the "natural way" is not defined.

Also, "octet string" has been changed to "bit string" in 10.4.2 step 4 and
10.4.3 Step 5 (this was a typo).

=====
EMSR1 Errata

TYPE: EDITORIAL

CHANGE: Per a comment by Wei Dai, revise 12.3.1 Note 2, which stated:

EMSR1 is not amenable to "single-pass" processing _in the case that the
signature is transmitted after the non-recoverable message part_

(emphasis added). The italicized text suggested that EMSR1 would be amenable
to single-pass processing if the signature were transmitted first, which is
true only for signature verification, not signature generation. The
italicized text has been dropped.

=====
HMAC Constant

TYPE: EDITORIAL

CHANGE: Correct a typo in the HMAC oPad constant in 14.4.1 step 5, per a
comment by Wei Dai. The correct value is 5c, not 5a.

=====
Exponent in Extension Field Inversion

TYPE: EDITORIAL

CHANGE: Correct typos in the exponents in the definition of Norm(\alpha) in
A.17.3.3, per a comment by Daniel Bleichenbacher: they should be functions
of p, not q, and the last exponent should be p^{m-1}, not q(m-1).

=====