Re: [P1363:] Teleconference meeting reminder: June 24th 2008, 1-4 pm EDT
Hi
As explained to William I am unable to make the teleconference but
Dan Page and myself have a number of comments on the 1363.3 draft,
some stylistic, and some correctiosn. I detail these below.
First some general comments re pairings. I will denote the taxonomy of
Type I, Type II and Type III pairings from the "Pairings for
Cryptographers" paper. Sometimes the draft refers to, or implies it
is talking about, one of the various Types. For example it assumes
a mapping from G2 to G1 in places. This is a bad idea. The most
efficient pairings known (Ate-pairings) are in the Type 3 setting.
Hence, protocols should be written with full generality in mind. I
understand this is only the first draft, but someone needs to go
through and pick up the places where this is done and smooth the
whole presentation over.
Secondly assuming Type II/Type III pairings the draft makes a
particular choice in the key generation primitives as to which groups
various elements lie in, see the comment below on the BF key
construction. This might make sense for the BF encryption scheme,
but it might not make sense for other schemes using the same
key construction, e.g. SCK key agreement scheme. This needs to
be ironed out. See the paper of myself, Liqun Chen and Michael Cheng,
we present for example the standard BF key construction, and its
"dual". We refer to these as Extract 1 and Extract 1'. Suggest
that the current construction in the standard is called P-BF-G1,
P-BF-V1, etc and that "duals" are added, such as P-BF-G2, P-BF-V2.
Similar comments can be applied to the SK constructions, and probably
the BB ones as well.
Note these can be mixed and matched as well. You probably need to
add a TA key construction primitive, say P-TA-G1, with its dual
P-TA-G2. For example
P-TA-G1 : R = s Q \in G_2
whilst
P-TA-G2 : R = s P \in G_1
BUT this can be combined with either
P-BF-G1 : D = s M \in G_2
or
P-BF-G2 : D = s M \in G_1
Verification would need need to be altered as well.
Note capital/lower case are not consistent across the document. Some
private keys are upper case D and some are lower case d.
Detailed comments:
p 10. Section 1.3.1.
Needs updateing. Indeed much of the preamble needs sorting out.
p 16. Section 4.3.
You need to add in the other schemes considered such as ID-based key
agreement etc
p 17/18/19 Section 4.5.
The summary table is very incomplete. For example HIBE, P-BR, HIBS,
BB_2, EV are not mentioned. They should either be in the table or not
in the standard (suggest the former is what is wanted).
The table entry marked "SCC Key Agreement" should be
"SCK Key Agreement"
and the final column for this entry should include
P-BF-G, P-BF-V, P-SCK-D1
p 21. Item 21 and 22.
This seems awkward. It is not the "pairing" which is compressed, but an
element of the target group. There might be other things compressed and
not just the pairing values.
p 21. Item 27
If memory serves me correct this is an isomorphism over the algebraic
closure.
p 24 Lines 21++.
See the earlier comment on Type 2 and 3 pairings.
p 36. Line 16.
See earlier comment on Type 2 and 3 pairings. What if the mapping does
not exist ?
p 42. Line 1 etc
For the SCK scheme one needs M and D to be in G_2 to achieve the optimal
scheme.
p 43. Line 23
Bit of explanation needed here, for example a reference to where this
construction is used in the literature. Otherwise it seems to come
from nowhere. For example, how does it fit with an earlier non-HIBE
scheme etc.
Similar comments apply to also
- p 46. Line 16
- p 49. Line 11
- p 53. Line 24
p 56. Line 11.
Reference missing
p58. Lines 5->9 etc
This construction uses the "dual" of P-BF. This should be pointed out
in these lines. The "identity" public keys refer to P-BF style
keys and the "second" public keys refer to standard DH style keys.
Perhaps a
p58. Lines 16->25
Loads of mistakes. In the following I assume the "dual" BF construction
1) Compute an elliptic curve point A = x R
2) Compute a pairing t_1 = e(A,Q)
3) Compute a pairing t_2 = e(E,d)
4) Compute an elliptic curve point B = x E
5) Comvert B into an octet string o_1 using EC2OSP
6) Compute t_3 = t_1 \cdot t_2
7) Convert t_3 into an octet string o_2 using FE2OSP
8) Let z = o_1 \Vert o_2
9) Output z as the shared secret value
[ Liqun can you check the above, it seems correct to me ]
p 62. Line 5
I suspect the reference [CHEN05] is wrong and you mean [CHEN06], i.e.
- L. Chen, Z. Cheng, J. Malone-Lee and N.P. Smart
- An efficient ID-KEM based on the Sakai--Kasahara key construction.
- IEE Proceedings Information Security, Vol 153, pp 19-26, 2006.
Since the scheme is the KEM and not the encryption scheme.
p 69. Line 21
This seems to be the Barreto/Libert/McCullagh/Quisquarter scheme. If so
this should be referenced.
p 70. Line 11 etc
Once again Type II pairings are assumed. In addition the whole key
construction thing here is essentially a copy of the P-SK routines.
This should be cleared up. The key constructions should be created
one and then reused in the document.
p 71. Line 10 etc
The conversion from points/elemnts of G_T into octet strings has not
been explicitly done.
p 71. Line 25.
Numerator I think should be e(Q,S)
p 76. Line 20 and 28
Replace "SCC" with "SCK"
p 77. Line 1.
Yes is the answer. See my earlier comment re page 58.
p 77. Line 7.
The primitive is defined it is P-SCK-D1
As the references are not included we have not checked whether the
correct papers are referenced at each point. There is some confusion
over references the papers related to the SK-KEM scheme, so would like
to check this is done correctly at some point.
Hope the above is all clear. Would be happy to help with more detailed
comment and clarifications.
Cheers
Nigel
Whyte, William wrote:
> Hi List,
>
> There'll be a P1363 teleconference on Tuesday, June 24th 2008, from 1-4
> pm EDT.
> Call-in number is:
>
> US: 1-800-201-6800
> Int: +1-212-786-7191
>
> Passcode: 7882130#
>
> The main agenda item will be the review of the current draft of 1363.3,
> which
> is available from http://grouper.ieee.org/groups/1363/IBC/index.html.
>
> If you have any other items for the agenda please let me know off-list.
>
> Cheers,
>
> William
>
> ================================
>
> William Whyte,
> Chair, IEEE P1363
> NTRU Cryptosystems,
> 35 Nagog Park, Acton, MA 01720
> ph: +1 978 844 5208
> fx: +1 978 264 0103
>
> ______________________________________________________________________
> To unsubscribe, mail LISTSERV@LISTSERV.IEEE.ORG with
> the body of the message containing: SIGNOFF STDS-P1363-DISCUSS
> Send any concerns to STDS-P1363-DISCUSS-request@LISTSERV.IEEE.ORG,
> or manage subscriptions at http://listserv.ieee.org/cgi-bin/wa
> Visit IEEE P1363 on the web at: http://grouper.ieee.org/groups/1363
> ______________________________________________________________________
>
> ______________________________________________________________________
> To unsubscribe, mail LISTSERV@LISTSERV.IEEE.ORG with
> the body of the message containing: SIGNOFF STDS-P1363-DISCUSS
> Send any concerns to STDS-P1363-DISCUSS-request@LISTSERV.IEEE.ORG,
> or manage subscriptions at http://listserv.ieee.org/cgi-bin/wa
> Visit IEEE P1363 on the web at: http://grouper.ieee.org/groups/1363
> ______________________________________________________________________
>
> ______________________________________________________________________
> To unsubscribe, mail LISTSERV@LISTSERV.IEEE.ORG with
> the body of the message containing: SIGNOFF STDS-P1363-DISCUSS
> Send any concerns to STDS-P1363-DISCUSS-request@LISTSERV.IEEE.ORG,
> or manage subscriptions at http://listserv.ieee.org/cgi-bin/wa
> Visit IEEE P1363 on the web at: http://grouper.ieee.org/groups/1363
> ______________________________________________________________________
______________________________________________________________________
To unsubscribe, mail LISTSERV@LISTSERV.IEEE.ORG with
the body of the message containing: SIGNOFF STDS-P1363-DISCUSS
Send any concerns to STDS-P1363-DISCUSS-request@LISTSERV.IEEE.ORG,
or manage subscriptions at http://listserv.ieee.org/cgi-bin/wa
Visit IEEE P1363 on the web at: http://grouper.ieee.org/groups/1363
______________________________________________________________________