From yaronf@checkpoint.com Wed Jul 8 08:54:15 2009 Return-Path: X-Original-To: cfrg@core3.amsl.com Delivered-To: cfrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 29D6F3A6AAA for ; Wed, 8 Jul 2009 08:54:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.567 X-Spam-Level: X-Spam-Status: No, score=-2.567 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EsXEJFcmegyL for ; Wed, 8 Jul 2009 08:54:14 -0700 (PDT) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id F22E63A6A3D for ; Wed, 8 Jul 2009 08:54:01 -0700 (PDT) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 100C8200E09; Wed, 8 Jul 2009 18:54:28 +0300 (IDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id ADC4120037B for ; Wed, 8 Jul 2009 18:54:27 +0300 (IDT) X-CheckPoint: {4A54C0CD-0-14201DC2-1FFFF} Received: from il-ex01.ad.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id n68FsE3d025260 for ; Wed, 8 Jul 2009 18:54:14 +0300 (IDT) Received: from il-ex01.ad.checkpoint.com ([194.29.32.26]) by il-ex01.ad.checkpoint.com ([194.29.32.26]) with mapi; Wed, 8 Jul 2009 18:54:13 +0300 From: Yaron Sheffer To: "cfrg@irtf.org" Date: Wed, 8 Jul 2009 18:54:13 +0300 Thread-Topic: Comments on draft-mcgrew-fundamental-ecc-00.txt Thread-Index: Acn/5Fa/ml20pduCT/mfdKuCYMOCuA== Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC8E8ABD59BAB@il-ex01.ad.checkpoint.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_00F2_01C9FFFD.7C18AB10" MIME-Version: 1.0 Subject: [Cfrg] Comments on draft-mcgrew-fundamental-ecc-00.txt X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2009 15:54:15 -0000 ------=_NextPart_000_00F2_01C9FFFD.7C18AB10 Content-Type: multipart/alternative; boundary="----=_NextPart_001_00F3_01C9FFFD.7C18AB10" ------=_NextPart_001_00F3_01C9FFFD.7C18AB10 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit First and foremost, I would like to thank the author for making this compilation available to the community. It certainly helps to cut through some of the IPR fog. - Sec. 2.1: Using Zp for a general group (not necessarily of prime order) is confusing. Can we have Zn instead? - 2.1: with all due respect, Knuth is probably unavailable to most of our readers. There must have been something published in the last 28 years to replace it... - 2.2: similarly for Deskins. Or (if the pre-1994 provenance is critical) add a reference to some modern tutorial coverage. Cormen, Leiserson, Rivest and Stein chapter 31, for example. Or better still, a URL. - 3: the formula pair for x3, y3 "if P is equal to Q" (the last one) is confusing, since the preceding formula refers to a sub-case of this case. Maybe change to "otherwise", or "if P is equal to Q and the previous condition does not hold". - General: the term "characteristic" (and once, "character") is used multiple times without definition. - 3.2: "the order n" (not indented, by the way) - is it part of the specification, or a dependent property of the group which is defined by the other parameters? - 4: can you say something about the security of ECDH? Specifically, are there validity checks required by both parties on the other party's value, so that an attacker cannot force "bad" values that will reveal the private key. Sec. 9.3 mentions that each party should check that the received value is in the group. Is this sufficient? - 4.1: is group element -> is a group element - 4.2: since all group operations have been defined in terms of full point (x and y), it is unclear how "compact representation" works, i.e. how both parties compute the shared secret when only X values are transmitted. - 7.1: when the dust around RFC 4735, its errata etc. settles, IKE (v1 and v2) will use compact output. Thanks, Yaron ------=_NextPart_001_00F3_01C9FFFD.7C18AB10 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

First and foremost, I would like to thank the author = for making this compilation available to the community. It certainly helps = to cut through some of the IPR fog.

 

- Sec. 2.1: Using Zp for a general group (not = necessarily of prime order) is confusing. Can we have Zn = instead?

- 2.1: with all due respect, Knuth is probably = unavailable to most of our readers. There must have been something published in the = last 28 years to replace it...

- 2.2: similarly for Deskins. Or (if the pre-1994 = provenance is critical) add a reference to some modern tutorial coverage. Cormen, Leiserson, Rivest and Stein chapter 31, for example. Or better still, a = URL.

- 3: the formula pair for x3, y3 "if P is equal = to Q" (the last one) is confusing, since the preceding formula refers to a = sub-case of this case. Maybe change to "otherwise", or "if P is = equal to Q and the previous condition does not = hold".

- General: the term "characteristic" (and = once, "character") is used multiple times without definition.

- 3.2: "the order n" (not indented, by the = way) - is it part of the specification, or a dependent property of the group which = is defined by the other parameters?

- 4: can you say something about the security of = ECDH? Specifically, are there validity checks required by both parties on the other party's = value, so that an attacker cannot force "bad" values that will reveal = the private key. Sec. 9.3 mentions that each party should check that the = received value is in the group. Is this sufficient?

- 4.1: is group element -> is a group = element

- 4.2: since all group operations have been defined = in terms of full point (x and y), it is unclear how "compact = representation" works, i.e. how both parties compute the shared secret when only X values are transmitted.

- 7.1: when the dust around RFC 4735, its errata etc. = settles, IKE (v1 and v2) will use compact output.

 

Thanks,

         =    Yaron

------=_NextPart_001_00F3_01C9FFFD.7C18AB10-- ------=_NextPart_000_00F2_01C9FFFD.7C18AB10 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPTTCCBDIw ggMaoAMCAQICAQEwDQYJKoZIhvcNAQEFBQAwezELMAkGA1UEBhMCR0IxGzAZBgNVBAgMEkdyZWF0 ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBwwHU2FsZm9yZDEaMBgGA1UECgwRQ29tb2RvIENBIExpbWl0 ZWQxITAfBgNVBAMMGEFBQSBDZXJ0aWZpY2F0ZSBTZXJ2aWNlczAeFw0wNDAxMDEwMDAwMDBaFw0y ODEyMzEyMzU5NTlaMHsxCzAJBgNVBAYTAkdCMRswGQYDVQQIDBJHcmVhdGVyIE1hbmNoZXN0ZXIx EDAOBgNVBAcMB1NhbGZvcmQxGjAYBgNVBAoMEUNvbW9kbyBDQSBMaW1pdGVkMSEwHwYDVQQDDBhB QUEgQ2VydGlmaWNhdGUgU2VydmljZXMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC+ QJ30buHqdoccTUVEjr5GyIMGncEq/hgfjuQC+vOrXVCKFjELmgbQxXAizUktVGPMtm5oRgtT6stM JMC8ck7q8RWu9FSaEgrDerIzYOLaiVXzIljz3tzP74OGooyUT59o8piQRoQnx3a/48w1LIteB2Rl gsBIsKiR+WGfdiBQqJHHZrXreGIDVvCKGhPqMaMeoJn9OPb2JzJYbwf1a7j7FCuvt6rM1mNfc4za BZmoOKjLF3g2UazpnvR4Oo3PD9lC4pgMqy+fDgHe75+ZSfEt36x0TRuYtUfF5SnR+ZAYx2KcvoPH Jns+iiXHwN2d5jVoECCdj9je0sOEnA1e6C/JAgMBAAGjgcAwgb0wHQYDVR0OBBYEFKARCiM+lvEH 7OKvKe+CpX/QMKS0MA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MHsGA1UdHwR0MHIw OKA2oDSGMmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0FBQUNlcnRpZmljYXRlU2VydmljZXMuY3Js MDagNKAyhjBodHRwOi8vY3JsLmNvbW9kby5uZXQvQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmww DQYJKoZIhvcNAQEFBQADggEBAAhW/ALwm+j/pPrWe8ZEgM5PxMX2AFjMpra8FEloBHbo5u5d7AIP YNaNUBhPJk4B4+awpe6/vHRUQb/9/BK4x09a9IlgBX9gtwVK8/bxwr/EuXSGti19a8zS80bdL8bg asPDNAMsfZbdWsIOpwqZwQWLqwwv81w6z2w3VQmH3lNAbFjv/LarZW4E9hvcPOBaFcae2fFZSDAh ZQNs7Okhc+ybA6HgN62gFRiP+roCzqcsqRATLNTlCCarIpdg+JBedNSimlO98qlo4KJuwtdssaMP nr/raOdW8q7y4ys4OgmBtWuF174t7T8at7Jj4vViLILUagBBUPE5g5+V6TaWmG4wggTdMIIDxaAD AgECAhBxkvvmGV+sTRKFdHE0ohinMA0GCSqGSIb3DQEBBQUAMHsxCzAJBgNVBAYTAkdCMRswGQYD VQQIDBJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcMB1NhbGZvcmQxGjAYBgNVBAoMEUNvbW9k byBDQSBMaW1pdGVkMSEwHwYDVQQDDBhBQUEgQ2VydGlmaWNhdGUgU2VydmljZXMwHhcNMDQwMTAx MDAwMDAwWhcNMjgxMjMxMjM1OTU5WjCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYD VQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYD VQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xp ZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBALI5haTyfatBO2JGN67NwWB1vDll+UoaR6K5zEjMapjVTTUZuaRC5c5J4oovHnzSMQfHTrSD ZJ0uKdWiZMSFvYVRNXmkTmiQexx6pJKoF/KYFfKTzMmkMpW7DE8wvZigC4vlbhuiRvp4vKJvq1le pS/Pytptqi/rrKGzaqq3Lmc1i3nhHmmI4uZGzaCl6r4LznY6eg6b6vzaJ1s9cx8i5khhxkzzabGo Lhu21DEgLLyCio6kDqXXiUP8FlqvHXHXEVnauocNr/rz4cLwpMVnjNbWVDreCqS6A3ezZcj9HtN0 YqoYymiTHqGFfvVHZcv4TVcodNI0/zC27vZiMBSMLOsCAwEAAaOCAScwggEjMB8GA1UdIwQYMBaA FKARCiM+lvEH7OKvKe+CpX/QMKS0MB0GA1UdDgQWBBSJgmd9xJ0mcABLtFBIfN49rgRufTAOBgNV HQ8BAf8EBAMCAQYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwEQYDVR0gBAowCDAGBgRVHSAAMHsGA1UdHwR0MHIwOKA2oDSGMmh0dHA6Ly9jcmwuY29tb2Rv Y2EuY29tL0FBQUNlcnRpZmljYXRlU2VydmljZXMuY3JsMDagNKAyhjBodHRwOi8vY3JsLmNvbW9k by5uZXQvQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmwwEQYJYIZIAYb4QgEBBAQDAgEGMA0GCSqG SIb3DQEBBQUAA4IBAQCdlcs8uH6lCcQevwvCx3aOOTyUxhCqTwzJ4KuEXYlU4GU7820cfDcsJVRf liH8N4SRnRXcFE+Bz1Qda2xFYMct+ZdRTPlmyjyggoymyPDi6dRK+ew/VsnddozDggFPbADzHhph dARHA6nGQFeRvGUixSdnT1fbZFrZjR+6hi/0Bq6cae3p9M8pF9jgSp8aIC+XTFG7RgfEijdOIOMJ MWjHnsSLneh+EbwyaBCWEZhE2CpRYE2I63Q630MGMsg5Vow6EVLTQaRDA/Tt7zMn2zngFE4mydj1 OeKJuJNdtykmQeqzm66D/Hd1yujKtf7iZUpjPkTE0MNeh3OpmByvfxV/MIIGMjCCBRqgAwIBAgIR AIDKyDfd56zXUq4aqXlC1iYwDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQI EwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0 d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNF UkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwwHhcNMDgwOTEwMDAwMDAwWhcN MDkwOTEwMjM1OTU5WjCB3jE1MDMGA1UECxMsQ29tb2RvIFRydXN0IE5ldHdvcmsgLSBQRVJTT05B IE5PVCBWQUxJREFURUQxRjBEBgNVBAsTPVRlcm1zIGFuZCBDb25kaXRpb25zIG9mIHVzZTogaHR0 cDovL3d3dy5jb21vZG8ubmV0L3JlcG9zaXRvcnkxHzAdBgNVBAsTFihjKTIwMDMgQ29tb2RvIExp bWl0ZWQxFjAUBgNVBAMTDVlhcm9uIFNoZWZmZXIxJDAiBgkqhkiG9w0BCQEWFXlhcm9uZkBjaGVj a3BvaW50LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALqGr14AEP/lS7OgXTYs 8LjmDZYg3KegpdGXufAXa93NbmAAQ1EmqkVBw8vC/EcYCM+D9uUWeK0uC7BpmCalFDh28AMMIUKI W0VGvDF+kE8zjnch/j7whoWvOvj6yFxYZNe9zfUlZZ7xBc+LEPzqsd4oLbK7a7WkvZAuUHfH0oiH k2miEZkXZF/mhpGp/LplLeA8b51fvQhv8UqIzwRghVTLDCAnIhVk/w+WMmRhcHptYZDa0gOhjyza a/4kG1oHw44Ae9cZpws8TXL+JOrUdmJG6uFY3wB0YvPw9b/u0WeY7Snq0bDF58vDNw0jaQsfIoxx EE+MscA9JbuaPaXIFdkCAwEAAaOCAhcwggITMB8GA1UdIwQYMBaAFImCZ33EnSZwAEu0UEh83j2u BG59MB0GA1UdDgQWBBSNbKhiJVIDkhy5HRA+njy+oWiKMDAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0T AQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQD AgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2Vj dXJlLmNvbW9kby5uZXQvQ1BTMIGlBgNVHR8EgZ0wgZowTKBKoEiGRmh0dHA6Ly9jcmwuY29tb2Rv Y2EuY29tL1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwSqBI oEaGRGh0dHA6Ly9jcmwuY29tb2RvLm5ldC9VVE4tVVNFUkZpcnN0LUNsaWVudEF1dGhlbnRpY2F0 aW9uYW5kRW1haWwuY3JsMGwGCCsGAQUFBwEBBGAwXjA2BggrBgEFBQcwAoYqaHR0cDovL2NydC5j b21vZG9jYS5jb20vVVROQUFBQ2xpZW50Q0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5j b21vZG9jYS5jb20wIAYDVR0RBBkwF4EVeWFyb25mQGNoZWNrcG9pbnQuY29tMA0GCSqGSIb3DQEB BQUAA4IBAQBemghknp7tCcWJ+Pzvopk4bHBaaYF/NJtkrSLXJdOb8p286uOS+7po0DIE+zh9iIyV MTq5GFkleVzIVQHWOIOfCMnxbYh6tgrJUZKdDHMJG2vhz2i2dFOJzWnMnosWmKsDDMpmtLMH1mn+ 31lQkp+rgUAkuFUruAPrG6ms5BVaO/Ta+yBGdEJ0ecLOKuA3zmKnmy8beceXpm4OdkBGWWdLvBGu P/+v8n8KwVf2zzNTaZeEy+139MH9GTrVTiHnOsgdkvvsTu7cAl3mhRxR+o60XU0fQdk3jtbPrzeF uK5fTY6yKlW2e/rlJg3hAr3FkIpszNRgnu+BUDYFg9VnYjjYMYIEaDCCBGQCAQEwgcQwga4xCzAJ BgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoT FVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29t MTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwC EQCAysg33ees11KuGql5QtYmMAkGBSsOAwIaBQCgggJ4MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTA5MDcwODE1NTQxM1owIwYJKoZIhvcNAQkEMRYEFEKZ9mG1Tv2O Pgmv50WsDvfnhObDMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCA MA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3 DQIFMIHVBgkrBgEEAYI3EAQxgccwgcQwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUG A1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8G A1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNs aWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwCEQCAysg33ees11KuGql5QtYmMIHXBgsqhkiG 9w0BCRACCzGBx6CBxDCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0 IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRw Oi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhl bnRpY2F0aW9uIGFuZCBFbWFpbAIRAIDKyDfd56zXUq4aqXlC1iYwDQYJKoZIhvcNAQEBBQAEggEA A37rIbneIJT6KD89n7K7I8vX7J7lMvBg5Wdgs3DvnDQVOJe8Q2pP5iBCaCeEMej6RiUFrCgz9pm3 fBAxOeLf/p3C5kg9mqEiz/S3anFqIUT8vQ2rg9gW34TqyDfN5+DNpzob1J6MrdpK39UwQIFC55M6 VQkgk45mHZdXuLve7BjkscCWam7c44P9TcRzoKPglrmVkLEpi9o1vHZajP6o3Xm6l906wzvZOApb 0z4rkf/QMt0GKitJA1SqBShy2Mr6vddgPL2S52Ag/PQrmyS4mUhBEMwhZoFeHk6dYhcfcjTjW8tn pgOw5DR3ybCR0gNtQYW5GmwSWHE7dmgfXj93BAAAAAAAAA== ------=_NextPart_000_00F2_01C9FFFD.7C18AB10-- From sshen@huawei.com Thu Jul 23 00:18:57 2009 Return-Path: X-Original-To: cfrg@core3.amsl.com Delivered-To: cfrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 03ED73A6823 for ; Thu, 23 Jul 2009 00:18:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.469 X-Spam-Level: * X-Spam-Status: No, score=1.469 tagged_above=-999 required=5 tests=[AWL=1.079, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cVv5xDigOwCe for ; Thu, 23 Jul 2009 00:18:56 -0700 (PDT) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id BB6193A6817 for ; Thu, 23 Jul 2009 00:18:33 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KN800KHX44UE2@szxga03-in.huawei.com> for cfrg@irtf.org; Thu, 23 Jul 2009 15:14:54 +0800 (CST) Received: from huawei.com ([172.24.1.33]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KN800D8D44U5K@szxga03-in.huawei.com> for cfrg@irtf.org; Thu, 23 Jul 2009 15:14:54 +0800 (CST) Received: from s00102542 ([10.111.12.128]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KN80030744TU9@szxml06-in.huawei.com> for cfrg@irtf.org; Thu, 23 Jul 2009 15:14:54 +0800 (CST) Date: Thu, 23 Jul 2009 15:14:53 +0800 From: Sean Shen To: mcgrew@cisco.com, cfrg@irtf.org Message-id: <00b101ca0b65$46ae9750$800c6f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: multipart/alternative; boundary="Boundary_(ID_m3R+WB9cL6GcbdPYMjRlfw)" Thread-index: AcoLZUY537JwzYi6Sm+8wuU0jTvsiw== Subject: [Cfrg] Comments on draft-mcgrew-fundamental-ecc-00 X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jul 2009 07:18:57 -0000 This is a multi-part message in MIME format. --Boundary_(ID_m3R+WB9cL6GcbdPYMjRlfw) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi, David, Thank you for providing such a document. As a ecc fan, I like this document very much, :) I was not able to finish reading the whole document yet, but get a few comments so far: #1 section 2.1 When you are discribing "set Zp = { 0, 1, 2, ..., p-1 }", looks like you do not limit p to be a prime. Usually Zn is used for arbitary modular group, Zp refer to modular group with prime order. #2 section 2.2 By definition, the operation "*" defined on any group have a property of associative law: (a*b)*c=a*(b*c). The operation "*" is called "+" when it also has another good property called commutative law, i.e. a+b=b+a. #3 section This document only cover curves over finite fields with Characteristic>3. Is there a reason for this? I imagine becuase Certicom's recent IPR disclosure provide royalty free license for 3 ECP curves? I don't know whether IETF will more recommend ECP curse because of this disclosure, but I think this is a good reason to only describe ECP curves. If it is the reason, might be good to mention it. I took a brief looks at EC groups defined for IKE and TLS: For IKE and IKEv2: RFC2409 and subsequetly IANA defined, 10 EC2N groups (Characteristic=2) (http://www.iana.org/assignments/ipsec-registry) RFC4753, 3 ECP groups (Characteristic>3) For TLS: RFC4492, 14 EC2N groups, 11 ECP groups This is a very rough look and can not be considered a survey. I will keep reading and hope to add more comments. Best, Sean --Boundary_(ID_m3R+WB9cL6GcbdPYMjRlfw) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT
Hi, David,
Thank you for providing such a document. As a ecc fan, I like this document very much, :)
I was not able to finish reading the whole document yet, but get a few comments so far:
#1
section 2.1
When you are discribing "set Zp = { 0, 1, 2, ..., p-1 }", looks like you do not limit p to be a prime. 
Usually Zn is used for arbitary modular group, Zp refer to modular group with prime order.
 
#2
section 2.2
By definition, the operation "*" defined on any group have a property of associative law: (a*b)*c=a*
(b*c).
The operation "*" is called "+" when it also has another good property called commutative law, i.e. a+b=b+a.
 
#3
section
This document only cover curves over finite fields with Characteristic>3. Is there a reason for this? I 
imagine becuase Certicom's recent IPR disclosure provide royalty free license for 3 ECP curves? I don't 
know whether IETF will more recommend ECP curse because of this disclosure, but I think this is a good 
reason to only describe ECP curves. If it is the reason, might be good to mention it. 
I took a brief looks at EC groups defined for IKE and TLS:
For IKE and IKEv2:
 RFC2409 and subsequetly IANA defined, 10 EC2N groups (Characteristic=2)
 (http://www.iana.org/assignments/ipsec-registry)
 RFC4753, 3 ECP groups (Characteristic>3)
For TLS:
 RFC4492, 14 EC2N groups, 11 ECP groups
This is a very rough look and can not be considered a survey. 
 
I will keep reading and hope to add more comments.
 
Best,
 
Sean
 
  
--Boundary_(ID_m3R+WB9cL6GcbdPYMjRlfw)-- From ashot@motorola.com Tue Jul 28 13:31:26 2009 Return-Path: X-Original-To: cfrg@core3.amsl.com Delivered-To: cfrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D235A3A6ACD for ; Tue, 28 Jul 2009 13:31:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4toOiDQGOALM for ; Tue, 28 Jul 2009 13:31:26 -0700 (PDT) Received: from mail55.messagelabs.com (mail55.messagelabs.com [216.82.241.163]) by core3.amsl.com (Postfix) with ESMTP id C01E93A68B3 for ; Tue, 28 Jul 2009 13:31:25 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: ashot@motorola.com X-Msg-Ref: server-6.tower-55.messagelabs.com!1248813078!13589909!1 X-StarScan-Version: 6.0.0; banners=-,-,- X-Originating-IP: [136.182.1.14] Received: (qmail 11848 invoked from network); 28 Jul 2009 20:31:19 -0000 Received: from motgate4.mot.com (HELO motgate4.mot.com) (136.182.1.14) by server-6.tower-55.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 28 Jul 2009 20:31:19 -0000 Received: from il27exr03.cig.mot.com (il27exr03.mot.com [10.17.196.72]) by motgate4.mot.com (8.14.3/8.14.3) with ESMTP id n6SKVI7g021883 for ; Tue, 28 Jul 2009 13:31:18 -0700 (MST) Received: from az10vts04.mot.com (il27vts04.cig.mot.com [10.17.196.88]) by il27exr03.cig.mot.com (8.13.1/Vontu) with SMTP id n6SKVIsh023198 for ; Tue, 28 Jul 2009 15:31:18 -0500 (CDT) Received: from ct11exm60.ds.mot.com (CT11EXM60.am.mot.com [10.177.8.44]) by il27exr03.cig.mot.com (8.13.1/8.13.0) with ESMTP id n6SKVH8N023181 for ; Tue, 28 Jul 2009 15:31:17 -0500 (CDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA0FC2.4F58E0FF" Date: Tue, 28 Jul 2009 16:31:10 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IKEv1 and 800-56A Thread-Index: AcoPwleYagib5HiVSIG/X6NaBhIFZg== From: "Andreasyan Ashot-C23793" To: X-CFilter-Loop: Reflected Subject: [Cfrg] IKEv1 and 800-56A X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2009 20:33:08 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA0FC2.4F58E0FF Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi All, =20 Recently NIST published "Recommendation for Pair-Wise Key Establishment Schemes Using Discrete Logarithm Cryptography" http://csrc.nist.gov/publications/nistpubs/800-56A/SP800-56A_Revision1_M ar08-2007.pdf =20 How does this this document is going to interconnect with IKEv1? =20 =20 Thanks, Ashot=20 =20 ------_=_NextPart_001_01CA0FC2.4F58E0FF Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi=20 All,
 
Recently NIST=20 published "Recommendation for=20 Pair-Wise Key Establishment Schemes Using Discrete Logarithm Cryptography"
http://csrc.nist.gov/publications/nistpubs/800-56A/= SP800-56A_Revision1_Mar08-2007.pdf
 
How = does=20 this this document is going to interconnect with = IKEv1?
 
 
Thanks,
Ashot
 
------_=_NextPart_001_01CA0FC2.4F58E0FF-- From mcgrew@cisco.com Thu Jul 30 11:34:32 2009 Return-Path: X-Original-To: cfrg@core3.amsl.com Delivered-To: cfrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 54B7A3A6C9B for ; Thu, 30 Jul 2009 11:34:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p5sSJzNi7SKC for ; Thu, 30 Jul 2009 11:34:31 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 249203A6CCA for ; Thu, 30 Jul 2009 11:34:29 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArUEAP+DcUqrR7PD/2dsb2JhbACCKC25J4gnkC0FhBc X-IronPort-AV: E=Sophos;i="4.43,296,1246838400"; d="scan'208,217";a="357268700" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 30 Jul 2009 18:34:30 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n6UIYVLZ028178; Thu, 30 Jul 2009 11:34:31 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n6UIYUn5027086; Thu, 30 Jul 2009 18:34:31 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 30 Jul 2009 11:34:30 -0700 Received: from [10.32.254.210] ([10.32.254.210]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 30 Jul 2009 11:34:29 -0700 Message-Id: <7F0B24B6-AA62-4575-A599-FDF30B80BA95@cisco.com> From: David McGrew To: Yaron Sheffer In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC8E8ABD59BAB@il-ex01.ad.checkpoint.com> Content-Type: multipart/alternative; boundary=Apple-Mail-6-88729078 Mime-Version: 1.0 (Apple Message framework v930.3) Date: Thu, 30 Jul 2009 11:34:28 -0700 References: <7F9A6D26EB51614FBF9F81C0DA4CFEC8E8ABD59BAB@il-ex01.ad.checkpoint.com> X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 30 Jul 2009 18:34:30.0335 (UTC) FILETIME=[603A1CF0:01CA1144] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=10792; t=1248978871; x=1249842871; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mcgrew@cisco.com; z=From:=20David=20McGrew=20 |Subject:=20Re=3A=20[Cfrg]=20Comments=20on=20draft-mcgrew-f undamental-ecc-00.txt |Sender:=20; bh=me47GG19Hx0qqy9NHdxeA27fAq/5epImo+mF+lmqKCY=; b=VwImCq0VBvYw1AtSZHb3tR9kG+CCstwW8SS1Mn29FXEMcgXOfihdE9YG0N 4QZZoF40HUtd7EvPJPwbY0831/tkEYHjd+xGn/x5Hhdp1dwjMLadyaMDWMGa f3jEXgRZi2; Authentication-Results: sj-dkim-3; header.From=mcgrew@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: "cfrg@irtf.org" Subject: Re: [Cfrg] Comments on draft-mcgrew-fundamental-ecc-00.txt X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2009 18:34:32 -0000 --Apple-Mail-6-88729078 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Hi Yaron, many thanks for your useful comments, they will improve the next version of the draft. If there is uncertainty about whether or not IKE uses compact output for ECDH, I wonder: why don't we just not use it? It is probably the simpler option, at least conceptually. Sorry for the slow reply, I have been on vacation recently. David On Jul 8, 2009, at 8:54 AM, Yaron Sheffer wrote: > First and foremost, I would like to thank the author for making this > compilation available to the community. It certainly helps to cut > through some of the IPR fog. > > - Sec. 2.1: Using Zp for a general group (not necessarily of prime > order) is confusing. Can we have Zn instead? > - 2.1: with all due respect, Knuth is probably unavailable to most > of our readers. There must have been something published in the last > 28 years to replace it... > - 2.2: similarly for Deskins. Or (if the pre-1994 provenance is > critical) add a reference to some modern tutorial coverage. Cormen, > Leiserson, Rivest and Stein chapter 31, for example. Or better > still, a URL. > - 3: the formula pair for x3, y3 "if P is equal to Q" (the last one) > is confusing, since the preceding formula refers to a sub-case of > this case. Maybe change to "otherwise", or "if P is equal to Q and > the previous condition does not hold". > - General: the term "characteristic" (and once, "character") is used > multiple times without definition. > - 3.2: "the order n" (not indented, by the way) - is it part of the > specification, or a dependent property of the group which is defined > by the other parameters? > - 4: can you say something about the security of ECDH? Specifically, > are there validity checks required by both parties on the other > party's value, so that an attacker cannot force "bad" values that > will reveal the private key. Sec. 9.3 mentions that each party > should check that the received value is in the group. Is this > sufficient? > - 4.1: is group element -> is a group element > - 4.2: since all group operations have been defined in terms of full > point (x and y), it is unclear how "compact representation" works, > i.e. how both parties compute the shared secret when only X values > are transmitted. > - 7.1: when the dust around RFC 4735, its errata etc. settles, IKE > (v1 and v2) will use compact output. > > Thanks, > Yaron > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > http://www.irtf.org/mailman/listinfo/cfrg --Apple-Mail-6-88729078 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Hi = Yaron,

many thanks for your useful comments, they = will improve the next version of the draft. =  

If there is uncertainty about whether or = not IKE uses compact output for ECDH, I wonder: why don't we just not = use it?  It is probably the simpler option, at least conceptually. =  

Sorry for the slow reply, I have been on = vacation recently. =  

David

On Jul 8, = 2009, at 8:54 AM, Yaron Sheffer wrote:

 
- Sec. 2.1: Using Zp for a general group = (not necessarily of prime order) is confusing. Can we have Zn = instead?
- = 2.1: with all due respect, Knuth is probably unavailable to most of our = readers. There must have been something published in the last 28 years = to replace it...
- = 2.2: similarly for Deskins. Or (if the pre-1994 provenance is critical) = add a reference to some modern tutorial coverage. Cormen, Leiserson, = Rivest and Stein chapter 31, for example. Or better still, a = URL.
- = 3: the formula pair for x3, y3 "if P is equal to Q" (the last one) is = confusing, since the preceding formula refers to a sub-case of this = case. Maybe change to "otherwise", or "if P is equal to Q and the = previous condition does not hold".
- General: the term "characteristic" (and = once, "character") is used multiple times without = definition.
- = 3.2: "the order n" (not indented, by the way) - is it part of the = specification, or a dependent property of the group which is defined by = the other parameters?
- 4: can you say something about the = security of ECDH? Specifically, are there validity checks required by = both parties on the other party's value, so that an attacker cannot = force "bad" values that will reveal the private key. Sec. 9.3 mentions = that each party should check that the received value is in the group. Is = this sufficient?
- = 4.1: is group element -> is a group = element
- = 4.2: since all group operations have been defined in terms of full point = (x and y), it is unclear how "compact representation" works, i.e. how = both parties compute the shared secret when only X values are = transmitted.
- = 7.1: when the dust around RFC 4735, its errata etc. settles, IKE (v1 and = v2) will use compact output.
 
Thanks,
From: David McGrew To: Andreasyan Ashot-C23793 In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-7-94478349 Mime-Version: 1.0 (Apple Message framework v930.3) Date: Thu, 30 Jul 2009 13:10:17 -0700 References: X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 30 Jul 2009 20:10:19.0721 (UTC) FILETIME=[C320CB90:01CA1151] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=6053; t=1248984620; x=1249848620; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mcgrew@cisco.com; z=From:=20David=20McGrew=20 |Subject:=20Re=3A=20[Cfrg]=20IKEv1=20and=20800-56A |Sender:=20; bh=qKkPBkv7FSuJpjgWseBJ+J2laIwSxyhzM9z4OzG+gFI=; b=JvWOcHasEc1aUu94NlwWU+2O70Ri3cMhDOdunNS4x07wbLiEwiHZCa1Fy2 06MhUEls/ztKSdcCH4QTm2Bp9aRQmg2Tp+7p2DOVRmso5IyRPORD8vwEokAv hqhGIRjfqc; Authentication-Results: sj-dkim-2; header.From=mcgrew@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: cfrg@irtf.org Subject: Re: [Cfrg] IKEv1 and 800-56A X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2009 20:10:19 -0000 --Apple-Mail-7-94478349 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Hi Ashot, On Jul 28, 2009, at 1:31 PM, Andreasyan Ashot-C23793 wrote: > Hi All, > > Recently NIST published "Recommendation for Pair-Wise Key > Establishment Schemes Using Discrete Logarithm Cryptography" > http://csrc.nist.gov/publications/nistpubs/800-56A/SP800-56A_Revision1_Mar08-2007.pdf > > How does this this document is going to interconnect with IKEv1? that's a good question. The Diffe-Hellman protocols in the NIST key management documents are based on ANSI and IEEE standards that were developed concurrently with ISAKMP/OAKLEY/IKE. They are functionally equivalent in some ways, but they are different and incompatible in other ways. Personally, I would like to see these standards be reconciled, with preference going towards what they industry is actually implementing and using whenever it is reasonably secure. I would expect this reconciliation to be a long term project. Other opinions are welcome. If you are interested in the NIST key management documents, you might want to review the NIST White Paper on transitioning algorithms and key sizes, see http://csrc.nist.gov/groups/ST/key_mgmt/ Note that the review period closes on August 3. David > > > Thanks, > Ashot > > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > http://www.irtf.org/mailman/listinfo/cfrg --Apple-Mail-7-94478349 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Hi = Ashot,

On Jul 28, 2009, at 1:31 PM, = Andreasyan Ashot-C23793 wrote:

Hi All,
 
Recently NIST = published "Key Establishment Schemes Using Discrete Logarithm y"<= /div>
 
How does = this this document is going to interconnect with = IKEv1?

that's = a good question.  The Diffe-Hellman protocols in the NIST key = management documents are based on ANSI and IEEE standards that were = developed concurrently with ISAKMP/OAKLEY/IKE.  They are = functionally equivalent in some ways, but they are different and = incompatible in other ways.  

Personally, = I would like to see these standards be reconciled, with preference going = towards what they industry is actually implementing and using whenever = it is reasonably secure.   I would expect this reconciliation to be = a long term project.   Other opinions are = welcome.

If you are interested in the NIST key = management documents, you might want to review the NIST White Paper on = transitioning algorithms and key sizes, see http://csrc.nist.gov/gro= ups/ST/key_mgmt/    Note that the review period closes on = August 3.

David

 
 
Thanks,
Ashot
Cfrg@irtf.org
http://www.irtf.org/mai= lman/listinfo/cfrg

= --Apple-Mail-7-94478349-- From yaronf@checkpoint.com Thu Jul 30 13:40:19 2009 Return-Path: X-Original-To: cfrg@core3.amsl.com Delivered-To: cfrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 399E33A68E8 for ; Thu, 30 Jul 2009 13:40:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.115 X-Spam-Level: X-Spam-Status: No, score=-2.115 tagged_above=-999 required=5 tests=[AWL=0.483, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A3ehTrNsxyVk for ; Thu, 30 Jul 2009 13:40:13 -0700 (PDT) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 417753A71FC for ; Thu, 30 Jul 2009 13:40:12 -0700 (PDT) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id C6D0E29C01E; Thu, 30 Jul 2009 23:40:30 +0300 (IDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 6CB0729C01C; Thu, 30 Jul 2009 23:40:30 +0300 (IDT) X-CheckPoint: {4A7203BB-0-14201DC2-1FFFF} Received: from il-ex01.ad.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id n6UKeB3d005012; Thu, 30 Jul 2009 23:40:12 +0300 (IDT) Received: from il-ex01.ad.checkpoint.com ([194.29.32.26]) by il-ex01.ad.checkpoint.com ([194.29.32.26]) with mapi; Thu, 30 Jul 2009 23:40:11 +0300 From: Yaron Sheffer To: David McGrew Date: Thu, 30 Jul 2009 23:40:08 +0300 Thread-Topic: [Cfrg] Comments on draft-mcgrew-fundamental-ecc-00.txt Thread-Index: AcoRRGUV1ffnC7z+TcWpAiGq+zA59gAEPLQQ Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC80133E557CD3B@il-ex01.ad.checkpoint.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC8E8ABD59BAB@il-ex01.ad.checkpoint.com> <7F0B24B6-AA62-4575-A599-FDF30B80BA95@cisco.com> In-Reply-To: <7F0B24B6-AA62-4575-A599-FDF30B80BA95@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_00F4_01CA1166.B0FFF020" MIME-Version: 1.0 Cc: "cfrg@irtf.org" Subject: Re: [Cfrg] Comments on draft-mcgrew-fundamental-ecc-00.txt X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2009 20:40:19 -0000 ------=_NextPart_000_00F4_01CA1166.B0FFF020 Content-Type: multipart/alternative; boundary="----=_NextPart_001_00F5_01CA1166.B0FFF020" ------=_NextPart_001_00F5_01CA1166.B0FFF020 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi David, I don't know if there's a good answer, I believe the answer is essentially that there are several implementations already using the compact representation. And that is also what http://tools.ietf.org/html/draft-solinas-rfc4753bis-00, currently in IETF last call, specifies. Thanks, Yaron _____ From: David McGrew [mailto:mcgrew@cisco.com] Sent: Thursday, July 30, 2009 20:34 To: Yaron Sheffer Cc: cfrg@irtf.org Subject: Re: [Cfrg] Comments on draft-mcgrew-fundamental-ecc-00.txt Hi Yaron, many thanks for your useful comments, they will improve the next version of the draft. If there is uncertainty about whether or not IKE uses compact output for ECDH, I wonder: why don't we just not use it? It is probably the simpler option, at least conceptually. Sorry for the slow reply, I have been on vacation recently. David On Jul 8, 2009, at 8:54 AM, Yaron Sheffer wrote: First and foremost, I would like to thank the author for making this compilation available to the community. It certainly helps to cut through some of the IPR fog. - Sec. 2.1: Using Zp for a general group (not necessarily of prime order) is confusing. Can we have Zn instead? - 2.1: with all due respect, Knuth is probably unavailable to most of our readers. There must have been something published in the last 28 years to replace it... - 2.2: similarly for Deskins. Or (if the pre-1994 provenance is critical) add a reference to some modern tutorial coverage. Cormen, Leiserson, Rivest and Stein chapter 31, for example. Or better still, a URL. - 3: the formula pair for x3, y3 "if P is equal to Q" (the last one) is confusing, since the preceding formula refers to a sub-case of this case. Maybe change to "otherwise", or "if P is equal to Q and the previous condition does not hold". - General: the term "characteristic" (and once, "character") is used multiple times without definition. - 3.2: "the order n" (not indented, by the way) - is it part of the specification, or a dependent property of the group which is defined by the other parameters? - 4: can you say something about the security of ECDH? Specifically, are there validity checks required by both parties on the other party's value, so that an attacker cannot force "bad" values that will reveal the private key. Sec. 9.3 mentions that each party should check that the received value is in the group. Is this sufficient? - 4.1: is group element -> is a group element - 4.2: since all group operations have been defined in terms of full point (x and y), it is unclear how "compact representation" works, i.e. how both parties compute the shared secret when only X values are transmitted. - 7.1: when the dust around RFC 4735, its errata etc. settles, IKE (v1 and v2) will use compact output. Thanks, Yaron _______________________________________________ Cfrg mailing list Cfrg@irtf.org http://www.irtf.org/mailman/listinfo/cfrg Scanned by Check Point Total Security Gateway. ------=_NextPart_001_00F5_01CA1166.B0FFF020 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi = David,

 

I don’t know if there’s = a good answer, I believe the answer is essentially that there are several = implementations already using the compact representation. And that is also what = http://to= ols.ietf.org/html/draft-solinas-rfc4753bis-00, currently in IETF last call, specifies.

 

Thanks,

           = ; Yaron

 


From: David = McGrew [mailto:mcgrew@cisco.com]
Sent: Thursday, July 30, = 2009 20:34
To: Yaron Sheffer
Cc: cfrg@irtf.org
Subject: Re: [Cfrg] = Comments on draft-mcgrew-fundamental-ecc-00.txt

 

Hi Yaron,

 

many thanks for your useful comments, they will improve the next version of the draft.  

 

If there is uncertainty about whether or not IKE uses compact = output for ECDH, I wonder: why don't we just not use it?  It is probably = the simpler option, at least conceptually. =  

 

Sorry for the slow reply, I have been on vacation recently. =  

 

David

 

On Jul 8, 2009, at 8:54 AM, Yaron = Sheffer wrote:



First and foremost, I would like = to thank the author for making this compilation available to the community. It = certainly helps to cut through some of the IPR = fog.

 

- Sec. 2.1: Using Zp for a general = group (not necessarily of prime order) is confusing. Can we have Zn = instead?

- 2.1: with all due respect, Knuth = is probably unavailable to most of our readers. There must have been = something published in the last 28 years to replace = it...

- 2.2: similarly for Deskins. Or = (if the pre-1994 provenance is critical) add a reference to some modern tutorial coverage. Cormen, Leiserson, Rivest and Stein chapter 31, for example. = Or better still, a URL.

- 3: the formula pair for x3, y3 = "if P is equal to Q" (the last one) is confusing, since the preceding = formula refers to a sub-case of this case. Maybe change to = "otherwise", or "if P is equal to Q and the previous condition does not = hold".

- General: the term "characteristic" (and once, "character") is used = multiple times without definition.

- 3.2: "the order n" = (not indented, by the way) - is it part of the specification, or a dependent property = of the group which is defined by the other = parameters?

- 4: can you say something about = the security of ECDH? Specifically, are there validity checks required by = both parties on the other party's value, so that an attacker cannot force "bad" values that will reveal the private key. Sec. 9.3 = mentions that each party should check that the received value is in the group. Is this sufficient?

- 4.1: is group element -> is a = group element

- 4.2: since all group operations = have been defined in terms of full point (x and y), it is unclear how = "compact representation" works, i.e. how both parties compute the shared = secret when only X values are transmitted.

- 7.1: when the dust around RFC = 4735, its errata etc. settles, IKE (v1 and v2) will use compact = output.

 

Thanks,<= font color=3Dblack>

      = ;      Yaron

____________= ___________________________________
Cfrg mailing list
Cfrg@irtf.org
http://www.irtf.org/ma= ilman/listinfo/cfrg

 



Scanned by Check Point Total Security Gateway. =

------=_NextPart_001_00F5_01CA1166.B0FFF020-- ------=_NextPart_000_00F4_01CA1166.B0FFF020 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPTTCCBDIw ggMaoAMCAQICAQEwDQYJKoZIhvcNAQEFBQAwezELMAkGA1UEBhMCR0IxGzAZBgNVBAgMEkdyZWF0 ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBwwHU2FsZm9yZDEaMBgGA1UECgwRQ29tb2RvIENBIExpbWl0 ZWQxITAfBgNVBAMMGEFBQSBDZXJ0aWZpY2F0ZSBTZXJ2aWNlczAeFw0wNDAxMDEwMDAwMDBaFw0y ODEyMzEyMzU5NTlaMHsxCzAJBgNVBAYTAkdCMRswGQYDVQQIDBJHcmVhdGVyIE1hbmNoZXN0ZXIx EDAOBgNVBAcMB1NhbGZvcmQxGjAYBgNVBAoMEUNvbW9kbyBDQSBMaW1pdGVkMSEwHwYDVQQDDBhB QUEgQ2VydGlmaWNhdGUgU2VydmljZXMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC+ QJ30buHqdoccTUVEjr5GyIMGncEq/hgfjuQC+vOrXVCKFjELmgbQxXAizUktVGPMtm5oRgtT6stM JMC8ck7q8RWu9FSaEgrDerIzYOLaiVXzIljz3tzP74OGooyUT59o8piQRoQnx3a/48w1LIteB2Rl gsBIsKiR+WGfdiBQqJHHZrXreGIDVvCKGhPqMaMeoJn9OPb2JzJYbwf1a7j7FCuvt6rM1mNfc4za BZmoOKjLF3g2UazpnvR4Oo3PD9lC4pgMqy+fDgHe75+ZSfEt36x0TRuYtUfF5SnR+ZAYx2KcvoPH Jns+iiXHwN2d5jVoECCdj9je0sOEnA1e6C/JAgMBAAGjgcAwgb0wHQYDVR0OBBYEFKARCiM+lvEH 7OKvKe+CpX/QMKS0MA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MHsGA1UdHwR0MHIw OKA2oDSGMmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0FBQUNlcnRpZmljYXRlU2VydmljZXMuY3Js MDagNKAyhjBodHRwOi8vY3JsLmNvbW9kby5uZXQvQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmww DQYJKoZIhvcNAQEFBQADggEBAAhW/ALwm+j/pPrWe8ZEgM5PxMX2AFjMpra8FEloBHbo5u5d7AIP YNaNUBhPJk4B4+awpe6/vHRUQb/9/BK4x09a9IlgBX9gtwVK8/bxwr/EuXSGti19a8zS80bdL8bg asPDNAMsfZbdWsIOpwqZwQWLqwwv81w6z2w3VQmH3lNAbFjv/LarZW4E9hvcPOBaFcae2fFZSDAh ZQNs7Okhc+ybA6HgN62gFRiP+roCzqcsqRATLNTlCCarIpdg+JBedNSimlO98qlo4KJuwtdssaMP nr/raOdW8q7y4ys4OgmBtWuF174t7T8at7Jj4vViLILUagBBUPE5g5+V6TaWmG4wggTdMIIDxaAD AgECAhBxkvvmGV+sTRKFdHE0ohinMA0GCSqGSIb3DQEBBQUAMHsxCzAJBgNVBAYTAkdCMRswGQYD VQQIDBJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcMB1NhbGZvcmQxGjAYBgNVBAoMEUNvbW9k byBDQSBMaW1pdGVkMSEwHwYDVQQDDBhBQUEgQ2VydGlmaWNhdGUgU2VydmljZXMwHhcNMDQwMTAx MDAwMDAwWhcNMjgxMjMxMjM1OTU5WjCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYD VQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYD VQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xp ZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBALI5haTyfatBO2JGN67NwWB1vDll+UoaR6K5zEjMapjVTTUZuaRC5c5J4oovHnzSMQfHTrSD ZJ0uKdWiZMSFvYVRNXmkTmiQexx6pJKoF/KYFfKTzMmkMpW7DE8wvZigC4vlbhuiRvp4vKJvq1le pS/Pytptqi/rrKGzaqq3Lmc1i3nhHmmI4uZGzaCl6r4LznY6eg6b6vzaJ1s9cx8i5khhxkzzabGo Lhu21DEgLLyCio6kDqXXiUP8FlqvHXHXEVnauocNr/rz4cLwpMVnjNbWVDreCqS6A3ezZcj9HtN0 YqoYymiTHqGFfvVHZcv4TVcodNI0/zC27vZiMBSMLOsCAwEAAaOCAScwggEjMB8GA1UdIwQYMBaA FKARCiM+lvEH7OKvKe+CpX/QMKS0MB0GA1UdDgQWBBSJgmd9xJ0mcABLtFBIfN49rgRufTAOBgNV HQ8BAf8EBAMCAQYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwEQYDVR0gBAowCDAGBgRVHSAAMHsGA1UdHwR0MHIwOKA2oDSGMmh0dHA6Ly9jcmwuY29tb2Rv Y2EuY29tL0FBQUNlcnRpZmljYXRlU2VydmljZXMuY3JsMDagNKAyhjBodHRwOi8vY3JsLmNvbW9k by5uZXQvQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmwwEQYJYIZIAYb4QgEBBAQDAgEGMA0GCSqG SIb3DQEBBQUAA4IBAQCdlcs8uH6lCcQevwvCx3aOOTyUxhCqTwzJ4KuEXYlU4GU7820cfDcsJVRf liH8N4SRnRXcFE+Bz1Qda2xFYMct+ZdRTPlmyjyggoymyPDi6dRK+ew/VsnddozDggFPbADzHhph dARHA6nGQFeRvGUixSdnT1fbZFrZjR+6hi/0Bq6cae3p9M8pF9jgSp8aIC+XTFG7RgfEijdOIOMJ MWjHnsSLneh+EbwyaBCWEZhE2CpRYE2I63Q630MGMsg5Vow6EVLTQaRDA/Tt7zMn2zngFE4mydj1 OeKJuJNdtykmQeqzm66D/Hd1yujKtf7iZUpjPkTE0MNeh3OpmByvfxV/MIIGMjCCBRqgAwIBAgIR AIDKyDfd56zXUq4aqXlC1iYwDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQI EwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0 d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNF UkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwwHhcNMDgwOTEwMDAwMDAwWhcN MDkwOTEwMjM1OTU5WjCB3jE1MDMGA1UECxMsQ29tb2RvIFRydXN0IE5ldHdvcmsgLSBQRVJTT05B IE5PVCBWQUxJREFURUQxRjBEBgNVBAsTPVRlcm1zIGFuZCBDb25kaXRpb25zIG9mIHVzZTogaHR0 cDovL3d3dy5jb21vZG8ubmV0L3JlcG9zaXRvcnkxHzAdBgNVBAsTFihjKTIwMDMgQ29tb2RvIExp bWl0ZWQxFjAUBgNVBAMTDVlhcm9uIFNoZWZmZXIxJDAiBgkqhkiG9w0BCQEWFXlhcm9uZkBjaGVj a3BvaW50LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALqGr14AEP/lS7OgXTYs 8LjmDZYg3KegpdGXufAXa93NbmAAQ1EmqkVBw8vC/EcYCM+D9uUWeK0uC7BpmCalFDh28AMMIUKI W0VGvDF+kE8zjnch/j7whoWvOvj6yFxYZNe9zfUlZZ7xBc+LEPzqsd4oLbK7a7WkvZAuUHfH0oiH k2miEZkXZF/mhpGp/LplLeA8b51fvQhv8UqIzwRghVTLDCAnIhVk/w+WMmRhcHptYZDa0gOhjyza a/4kG1oHw44Ae9cZpws8TXL+JOrUdmJG6uFY3wB0YvPw9b/u0WeY7Snq0bDF58vDNw0jaQsfIoxx EE+MscA9JbuaPaXIFdkCAwEAAaOCAhcwggITMB8GA1UdIwQYMBaAFImCZ33EnSZwAEu0UEh83j2u BG59MB0GA1UdDgQWBBSNbKhiJVIDkhy5HRA+njy+oWiKMDAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0T AQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQD AgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2Vj dXJlLmNvbW9kby5uZXQvQ1BTMIGlBgNVHR8EgZ0wgZowTKBKoEiGRmh0dHA6Ly9jcmwuY29tb2Rv Y2EuY29tL1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwSqBI oEaGRGh0dHA6Ly9jcmwuY29tb2RvLm5ldC9VVE4tVVNFUkZpcnN0LUNsaWVudEF1dGhlbnRpY2F0 aW9uYW5kRW1haWwuY3JsMGwGCCsGAQUFBwEBBGAwXjA2BggrBgEFBQcwAoYqaHR0cDovL2NydC5j b21vZG9jYS5jb20vVVROQUFBQ2xpZW50Q0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5j b21vZG9jYS5jb20wIAYDVR0RBBkwF4EVeWFyb25mQGNoZWNrcG9pbnQuY29tMA0GCSqGSIb3DQEB BQUAA4IBAQBemghknp7tCcWJ+Pzvopk4bHBaaYF/NJtkrSLXJdOb8p286uOS+7po0DIE+zh9iIyV MTq5GFkleVzIVQHWOIOfCMnxbYh6tgrJUZKdDHMJG2vhz2i2dFOJzWnMnosWmKsDDMpmtLMH1mn+ 31lQkp+rgUAkuFUruAPrG6ms5BVaO/Ta+yBGdEJ0ecLOKuA3zmKnmy8beceXpm4OdkBGWWdLvBGu P/+v8n8KwVf2zzNTaZeEy+139MH9GTrVTiHnOsgdkvvsTu7cAl3mhRxR+o60XU0fQdk3jtbPrzeF uK5fTY6yKlW2e/rlJg3hAr3FkIpszNRgnu+BUDYFg9VnYjjYMYIEaDCCBGQCAQEwgcQwga4xCzAJ BgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoT FVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29t MTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwC EQCAysg33ees11KuGql5QtYmMAkGBSsOAwIaBQCgggJ4MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTA5MDczMDIwNDAwOFowIwYJKoZIhvcNAQkEMRYEFFKqujYt07PI 3SEZ57ZITqYamL4dMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCA MA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3 DQIFMIHVBgkrBgEEAYI3EAQxgccwgcQwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUG A1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8G A1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNs aWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwCEQCAysg33ees11KuGql5QtYmMIHXBgsqhkiG 9w0BCRACCzGBx6CBxDCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0 IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRw Oi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhl bnRpY2F0aW9uIGFuZCBFbWFpbAIRAIDKyDfd56zXUq4aqXlC1iYwDQYJKoZIhvcNAQEBBQAEggEA igB0ssCDFewuSszMDRleOGAQQTYJcBcOmGCh7whW4M+wxiDjS0l1EV6tn8LrX/T/b2/JdBudpXEl /+L8mju1FqxkrK2/vUUavLSV6AL2tdSuIWvK2qtau4cD1xJu830BTL1muJyr+P8tZFdr8WlMtaPO KPhpRbGuU5OXqD8TeB4uwbUpoWHY8LcUJCMYaXsm7wC17vW6Y4jL33/9RwE878A/Zky1PR7NFFJl 93vC9t/XMguQ9XbyOWzH3WZfsN9liVgvHDCfmnSyiqv9FVrGX3hGJnWJQIVA8XpubP7JyIX5qFg1 AQUhu7+C5s+PObvoGuwUwiDIZEiqetkdxcYW4QAAAAAAAA== ------=_NextPart_000_00F4_01CA1166.B0FFF020-- From ashot@motorola.com Thu Jul 30 14:30:59 2009 Return-Path: X-Original-To: cfrg@core3.amsl.com Delivered-To: cfrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 73A013A68E0 for ; Thu, 30 Jul 2009 14:30:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.51 X-Spam-Level: X-Spam-Status: No, score=-6.51 tagged_above=-999 required=5 tests=[AWL=0.088, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sIqC2aD7mfbD for ; Thu, 30 Jul 2009 14:30:58 -0700 (PDT) Received: from mail55.messagelabs.com (mail55.messagelabs.com [216.82.241.163]) by core3.amsl.com (Postfix) with ESMTP id EF3A03A6C4F for ; Thu, 30 Jul 2009 14:30:57 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: ashot@motorola.com X-Msg-Ref: server-9.tower-55.messagelabs.com!1248989436!77011238!1 X-StarScan-Version: 6.0.0; banners=-,-,- X-Originating-IP: [136.182.1.14] Received: (qmail 9297 invoked from network); 30 Jul 2009 21:30:50 -0000 Received: from motgate4.mot.com (HELO motgate4.mot.com) (136.182.1.14) by server-9.tower-55.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 30 Jul 2009 21:30:50 -0000 Received: from il27exr03.cig.mot.com (il27exr03.mot.com [10.17.196.72]) by motgate4.mot.com (8.14.3/8.14.3) with ESMTP id n6ULUIlV000442 for ; Thu, 30 Jul 2009 14:30:31 -0700 (MST) Received: from il27vts01 (il27vts01.cig.mot.com [10.17.196.85]) by il27exr03.cig.mot.com (8.13.1/Vontu) with SMTP id n6ULUICr023096 for ; Thu, 30 Jul 2009 16:30:18 -0500 (CDT) Received: from ct11exm60.ds.mot.com (CT11EXM60.am.mot.com [10.177.8.44]) by il27exr03.cig.mot.com (8.13.1/8.13.0) with ESMTP id n6ULUIIb023085 for ; Thu, 30 Jul 2009 16:30:18 -0500 (CDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA115C.E25FE2CA" Date: Thu, 30 Jul 2009 17:30:21 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Cfrg] IKEv1 and 800-56A Thread-Index: AcoRUculMURgWAm5RLKryLsHIz5TkwACprEw References: From: "Andreasyan Ashot-C23793" To: "David McGrew" X-CFilter-Loop: Reflected Cc: cfrg@irtf.org Subject: Re: [Cfrg] IKEv1 and 800-56A X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2009 21:30:59 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA115C.E25FE2CA Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi David, =20 Thank you for your response.=20 =20 I have already read that paper and it looks like they are OK for now with IKEv1 KDF but you are right that consolidation is long term project and IETF needs to take care. =20 Ashot ________________________________ From: David McGrew [mailto:mcgrew@cisco.com]=20 Sent: Thursday, July 30, 2009 1:10 PM To: Andreasyan Ashot-C23793 Cc: cfrg@irtf.org Subject: Re: [Cfrg] IKEv1 and 800-56A Hi Ashot,=20 On Jul 28, 2009, at 1:31 PM, Andreasyan Ashot-C23793 wrote: Hi All, =20 Recently NIST published "Recommendation for Pair-Wise Key Establishment Schemes Using Discrete Logarithm Cryptography" =09 http://csrc.nist.gov/publications/nistpubs/800-56A/SP800-56A_Revision1_M ar08-2007.pdf =20 How does this this document is going to interconnect with IKEv1? that's a good question. The Diffe-Hellman protocols in the NIST key management documents are based on ANSI and IEEE standards that were developed concurrently with ISAKMP/OAKLEY/IKE. They are functionally equivalent in some ways, but they are different and incompatible in other ways. =20 Personally, I would like to see these standards be reconciled, with preference going towards what they industry is actually implementing and using whenever it is reasonably secure. I would expect this reconciliation to be a long term project. Other opinions are welcome. If you are interested in the NIST key management documents, you might want to review the NIST White Paper on transitioning algorithms and key sizes, see http://csrc.nist.gov/groups/ST/key_mgmt/ Note that the review period closes on August 3. David =20 =20 Thanks, Ashot=20 =20 _______________________________________________ Cfrg mailing list Cfrg@irtf.org http://www.irtf.org/mailman/listinfo/cfrg =09 ------_=_NextPart_001_01CA115C.E25FE2CA Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi David,
 
Thank you for your response. =
 
I have already read that paper and it = looks like they=20 are OK for now with IKEv1 KDF but
you are right that consolidation = is long term=20 project and IETF needs to take care.
 
Ashot

From: David McGrew = [mailto:mcgrew@cisco.com]=20
Sent: Thursday, July 30, 2009 1:10 PM
To: = Andreasyan=20 Ashot-C23793
Cc: cfrg@irtf.org
Subject: Re: [Cfrg] = IKEv1 and=20 800-56A

Hi Ashot,

On Jul 28, 2009, at 1:31 PM, Andreasyan Ashot-C23793 = wrote:
Hi All,
 
Recently NIST published=20 "Recommendation for Pair-Wise = Key Establishment Schemes = Using Discrete Logarithm = Cryptography"
http://csrc.nist.gov/publications/nistpubs/800-56A/= SP800-56A_Revision1_Mar08-2007.pdf
 
How does this this = document is=20 going to interconnect with = IKEv1?

that's a good question.  The Diffe-Hellman protocols in the = NIST key=20 management documents are based on ANSI and IEEE standards that were = developed=20 concurrently with ISAKMP/OAKLEY/IKE.  They are functionally = equivalent in=20 some ways, but they are different and incompatible in other ways. =  

Personally, I would like to see these standards be reconciled, with = preference going towards what they industry is actually implementing and = using=20 whenever it is reasonably secure.   I would expect this = reconciliation to=20 be a long term project.   Other opinions are welcome.

If you are interested in the NIST key management documents, you = might want=20 to review the NIST White Paper on transitioning algorithms and key = sizes,=20 see http://csrc.nist.gov/gr= oups/ST/key_mgmt/=20    Note that the review period closes on August 3.

David

 
 
Thanks,
Ashot
 
_______________________________________= ________
Cfrg=20 mailing list
Cfrg@irtf.org
http://www.irtf.org/ma= ilman/listinfo/cfrg

------_=_NextPart_001_01CA115C.E25FE2CA-- From lloyd@randombit.net Fri Jul 31 12:35:34 2009 Return-Path: X-Original-To: cfrg@core3.amsl.com Delivered-To: cfrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A52103A6D56 for ; Fri, 31 Jul 2009 12:35:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N0VXDlUA6zL8 for ; Fri, 31 Jul 2009 12:35:34 -0700 (PDT) Received: from mail.randombit.net (chihiro.randombit.net [69.48.226.76]) by core3.amsl.com (Postfix) with ESMTP id 077EE3A68D9 for ; Fri, 31 Jul 2009 12:35:33 -0700 (PDT) Received: by mail.randombit.net (Postfix, from userid 1000) id BEF261C8056; Fri, 31 Jul 2009 15:35:35 -0400 (EDT) Date: Fri, 31 Jul 2009 15:35:35 -0400 From: Jack Lloyd To: Basil Dolmatov Message-ID: <20090731193535.GQ3413@randombit.net> References: <4A336353.2070309@cryptocom.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4A336353.2070309@cryptocom.ru> X-PGP-Fingerprint: 3F69 2E64 6D92 3BBE E7AE 9258 5C0F 96E8 4EC1 6D6B X-PGP-Key: http://www.randombit.net/pgpkey.html User-Agent: Mutt/1.5.16 (2007-06-09) Cc: cfrg@irtf.org Subject: Re: [Cfrg] [saag] GOST algorithms descriptions X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jul 2009 19:35:34 -0000 On Sat, Jun 13, 2009 at 12:29:07PM +0400, Basil Dolmatov wrote: > Hello, > > the fact that the GOST cryptography algorithms descriptions are not easily > accessible in English was repeatedly mentioned when discussing related > subjects. > Now, these descriptions are posted as I-Ds, we hope that will serve the > community to get acquianted more closely with these sets of widely used > algorithms. > > http://www.ietf.org/internet-drafts/draft-dolmatov-cryptocom-gost341194-00.txt > > > http://www.ietf.org/internet-drafts/draft-dolmatov-cryptocom-gost34102001-00.txt > The examples use a set of sboxes for GOST-28147 which are referred to in RFC 4375 as id-GostR3411-94-TestParamSet, whereas the text of RFC 4375 itself uses the other param set (id-GostR3411-94-CryptoProParamSet) in all situations. Given that all (?) IETF GOST standards use this param set, why not provide test vectors for it rather than the (otherwise unused) TestParamSet? Regards, Jack Lloyd