Hi John:
I do think your statements below got some things wrong:
a) Virtually all implementations of curve arithmetic for Weierstrass
curves (including NIST curves, such as P-256) use a *lossless*
representation of elliptic curve points, for which - in the case of the
P-256 curve - no secure 256-bit representation is known (if you know
one, I would be excited to learn about this). So, characterizing this as
"change from 32 to 33 bytes" gets the order wrong, as the SECG, NIST,
ANSI, and BSI specs show. {I am not sure whether RFC 6090 counts as a
spec, since its purpose was mainly to document prior art for
intellectual property reasons, and is known to be entirely insecure for
any curve with co-factor greater than one (if only due to allowing small
subgroup attacks.}
b) Affine representations allow virtually zero-cost public-key
validation of a received point (which most standards mandate), while
allowing implementors to pick an implementation that suits their needs
(taking into account development cost, existing platforms, etc.). As
case in point, this allows use of table-assisted approaches,
differential addition chains (e.g., Montgomery ladder), etc. Lossy
representations may make some of the security checks less economical
(and, thereby, promote moral hazards by implementors wishing to squeeze
out more efficiency "because nobody would normally notice").
c) Montgomery ladders can be implemented with so-called y-coordinate
recovery at the end of this calculation - see, e.g.,
https://datatracker.ietf.org/doc/html/draft-ietf-lwig-curve-representations-19#appendix-C.
This fact has been known since 2002 or earlier.For formulas, see also
Secion 4.2 of the lwig curve document.
Encoding format issues may negatively impact code reuse and reuse of
existing standards, since can be used as artificial ‟moat around a
solution”, making code reuse or algorithm agility
economically less viable than these could/should be. For a detailed
discussion of various representation aspects, see also
https://datatracker.ietf.org/meeting/101/materials/slides-101-lwig-4-lwig-curve-representations-01.
Best regards, Rene
On 2021-02-11 6:19 a.m., John Mattsson wrote:
Hi Mohit,
A P-256 ECDH public key does not _/require/_ 33 bytes. EDHOC uses 32
bytes compact representation [RFC 6090] and there are a lot of people
arguing that HPKE should do the same.
3GPP 5G already uses the 33 bytes compressed format from SECG in SUCI
(I wrote part of that specification) but I now think it was a mistake.
The change from 32 to 33 bytes encoding affects more than just size.
Forcing the implementation to calculate a y-coordinate significantly
slows down the calculations as a x-coordinate only ladder cannot be
used. I don’t think this change is good.
Also, referring to both 186-4 and SECG for the encoding seems strange.
If the 33 byte encoding is kept, I think SECG only is enough.
John
*From: *Emu <emu-boun...@ietf.org> on behalf of Mohit Sethi M
<mohit.m.sethi=40ericsson....@dmarc.ietf.org>
*Date: *Thursday, 9 July 2020 at 08:46
*To: *Russ Housley <hous...@vigilsec.com>
*Cc: *"emu@ietf.org" <emu@ietf.org>
*Subject: *Re: [Emu] I-D Action: draft-ietf-emu-aka-pfs-04.txt
Rene, Russ, and I had an offline email exchange about this issue. I
think we are now in agreement that the public key for the NIST P-256
curve requires at least 33 bytes (in the compressed format).
Thus, we should update the draft to reflect the correct key size.
Adding a reference to https://www.secg.org/SEC2-Ver-1.0.pdf
<https://protect2.fireeye.com/v1/url?k=ee7f4584-b0df87c2-ee7f051f-86fc6812c361-2b60805fe723aebc&q=1&e=8fc33e3e-797f-4645-8a58-9177a3822ce7&u=https%3A%2F%2Fwww.secg.org%2FSEC2-Ver-1.0.pdf>
and explicitly mentioning the use of the compressed format would also
be beneficial.
--Mohit
On 6/24/20 11:04 PM, Russ Housley wrote:
The ECDH public value in RFC 5480 is an OCTET STRING, which means that the
value is exactly 32 bytes. When this gets carried as a subject public key in a
certificate, there is an extra byte only because the type is a BIT STRING.
My conclusion is that the current draft is correct:
* For P-256, the length of this value is 32 bytes, encoded in
binary as specified in [FIPS186-4].
Russ
On Jun 24, 2020, at 1:10 AM, Mohit Sethi
M<mohit.m.sethi=40ericsson....@dmarc.ietf.org>
<mailto:mohit.m.sethi=40ericsson....@dmarc.ietf.org> wrote:
Hi all,
I am not a crypto expert and my knowledge of public key encodings is
based on my work with Rene Struik for a different draft.
The current text in draft-ietf-emu-aka-pfs-04 says "For P-256, the
length of this value is 32 bytes, encoded in binary". Shouldn't this be
33 bytes? And wouldn't it make sense to explicitly say that this is an
octet string in the compressed format while referencing "SEC 1: Elliptic
Curve Cryptography, Version 2.0" for the point to octet string
conversion rules?
--Mohit
On 5/26/20 9:57 AM,internet-dra...@ietf.org
<mailto:internet-dra...@ietf.org> wrote:
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
This draft is a work item of the EAP Method Update WG of the IETF.
Title : Perfect-Forward Secrecy for the
Extensible Authentication Protocol Method for Authentication and Key Agreement
(EAP-AKA' PFS)
Authors : Jari Arkko
Karl Norrman
Vesa Torvinen
Filename : draft-ietf-emu-aka-pfs-04.txt
Pages : 26
Date : 2020-05-25
Abstract:
Many different attacks have been reported as part of revelations
associated with pervasive surveillance. Some of the reported
attacks
involved compromising smart cards, such as attacking SIM card
manufacturers and operators in an effort to compromise shared
secrets
stored on these cards. Since the publication of those reports,
manufacturing and provisioning processes have gained much
scrutiny
and have improved. However, the danger of resourceful
attackers for
these systems is still a concern.
This specification is an optional extension to the EAP-AKA'
authentication method which was defined in
[I-D.ietf-emu-rfc5448bis].
The extension, when negotiated, provides Perfect Forward
Secrecy for
the session key generated as a part of the authentication run
in EAP-
AKA'. This prevents an attacker who has gained access to the
long-
term pre-shared secret in a SIM card from being able to decrypt
any
past communications. In addition, if the attacker stays merely
a
passive eavesdropper, the extension prevents attacks against
future
sessions. This forces attackers to use active attacks instead.
The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-emu-aka-pfs/
<https://datatracker.ietf.org/doc/draft-ietf-emu-aka-pfs/>
There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-emu-aka-pfs-04
<https://tools.ietf.org/html/draft-ietf-emu-aka-pfs-04>
https://datatracker.ietf.org/doc/html/draft-ietf-emu-aka-pfs-04
<https://datatracker.ietf.org/doc/html/draft-ietf-emu-aka-pfs-04>
A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-emu-aka-pfs-04
<https://www.ietf.org/rfcdiff?url2=draft-ietf-emu-aka-pfs-04>
Please note that it may take a couple of minutes from the time of
submission
until the htmlized version and diff are available at tools.ietf.org.
Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/
<ftp://ftp.ietf.org/internet-drafts/>
_______________________________________________
Emu mailing list
Emu@ietf.org <mailto:Emu@ietf.org>
https://www.ietf.org/mailman/listinfo/emu
<https://www.ietf.org/mailman/listinfo/emu>
_______________________________________________
Emu mailing list
Emu@ietf.org <mailto:Emu@ietf.org>
https://www.ietf.org/mailman/listinfo/emu
<https://www.ietf.org/mailman/listinfo/emu>
_______________________________________________
Emu mailing list
Emu@ietf.org <mailto:Emu@ietf.org>
https://www.ietf.org/mailman/listinfo/emu
<https://www.ietf.org/mailman/listinfo/emu>
_______________________________________________
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
--
email: rstruik....@gmail.com | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 287-3867
_______________________________________________
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
