From nobody Fri Apr 1 08:24:42 2016 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F037F12D668 for ; Fri, 1 Apr 2016 08:24:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.207 X-Spam-Level: X-Spam-Status: No, score=-4.207 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9adhVvE8hUqo for ; Fri, 1 Apr 2016 08:24:39 -0700 (PDT) Received: from llmx2.ll.mit.edu (LLMX2.LL.MIT.EDU [129.55.12.48]) by ietfa.amsl.com (Postfix) with ESMTP id 936E612D681 for ; Fri, 1 Apr 2016 08:24:23 -0700 (PDT) Received: from LLE2K10-HUB01.mitll.ad.local (LLE2K10-HUB01.mitll.ad.local) by llmx2.ll.mit.edu (unknown) with ESMTP id u31FNC0u007426; Fri, 1 Apr 2016 11:23:12 -0400 From: "Blumenthal, Uri - 0553 - MITLL" To: Tony Arcieri , "cfrg@irtf.org" Thread-Topic: [Cfrg] OCB patents expired? Thread-Index: AQHRi8nPAwdfsRQg90eNWEdSm8HM9Z91PX6A Date: Fri, 1 Apr 2016 15:24:21 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.2.160219 x-originating-ip: [172.25.177.51] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha384; boundary="B_3542354649_15160372" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-04-01_06:, , signatures=0 X-Proofpoint-Spam-Details: rule=inbound_notspam policy=inbound score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1601100000 definitions=main-1604010218 Archived-At: Subject: Re: [Cfrg] OCB patents expired? X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Apr 2016 15:24:41 -0000 --B_3542354649_15160372 Content-type: multipart/alternative; boundary="B_3542354649_15138243" --B_3542354649_15138243 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable > According to the USPTO, patents 7046802 and 7200227 on OCB mode have expi= red > due to non-payment. >=20 > I'm aware there's already a TLS exemption, but this seems like it should = open > up OCB mode for use in all protocols. I=E2=80=99d love to see OCB used wider. --B_3542354649_15138243 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable
Accord= ing to the USPTO, patents 7046802 and 7200227 on OCB mode have expired due t= o non-payment.

I'm aware there's already a TLS exemption, but this see= ms like it should open up OCB mode for use in all protocols.

<= div>
I’d love<= /u> to see OCB used wider. 
--B_3542354649_15138243-- --B_3542354649_15160372 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIQ4AYJKoZIhvcNAQcCoIIQ0TCCEM0CAQExDzANBglghkgBZQMEAgIFADALBgkqhkiG9w0B BwGggg6fMIIE6jCCA9KgAwIBAgIKMztKZQAAAABumTANBgkqhkiG9w0BAQsFADBRMQswCQYD VQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJ MRMwEQYDVQQDEwpNSVRMTCBDQS0zMB4XDTE2MDExNDE3MzMzN1oXDTE5MDExMzE3MzMzN1ow YTELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDzANBgNV BAsTBlBlb3BsZTEgMB4GA1UEAxMXQmx1bWVudGhhbC5VcmkuNTAwMTA1ODQwggEiMA0GCSqG SIb3DQEBAQUAA4IBDwAwggEKAoIBAQDqifs8K0OoodbmOo5G/j2+p2ibbOsEoJ9GJjK8K1Iw 6iig59a3EuNB6NR4tAR3INwjjUwMCa4o8ysnk1hN32B3HPrK5Z8++Y/xcX5iP1L6fc51YQ5C /EGvrSbjuPLvt19SNfVdwcuoc842Sgk9N/HemdwmvcqJkwzWDsuxKikI2clT1N5LTAaPMkhr HVuYOHBE0mCXjHjFnYuHsEXyVvUZLxziDgduV9WKbC90Z1NZMXB6ZeQTACUWgMfpFrE12LKb fvOmxepCBfCPbGB3ZyG+FaUdtQoCEAbGTnY7nCedQFn7pV1hppCt4jjLVlOpgYc3dPmyiXsL nhDQZ5ptmks/AgMBAAGjggGyMIIBrjAdBgNVHQ4EFgQUiXqPublGfd0sWKNk/BObT6Oorzgw DgYDVR0PAQH/BAQDAgbAMB8GA1UdIwQYMBaAFNdgZg57SY11TA39z0beyMcSh8q/MDMGA1Ud HwQsMCowKKAmoCSGImh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXRjcmwvTExDQTMwZgYIKwYB BQUHAQEEWjBYMC0GCCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8vTExD QTMwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLmxsLm1pdC5lZHUvb2NzcDA9BgkrBgEEAYI3 FQcEMDAuBiYrBgEEAYI3FQiDg+Udh+ynZoathxWD6vBFhbahHx2Fy94yh/+KcwIBZAIBBjAi BgNVHSUBAf8EGDAWBggrBgEFBQcDBAYKKwYBBAGCNwoDDDAYBgNVHSAEETAPMA0GCyqGSIb3 EgIBAwEIMBkGA1UdEQQSMBCBDnVyaUBsbC5taXQuZWR1MCcGCSsGAQQBgjcUAgQaHhgATABM AFUAcwBlAHIAUwBpAGcALQBTAFcwDQYJKoZIhvcNAQELBQADggEBAK7HM6o1IolvkCJrlsjj N1+0Z2JG8anwkHkVKAg/K9qUD0LE9zbnK3kZRGZsljJUDG+hMWmTWCkx0TTzbg/BeVrypVPD 7rn1Tagi9QBV2eJhdBZRHWOcsteRldUukKbMw74hkNGH9o/p/FFZYMA0kHnA7XfECilF9Yl6 uKDv1lbjuWdgcKD1FdEj7rL/IdX0wKJVUKjwLG1RQZel1nuwyRjVtXWz8IUMJXRsYHf6uSzy YoNBeZuWyMx/J5c0ACKXXs1O721GPJ5U5gcEaQ/b8lwQGcOgPk28RPwgiBF3f5TgrTa7QxGf ozmNsTj1OV1vU0vjqKrg7USi9q0xTdGUIyowggS8MIIDpKADAgECAgEpMA0GCSqGSIb3DQEB BQUAMFQxCzAJBgNVBAYTAlVTMR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQww CgYDVQQLEwNQS0kxFjAUBgNVBAMTDU1JVExMIFJvb3QgQ0EwHhcNMTMxMjE3MDAwMDAwWhcN MjAxMjMxMjM1OTU5WjBRMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFi b3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBDQS0zMIIBIjANBgkqhkiG 9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2jBSdW18tuW1tNxG6h8B0kqckFZQAAtoHCkvUpUEX6jF vBd8mQI53GyLYRuAo4HWJpe7/izFXOfSJDs6UM5ovvCOfXg2bJgDYlBC9JDcLBFIn0nppOu9 RvpjWSixtC56crwJ5Us5QPdtxtKdek5LJXl2oKw3w8lihUixePbxWad1m7ZMKKagvm9zTybP 6FumKRxeYJjSpB2+cAYjoGGEbSVHyx8uzHm6xAoBMHxa8by+yDz8Jzk6sP9iilgP3iXSGoCA mhyBzvlQQ5QNNWP+Emo9jz/ukKhYVB/VwdxtoquPAqn4ifDAIaM9dtb05cy1gXAFSP3Z/iUk xyBZZUORfwIDAQABo4IBmjCCAZYwEgYDVR0TAQH/BAgwBgEB/wIBADAdBgNVHQ4EFgQU12Bm DntJjXVMDf3PRt7IxxKHyr8wHwYDVR0jBBgwFoAUZ6p6z/QKprlytYqg0p3yEMND7SkwDgYD VR0PAQH/BAQDAgGGMGYGCCsGAQUFBwEBBFowWDAtBggrBgEFBQcwAoYhaHR0cDovL2NybC5s bC5taXQuZWR1L2dldHRvP0xMUkNBMCcGCCsGAQUFBzABhhtodHRwOi8vb2NzcC5sbC5taXQu ZWR1L29jc3AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC5sbC5taXQuZWR1L2dldGNy bD9MTFJDQTCBkgYDVR0gBIGKMIGHMA0GCyqGSIb3EgIBAwEGMA0GCyqGSIb3EgIBAwEIMA0G CyqGSIb3EgIBAwEHMA0GCyqGSIb3EgIBAwEJMA0GCyqGSIb3EgIBAwEKMA0GCyqGSIb3EgIB AwELMA0GCyqGSIb3EgIBAwEOMA0GCyqGSIb3EgIBAwEPMA0GCyqGSIb3EgIBAwEQMA0GCSqG SIb3DQEBBQUAA4IBAQAsf9HBn72qU7UTgkxarjAc7iynhcDEgWwezYKtd/SLGSQ0DhtzIV/L TCxqULjOd+H+HTqMJXB8+nHnzhyqQ43RsnGZOFT5RfzPh94db/ZJ3ql244DwlJI7yXBA2DkZ cEEgOWC9bHcrElzU6NnigahSW5odVJrhmH/XhQAcMS77E5H62yyxK1WPPgcBipGVnu1xSHbT iHe7DqfWQ2tVMLUf23XYhIua94kJsQd4jSh71NVD0e7F4snAoqQMI98MzDYeLOkjlzKRs77r /aMsPAKx6nMaOvRL7Cy0Pjp51i2qFkbGmX8ofnh2kerjTTvRJ/g22r1MV8RR1PktjMsNOsPf MIIE7TCCA9WgAwIBAgIKMziUjwAAAABuljANBgkqhkiG9w0BAQsFADBRMQswCQYDVQQGEwJV UzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYD VQQDEwpNSVRMTCBDQS0zMB4XDTE2MDExNDE3MzAzOVoXDTE5MDExMzE3MzAzOVowYTELMAkG A1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDzANBgNVBAsTBlBl b3BsZTEgMB4GA1UEAxMXQmx1bWVudGhhbC5VcmkuNTAwMTA1ODQwggEiMA0GCSqGSIb3DQEB AQUAA4IBDwAwggEKAoIBAQDjFDaGib07mHBdNaVMNpj9+4iJa+K9AcTN3y+iU1ygtvHG4cot eDBf77ZN1uwdt+lodW0C8XyG43suSfpNp/owLOUElFagAnPqHAvAUIwsl5AjzncpJP+78Ui4 u34aMNsddP+QZu9HI2Qg+P6eMD25jkjybT9dQMxXZpO2oTBznlWjYIItdZhK1DWZqIR0at7n 2YjCSQsZNX0lJ4JwrtjHYFrYPnnZC0f1B2M7V54IS863CEyfu5XotoZx8YuHwYpKSFq80SEh 6cMDLdTe1ZAjWxsnbyKC64rreStyI2PVN9uBWd+OleGoIAjVogpMKKi0pSRHcCuwDwGekpQV ubK9AgMBAAGjggG1MIIBsTAdBgNVHQ4EFgQU8U/FiJmibLZl2+KcNbVWE2PZipswDgYDVR0P AQH/BAQDAgUgMB8GA1UdIwQYMBaAFNdgZg57SY11TA39z0beyMcSh8q/MDMGA1UdHwQsMCow KKAmoCSGImh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXRjcmwvTExDQTMwZgYIKwYBBQUHAQEE WjBYMC0GCCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8vTExDQTMwJwYI KwYBBQUHMAGGG2h0dHA6Ly9vY3NwLmxsLm1pdC5lZHUvb2NzcDA9BgkrBgEEAYI3FQcEMDAu BiYrBgEEAYI3FQiDg+Udh+ynZoathxWD6vBFhbahHx2F69Bwg+vtIAIBZAIBBTAlBgNVHSUE HjAcBgRVHSUABggrBgEFBQcDBAYKKwYBBAGCNwoDBDAYBgNVHSAEETAPMA0GCyqGSIb3EgIB AwEIMBkGA1UdEQQSMBCBDnVyaUBsbC5taXQuZWR1MCcGCSsGAQQBgjcUAgQaHhgATABMAFUA cwBlAHIARQBuAGMALQBTAFcwDQYJKoZIhvcNAQELBQADggEBABbuvs9m0gS5U8JJuVc+qttV 2BWQ0jDepXpYfP/xN8rVScRPHe2SMUaFH5OMRhheGJkdogWVNnMrjHxQfpfc0z8yotlD3xwX ENWUY5MoQmpEGB2ksFqgMd121bqzR3WY84Lcosfow0MoplXs8mvO7TnozwM+PtGZs0mpp2Pz BkvWdNbs2r/7wXJP6/pLd5zPvywRNhTgoVe1aN4ivIkU8svkKMggv5ZaOsonaW8JS6dUYmvv k0QvDJRIQNRR0zpQpOKp+4V/XhMZRhxQJ3DjVTjh9Q/pHKm7ARFhFr3QAJ6ocCjyzLF5issa 1Vshx7ElBIk0cXhep6mLMLqGNX3azAkxggIFMIICAQIBATBfMFExCzAJBgNVBAYTAlVTMR8w HQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxEzARBgNVBAMT Ck1JVExMIENBLTMCCjM7SmUAAAAAbpkwDQYJYIZIAWUDBAICBQCgeTA/BgkqhkiG9w0BCQQx MgQwombCkAIJ9Bp68hCfw7H1rSNtY7+7dM1nT/no0gjY0k0FwdyyGP6oOdH6OxnBAsmfMBgG CSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE2MDQwMTE1MjQwOVow DQYJKoZIhvcNAQEBBQAEggEAFJWk+cd1nq6TY7ALP/LpkENP35nwuPsCTZ+5xTeVGopC4tVH ja1i7PVaamRHKdLQrb3DlNuW6MYo7DfHuscdVGoeAY6Tae/3K+UOJ93G7GRhY5F+2gyzvJQw hHIGQ544Fs5qQ57H236mQ8DHoY+jqC0y55xJ2NOvZ7fSBwZQVjBChu/ZsvOSrCoyuoOT3rkF bKsSZvAcuSC3wo40ZcwTIeLQO0Q8duEQ/aIaJXOvgwo8iWe2hwR6wncvhQ/tTlKYHMyBWRfU RfjORjl7BBymYFcXVab/W3wt8+i0u/9vUMJ7oRv6nnH16awloat31ryaw3HdHFORxDQ1nSDt SYkT4w== --B_3542354649_15160372-- From nobody Fri Apr 1 08:58:12 2016 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DD4812D183 for ; Fri, 1 Apr 2016 08:58:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=securityinnovation.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id htOZSAZGRiVh for ; Fri, 1 Apr 2016 08:58:08 -0700 (PDT) Received: from mail-oi0-x22c.google.com (mail-oi0-x22c.google.com [IPv6:2607:f8b0:4003:c06::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7380812D6EF for ; Fri, 1 Apr 2016 08:58:04 -0700 (PDT) Received: by mail-oi0-x22c.google.com with SMTP id r187so111189059oih.3 for ; Fri, 01 Apr 2016 08:58:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=securityinnovation.com; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=cxWDCIR/UvnrtNL08uquZ7xWEdM7FIFtHUD3us5TY9s=; b=ZAhGcgPEmpQ9lUXpMXVtlJoW+fDGDUHeQpxhfudTdsmaJDsT5rYOHkr8T3NQzP0kbQ lY52H+KpqWfaI+X+hBTU4Ptw8nOyiofhAgrn540750jJtJ8/5/p9k4R9XTYwnS+hG+Wq y8Oi9qWjhWKJ3BheIC/3/T1N5cnz437gaUW2w= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=cxWDCIR/UvnrtNL08uquZ7xWEdM7FIFtHUD3us5TY9s=; b=kOD00mJdXfafLGPvqEH9OZ2pWG7tFLXldVYDS/YW+Qh6QpBTx8ZltuxkZ3RfnWuinh B3C4WWqVSnCFbnk3UFnjNAiQFeFmxHsaoPL0LPCFi/RQUj4adS2a34Qdd32EDcSiSlyp MtJmZu3FpiEVlbPYldwnxJbpltbv0cOZM8NdtBMJhmNGjOJgBMbHxXRRiR641VDD4Tj2 cTtIGZ9dK+EJvtaxQnPfEFrKuydxK5IDEY4/vsVadUIyejsPdLKyOYdIpX6jF8ef7Uyq +jMyM1UhJsmR6pTTuVWgsnl4Eat3mlvvF2gWQt53UDTD4V2giblLuLmUT9N9JWu2Nxgt rX4A== X-Gm-Message-State: AD7BkJIg+HJPwtsIZ0MNLQ+RezFCpoLPMeY2pYNHjlIK+YZHUQE06+RljQu5JzU3CTDKI7oompcnotn7BxEa0RNh MIME-Version: 1.0 X-Received: by 10.157.44.135 with SMTP id p7mr3429789otb.98.1459526283716; Fri, 01 Apr 2016 08:58:03 -0700 (PDT) Received: by 10.202.84.84 with HTTP; Fri, 1 Apr 2016 08:58:03 -0700 (PDT) In-Reply-To: References: Date: Fri, 1 Apr 2016 11:58:03 -0400 Message-ID: From: William Whyte To: "Blumenthal, Uri - 0553 - MITLL" Content-Type: multipart/alternative; boundary=001a113cbcf6ae74b5052f6e71bd Archived-At: Cc: "cfrg@irtf.org" Subject: Re: [Cfrg] OCB patents expired? X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Apr 2016 15:58:10 -0000 --001a113cbcf6ae74b5052f6e71bd Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Is there any concern about the IAPM patents due to Jutla and owned by IBM? I understand that ideas from IAPM underlie OCB, but I don't know if OCB can be implemented without infringing on those patents. The IAPM patent was filed in 2000, so expires in 2020, AFAIK. William On Fri, Apr 1, 2016 at 11:24 AM, Blumenthal, Uri - 0553 - MITLL < uri@ll.mit.edu> wrote: > According to the USPTO, patents 7046802 and 7200227 on OCB mode have > expired due to non-payment. > > I'm aware there's already a TLS exemption, but this seems like it should > open up OCB mode for use in all protocols. > > > I=E2=80=99d *love* to see OCB used wider. > > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > https://www.irtf.org/mailman/listinfo/cfrg > > --001a113cbcf6ae74b5052f6e71bd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Is there any concern about the IAPM patents due to Jutla a= nd owned by IBM? I understand that ideas from IAPM underlie OCB, but I don&= #39;t know if OCB can be implemented without infringing on those patents.
The IAPM patent was filed in 2000, so expires in 2020, AF= AIK.

William

On Fri, Apr 1, 2016 at 11:24 AM, Blumenthal, Uri - 055= 3 - MITLL <uri@ll.mit.edu> wrote:
According to the USPTO, patents 7046802 and 7200227 on OCB mode h= ave expired due to non-payment.

I'm aware there's already a TLS exemption, but = this seems like it should open up OCB mode for use in all protocols.
<= /div>

=
I=E2=80=99d love=C2=A0to see OCB used wid= er.=C2=A0

_______________________________________________
Cfrg mailing list
Cfrg@irtf.org
https://www.irtf.org/mailman/listinfo/cfrg


--001a113cbcf6ae74b5052f6e71bd-- From nobody Fri Apr 1 09:50:12 2016 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8A7B12D5BC for ; Fri, 1 Apr 2016 09:50:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.591 X-Spam-Level: X-Spam-Status: No, score=-0.591 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_BL=0.01, RCVD_IN_MSPIKE_L3=2.099] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=seer-grog.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aAPpHGNeL97T for ; Fri, 1 Apr 2016 09:50:09 -0700 (PDT) Received: from homiemail-a20.g.dreamhost.com (sub3.mail.dreamhost.com [69.163.253.7]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6031A12D6E6 for ; Fri, 1 Apr 2016 09:50:03 -0700 (PDT) Received: from homiemail-a20.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a20.g.dreamhost.com (Postfix) with ESMTP id BE4BA7EC069; Fri, 1 Apr 2016 09:50:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=seer-grog.net; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s= seer-grog.net; bh=JTP4AtL8ESXR3N4QcxOe8j1DAgY=; b=nXnrbaxlB3FABg PkbE3WvGuAFFy2+7BMlBsA83fBgkLKkwfhuiGWiW5rlQFICqjg5pOUub999jeCR+ 6ZrocIpyM7K0mcLnd1xz+dRY+7sH2akvw1vF4KJJUDtjfUiYuBpvjkQtN+brLVkl 9AqJorjhL7PWuxq70v61g2PmElG+Y= Received: from [10.0.1.5] (cpe-76-167-195-197.san.res.rr.com [76.167.195.197]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: ggr@seer-grog.net) by homiemail-a20.g.dreamhost.com (Postfix) with ESMTPSA id 8DB567EC060; Fri, 1 Apr 2016 09:50:02 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Greg Rose In-Reply-To: Date: Fri, 1 Apr 2016 09:50:02 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <181BD549-B2D0-4E42-A448-9213D86F0358@seer-grog.net> References: To: William Whyte X-Mailer: Apple Mail (2.3112) Archived-At: Cc: "cfrg@irtf.org" Subject: Re: [Cfrg] OCB patents expired? X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Apr 2016 16:50:10 -0000 There are also patents in this area from Virgil Gligor, about the same = time. I haven't looked at them recently. Greg. > On Apr 1, 2016, at 8:58 , William Whyte = wrote: >=20 > Is there any concern about the IAPM patents due to Jutla and owned by = IBM? I understand that ideas from IAPM underlie OCB, but I don't know if = OCB can be implemented without infringing on those patents. >=20 > The IAPM patent was filed in 2000, so expires in 2020, AFAIK. >=20 > William >=20 > On Fri, Apr 1, 2016 at 11:24 AM, Blumenthal, Uri - 0553 - MITLL = wrote: > According to the USPTO, patents 7046802 and 7200227 on OCB mode have = expired due to non-payment. >=20 > I'm aware there's already a TLS exemption, but this seems like it = should open up OCB mode for use in all protocols. >=20 > I=E2=80=99d love to see OCB used wider.=20 >=20 > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > https://www.irtf.org/mailman/listinfo/cfrg >=20 >=20 > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > https://www.irtf.org/mailman/listinfo/cfrg Phone: +1 619 890 8236=20 GPG/PGP: 1081A37C 232B EC8F 44C6 C853 D68F E107 E6BF CD2F 1081 A37C From nobody Sat Apr 2 16:57:34 2016 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA66612D58C for ; Sat, 2 Apr 2016 16:57:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.4 X-Spam-Level: X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x_LCLE0Wo5X1 for ; Sat, 2 Apr 2016 16:57:30 -0700 (PDT) Received: from mail-ig0-x243.google.com (mail-ig0-x243.google.com [IPv6:2607:f8b0:4001:c05::243]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ADF4512D580 for ; Sat, 2 Apr 2016 16:57:30 -0700 (PDT) Received: by mail-ig0-x243.google.com with SMTP id sy18so6793283igc.3 for ; Sat, 02 Apr 2016 16:57:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc; bh=ATbR3rzJRlPONXDbDQWpRvPQiYeXZJMeZo05byVXx74=; b=w0Bxir2wkKCAL5WQss67Sd8ZvgzQ4rgV+rUzck82HB/O8dt/T/oKXZhj6XAAuRLaiP alJfPq1GFKvQzwk2RDgRVoZCwgSzdcGh3ngmwOj/LhswtGc65wK/vYBMym9SfKZX/oPV d659hU6W+G7W6v5NeeEzWDN1IjJwQB/Q71KCY6bchO5BJmgv1XfN+6G4UWiyOarxp/Gn n6tgiK8TQWKZ1Om1CNhYLDQn9lFatXF2Nb1WgH6s08xo7l56Fn/M2GmUMjaFuENGu1vp hghQPdy6C0dhrHHNzhuVDHa21Zhr02QFEpBQLZZG7f+dX07rLbZmFHkTMBMrhqk8iC/Z Hmeg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=ATbR3rzJRlPONXDbDQWpRvPQiYeXZJMeZo05byVXx74=; b=FT8sLj2fyC1udnCva12v06lCKEBvDDk12jAiBK3Wk6nWQJVXPaauG//KTEEnTej0Wa 4/Jlb8/8VCgISsEMwhUv9XEnG1fa2QZL60s0co3HoINz58568/LZTqEq+b5emBv8YxG8 x9m1yrivQSoenkD1AwyuwqVfT8DC/rOG/X6cOacdYV0PJySz2LkW555f186L4BlFSXUN 1Vj1QzXUm1RYRjgLrZqVeLX1OsjYvX1Ic4BD6r6fWuIgNBFR+g71C5PuB9voa0k9TQ6J 58vi99qSfX74MpEki2xCdHVXm5wJ2M7lLDUKBm2cimG9l64L9K5SOfY6zdVNkBkUNnf6 GdgQ== X-Gm-Message-State: AD7BkJJGzAj6PaC+DiBTKsqCJXE8i0yzN51/oidiF6Te3P6syLysgDOcPUAtSYErVVt0qUkuXFXRdSSW/We1ZQ== MIME-Version: 1.0 X-Received: by 10.107.151.133 with SMTP id z127mr10420168iod.191.1459641449915; Sat, 02 Apr 2016 16:57:29 -0700 (PDT) Sender: alangley@gmail.com Received: by 10.79.117.207 with HTTP; Sat, 2 Apr 2016 16:57:29 -0700 (PDT) In-Reply-To: References: <1893951588-3704@skroderider.denisbider.com> Date: Sun, 3 Apr 2016 06:57:29 +0700 X-Google-Sender-Auth: 2QWC2VlpDUUm57RaxpJmcsCE3vE Message-ID: From: Adam Langley To: Andy Lutomirski Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Yehuda Lindell , "cfrg@irtf.org" , Adam Langley Subject: Re: [Cfrg] Adopting "AES-GCM-SIV: Nonce Misuse-Resistant Authenticated Encryption" as a CFRG document X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Apr 2016 23:57:33 -0000 On Thu, Mar 31, 2016 at 3:22 PM, Andy Lutomirski wrote: > 4. Since this claims nonce-MR, setting nonce=0 is valid. If someone does > this, then I think they are vulnerable to the extra-easy parallel attack. Ah, do you mean when the AES-GCM-SIV is used with a fixed nonce? In that case, it breaks down in the same way as AES-GCM with random nonces. We note that in the Security Considerations (https://tools.ietf.org/html/draft-gueron-gcmsiv-02#section-9): "It's worth noting that the 2^32 limit still applies as the number of distinct messages that can be encrypted under a fixed nonce. Nonces should be unique and the misuse-resistance of these AEADs should not be depended on to the extent that 2^32 duplicates may occur. (Or 2^31 duplicates in the case of AEAD_AES_256_GCM_SIV.)" Basically our "misuse" resistance doesn't stretch to that kind of abuse. That might not meet some definitions of nonce-MR but AES-GCM-SIV is very strongly related to AES-GCM and so acts like it in some cases. Cheers AGL From nobody Sat Apr 2 17:49:22 2016 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DC9912D0DB for ; Sat, 2 Apr 2016 17:49:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=amacapital-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mEZFGT39lfdS for ; Sat, 2 Apr 2016 17:49:17 -0700 (PDT) Received: from mail-oi0-x22e.google.com (mail-oi0-x22e.google.com [IPv6:2607:f8b0:4003:c06::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3AD3B12D0A7 for ; Sat, 2 Apr 2016 17:49:17 -0700 (PDT) Received: by mail-oi0-x22e.google.com with SMTP id y204so6503725oie.3 for ; Sat, 02 Apr 2016 17:49:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amacapital-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=BbAbcmq7vRUpotUb7xixfLKSPmIoeR/4sHpcy0KIjyY=; b=aRfvy1WizC16iwyrl4ArDbcnkQ8WT3GMJweL1KcBJadbH7AbUzpdObrHKModW9zAsD cW70O6cB2U080HKRNd4Tl2dFyeq+Ygx1dU1LQ9sovyBqB/iLG3Yv0EZObcK7RhuwaWHD SEXahplkLSRT5LZmX7G8aK8psrkqpMs2m0/KzPue3F7lojDHdVdSsz7N/KLIAXKKkSuT CGOeIN6CpQoQA85LCKB9mCRDFa5z7M5y9iKqYqd/RH5GbFDaRB+jlfmUYc+zL1HxDAC7 5B/ATtPbFqOeBjsHuGJFFejDlvaCCMePpMJk9W28mxylCgr5DZ36/YkPjRmm7eiQUssG /i+Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=BbAbcmq7vRUpotUb7xixfLKSPmIoeR/4sHpcy0KIjyY=; b=lE6ohdQVaPAC3Iu7ISqt9O/kQjsoOji0oZ9SFG5tG7dd8aMS8xIKhTqjCDWqxyBh+x yz+rvWw47nz+A8I1EdbfXuJbwJatCKWsBXQ7njfI1GoiRNtx41Jtk/TSagasjlvaZeP4 Rdp7XBF/RMUnNv8WHM6q3KAd6GigFjf8zZv1K26NmA4gUwkurbtSHjdCndtF/P1z1fmL L7lzLNg/gaDiAlGZaRzcgVhEEv5S8wvijdc625Vp2EcVxldBMXziccmrfy7FoufD8+lq 7FOxIzNkvUixnIL4QW1pxz1FyKUlfvMvGpz0iPMw9HyiKIqqlPHt3olF3do6ciEw0cR6 2uBw== X-Gm-Message-State: AD7BkJI5uIn4hgBNsYZUz6R2MgOY3xVnEh+Qx4UyK99C2xQxcdEWJtCySLxo+EWsSqjBgaeBH7dvWB0lixJctP6M MIME-Version: 1.0 X-Received: by 10.202.60.5 with SMTP id j5mr1056231oia.43.1459644556517; Sat, 02 Apr 2016 17:49:16 -0700 (PDT) Received: by 10.202.202.209 with HTTP; Sat, 2 Apr 2016 17:49:15 -0700 (PDT) Received: by 10.202.202.209 with HTTP; Sat, 2 Apr 2016 17:49:15 -0700 (PDT) In-Reply-To: References: <1893951588-3704@skroderider.denisbider.com> Date: Sat, 2 Apr 2016 17:49:15 -0700 Message-ID: From: Andy Lutomirski To: Adam Langley Content-Type: multipart/alternative; boundary=001a113cc26c4a4387052f89fbb8 Archived-At: Cc: Yehuda Lindell , cfrg@irtf.org, Adam Langley Subject: Re: [Cfrg] Adopting "AES-GCM-SIV: Nonce Misuse-Resistant Authenticated Encryption" as a CFRG document X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Apr 2016 00:49:19 -0000 --001a113cc26c4a4387052f89fbb8 Content-Type: text/plain; charset=UTF-8 On Apr 2, 2016 7:57 PM, "Adam Langley" wrote: > > On Thu, Mar 31, 2016 at 3:22 PM, Andy Lutomirski wrote: > > 4. Since this claims nonce-MR, setting nonce=0 is valid. If someone does > > this, then I think they are vulnerable to the extra-easy parallel attack. > > Ah, do you mean when the AES-GCM-SIV is used with a fixed nonce? > > In that case, it breaks down in the same way as AES-GCM with random > nonces. We note that in the Security Considerations > (https://tools.ietf.org/html/draft-gueron-gcmsiv-02#section-9): I mean something different, but I read it a bit wrong. If I understand correctly, if AES256-GCM-SIV is used 128-bit keys, then you can only encrypt with ~2^64 (key, nonce) pairs, even with different keys, before a work factor ~2^64 attacker can decrypt one of them (which one is not under their control). This may not work if something prevents DJB's efficient parallel attack from working. With fixed nonce, the key derivation has no practical effect (as I said, I read it wrong at first). With *variable* nonce, the protocol no longer works like the paper, so I don't believe the security proof works as is. --001a113cc26c4a4387052f89fbb8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Apr 2, 2016 7:57 PM, "Adam Langley" <agl@imperialviolet.org> wrote:
>
> On Thu, Mar 31, 2016 at 3:22 PM, Andy Lutomirski <luto@amacapital.net> wrote:
> > 4. Since this claims nonce-MR, setting nonce=3D0 is valid.=C2=A0 = If someone does
> > this, then I think they are vulnerable to the extra-easy parallel= attack.
>
> Ah, do you mean when the AES-GCM-SIV is used with a fixed nonce?
>
> In that case, it breaks down in the same way as AES-GCM with random > nonces. We note that in the Security Considerations
> (https://tools.ietf.org/html/draft-gueron-gcmsiv-02#section-9):

I mean something different, but I read it a bit wrong.=C2=A0= If I understand correctly, if AES256-GCM-SIV is used 128-bit keys, then yo= u can only encrypt with ~2^64 (key, nonce) pairs, even with different keys,= before a work factor ~2^64 attacker can decrypt one of them (which one is = not under their control).=C2=A0 This may not work if something prevents DJB= 's efficient parallel attack from working.

With fixed nonce, the key derivation has no practical effect= (as I said, I read it wrong at first).=C2=A0 With *variable* nonce, the pr= otocol no longer works like the paper, so I don't believe the security = proof works as is.

--001a113cc26c4a4387052f89fbb8-- From nobody Sun Apr 3 10:16:48 2016 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8430712D162 for ; Sun, 3 Apr 2016 10:16:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.umd.edu Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wGLdK8611IvA for ; Sun, 3 Apr 2016 10:16:46 -0700 (PDT) Received: from mrouter00.cs.umd.edu (mrouter00.cs.umd.edu [128.8.128.203]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 11AA312D104 for ; Sun, 3 Apr 2016 10:16:45 -0700 (PDT) Received: from barracuda.cs.umd.edu (barracuda01.cs.umd.edu [128.8.128.202]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mrouter00.cs.umd.edu (Postfix) with ESMTPS id B5F8D4253B55 for ; Sun, 3 Apr 2016 13:16:44 -0400 (EDT) X-ASG-Debug-ID: 1459703804-08f01f19372c3730001-UHwLLG Received: from smtp00.cs.umd.edu (smtp00.cs.umd.edu [128.8.127.20]) by barracuda.cs.umd.edu with ESMTP id qPhUElJLuF6T6CrD for ; Sun, 03 Apr 2016 13:16:44 -0400 (EDT) X-Barracuda-Envelope-From: jkatz@cs.umd.edu X-Barracuda-Effective-Source-IP: smtp00.cs.umd.edu[128.8.127.20] X-Barracuda-Apparent-Source-IP: 128.8.127.20 Received: from mail-oi0-f52.google.com (mail-oi0-f52.google.com [209.85.218.52]) (Authenticated sender: jkatz) by smtp00.cs.umd.edu (Postfix) with ESMTPSA id 1527040319C7 for ; Sun, 3 Apr 2016 13:16:44 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.umd.edu; s=csmx; t=1459703804; bh=p4Q2LOL46FbutbrkjM65IGawaEGTQ69F9jk84C95rO8=; h=Date:Subject:From:To; b=ZDxP1cLjAKv4Ycl97BAgChOaf3O7EXVdXmA96gx1rpDrdRMaphEXYklyML72hw49A 1Kzsj+n9J4M/bpkgTnMupG9H+jkLZKtRsJFzPjd7TvU6mG8yQdhd8Mt9GhkLlfgZ21 5N7l0RK3Pu9fKMpMCk6nJDBpg1G1PkZkoCnLSQmg= Received: by mail-oi0-f52.google.com with SMTP id p188so139332824oih.2 for ; Sun, 03 Apr 2016 10:16:44 -0700 (PDT) X-Gm-Message-State: AD7BkJLnoo4MyfUMC5GdR57DEYLCTbwafzBGpqw2BBgcLyNOz8SppjPpio/Zi5x96JbuPwgSTd6XyFoQTX+pKQ== MIME-Version: 1.0 X-Received: by 10.157.4.39 with SMTP id 36mr3654462otc.195.1459703803665; Sun, 03 Apr 2016 10:16:43 -0700 (PDT) Received: by 10.76.72.36 with HTTP; Sun, 3 Apr 2016 10:16:43 -0700 (PDT) Date: Sun, 3 Apr 2016 13:16:43 -0400 X-Gmail-Original-Message-ID: Message-ID: From: Jonathan Katz X-ASG-Orig-Subj: Analysis of Hash-Based Signatures (draft-mcgrew-hash-sigs-04) To: cfrg@irtf.org Content-Type: text/plain; charset=UTF-8 X-Barracuda-Connect: smtp00.cs.umd.edu[128.8.127.20] X-Barracuda-Start-Time: 1459703804 X-Barracuda-URL: https://barracuda01.cs.umd.edu:443/cgi-mod/mark.cgi X-Barracuda-Scan-Msg-Size: 315 X-Virus-Scanned: by bsmtpd at cs.umd.edu X-Barracuda-BRTS-Status: 1 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=1000.0 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.28426 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- Archived-At: Subject: [Cfrg] Analysis of Hash-Based Signatures (draft-mcgrew-hash-sigs-04) X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Apr 2016 17:16:47 -0000 I have updated a previous manuscript I wrote containing a proof of security for the hash-based signature scheme proposed in an Internet Draft by McGrew and Curcio, currently draft-mcgrew-hash-sigs-04. The paper is available here: http://www.cs.umd.edu/~jkatz/papers/HashBasedSigs-04.pdf Comments welcome. From nobody Tue Apr 5 06:14:38 2016 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 814C612D80E for ; Tue, 5 Apr 2016 06:14:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x2IgQMQJOOUx for ; Tue, 5 Apr 2016 06:14:30 -0700 (PDT) Received: from mail-wm0-x236.google.com (mail-wm0-x236.google.com [IPv6:2a00:1450:400c:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 299C312D69C for ; Tue, 5 Apr 2016 06:14:16 -0700 (PDT) Received: by mail-wm0-x236.google.com with SMTP id n3so21168420wmn.0 for ; Tue, 05 Apr 2016 06:14:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:cc:date:message-id:in-reply-to:reply-to:user-agent :mime-version; bh=9MVDqq6p6EJhOGStyVvj28vVd64gZz9svr4sE0M1haE=; b=yiOVa0u37chg/Ef53LbngaeYiO9T+cdeaGJbn57kbwY9jpscnLsLDXz0bakuOAmN6s SfhfMbHxPh6avXZR2U+UaNIUpwweH5ORbEdNCmCEeQgjWGpfBPPTS1vnb9iIOet5gY9v 9o1MQINotoWGK02mZY1A8uACsq8byrFSr4JpM9HpDRUmJ3Y/VJlPdFQ2f2unAIJyGx1H 3jbhMPU4UcYHN2tUcYg4CtTES5b8+dW974JvP27sL0IcvOk9T5ecxZDWAnl1OeYSeS6m TjECiNaIfC5y0Da/tRGo0VJQf17EXAWV4JQLEL63KKi24dZ2k4Rh19tCyK4n7N1Nhs32 oc1A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:subject:cc:date:message-id:in-reply-to :reply-to:user-agent:mime-version; bh=9MVDqq6p6EJhOGStyVvj28vVd64gZz9svr4sE0M1haE=; b=KT45KTIhlpKEzRShJ2qxvqJz31Q2gQMFHbE4PzlE2xUhFlyBiC2DmODvT+qRBrOQa7 ppxuiB5ukDxMwLFfFnvhJgMjmC1TcYm+zSl3WvffuNShgRyXptlsnISZBy8BUNcB1PM7 8RjkePSMkkC1DV3O/0TOuXhw4DUlQqAIfUhRKH0PNYMPUSyCAkDKLpegUTXQ5NsJl+IH byUnky0AZxW51IscCnmdNZysLmwjK30tVkzIHCbMLFOfga7H9W90B/APOJLqE1E/KPhB tjWSmb2QrUu8S3k0cHtvyIhauEaLexydCskxIC2EGN1VgsKMZdzc/z5Pz/jIfqBHUTti m7zA== X-Gm-Message-State: AD7BkJJJYpTGSWWBTu9jWdy+HNbhks54v3PGwIFYIpWqUxTd62SRLz19O3Y+qJG8oShLlA== X-Received: by 10.28.53.134 with SMTP id c128mr18039990wma.10.1459862054680; Tue, 05 Apr 2016 06:14:14 -0700 (PDT) Received: from [10.0.0.7] (bzq-79-177-151-59.red.bezeqint.net. [79.177.151.59]) by smtp.gmail.com with ESMTPSA id x2sm23156951wjr.33.2016.04.05.06.14.12 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 05 Apr 2016 06:14:13 -0700 (PDT) From: "Gueron, Shay" To: cfrg@irtf.org Date: Tue, 05 Apr 2016 13:14:05 +0000 Message-Id: In-Reply-To: User-Agent: eM_Client/6.0.24316.0 Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="------=_MB501F1D44-E07B-4423-949A-91E7DB8EAFC9" Archived-At: Cc: Adam Langley , Yehuda Lindell , Adam Langley Subject: [Cfrg] Adopting "AES-GCM-SIV: Nonce Misuse-Resistant Authenticated Encryption" as a CFRG document ---- Some clarifications X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: "Gueron, Shay" List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2016 13:14:36 -0000 --------=_MB501F1D44-E07B-4423-949A-91E7DB8EAFC9 Content-Type: text/plain; format=flowed; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hello =E2=80=93 After we posted the AES-GCM-SIV draft, we saw several questions. We are=20 trying to address the points that were raised, hence the lengthy mail. Firstly, we=E2=80=99re sensitive to the concern that we=E2=80=99re pre-empt= ing CAESAR=20 here but we think that this is significantly smaller in scope than what=20 CAESAR is attempting. AES-GCM-SIV just reformulates AES-GCM in a=20 different order so that we can address some situations where the nonce=20 requirements of AES-GCM are troubling. AES-GCM-SIV has roughly the same cost as AES-GCM, which is already=20 widely used on various platforms, both with and without AES hardware=20 support. But, from an engineering point of view, there are a lot of=20 machine with AES-GCM hardware support, which is driving the use of=20 AES-GCM because of its performance on those machines. And it=E2=80=99s driv= ing=20 use of AES-GCM even in cases where the nonce can=E2=80=99t be a simple coun= ter.=20 Thus the motivation for a tweak to AES-GCM that avoids this problem. We gladly offer it for free, for anyone to enjoy and use. The code (reference, performance code, and performance numbers) is=20 available in the github repository at=20 https://github.com/Shay-Gueron/AES-GCM-SIV. BoringSSL will integrate it=20 as well, so it could be used directly from that library. The (ACM CCS) paper described a GCM-SIV implementation with 128-bit=20 keys. The CFRG submission is different in two respects: 1. A 256-bit version that is added. 2. There is key derivation added (based on the nonce) to refresh the=20 encryption key for each record. The purpose of #2 is to allow AES-GCM-SIV to use a single key multiple=20 times. In the original paper version, an IV is derived from the=20 universal hash function (and the nonce) over the message, and occupies=20 95 bits of the counter block during the encryption. Collisions are=20 imminent after 2^48 uses, and to maintain safety margins, we would need=20 to restrict the usage of one key to 2^32 messages. This could seem like=20 a real constraint for a real AE scheme. With a differently derived key=20 (derived from the nonce), the lifetime of one key can be extended. The cost of extending the lifetime of the key is that of computing a key= =20 schedule, but this overhead is small on the target platforms that have=20 AES hardware support. To clarify a possible confusion about the 256-bit variant: no 256-bit=20 key is ever derived from a 128-bit key. A 256-bit encryption key is=20 derived from the 256-bit master key and a (128-bit) nonce but two=20 encryptions. The authentication key has 128 bits, and so does the=20 authentication tag. Regarding the 256-bit key variant, and the key derivation in general, we= =20 are currently working on a full proof of security to show the exact=20 bounds. However, for now, we would like to point you to this sketch of a= =20 proof, showing that obtaining a key by applying AES-256 to the nonce=20 (twice) as we do, does not harm security (the full proof later will show= =20 that it significantly increases the security). PROOF SKETCH: Let \Pi=3D(Gen,Enc,Dec) be an encryption scheme (including mode of=20 operation) that uses AES256 directly and is (t,q,e)-indistinguishable=20 (time t, with q queries to encryption oracle, advantage e). Now, modify=20 to \Pi=E2=80=99=3D(Gen=E2=80=99,Enc=E2=80=99,Dec=E2=80=99) where the only= difference is that Enc=E2=80=99 begins=20 by deriving a 256 bit key by applying AES256 to the nonce with 0 and=20 then to the nonce with 1. Then, the distinguishing probability for \Pi=E2=80=99 is at most (t,q,e)= PLUS=20 what can be gained by distinguishing AES256 from a PRP with the number=20 of queries equalling twice the number of different nonces queried PLUS=20 2^{-128}. This follows since a distinguisher D for AES256 can derive the= =20 keys using its oracle. We have the following observations: 1) If the function being accessed by D is random, then the key is truly=20 random EXCEPT that it cannot be of the form k'||k=E2=80=99. Thus, with=20 probability 2^{-128} the key will be of this form and it won=E2=80=99t be= the=20 same as the original encryption scheme. Otherwise, it=E2=80=99s identical= to the=20 original encryption scheme. 2) If the function being accessed by D is AES256, then this is exactly=20 the modified encryption scheme. Note that the number of queries made by D to its oracle is twice the=20 number of different nonces. Thus, this is the only difference. We stress that the above just shows that nothing is lost by doing this=20 derivation. However, we do it in order to gain inside \Pi. The bounds=20 will be published soon. Thank you, Shay, Adam, Yehuda --------=_MB501F1D44-E07B-4423-949A-91E7DB8EAFC9 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

Hello =E2=80=93

 

After we posted the AES-GCM-SIV= draft, we saw several questions. We are trying to address the points that= were raised, hence the lengthy mail.

Firstly, we=E2=80=99re sensitive= to the concern that we=E2=80=99re pre-empting CAESAR here but we think = that this is significantly smaller in scope than what CAESAR is attempting.= AES-GCM-SIV just reformulates AES-GCM in a different order so that we can= address some situations where the nonce requirements of AES-GCM are troubl= ing.

 

AES-GCM-SIV has roughly the same= cost as AES-GCM, which is already widely used on various platforms, both= with and without AES hardware support. But, from an engineering point of= view, there are a lot of machine with AES-GCM hardware support, which is= driving the use of AES-GCM because of its performance on those machines.= And it=E2=80=99s driving use of AES-GCM even in cases where the nonce can= =E2=80=99t be a simple counter. Thus the motivation for a tweak to AES-GCM= that avoids this problem.


We gladly offer it for free,= for anyone to enjoy and use.

The code (reference, performance= code, and performance numbers) is available in the github repository at https://github.com/Shay-Gueron/AES-GCM-SIV. BoringSSL will integrate it as well, so it= could be used directly from that library.

The (ACM CCS) paper desc= ribed a GCM-SIV implementation with 128-bit keys. The CFRG submission is= different in two respects:
1. A 256-bit version that is added.
2.= There is key derivation added (based on the nonce) to refresh the encrypti= on key for each record.

The purpose of #2 is to allow AES-GCM-SIV= to use a single key multiple times. In the original paper version, an IV= is derived from the universal hash function (and the nonce) over the messa= ge, and occupies 95 bits of the counter block during the encryption. Collis= ions are imminent after 2^48 uses, and to maintain safety margins, we would= need to restrict the usage of one key to 2^32 messages. This could seem= like a real constraint for a real AE scheme. With a differently derived= key (derived from the nonce), the lifetime of one key can be extended. =

The cost of extending the lifetime of the key is that of computing= a key schedule, but this overhead is small on the target platforms that= have AES hardware support.

To clarify a possible confusion about= the 256-bit variant: no 256-bit key is ever derived from a 128-bit key.= A 256-bit encryption key is derived from the 256-bit master key and a (128= -bit) nonce but two encryptions. The authentication key has 128 bits, and= so does the authentication tag.

 

Regarding the 256-bit key variant= , and the key derivation in general, we are currently working on a full = proof of security to show the exact bounds. However, for now, we would like= to point you to this sketch of a proof, showing that obtaining a key by= applying AES-256 to the nonce (twice) as we do, does not harm security = (the full proof later will show that it significantly increases the securit= y).

 

PROOF SKETCH:

Let \Pi=3D(Gen,Enc,Dec) be an = encryption scheme (including mode of operation) that uses AES256 directly= and is (t,q,e)-indistinguishable (time t, with q queries to encryption = oracle, advantage e). Now, modify to \Pi=E2=80=99=3D(Gen=E2=80=99,Enc=E2= =80=99,Dec=E2=80=99) where the only difference is that Enc=E2=80=99 begins= by deriving a 256 bit key by applying AES256 to the nonce with 0 and then= to the nonce with 1.

 

Then, the distinguishing probabil= ity for \Pi=E2=80=99 is at most (t,q,e) PLUS what can be gained by distingu= ishing AES256 from a PRP with the number of queries equalling twice the = number of different nonces queried PLUS 2^{-128}. This follows since a dist= inguisher D for AES256 can derive the keys using its oracle. We have the= following observations:

1) If the function being accessed= by D is random, then the key is truly random EXCEPT that it cannot be of= the form k'||k=E2=80=99. Thus, with probability 2^{-128} the key will be= of this form and it won=E2=80=99t be the same as the original encryption= scheme. Otherwise, it=E2=80=99s identical to the original encryption schem= e.

2) If the function being accessed= by D is AES256, then this is exactly the modified encryption scheme.

Note that the number of queries= made by D to its oracle is twice the number of different nonces. Thus, = this is the only difference.

 

We stress that the above just = shows that nothing is lost by doing this derivation. However, we do it in= order to gain inside \Pi. The bounds will be published soon.


Thank you,
Shay, Adam,= Yehuda

--------=_MB501F1D44-E07B-4423-949A-91E7DB8EAFC9-- From nobody Tue Apr 5 16:34:30 2016 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A512012D627 for ; Tue, 5 Apr 2016 16:34:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=azet.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gQxLsReyiOZ0 for ; Tue, 5 Apr 2016 16:34:27 -0700 (PDT) Received: from mail-wm0-x234.google.com (mail-wm0-x234.google.com [IPv6:2a00:1450:400c:c09::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB98A12D5CC for ; Tue, 5 Apr 2016 16:34:26 -0700 (PDT) Received: by mail-wm0-x234.google.com with SMTP id v188so4863516wme.1 for ; Tue, 05 Apr 2016 16:34:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=azet.org; s=gmail; h=subject:mime-version:from:in-reply-to:date:cc:message-id:references :to; bh=CJBl0yaMDGVYz36hE0xarnMatNmCdLZiZQvyaZbYeeU=; b=hS2uQ4S/VI0K4xKBnAQzKx2hOMOriPD2y/IDXEq0Ftk1DeeKayD7h0Eql8ENhAnu6O sCGX7waRCl/b5QcyOlVR/0JHhMBa/CWpbg2ZT4Qs74PuefTjN6vKN+eRvjGSnTO8rnam ri6o68FMS0f2Lk/WZw6GQ4JoX8e24VDvRaIT4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:mime-version:from:in-reply-to:date:cc :message-id:references:to; bh=CJBl0yaMDGVYz36hE0xarnMatNmCdLZiZQvyaZbYeeU=; b=mkoyyFym58LQBu6KMWcRkH55RB0ZtrxYGbjGYmhSQZ8Qdv0Ap6AFnBwSV5W5qXdGJW jBdG3i0L4nDIyW34KlR2jgQIr0nRH6zQhvRfi7Mi3JBHeuWTD1M8BsoWScbDafTigX8h 1b+o8cE3rxeuPyZU402NZJsJUhvrkluCb9DFGZZ9Sg5PbJmwe6nPxT4JSxr9KEOQLhIN cboofBVMXn5yg8oNwxrsgcDbi8CYuj+DFl2zNBW4kahGkJ50WqOkFreEQGr1qXPXsMR7 87jtDf31arMq0bmZUcXWP5V1iCEqDhoMmJ1T37qPOFxEIMvZdtztyfO/ai1rgUSO84wB XO+A== X-Gm-Message-State: AD7BkJK2t6v35nR+qV46vkPgyLnlL9UMKAnHHRO7lsxiz2Ra3WH8eGyh78YoGk2iJfTaBA== X-Received: by 10.194.77.15 with SMTP id o15mr33622702wjw.41.1459899265329; Tue, 05 Apr 2016 16:34:25 -0700 (PDT) Received: from aarons-macbook.home.azet.org (chello080108049181.14.11.vie.surfer.at. [80.108.49.181]) by smtp.gmail.com with ESMTPSA id w184sm635123wmb.1.2016.04.05.16.34.23 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 05 Apr 2016 16:34:23 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) Content-Type: multipart/signed; boundary="Apple-Mail=_74E45E76-8526-44EC-A2CE-1254BC8C1F3E"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.6b2 From: Aaron Zauner In-Reply-To: Date: Wed, 6 Apr 2016 01:34:48 +0200 Message-Id: References: To: William Whyte X-Mailer: Apple Mail (2.3112) Archived-At: Cc: "cfrg@irtf.org" Subject: Re: [Cfrg] OCB patents expired? X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2016 23:34:28 -0000 --Apple-Mail=_74E45E76-8526-44EC-A2CE-1254BC8C1F3E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, > On 01 Apr 2016, at 17:58, William Whyte = wrote: >=20 > Is there any concern about the IAPM patents due to Jutla and owned by = IBM? I understand that ideas from IAPM underlie OCB, but I don't know if = OCB can be implemented without infringing on those patents. >=20 > The IAPM patent was filed in 2000, so expires in 2020, AFAIK. There's an IPR exemption for my draft on OCB cipher-suites in TLS [0] = related to IAPM from Jutla/IBM: https://datatracker.ietf.org/ipr/2647/ HTH, Aaron [0] https://datatracker.ietf.org/doc/draft-zauner-tls-aes-ocb/ --Apple-Mail=_74E45E76-8526-44EC-A2CE-1254BC8C1F3E Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQIbBAEBCgAGBQJXBEuZAAoJEOTbZJL9ubXVqZEP+OmLOMAAjCD3ihz3XHhmNEYL 2ypmLt/tCl6sTRdWVglnTwT8rkVBSZ0gtG9o8Fnqaxw6hGcbSJ+JrMPOYywItUOt TTi8G1Om56sm+6Wns4OY05Fv5oLD2S66AHctqJhoMJAyjzz3iSc8okcBBHhgzywx AWy+sJQn8l0FtGSv/Ep6ae+9r0aanoPKRzr/q7o5IzE7yvy4nQVSk8/llxums15+ 6RVaLfQIAv4TWQOb/KRy0OFzL+/6EpFf/cM9V+VtlUfrZ5uH62OCP5EC7ZNrOgrd aNlBbg8OPSMr4kAa8IOKfJN2effl3AZ97oDGZuohpm+5r6ZHVkDl54q91MH1tnpI b7wwrvdh4tGXSUEsoG2N9OM5msdUbZajZJ3XhFM3e+oenCu0qzchfjnFuNzf61JW IMCl0seCzJQ48ZK0HsJKwncWUc+7ZQyzeVB4CbsFTL7azNF3Z0PssF7t5XNdYIn3 xOJPAKQgBjCl4zMekid2DJz6zKVIE31Gk7QK4pHbq+sNGuIOIEdDJwkFdZa+ifcg dddPRtYpT+MikRi/3dTk95/qBFeG4w8RpS9Yggn+zqXvxarHiY07X53XlB4Q+mv1 9kArxy9r5Z1n31fnm19hbnC+BChNewDiiCEctCVMFCv9e+NoFsQX4RHK47TAMqL6 J4JHfTXahDH7UpxHAV8= =w43l -----END PGP SIGNATURE----- --Apple-Mail=_74E45E76-8526-44EC-A2CE-1254BC8C1F3E-- From nobody Tue Apr 5 16:38:15 2016 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29D5212D5CC for ; Tue, 5 Apr 2016 16:38:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=azet.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j9N0xsAlPTcC for ; Tue, 5 Apr 2016 16:38:11 -0700 (PDT) Received: from mail-wm0-x22d.google.com (mail-wm0-x22d.google.com [IPv6:2a00:1450:400c:c09::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A63F12D0EE for ; Tue, 5 Apr 2016 16:38:11 -0700 (PDT) Received: by mail-wm0-x22d.google.com with SMTP id n3so40876338wmn.0 for ; Tue, 05 Apr 2016 16:38:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=azet.org; s=gmail; h=subject:mime-version:from:in-reply-to:date:cc:message-id:references :to; bh=2qO5axh4ppsznjJDuIPSQye3tgh/KG1szmrThfRtldE=; b=C4l2Ppi5ZXlzEY5xCuegZ0BBZmd2XV+3Gf0YdEhJnFtZzfqSWFdrfvZhcz0qx6/Owv XAT+udzHRxa4z1cRj5Y3dX7TYb2iKzPlu4hC09fz0fMYFBLfOk8VGupvr4WRmHloaQ17 12hJfNfH8PhsTuhpqDThgRdIJaBHmx6Hxtkdc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:mime-version:from:in-reply-to:date:cc :message-id:references:to; bh=2qO5axh4ppsznjJDuIPSQye3tgh/KG1szmrThfRtldE=; b=Fi+7DIaR7lv3op24glrxLJLJOvz7EWlpif27seYR4iHn4r3z92XGd8bWy6v50zPRxT eU9y5rF/xOqTuAdRa8zYa9hzk57tfm7IcNkcjtW3k3JP630qryVMYVMNbMxNRgeumaR/ f9hGzMgRR5jjdI+x9vQh2aKGuTrIbAfNkqW4dy+0BKQo4I0YDl7zjnB6wOQh7v5KLE3/ 40fsNCOGc+uQUaMrWoT43Ochfqk3Q4rE7Eom/LH2XTaWc4zXosMwvjluwrhbRSoUodE4 e1cuL7dgmeTvUJbiIAVsFb0kGqHbERqtt/wR5KkOqsSMRFYTk+DbLs15DJd32CmLILJR khCg== X-Gm-Message-State: AD7BkJIBBuqM/L6JAiHM+k2lQvela4c2oRveZjdU2Hsh4PXYBjh9NJFU0ELTD1F5Fm6cLA== X-Received: by 10.194.122.138 with SMTP id ls10mr26739888wjb.51.1459899489993; Tue, 05 Apr 2016 16:38:09 -0700 (PDT) Received: from aarons-macbook.home.azet.org (chello080108049181.14.11.vie.surfer.at. [80.108.49.181]) by smtp.gmail.com with ESMTPSA id g3sm120233wjw.31.2016.04.05.16.38.07 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 05 Apr 2016 16:38:08 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) Content-Type: multipart/signed; boundary="Apple-Mail=_C34DDC47-32AC-4F80-B3DF-072DABF02B63"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.6b2 From: Aaron Zauner In-Reply-To: <181BD549-B2D0-4E42-A448-9213D86F0358@seer-grog.net> Date: Wed, 6 Apr 2016 01:38:33 +0200 Message-Id: <77FF4992-AB83-4F56-8DC1-A989F1AC246A@azet.org> References: <181BD549-B2D0-4E42-A448-9213D86F0358@seer-grog.net> To: Greg Rose X-Mailer: Apple Mail (2.3112) Archived-At: Cc: "cfrg@irtf.org" Subject: Re: [Cfrg] OCB patents expired? X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2016 23:38:13 -0000 --Apple-Mail=_C34DDC47-32AC-4F80-B3DF-072DABF02B63 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, > On 01 Apr 2016, at 18:50, Greg Rose wrote: >=20 > There are also patents in this area from Virgil Gligor, about the same = time. I haven't looked at them recently. These patents were filed after relevant OCB and IAPM patents. I'm not = very familiar with US patent law nor am I a lawyer but I'm told that = this makes any claims irrelevant. See also: = https://www.ietf.org/mail-archive/web/tls/current/msg18252.html Aaron --Apple-Mail=_C34DDC47-32AC-4F80-B3DF-072DABF02B63 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJXBEx5AAoJEOTbZJL9ubXVAWwQAJYI3fnuq7QVsK45c2nvX5im qe4cNlo7ouabeeYWi9d0871kGsSUkxPiKGqYQSLGfA4Fo4XEoQeEip+d9gwrkhf9 GNlTwYkmBUVb106TynlZzVv0pkCjkxDY0iSxj14kTYUbO8Clk83er2cXnnCt5hDx Vh7IOAcZoOjW9Jy6Jm66D2/YFTA7ron02diD09Tgn8V475Kul6L99I8sduwvrRK4 nMbnV0RMOCPac2kxG6PMeug0KoJkrrtOJ/e+B/NFQdRglFdBvCBvW5ISZtmkQZTI svHJsV9A/KfrTUdLlBqxy9P6+J/vFHV1b7RIAiekg79WicJ5TUATYRSmiR+DMPcr tQQHBeQ/2R8WJI6xutW3Gndsd2DXs6PnFsu9U2xYy1eHAzN2t9g6aicpVFv4qDSB TYaa2NBm5ABTCMeLC4pLuX7fRRz1DTCQqXJzIZRBEp7fh0l4s9c80ZOQfL2x6vsr 6zsrcFlmK2jeMhhVeO+n795CP8UsfEKmuXmo84bI8NwT3Iu6als5vwxqO456ZS2G TUxXPxiPEZBJ6F3VGfWYgyDt80QBhYXwlpThZIlatfVUgJaxsRKjoaU71wuJ7auj 9jDHywoANwBUZpBZE1A7Yh+fltrXPeojgD/Tahjpr4v2l3K2B8RK/idErD7gOjSI FYzYbFM+pgmmlbkIj19m =n5kq -----END PGP SIGNATURE----- --Apple-Mail=_C34DDC47-32AC-4F80-B3DF-072DABF02B63-- From nobody Tue Apr 5 17:23:51 2016 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9924B12D155 for ; Tue, 5 Apr 2016 17:23:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.49 X-Spam-Level: X-Spam-Status: No, score=-2.49 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_LOW=-0.7, T_DKIM_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=seer-grog.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gx21jxnbZ08s for ; Tue, 5 Apr 2016 17:23:48 -0700 (PDT) Received: from homiemail-a75.g.dreamhost.com (sub3.mail.dreamhost.com [69.163.253.7]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EEA1212D121 for ; Tue, 5 Apr 2016 17:23:47 -0700 (PDT) Received: from homiemail-a75.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a75.g.dreamhost.com (Postfix) with ESMTP id 996325EC07C; Tue, 5 Apr 2016 17:23:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=seer-grog.net; h=subject :mime-version:content-type:from:in-reply-to:date:cc:message-id :references:to; s=seer-grog.net; bh=WgkFTEbiniN4eLdjxA2laHk3FRI= ; b=kYK3lFrKzlkrqC9aAG5tW4zp7k3c8AN9zF02Q26hMiYvypYVi27/hNz++KKA 2el7gs/u+/hgMU2MB7R5d1WqX3w4kcIBwU1fZTtFNWHoowIypjBI80UN6hOg4Z4F VpphtWdoNBW/Gnzk9QGM6l2Da2aUJ/UeNVTROm0yiqJBi8I= Received: from [10.0.1.5] (cpe-76-167-195-197.san.res.rr.com [76.167.195.197]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: ggr@seer-grog.net) by homiemail-a75.g.dreamhost.com (Postfix) with ESMTPSA id 7BE095EC079; Tue, 5 Apr 2016 17:23:47 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) Content-Type: multipart/signed; boundary="Apple-Mail=_57EAA971-7556-4C37-B858-3AE2D6FD74C1"; protocol="application/pgp-signature"; micalg=pgp-sha1 X-Pgp-Agent: GPGMail 2.6b2 From: Greg Rose In-Reply-To: <77FF4992-AB83-4F56-8DC1-A989F1AC246A@azet.org> Date: Tue, 5 Apr 2016 17:23:42 -0700 Message-Id: <46247E92-CA27-46F5-9EE3-1E50DE92AFEA@seer-grog.net> References: <181BD549-B2D0-4E42-A448-9213D86F0358@seer-grog.net> <77FF4992-AB83-4F56-8DC1-A989F1AC246A@azet.org> To: Aaron Zauner X-Mailer: Apple Mail (2.3112) Archived-At: Cc: "cfrg@irtf.org" Subject: Re: [Cfrg] OCB patents expired? X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2016 00:23:49 -0000 --Apple-Mail=_57EAA971-7556-4C37-B858-3AE2D6FD74C1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Apr 5, 2016, at 16:38 , Aaron Zauner wrote: >=20 > Hi, >=20 >> On 01 Apr 2016, at 18:50, Greg Rose wrote: >>=20 >> There are also patents in this area from Virgil Gligor, about the = same time. I haven't looked at them recently. >=20 >=20 > These patents were filed after relevant OCB and IAPM patents. I'm not = very familiar with US patent law nor am I a lawyer but I'm told that = this makes any claims irrelevant. >=20 > See also: = https://www.ietf.org/mail-archive/web/tls/current/msg18252.html I don't want to start a legal flame war, but at the time, the rules were = "first to invent" not "first to file" (which is relatively recent to the = US). It's theoretically possible that there is documentation supporting = his patent. Anyway, I agree it's probably irrelevant. Greg. Phone: +1 619 890 8236 GPG/PGP: 1081A37C 232B EC8F 44C6 C853 D68F E107 E6BF CD2F 1081 A37C --Apple-Mail=_57EAA971-7556-4C37-B858-3AE2D6FD74C1 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iEYEARECAAYFAlcEVxMACgkQ5r/NLxCBo3zE9gCg6RlYwgp6s7GC2LHNs4Jh3dwv lqIAn1j11vRIRRUQZ4DBwhPfwLqX8532 =PByF -----END PGP SIGNATURE----- --Apple-Mail=_57EAA971-7556-4C37-B858-3AE2D6FD74C1-- From nobody Tue Apr 5 22:42:41 2016 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E73A112D815 for ; Tue, 5 Apr 2016 22:42:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.93 X-Spam-Level: X-Spam-Status: No, score=-6.93 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BsG66VZNB9Hv for ; Tue, 5 Apr 2016 22:42:34 -0700 (PDT) Received: from mx143.netapp.com (mx143.netapp.com [216.240.21.24]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A58012D0B8 for ; Tue, 5 Apr 2016 22:42:34 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.24,447,1455004800"; d="asc'?scan'208,217";a="106954163" Received: from hioexcmbx07-prd.hq.netapp.com ([10.122.105.40]) by mx143-out.netapp.com with ESMTP; 05 Apr 2016 22:37:33 -0700 Received: from HIOEXCMBX07-PRD.hq.netapp.com (10.122.105.40) by hioexcmbx07-prd.hq.netapp.com (10.122.105.40) with Microsoft SMTP Server (TLS) id 15.0.1156.6; Tue, 5 Apr 2016 22:37:33 -0700 Received: from HIOEXCMBX07-PRD.hq.netapp.com ([::1]) by hioexcmbx07-prd.hq.netapp.com ([fe80::c07c:8fcd:f7e4:f32b%21]) with mapi id 15.00.1156.000; Tue, 5 Apr 2016 22:37:33 -0700 From: "Eggert, Lars" To: "cfrg@irtf.org" Thread-Topic: [IP] Security research, DRM and the W3C Thread-Index: AQHRj1Z9yE62EdqeWUqqpRP3lTxALA== Date: Wed, 6 Apr 2016 05:37:33 +0000 Message-ID: <7A2B4897-4DF0-49DE-BF2A-EF48216EBACE@netapp.com> References: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3124) x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.120.60.35] Content-Type: multipart/signed; boundary="Apple-Mail=_25869ECE-03A2-44C0-B395-6FF0A1F3D779"; protocol="application/pgp-signature"; micalg=pgp-sha256 MIME-Version: 1.0 Archived-At: Subject: [Cfrg] Fwd: [IP] Security research, DRM and the W3C X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2016 05:42:37 -0000 --Apple-Mail=_25869ECE-03A2-44C0-B395-6FF0A1F3D779 Content-Type: multipart/alternative; boundary="Apple-Mail=_FD7F311B-2D4E-4DB9-9725-AE55CF3EB94C" --Apple-Mail=_FD7F311B-2D4E-4DB9-9725-AE55CF3EB94C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Potentially of interest to some > Begin forwarded message: >=20 > From: "Dave Farber" > Subject: [IP] Security research, DRM and the W3C > Date: March 29, 2016 at 19:45:51 GMT+2 > To: "ip" > Reply-To: dave@farber.net >=20 >=20 >=20 >=20 > Begin forwarded message: >=20 >> From: Cory Doctorow > >> Date: March 29, 2016 at 1:40:46 PM EDT >> To: Dave Farber > >> Subject: Security research, DRM and the W3C >>=20 >> We're looking for security researchers to sign onto an open letter to >> the W3C calling on it to require members to promise not to use the = DMCA >> (or its global equivalents like the EUCD) to attack researchers who >> reveal flaws in the DRM they're standardizing. >>=20 >> = https://www.eff.org/deeplinks/2016/03/security-researchers-tell-w3c-protec= t-researchers-who-investigate-browsers = >>=20 >> Please pass on to any researchers you know! >>=20 >> Cory >> -- >>=20 >> FOR PUBLIC SAFETY REASONS, THIS EMAIL HAS BEEN INTERCEPTED BY YOUR >> GOVERNMENT AND WILL BE RETAINED FOR FUTURE ANALYSIS >>=20 >> -- >>=20 >> Cory Doctorow >> doctorow@craphound.com >> Wickr: doctorow >>=20 >> For avoidance of doubt: This email does not constitute permission to = add >> me to your mailing list. >>=20 >> blog: boingboing.net = >> upcoming appearances: craphound.com/?page_id=3D4667 = >> books (novels, collections graphic novels, essay collections): = craphound.com = >> latest nonfiction: Information Doesn't Want to Be Free >> latest graphic novel: In Real Life >> podcast: feeds.feedburner.com/doctorow_podcast = >> latest novel: Homeland craphound.com/homeland = >> latest short story collection: With a Little Help craphound.com/walh = >>=20 >> Join my mailing list and find out about upcoming books, stories, >> articles and appearances: >>=20 >> http://www.ctyme.com/mailman/listinfo/doctorow = >>=20 >> READ CAREFULLY. By reading this email, you agree, on behalf of your >> employer, to release me from all obligations and waivers arising from >> any and all NON-NEGOTIATED agreements, licenses, terms-of-service, >> shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, >> non-compete and acceptable use policies ("BOGUS AGREEMENTS") that I = have >> entered into with your employer, its partners, licensors, agents and >> assigns, in perpetuity, without prejudice to my ongoing rights and >> privileges. You further represent that you have the authority to = release >> me from any BOGUS AGREEMENTS on behalf of your employer. >>=20 >> As is the case with every email you've ever received, this email has = not >> been scanned for all known viruses. >>=20 >> Duh. >>=20 >=20 > Archives = | = Modify = Your Subscription | Unsubscribe Now = = --Apple-Mail=_FD7F311B-2D4E-4DB9-9725-AE55CF3EB94C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Potentially of interest to some

Begin = forwarded message:

From: = "Dave Farber" <farber@gmail.com>
Subject: = [IP] Security = research, DRM and the W3C
Date: = March 29, 2016 at 19:45:51 = GMT+2
To: = "ip" <ip@listbox.com>
Reply-To: = dave@farber.net




Begin forwarded message:

From: Cory Doctorow <doctorow@craphound.com>
Date: March 29, 2016 at 1:40:46 PM EDT
To: Dave Farber <dave@farber.net>
Subject: Security research, DRM and the = W3C

We're looking for security = researchers to sign onto an open letter to
the W3C calling on it to require members to promise not to = use the DMCA
(or its global = equivalents like the EUCD) to attack researchers who
reveal flaws in the DRM they're = standardizing.

https://www.eff.org/deeplinks/2016/03/security-researchers-tell= -w3c-protect-researchers-who-investigate-browsers

Please = pass on to any researchers you know!

Cory
--

FOR PUBLIC SAFETY = REASONS, THIS EMAIL HAS BEEN INTERCEPTED BY YOUR
GOVERNMENT AND WILL BE RETAINED FOR FUTURE = ANALYSIS

--

Cory Doctorow
doctorow@craphound.com
Wickr: doctorow

For avoidance of = doubt: This email does not constitute permission to add
me to your mailing list.

blog: = boingboing.net
upcoming appearances: craphound.com/?page_id=3D4667
books (novels, collections graphic novels, = essay collections): craphound.com
latest = nonfiction: Information Doesn't Want to Be Free
latest graphic novel: In Real Life
podcast: feeds.feedburner.com/doctorow_podcast
latest novel: Homeland craphound.com/homeland
latest short story collection: With a Little Help craphound.com/walh

Join my mailing list = and find out about upcoming books, stories,
articles and appearances:

http://www.ctyme.com/mailman/listinfo/doctorow

READ = CAREFULLY. By reading this email, you agree, on behalf of your
employer, to release me from all obligations = and waivers arising from
any and = all NON-NEGOTIATED  agreements, licenses, = terms-of-service,
shrinkwrap, = clickwrap, browsewrap, confidentiality, non-disclosure,
non-compete and acceptable use policies = ("BOGUS AGREEMENTS") that I have
entered into with your employer, its partners, licensors, = agents and
assigns, in perpetuity, = without prejudice to my ongoing rights and
privileges. You further represent that you have the authority = to release
me from any BOGUS = AGREEMENTS on behalf of your employer.

As is the case with = every email you've ever received, this email has not
been scanned for all known = viruses.

Duh.

Archives | Modify Your Subscription | Unsubscribe Now

= --Apple-Mail=_FD7F311B-2D4E-4DB9-9725-AE55CF3EB94C-- --Apple-Mail=_25869ECE-03A2-44C0-B395-6FF0A1F3D779 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQIcBAEBCAAGBQJXBKCdAAoJEFS1wwm/cMFXOWwP/juhoh8LT8hyNvpJ4L5SBhUq hkkwjr1k/fz1c7SBuGvqIGMBFrZEcIlQ3dthgW5V3pwOuQ1UayF1lkt1YSC/rWLk Cq3vtCvIFjRTUoKcChX9J0dcF/U3xgfACOA8HgHjKEUcTgDCh3ULYL9XLv21n+v4 QQY/BMT45NWWK6OswngyruyFuS7SQkXC+gDUt8cS8mVljIjvy6tA1PWIJjHDLtSp /nDYdErjLwDuCn/dnJjQMUoUrc5aXbH5GapJfnDhWmi0x6OTTYlvEFfn5EM0QfOF xTSXElWq451lc81xDKMUnjYUN0bO5n2CGjiMKeJBAczsqgxBIjxtRGtM/Lfm9Hce xWDKcpWOQWKO+DwLNysxCWVCJgEyjipFPQBaouUOhXEUSqkpb1CL32z9bU2vK9Ft x9WVqI3WJg4I0KFJk+J3ZtpEyxAarhZGHn+uRYw0BbvbwUhnv68oY21U9+MYY+So bFR3qexEKoRIdcZrvwIaraLjO/YvxBvLnLORI7xr1UvNy6Jjw2ZxWqfQjgIT2n84 OXlYjtt0UQBSgHnEn60rD2Fwtx8WhIO8nhSZvjCn7mGihT4HIynRyBthjYX7IHoj GMemA1SKvqvEi2yf4ptgWcvTuP+XNt+z64A9tHiLUsI5guhGMQDpxtvHknpBQ1M9 nWkbev47tOqUNe7SCUni =ApR2 -----END PGP SIGNATURE----- --Apple-Mail=_25869ECE-03A2-44C0-B395-6FF0A1F3D779-- From nobody Wed Apr 6 00:36:57 2016 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B683E12D859 for ; Wed, 6 Apr 2016 00:36:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.185 X-Spam-Level: X-Spam-Status: No, score=-1.185 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_RHS_DOB=1.514] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CsJFOhDZfMfR for ; Wed, 6 Apr 2016 00:36:54 -0700 (PDT) Received: from mail-io0-x229.google.com (mail-io0-x229.google.com [IPv6:2607:f8b0:4001:c06::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7AD9012D57F for ; Wed, 6 Apr 2016 00:36:54 -0700 (PDT) Received: by mail-io0-x229.google.com with SMTP id g185so46734476ioa.2 for ; Wed, 06 Apr 2016 00:36:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=M25RHDmEXMAqpdurCRHtOTZUok+Ekm7mIJ0jitJQbtQ=; b=BQ7NIlOTBghfhdh9YVIAtDfbOIheLRHd6pqrrR52J+EdATN/AqWE0S+oqjon+VYK8f bEuZMGt4uCv4HBKScgC9um/nxwAHkBi1yFuetX3TNbztb15Qilw8G8pTQxHfo+/PF3Z+ o1hftF7wZjlKja4O8a5GStD8/KMrxgN4cSWEDCt055HuI0zVYIGIYJqWkIz7LbhFY+Vc OJ8WSh6qPh+bS2mI27FPpM2n55VZgkLkSADoa8f0GmSESteW9bmPiFti4Do3tiR8DLGU 5zy3cAM3UtIMKxciZmqxPFYqrgQ+FEOI8qDiiLQ2uKr5mwAxoHSbdQTDBOCSCu01Jn6+ KuPg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=M25RHDmEXMAqpdurCRHtOTZUok+Ekm7mIJ0jitJQbtQ=; b=S1ZshsTj71edYezBBc/uzuvBdbpesCh4571GaiG69SmO3yQnGWXB19/p4PETk509l5 6+hGwW9/26PHyU4tqKmTF7IwQ8+WmUlYxGqQwnfJTx9uMG5gqUJQ0FEUc00CM141KFgP JyngKR4K5Ox+er5t9r9p7fj6VW+Sh/C39SVS0XVdOHzNDxC0JePteiM/GEHb3cvCFb/s lNHC1Sbn9iFnht+2qrcjHE5tYOdrfsPjXZQtAIsrzNvNKvsDH2Gq3x/SaskES2U52D1j gRbkRvv+A/iLTrMe3zDXMpc8crQTWfYL+Za+a7dCmLiKXjD0lOW+eIoT3GfS8J/nqnRf 5QCw== X-Gm-Message-State: AD7BkJJ064pDasC9N86AT/dzs8POyM02WJx8FtMhYrBErhbRSFNiiasoiKkI/KSDOqoSHB/4JPK28hSh2VsLIQ== X-Received: by 10.107.14.66 with SMTP id 63mr15749738ioo.150.1459928213788; Wed, 06 Apr 2016 00:36:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.7.76 with HTTP; Wed, 6 Apr 2016 00:36:34 -0700 (PDT) From: Tony Arcieri Date: Wed, 6 Apr 2016 00:36:34 -0700 Message-ID: To: "cfrg@irtf.org" Content-Type: multipart/alternative; boundary=001a113fe1be94c136052fcc068b Archived-At: Subject: [Cfrg] Noise X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2016 07:36:56 -0000 --001a113fe1be94c136052fcc068b Content-Type: text/plain; charset=UTF-8 WhatsApp announced today they are using Trevor Perrin's Noise protocol for transport encryption protocol: https://www.whatsapp.com/security/WhatsApp-Security-Whitepaper.pdf New web site here: http://noiseprotocol.org/ Allegedly it is the transport encryption protocol now used by over a billion WhatsApp users worldwide. I bring it up mostly to ask if anyone is doing or plans to do analysis on it. -- Tony Arcieri --001a113fe1be94c136052fcc068b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
WhatsApp announced today they are using Trevor Perrin'= s Noise protocol for transport encryption protocol:

= https://www.whatsapp.com/security/WhatsApp-Security-Whitepaper.pdf

New web site here:

http://noiseprotocol.org/

Allegedly it is the transport encryption protocol n= ow used by over a billion WhatsApp users worldwide.

I bring it up mostly to ask if anyone is doing or plans to do analysis on= it.

--
Tony Arcieri=
--001a113fe1be94c136052fcc068b-- From nobody Wed Apr 6 07:01:15 2016 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BAE812D5D5 for ; Wed, 6 Apr 2016 07:01:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.131 X-Spam-Level: X-Spam-Status: No, score=-0.131 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_NAME_DR=1, RCVD_IN_SORBS_WEB=0.77, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nSUdd-djQax7 for ; Wed, 6 Apr 2016 07:01:12 -0700 (PDT) Received: from mail.katezarealty.com (cvps8815162906.hostwindsdns.com [104.168.158.213]) by ietfa.amsl.com (Postfix) with ESMTP id 34CCF12D525 for ; Wed, 6 Apr 2016 07:01:12 -0700 (PDT) Received: from iMassi.local (unknown [200.61.9.66]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.katezarealty.com (Postfix) with ESMTPSA id 627E43743B78 for ; Wed, 6 Apr 2016 10:01:11 -0400 (EDT) To: cfrg@irtf.org From: "Dr. Pala" Organization: OpenCA Labs Message-ID: <570516A0.3090502@openca.org> Date: Wed, 6 Apr 2016 11:01:04 -0300 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [Cfrg] Question about XTS mode X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2016 14:01:14 -0000 Hi all, I wanted to ask a small question on the list - I hope it is not too much off topic. I was talking with Rich Saltz and Jim Shaad about using the AES in XTS mode and I have a couple of concerns about the security of the encryption key for which we did not have a definitive answer. In particular, I was wondering if re-using the encryption key might be a problem in this case (usually it is a bad idea for any stream-like ciphers) since I am not familiar with the internals of XTS (i.e., encrypting different files with the same key is safe or does it provides a security risk ?). Last question I have is about the different security characteristics of XTS and CRT - are they practically equivalent ? Thanks, -- Massimiliano Pala, PhD Director at OpenCA Labs twitter: @openca From nobody Wed Apr 6 07:22:46 2016 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBE3312D565 for ; Wed, 6 Apr 2016 07:22:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r8S11WmVGNua for ; Wed, 6 Apr 2016 07:22:38 -0700 (PDT) Received: from mail-wm0-x229.google.com (mail-wm0-x229.google.com [IPv6:2a00:1450:400c:c09::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 33F1112D0B4 for ; Wed, 6 Apr 2016 07:22:38 -0700 (PDT) Received: by mail-wm0-x229.google.com with SMTP id l6so67575332wml.1 for ; Wed, 06 Apr 2016 07:22:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=F2MzI83Hsb+l3Ti2793mMi88lHgYt8uZEveIoe3s8V0=; b=ztPwdsLpybzH7xrJ5yQ6n4poIW8KSO7cIcomQN7h3is9CRpwLDov6R45eCVI29Y0lo DCiJCW8U9DVIVSVqPpOUQCvFSyO0TnHvZIBuRlj8ODnuoMB24nTkjzpVpmR7zNesy2e1 dr4dIq3nTieoxgmgxf4Z5BRgo6hxWkPDh9OdY5CKfUkeFuSrubK6dgBsToPL2YnImER8 yflIrLw7bsLUcCrLsfKgGLCdS02LkpMoMWcHVTIUzGkMl0JJqMGwITPRX0ZFzvCf122l OjX0aKfsB2GYnmfxhn7Ah2Adik9aSSb5qTxfMZZF7M5Zs4S5ds3Ncl3IgKe2xa9qfkRk jm3A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=F2MzI83Hsb+l3Ti2793mMi88lHgYt8uZEveIoe3s8V0=; b=JxrRi7TZCw9Z97Xy972O3jaFPGx4wQkJO6f6GYgZC/zZl4QQg9TYiAj6ya1jXnf559 zkPEBEJ107Xbit3GUPkOz9RR59HkPv1BiR+2VKmyyjFD0tf1Nunbz8JXzUZe0td440M+ 773W3psPEIkYYiV2zcuDQft38iSAugm/f2PqI+C/jHHS1ijNTNJr3iyQvDRCSy8n9xvP IZ5tCMxzRJz4psuiWc3pBLAv8a5MrA1QPili9EY4gShbobF8tNzQxxtWrZxb5wq4v9+M qHHWddExdBaXg5+GiXVv2mltUdhUj++HsnqFt+1uzTyPBYFdOMOJhSGp2boMuJ82eiLr TZoQ== X-Gm-Message-State: AD7BkJK8kz8GeOPv4OeN3FdDxN7jHK919XBlo7ag5Q7H2b93LLew+gC+nD4S9iwZz3tuRnc04wJ8FHQ8K7GOzg== MIME-Version: 1.0 X-Received: by 10.194.171.130 with SMTP id au2mr24105937wjc.99.1459952556675; Wed, 06 Apr 2016 07:22:36 -0700 (PDT) Received: by 10.194.23.195 with HTTP; Wed, 6 Apr 2016 07:22:36 -0700 (PDT) Received: by 10.194.23.195 with HTTP; Wed, 6 Apr 2016 07:22:36 -0700 (PDT) In-Reply-To: <570516A0.3090502@openca.org> References: <570516A0.3090502@openca.org> Date: Wed, 6 Apr 2016 16:22:36 +0200 Message-ID: From: Natanael To: "Dr. Pala" Content-Type: multipart/alternative; boundary=089e011773ef879c6a052fd1b1fd Archived-At: Cc: cfrg@irtf.org Subject: Re: [Cfrg] Question about XTS mode X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2016 14:22:44 -0000 --089e011773ef879c6a052fd1b1fd Content-Type: text/plain; charset=UTF-8 Den 6 apr. 2016 16:01 skrev "Dr. Pala" : > > Hi all, > > I wanted to ask a small question on the list - I hope it is not too much off topic. I was talking with Rich Saltz and Jim Shaad about using the AES in XTS mode and I have a couple of concerns about the security of the encryption key for which we did not have a definitive answer. > > In particular, I was wondering if re-using the encryption key might be a problem in this case (usually it is a bad idea for any stream-like ciphers) since I am not familiar with the internals of XTS (i.e., encrypting different files with the same key is safe or does it provides a security risk ?). > > Last question I have is about the different security characteristics of XTS and CRT - are they practically equivalent ? XTS behaves like a block cipher, not like a stream cipher. Multiple encryptions under the same key will have the same result as ECB on a per-block basis (it is deterministic), you can see if a previous ciphertext / plaintext reoccurs in the exact same place. Across blocks, this isn't possible (so moving a file within the encrypted volume is indistinguishable from two random writes). This is because XTS within a disk block first encrypts the block's number, as well as each cipher block's number within the disk block (a 1k disk block fits 8x 128 bit cipher blocks), and then uses that as an input for the final encryption of the plaintext (it's like a full-disk key schedule, every cipher block got a unique salt). For local encryption, no problem. For storage on cloud services, attacks like selective roll-back of individual blocks is possible due to lack of ciphertext authentication (sign your encrypted volume before backup to avoid this), and you'll reveal a lot of usage statistics if you sync changes often, such as if/when you delete files (frequent reoccurances of zeroed blocks). But the plaintext won't leak, neither will the key. --089e011773ef879c6a052fd1b1fd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


Den 6 apr. 2016 16:01 skrev "Dr. Pala" <director@openca.org>:
>
> Hi all,
>
> I wanted to ask a small question on the list - I hope it is not too mu= ch off topic. I was talking with Rich Saltz and Jim Shaad about using the A= ES in XTS mode and I have a couple of concerns about the security of the en= cryption key for which we did not have a definitive answer.
>
> In particular, I was wondering if re-using the encryption key might be= a problem in this case (usually it is a bad idea for any stream-like ciphe= rs) since I am not familiar with the internals of XTS (i.e., encrypting dif= ferent files with the same key is safe or does it provides a security risk = ?).
>
> Last question I have is about the different security characteristics o= f XTS and CRT - are they practically equivalent ?

XTS behaves like a block cipher, not like a stream cipher.

Multiple encryptions under the same key will have the same r= esult as ECB on a per-block basis (it is deterministic), you can see if a p= revious ciphertext / plaintext reoccurs in the exact same place. Across blo= cks, this isn't possible (so moving a file within the encrypted volume = is indistinguishable from two random writes).

This is because XTS within a disk block first encrypts the b= lock's number, as well as each cipher block's number within the dis= k block (a 1k disk block fits 8x 128 bit cipher blocks), and then uses that= as an input for the final encryption of the plaintext (it's like a ful= l-disk key schedule, every cipher block got a unique salt).

For local encryption, no problem. For storage on cloud servi= ces, attacks like selective roll-back of individual blocks is possible due = to lack of ciphertext authentication (sign your encrypted volume before bac= kup to avoid this), and you'll reveal a lot of usage statistics if you = sync changes often, such as if/when you delete files (frequent reoccurances= of zeroed blocks).

But the plaintext won't leak, neither will the key.

--089e011773ef879c6a052fd1b1fd-- From nobody Wed Apr 6 07:39:11 2016 Return-Path: <_@lvh.cc> X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7448812D1E4 for ; Wed, 6 Apr 2016 07:39:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lvh-cc.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CLbtsOmTgPMS for ; Wed, 6 Apr 2016 07:39:07 -0700 (PDT) Received: from mail-io0-x236.google.com (mail-io0-x236.google.com [IPv6:2607:f8b0:4001:c06::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A3AFC12D15F for ; Wed, 6 Apr 2016 07:39:07 -0700 (PDT) Received: by mail-io0-x236.google.com with SMTP id 2so58510404ioy.1 for ; Wed, 06 Apr 2016 07:39:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lvh-cc.20150623.gappssmtp.com; s=20150623; h=sender:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=v6+yXyjetiKmjCedXTjGhQmpRBY4ejv9qsLR5IhxmuI=; b=DtuYLzxffRaDvCW+EDRca7ANRtAf5MGPuAqT4nKDNUWggAzAdJ2FHPD9Ljtbvit+Fr SeVpDnhFeqlysme1dMfQyGSclHPBNPI8rC8FCYMiVqIQKRFyXOsEj4MOs/dg4NXAlvFd XeeeNvwDVKpGz5kzT6/aOiLAuwb8yZIsKisXCdW2AnmhuTtAc12DWJJtBEQT1Q+Lp/mp 5EpMEYAEwOWDF3OBTkZFxxTTySIRRAJ+kU2+Dhcfvaurp2fm0YK5WOlLukYp98u3LUhx 8kI8qa6y5cxaTEqTovqqLMUK4QENIw/k7xRvv8fUKqDFQAoSxYdl4EdkpkAw6J9b6nRx yrxQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:mime-version:subject:from:in-reply-to :date:cc:content-transfer-encoding:message-id:references:to; bh=v6+yXyjetiKmjCedXTjGhQmpRBY4ejv9qsLR5IhxmuI=; b=Mn+xfeYmtXr0WZmm2Jl7NXhf3DjW6+9cP9PRoGIr4bz0C4kHTsUh3lcQ7IyfQ95hhh qAFJbXcaibHvNk/+oheIOnci7vr3EAKzgNVNrT+Py6gK7bBqkBLC/ZaMvyKnUKXKAIHU CGBq+0dz6q7VzmL+Xm62ficIduf5xUBcEDJgFyo7hRRj17TqaRktv9+s7mdZdRjcyT5c E4lWYFoUeG8onMCH4QzCO5+vdP0807R77VApzZzczipam057xpItaq3d0FAkyT41sTvK lsrCJNxRoMV4bvFpUr428k5zSLS/AbL0afWkHvg0oGFqB3LKcdA55V8jUcxDKcbocj3z 5E9Q== X-Gm-Message-State: AD7BkJIjwSusC1IdnnlZ40LBmakcOHogEXrh9+m0vPwm/K5WH56V4S8DgJFTjEla2gmubw== X-Received: by 10.107.63.215 with SMTP id m206mr4964071ioa.15.1459953546919; Wed, 06 Apr 2016 07:39:06 -0700 (PDT) Received: from ?IPv6:2601:241:200:6ac0:391a:125:438:52d2? ([2601:241:200:6ac0:391a:125:438:52d2]) by smtp.gmail.com with ESMTPSA id e15sm9530681igq.20.2016.04.06.07.39.05 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 06 Apr 2016 07:39:05 -0700 (PDT) Sender: Laurens Van Houtven <_@lvh.cc> Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: lvh <_@lvh.io> In-Reply-To: <570516A0.3090502@openca.org> Date: Wed, 6 Apr 2016 09:39:05 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <47880DBB-E5DC-44A0-8CDE-A008C8B5460C@lvh.io> References: <570516A0.3090502@openca.org> To: "Dr. Pala" X-Mailer: Apple Mail (2.3124) Archived-At: Cc: cfrg@irtf.org Subject: Re: [Cfrg] Question about XTS mode X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2016 14:39:09 -0000 Hi, > On Apr 6, 2016, at 9:01 AM, Dr. Pala wrote: >=20 > Hi all, >=20 > I wanted to ask a small question on the list - I hope it is not too = much off topic. I was talking with Rich Saltz and Jim Shaad about using = the AES in XTS mode and I have a couple of concerns about the security = of the encryption key for which we did not have a definitive answer. >=20 > In particular, I was wondering if re-using the encryption key might be = a problem in this case (usually it is a bad idea for any stream-like = ciphers) since I am not familiar with the internals of XTS (i.e., = encrypting different files with the same key is safe or does it provides = a security risk ?). I would recommend reading more about the internals of XTS, as I imagine = this will clear stuff up. I recommend starting with Rogaway=E2=80=99s = XEX paper, then moving on to XTS (say, the NIST spec). When you=E2=80=99re talking about bad consequences of reusing keys, = I=E2=80=99m assuming you=E2=80=99re referring to reusing _keystreams_ as = produced by CTR-interpreted-as-a-synchronous-stream-cipher, since = reusing keys is fine as long as you don=E2=80=99t reuse nonces. That=E2=80= =99s not really a problem XTS has: XTS does not work like a stream = cipher, but more like a very very wide block cipher; two different = inputs with the same key and tweak (~sector number for FDE) won=E2=80=99t = have any relation as they would with two different inputs with the same = key and nonce in CTR mode. > Last question I have is about the different security characteristics = of XTS and CRT - are they practically equivalent ? As above; definitely not :) lvh > Thanks, >=20 > --=20 > Massimiliano Pala, PhD > Director at OpenCA Labs > twitter: @openca >=20 > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > https://www.irtf.org/mailman/listinfo/cfrg From nobody Wed Apr 6 09:41:26 2016 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6283D12D5A3 for ; Wed, 6 Apr 2016 09:41:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.185 X-Spam-Level: X-Spam-Status: No, score=-1.185 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_RHS_DOB=1.514] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7WU4H18ebIdy for ; Wed, 6 Apr 2016 09:41:22 -0700 (PDT) Received: from mail-oi0-x236.google.com (mail-oi0-x236.google.com [IPv6:2607:f8b0:4003:c06::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7384A12D590 for ; Wed, 6 Apr 2016 09:41:22 -0700 (PDT) Received: by mail-oi0-x236.google.com with SMTP id p188so65210430oih.2 for ; Wed, 06 Apr 2016 09:41:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=nOH7NXskRHtZtBTqmCFqJvOoDiq2jiZ42K5r51RbYGI=; b=KWMs2T7v/YVmP/NrtsBNfOu+/q2kADn6P1zifMANF9awENKTm49YGd+N7Gjq7pqUjX NkXlaepRw3Fw3qp0HQdq/AVqUNjLZRbdUuiwhuZn9yaBHU9kvrGV7LgmnVJ6CPAjadyL LfKGox6kaTL3HJZOphmWKdDKcP+Nr1CZqpyoe5flMAqQHgCRr63/H0hbrtRdskFVUkPJ xjjzPRMXL6cQkFMW/ZuRW92fju6z2/jymybpwhCcpIZITBCuLx/5BEKdmqyMSCVDtl0V s68xQkcIhv/iVzNUS7B2rdMFimuYahDb0cO7S6y8YJoYsStoY6LpWuNreo4EXaJZa5oo QTtw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=nOH7NXskRHtZtBTqmCFqJvOoDiq2jiZ42K5r51RbYGI=; b=jrdyKKZnjB/GNkQWjMV2btlapJrS5gd5/jo8Aveuwc66RcB//E4LtIgW7+x2PycQRx +4nPj15yScHBlTtXGoabphcldKZblamT4jk0xbj+2rdvsDn+8Dsb5p1PcFk+BTE3WIpq o9X9JX9DrFqwuqa9R9MTcfCX4Z6vRJLfYxNvb8hmxWEhYeCExKIQyWJyFYhXEB1B4xum 4sE+PUveCXmLfb/PxeD2ZJV5+OKTMyllkQgP6sjnn7wTaqQFCfAwOFOwKF9dkjmv85p9 IFkkwTmrcQA5xNFBEBKXvn3Dc+stCORtq3vDoeXTsJrQJ9Mqz6LQT3nmPHLuXQEOAZ2p q/pg== X-Gm-Message-State: AD7BkJIagUIZjOhHJTb0HUSCztB4OSF73lIYHZzmT10gt+OscGgy8vVQNyI0JioJ4nO0TDj2gHZr5HAP25K1Mw== MIME-Version: 1.0 X-Received: by 10.202.95.68 with SMTP id t65mr2731843oib.7.1459960881850; Wed, 06 Apr 2016 09:41:21 -0700 (PDT) Received: by 10.60.95.41 with HTTP; Wed, 6 Apr 2016 09:41:21 -0700 (PDT) In-Reply-To: References: Date: Wed, 6 Apr 2016 09:41:21 -0700 Message-ID: From: Bill Cox To: Tony Arcieri Content-Type: multipart/alternative; boundary=001a113cdb14bfb143052fd3a1e5 Archived-At: Cc: "cfrg@irtf.org" Subject: Re: [Cfrg] Noise X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2016 16:41:25 -0000 --001a113cdb14bfb143052fd3a1e5 Content-Type: text/plain; charset=UTF-8 With a quick read over the Noise protocol, I am impressed. It may lack some of the cipher suite agility we see in TLS, and I do not see any extension mechanism, but the frameworks looks both simple and well designed. I am concerned that there seems to be no version negotiation, and the application software is expected to do this out-of-band, or in cleartext negotiation pre-handshake. The Noise documentation does a good job IMO covering various security properties. At this point, I think I would be able to spot many rookie mistakes such as malleable encrypted data, lack of entropy, and replayable messages. The Noise framework gives the user the flexibility to shoot themselves in the foot with all of these rookie mistakes, so the security of connections depends heavily on how the framework is used. If using one of the recommended modes, such as "Noise_XX", it looks hard to mess up badly, assuming version negotiation goes well. Noise_XX uses this handshake: Noise_XX -> e <- e, dhee, s, dhse -> s, dhse The 'e' is an ephemeral Curve25519 public key. 's' is a static Curve25519 public key. "dhee" and "dhse" I think are tokens indicating that the data following the tag will be encrypted using keys derived from two ephemeral keys (dhee) or one ephemeral and one static key (dhse). The signal protocol used on top of the Noise framework seems hard to analyze, at least from just the Java code. It looks like hiding meta-data, such as who is talking to who, was not a top level priority compared to the convenience of finding contacts who already use WhatsApp from your email contacts. IIUC (highly unlikely), this meta data (who talked to who, when, how long) is all that is legally required by the US government from telecommunications companies. Maybe hiding this meta data was intentionally not done by the WhatsApp team. In any case, kudos to the WhatsApp team. Regardless of the security of their implementation, it takes guts to ship strong end-to-end encryption in this political environment. Bill On Wed, Apr 6, 2016 at 12:36 AM, Tony Arcieri wrote: > WhatsApp announced today they are using Trevor Perrin's Noise protocol for > transport encryption protocol: > > https://www.whatsapp.com/security/WhatsApp-Security-Whitepaper.pdf > > New web site here: > > http://noiseprotocol.org/ > > Allegedly it is the transport encryption protocol now used by over a > billion WhatsApp users worldwide. > > I bring it up mostly to ask if anyone is doing or plans to do analysis on > it. > > -- > Tony Arcieri > > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > https://www.irtf.org/mailman/listinfo/cfrg > > --001a113cdb14bfb143052fd3a1e5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
With a quick read over the Noise protocol, I am impressed.= =C2=A0 It may lack some of the cipher suite agility we see in TLS, and I do= not see any extension mechanism, but the frameworks looks both simple and = well designed.=C2=A0 I am concerned that there seems to be no version negot= iation, and the application software is expected to do this out-of-band, or= in cleartext negotiation pre-handshake.=C2=A0 The Noise documentation does= a good job IMO covering various security properties.

At this point, I think I would be able to spot many rookie mistakes such= as malleable encrypted data, lack of entropy, and replayable messages.=C2= =A0 The Noise framework gives the user the flexibility to shoot themselves = in the foot with all of these rookie mistakes, so the security of connectio= ns depends heavily on how the framework is used.=C2=A0 If using one of the = recommended modes, such as "Noise_XX", it looks hard to mess up b= adly, assuming version negotiation goes well.=C2=A0 Noise_XX uses this hand= shake:

Noise_XX =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0
=C2=A0-> e
=C2=A0= <- e, dhee, s, dhse
=C2=A0-> s, dhse

The 'e' is an ephemeral Curve25519 public key. =C2=A0's'= is a static Curve25519 public key. =C2=A0"dhee" and "dhse&q= uot; I think are tokens indicating that the data following the tag will be = encrypted using keys derived from two ephemeral keys (dhee) or one ephemera= l and one static key (dhse).

The signal protocol= =C2=A0used on top of the Noise framework seems hard to analyze, at least fr= om just the Java code.=C2=A0 It looks like hiding meta-data, such as who is= talking to who, was not a top level priority compared to the convenience o= f finding contacts who already use WhatsApp from your email contacts.
=

IIUC (highly unlikely), this meta data (who talked to w= ho, when, how long) is all that is legally required by the US government fr= om telecommunications companies.=C2=A0 Maybe hiding this meta data was inte= ntionally not done by the WhatsApp team.=C2=A0 In any case, kudos to the Wh= atsApp team.=C2=A0 Regardless of the security of their implementation, it t= akes guts to ship strong end-to-end encryption in this political environmen= t.

Bill

On Wed, Apr 6, 2016 at 12:36 AM, Ton= y Arcieri <bascule@gmail.com> wrote:
WhatsApp announced today they are using Trevor = Perrin's Noise protocol for transport encryption protocol:

https://www.whatsapp.com/security/WhatsApp-Sec= urity-Whitepaper.pdf

New web site = here:


Alle= gedly it is the transport encryption protocol now used by over a billion Wh= atsApp users worldwide.

I bring it up mostly to as= k if anyone is doing or plans to do analysis on it.

--
Tony Arcieri

_______________________________________________
Cfrg mailing list
Cfrg@irtf.org
https://www.irtf.org/mailman/listinfo/cfrg


--001a113cdb14bfb143052fd3a1e5-- From nobody Wed Apr 6 12:15:09 2016 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30C6212D539 for ; Wed, 6 Apr 2016 12:15:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Et5vZ6PvsQV for ; Wed, 6 Apr 2016 12:15:06 -0700 (PDT) Received: from welho-filter1.welho.com (welho-filter1.welho.com [83.102.41.23]) by ietfa.amsl.com (Postfix) with ESMTP id C3F6812D52F for ; Wed, 6 Apr 2016 12:15:05 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter1.welho.com (Postfix) with ESMTP id 4076F2BA6; Wed, 6 Apr 2016 22:15:04 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp3.welho.com ([IPv6:::ffff:83.102.41.86]) by localhost (welho-filter1.welho.com [::ffff:83.102.41.23]) (amavisd-new, port 10024) with ESMTP id dVO_vhodr17Q; Wed, 6 Apr 2016 22:15:04 +0300 (EEST) Received: from LK-Perkele-V2 (87-100-143-35.bb.dnainternet.fi [87.100.143.35]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp3.welho.com (Postfix) with ESMTPSA id 08EAE2310; Wed, 6 Apr 2016 22:15:04 +0300 (EEST) Date: Wed, 6 Apr 2016 22:15:02 +0300 From: Ilari Liusvaara To: Bill Cox Message-ID: <20160406191502.GA25294@LK-Perkele-V2.elisa-laajakaista.fi> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Sender: ilariliusvaara@welho.com Archived-At: Cc: "cfrg@irtf.org" Subject: Re: [Cfrg] Noise X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2016 19:15:08 -0000 On Wed, Apr 06, 2016 at 09:41:21AM -0700, Bill Cox wrote: > With a quick read over the Noise protocol, I am impressed. It may lack > some of the cipher suite agility we see in TLS, and I do not see any > extension mechanism, but the frameworks looks both simple and well > designed. I am concerned that there seems to be no version negotiation, > and the application software is expected to do this out-of-band, or in > cleartext negotiation pre-handshake. The Noise documentation does a good > job IMO covering various security properties. As far as I can see, Application can send data before the handshake and this data is confirmed. Ther are also application message fields in handshake messages. One thing I noticed is that there doesn't seem to be space for splitting messages, limiting application data to ~63kB per handshake message, but going for TLS, that's usually plenty. Also, it is unclear how to do parameter negotiation without losing a roundtrip (client negotiation can be included in prologue but what about server data sent immediately?) -Ilari From nobody Wed Apr 6 21:44:37 2016 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D18DB12D0AE for ; Wed, 6 Apr 2016 21:44:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.185 X-Spam-Level: X-Spam-Status: No, score=-1.185 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_RHS_DOB=1.514] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pfnju90DC3NF for ; Wed, 6 Apr 2016 21:44:33 -0700 (PDT) Received: from mail-ob0-x231.google.com (mail-ob0-x231.google.com [IPv6:2607:f8b0:4003:c01::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7CF2112D0A3 for ; Wed, 6 Apr 2016 21:44:33 -0700 (PDT) Received: by mail-ob0-x231.google.com with SMTP id bg3so45407043obb.1 for ; Wed, 06 Apr 2016 21:44:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=FzaSIgrRpJ+Rg/wIY3w4p5eifimaosvJwFAb+PhaWJg=; b=IkDaDfGvL15igPYAZ6dP049+SCQuIsBsdTej9XbtSauBLhNPYXfT2ADMzvFWW1e8kX 3ww8cSjMlURJtNFx4/U5k46YMg3YdC/2oh7YYxjKqrGBROluBNQgEIRZQT2XdZNvPAkW eRYsBbB2oca++AQcD7P6Ki9+YJwcY5lG+lnAh7Xdq9wDAoSZrZLHNmg/PGvQXwjEtIOu 23xM+TsOx+36vvDzuQ0uDWKtY9vzNlZKdEH0/9S4lypTPvc9fXQJJ55xl32VUvQQVx/J snr31iM24vrWmQ9GBXzybvdj9gWKg02FR/u9e7pAm0sGPmBgha4HbRqzOvEQc2bUGksb hRGA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=FzaSIgrRpJ+Rg/wIY3w4p5eifimaosvJwFAb+PhaWJg=; b=dkdpEBj3+CWjQ9+iN4jITV9BGTr4uSIY0Fk3j1GmxN33nJK2PP/Jc2qorFdeC5nfS2 eiC6cZDuauUd+JftOhIjXSjo67geSb9yl15eqYiE4vtsaARw5nWJUhhM9qW10KCU1vzr LidZPNziPL9yKS477g9h315Cge8beutz/BAOuJ6ApG47RytRN6aSDyOB9RwmAsivgtcD hIibrhoj89perVBRHeQODHg0HuKMiRUwWFcUFZ6Bao4d0yqJTa/klbujiwgIzeaX+sAS Jxym3Ou1bvcXhoHmy8G/zFMPp1ls/ach3ul6me/d9yev2rL0h4xoUs+NDn0S3jijmU33 KOAw== X-Gm-Message-State: AD7BkJJfqyQUxy5DMcfx77epRa57QJ66XOGCee0ZxUccTMTu0wf3BJjtvS3eroY7kpPaBk7SWuJ1U5gLLM/rQA== MIME-Version: 1.0 X-Received: by 10.60.46.193 with SMTP id x1mr453637oem.17.1460004272905; Wed, 06 Apr 2016 21:44:32 -0700 (PDT) Received: by 10.60.95.41 with HTTP; Wed, 6 Apr 2016 21:44:32 -0700 (PDT) In-Reply-To: <20160406191502.GA25294@LK-Perkele-V2.elisa-laajakaista.fi> References: <20160406191502.GA25294@LK-Perkele-V2.elisa-laajakaista.fi> Date: Wed, 6 Apr 2016 21:44:32 -0700 Message-ID: From: Bill Cox To: Ilari Liusvaara Content-Type: multipart/alternative; boundary=089e013a2c6a0ea5d7052fddbc3b Archived-At: Cc: "cfrg@irtf.org" Subject: Re: [Cfrg] Noise X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2016 04:44:36 -0000 --089e013a2c6a0ea5d7052fddbc3b Content-Type: text/plain; charset=UTF-8 My effort to further analyze WhatsApp security failed, because I can't find any source code implementing Noise Pipes as claimed by WhatsApp. The noiseprotocol.org site has 3 implementations: one in Go, one in Rust, and one in Haskell, while the libsignal library the WhatsApp points to is entirely in Java and has no code that resembles a Noise Pipes implementation. Is this more security through obscurity? Bill --089e013a2c6a0ea5d7052fddbc3b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
My effort to further analyze Wh= atsApp security failed, because I can't find any source code implementi= ng Noise Pipes as claimed by WhatsApp.

=
The n= oiseprotocol.org site has 3 implementations: one in Go, one in Rust, an= d one in Haskell, while the libsignal library the WhatsApp points to is ent= irely in Java and has no code that resembles a Noise Pipes implementation.= =C2=A0 Is this more security through obscurity?

Bill
--089e013a2c6a0ea5d7052fddbc3b-- From nobody Thu Apr 7 06:39:45 2016 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A4A412D1B9 for ; Thu, 7 Apr 2016 06:39:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GXp3jqQzuRfi for ; Thu, 7 Apr 2016 06:39:41 -0700 (PDT) Received: from www363.your-server.de (www363.your-server.de [78.46.179.9]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2DA0712D1AC for ; Thu, 7 Apr 2016 06:39:39 -0700 (PDT) Received: from [88.198.220.132] (helo=sslproxy03.your-server.de) by www363.your-server.de with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.85_2) (envelope-from ) id 1aoA9o-00080S-Gv for cfrg@irtf.org; Thu, 07 Apr 2016 15:39:36 +0200 Received: from [131.155.70.178] by sslproxy03.your-server.de with esmtpsa (TLSv1.2:DHE-RSA-AES256-SHA:256) (Exim 4.84_2) (envelope-from ) id 1aoA9n-0003K9-Qt for cfrg@irtf.org; Thu, 07 Apr 2016 15:39:35 +0200 To: "cfrg@irtf.org" From: "A. Huelsing" Message-ID: <57066319.5050606@huelsing.net> Date: Thu, 7 Apr 2016 15:39:37 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------020108030904010904040206" X-Authenticated-Sender: ietf@huelsing.net X-Virus-Scanned: Clear (ClamAV 0.99/21486/Tue Apr 5 22:19:10 2016) Archived-At: Subject: [Cfrg] Topics for hash-based signatures (draft-huelsing-cfrg-hash-sig-xmss) for Friday X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2016 13:39:44 -0000 This is a multi-part message in MIME format. --------------020108030904010904040206 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Hi, in preparation for Friday we want to point you at the topics we'd like to discuss. 1. Instantiation aka choice of hash function ------------------------------------------------------- This was already briefly discussed on the list and we got some further direct feedback on this. We think the important parameter set is for 256 bit classical / 128 bit quantum security. Currently this is implemented using SHA2-256 for everything besides the PRG which uses ChaCha20. Besides, the draft proposes a 512 bit classical / 256 bit quantum secure implementation using SHA2-512. The main comments we got were 1. Why no SHA3 2. Why no plain SHA2 implementation (code size) As we do not want to blow up the number of possibilities, our proposal would be 1.) Plain SHA2-256 implementation as mandatory 2.) SHA2-512 optional 3.) SHA3-(256/512) optional 2. Addresses ------------------ We simplified the address format in the last version such that fields do not cross byte boundaries. However, this leaves not enough space for large tree indices. Currently, the address format only supports tree indices up to 40 bit. Preventing parameters with e.g. 12 layers of trees of height 5 as used in SPHINCS. We suggest to increase the address size to 32 byte. This is another motivation to remove the SHA2/ChaCha implementation as this was not possible with ChaCha20 because nonce + counter just give us 16 byte. 3. Randomness for message hash --------------------------------------------- According to the current draft R = PRF(SK_PRF, M), i.e. the randomness is obtained, applying a PRF to the message, keyed with a dedicated secret key. The reason is that this is a common way to derandomize this step. However, as XMSS is stateful anyway, we could just do R = PRF(SK_PRF, idx) using the idx of the used one-time key pair. For long messages this prevents processing the message twice. -------------------------------------------- Any feedback also before the meeting tomorrow is welcome. Andreas --------------020108030904010904040206 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit Hi,
in preparation for Friday we want to point you at the topics we'd like to discuss.

1. Instantiation aka choice of hash function
-------------------------------------------------------
This was already briefly discussed on the list and we got some further direct feedback on this.
We think the important parameter set is for 256 bit classical / 128 bit quantum security.
Currently this is implemented using SHA2-256 for everything besides the PRG which uses ChaCha20.
Besides, the draft proposes a 512 bit classical / 256 bit quantum secure implementation using SHA2-512.

The main comments we got were
1. Why no SHA3
2. Why no plain SHA2 implementation (code size)

As we do not want to blow up the number of possibilities, our proposal would be

1.) Plain SHA2-256 implementation as mandatory
2.) SHA2-512 optional
3.) SHA3-(256/512) optional


2. Addresses
------------------
We simplified the address format in the last version such that fields do not cross byte boundaries.
However, this leaves not enough space for large tree indices. Currently, the address format only
supports tree indices up to 40 bit. Preventing parameters with e.g. 12 layers of trees of height 5
as used in SPHINCS.

We suggest to increase the address size to 32 byte. This is another motivation to remove the SHA2/ChaCha implementation
as this was not possible with ChaCha20 because nonce + counter just give us 16 byte.


3. Randomness for message hash
---------------------------------------------
According to the current draft R = PRF(SK_PRF, M),
i.e. the randomness is obtained, applying a PRF to the message,
keyed with a dedicated secret key. The reason is that this is a common
way to derandomize this step.

However, as XMSS is stateful anyway, we could just do
R = PRF(SK_PRF, idx)
using the idx of the used one-time key pair. For long messages this prevents
processing the message twice.

--------------------------------------------

Any feedback also before the meeting tomorrow is welcome.

Andreas

--------------020108030904010904040206-- From nobody Thu Apr 7 08:53:46 2016 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7C3012D13E for ; Thu, 7 Apr 2016 08:53:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z_2RRYdkfweL for ; Thu, 7 Apr 2016 08:53:41 -0700 (PDT) Received: from mail-qk0-x233.google.com (mail-qk0-x233.google.com [IPv6:2607:f8b0:400d:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B4B3012D0E3 for ; Thu, 7 Apr 2016 08:53:40 -0700 (PDT) Received: by mail-qk0-x233.google.com with SMTP id r184so32473863qkc.1 for ; Thu, 07 Apr 2016 08:53:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:subject:date:message-id:cc:to:mime-version; bh=Aw3jGkZp9Zn2sSqR19zW/JD4t66iHwuEa5Qr3sKiviQ=; b=JWgy2fqnZPgrZMFJGn8hXx3yn+AYVlSWbbmOzdiZdl0QkgJZd2PRO1ARX2QXXcrSjK XgKxcPbe2OxuG1Ah/vfjQ+RsHrpJiElj+ITD1oEaiFIXAy1RG0EIxm6kQmBcWbgY+o2H d3VMO30znB3m3M5uLtxr4nqdqX0oiPAEUNKMVsdnjHGMl1pZ4UNDci7MkWZcmWRndOuM gCIH2nwH1Rv6JSZNSyTDXNVxPFb4hYngb2PB+bVno5QU0b6KgJ9wezG8nMkaL5eX/dVs rgvhTPxC7ddITlruPdIGQL6ESfqpmzjmilFPLYwmW3/i7UBO7JAD6NzOEm2Xqi0Ojnrc Gttw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:subject:date:message-id:cc:to:mime-version; bh=Aw3jGkZp9Zn2sSqR19zW/JD4t66iHwuEa5Qr3sKiviQ=; b=ETZTMLrvrNm2iEbmvobJzhjdQQ/PuxehP4AIxo3n7gPH7NoNnTNve1OWZ+k5miqlQP 8+dBB9NRL+I2uyQNarvy/eDDKfEWOd/y0dnzsREi2pa80aJykc1j1V31EbTi6eLDUsf6 uP804x+uF5CSB+nSGwArYBI9kbkUYmChpHFAE5n83uEMoFQgxnC4sc2w3OQobAUCtcaa dydkS8/PXx3Jtwk3Ab9G3Kc8/CyuonGyMO5tFq3eK0LIZwJjDMyTLwdNHEyejcjP0TYO 23/s1SN9JngKSyJ9lrRSL3l5SpHd+bQgtezlJwOEcQFe03kk2L+eUiEIZkXNbNrRT65A QzSg== X-Gm-Message-State: AD7BkJInBAIgORYQTJ2MbtFAzAEJFIcUY8NMUBJE39m2m1L8tgK3bGJCyqM2ZPwwKhS9LA== X-Received: by 10.55.72.67 with SMTP id v64mr4616852qka.101.1460044419859; Thu, 07 Apr 2016 08:53:39 -0700 (PDT) Received: from [192.168.1.194] ([201.177.50.160]) by smtp.gmail.com with ESMTPSA id j67sm3616175qgj.35.2016.04.07.08.53.13 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 07 Apr 2016 08:53:38 -0700 (PDT) From: Bryan Ford Content-Type: multipart/signed; boundary="Apple-Mail=_A68F111E-1EA5-4C10-B1F3-BC9123FD9F9F"; protocol="application/pkcs7-signature"; micalg=sha1 Date: Thu, 7 Apr 2016 12:52:26 -0300 Message-Id: <1AAB080D-9E63-4893-B43F-7764C1445CB6@gmail.com> To: "cfrg@irtf.org" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Christian Huitema Subject: [Cfrg] Fingerprint schemes resistant to similar-fingerprint-mining? X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2016 15:53:43 -0000 --Apple-Mail=_A68F111E-1EA5-4C10-B1F3-BC9123FD9F9F Content-Type: multipart/alternative; boundary="Apple-Mail=_DDC60266-4732-4D49-955C-DA8FBA833420" --Apple-Mail=_DDC60266-4732-4D49-955C-DA8FBA833420 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 OpenPGP needs a replacement for its old SHA1-based key fingerprint = scheme, and while the topic is under discussion on the openpgp list, = I=E2=80=99d like to bring up a question and see if there=E2=80=99s any = broader interest in CFRG. OpenPGP key fingerprints especially - but also cryptographic = key-fingerprints in general - get printed on business cards, displayed = on websites, and get used for =E2=80=9Ceyeball-comparison=E2=80=9D of = public keys or certificates, etc. But how many users in practice bother = to verify more than the first few (and maybe last few) digits of a = fingerprint? =20 The problem: as others have pointed out, this leaves practically all = =E2=80=9Cmanual-comparison=E2=80=9D uses of fingerprints open to = =E2=80=9Csimilar-fingerprint-mining=E2=80=9D attacks. For example, you = want to impersonate me, so you invest some CPU time into creating many = PGP (or other) public keys until you find one whose fingerprint looks = similar to mine in the first and/or last digits. It=E2=80=99s fairly = easy with todays hardware =E2=80=99s mine for quite a few fingerprint = digits matching whatever you want. Then you post the public key on = openpgp key servers, or send someone else E-mail claiming it=E2=80=99s = from me, and your victim thinks it really is from me because they = =E2=80=9Cchecked=E2=80=9D its fingerprint against what=E2=80=99s on my = business card or web site=E2=80=A6 =20 Possible solution: design new fingerprinting schemes to allow the = creator of a new key pair to invest some =E2=80=9Cmining=E2=80=9D = time/effort deliberately into the key creation, basically creating a key = pair that embodies a self-certifying proof-of-work that its fingerprint = reflects. This key-creation effort then greatly increases the amount of = effort an attacker would have to invest to mine for a key whose = fingerprint is similar in more than a few digits. For example, if I = invest around 1 minute into creating my key-pair, a similarity attack = should cost an attacker with similar hardware around 2^B *minutes* worth = of CPU time to get B fingerprint bits to match mine, rather than = requiring only 2^B public-key-generation-and-hash calculations. I briefly sketched one possible approach yesterday in this message on = the openpgp list: = https://mailarchive.ietf.org/arch/msg/openpgp/w-WTcu-RL4SgXJw0K51FtWFqUJ0 = This approach builds on Argon2 and ideas previously suggested by = Christian Huitema and Philip Hallam-Baker and others. See that if = you=E2=80=99re interested in the details. But my main questions for the CFRG list are: (a) do people consider this = a problem; (b) is it important enough to try to solve; and (c) is it = strictly an =E2=80=9Copenpgp thing=E2=80=9D or is it potentially of = broader interest, since PGP isn=E2=80=99t the only crypto-based protocol = that uses uses fingerprints (though it may be most widely-deployed one = that relies heavily on fingerprints)? Thanks Bryan= --Apple-Mail=_DDC60266-4732-4D49-955C-DA8FBA833420 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
OpenPGP needs a replacement for its old = SHA1-based key fingerprint scheme, and while the topic is under = discussion on the openpgp list, I=E2=80=99d like to bring up a question = and see if there=E2=80=99s any broader interest in CFRG.

OpenPGP key fingerprints = especially - but also cryptographic key-fingerprints in general - get = printed on business cards, displayed on websites, and get used for = =E2=80=9Ceyeball-comparison=E2=80=9D of public keys or certificates, = etc.  But how many users in practice bother to verify more than the = first few (and maybe last few) digits of a fingerprint?  

The problem: as others = have pointed out, this leaves practically all =E2=80=9Cmanual-comparison=E2= =80=9D uses of fingerprints open to =E2=80=9Csimilar-fingerprint-mining=E2= =80=9D attacks.  For example, you want to impersonate me, so you = invest some CPU time into creating many PGP (or other) public keys until = you find one whose fingerprint looks similar to mine in the first and/or = last digits.  It=E2=80=99s fairly easy with todays hardware =E2=80=99= s mine for quite a few fingerprint digits matching whatever you want. =  Then you post the public key on openpgp key servers, or send = someone else E-mail claiming it=E2=80=99s from me, and your victim = thinks it really is from me because they =E2=80=9Cchecked=E2=80=9D its = fingerprint against what=E2=80=99s on my business card or web site=E2=80=A6=  

Possible= solution: design new fingerprinting schemes to allow the creator of a = new key pair to invest some =E2=80=9Cmining=E2=80=9D time/effort = deliberately into the key creation, basically creating a key pair that = embodies a self-certifying proof-of-work that its fingerprint reflects. =  This key-creation effort then greatly increases the amount of = effort an attacker would have to invest to mine for a key whose = fingerprint is similar in more than a few digits.  For example, if = I invest around 1 minute into creating my key-pair, a similarity attack = should cost an attacker with similar hardware around 2^B *minutes* worth = of CPU time to get B fingerprint bits to match mine, rather than = requiring only 2^B public-key-generation-and-hash = calculations.

I = briefly sketched one possible approach yesterday in this message on the = openpgp list: https://mailarchive.ietf.org/arch/msg/openpgp/w-WTcu-RL4SgXJw0K= 51FtWFqUJ0  This approach builds on Argon2 and ideas previously = suggested by Christian Huitema and Philip Hallam-Baker and others. =  See that if you=E2=80=99re interested in the details.

But my main questions = for the CFRG list are: (a) do people consider this a problem; (b) is it = important enough to try to solve; and (c) is it strictly an =E2=80=9Copenp= gp thing=E2=80=9D or is it potentially of broader interest, since PGP = isn=E2=80=99t the only crypto-based protocol that uses uses fingerprints = (though it may be most widely-deployed one that relies heavily on = fingerprints)?

Thanks
Bryan
= --Apple-Mail=_DDC60266-4732-4D49-955C-DA8FBA833420-- --Apple-Mail=_A68F111E-1EA5-4C10-B1F3-BC9123FD9F9F Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJ+DCCBK8w ggOXoAMCAQICEQDgI8sVEoNTia1hbnpUZ2shMA0GCSqGSIb3DQEBCwUAMG8xCzAJBgNVBAYTAlNF MRQwEgYDVQQKEwtBZGRUcnVzdCBBQjEmMCQGA1UECxMdQWRkVHJ1c3QgRXh0ZXJuYWwgVFRQIE5l dHdvcmsxIjAgBgNVBAMTGUFkZFRydXN0IEV4dGVybmFsIENBIFJvb3QwHhcNMTQxMjIyMDAwMDAw WhcNMjAwNTMwMTA0ODM4WjCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hl c3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNV BAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWls IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAibEN2npTGU5wUh28VqYGJre4SeCW 51Gr8fBaE0kVo7SMG2C8elFCp3mMpCLfF2FOkdV2IwoU00oCf7YdCYBupQQ92bq7Fv6hh6kuQ1JD FnyvMlDIpk9a6QjYz5MlnHuI6DBk5qT4VoD9KiQUMxeZrETlaYujRgZLwjPU6UCfBrCxrJNAubUI kzqcKlOjENs9IGE8VQOO2U52JQIhKfqjfHF2T+7hX4Hp+1SA28N7NVK3hN4iPSwwLTF/Wb1SN7Az aS1D6/rWpfGXd2dRjNnuJ+u8pQc4doykqTj/34z1A6xJvsr3c5k6DzKrnJU6Ez0ORjpXdGFQvsZA P8vk4p+iIQIDAQABo4IBFzCCARMwHwYDVR0jBBgwFoAUrb2YejS0Jvf6xCZU7wO94CTLVBowHQYD VR0OBBYEFJJha4LhoqCqT+xn8cKj97SAAMHsMA4GA1UdDwEB/wQEAwIBhjASBgNVHRMBAf8ECDAG AQH/AgEAMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDARBgNVHSAECjAIMAYGBFUdIAAw RAYDVR0fBD0wOzA5oDegNYYzaHR0cDovL2NybC51c2VydHJ1c3QuY29tL0FkZFRydXN0RXh0ZXJu YWxDQVJvb3QuY3JsMDUGCCsGAQUFBwEBBCkwJzAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNl cnRydXN0LmNvbTANBgkqhkiG9w0BAQsFAAOCAQEAGypurFXBOquIxdjtzVXzqmthK8AJECOZD8Vm am+x9bS1d14PAmEA330F/hKzpICAAPz7HVtqcgIKQbwFusFY1SbC6tVNhPv+gpjPWBvjImOcUvi7 BTarfVil3qs7Y+Xa1XPv7OD7e+Kj//BCI5zKto1NPuRLGAOyqC3U2LtCS5BphRDbpjc06HvgARCl nMo6x59PiDRuimXQGoq7qdzKyjbR9PzCZCk1r9axp3ER0gNDsY8+muyeMlP0dpLKhjQHuSzK5hxK 2JkNwYbikJL7WkJqIyEQ6WXH9dW7fuqMhSACYurROgcsWcWZM/I4ieW26RZ6H3kU9koQGib6fIr7 mzCCBUEwggQpoAMCAQICEBalm03EcGSFWgbYcpp5puowDQYJKoZIhvcNAQELBQAwgZsxCzAJBgNV BAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAY BgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQg QXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xNTA2MjQwMDAwMDBaFw0xNjA2 MjMyMzU5NTlaMCYxJDAiBgkqhkiG9w0BCQEWFWJyeW5vc2F1cnVzQGdtYWlsLmNvbTCCASIwDQYJ KoZIhvcNAQEBBQADggEPADCCAQoCggEBAMA89U5ktW7a1k5qjaiycbEbBjLucLdRfzKh5us59o1a Qi0iRQfo1BEq6rG4MTvXburjxUdzuTCaDgOJ+g6PFKNfJP5H2lH962EXCNeJYKOwhpZtwVzpfsPV 8iKw7XjPwPiW4E7Ut7M1UHoN57yUy60/047gyYpZirf4lpv1G//cFcLKIMNB/GGK5YXNlBNalvMY Z/CK1yo8cf3s83gI4KGGE65RL1i3WpAFjwaffp5V6kp3PdiIXuKL8kO2HWID/McrynKKb46ARFzC joiV2qHn27LQiMwBwoDUxzfgCAxAl0uWaFgBqLmcws4lCIXN8jIHp6CNLKKyHHXWukv/EqUCAwEA AaOCAfMwggHvMB8GA1UdIwQYMBaAFJJha4LhoqCqT+xn8cKj97SAAMHsMB0GA1UdDgQWBBSlca2J DhGBY+vVSOfJ1I+3I9NqLzAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAX BggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYM KwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BT MF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET1NIQTI1NkNs aWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgZAGCCsGAQUFBwEBBIGDMIGA MFgGCCsGAQUFBzAChkxodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01PRE9TSEEyNTZDbGllbnRB dXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2Nz cC5jb21vZG9jYS5jb20wIAYDVR0RBBkwF4EVYnJ5bm9zYXVydXNAZ21haWwuY29tMA0GCSqGSIb3 DQEBCwUAA4IBAQAMNIE1FhYCtEA9JMwLoNKtQ4hZDcnUKYRcRihDhAHIKSTJtFQKBchp1MBTCP4P 1lfgdDHG+06Rv65VAKfBsjqMZmPQylvsxZg5kPJ5BPVgShQxGl5RSlMN3qLDcSbQt/6uPv9U+Vgq 8StMI6fIRSbbPwyKyZyM8gUnxR34dxzJ+mSGi0kdtUE36FIabTeXtjFVXN/2jDOrsvm8IHlp8nJM 23nHuqUsJyyIYFbaRKhApoMAzC5gynlg6APV2hz/JYlKSJABwpxZjYAtpyz5rQVIi2pPWs2Te2cd faykisGAOu/7nJtlcEGMCSd61tM43matZPa3MuBiko8kuzj0RMigMYIDwzCCA78CAQEwgbAwgZsx CzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZv cmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBD bGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQFqWbTcRwZIVaBthymnmm 6jAJBgUrDgMCGgUAoIIB5zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xNjA0MDcxNTUyMjdaMCMGCSqGSIb3DQEJBDEWBBTOeOoqBU1l/1adO0HEq4fhmYxmajCBwQYJ KwYBBAGCNxAEMYGzMIGwMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVz dGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UE AxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwg Q0ECEBalm03EcGSFWgbYcpp5puowgcMGCyqGSIb3DQEJEAILMYGzoIGwMIGbMQswCQYDVQQGEwJH QjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQK ExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UEAxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhl bnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEBalm03EcGSFWgbYcpp5puowDQYJKoZIhvcN AQEBBQAEggEAOfQdbC4l8E6lkjaDe+VuTBpQNv/ct1sczCgn+QfLovzSfJI5ae/vscIA86FqRdcf utitQKWUWtTnC7FOwAt1cMCLTJFPwBbLTF9CSz/+zk/wfPHCqYSJWMHfS0XJNI+zSsQFlvqVVYVy ZYJSgfu8hsmVFKza1SbHSrvUw0qGgcyyFtB1QnCNnWiH6dOHmvv3e8OBqwEq9/H28eGdOn3BatW7 5lKajsGs/kCYmdW8RIYh3TpZcO+4VAiGPMCanHnRxJ3mW09sYQzgiEJ+1shZdPeVvaajVeouwQsF PF47eJRyO4BrFQvb5tJrOmdJZaWBRVprrC+t8mTIOcCQDG0+yAAAAAAAAA== --Apple-Mail=_A68F111E-1EA5-4C10-B1F3-BC9123FD9F9F-- From nobody Thu Apr 7 11:38:44 2016 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 036CB12D6AE for ; Thu, 7 Apr 2016 11:38:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P6iv4FTYBQHv for ; Thu, 7 Apr 2016 11:38:23 -0700 (PDT) Received: from mail-qg0-x233.google.com (mail-qg0-x233.google.com [IPv6:2607:f8b0:400d:c04::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB75F12D5E7 for ; Thu, 7 Apr 2016 11:38:22 -0700 (PDT) Received: by mail-qg0-x233.google.com with SMTP id f105so47277797qge.2 for ; Thu, 07 Apr 2016 11:38:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:from:in-reply-to:date:cc:message-id:references :to; bh=s+HjeYSHH+JDP8rU9r+LOVlyRm67KhNpG4QgJDE9aWg=; b=RlHIWTryF7SsiC+Ld6jZPG+Q8ONzQB4rPeAPFv69AF+HbodmRd4G+JUMLZ2SDS3dSn tUWzyE0CRwiGB1MtMgDe49frPR4BO/6pWHi/e9Rw76pksIa2ksSrQUmFo9TSmRHe5oiW WT0MjfGNYSXhhD+4Q8mp0N8CZHWMUeK7jvU23opT3auNVStzrUCihNCfKFEoNgY8/nLw 8UNHaGSx9JPD/QZIZ1MJXN5cSTGDfoWAf6yRcWHl9jiArstzQqs941/v4kY4tJZdADEj dkDFOXtHNXSlEf35PLn4kruzUkUQSs5+5vCJ+GhCcthTb34zbt0yK804WffG2kLMRpES /M7A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:mime-version:from:in-reply-to:date:cc :message-id:references:to; bh=s+HjeYSHH+JDP8rU9r+LOVlyRm67KhNpG4QgJDE9aWg=; b=gMG41G+Eo7MPwZ7MiqtsgvMtzrsS3vjbWCWIbQqd1FsrFVCzQEJPY+QRgxgvIeRNqL 6s6lGOsPCVy3R09c2H+J/3/jImqM4+fN5Z6fkAb+cs1mc95sRIAP+CtPCvZydleei+i/ Me3A+3aUHMOuDtHnoh7aCZM+pAeWPDRg+3ITwdXGp3QdWN1w28LM7CDivdONov0rIgad XR7WSaGsqiJUc19cAWwX0WdrOzUURmwH4EXxAoLabs8KzFgEKk7S9Q89BtygktUavCN9 pBXKxedjB5NAHFv8gje1sEOmsylpw36TlRROi1rhsZyqu97p6seX61Bz4wJG0MgZxKR0 ZpZA== X-Gm-Message-State: AD7BkJIaCZJQfNDGs1YjmPlZfdtXP2yrkgKWmOr8JX6aSUuFqthSX3ue9aWp3LP6DqPbaQ== X-Received: by 10.140.146.142 with SMTP id 136mr6296075qhs.30.1460054301823; Thu, 07 Apr 2016 11:38:21 -0700 (PDT) Received: from ?IPv6:2001:67c:370:160:1c0e:f6a8:d453:299c? ([2001:67c:370:160:1c0e:f6a8:d453:299c]) by smtp.gmail.com with ESMTPSA id l188sm3908310qhc.10.2016.04.07.11.38.19 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 07 Apr 2016 11:38:20 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) Content-Type: multipart/signed; boundary="Apple-Mail=_84C6C3D7-1164-4A90-B1BE-5D3A9939F2B7"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.6b2 From: =?utf-8?B?0JLQsNGB0LjQu9C40Lkg0JTQvtC70LzQsNGC0L7Qsg==?= In-Reply-To: <57066319.5050606@huelsing.net> Date: Thu, 7 Apr 2016 15:38:18 -0300 Message-Id: References: <57066319.5050606@huelsing.net> To: "A. Huelsing" X-Mailer: Apple Mail (2.3112) Archived-At: Cc: "cfrg@irtf.org" Subject: Re: [Cfrg] Topics for hash-based signatures (draft-huelsing-cfrg-hash-sig-xmss) for Friday X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2016 18:38:30 -0000 --Apple-Mail=_84C6C3D7-1164-4A90-B1BE-5D3A9939F2B7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 As it was already noted in this list, it is reasonable to start with the = list of existing hashes and then define the criteria for the choosing = from this list. Current list of active hashes is SHA2, SHA3, BLAKE2, STREEBOG. I propose to consider them and criteria for choosing. dol@ > 7 =D0=B0=D0=BF=D1=80. 2016 =D0=B3., =D0=B2 10:39, A. Huelsing = =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB(=D0=B0): >=20 > Hi, > in preparation for Friday we want to point you at the topics we'd like = to discuss. >=20 > 1. Instantiation aka choice of hash function > ------------------------------------------------------- > This was already briefly discussed on the list and we got some further = direct feedback on this. > We think the important parameter set is for 256 bit classical / 128 = bit quantum security. > Currently this is implemented using SHA2-256 for everything besides = the PRG which uses ChaCha20. > Besides, the draft proposes a 512 bit classical / 256 bit quantum = secure implementation using SHA2-512. >=20 > The main comments we got were > 1. Why no SHA3 > 2. Why no plain SHA2 implementation (code size) >=20 > As we do not want to blow up the number of possibilities, our proposal = would be >=20 > 1.) Plain SHA2-256 implementation as mandatory > 2.) SHA2-512 optional > 3.) SHA3-(256/512) optional >=20 >=20 > 2. Addresses > ------------------ > We simplified the address format in the last version such that fields = do not cross byte boundaries. > However, this leaves not enough space for large tree indices. = Currently, the address format only > supports tree indices up to 40 bit. Preventing parameters with e.g. 12 = layers of trees of height 5 > as used in SPHINCS. >=20 > We suggest to increase the address size to 32 byte. This is another = motivation to remove the SHA2/ChaCha implementation > as this was not possible with ChaCha20 because nonce + counter just = give us 16 byte. >=20 >=20 > 3. Randomness for message hash > --------------------------------------------- > According to the current draft R =3D PRF(SK_PRF, M), > i.e. the randomness is obtained, applying a PRF to the message, > keyed with a dedicated secret key. The reason is that this is a common > way to derandomize this step. >=20 > However, as XMSS is stateful anyway, we could just do > R =3D PRF(SK_PRF, idx) > using the idx of the used one-time key pair. For long messages this = prevents > processing the message twice. >=20 > -------------------------------------------- >=20 > Any feedback also before the meeting tomorrow is welcome. >=20 > Andreas >=20 > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > https://www.irtf.org/mailman/listinfo/cfrg --Apple-Mail=_84C6C3D7-1164-4A90-B1BE-5D3A9939F2B7 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJXBqkaAAoJEM95xWjAML1trkEQAKOWHvvzoYhN83D7sLpS/A+h KvVu8U0ZHBtb2q3YvkiDWvg+/atV08RQLe8wCDS5kjhpKlvTFouegxGHehG6Lucn xVuQg7OMCPNzFaXdEgxA0nRpMgwkBPNk0bJULRALFdF6iKzrO3P4qiZ3y6hneYw6 Y08ErKgPp02UWNvsfJITBUeV1+SHVSA1Wn1qv7QJmd+Hde/70SEKNgfKp8OLrYo/ quHxKOXvrwGMQY2iaUZUFNgbEarycXW+5VZR+ejuVlN6cFoiMVR+NebPtEBi+jwX keMSjubuaNt5wd3nFFFJfWqRjpQyNYv7IAbZEwoJVLL/2OOlRwsEFG/TmVEH5Rgk QcXx3o3OCRil68ztaEOAIZ5WsciT68v60WqLEK5IZUYg+M3augHRK1nxt698WSY6 Ki4NpLQ/Dq68clkTnt5bDLa7BkJVjHB9DlZS7t4GJLmD3EeILglzA6ucuxGojFnV bu7+T/S+4sw8rgqF5U5kJbclGXW/1jSSJ53HzdgR+//kz8s+0eG3k/ApIp9UFLVN 0Xr7cLgLnZ4uM+DhzFxewNxGAm7g2p/jUxHcwFvcc4RuckGBUDhn4zBjN+ahB82O fGaM9ao25AmbioOmylDdqAofXkEzc+L+HbNMiHbnPxr8acdHyzo2Kd6648dQ9JcW iA9GF+2v3fednXXERTLx =/Cu0 -----END PGP SIGNATURE----- --Apple-Mail=_84C6C3D7-1164-4A90-B1BE-5D3A9939F2B7-- From nobody Thu Apr 7 16:16:31 2016 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C5BF12D1ED for ; Thu, 7 Apr 2016 16:16:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=amacapital-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XF-Q2uqHHk0Y for ; Thu, 7 Apr 2016 16:16:27 -0700 (PDT) Received: from mail-oi0-x229.google.com (mail-oi0-x229.google.com [IPv6:2607:f8b0:4003:c06::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9168B12D12E for ; Thu, 7 Apr 2016 16:16:27 -0700 (PDT) Received: by mail-oi0-x229.google.com with SMTP id p188so117483511oih.2 for ; Thu, 07 Apr 2016 16:16:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amacapital-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=yd/bJP7//4XcHT/DvgMl361xwzkDpHhG+xXpSOmQQ/E=; b=vkeSraYJisotJ1kUwLhL9x9Z4InqP/CDAc6krSgrJxMR+A0Y3wGWjYb42b5dRObYk9 J2BDbcJxN/L4DZfUSOq5sni61E/k/fncPEu1ROL+SK+BgpuPdjBrYYyMCNrU/OMwNclt D92MkCz+zNJwv7NpmH8ew0lhdVxZTcAUtiml2YDyVckgJqW+PsNoS+hTWoLe6xk6RVbH 6S6X0dvy7zNRXefJiFwhHVW5qvWyjXBy+RfvkGP/ojCTPPec1QKQ6enrgrNUqpIPp4sO P7Tk1i0SEyv0pfDZcYdC2UH83YQAAs8vIm71XQTi6GDI0EuMd9qBn0+7i/8UhcV9w+Hy brDQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=yd/bJP7//4XcHT/DvgMl361xwzkDpHhG+xXpSOmQQ/E=; b=heX8vI+/NsJU8/YTd1VYF/dyoOhKy9mGmMpSPfK1SmMbVmIN+q2MtlgmSrENhH91ub UExNuxjf6oXPpCSkVYixolRhfh6g7LHlToVMZtQLDWZu3Yw3VS1ZazMOwAaq4FKL0AqG u1Id1YmnwIRtUdLGWmVgkY7veBKxv1I272nUi2SZ6w40b3f5mn1MC5lZbY2qi/qF1/mw WkDl7C3H/mNekTfNn5+81WqTlTYuuL2BxPYVzGlO4oXqC57zqUnWjcKSTQJYIY/4Tc03 SHCGhCmkFx/wlUFLmT3TJ0EOenp/4XfSxHtNChWGFrI92br2/cMd83vxbU8t+1QFTfUF ds6Q== X-Gm-Message-State: AD7BkJLhDZa5jGzw4kDbZmMiLpcXZDDGF8WsuwFNOXqa/BlU77Fpu8Nce2AQUP0v3aVSc1dcGpkcAAPKGSwwrd2t X-Received: by 10.202.60.5 with SMTP id j5mr2796563oia.43.1460070986967; Thu, 07 Apr 2016 16:16:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.202.202.209 with HTTP; Thu, 7 Apr 2016 16:16:07 -0700 (PDT) In-Reply-To: References: From: Andy Lutomirski Date: Thu, 7 Apr 2016 16:16:07 -0700 Message-ID: To: "Gueron, Shay" Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Adam Langley , Yehuda Lindell , "cfrg@irtf.org" , Adam Langley Subject: Re: [Cfrg] Adopting "AES-GCM-SIV: Nonce Misuse-Resistant Authenticated Encryption" as a CFRG document ---- Some clarifications X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2016 23:16:29 -0000 On Tue, Apr 5, 2016 at 6:14 AM, Gueron, Shay wrote: > The (ACM CCS) paper described a GCM-SIV implementation with 128-bit keys. > The CFRG submission is different in two respects: > 1. A 256-bit version that is added. > 2. There is key derivation added (based on the nonce) to refresh the > encryption key for each record. > > The purpose of #2 is to allow AES-GCM-SIV to use a single key multiple > times. In the original paper version, an IV is derived from the universal > hash function (and the nonce) over the message, and occupies 95 bits of the > counter block during the encryption. Collisions are imminent after 2^48 > uses, and to maintain safety margins, we would need to restrict the usage of > one key to 2^32 messages. This could seem like a real constraint for a real > AE scheme. With a differently derived key (derived from the nonce), the > lifetime of one key can be extended. > > The cost of extending the lifetime of the key is that of computing a key > schedule, but this overhead is small on the target platforms that have AES > hardware support. > > To clarify a possible confusion about the 256-bit variant: no 256-bit key is > ever derived from a 128-bit key. A 256-bit encryption key is derived from > the 256-bit master key and a (128-bit) nonce but two encryptions. The > authentication key has 128 bits, and so does the authentication tag. The only relevant text I can find in the draft is: If the AES key is 16 bytes long then define the _record-encryption key_ as the encryption of the nonce using the AES key. If AES-256 is being used then this is insufficient as 256 bits of key material are needed. Therefore the record-encryption key in this case is the concatenation of the result of encrypting, using the AES key, the nonce with the least-significant bit of the first byte set to zero and then to one. This very much sounds to be like (a) a 256-bit key is derived from a 128-bit key and (b) the draft doesn't actually specify what the record key is in any other case. I interpreted the vague text to mean that the record key is the AES key in all other cases. Can you clarify the draft? --Andy From nobody Thu Apr 7 16:55:23 2016 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4924612D15E for ; Thu, 7 Apr 2016 16:55:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.4 X-Spam-Level: X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5OvOMvQ9D4yj for ; Thu, 7 Apr 2016 16:55:19 -0700 (PDT) Received: from mail-io0-x236.google.com (mail-io0-x236.google.com [IPv6:2607:f8b0:4001:c06::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D6BE12D0C0 for ; Thu, 7 Apr 2016 16:55:19 -0700 (PDT) Received: by mail-io0-x236.google.com with SMTP id g185so113216904ioa.2 for ; Thu, 07 Apr 2016 16:55:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc; bh=ulP6dhV0i7S8dH/97VZitNaBjFicaNe2z9kfYlpNBn4=; b=x3QjHdg2bg5QT4RbxsiYaxe1fb+qaivUzW08na1AQGQxMVeWTkI08elSuWqVxu//by pMe7xy2ghIU896d9E+wK7mRNAMUV2Or2ZzzdENmprdueudTs9f2ZP5k2yji2mQMgNkIe PxJll+uMcUgC/0edam7JVedrJYqWbLMoPftXantD5qjCgcOqA1Xozqka5P7ZAodv5Vyu PYAVeJ8Gi0VyLHBOu/CB3MrlwJeXfvNqvXYMgJQjueaOLXFTbu2ylRrRMXTxtRMRbVLd OMWAJm3TFNloETM9yi3biWuY6xIVJWdW0Fx80JnRyzqoUeUmcnjf/omVFkPGqf5Xy8Dj Z5jg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=ulP6dhV0i7S8dH/97VZitNaBjFicaNe2z9kfYlpNBn4=; b=abB98FO67QR830QGZ2ymmJubiZoQdXs+GF8vYeZLiSynjyQF06PyKDAuPAVSQUkqZD Eb+HcHSl0iinAe/XXMUY843D4s5K8F3Tgm1IBatjMFQTV0mLPS+sj5XkAnO6n1oGnJzZ TA4ujSmLs3u1mL5lXRgClfC/kCy2hX923OiLrCRhKjCfENdwkBlsgig7U8Pba7WK/NXw Gzyn7tqa6XImgxXnjqE8YI6XhK/iL0AmHAJz4ZRvFghLpgSUyk+19xFw2OTSvHt2flcR jczZ8UrXuI6j33OSmsgj+5MdPzWyC6bPGzkYaxlQCPt84UCh8ow+wT40/C+LcQgcvWAD 5big== X-Gm-Message-State: AD7BkJJzBYpYR7MNbV4INE1E63YNWFVI9eGDEmg21Hk8eJlqnH1SN7sEqTRIUG8gWdofyA++tiwJuBLT5D53pA== MIME-Version: 1.0 X-Received: by 10.107.150.208 with SMTP id y199mr6086872iod.23.1460073317312; Thu, 07 Apr 2016 16:55:17 -0700 (PDT) Sender: alangley@gmail.com Received: by 10.79.117.207 with HTTP; Thu, 7 Apr 2016 16:55:17 -0700 (PDT) In-Reply-To: References: Date: Fri, 8 Apr 2016 08:55:17 +0900 X-Google-Sender-Auth: qeEfktfrUtb-RVylTSiIpKiDsfE Message-ID: From: Adam Langley To: Andy Lutomirski Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Yehuda Lindell , "cfrg@irtf.org" , Adam Langley Subject: Re: [Cfrg] Adopting "AES-GCM-SIV: Nonce Misuse-Resistant Authenticated Encryption" as a CFRG document ---- Some clarifications X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2016 23:55:21 -0000 On Fri, Apr 8, 2016 at 8:16 AM, Andy Lutomirski wrote: > Can you clarify the draft? Will do as soon as I'm able (which should be next week). Cheers AGL -- Adam Langley agl@imperialviolet.org https://www.imperialviolet.org From nobody Thu Apr 7 21:00:17 2016 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AD6C12D795 for ; Thu, 7 Apr 2016 21:00:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f7_j9jpCLIQM for ; Thu, 7 Apr 2016 21:00:14 -0700 (PDT) Received: from mail-wm0-x22a.google.com (mail-wm0-x22a.google.com [IPv6:2a00:1450:400c:c09::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F044212D783 for ; Thu, 7 Apr 2016 21:00:13 -0700 (PDT) Received: by mail-wm0-x22a.google.com with SMTP id 191so5422028wmq.0 for ; Thu, 07 Apr 2016 21:00:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:cc:date:message-id:in-reply-to:reply-to:user-agent :mime-version:content-transfer-encoding; bh=aTyZTUNkySjfAhfPzhIoFHXSLOafqJFxE5MQmfqabdk=; b=lkBluaEYo2fa87g68iJE9o1TRv9kiblgbbhNtZxDfmW4nTbxmk8G8M1aQ65qSuDHay RKusPWKyLgpJh2JeSmg1IwZgweDWTdqz+XSP+ymaWDsHYywRk08SUZHXU+NCMF8xtwjq h8edQDZNEp0H4vwb9pWqv50eB8TqBWvoMwZa3m5clLVtSRyq/FPOXKitkm9FnNgw9vsy LdW2ZM8oihbv9yfTccVh042nPsCbnVtpP4Ahc8DWz+z73NPRKV6EiyZnXVHZ0adnbfpB I2dLp5ptJ7ZQ0Rr2i1iT2yzCDyFYfbc1jNad5HER3D8axZm3wU10O686a3qrD6NNZmcm Sw7Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:subject:cc:date:message-id:in-reply-to :reply-to:user-agent:mime-version:content-transfer-encoding; bh=aTyZTUNkySjfAhfPzhIoFHXSLOafqJFxE5MQmfqabdk=; b=dAJH0tHbP0wohEBr8BRFpcQboLfndOm6KdSnZ25WaK4bc1qQWXKcdJefCA33fRlFT0 W95fBc8OmT8zdxa/NhBIr86Zp6U2iyaWSeTiezpdG79/G8gb+pzyKwafyQXaSqPgWC3P OZX9b3gMYBqYu4ESNKXjiXmU+WW+y9jhKBCTjqRbsQzIegO5Q5k6W2wFuMBCvBHG3tcC iTfoptj4mKEwe2JqaNqNkU+LfnJX+lzQVTI3SzSbAiB+//Z2ftcnWccye4nGOpNpVGj2 6uRhYv+ZaeaiIHnMbFM7H530mTmuTlaivp+YNrlEfGm+2P8Clj/DpmaGo0ecm3/dtlPr wu5g== X-Gm-Message-State: AD7BkJJ5uu7VXyox3cDpF3HYBvAE0Ok7JIxVcV+2xsMI5FmDv7er4M1eRTRDN/02y5jrdA== X-Received: by 10.28.222.84 with SMTP id v81mr1158361wmg.14.1460088012279; Thu, 07 Apr 2016 21:00:12 -0700 (PDT) Received: from [192.168.127.191] (bzq-199-168-31-213.red.bezeqint.net. [31.168.199.213]) by smtp.gmail.com with ESMTPSA id 198sm948483wml.22.2016.04.07.21.00.10 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 07 Apr 2016 21:00:11 -0700 (PDT) From: "Gueron, Shay" To: "Andy Lutomirski" Date: Fri, 08 Apr 2016 04:00:00 +0000 Message-Id: In-Reply-To: User-Agent: eM_Client/6.0.24316.0 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Adam Langley , Yehuda Lindell , "cfrg@irtf.org" , Adam Langley Subject: Re: [Cfrg] Adopting "AES-GCM-SIV: Nonce Misuse-Resistant Authenticated Encryption" as a CFRG document ---- Some clarifications X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: "Gueron, Shay" List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2016 04:00:16 -0000 Regarding: **** The only relevant text I can find in the draft is: If the AES key is 16 bytes long then define the _record-encryption key_ as the encryption of the nonce using the AES key. If AES-256 is being used then this is insufficient as 256 bits of key material are needed. Therefore the record-encryption key in this case is the concatenation of the result of encrypting, using the AES key, the nonce with the least-significant bit of the first byte set to zero and then to one. This very much sounds to be like (a) a 256-bit key is derived from a 128-bit key and (b) the draft doesn't actually specify what the record key is in any other case. I interpreted the vague text to mean that the record key is the AES key in all other cases. Can you clarify the draft? --Andy **** Yes, of course. Here is the paragraph with explanatory notes in *** ...=20 *** If the AES key is 16 bytes long then define the _record-encryption key_ as the encryption of the nonce using the AES key. *** so far, the=20 case of 128-bit key*** If AES-256 is being used *** now the case of 256-bit key*** then this is insufficient as 256 bits of key material are needed ***=20 because one invocation produces only 128 bits, and we want to derive a=20 256-bit key *** Therefore the record-encryption key in this case is the *** here is the=20 explanation: *** concatenation of the result of encrypting, using the AES key *** recall=20 that it is the 256-bit case***, the nonce with the least-significant bit= =20 of the first byte set to zero and then to one. *** that is AES New key (256 bits) =3D AES256 (NONCE[127:1] || 0) ||=20 AES256 (NONCE[127:1] || 1) (256 bits altogether). Thus, "This very much sounds to be like (a) a 256-bit key is derived=20 from a 128-bit key and (b) the draft doesn't actually specify what the=20 record" is not the case. Shay ------ Original Message ------ From: "Andy Lutomirski" To: "Gueron, Shay" Cc: "cfrg@irtf.org" ; "Adam Langley"=20 ; "Yehuda Lindell" ;=20 "Adam Langley" Sent: 4/8/2016 2:16:07 AM Subject: Re: [Cfrg] Adopting "AES-GCM-SIV: Nonce Misuse-Resistant=20 Authenticated Encryption" as a CFRG document ---- Some clarifications >On Tue, Apr 5, 2016 at 6:14 AM, Gueron, Shay =20 >wrote: >> The (ACM CCS) paper described a GCM-SIV implementation with 128-bit=20 >>keys. >> The CFRG submission is different in two respects: >> 1. A 256-bit version that is added. >> 2. There is key derivation added (based on the nonce) to refresh the >> encryption key for each record. >> >> The purpose of #2 is to allow AES-GCM-SIV to use a single key=20 >>multiple >> times. In the original paper version, an IV is derived from the=20 >>universal >> hash function (and the nonce) over the message, and occupies 95 bits= =20 >>of the >> counter block during the encryption. Collisions are imminent after=20 >>2^48 >> uses, and to maintain safety margins, we would need to restrict the=20 >>usage of >> one key to 2^32 messages. This could seem like a real constraint for= =20 >>a real >> AE scheme. With a differently derived key (derived from the nonce),=20 >>the >> lifetime of one key can be extended. >> >> The cost of extending the lifetime of the key is that of computing a= =20 >>key >> schedule, but this overhead is small on the target platforms that=20 >>have AES >> hardware support. >> >> To clarify a possible confusion about the 256-bit variant: no 256-bit= =20 >>key is >> ever derived from a 128-bit key. A 256-bit encryption key is derived= =20 >>from >> the 256-bit master key and a (128-bit) nonce but two encryptions. The >> authentication key has 128 bits, and so does the authentication tag. > >The only relevant text I can find in the draft is: > > If the AES key is 16 bytes long then define the _record-encryption > key_ as the encryption of the nonce using the AES key. If AES-256=20 >is > being used then this is insufficient as 256 bits of key material are > needed. Therefore the record-encryption key in this case is the > concatenation of the result of encrypting, using the AES key, the > nonce with the least-significant bit of the first byte set to zero > and then to one. > >This very much sounds to be like (a) a 256-bit key is derived from a >128-bit key and (b) the draft doesn't actually specify what the record >key is in any other case. I interpreted the vague text to mean that >the record key is the AES key in all other cases. > >Can you clarify the draft? > >--Andy From nobody Thu Apr 7 21:11:52 2016 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8B3912D576 for ; Thu, 7 Apr 2016 21:11:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=amacapital-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ymjrGX9sXq7Z for ; Thu, 7 Apr 2016 21:11:49 -0700 (PDT) Received: from mail-oi0-x229.google.com (mail-oi0-x229.google.com [IPv6:2607:f8b0:4003:c06::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F364C12D1D2 for ; Thu, 7 Apr 2016 21:11:48 -0700 (PDT) Received: by mail-oi0-x229.google.com with SMTP id p188so123501867oih.2 for ; Thu, 07 Apr 2016 21:11:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amacapital-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=USJTMCtEoT9kK6zQNY0kUnwCfTW0v5WgUmgsgS2Aof8=; b=znYmdWVILbq/3q+s5fnHb/t55J0lDGfx1DICAZkKj+CmcCg76m5LPWR68VpnfPGjcP EIgAX6UfDrbGcXlRkZVTb9V2mtoPl2wlVAFXkN6iM6b+vrahj97Rw6hKYlvoGgICc14P F/qtXdI3bgT2QnYvoR4+XfMB63cvo9SaciqptBY9We5WvB58FkzYUvUzjEB4ZpyodtMy V8NBvmsK+oZ5mh5qxFY5eCGTEH5OEF0J+PS7C1IZNo0xRx3kAMapAp6irKen1671IarJ sGbhnGoCVOewvsI15VdQlWMsuBMKIQnCcGp8YWa0BrQakDTCnghVZHGPaooWhnHLz0jU X2Jg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=USJTMCtEoT9kK6zQNY0kUnwCfTW0v5WgUmgsgS2Aof8=; b=K7OdIBg2UlxKuUcFK2d65WxTZVAVaU5twN7pTtoXSyJ2r1IcVdC0hJi+0Rz47QNYrU um+QVEBjjNShiM7/XfH+exv0Qo1+mok/04cOUFOlU5DC+m3IkDCEUShL2HJKJhy7kOPA ukea0IxDDNDPHqKAZyja4kD5qCPMDkswT0V/ltZ1tZFYh8vPryMUgSPL5DADFQvabzCd hvSeTa1/SqAjeTJZ3BH2xO/cRfaXasM1HaP3Oam4RqiMJAzU9/h+Kxe4eaAas9MDvQf1 fNtE/18tVszUiTHBEUoNaBCPaq6xvWEraifT16PiIkPf1aHwffuvj4Ah0S5+fdTg7xNs 2R+g== X-Gm-Message-State: AD7BkJLQsAQglZa35XL1DlWnY9b9Nj28ZNGHXKg1clBvkgxoqYBCATu749WQZwv4sXytDFMws0SkVUelA7b3Z8qy X-Received: by 10.202.88.130 with SMTP id m124mr3177124oib.52.1460088708387; Thu, 07 Apr 2016 21:11:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.202.202.209 with HTTP; Thu, 7 Apr 2016 21:11:28 -0700 (PDT) In-Reply-To: References: From: Andy Lutomirski Date: Thu, 7 Apr 2016 21:11:28 -0700 Message-ID: To: "Gueron, Shay" Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Adam Langley , Yehuda Lindell , "cfrg@irtf.org" , Adam Langley Subject: Re: [Cfrg] Adopting "AES-GCM-SIV: Nonce Misuse-Resistant Authenticated Encryption" as a CFRG document ---- Some clarifications X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2016 04:11:51 -0000 On Thu, Apr 7, 2016 at 9:00 PM, Gueron, Shay wrote: > Regarding: > > **** > The only relevant text I can find in the draft is: > > If the AES key is 16 bytes long then define the _record-encryption > key_ as the encryption of the nonce using the AES key. If AES-256 is > being used then this is insufficient as 256 bits of key material are > needed. Therefore the record-encryption key in this case is the > concatenation of the result of encrypting, using the AES key, the > nonce with the least-significant bit of the first byte set to zero > and then to one. > > This very much sounds to be like (a) a 256-bit key is derived from a > 128-bit key and (b) the draft doesn't actually specify what the record > key is in any other case. I interpreted the vague text to mean that > the record key is the AES key in all other cases. > > Can you clarify the draft? > > --Andy > **** > > Yes, of course. Here is the paragraph with explanatory notes in *** ... *** > > If the AES key is 16 bytes long then define the _record-encryption > key_ as the encryption of the nonce using the AES key. *** so far, the case > of 128-bit key*** > > If AES-256 is being used *** now the case of 256-bit key*** > then this is insufficient as 256 bits of key material are needed *** because > one invocation produces only 128 bits, and we want to derive a 256-bit key > *** > Therefore the record-encryption key in this case is the *** here is the > explanation: *** > concatenation of the result of encrypting, using the AES key *** recall that > it is the 256-bit case***, the nonce with the least-significant bit of the > first byte set to zero and then to one. > *** that is AES New key (256 bits) = AES256 (NONCE[127:1] || 0) || AES256 > (NONCE[127:1] || 1) (256 bits altogether). > > Thus, "This very much sounds to be like (a) a 256-bit key is derived from a > 128-bit key and (b) the draft doesn't actually specify what the record" is > not the case. > Shay > Hmm, I guess I didn't read it quite right. What happens if AES-128 is used and the "AES key" is 32 bytes long? Or is this not allowed? It might help to clarify exactly what variants of this scheme exist in terms of AES variant and key size. --Andy From nobody Fri Apr 8 01:26:00 2016 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78D6712D569 for ; Fri, 8 Apr 2016 01:25:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z7Wcg4SXVPIm for ; Fri, 8 Apr 2016 01:25:53 -0700 (PDT) Received: from mail-oi0-x232.google.com (mail-oi0-x232.google.com [IPv6:2607:f8b0:4003:c06::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B73912D555 for ; Fri, 8 Apr 2016 01:25:53 -0700 (PDT) Received: by mail-oi0-x232.google.com with SMTP id y204so128724756oie.3 for ; Fri, 08 Apr 2016 01:25:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=mvwwJJZCnFFfX4QKww1OgjZHaTSK8IqJyEAlj7hRSXw=; b=qGFt752NvE9i/NBQpKVmg2ZBMaWMgzh0FFqh5KsnK/WflmsO1YfnU17eUbe6TkL1Of RayYqVV6hPeU12Szp/oqobzoQ3m7lsIiSmIKRho82rV/EyIwF8jQpAqH6+WH7rl+FeGy VyapU2A6/zmHG1xW14DBTB+TrzvwvYbmkLkMs7mE65sovGDnYEXNZwBvUi5GfhOcSjq9 PiM+rlid5CZ7fERRfpR7JgB/d4vDpqRC3myTkQDUBsPbEN3Z4zO7XkW4iTnaGPRAIhC1 A78ilf6IeCPtS/JJrtlhCxDq68qXxuHrz5g5Z2SnME1ZcSuKHZf3f+HA0WUafCRaEUjC bKKw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=mvwwJJZCnFFfX4QKww1OgjZHaTSK8IqJyEAlj7hRSXw=; b=PS4H/7VseN7YpaF+jbCgyMZm/55nnvZFs+XmIIW9I+WlNF72gScnX3OZ+DtqsIFxXo goJl8wYRu096SsQsQquAl4wA1FHqXGOa7Zgzl2nA6Nia6ULCLELEXB6Qd9GbVWrOCF4K Mu763e8mgkFl6o6CnUG9iNyn9iRzSnLxn50YisKGOqxyD4k/J/Ihs165bCH7Q3ei8QNX 11AuCA4r7xvYij9zwc49Ia0i6KstFthI/AQpMkB88PaSWpvDnDWVTrj8caYaVQisylJH XSNfVecHC9ndHaqC0iOdbuud1maWv/XvWMSZCYhsqpZfFualPJRoITGmuj+tStEubtBz oERg== X-Gm-Message-State: AD7BkJLDE/LPhLpspDYRsX8sFh7L8fwWVcthA6MRuhHgb3le63shDGpRAzJLuNOCYrRbw+/wdOUtCvEDHj+faQ== MIME-Version: 1.0 X-Received: by 10.157.2.69 with SMTP id 63mr3814225otb.170.1460103952678; Fri, 08 Apr 2016 01:25:52 -0700 (PDT) Received: by 10.157.14.175 with HTTP; Fri, 8 Apr 2016 01:25:52 -0700 (PDT) In-Reply-To: References: Date: Fri, 8 Apr 2016 11:25:52 +0300 Message-ID: From: Shay Gueron To: Andy Lutomirski Content-Type: multipart/alternative; boundary=94eb2c114d246f4ba5052ff4f1ba Archived-At: Cc: Adam Langley , Yehuda Lindell , "cfrg@irtf.org" , Adam Langley Subject: Re: [Cfrg] Adopting "AES-GCM-SIV: Nonce Misuse-Resistant Authenticated Encryption" as a CFRG document ---- Some clarifications X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2016 08:25:59 -0000 --94eb2c114d246f4ba5052ff4f1ba Content-Type: text/plain; charset=UTF-8 OK, let me explain: There are (only) two options for the key: 128 bit or 256 bits. For the "128-bit" case, the document states "If the AES key is 16 bytes long then define the _record-encryption-key_ as the encryption of the nonce using the AES key". That is AES128 (NONCE) (using the 128-bit key). This is the straightforward case. The "256-bit" case, is covered in my previous explanation, basically: AES256 (NONCE[127:1] || 0) || AES256 (NONCE[127:1] || 1) (using the 256-bit key, and producing 256 bits altogether). I hope this helps. We will definitely edit the text and post a version that includes these explanations (soon). Thank you, Shay 2016-04-08 7:11 GMT+03:00 Andy Lutomirski : > On Thu, Apr 7, 2016 at 9:00 PM, Gueron, Shay > wrote: > > Regarding: > > > > **** > > The only relevant text I can find in the draft is: > > > > If the AES key is 16 bytes long then define the _record-encryption > > key_ as the encryption of the nonce using the AES key. If AES-256 is > > being used then this is insufficient as 256 bits of key material are > > needed. Therefore the record-encryption key in this case is the > > concatenation of the result of encrypting, using the AES key, the > > nonce with the least-significant bit of the first byte set to zero > > and then to one. > > > > This very much sounds to be like (a) a 256-bit key is derived from a > > 128-bit key and (b) the draft doesn't actually specify what the record > > key is in any other case. I interpreted the vague text to mean that > > the record key is the AES key in all other cases. > > > > Can you clarify the draft? > > > > --Andy > > **** > > > > Yes, of course. Here is the paragraph with explanatory notes in *** ... > *** > > > > If the AES key is 16 bytes long then define the _record-encryption > > key_ as the encryption of the nonce using the AES key. *** so far, the > case > > of 128-bit key*** > > > > If AES-256 is being used *** now the case of 256-bit key*** > > then this is insufficient as 256 bits of key material are needed *** > because > > one invocation produces only 128 bits, and we want to derive a 256-bit > key > > *** > > Therefore the record-encryption key in this case is the *** here is the > > explanation: *** > > concatenation of the result of encrypting, using the AES key *** recall > that > > it is the 256-bit case***, the nonce with the least-significant bit of > the > > first byte set to zero and then to one. > > *** that is AES New key (256 bits) = AES256 (NONCE[127:1] || 0) || > AES256 > > (NONCE[127:1] || 1) (256 bits altogether). > > > > Thus, "This very much sounds to be like (a) a 256-bit key is derived > from a > > 128-bit key and (b) the draft doesn't actually specify what the record" > is > > not the case. > > Shay > > > > Hmm, I guess I didn't read it quite right. > > What happens if AES-128 is used and the "AES key" is 32 bytes long? > Or is this not allowed? > > It might help to clarify exactly what variants of this scheme exist in > terms of AES variant and key size. > > --Andy > --94eb2c114d246f4ba5052ff4f1ba Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

OK, let me exp= lain:=C2=A0

There are (onl= y) two options for the key: 128 bit or 256 bits.=C2=A0

For the "128-bit" case, the document= states=C2=A0
"If the AES key is 16 bytes long t= hen define the _record-encryption-key_ as the encryption of the nonce using= the AES key".=C2=A0
That is AES128 (NONCE) =C2= =A0(using the 128-bit key). This is the straightforward case.=C2=A0

The "256-bit" case, is = covered in my previous explanation, basically: =C2=A0

AES256 (NONCE[127:1] || 0)= || AES256 (NONCE[127:1] || 1) =C2=A0(using the 256-bit key, and producing = 256 bits altogether).

I hope this help= s. We will definitely edit the text and post a version that includes these = explanations (soon).

Thank you, Shay=C2=A0



2016-04-08 7:11 G= MT+03:00 Andy Lutomirski <luto@amacapital.net>:
On Thu, Apr 7, 2016 at 9:00 PM, Gueron, Shay <shay.gueron@gmail.co= m> wrote:
>=C2=A0 Regarding:
>
> ****
> The only relevant text I can find in the draft is:
>
> If the AES key is 16 bytes long then define the _record-encryption
> key_ as the encryption of the nonce using the AES key. If AES-256 is > being used then this is insufficient as 256 bits of key material are > needed. Therefore the record-encryption key in this case is the
> concatenation of the result of encrypting, using the AES key, the
> nonce with the least-significant bit of the first byte set to zero
> and then to one.
>
> This very much sounds to be like (a) a 256-bit key is derived from a > 128-bit key and (b) the draft doesn't actually specify what the re= cord
> key is in any other case. I interpreted the vague text to mean that > the record key is the AES key in all other cases.
>
> Can you clarify the draft?
>
> --Andy
> ****
>
> Yes, of course. Here is the paragraph with explanatory notes in *** ..= . ***
>
> If the AES key is 16 bytes long then define the _record-encryption
> key_ as the encryption of the nonce using the AES key. *** so far, the= case
> of 128-bit key***
>
> If AES-256 is being used *** now the case of 256-bit key***
> then this is insufficient as 256 bits of key material are needed *** b= ecause
> one invocation produces only 128 bits, and we want to derive a 256-bit= key
> ***
> Therefore the record-encryption key in this case is the *** here is th= e
> explanation: ***
> concatenation of the result of encrypting, using the AES key *** recal= l that
> it is the 256-bit case***, the nonce with the least-significant bit of= the
> first byte set to zero and then to one.
> *** that is AES=C2=A0 New key (256 bits) =3D=C2=A0 AES256 (NONCE[127:1= ] || 0) || AES256
> (NONCE[127:1] || 1)=C2=A0 (256 bits altogether).
>
> Thus, "This very much sounds to be like (a) a 256-bit key is deri= ved from a
> 128-bit key and (b) the draft doesn't actually specify what the re= cord" is
> not the case.
> Shay
>

Hmm, I guess I didn't read it quite right.

What happens if AES-128 is used and the "AES key" is 32 bytes lon= g?
Or is this not allowed?

It might help to clarify exactly what variants of this scheme exist in
terms of AES variant and key size.

--Andy

--94eb2c114d246f4ba5052ff4f1ba-- From nobody Fri Apr 8 05:40:55 2016 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFD9412D711 for ; Fri, 8 Apr 2016 05:40:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.209 X-Spam-Level: X-Spam-Status: No, score=-4.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LXQ4rgt9uDJM for ; Fri, 8 Apr 2016 05:40:33 -0700 (PDT) Received: from llmx2.ll.mit.edu (LLMX2.LL.MIT.EDU [129.55.12.48]) by ietfa.amsl.com (Postfix) with ESMTP id 3480812D8CF for ; Fri, 8 Apr 2016 05:40:32 -0700 (PDT) Received: from LLE2K10-HUB02.mitll.ad.local (LLE2K10-HUB02.mitll.ad.local) by llmx2.ll.mit.edu (unknown) with ESMTP id u38CdC0V030510; Fri, 8 Apr 2016 08:39:12 -0400 From: "Blumenthal, Uri - 0553 - MITLL" To: Adam Langley , Andy Lutomirski Thread-Topic: [Cfrg] Adopting "AES-GCM-SIV: Nonce Misuse-Resistant Authenticated Encryption" as a CFRG document ---- Some clarifications Thread-Index: AdGRk9PWcBDJFfpWREmYbD5sdatNiw== Date: Fri, 8 Apr 2016 12:40:27 +0000 Message-ID: <20160408124036.18280531.99866.62311@ll.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="===============0436011443==" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-04-08_08:, , signatures=0 X-Proofpoint-Spam-Details: rule=inbound_notspam policy=inbound score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1603180000 definitions=main-1604080186 Archived-At: Cc: Yehuda Lindell , "cfrg@irtf.org" , Adam Langley Subject: Re: [Cfrg] Adopting "AES-GCM-SIV: Nonce Misuse-Resistant Authenticated Encryption" as a CFRG document ---- Some clarifications X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2016 12:40:37 -0000 --===============0436011443== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable BTW, what assembler is the optimized code supposed to work with? I'm on Mac OSX (10.10.5 and 10.11.4) using Xcode 7.2.1 and 7.3 correspondin= gly. Both systems also have gcc-5.3 and clang-3.7. I also t=E2=80=8Eried na= sm, yasm. Nothing works. Would like some guidance.=C2=A0 Sent=C2=A0from=C2=A0my=C2=A0BlackBerry=C2=A010=C2=A0smartphone=C2=A0on=C2= =A0the Verizon=C2=A0Wireless=C2=A04G=C2=A0LTE=C2=A0network. =C2=A0 Original Message =C2=A0 From: Adam Langley Sent: Thursday, April 7, 2016 19:55 To: Andy Lutomirski Cc: Yehuda Lindell; cfrg@irtf.org; Adam Langley Subject: Re: [Cfrg] Adopting "AES-GCM-SIV: Nonce Misuse-Resistant Authentic= ated Encryption" as a CFRG document ---- Some clarifications On Fri, Apr 8, 2016 at 8:16 AM, Andy Lutomirski wrote: > Can you clarify the draft? Will do as soon as I'm able (which should be next week). Cheers AGL --=20 Adam Langley agl@imperialviolet.org https://www.imperialviolet.org _______________________________________________ Cfrg mailing list Cfrg@irtf.org https://www.irtf.org/mailman/listinfo/cfrg --===============0436011443== Content-Type: application/x-pkcs7-signature; name="smime.p7s" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExDTALBglghkgBZQMEAgEwgAYJKoZIhvcNAQcBAACggg7NMIIE 6jCCA9KgAwIBAgIKMz1Y1wAAAABunjANBgkqhkiG9w0BAQsFADBRMQswCQYDVQQGEwJVUzEfMB0G A1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRM TCBDQS0zMB4XDTE2MDExNDE3MzU1MloXDTE5MDExMzE3MzU1MlowYTELMAkGA1UEBhMCVVMxHzAd BgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDzANBgNVBAsTBlBlb3BsZTEgMB4GA1UEAxMX Qmx1bWVudGhhbC5VcmkuNTAwMTA1ODQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCz HVEw2ojNZjWEnTASyJaQIvzziBmrH07FzMEY2xFGNDJpss38CcFRjfRx1EyEp7BrFdAXC2pHjFwa gFr+McYdXZiKEci0Mzna2uibsMDVbhlT6TwtmAL6QzdtjN28dn+7vQUkRUWUm9VVaBVVxUgX3f2l oEZsJNvWb7C8vj2DZF/uEt/EU/9KcUuodMgCR4zYLFVpNh1U6tCYACNDNtj/nmNjubtez1Y56zjZ AVOXZWsjNCPrC2jVwDdg1AIcs5ayDMOC2p1F95kSxWsJwinKfSe8p2/YR/cwUo8ljFoBPj60AGW3 WjaJyKXK+ZgJwjwl9gG/pg2T4mQhIAIZWZQ9AgMBAAGjggGyMIIBrjAdBgNVHQ4EFgQUtKJz3aEd G/MvxjE38EW6PHdcUDQwDgYDVR0PAQH/BAQDAgbAMB8GA1UdIwQYMBaAFNdgZg57SY11TA39z0be yMcSh8q/MDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXRjcmwvTExD QTMwZgYIKwYBBQUHAQEEWjBYMC0GCCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0 dG8vTExDQTMwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLmxsLm1pdC5lZHUvb2NzcDA9BgkrBgEE AYI3FQcEMDAuBiYrBgEEAYI3FQiDg+Udh+ynZoathxWD6vBFhbahHx2Fy94yh/+KcwIBZAIBBjAi BgNVHSUBAf8EGDAWBggrBgEFBQcDBAYKKwYBBAGCNwoDDDAYBgNVHSAEETAPMA0GCyqGSIb3EgIB AwEIMBkGA1UdEQQSMBCBDnVyaUBsbC5taXQuZWR1MCcGCSsGAQQBgjcUAgQaHhgATABMAFUAcwBl AHIAUwBpAGcALQBTAFcwDQYJKoZIhvcNAQELBQADggEBAJTu0/WcX0ebe9UfUMslvy9fC2aCQong cVcEKlEjU8IvCKa6YpZHQKTVXQ3e4KKvw1DgzFvq8/rOv87Woj45q8smgNyivgAMCnrT7a6B/9Kn 85l9BjeoLMPLypvsmz1l7oX45NPr3LF4VEMzxqczdovS14woPKdegEKQYyPSZGhKTCCe/9FhtgEc 3gfVyE1mH6ZNeDEalr7nx7F0qemhh3QN6i6XPrudzv9el5JeovPedZ0JqDT0ctXj6ECYOiEyEfJm 85C5QGmpjLmCM99gAmgpP5Tx6APB/tvcUw/mgt4HOvqavGkvUkoJ8XEEwt9AgXaznS626Kb8RpAh w2zN2yMwggTqMIID0qADAgECAgozPVjXAAAAAG6eMA0GCSqGSIb3DQEBCwUAMFExCzAJBgNVBAYT AlVTMR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxEzARBgNV BAMTCk1JVExMIENBLTMwHhcNMTYwMTE0MTczNTUyWhcNMTkwMTEzMTczNTUyWjBhMQswCQYDVQQG EwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEPMA0GA1UECxMGUGVvcGxlMSAw HgYDVQQDExdCbHVtZW50aGFsLlVyaS41MDAxMDU4NDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBALMdUTDaiM1mNYSdMBLIlpAi/POIGasfTsXMwRjbEUY0MmmyzfwJwVGN9HHUTISnsGsV 0BcLakeMXBqAWv4xxh1dmIoRyLQzOdra6JuwwNVuGVPpPC2YAvpDN22M3bx2f7u9BSRFRZSb1VVo FVXFSBfd/aWgRmwk29ZvsLy+PYNkX+4S38RT/0pxS6h0yAJHjNgsVWk2HVTq0JgAI0M22P+eY2O5 u17PVjnrONkBU5dlayM0I+sLaNXAN2DUAhyzlrIMw4LanUX3mRLFawnCKcp9J7ynb9hH9zBSjyWM WgE+PrQAZbdaNonIpcr5mAnCPCX2Ab+mDZPiZCEgAhlZlD0CAwEAAaOCAbIwggGuMB0GA1UdDgQW BBS0onPdoR0b8y/GMTfwRbo8d1xQNDAOBgNVHQ8BAf8EBAMCBsAwHwYDVR0jBBgwFoAU12BmDntJ jXVMDf3PRt7IxxKHyr8wMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC5sbC5taXQuZWR1L2dl dGNybC9MTENBMzBmBggrBgEFBQcBAQRaMFgwLQYIKwYBBQUHMAKGIWh0dHA6Ly9jcmwubGwubWl0 LmVkdS9nZXR0by9MTENBMzAnBggrBgEFBQcwAYYbaHR0cDovL29jc3AubGwubWl0LmVkdS9vY3Nw MD0GCSsGAQQBgjcVBwQwMC4GJisGAQQBgjcVCIOD5R2H7Kdmhq2HFYPq8EWFtqEfHYXL3jKH/4pz AgFkAgEGMCIGA1UdJQEB/wQYMBYGCCsGAQUFBwMEBgorBgEEAYI3CgMMMBgGA1UdIAQRMA8wDQYL KoZIhvcSAgEDAQgwGQYDVR0RBBIwEIEOdXJpQGxsLm1pdC5lZHUwJwYJKwYBBAGCNxQCBBoeGABM AEwAVQBzAGUAcgBTAGkAZwAtAFMAVzANBgkqhkiG9w0BAQsFAAOCAQEAlO7T9ZxfR5t71R9QyyW/ L18LZoJCieBxVwQqUSNTwi8IprpilkdApNVdDd7goq/DUODMW+rz+s6/ztaiPjmryyaA3KK+AAwK etPtroH/0qfzmX0GN6gsw8vKm+ybPWXuhfjk0+vcsXhUQzPGpzN2i9LXjCg8p16AQpBjI9JkaEpM IJ7/0WG2ARzeB9XITWYfpk14MRqWvufHsXSp6aGHdA3qLpc+u53O/16Xkl6i8951nQmoNPRy1ePo QJg6ITIR8mbzkLlAaamMuYIz32ACaCk/lPHoA8H+29xTD+aC3gc6+pq8aS9SSgnxcQTC30CBdrOd LrbopvxGkCHDbM3bIzCCBO0wggPVoAMCAQICCjM4lI8AAAAAbpYwDQYJKoZIhvcNAQELBQAwUTEL MAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsTA1BL STETMBEGA1UEAxMKTUlUTEwgQ0EtMzAeFw0xNjAxMTQxNzMwMzlaFw0xOTAxMTMxNzMwMzlaMGEx CzAJBgNVBAYTAlVTMR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQ8wDQYDVQQLEwZQ ZW9wbGUxIDAeBgNVBAMTF0JsdW1lbnRoYWwuVXJpLjUwMDEwNTg0MIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEA4xQ2hom9O5hwXTWlTDaY/fuIiWvivQHEzd8volNcoLbxxuHKLXgwX++2 TdbsHbfpaHVtAvF8huN7Lkn6Taf6MCzlBJRWoAJz6hwLwFCMLJeQI853KST/u/FIuLt+GjDbHXT/ kGbvRyNkIPj+njA9uY5I8m0/XUDMV2aTtqEwc55Vo2CCLXWYStQ1maiEdGre59mIwkkLGTV9JSeC cK7Yx2Ba2D552QtH9QdjO1eeCEvOtwhMn7uV6LaGcfGLh8GKSkhavNEhIenDAy3U3tWQI1sbJ28i guuK63krciNj1TfbgVnfjpXhqCAI1aIKTCiotKUkR3ArsA8BnpKUFbmyvQIDAQABo4IBtTCCAbEw HQYDVR0OBBYEFPFPxYiZomy2ZdvinDW1VhNj2YqbMA4GA1UdDwEB/wQEAwIFIDAfBgNVHSMEGDAW gBTXYGYOe0mNdUwN/c9G3sjHEofKvzAzBgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLmxsLm1p dC5lZHUvZ2V0Y3JsL0xMQ0EzMGYGCCsGAQUFBwEBBFowWDAtBggrBgEFBQcwAoYhaHR0cDovL2Ny bC5sbC5taXQuZWR1L2dldHRvL0xMQ0EzMCcGCCsGAQUFBzABhhtodHRwOi8vb2NzcC5sbC5taXQu ZWR1L29jc3AwPQYJKwYBBAGCNxUHBDAwLgYmKwYBBAGCNxUIg4PlHYfsp2aGrYcVg+rwRYW2oR8d hevQcIPr7SACAWQCAQUwJQYDVR0lBB4wHAYEVR0lAAYIKwYBBQUHAwQGCisGAQQBgjcKAwQwGAYD VR0gBBEwDzANBgsqhkiG9xICAQMBCDAZBgNVHREEEjAQgQ51cmlAbGwubWl0LmVkdTAnBgkrBgEE AYI3FAIEGh4YAEwATABVAHMAZQByAEUAbgBjAC0AUwBXMA0GCSqGSIb3DQEBCwUAA4IBAQAW7r7P ZtIEuVPCSblXPqrbVdgVkNIw3qV6WHz/8TfK1UnETx3tkjFGhR+TjEYYXhiZHaIFlTZzK4x8UH6X 3NM/MqLZQ98cFxDVlGOTKEJqRBgdpLBaoDHddtW6s0d1mPOC3KLH6MNDKKZV7PJrzu056M8DPj7R mbNJqadj8wZL1nTW7Nq/+8FyT+v6S3ecz78sETYU4KFXtWjeIryJFPLL5CjIIL+WWjrKJ2lvCUun VGJr75NELwyUSEDUUdM6UKTiqfuFf14TGUYcUCdw41U44fUP6RypuwERYRa90ACeqHAo8syxeYrL GtVbIcexJQSJNHF4XqepizC6hjV92swJMYIB8TCCAe0CAQEwXzBRMQswCQYDVQQGEwJVUzEfMB0G A1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRM TCBDQS0zAgozPVjXAAAAAG6eMAsGCWCGSAFlAwQCAaBpMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTE2MDQwODEyNDAzNVowLwYJKoZIhvcNAQkEMSIEIOEJuV76Fydk h3RtrVe83lUzjsykj1LhJC8eJPOyhoNSMAsGCSqGSIb3DQEBCwSCAQCDvJrL8a9kWnWcxXKrBY2R 9mUwZwyjR3T8SsiJ+BbfG7tkZOENfXEO/j6gUPQYLVAprSVtpGFmGq0RV1u3sezuWFN5NrTAeWR3 6xxAn+KWrd1nuIXerYjxf6pgv/I8hZCtJIcKWpcNg96Tks4jtq24EWpcbrFPGVgE2rTnvDlsnqhv bxBU46Pces7pkxzcDrxuwGCwnxfuKLm7Dm//EpSxOhd3w4kd+tODX4DP5eO3R3qCuo+hbvTQsKRF bZr62cmFZ5cM+uw9QFLNYB/8N7qz8UDe3NcC7gx5l1a1Rv9n4SAR8BSsWHQmTLQHRjxT85G88xN/ +aU7yINTpIv2VPziAAAAAAAA --===============0436011443==-- From nobody Fri Apr 8 05:53:57 2016 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D0E512D705 for ; Fri, 8 Apr 2016 05:53:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.53 X-Spam-Level: X-Spam-Status: No, score=-14.53 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OfzjVs1-Guzk for ; Fri, 8 Apr 2016 05:53:53 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E81012D652 for ; Fri, 8 Apr 2016 05:53:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1516; q=dns/txt; s=iport; t=1460120033; x=1461329633; h=mime-version:subject:from:in-reply-to:date:cc:message-id: references:to; bh=VPXOUF6mR3WAAK4HeUMio3IdZd37HuMAjV+MPlOAAN4=; b=D+VeQX1r2acrYlv8KpzCzuTEemJ3ObTUReR2KDg5VDV61cHxy7SJsSQF hEz3bfDGAUulgq/MJSTSijTwEMrsJLpj/AkxPhCNf0K1FUQTmGD9CbjnF keFlgHrg07L0irW+Ceb4zRRqKciKbmrAzyWJjwOwIN9gqbDAJpY6RQGU4 g=; X-IronPort-AV: E=Sophos;i="5.24,449,1454976000"; d="scan'208,217";a="258901811" Received: from alln-core-7.cisco.com ([173.36.13.140]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 08 Apr 2016 12:53:52 +0000 Received: from [10.24.35.251] ([10.24.35.251]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id u38Crkpk023495 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 8 Apr 2016 12:53:49 GMT Content-Type: multipart/alternative; boundary="Apple-Mail=_D0AC66A6-66E6-4C59-88A8-83843BCE650F" Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: David McGrew In-Reply-To: <112318523.r9ZLk0otbW@illuan> Date: Fri, 8 Apr 2016 08:53:46 -0400 Message-Id: <88B63C6A-7EEB-4E8C-B54D-2CE40DA55E61@cisco.com> References: <833fbd3038f64cd88a28b2ac1cbb6fd1@XCH-ALN-010.cisco.com> <112318523.r9ZLk0otbW@illuan> To: cfrg@irtf.org X-Mailer: Apple Mail (2.3112) Archived-At: Cc: Stefan-Lukas Gazdag , "Scott Fluhrer \(sfluhrer\)" , Johannes Buchmann Subject: Re: [Cfrg] thoughts on state management in n-time signatures X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2016 12:53:55 -0000 --Apple-Mail=_D0AC66A6-66E6-4C59-88A8-83843BCE650F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi CFRG, today, I will be giving a presentation on behalf of some work that I did = with Panos, Scott, Stefan, Denis, and Johannes, on "State Management for = Hash Based Signatures=E2=80=9D. If you are interested in more details = after the presentation, our preprint is online at = https://eprint.iacr.org/2016/357.pdf = best regards, David= --Apple-Mail=_D0AC66A6-66E6-4C59-88A8-83843BCE650F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi CFRG,

today, I will be giving = a presentation on behalf of some work that I did with Panos, Scott, = Stefan, Denis, and Johannes, on "State Management for Hash Based = Signatures=E2=80=9D.   If you are interested in more details after = the presentation, our preprint is online at https://eprint.iacr.org/2016/357.pdf

best = regards,

David
= --Apple-Mail=_D0AC66A6-66E6-4C59-88A8-83843BCE650F-- From nobody Fri Apr 8 06:49:28 2016 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B73F812D12D for ; Fri, 8 Apr 2016 06:49:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.207 X-Spam-Level: X-Spam-Status: No, score=-4.207 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P7YkaHUVR-bc for ; Fri, 8 Apr 2016 06:49:25 -0700 (PDT) Received: from llmx2.ll.mit.edu (LLMX2.LL.MIT.EDU [129.55.12.48]) by ietfa.amsl.com (Postfix) with ESMTP id E42C912D5C1 for ; Fri, 8 Apr 2016 06:49:24 -0700 (PDT) Received: from LLE2K10-HUB01.mitll.ad.local (LLE2K10-HUB01.mitll.ad.local) by llmx2.ll.mit.edu (unknown) with ESMTP id u38Dm7wx029663 for ; Fri, 8 Apr 2016 09:48:07 -0400 From: "Blumenthal, Uri - 0553 - MITLL" To: "cfrg@irtf.org" Thread-Topic: [Cfrg] Adopting "AES-GCM-SIV: Nonce Misuse-Resistant Authenticated Encryption" as a CFRG document ---- Some clarifications Thread-Index: AQHRjz1rcBDJFfpWREmYbD5sdatNi59/a4CAgABPUQCAAAM0AIAARxQAgAAXRAA= Date: Fri, 8 Apr 2016 13:49:22 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.2.160219 x-originating-ip: [172.25.177.51] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha384; boundary="B_3542953748_51060236" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-04-08_09:, , signatures=0 X-Proofpoint-Spam-Details: rule=inbound_notspam policy=inbound score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1603180000 definitions=main-1604080204 Archived-At: Subject: Re: [Cfrg] Adopting "AES-GCM-SIV: Nonce Misuse-Resistant Authenticated Encryption" as a CFRG document ---- Some clarifications X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2016 13:49:27 -0000 --B_3542953748_51060236 Content-type: multipart/alternative; boundary="B_3542953748_51090628" --B_3542953748_51090628 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable > OK, let me explain: > . . . . . .=20 > The "256-bit" case, is covered in my previous explanation, basically: >=20 > AES256 (NONCE[127:1] || 0) || AES256 (NONCE[127:1] || 1) (using the 256-= bit > key, and producing 256 bits altogether). Another way to explain it =E2=80=93 you run AES256 as a PRF to generate 256 pseudo-random bits with it, and take those 256 bits as a record key for AES256. (Sounds solid to me.) --B_3542953748_51090628 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable
O= K, let me explain: 
. . . . . . 
The "256-bit" case, is covered in my previous explanation, basically:=  

AES2= 56 (NONCE[127:1] || 0) || AES256 (NONCE[127:1] || 1)  (using the 256-bi= t key, and producing 256 bits altogether).

Another way to explain it – you run AES256 as = a PRF to generate 256 pseudo-random bits with it, and take those 256 bits as= a record key for AES256.

(Sounds solid to me.)


--B_3542953748_51090628-- --B_3542953748_51060236 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIQ4AYJKoZIhvcNAQcCoIIQ0TCCEM0CAQExDzANBglghkgBZQMEAgIFADALBgkqhkiG9w0B BwGggg6fMIIE6jCCA9KgAwIBAgIKMztKZQAAAABumTANBgkqhkiG9w0BAQsFADBRMQswCQYD VQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJ MRMwEQYDVQQDEwpNSVRMTCBDQS0zMB4XDTE2MDExNDE3MzMzN1oXDTE5MDExMzE3MzMzN1ow YTELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDzANBgNV BAsTBlBlb3BsZTEgMB4GA1UEAxMXQmx1bWVudGhhbC5VcmkuNTAwMTA1ODQwggEiMA0GCSqG SIb3DQEBAQUAA4IBDwAwggEKAoIBAQDqifs8K0OoodbmOo5G/j2+p2ibbOsEoJ9GJjK8K1Iw 6iig59a3EuNB6NR4tAR3INwjjUwMCa4o8ysnk1hN32B3HPrK5Z8++Y/xcX5iP1L6fc51YQ5C /EGvrSbjuPLvt19SNfVdwcuoc842Sgk9N/HemdwmvcqJkwzWDsuxKikI2clT1N5LTAaPMkhr HVuYOHBE0mCXjHjFnYuHsEXyVvUZLxziDgduV9WKbC90Z1NZMXB6ZeQTACUWgMfpFrE12LKb fvOmxepCBfCPbGB3ZyG+FaUdtQoCEAbGTnY7nCedQFn7pV1hppCt4jjLVlOpgYc3dPmyiXsL nhDQZ5ptmks/AgMBAAGjggGyMIIBrjAdBgNVHQ4EFgQUiXqPublGfd0sWKNk/BObT6Oorzgw DgYDVR0PAQH/BAQDAgbAMB8GA1UdIwQYMBaAFNdgZg57SY11TA39z0beyMcSh8q/MDMGA1Ud HwQsMCowKKAmoCSGImh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXRjcmwvTExDQTMwZgYIKwYB BQUHAQEEWjBYMC0GCCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8vTExD QTMwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLmxsLm1pdC5lZHUvb2NzcDA9BgkrBgEEAYI3 FQcEMDAuBiYrBgEEAYI3FQiDg+Udh+ynZoathxWD6vBFhbahHx2Fy94yh/+KcwIBZAIBBjAi BgNVHSUBAf8EGDAWBggrBgEFBQcDBAYKKwYBBAGCNwoDDDAYBgNVHSAEETAPMA0GCyqGSIb3 EgIBAwEIMBkGA1UdEQQSMBCBDnVyaUBsbC5taXQuZWR1MCcGCSsGAQQBgjcUAgQaHhgATABM AFUAcwBlAHIAUwBpAGcALQBTAFcwDQYJKoZIhvcNAQELBQADggEBAK7HM6o1IolvkCJrlsjj N1+0Z2JG8anwkHkVKAg/K9qUD0LE9zbnK3kZRGZsljJUDG+hMWmTWCkx0TTzbg/BeVrypVPD 7rn1Tagi9QBV2eJhdBZRHWOcsteRldUukKbMw74hkNGH9o/p/FFZYMA0kHnA7XfECilF9Yl6 uKDv1lbjuWdgcKD1FdEj7rL/IdX0wKJVUKjwLG1RQZel1nuwyRjVtXWz8IUMJXRsYHf6uSzy YoNBeZuWyMx/J5c0ACKXXs1O721GPJ5U5gcEaQ/b8lwQGcOgPk28RPwgiBF3f5TgrTa7QxGf ozmNsTj1OV1vU0vjqKrg7USi9q0xTdGUIyowggS8MIIDpKADAgECAgEpMA0GCSqGSIb3DQEB BQUAMFQxCzAJBgNVBAYTAlVTMR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQww CgYDVQQLEwNQS0kxFjAUBgNVBAMTDU1JVExMIFJvb3QgQ0EwHhcNMTMxMjE3MDAwMDAwWhcN MjAxMjMxMjM1OTU5WjBRMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFi b3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBDQS0zMIIBIjANBgkqhkiG 9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2jBSdW18tuW1tNxG6h8B0kqckFZQAAtoHCkvUpUEX6jF vBd8mQI53GyLYRuAo4HWJpe7/izFXOfSJDs6UM5ovvCOfXg2bJgDYlBC9JDcLBFIn0nppOu9 RvpjWSixtC56crwJ5Us5QPdtxtKdek5LJXl2oKw3w8lihUixePbxWad1m7ZMKKagvm9zTybP 6FumKRxeYJjSpB2+cAYjoGGEbSVHyx8uzHm6xAoBMHxa8by+yDz8Jzk6sP9iilgP3iXSGoCA mhyBzvlQQ5QNNWP+Emo9jz/ukKhYVB/VwdxtoquPAqn4ifDAIaM9dtb05cy1gXAFSP3Z/iUk xyBZZUORfwIDAQABo4IBmjCCAZYwEgYDVR0TAQH/BAgwBgEB/wIBADAdBgNVHQ4EFgQU12Bm DntJjXVMDf3PRt7IxxKHyr8wHwYDVR0jBBgwFoAUZ6p6z/QKprlytYqg0p3yEMND7SkwDgYD VR0PAQH/BAQDAgGGMGYGCCsGAQUFBwEBBFowWDAtBggrBgEFBQcwAoYhaHR0cDovL2NybC5s bC5taXQuZWR1L2dldHRvP0xMUkNBMCcGCCsGAQUFBzABhhtodHRwOi8vb2NzcC5sbC5taXQu ZWR1L29jc3AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC5sbC5taXQuZWR1L2dldGNy bD9MTFJDQTCBkgYDVR0gBIGKMIGHMA0GCyqGSIb3EgIBAwEGMA0GCyqGSIb3EgIBAwEIMA0G CyqGSIb3EgIBAwEHMA0GCyqGSIb3EgIBAwEJMA0GCyqGSIb3EgIBAwEKMA0GCyqGSIb3EgIB AwELMA0GCyqGSIb3EgIBAwEOMA0GCyqGSIb3EgIBAwEPMA0GCyqGSIb3EgIBAwEQMA0GCSqG SIb3DQEBBQUAA4IBAQAsf9HBn72qU7UTgkxarjAc7iynhcDEgWwezYKtd/SLGSQ0DhtzIV/L TCxqULjOd+H+HTqMJXB8+nHnzhyqQ43RsnGZOFT5RfzPh94db/ZJ3ql244DwlJI7yXBA2DkZ cEEgOWC9bHcrElzU6NnigahSW5odVJrhmH/XhQAcMS77E5H62yyxK1WPPgcBipGVnu1xSHbT iHe7DqfWQ2tVMLUf23XYhIua94kJsQd4jSh71NVD0e7F4snAoqQMI98MzDYeLOkjlzKRs77r /aMsPAKx6nMaOvRL7Cy0Pjp51i2qFkbGmX8ofnh2kerjTTvRJ/g22r1MV8RR1PktjMsNOsPf MIIE7TCCA9WgAwIBAgIKMziUjwAAAABuljANBgkqhkiG9w0BAQsFADBRMQswCQYDVQQGEwJV UzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYD VQQDEwpNSVRMTCBDQS0zMB4XDTE2MDExNDE3MzAzOVoXDTE5MDExMzE3MzAzOVowYTELMAkG A1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDzANBgNVBAsTBlBl b3BsZTEgMB4GA1UEAxMXQmx1bWVudGhhbC5VcmkuNTAwMTA1ODQwggEiMA0GCSqGSIb3DQEB AQUAA4IBDwAwggEKAoIBAQDjFDaGib07mHBdNaVMNpj9+4iJa+K9AcTN3y+iU1ygtvHG4cot eDBf77ZN1uwdt+lodW0C8XyG43suSfpNp/owLOUElFagAnPqHAvAUIwsl5AjzncpJP+78Ui4 u34aMNsddP+QZu9HI2Qg+P6eMD25jkjybT9dQMxXZpO2oTBznlWjYIItdZhK1DWZqIR0at7n 2YjCSQsZNX0lJ4JwrtjHYFrYPnnZC0f1B2M7V54IS863CEyfu5XotoZx8YuHwYpKSFq80SEh 6cMDLdTe1ZAjWxsnbyKC64rreStyI2PVN9uBWd+OleGoIAjVogpMKKi0pSRHcCuwDwGekpQV ubK9AgMBAAGjggG1MIIBsTAdBgNVHQ4EFgQU8U/FiJmibLZl2+KcNbVWE2PZipswDgYDVR0P AQH/BAQDAgUgMB8GA1UdIwQYMBaAFNdgZg57SY11TA39z0beyMcSh8q/MDMGA1UdHwQsMCow KKAmoCSGImh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXRjcmwvTExDQTMwZgYIKwYBBQUHAQEE WjBYMC0GCCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8vTExDQTMwJwYI KwYBBQUHMAGGG2h0dHA6Ly9vY3NwLmxsLm1pdC5lZHUvb2NzcDA9BgkrBgEEAYI3FQcEMDAu BiYrBgEEAYI3FQiDg+Udh+ynZoathxWD6vBFhbahHx2F69Bwg+vtIAIBZAIBBTAlBgNVHSUE HjAcBgRVHSUABggrBgEFBQcDBAYKKwYBBAGCNwoDBDAYBgNVHSAEETAPMA0GCyqGSIb3EgIB AwEIMBkGA1UdEQQSMBCBDnVyaUBsbC5taXQuZWR1MCcGCSsGAQQBgjcUAgQaHhgATABMAFUA cwBlAHIARQBuAGMALQBTAFcwDQYJKoZIhvcNAQELBQADggEBABbuvs9m0gS5U8JJuVc+qttV 2BWQ0jDepXpYfP/xN8rVScRPHe2SMUaFH5OMRhheGJkdogWVNnMrjHxQfpfc0z8yotlD3xwX ENWUY5MoQmpEGB2ksFqgMd121bqzR3WY84Lcosfow0MoplXs8mvO7TnozwM+PtGZs0mpp2Pz BkvWdNbs2r/7wXJP6/pLd5zPvywRNhTgoVe1aN4ivIkU8svkKMggv5ZaOsonaW8JS6dUYmvv k0QvDJRIQNRR0zpQpOKp+4V/XhMZRhxQJ3DjVTjh9Q/pHKm7ARFhFr3QAJ6ocCjyzLF5issa 1Vshx7ElBIk0cXhep6mLMLqGNX3azAkxggIFMIICAQIBATBfMFExCzAJBgNVBAYTAlVTMR8w HQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxEzARBgNVBAMT Ck1JVExMIENBLTMCCjM7SmUAAAAAbpkwDQYJYIZIAWUDBAICBQCgeTA/BgkqhkiG9w0BCQQx MgQwLvwXw5DY9OY/wO1YVh9dS4d4CjY1yumlocjAc8QG6ug83MWtP8VRtCt9sjNK6GjnMBgG CSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE2MDQwODEzNDkwOFow DQYJKoZIhvcNAQEBBQAEggEAKePGyhoQRwyThCyNQ5apjTcGWK+ZoMBrxr306tJjZFF9JwNx S5FbySD1PfL8mJt6jvaeA1bxxZ4u7Rc0w0St/3j2LLzoRlARR4cNxHfSQ3fhuxzsrfcrYPfB 5623Arm7z9qY8r7MCDUxk8+X8XhZfcxPGDxZUv1Znc3JrKUwHGXoTF6jbGXTScuOd6SxYQ2q GUMCRSsz0qnxQW2rtYOtuQwQQKPDY1A5yZ3KE5n95EQyrVejX1T9ayJv9CZmcJpnPE98PAnM EmWaODAkwSvP1gf6VK4xRh/DSE2+t7DlBFWN1dsP4WtEsSrZZXhMugfcolp2eKgqK64vGk5w VhMKXw== --B_3542953748_51060236-- From nobody Fri Apr 8 09:15:48 2016 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 758C012D1AC for ; Fri, 8 Apr 2016 09:15:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H51utJcQPgwQ for ; Fri, 8 Apr 2016 09:15:46 -0700 (PDT) Received: from mail-oi0-x235.google.com (mail-oi0-x235.google.com [IPv6:2607:f8b0:4003:c06::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 642A112D92A for ; Fri, 8 Apr 2016 09:15:41 -0700 (PDT) Received: by mail-oi0-x235.google.com with SMTP id w85so141872280oiw.0 for ; Fri, 08 Apr 2016 09:15:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to; bh=4+eFPaBOx1iYhrSlMM9NTX9hXrPne7bV78o8fl+opdw=; b=WTUeTyeZagLz1yEa1+PqBIDsu86OERo9o3QoPVeEUpCnU/+nW0J5u9jF4k+gvXPy1t T8nxjcUEbU3aGrjCq/CJ7bwXReNlSq/E1qFj5l84kXcquWuUhrkNmlOzEiCxXTmP06rU EgB3sZXa0o2qETPRgAx4+Ge1c0U6XOAHq4MeuubaC4JMCTMCyUpXXr52+DKov6WZ3//G CHNcLfsy0g3+oh9Yv2JAN8a4FEA2gQ2Sl/Tq5K/uLKSlKg0PeCq3SnMD3QUr1X9Dloz8 hmBBWHiYqcSA8BOYOABGcDLkZXy51p0QJkUsV5vwlr5CC9ErGwg6QOhS0YHxXorJR0LI Dshw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to; bh=4+eFPaBOx1iYhrSlMM9NTX9hXrPne7bV78o8fl+opdw=; b=g/eNGR7z72LJVZokSYGBpH3C7dIK6IkNoZs6+Pw0fewlcX5Xb83AwUwZNv+SVQZQPt PnMcbwxByACVc047OHKpiPzn6gEiq7LmNjYtLF9FjkCGUYM4xJHMwBvRwZvRyCyauF95 /jJvf98wYUoqwtZH30sEDhD9bEWgJ0k7OVQxfBtX/daQbJIkCsixMQ+1N0S9W2QZ3/WI ftbcSW2Yau11xdsTZcDX7mWzfygFvdSxYvonf1Rdaj3QjjRSvPHPHLEdOxPKsCozdHTl kGp+wGblzzIYPMoFyAl1vbtzpBctsjTmlRf8pL0cLuplkDwWjJ+An1ONtMon1rnu6pjT eqLg== X-Gm-Message-State: AD7BkJLVqwcLiZD8Tc/OL3UtXyexENt3Z2erqy/btkl6r7hMUtFa2DW5W7gVkBK6BDwU6x9MJcxbw7HG6qbD3g== MIME-Version: 1.0 X-Received: by 10.202.201.198 with SMTP id z189mr4651814oif.98.1460132140829; Fri, 08 Apr 2016 09:15:40 -0700 (PDT) Received: by 10.60.95.41 with HTTP; Fri, 8 Apr 2016 09:15:40 -0700 (PDT) Date: Fri, 8 Apr 2016 09:15:40 -0700 Message-ID: From: Bill Cox To: cfrg@ietf.org Content-Type: multipart/alternative; boundary=001a1137c44c94546e052ffb816d Archived-At: Subject: [Cfrg] I would like to help on the review team X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2016 16:15:47 -0000 --001a1137c44c94546e052ffb816d Content-Type: text/plain; charset=UTF-8 Is this the right way to self-nominate? I'll have no hard feelings if not accepted to the team. I am still somewhat new to crypto, but I enjoy trying to find flaws in crypto code (the actual code more than the specs), and I think I would learn more quickly as part of the review team. Thanks, Bill --001a1137c44c94546e052ffb816d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Is this the right way to self-nominate?=C2=A0 I'll hav= e no hard feelings if not accepted to the team.=C2=A0 I am still somewhat n= ew to crypto, but I enjoy trying to find flaws in crypto code (the actual c= ode more than the specs), and I think I would learn more quickly as part of= the review team.

Thanks,
Bill
--001a1137c44c94546e052ffb816d-- From nobody Fri Apr 8 09:17:08 2016 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1933B12D547 for ; Fri, 8 Apr 2016 09:17:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t6ww1cR-vkdA for ; Fri, 8 Apr 2016 09:17:04 -0700 (PDT) Received: from mail-pf0-x234.google.com (mail-pf0-x234.google.com [IPv6:2607:f8b0:400e:c00::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 408EC12D1AC for ; Fri, 8 Apr 2016 09:17:03 -0700 (PDT) Received: by mail-pf0-x234.google.com with SMTP id e128so78570013pfe.3 for ; Fri, 08 Apr 2016 09:17:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:message-id:subject:mime-version; bh=qNxq7Pubr3Yvxvit0wsULoXi7s5/DEnmnln98y3wi3E=; b=fCVwfIj77IxtmJ7ueETomG2erLpxHtWyS7U2loPHrcTROBYFSRCu3/et39z+RcON0s WSdF8c4h/QknLsJq0I2dI11C9kkoqRfuPmDE1s+Rg9uoon6CyMpYhOLn2g4eiXcoSS1f ftmyDyiS3XuqDL/e9HyPiIRdJLbm6nqlmqE8eZoP0ubEzmYq0ekTmNfIJS1uTa3POfH7 Hl6KBOcXrVQB7wJsjs/12L1BKUxN5VdIH1H1HXv1YYdfmUHYZbpyOOdRrSIZ6ROe3V/o 9I78uZOfL//Zaw0qR8CxQc0Buxub1OGT1fiUqABgEtHikOp/TyEUeBByQROWdxBeEPZy 0n2A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:date:from:to:message-id:subject :mime-version; bh=qNxq7Pubr3Yvxvit0wsULoXi7s5/DEnmnln98y3wi3E=; b=XKiGw9OaBWQClNN9SK/x0E0CM7DWIaYIWUcA/yn0vaEn5QQrVmcXCJme8sYPJvrJMe gh3BptXP3Mod2VjMAHXNvDK6a4fp0prG9yIs1EZji87lU6/CT7SuVi0QsJL8R4sxfw7D HXy5vvmr3YildakYlhv7UP2rQ+OCtgysOYEnmq4LZ3/FxwJhof44ruhhjmgRIAATIiVa aqR9RzAoxWaIkzTUSOVnqcvxgkMMoM4GhzDYTRa4DxQwu4exfXhX+UenRLbOGZlcnogo Zzm96lrRwLF+lgcv0NaxQS9Vseb791KynrapN5Vh66Pj2s/yiyQ9MWEYxsp1BaJsfiKS Hwxw== X-Gm-Message-State: AD7BkJJZEDie2yz5Cr362lqXCms4JB1A1tjQPeY7eFYzVI03sXkdwpZ3gZyCcgGozSEzYQ== X-Received: by 10.98.7.153 with SMTP id 25mr13951842pfh.38.1460132222794; Fri, 08 Apr 2016 09:17:02 -0700 (PDT) Received: from mail.outlook.com (ec2-52-24-139-88.us-west-2.compute.amazonaws.com. [52.24.139.88]) by smtp.gmail.com with ESMTPSA id to9sm19788050pab.27.2016.04.08.09.17.00 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 08 Apr 2016 09:17:00 -0700 (PDT) Sender: Phillip Hallam-Baker Date: Fri, 8 Apr 2016 16:16:59 +0000 (UTC) From: Phillip Hallam-Baker To: IRTF CFRG Message-ID: <994C5976EA09B556.C00F2996-803A-4815-814F-69865ECFCC39@mail.outlook.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_4878_831816746.1460132219649" X-Mailer: Outlook for iOS and Android Archived-At: Subject: [Cfrg] Two types of quantum resistance X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2016 16:17:06 -0000 ------=_Part_4878_831816746.1460132219649 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit It occurred to me that there are two types of attack to be concerned with: 1) Someone creates a QC that can break any key of size x bits with some limitation on rate2) Someone applies the QC so that they can break every key. Even if someone has a QC that can break thousands of keys a second, I doubt they are going to use it in ways that would risk the existence of the machine being discovered. Yes we now know that DH in discrete log has a problem, someone can find an inverse function that allows any public key to be broken. Questions1) Does the same attack or something similar apply to ECDH? Or is ECDH immune for the same reason that index calculus and RSA don't work? 2) Are there defenses we should be considering - like not using all the same groups all the time? Sent from Outlook Mobile ------=_Part_4878_831816746.1460132219649 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
It occurred to me that there are two types of attack to be concerned w= ith:

1) Someone creates a QC that can break any ke= y of size x bits with some limitation on rate
2) Someone applies = the QC so that they can break every key.

Even if s= omeone has a QC that can break thousands of keys a second, I doubt they are= going to use it in ways that would risk the existence of the machine being= discovered.

Yes we now know that DH in discrete l= og has a problem, someone can find an inverse function that allows any publ= ic key to be broken.

Questions
1) Does t= he same attack or something similar apply to ECDH? Or is ECDH immune for th= e same reason that index calculus and RSA don't work?

<= div>2) Are there defenses we should be considering - like not using all the= same groups all the time?


Sent from Outlook Mobile

=
------=_Part_4878_831816746.1460132219649-- From nobody Fri Apr 8 09:23:53 2016 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9253312D5B4 for ; Fri, 8 Apr 2016 09:23:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=rhul.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AWN0NDdpBUig for ; Fri, 8 Apr 2016 09:23:49 -0700 (PDT) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0661.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::661]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B714E12D57E for ; Fri, 8 Apr 2016 09:23:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rhul.onmicrosoft.com; s=selector1-rhul-ac-uk; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=aXKue3wwMACcvTOLUXpg66Xq7rN+c/HVJvLSX07JL+w=; b=U5suF8rdvsWGupALvPTbjdFvuzaBrDrX8zxHS1QiCKVYzqBjTmMjnPlPT6JzLeg47aS6k6R4Weze1nF7QnrQn9HaAmwvDPpp5OqXpOhKlBJHKHluv0elbcYMVvWNpu4IWp1xMIbiJ2SpI7g1RF8HNQJTwTas40tK09qvVcO2/Uo= Received: from VI1PR03MB1822.eurprd03.prod.outlook.com (10.166.42.148) by VI1PR03MB1824.eurprd03.prod.outlook.com (10.166.42.150) with Microsoft SMTP Server (TLS) id 15.1.453.26; Fri, 8 Apr 2016 16:23:26 +0000 Received: from VI1PR03MB1822.eurprd03.prod.outlook.com ([10.166.42.148]) by VI1PR03MB1822.eurprd03.prod.outlook.com ([10.166.42.148]) with mapi id 15.01.0453.028; Fri, 8 Apr 2016 16:23:26 +0000 From: "Paterson, Kenny" To: Phillip Hallam-Baker , IRTF CFRG Thread-Topic: [Cfrg] Two types of quantum resistance Thread-Index: AQHRkbIflRs05IilkUKmSkCDscjZpJ+AU40A Date: Fri, 8 Apr 2016 16:23:26 +0000 Message-ID: References: <994C5976EA09B556.C00F2996-803A-4815-814F-69865ECFCC39@mail.outlook.com> In-Reply-To: <994C5976EA09B556.C00F2996-803A-4815-814F-69865ECFCC39@mail.outlook.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.1.160122 authentication-results: hallambaker.com; dkim=none (message not signed) header.d=none; hallambaker.com; dmarc=none action=none header.from=rhul.ac.uk; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [134.219.148.47] x-ms-office365-filtering-correlation-id: 1ca9d4f7-04ef-4b7a-62b5-08d35fca1d28 x-microsoft-exchange-diagnostics: 1; VI1PR03MB1824; 5:9ZtblBP/AJnPaPsIBpSLpWuoIcLREH46rVCh4827UsrtPQu5udrXrk0OYrC5q0zfUFE+QfoO3jocvk1tD3rAxP2WNN75E+jCQ5eVPXLCtllFF+dxBqFU0wXaBd9EBlJ/7YI2DtJrsk2PLx2D6hdxUg==; 24:yP0FZNvYBgU01LfEHIlRMkS2OWnsRHGlUeRI0L6HxBrLeGyW0em9wJu9mxei/yz2V5ckjv55kCbGRRROBEimrnt9F0G4S9rMx2hzjbTShLw= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:VI1PR03MB1824; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001); SRVR:VI1PR03MB1824; BCL:0; PCL:0; RULEID:; SRVR:VI1PR03MB1824; x-forefront-prvs: 0906E83A25 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(24454002)(3280700002)(3660700001)(1096002)(1220700001)(106116001)(4001350100001)(5001770100001)(86362001)(54356999)(81166005)(5008740100001)(50986999)(107886002)(189998001)(2906002)(76176999)(122556002)(77096005)(10400500002)(19580405001)(19580395003)(87936001)(36756003)(74482002)(586003)(6116002)(102836003)(3846002)(66066001)(5004730100002)(92566002)(83506001)(11100500001)(5002640100001)(2900100001)(2950100001); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR03MB1824; H:VI1PR03MB1822.eurprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: text/plain; charset="utf-8" Content-ID: <85B9836987C4484A9DE577B2056F3005@eurprd03.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: rhul.ac.uk X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Apr 2016 16:23:26.5809 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2efd699a-1922-4e69-b601-108008d28a2e X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR03MB1824 Archived-At: Subject: Re: [Cfrg] Two types of quantum resistance X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2016 16:23:52 -0000 UGhpbGlwLA0KDQpPbiAwOC8wNC8yMDE2IDE3OjE2LCAiQ2ZyZyBvbiBiZWhhbGYgb2YgUGhpbGxp cCBIYWxsYW0tQmFrZXIiDQo8Y2ZyZy1ib3VuY2VzQGlydGYub3JnIG9uIGJlaGFsZiBvZiBwaGls bEBoYWxsYW1iYWtlci5jb20+IHdyb3RlOg0KDQo+WWVzIHdlIG5vdyBrbm93IHRoYXQgREggaW4g ZGlzY3JldGUgbG9nIGhhcyBhIHByb2JsZW0sIHNvbWVvbmUgY2FuIGZpbmQNCj5hbiBpbnZlcnNl IGZ1bmN0aW9uIHRoYXQgYWxsb3dzIGFueSBwdWJsaWMga2V5IHRvIGJlIGJyb2tlbi4NCg0KSSdt IG5vdCBzdXJlIHdoYXQgeW91IG1lYW4gYnkgIkRIIGluIGRpc2NyZXRlIGxvZyIgaGVyZS4gV2Un dmUgYWx3YXlzDQprbm93biB0aGF0IERIIGlzIHZ1bG5lcmFibGUgdG8gZGlzY3JldGUgbG9nYXJp dGhtIGFsZ29yaXRobXMuDQoNCj5RdWVzdGlvbnMNCj4xKSBEb2VzIHRoZSBzYW1lIGF0dGFjayBv ciBzb21ldGhpbmcgc2ltaWxhciBhcHBseSB0byBFQ0RIPyBPciBpcyBFQ0RIDQo+aW1tdW5lIGZv ciB0aGUgc2FtZSByZWFzb24gdGhhdCBpbmRleCBjYWxjdWx1cyBhbmQgUlNBIGRvbid0IHdvcms/ DQoNClllcywgU2hvciBhbHNvIGFwcGxpZXMgdG8gRUNESC4NCg0KPjIpIEFyZSB0aGVyZSBkZWZl bnNlcyB3ZSBzaG91bGQgYmUgY29uc2lkZXJpbmcgLSBsaWtlIG5vdCB1c2luZyBhbGwgdGhlDQo+ c2FtZSBncm91cHMgYWxsIHRoZSB0aW1lPw0KDQpUaGlzIGlzIHVubGlrZWx5IHRvIGJlIGEgcm9i dXN0IGRlZmVuY2UgYWdhaW5zdCBhIGxhcmdlLXNjYWxlLCBmdWxseQ0KcHJvZ3JhbW1hYmxlIHF1 YW50dW0gY29tcHV0ZXIuIEl0IG1pZ2h0IHByb3ZpZGUgc29tZSB2ZXJ5IGxpbWl0ZWQNCm1pdGln YXRpb24gaWYgdGhlIHF1YW50dW0gaGFyZHdhcmUgdGVjaG5vbG9neSBwYXRoIGV2b2x2ZXMgaW4g cGFydGljdWxhciwNCnJlc3RyaWN0ZWQgd2F5cywgYnV0IEkgd291bGQgbm90IGJlIGhhcHB5IGJl dHRpbmcgdGhhdCBpdCB3aWxsIChvciB5b3UnZA0KbmVlZCB0byBnaXZlIG1lIHZlcnkgZ2VuZXJv dXMgb2RkcykuDQoNCkNoZWVycw0KDQpLZW5ueSANCg0KDQo= From nobody Fri Apr 8 09:30:36 2016 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 006F012D95A for ; Fri, 8 Apr 2016 09:30:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d6HunO4oZ3LG for ; Fri, 8 Apr 2016 09:30:31 -0700 (PDT) Received: from welho-filter1.welho.com (welho-filter1.welho.com [83.102.41.23]) by ietfa.amsl.com (Postfix) with ESMTP id BD74C12D8CE for ; Fri, 8 Apr 2016 09:30:31 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter1.welho.com (Postfix) with ESMTP id 45E5C2867; Fri, 8 Apr 2016 19:30:30 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp2.welho.com ([IPv6:::ffff:83.102.41.85]) by localhost (welho-filter1.welho.com [::ffff:83.102.41.23]) (amavisd-new, port 10024) with ESMTP id KcWAV6RF8c11; Fri, 8 Apr 2016 19:30:30 +0300 (EEST) Received: from LK-Perkele-V2 (87-100-143-35.bb.dnainternet.fi [87.100.143.35]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp2.welho.com (Postfix) with ESMTPSA id EC04121C; Fri, 8 Apr 2016 19:30:29 +0300 (EEST) Date: Fri, 8 Apr 2016 19:30:28 +0300 From: Ilari Liusvaara To: Phillip Hallam-Baker Message-ID: <20160408163028.GA30660@LK-Perkele-V2.elisa-laajakaista.fi> References: <994C5976EA09B556.C00F2996-803A-4815-814F-69865ECFCC39@mail.outlook.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <994C5976EA09B556.C00F2996-803A-4815-814F-69865ECFCC39@mail.outlook.com> User-Agent: Mutt/1.5.24 (2015-08-30) Sender: ilariliusvaara@welho.com Archived-At: Cc: IRTF CFRG Subject: Re: [Cfrg] Two types of quantum resistance X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2016 16:30:36 -0000 On Fri, Apr 08, 2016 at 04:16:59PM +0000, Phillip Hallam-Baker wrote: > It occurred to me that there are two types of attack to be concerned with: > 1) Someone creates a QC that can break any key of size x bits with some limitation on rate2) Someone applies the QC so that they can break every key. > Even if someone has a QC that can break thousands of keys a second, I doubt they are going to use it in ways that would risk the existence of the machine being discovered. > Yes we now know that DH in discrete log has a problem, someone can find an inverse function that allows any public key to be broken. > Questions1) Does the same attack or something similar apply to ECDH? Or is ECDH immune for the same reason that index calculus and RSA don't work? In fact, ECDH is even more vulernable to QC than (mult-group)DH. This is because the increased qubit requirements per field bit are not enough to balance the reduction in field bits. IIRC, pretty much any elliptic curve in use can be cracked with ~3kqbit QC, whereas DH2k would need ~4kqbit. > 2) Are there defenses we should be considering - like not using all the same groups all the time? That won't help against QC. It would help against some attacks, but those are hopeless against prime-curve ECDH anyway. -Ilari From nobody Fri Apr 8 09:47:41 2016 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52D7B12D0B4 for ; Fri, 8 Apr 2016 09:47:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.4 X-Spam-Level: X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 22RlbxyoHevK for ; Fri, 8 Apr 2016 09:47:37 -0700 (PDT) Received: from mail-lf0-x232.google.com (mail-lf0-x232.google.com [IPv6:2a00:1450:4010:c07::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7702B12D145 for ; Fri, 8 Apr 2016 09:47:37 -0700 (PDT) Received: by mail-lf0-x232.google.com with SMTP id g184so84037843lfb.3 for ; Fri, 08 Apr 2016 09:47:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc; bh=9+1Bmx7Vq78OxtQN9BjGHdNOQCRFt/W+qR57JtBezyQ=; b=W4d5tCO7iPyu8AwW6v2AIMID23F2yIbX43XzfLSzVgkbYUc6TWwEUxWxhO7WS+iMmk 0moTr5cG6PrzPaCy5sDYNlCP5oqxVm6RgBFf7hb3KGId28yxccVrN+Qggq0O9s+enrtS jkcytxAjpVt8Ge0JKz8fUlNNoGJ+dhxycbrG7iSjUYgQsszDXH75MgSyRcbMEPYmAcXG 6oHRTV7h/hvrEEk604nknbneobDizmMXNK+sRIA/p3NU8Gm8TLQQsdl5TKJbyRmtn94M 3Il1KLcr3U+hHpHyMLmMkI2pDoDo1nUpRcd6cVp5e/GNRkEvwsGFYnQ8uBg750u9jt/F tkfg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=9+1Bmx7Vq78OxtQN9BjGHdNOQCRFt/W+qR57JtBezyQ=; b=FQVjFq9GXaSTQoQewmfdpLksQwnKlt94YE3l0Dn0SUd2cFzEoOvRg0g5VPDtwgiuDn 9eD72+GQ3XsLmmcCBWM5PRRx0b0W7E714yECQ2cTP/PGfB+wABJGv6r0tFkd5ExwFN3A BMrUoe5USW4qnPMwoC/cIYafiN3BFAHEzEvjxcHJ7ilDQ3h71IBgeB4xeVGU8M5RSwRh FbJ7sb5CxdbgKzEVpWKOnL0dJi85ZJlhXiAONOArrJB2hoRTrvnEyiqj1suLRei7t1CC RuawquaHn6FNdrG1+quzgWYjJ1SLxCgXYyYXAKdUFVp9EUXySSqo5tZhIH3lcnmofu0K +ltw== X-Gm-Message-State: AD7BkJKNgK540J7954rtNNjKqeIWuypseB3Y/3N/XgfqEZsNs5h1ysLblADuyz/Zr4JfvnT3/CB62/74n/UAHQ== MIME-Version: 1.0 X-Received: by 10.112.25.100 with SMTP id b4mr4042047lbg.142.1460134055679; Fri, 08 Apr 2016 09:47:35 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.112.151.67 with HTTP; Fri, 8 Apr 2016 09:47:35 -0700 (PDT) In-Reply-To: References: <994C5976EA09B556.C00F2996-803A-4815-814F-69865ECFCC39@mail.outlook.com> Date: Fri, 8 Apr 2016 13:47:35 -0300 X-Google-Sender-Auth: d28pRJabcXVai0EEOQP4no1qlps Message-ID: From: Phillip Hallam-Baker To: "Paterson, Kenny" Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: IRTF CFRG Subject: Re: [Cfrg] Two types of quantum resistance X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2016 16:47:39 -0000 On Fri, Apr 8, 2016 at 1:23 PM, Paterson, Kenny wrote: > Philip, > > On 08/04/2016 17:16, "Cfrg on behalf of Phillip Hallam-Baker" > wrote: > >>Yes we now know that DH in discrete log has a problem, someone can find >>an inverse function that allows any public key to be broken. > > I'm not sure what you mean by "DH in discrete log" here. We've always > known that DH is vulnerable to discrete logarithm algorithms. > >>Questions >>1) Does the same attack or something similar apply to ECDH? Or is ECDH >>immune for the same reason that index calculus and RSA don't work? > > Yes, Shor also applies to ECDH. Does Shor allow a logjam type attack where you work out the magic key that allows you to use a conventional computer to convert a public key to a private? My hunch based on my DESY/CERN experience is that the first quantum computers are going to look like science experiments and be rather temperamental. Like the totemak fusion experiments that would run for a few milliseconds and then be down for weeks. Getting from that point to being able to run one in production is likely to take another decade of engineering. Hence whether the math enables the general attack to solve an entire curve or just individual points on a curve is quite significant. >>2) Are there defenses we should be considering - like not using all the >>same groups all the time? > > This is unlikely to be a robust defence against a large-scale, fully > programmable quantum computer. It might provide some very limited > mitigation if the quantum hardware technology path evolves in particular, > restricted ways, but I would not be happy betting that it will (or you'd > need to give me very generous odds). I am not very happy about any of this... Isn't it a bit odd that we have two really hard engineering problems involving trying to maintain a particular quantum state for a sustained period? One is very hot and offers limitless free energy. The other is very cold and threatens to destroy the basis of the information infrastructure. Oh and the very cold one also has the curious property that we don't know if the problem has been solved or not until we open up the NSA box. From nobody Fri Apr 8 10:35:02 2016 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B65AE12D956 for ; Fri, 8 Apr 2016 10:35:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TWOzy0kCCBVT for ; Fri, 8 Apr 2016 10:35:00 -0700 (PDT) Received: from mail-io0-x22d.google.com (mail-io0-x22d.google.com [IPv6:2607:f8b0:4001:c06::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E80212D102 for ; Fri, 8 Apr 2016 10:35:00 -0700 (PDT) Received: by mail-io0-x22d.google.com with SMTP id g185so140049450ioa.2 for ; Fri, 08 Apr 2016 10:35:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=gJy/QS6s3ecHupYUPFCuNBWsTDeQRqbM7A8cr6msm6M=; b=TFCj2i/7MM43KcoJ9FOOG2x+qcOrQNVjUUMuFRi+UyTuDOnbVNk6dJwHwEtTnrqvD/ YCXDWa6AIpXBH0EQAveSBRled5sC5N/qte4C8x+ponYF2DinUN0HDPOqseSveKQVIpaF yKHXBAqEzMXXv6c8qQMJsPshJa3PuOsdLFAfZk3wH7jmcDERKYaEwbZDRE4fS2vH5/eV ePN4uEWVjxRcT3xxg+xQGSI/nARci+/a4daoTaWE12ug3//HUzSlXuO76Ng47sftLBFp H/fFdHQg81SY3PhbtuZb/GaIvroGO5/O3AKG4dpmLnB0+aFODzKisBB7NDlHtckNXC0G /iTw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=gJy/QS6s3ecHupYUPFCuNBWsTDeQRqbM7A8cr6msm6M=; b=itlq/kHvA+PYhkJhqyP8BPygCSMGWVG/SupdWzxsBrn7whJEFMcdlLogCOsH/C/tdF 7tSeiRwK4L6HZeg+xd94s9UDaSQ6aCi23rroHJ7jWyRprtrLAxC4PceRysQckQMAsPRZ VLxho0Z0IAaRCPxr/CzOvmXPE5TKOXMUozOtSXb34TDovrnLssdfk8PPkCl72YjW8h0I kIlyNEhcdx/VYJWCVl9RZjSC7mWdlkmE7tt/puTrRjnPi/+6H4LwTa+LfL10sUzQFcH9 7qgw9eS2WQmWuhVQLwj6ClDZy96nsGybQdXP5pK+ZhH5D90tCQI03VToxrY/KQ1akjB3 Dq4Q== X-Gm-Message-State: AD7BkJK2K12hctX0qzDZHatDuag3cMf4IUBuNMMpSFveA7k+/JIOuwkb2cWV1qgmlnEv3Q== X-Received: by 10.107.152.17 with SMTP id a17mr11949417ioe.195.1460136899479; Fri, 08 Apr 2016 10:34:59 -0700 (PDT) Received: from pc-stebila-d.cas.mcmaster.ca (pc-stebila-d.cas.McMaster.CA. [130.113.68.193]) by smtp.gmail.com with ESMTPSA id h75sm7246903ioe.39.2016.04.08.10.34.57 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 08 Apr 2016 10:34:58 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Douglas Stebila In-Reply-To: <20160408163028.GA30660@LK-Perkele-V2.elisa-laajakaista.fi> Date: Fri, 8 Apr 2016 13:34:57 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <994C5976EA09B556.C00F2996-803A-4815-814F-69865ECFCC39@mail.outlook.com> <20160408163028.GA30660@LK-Perkele-V2.elisa-laajakaista.fi> To: Ilari Liusvaara X-Mailer: Apple Mail (2.3124) Archived-At: Cc: IRTF CFRG Subject: Re: [Cfrg] Two types of quantum resistance X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2016 17:35:02 -0000 On Apr 8, 2016, at 12:30 PM, Ilari Liusvaara = wrote: >=20 > In fact, ECDH is even more vulernable to QC than (mult-group)DH. This > is because the increased qubit requirements per field bit are not = enough > to balance the reduction in field bits. >=20 > IIRC, pretty much any elliptic curve in use can be cracked with = ~3kqbit > QC, whereas DH2k would need ~4kqbit. Do you happen to remember where those estimate came from? Were they for = logical qubits or physical qubits? Douglas= From nobody Fri Apr 8 10:41:58 2016 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4453D12D976 for ; Fri, 8 Apr 2016 10:41:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=amacapital-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LefIVTJcZkck for ; Fri, 8 Apr 2016 10:41:53 -0700 (PDT) Received: from mail-oi0-x231.google.com (mail-oi0-x231.google.com [IPv6:2607:f8b0:4003:c06::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 14F2712D975 for ; Fri, 8 Apr 2016 10:41:52 -0700 (PDT) Received: by mail-oi0-x231.google.com with SMTP id w85so144506442oiw.0 for ; Fri, 08 Apr 2016 10:41:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amacapital-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=y182Iti5shxCF1Xv51LlygMoQOtNNFtGhQBmG25BQl8=; b=eyJbavKnibtzNli6jG8gOZ7HWHpOZVtDujq+p57BPN7qFOskO1r+Pnzqz77TSBqMBZ K6J5+Izpacne5BiOEifACwck1DRhOxkrvWSZ0vQTnxKn/JnyIyg/zjRhipW1u9XqzV2Z 4Ki8KSoR8XOVg2vbh3oKSL3/cV0tsy5DyKkRl5YIWGPhgbjTjXB5TGMc5Wuyae6kcpXC kFh05LAPhys2CsMg7kt96LyP4dbmqPRtL4s/KInx5IIVfOlqfu/z/mPnxX94rAS7z9pp 7yn1x7PtMItYhv5jHvGe1Ov5uJwHZTDtpABOJjha6LuMdXlmZbLDg/1z3wr4jS+xqv3w /GhA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=y182Iti5shxCF1Xv51LlygMoQOtNNFtGhQBmG25BQl8=; b=H0xcw8txGm1JbQ6M/L61MOTzuesocQhwtoh5sgi+hrQqgJxI2IP8yv1ZEQLs9RP6u5 SPWNOFWHMtbF+b9hUktj6GWe5PAXgBf8FYs3X9ant7slIaggq4n5CQR9LrfHOUYYbgvy nnarlak8f0/9U+DuAeRhinJjNA9wQ8TFLPWyjCfdyoX8SofwQyOVzSHSho8C/yJ/N2DO 3qIW20BnFzplFIwx6Pj8IpMm2Ks72P2OoyfNLwT1XfsWDNgLxvFTljcdlWwzcrc4Y6at i83tyIKZQOlSnTpYtmtgcVhe9BIvIqUKJ8pXs0b/brf/fwwRFyjNq7iSImXNe6ZioA3C FEoQ== X-Gm-Message-State: AD7BkJI6RxbUYWxU6UM+34OyJF+97ez/bM6+tLdlibhL3R3pMedEYQlLH+5Sj2RgdhYMOZJ/SAFg4SLvxaJljNuz MIME-Version: 1.0 X-Received: by 10.157.4.39 with SMTP id 36mr5216055otc.195.1460137310600; Fri, 08 Apr 2016 10:41:50 -0700 (PDT) Received: by 10.202.202.209 with HTTP; Fri, 8 Apr 2016 10:41:50 -0700 (PDT) Received: by 10.202.202.209 with HTTP; Fri, 8 Apr 2016 10:41:50 -0700 (PDT) In-Reply-To: References: <994C5976EA09B556.C00F2996-803A-4815-814F-69865ECFCC39@mail.outlook.com> <20160408163028.GA30660@LK-Perkele-V2.elisa-laajakaista.fi> Date: Fri, 8 Apr 2016 10:41:50 -0700 Message-ID: From: Andy Lutomirski To: Douglas Stebila Content-Type: multipart/alternative; boundary=001a11370e5eb8d7c4052ffcb5cb Archived-At: Cc: cfrg@irtf.org Subject: Re: [Cfrg] Two types of quantum resistance X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2016 17:41:55 -0000 --001a11370e5eb8d7c4052ffcb5cb Content-Type: text/plain; charset=UTF-8 On Apr 8, 2016 10:35 AM, "Douglas Stebila" wrote: > > On Apr 8, 2016, at 12:30 PM, Ilari Liusvaara wrote: > > > > In fact, ECDH is even more vulernable to QC than (mult-group)DH. This > > is because the increased qubit requirements per field bit are not enough > > to balance the reduction in field bits. > > > > IIRC, pretty much any elliptic curve in use can be cracked with ~3kqbit > > QC, whereas DH2k would need ~4kqbit. > > Do you happen to remember where those estimate came from? Were they for logical qubits or physical qubits? > That number sounds like a huge overestimate for EC. I bet it could be done with a few hundred logical qubits. I haven't looked at the details, but the recent paper from Chuang et al suggests that most of the ancilla qubits aren't actually necessary. --Andy > Douglas > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > https://www.irtf.org/mailman/listinfo/cfrg --001a11370e5eb8d7c4052ffcb5cb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Apr 8, 2016 10:35 AM, "Douglas Stebila" <dstebila@gmail.com> wrote:
>
> On Apr 8, 2016, at 12:30 PM, Ilari Liusvaara <ilariliusvaara@welho.com> wrote:
> >
> > In fact, ECDH is even more vulernable to QC than (mult-group)DH. = This
> > is because the increased qubit requirements per field bit are not= enough
> > to balance the reduction in field bits.
> >
> > IIRC, pretty much any elliptic curve in use can be cracked with ~= 3kqbit
> > QC, whereas DH2k would need ~4kqbit.
>
> Do you happen to remember where those estimate came from?=C2=A0 Were t= hey for logical qubits or physical qubits?
>

That number sounds like a huge overestimate for EC.=C2=A0 I = bet it could be done with a few hundred logical qubits.

I haven't looked at the details, but the recent paper fr= om Chuang et al suggests that most of the ancilla qubits aren't actuall= y necessary.

--Andy

> Douglas
> _______________________________________________
> Cfrg mailing list
> Cfrg@irtf.org
> https://www.irt= f.org/mailman/listinfo/cfrg

--001a11370e5eb8d7c4052ffcb5cb-- From nobody Fri Apr 8 11:30:18 2016 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1DE912D53A for ; Fri, 8 Apr 2016 11:30:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=securityinnovation.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rRjEJrj4ibAD for ; Fri, 8 Apr 2016 11:30:15 -0700 (PDT) Received: from mail-ob0-x235.google.com (mail-ob0-x235.google.com [IPv6:2607:f8b0:4003:c01::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F6D812D586 for ; Fri, 8 Apr 2016 11:30:15 -0700 (PDT) Received: by mail-ob0-x235.google.com with SMTP id tz8so72072862obc.0 for ; Fri, 08 Apr 2016 11:30:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=securityinnovation.com; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=wcSaDNU3jm1Lq+JTWmcV1rgetN3whZblXsdHiLTWVzY=; b=Ke9zalXgu7xIdlXNZvOYwV0MUPVzlK6ChAmsMwxi57gBUP1/UizUES0J2AQRw8YM54 wShTVNr54I1eUTQGT6hUUp+Kzef5s+sret9TGXhR8mDgg6FqkbjoG9ErrizjIay0IMeK 8Ke10xt2L394X7i3tU8ck8G7IlQGIoN9wK35s= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=wcSaDNU3jm1Lq+JTWmcV1rgetN3whZblXsdHiLTWVzY=; b=RHiWEDEQBDuMEhsn+Ou7qcOtkn3EF6llD+IHrHY7v21HvMI81JMp1hA3C/mS+X/pNx u3/xDALOHjlif1BfPYluL0kkUX909OTCPFgbuEYzzwrZkLXPNIqNfan8Gc4fcREQ5lNX +6dVAe/yl2GN0zp0rMWD/nE5OKnaV0lgTHDvqcahSg3ERpTw8AX9IKLQYfjC6jzV0PW8 knMAqWeB2lyU6GUeDq0w/QRaB6sRmTnLam5D2qRGX26Gp183CdqlCWVBbjnWbiep+DW8 8AFiAzieN+eu+mIHCbLpftCC3ZdK6PkOddVib4hp/VL9NpfLyRn1VQJl1/kMrOY2nhlE CrHQ== X-Gm-Message-State: AD7BkJJU8D2r4T5Gk5u7l9lLWAd9yhAf40VxueRAQxgClsgAqCmLsScFTu58p0erDZPT5tkSkx3HHI+VaDsU8sDJ MIME-Version: 1.0 X-Received: by 10.182.97.164 with SMTP id eb4mr4892202obb.39.1460140214541; Fri, 08 Apr 2016 11:30:14 -0700 (PDT) Received: by 10.202.84.84 with HTTP; Fri, 8 Apr 2016 11:30:14 -0700 (PDT) In-Reply-To: References: <994C5976EA09B556.C00F2996-803A-4815-814F-69865ECFCC39@mail.outlook.com> <20160408163028.GA30660@LK-Perkele-V2.elisa-laajakaista.fi> Date: Fri, 8 Apr 2016 14:30:14 -0400 Message-ID: From: William Whyte To: Douglas Stebila Content-Type: multipart/alternative; boundary=047d7b2e41c0cf8ed6052ffd62ce Archived-At: Cc: IRTF CFRG Subject: Re: [Cfrg] Two types of quantum resistance X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2016 18:30:17 -0000 --047d7b2e41c0cf8ed6052ffd62ce Content-Type: text/plain; charset=UTF-8 It sounds like it comes from John Proos's master's thesis, specifically the part here: http://arxiv.org/abs/quant-ph/0301141 The abstract: We show in some detail how to implement Shor's efficient quantum algorithm for discrete logarithms for the particular case of elliptic curve groups. It turns out that for this problem a smaller quantum computer can solve problems further beyond current computing than for integer factorisation. A 160 bit elliptic curve cryptographic key could be broken on a quantum computer using around 1000 qubits while factoring the security-wise equivalent 1024 bit RSA modulus would require about 2000 qubits. My understanding is the number of qubits scales as the field size, but I haven't read that paper in some time. If so, 512-bit ECC would take about 3000 qubits. William On Fri, Apr 8, 2016 at 1:34 PM, Douglas Stebila wrote: > On Apr 8, 2016, at 12:30 PM, Ilari Liusvaara > wrote: > > > > In fact, ECDH is even more vulernable to QC than (mult-group)DH. This > > is because the increased qubit requirements per field bit are not enough > > to balance the reduction in field bits. > > > > IIRC, pretty much any elliptic curve in use can be cracked with ~3kqbit > > QC, whereas DH2k would need ~4kqbit. > > Do you happen to remember where those estimate came from? Were they for > logical qubits or physical qubits? > > Douglas > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > https://www.irtf.org/mailman/listinfo/cfrg > --047d7b2e41c0cf8ed6052ffd62ce Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
It sounds like it comes from John Proos's master's= thesis, specifically the part here:=C2=A0http://arxiv.org/abs/quant-ph/0301141

The abstract: We show in some detail how to implement Shor's efficie= nt quantum algorithm for discrete logarithms for the particular case of ell= iptic curve groups. It turns out that for this problem a smaller quantum co= mputer can solve problems further beyond current computing than for integer= factorisation. A 160 bit elliptic curve cryptographic key=C2=A0could be br= oken on a quantum computer using around 1000 qubits while factoring the sec= urity-wise equivalent 1024 bit RSA modulus would require about 2000 qubits.=

My understanding is the number of qubits scales a= s the field size, but I haven't read that paper in some time. If so, 51= 2-bit ECC would take about 3000 qubits.

William

On Fri, = Apr 8, 2016 at 1:34 PM, Douglas Stebila <dstebila@gmail.com> wrote:
On Apr 8, 2016,= at 12:30 PM, Ilari Liusvaara <ilariliusvaara@welho.com> wrote:
>
> In fact, ECDH is even more vulernable to QC than (mult-group)DH. This<= br> > is because the increased qubit requirements per field bit are not enou= gh
> to balance the reduction in field bits.
>
> IIRC, pretty much any elliptic curve in use can be cracked with ~3kqbi= t
> QC, whereas DH2k would need ~4kqbit.

Do you happen to remember where those estimate came from?=C2=A0 Were= they for logical qubits or physical qubits?

Douglas
_____________________= __________________________
Cfrg mailing list
Cfrg@irtf.org
https://www.irtf.org/mailman/listinfo/cfrg

--047d7b2e41c0cf8ed6052ffd62ce-- From nobody Sat Apr 9 01:26:12 2016 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8A7A12D10D for ; Sat, 9 Apr 2016 01:26:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=rhul.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MbzOifk9q7bC for ; Sat, 9 Apr 2016 01:26:09 -0700 (PDT) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0674.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::674]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F380A12D0EC for ; Sat, 9 Apr 2016 01:26:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rhul.onmicrosoft.com; s=selector1-rhul-ac-uk; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=FSqVq2I+5b/61ph/NPSIxOscQebwmXCu0IgwLWhQmR0=; b=BXB4aWZwg3Tww/+O5f9uURbsAkfqjOT6bCiigE7ovBjGI8QBBwXrvK91X7EnI4h4lAYDYn/LpiP19mxA49sNR9TdODFk2AShnNmfWEIs6qmjzvkpa5ShjA++DFHtH+/uW9UH8STsMAeaddyncMvT0HU9VYmPBQnQNz0+1JOYpqk= Received: from VI1PR03MB1822.eurprd03.prod.outlook.com (10.166.42.148) by VI1PR03MB1824.eurprd03.prod.outlook.com (10.166.42.150) with Microsoft SMTP Server (TLS) id 15.1.453.26; Sat, 9 Apr 2016 08:25:51 +0000 Received: from VI1PR03MB1822.eurprd03.prod.outlook.com ([10.166.42.148]) by VI1PR03MB1822.eurprd03.prod.outlook.com ([10.166.42.148]) with mapi id 15.01.0453.028; Sat, 9 Apr 2016 08:25:50 +0000 From: "Paterson, Kenny" To: Bill Cox , "cfrg@ietf.org" Thread-Topic: [Cfrg] I would like to help on the review team Thread-Index: AQHRkbH4l/oLR2zha0Gu44zoUWMOlZ+BYGuA Date: Sat, 9 Apr 2016 08:25:50 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.1.160122 authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=rhul.ac.uk; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [92.4.66.92] x-ms-office365-filtering-correlation-id: 3149afbb-78c9-44ca-e93d-08d360508f32 x-microsoft-exchange-diagnostics: 1; VI1PR03MB1824; 5:7mLdJCTqDuKWXA9zTsnkdZSc7GUhunXuNfVc7vz5yC+nuDneu+Ns1dEnM8EXoCprj4xldOdxxZ5EnUxEt7jzpdLv6SnneWZMmIKPJt9uW6ujDf6iMK5n16e8DdP2/fTPUery1SMcNl8xZX9p+CStrw==; 24:9754VN0YENq/9E9TekJl/GSGR6Rc2tHKDkCkrZgQz1nndt6yuJr2N+x2pW0wcwGNghAqCv52F+vKLtlKr+I2qkNJaqeLprottTfUhvwBvNA= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:VI1PR03MB1824; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001); SRVR:VI1PR03MB1824; BCL:0; PCL:0; RULEID:; SRVR:VI1PR03MB1824; x-forefront-prvs: 0907F58A24 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(24454002)(3280700002)(3660700001)(1096002)(1220700001)(81166005)(164054004)(5002640100001)(4001350100001)(5001770100001)(106116001)(54356999)(86362001)(50986999)(107886002)(2501003)(76176999)(189998001)(2906002)(102836003)(5008740100001)(77096005)(122556002)(10400500002)(19580405001)(19580395003)(87936001)(2900100001)(83506001)(586003)(66066001)(74482002)(36756003)(5004730100002)(3846002)(2950100001)(6116002)(92566002); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR03MB1824; H:VI1PR03MB1822.eurprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: text/plain; charset="utf-8" Content-ID: <28B3EFBA0AA6E6429EE186B5D6999D71@eurprd03.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: rhul.ac.uk X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Apr 2016 08:25:50.3781 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2efd699a-1922-4e69-b601-108008d28a2e X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR03MB1824 Archived-At: Subject: Re: [Cfrg] I would like to help on the review team X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Apr 2016 08:26:11 -0000 RGVhciBCaWxsLA0KDQpUaGFua3MgZm9yIHZvbHVudGVlcmluZy4NCg0KV2UndmUgb25seSBqdXN0 IHJhaXNlZCB0aGUgaWRlYSBvZiBzZXR0aW5nIHVwIGEgQ0ZSRyByZXZpZXcgYm9hcmQgYXQgdGhl DQpDRlJHIG1lZXRpbmcgdG9kYXksIGFuZCBpdCdzIHNvbWV0aGluZyB3ZSBzaG91bGQgZGlzY3Vz cyBvbiB0aGUgbGlzdCB0b28sDQpzbyB0aGF0IHBlb3BsZSB3aG8gd2VyZSBub3QgYXQgdGhlIEJB IG1lZXRpbmcgY2FuIHZvaWNlIHRoZWlyIG9waW5pb25zLg0KDQpPbmNlIGV2ZXJ5b25lIGlzIGJh Y2sgb24gdGhlIGdyb3VuZCBhZ2FpbiBhZnRlciB0aGUgQkEgbWVldGluZywgdGhlIGNoYWlycw0K d2lsbCBzdGFydCBhbiBvbi1saXN0IGRpc2N1c3Npb24gYWJvdXQgdGhlIGlkZWE7IGlmIGl0IGZs aWVzLCB3ZSdsbCB0aGVuDQpzZXQgdXAgdGhlIGJvYXJkLg0KDQpSZWdhcmRzDQoNCktlbm55IA0K DQpPbiAwOC8wNC8yMDE2IDE3OjE1LCAiQ2ZyZyBvbiBiZWhhbGYgb2YgQmlsbCBDb3giIDxjZnJn LWJvdW5jZXNAaXJ0Zi5vcmcNCm9uIGJlaGFsZiBvZiB3YXl3YXJkZ2Vla0BnbWFpbC5jb20+IHdy b3RlOg0KDQo+SXMgdGhpcyB0aGUgcmlnaHQgd2F5IHRvIHNlbGYtbm9taW5hdGU/ICBJJ2xsIGhh dmUgbm8gaGFyZCBmZWVsaW5ncyBpZg0KPm5vdCBhY2NlcHRlZCB0byB0aGUgdGVhbS4gIEkgYW0g c3RpbGwgc29tZXdoYXQgbmV3IHRvIGNyeXB0bywgYnV0IEkgZW5qb3kNCj50cnlpbmcgdG8gZmlu ZCBmbGF3cyBpbiBjcnlwdG8gY29kZSAodGhlIGFjdHVhbCBjb2RlIG1vcmUgdGhhbiB0aGUNCj5z cGVjcyksIGFuZCBJIHRoaW5rIEkgd291bGQgbGVhcm4NCj4gbW9yZSBxdWlja2x5IGFzIHBhcnQg b2YgdGhlIHJldmlldyB0ZWFtLg0KPg0KPg0KPlRoYW5rcywNCj5CaWxsDQo+DQoNCg== From nobody Sun Apr 10 06:39:12 2016 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C999712D59E for ; Sun, 10 Apr 2016 06:39:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4tpU4Zj5TDde for ; Sun, 10 Apr 2016 06:39:09 -0700 (PDT) Received: from mail-io0-x231.google.com (mail-io0-x231.google.com [IPv6:2607:f8b0:4001:c06::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 37FFC12D5A0 for ; Sun, 10 Apr 2016 06:39:09 -0700 (PDT) Received: by mail-io0-x231.google.com with SMTP id u185so12315541iod.3 for ; Sun, 10 Apr 2016 06:39:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:cc:date:message-id:in-reply-to:reply-to:user-agent :mime-version; bh=Ke0r6ViGPkVYBgyIVoSTBTiCZLZWo/KE1pC9YhYIj80=; b=hEFgnJT1+OE0J43UZxjY3JvpEQBteu1/BU1sBXcaEMMHfOnCfp7iNtnNhhe2TkIPZ5 Je4fMPFA+DN3n7YHIIuSyekRRMEHfaRpmzAOCgiX748MLYfNJD5gXtoCGQRIFaj0YCjC f3JcJitlxCh0FQPk9/RqXglovOPwkni+WdCb14aCmljbEeHp15WM9E8PCnoL4me5ep9U ocV9HjrRmwDNlGPPSx2miygRKqLUUNZbbphUszaylM/BfpLFOeE96x9OaCrhhXeDWpGn VRGUc4itMHNe+jwGhhx1vWNEVT5vPPYAJ+34btfPCBZsuQTLWNKjcO7G3hkV2TKMj51C c+mA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:subject:cc:date:message-id:in-reply-to :reply-to:user-agent:mime-version; bh=Ke0r6ViGPkVYBgyIVoSTBTiCZLZWo/KE1pC9YhYIj80=; b=JCvuGrnhreHgH2omoVSklXk4sUhccUbmMn9OXfKSyTMMJ76tz9C9lYDsK0jbeAPc6/ tn/bkQo1dOyEcalIrEnnRs2cKB6Y0+OYlisGPRXhB2cPKRnNqAZdPLPguX5ZbT3tJja7 w8QmRGPoF4yBd1Gm4PwY7RdqDdob+14fskAHznv+Q20GOWoPLX3rGXSuBwegJ2zpLxCh 35AUyfz4QT4M798Ja2DFCtkdGT2Ki13QZUqh31ELbu0WjH3iSXpaBnxdJuqE7KdYMyN0 ysmwGSEEfRxCscwsXzFOJUYmuGZ77/mSFViIvAKFSf1Eq7ItguZ7ADW+2hTxUroVDrPV dOcg== X-Gm-Message-State: AD7BkJKR3u33safATEXxT/JRKBPNKMLZlWSd4gCAtJeR5F0e5TuTBi2sxxAyPPsxJE9gzQ== X-Received: by 10.107.9.202 with SMTP id 71mr21048285ioj.52.1460295548572; Sun, 10 Apr 2016 06:39:08 -0700 (PDT) Received: from [10.254.185.252] (fmdmzpr04-ext.fm.intel.com. [192.55.55.39]) by smtp.gmail.com with ESMTPSA id u3sm13659561iod.1.2016.04.10.06.39.07 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sun, 10 Apr 2016 06:39:07 -0700 (PDT) From: "Gueron, Shay" To: "Blumenthal, Uri - 0553 - MITLL" , "Adam Langley" , "Andy Lutomirski" Date: Sun, 10 Apr 2016 13:35:23 +0000 Message-Id: In-Reply-To: <20160408124036.18280531.99866.62311@ll.mit.edu> User-Agent: eM_Client/6.0.24316.0 Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="------=_MB23F834FB-2F51-4147-8CD9-421F0A5F87AA" Archived-At: Cc: Yehuda Lindell , "cfrg@irtf.org" , Adam Langley Subject: Re: [Cfrg] Adopting "AES-GCM-SIV: Nonce Misuse-Resistant Authenticated Encryption" as a CFRG document ---- Some clarifications X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: "Gueron, Shay" List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Apr 2016 13:39:12 -0000 --------=_MB23F834FB-2F51-4147-8CD9-421F0A5F87AA Content-Type: text/plain; format=flowed; charset=utf-8 Content-Transfer-Encoding: quoted-printable >>> BTW, what assembler is the optimized code supposed to work with? The code that is currently posted was compiled and tested under Red Hat=20 Linux, Fedora release 23, using GCC 4.8.2 & GNU assembly version 2.25. MAC OS does not easily chew this assembler syntax, and some work needs=20 to be done around it. However, I will soon post a C (intrinsics) version= =20 of the code, that should compile on all platforms (of course, at the=20 cost of giving up some performance that hand tuned assembler achieves). Regards, Shay ------ Original Message ------ From: "Blumenthal, Uri - 0553 - MITLL" To: "Adam Langley" ; "Andy Lutomirski"=20 Cc: "Yehuda Lindell" ; "cfrg@irtf.org"=20 ; "Adam Langley" Sent: 4/8/2016 5:40:27 AM Subject: Re: [Cfrg] Adopting "AES-GCM-SIV: Nonce Misuse-Resistant=20 Authenticated Encryption" as a CFRG document ---- Some clarifications >BTW, what assembler is the optimized code supposed to work with? > >I'm on Mac OSX (10.10.5 and 10.11.4) using Xcode 7.2.1 and 7.3=20 >correspondingly. Both systems also have gcc-5.3 and clang-3.7. I also=20 >t=E2=80=8Eried nasm, yasm. Nothing works. Would like some guidance. > >Sent from my BlackBerry 10 smartphone on the Verizon Wireless 4G LTE=20 >network. > Original Message >From: Adam Langley >Sent: Thursday, April 7, 2016 19:55 >To: Andy Lutomirski >Cc: Yehuda Lindell; cfrg@irtf.org; Adam Langley >Subject: Re: [Cfrg] Adopting "AES-GCM-SIV: Nonce Misuse-Resistant=20 >Authenticated Encryption" as a CFRG document ---- Some clarifications > >On Fri, Apr 8, 2016 at 8:16 AM, Andy Lutomirski =20 >wrote: >> Can you clarify the draft? > >Will do as soon as I'm able (which should be next week). > > >Cheers > >AGL > >-- >Adam Langley agl@imperialviolet.orghttps://www.imperialviolet.org > >_______________________________________________ >Cfrg mailing list >Cfrg@irtf.org >https://www.irtf.org/mailman/listinfo/cfrg > --------=_MB23F834FB-2F51-4147-8CD9-421F0A5F87AA Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

Hi Uri,

 

You are definitely righ= t.

I just tried to answer= about the actual flow, rather than the intended cryptographic property = (i.e., how the 256-bit case operates).

The details on how the= nonce is used, show that AES256 is applied to 2 different blocks. But agai= n =E2=80=93 your description grasps the intention.

 

A comment (that was = asked / addressed in previous threads): AES256 used here is a permutation= invoked over 2 different blocks. So, a key search can ignore 256-bit keys= of the form =E2=80=9Cx || x=E2=80=9D (i.e., there are only 2^{256}-2^{128}= options). This is negligible.

 

Thanks, Shay

 
------ Original Message ------
From: "Blumenthal, Uri - 0553 - MITLL" <uri@ll.mit.edu>
To: "cfrg@irtf.org" <cfrg@irtf.org= >
Sent: 4/8/2016 6:49:22 AM
Subject: Re: [Cfrg] Adopting "AES-GCM-SIV: Nonce Misuse-Resistant Auth= enticated Encryption" as a CFRG document ---- Some clarifications
 
OK, let me explain: 
. . . . . . 
The "256-bit" case, is covered in my previous explanation,= basically:  

AES256 (NONCE[127:1] || 0) || AES256 (NONCE[127:1] || 1) =  (using the 256-bit key, and producing 256 bits altogether).

Another way to explain it =E2=80=93 you run AES256 as a PRF to generat= e 256 pseudo-random bits with it, and take those 256 bits as a record key= for AES256.

(Sounds solid to me.)


<= /HTML> --------=_MB075A6B1E-12D2-4C95-80A2-F6959938E579-- From nobody Sun Apr 10 07:59:07 2016 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AED3312D16C for ; Sun, 10 Apr 2016 07:59:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.4 X-Spam-Level: X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9M7iiENSoPuI for ; Sun, 10 Apr 2016 07:59:04 -0700 (PDT) Received: from mail-lf0-x231.google.com (mail-lf0-x231.google.com [IPv6:2a00:1450:4010:c07::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F231C12D1A5 for ; Sun, 10 Apr 2016 07:59:03 -0700 (PDT) Received: by mail-lf0-x231.google.com with SMTP id j11so127237243lfb.1 for ; Sun, 10 Apr 2016 07:59:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to; bh=h2D29Rb2Q1v7K8ziJFFgLDzcBVY1MYwH5mIfVOoyZbE=; b=SpkKhoaNxBfbCrEiIGHIeDMaZaKY+wxlpTXm1/1niDlr3NLAofTwWAQH3SE7fcCUrY 1x3KcGWxVrNurePnrvX1I4e05vZwULSk4YHsUKkdWvQRPfwpoQFl7Fk/P3HM4/HSDfL5 R2XLCoalAV3sywCQFrsH3CVN9e3kRo4drzZnM9SziFplyya5G6vr+j/SoPhUxBsDLEwQ tTAa8y974VYGoodmL5uncQpkTFYFxBpu6ZA58JoSatrfiZciZ3VjtrC/xHQVGoiNoRat kJewryC23tol3sVSmk3tx01P+t3AtvLRUT0Bmq7xxgYF/4y1mtwpzOTNbfyJ0NziPSI3 p9/w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:date:message-id:subject:from :to; bh=h2D29Rb2Q1v7K8ziJFFgLDzcBVY1MYwH5mIfVOoyZbE=; b=KUQti/2GQipsRQ+be+9N732Yu+59NarBNkZ0aJuNM/sA2EP6jMspt18iLGQ6CLsCCF 6L+FDcgYJRcQt3RZdIUnrl+iqNKX9aoozuiyTAq8jTkjY9Dn+SJ5Og1qIC6gaRyiNAAu hqGm7H4rpesYEvmSFcHAU0h2KIjW/tS9bFDnzPPnCnDnPR8Dex6V+WjReiWY2p4t9Dv8 MxAMkyHClVMBYgUd8mIkQOy6yb+v/3ERVTQw3Qn1lp9qTbIqUQQHwg3vR0/88+8FDchc tfw0inFjoZYRmLaC8sGtaq68HGHMRIU3MgbgbnO0OwvUeY3W0nZXvjD0WGqV4FDcqAtJ hqqQ== X-Gm-Message-State: AD7BkJIOB90FIFum9hyJIPDkVhrCWhvRP8jPzTS+Y3yE08Rl3oNZXj/oaSD+aU6vK3ZnMQEtzKuSaUglWsPZlg== MIME-Version: 1.0 X-Received: by 10.25.37.136 with SMTP id l130mr6854344lfl.153.1460300342122; Sun, 10 Apr 2016 07:59:02 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.112.151.67 with HTTP; Sun, 10 Apr 2016 07:59:02 -0700 (PDT) Date: Sun, 10 Apr 2016 11:59:02 -0300 X-Google-Sender-Auth: foZHkgMleQPIlWrtxSJQ1PAKZis Message-ID: From: Phillip Hallam-Baker To: "cfrg@irtf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [Cfrg] A big, big Elliptic Curve X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Apr 2016 14:59:06 -0000 Following our discussion on QC hardening. Among the range of responses, perhaps we should consider an Elliptic Curve with a QC difficulty comparable to that of RSA. As mentioned in the meeting, QC attacks don't use the same algorithms as conventional attacks and so the difficulty of breaking Curve 25519 is considerably less than breaking RSA2048. Interpreting the NSA advice is error prone. But the straight reading would be 'we think it more likely that a quantum computer will be built that can break current ECC schemes before someone works out how to break RSA 3096. So maybe what we need is Curve2048 or Curve3096, just to be sure. It would be slow of course. But it could be useful. From nobody Sun Apr 10 10:12:42 2016 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D47A12B044 for ; Sun, 10 Apr 2016 10:12:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.02 X-Spam-Level: X-Spam-Status: No, score=-1.02 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RDNS_DYNAMIC=0.982, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=shiftleft.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kmWtCx6UK5kk for ; Sun, 10 Apr 2016 10:12:40 -0700 (PDT) Received: from astral.shiftleft.org (192-195-80-246.PUBLIC.monkeybrains.net [192.195.80.246]) by ietfa.amsl.com (Postfix) with ESMTP id 5835112B041 for ; Sun, 10 Apr 2016 10:12:40 -0700 (PDT) Received: from [192.168.1.114] (unknown [192.168.1.1]) (Authenticated sender: mike) by astral.shiftleft.org (Postfix) with ESMTPSA id C5E509FFA8; Sun, 10 Apr 2016 10:12:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=shiftleft.org; s=sldo; t=1460308359; bh=LQE8aVsG59FCjGVmGTZkEh6o7xqS+aJzsD4Yy7x2D3I=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=AtuF6t+t/MtbpXrnba7a0x1STgUqhmyFNhJq+zstFmRPQYSRIcbC5ROwTdgRnIf/i It1F8htGafOrc/eDe9HbnGg4Wq7nFCBDV9N3fyTs5s31jJUYJGzJ3Rp+/pwddXhFTT R0g+OlvdF+uzQWK3bPYXAMfvP7IR1qTqudBT25FY= Content-Type: multipart/signed; boundary=Apple-Mail-63EF8944-6F5F-4D0A-A34B-26BF88B48FA5; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (1.0) From: Mike Hamburg X-Mailer: iPhone Mail (13E238) In-Reply-To: Date: Sun, 10 Apr 2016 10:12:39 -0700 Content-Transfer-Encoding: 7bit Message-Id: <858AE939-7119-49DA-A9C2-79B1DF5DC8BB@shiftleft.org> References: To: Phillip Hallam-Baker X-Virus-Scanned: clamav-milter 0.98.7 at astral X-Virus-Status: Clean Archived-At: Cc: "cfrg@irtf.org" Subject: Re: [Cfrg] A big, big Elliptic Curve X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Apr 2016 17:12:41 -0000 --Apple-Mail-63EF8944-6F5F-4D0A-A34B-26BF88B48FA5 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable At that point, wouldn't the multiplicative group of a prime field be a bette= r choice? Sent from my phone. Please excuse brevity and typos. > On Apr 10, 2016, at 07:59, Phillip Hallam-Baker wr= ote: >=20 > Following our discussion on QC hardening. Among the range of > responses, perhaps we should consider an Elliptic Curve with a QC > difficulty comparable to that of RSA. >=20 > As mentioned in the meeting, QC attacks don't use the same algorithms > as conventional attacks and so the difficulty of breaking Curve 25519 > is considerably less than breaking RSA2048. >=20 > Interpreting the NSA advice is error prone. But the straight reading > would be 'we think it more likely that a quantum computer will be > built that can break current ECC schemes before someone works out how > to break RSA 3096. >=20 > So maybe what we need is Curve2048 or Curve3096, just to be sure. It > would be slow of course. But it could be useful. >=20 > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > https://www.irtf.org/mailman/listinfo/cfrg --Apple-Mail-63EF8944-6F5F-4D0A-A34B-26BF88B48FA5 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGKDCCBiQw ggUMoAMCAQICAw45CjANBgkqhkiG9w0BAQsFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0 YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENB MB4XDTE1MDUzMTA1NDAwOVoXDTE2MDUzMTEyNDE0MVowQDEbMBkGA1UEAwwSbWlrZUBzaGlmdGxl ZnQub3JnMSEwHwYJKoZIhvcNAQkBFhJtaWtlQHNoaWZ0bGVmdC5vcmcwggEiMA0GCSqGSIb3DQEB AQUAA4IBDwAwggEKAoIBAQDId3vnJ+7/Br823rQFHCOgBLEI0U18zhqkw6S1fnY58xvPOLrmZ+WD +YN2//4QSRD9Ub3N7eegXMDXEGLVnfBpIXi9V3gUYyjpSQk1Wq3uaVVY4rTRwL1TOlMUkHB5pPhb DG1fQwrmcvjypqy/xZUSv3WDR5Qa26+VnjS240edIbZm4pPxshdAv+MyKpk6FY338wMl4lCneR12 pWX56Q0FIPNB3Y9NsYs4WmYSlOZDWLlAVnRCTz5szyTmttMi4ohEt37z5YKOinE1dPBx389vlbyB 1jucz928ogqoMGlmNgs1mjpdxL5TtJMFO2+7hRX/wuge/zvTdXxt1O1/kmRTAgMBAAGjggLYMIIC 1DAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQw HQYDVR0OBBYEFLIEcKRUYIF9pgcRGXfA4nz3JJKXMB8GA1UdIwQYMBaAFFNy7ZKc4NrLAVx8fpY1 TvLUuFGCMB0GA1UdEQQWMBSBEm1pa2VAc2hpZnRsZWZ0Lm9yZzCCAUwGA1UdIASCAUMwggE/MIIB OwYLKwYBBAGBtTcBAgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9w b2xpY3kucGRmMIH3BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhv cml0eTADAgEBGoG+VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUg Q2xhc3MgMSBWYWxpZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5 LCByZWxpYW5jZSBvbmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9m IHRoZSByZWx5aW5nIHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8v Y3JsLnN0YXJ0c3NsLmNvbS9jcnR1MS1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUF BzABhi1odHRwOi8vb2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMS9jbGllbnQvY2EwQgYIKwYB BQUHMAKGNmh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczEuY2xpZW50LmNh LmNydDAjBgNVHRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQELBQAD ggEBAJ0SlqTH81w2RcsWNq3v5mSG7n5SADOuYwndB8ycB6xm/1TW14pSmxhQreHghg1X+LAVwhyh TONFUkbBLnsF7H3IrgCFQGGSSqL8GN1vRtLQjWq/6E3XjePPlfRoWVPgSBrRo6a3SL9O7G3v9yeY 1cNB+TzJqat/v4rNcO8JOcPAw55RP3Am3apg+Um6KJdpVKB0djHw1FSGckmJBPcFr2bDfmb0ov9c 98cRSO7AZLeuxtfOKckLwLX8qH+ueo37bDrxUCaGeTNQ3VTgY2UeeCFEnSaQxRQ1MsYWay8BH9C5 NRJB7HzR/qfVq8Hn1pgUQvylRQ6pdY24UdHLJGM11GkxggNvMIIDawIBATCBlDCBjDELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENl cnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRl cm1lZGlhdGUgQ2xpZW50IENBAgMOOQowCQYFKw4DAhoFAKCCAa8wGAYJKoZIhvcNAQkDMQsGCSqG SIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTYwNDEwMTcxMjM5WjAjBgkqhkiG9w0BCQQxFgQU85Mu fJklMXDwv5R0SF3DJ/Ym0qcwgaUGCSsGAQQBgjcQBDGBlzCBlDCBjDELMAkGA1UEBhMCSUwxFjAU BgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRl IFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUg Q2xpZW50IENBAgMOOQowgacGCyqGSIb3DQEJEAILMYGXoIGUMIGMMQswCQYDVQQGEwJJTDEWMBQG A1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUg U2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBD bGllbnQgQ0ECAw45CjANBgkqhkiG9w0BAQEFAASCAQDDxGOBduROmGb5jprSQxLZOFR6qaVGnyxn Nyy8prVsXmwVJjn2FsZbFdpjH0/bmr3OWbbIo5K1p5zyNmjXh/xGYEjFn6IWiARgC3ylYT5CySQY 6v0PU5QiogNSOga0vNHakNZumQ3Bb/SvKIsVmA5lG9VziLjVM86yT4a0aQXy6l4vninonfwglX7M nvlbin22gMZe1Dy6HFNOkzjinoA3NBs8C8boLGrmmX6QkAwwT6ISqRCCeQWeHls5n/4O+caCqYin GU+yWcoCZtvIU/gV9J2ChTUD2+oyrkfqOlK8+8yFUMhGrLiCe3lutFmfZZtrfCT1NNciB77pfmkI ayfIAAAAAAAA --Apple-Mail-63EF8944-6F5F-4D0A-A34B-26BF88B48FA5-- From nobody Sun Apr 10 10:31:55 2016 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2ECB12D61C for ; Sun, 10 Apr 2016 10:31:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.896 X-Spam-Level: X-Spam-Status: No, score=-2.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.996] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4c_ip35CwKGB for ; Sun, 10 Apr 2016 10:31:51 -0700 (PDT) Received: from welho-filter1.welho.com (welho-filter1.welho.com [83.102.41.23]) by ietfa.amsl.com (Postfix) with ESMTP id B8FCA12D095 for ; Sun, 10 Apr 2016 10:31:51 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter1.welho.com (Postfix) with ESMTP id 548543550; Sun, 10 Apr 2016 20:31:50 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp1.welho.com ([IPv6:::ffff:83.102.41.84]) by localhost (welho-filter1.welho.com [::ffff:83.102.41.23]) (amavisd-new, port 10024) with ESMTP id RZAiZtoEiRmz; Sun, 10 Apr 2016 20:31:50 +0300 (EEST) Received: from LK-Perkele-V2 (87-100-143-35.bb.dnainternet.fi [87.100.143.35]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp1.welho.com (Postfix) with ESMTPSA id 04F4D27F; Sun, 10 Apr 2016 20:31:50 +0300 (EEST) Date: Sun, 10 Apr 2016 20:31:48 +0300 From: Ilari Liusvaara To: Mike Hamburg Message-ID: <20160410173148.GA8578@LK-Perkele-V2.elisa-laajakaista.fi> References: <858AE939-7119-49DA-A9C2-79B1DF5DC8BB@shiftleft.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <858AE939-7119-49DA-A9C2-79B1DF5DC8BB@shiftleft.org> User-Agent: Mutt/1.5.24 (2015-08-30) Sender: ilariliusvaara@welho.com Archived-At: Cc: "cfrg@irtf.org" Subject: Re: [Cfrg] A big, big Elliptic Curve X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Apr 2016 17:31:54 -0000 On Sun, Apr 10, 2016 at 10:12:39AM -0700, Mike Hamburg wrote: > > > On Apr 10, 2016, at 07:59, Phillip Hallam-Baker wrote: > > > > Following our discussion on QC hardening. Among the range of > > responses, perhaps we should consider an Elliptic Curve with a QC > > difficulty comparable to that of RSA. > > > > Interpreting the NSA advice is error prone. But the straight reading > > would be 'we think it more likely that a quantum computer will be > > built that can break current ECC schemes before someone works out how > > to break RSA 3096. My interpretation of NSA position & announcements is: - QC is coming sufficently soon (and here "soon" can mean 30 years or so) that there is no point in transitioning to ECC anymore. - NSA thinks that multiplicative-DH is significantly harder than what "open literature" considers. > > So maybe what we need is Curve2048 or Curve3096, just to be sure. It > > would be slow of course. But it could be useful. > > At that point, wouldn't the multiplicative group of a prime field be a better choice? Yes, I think that if you want maximum speed for given qbit bound, multiplicative groups are faster than ECC. However, once one has gotten to the point where QC of hundreds of fully-coupled gbits can be built, things are looking _very_ dire, for both. -Ilari From nobody Sun Apr 10 10:43:06 2016 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D496A12B052 for ; Sun, 10 Apr 2016 10:43:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.297 X-Spam-Level: X-Spam-Status: No, score=-5.297 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RVsOR4c6kraD for ; Sun, 10 Apr 2016 10:43:03 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 70E9F12B04E for ; Sun, 10 Apr 2016 10:43:03 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 039CEBE2D; Sun, 10 Apr 2016 18:43:02 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6uGRX7JCUhYm; Sun, 10 Apr 2016 18:43:00 +0100 (IST) Received: from [10.87.49.100] (unknown [86.46.23.241]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 1AF76BDF9; Sun, 10 Apr 2016 18:43:00 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1460310180; bh=ktBR2ZcLWbinXI+lBaadMjjqCTzmaidscVu2bb34U8U=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=UDNNxxblhyUqplxYa8PrKJ6DMS65ONBhbn+I7uyo9BSaNyVj36u0iDHWzKwhHgE+L cFBnOrgB8ItIBZ7RIIdt1lvTFF17fo65g4okF4AZXJtUrBjkcCe4/QvIQxRAqcuOED xdFVrNophZiJiwaACkf7q4id/mu4FE8z5uXcEuBY= To: Ilari Liusvaara , Mike Hamburg References: <858AE939-7119-49DA-A9C2-79B1DF5DC8BB@shiftleft.org> <20160410173148.GA8578@LK-Perkele-V2.elisa-laajakaista.fi> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <570A90A3.5010607@cs.tcd.ie> Date: Sun, 10 Apr 2016 18:42:59 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <20160410173148.GA8578@LK-Perkele-V2.elisa-laajakaista.fi> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms060400000302090409010106" Archived-At: Cc: "cfrg@irtf.org" Subject: Re: [Cfrg] A big, big Elliptic Curve X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Apr 2016 17:43:05 -0000 This is a cryptographically signed message in MIME format. --------------ms060400000302090409010106 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 10/04/16 18:31, Ilari Liusvaara wrote: > My interpretation of NSA position & announcements is: > - QC is coming sufficently soon (and here "soon" can mean 30 years or > so) that there is no point in transitioning to ECC anymore. > - NSA thinks that multiplicative-DH is significantly harder than what > "open literature" considers. >=20 That seems like a reasonable interpretation if one takes what they say at face value. I'm not comfortable doing that to be honest. I remain concerned that a part of this could be an attempt to discourage deployment of current crypto by focusing attention on the next shiny thing (pq crypto). I do think we should be doing preparatory work on pq crypto, but I am frankly uneasy to see people seemingly believing what the NSA assert with no real evidence offered. These after all are the same people (or indistinguishable from the people) who were happy to try pull a fast one on another part of their own government (I mean NIST/dual-ec). I think the very least they need to do is to offer evidence if they expect to be believed about anything non-obvious. The solution to this quandry I think is for us to base decisions on whatever openly available evidence we have, but on nothing else. (So we ought not IMO factor in press-releases from anyone.) And yes, if we don't have that evidence, that does create a danger that we ignore qc risks more than we ought. The blame for that however lies clearly with those who muddied the waters. Cheers, S. --------------ms060400000302090409010106 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CvIwggUIMIID8KADAgECAhBPzaE7pzYviUJyhmHTFBdnMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwMjA5MDkyODE1WhcNMTcwMjA5MDkyODE1WjBOMSIwIAYDVQQDDBlzdGVw aGVuLmZhcnJlbGxAY3MudGNkLmllMSgwJgYJKoZIhvcNAQkBFhlzdGVwaGVuLmZhcnJlbGxA Y3MudGNkLmllMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuC0rYze/2JinSra C9F2RjGdQZjNALLcW9C3WKTwYII3wBslobmHuPEYE5JaGItmzuKnAW619R1rD/kfoNWC19N3 rBZ6UX9Cmb9D9exCwYIwVuSwjrCQWGxgCtNQTrwKzCCpI790GRiMTvxvO7UmzmBrCaBLiZW5 R0fBjK5Yn6hUhAzGBkNbkIEL28cLJqH0yVz7Kl92OlzrQqTPEts5m6cDnNdY/ADfeAX18c1r dxZqcAxhLotrCqgsVA4ilbQDMMXGTLlB5TP35HeWZuGBU7xu003rLcFLdOkD8xvpJoYZy9Kt 3oABXPS5yqtMK+XCNdqmMn+4mOtLwQSMmPCSiQIDAQABo4IBuTCCAbUwCwYDVR0PBAQDAgSw MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQJ QhvwQ5Fl372Z6xqo6fdn8XejTTAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBv BggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5 BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEu Y3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGll bnQxLmNybDAkBgNVHREEHTAbgRlzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllMCMGA1UdEgQc MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIE MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG 9w0BAQsFAAOCAQEArzrSv2C8PlBBmGuiGrzm2Wma46/KHtXmZYS0bsd43pM66Pc/MsqPE0HD C1GzMFfwB6BfkJn8ijNSIhlgj898WzjvnpM/SO8KStjlB8719ig/xKISrOl5mX55XbFlQtX9 U6MrqRgbDIATxhD9IDr+ryvovDzChqgQj7mt2jYr4mdlRjsjod3H1VY6XglRmaaNGZfsCARM aE/TU5SXIiqauwt5KxNGYAY67QkOBs7O1FkSXpTk7+1MmzJMF4nP8QQ5n8vhVNseF+/Wm7ai 9mtnrkLbaznMsy/ULo/C2yuLUWTbZZbf4EKNmVdme6tUDgYkFjAFOblfA7W1fSPiQGagYzCC BeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmv mCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnm VkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4 D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PI dopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuu N0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUE FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzAp MCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEE WjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKG JGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+ SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0g BDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY 0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpF NjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9 uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p 6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOv Z3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOu mZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7 RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO /ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsN JQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPM MIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDEgQ2xpZW50IENBAhBPzaE7pzYviUJyhmHTFBdnMA0GCWCGSAFlAwQCAQUA oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjA0MTAx NzQyNTlaMC8GCSqGSIb3DQEJBDEiBCBHAUajKT+OIXN9jw/pxgwVTE26ZtDkeJu3QkuQKQ8K QjBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq hkiG9w0BAQEFAASCAQAGfrhzOtKzue8/tnYTUjYqUhlMJAzu9vtBZIQuHTIwXPRd1iQ/YU8N unvVj/GpeVi8ZXOQ44yU6645uX2e+41HSBGDchIXNAVWBEO8LEetPEgv6rs1FR8KKZPkqTle l0qW4UO7aZOwqEclmrE98mCah/gHZsGVLTA93lKDxjAWlOp2EsU4zdbApMg4o9UaQEoxCTXc d3yTU1TeRgrn03EFsbxnJsvcOYkePnKbGs0J9C+Gi7fsN6WnmnhtoBAdib+pbCphXnaNDXQY fyFtvthyf6H9nNCYMhzRrIKndtdtPpf+rbjDZWqSt3TnGiyXEHl9Nj7OKPQSfIr/osZUiSxP AAAAAAAA --------------ms060400000302090409010106-- From nobody Sun Apr 10 10:55:56 2016 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EFA212B04E for ; Sun, 10 Apr 2016 10:55:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.194 X-Spam-Level: X-Spam-Status: No, score=-5.194 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.996, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p1_oJzi9JE1m for ; Sun, 10 Apr 2016 10:55:51 -0700 (PDT) Received: from llmx2.ll.mit.edu (LLMX2.LL.MIT.EDU [129.55.12.48]) by ietfa.amsl.com (Postfix) with ESMTP id 3928212B043 for ; Sun, 10 Apr 2016 10:55:50 -0700 (PDT) Received: from LLE2K10-HUB02.mitll.ad.local (LLE2K10-HUB02.mitll.ad.local) by llmx2.ll.mit.edu (unknown) with ESMTP id u3AHsVJI000543; Sun, 10 Apr 2016 13:54:31 -0400 From: "Blumenthal, Uri - 0553 - MITLL" To: "Gueron, Shay" Thread-Topic: Re[2]: [Cfrg] Adopting "AES-GCM-SIV: Nonce Misuse-Resistant Authenticated Encryption" as a CFRG document ---- Some clarifications Thread-Index: AdGTUjYQcBDJFfpWREmYbD5sdatNiw== Date: Sun, 10 Apr 2016 17:55:48 +0000 Message-ID: <20160410175556.18280531.28306.62607@ll.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="===============1516255697==" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-04-10_11:, , signatures=0 X-Proofpoint-Spam-Details: rule=inbound_notspam policy=inbound score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1603180000 definitions=main-1604100268 Archived-At: Cc: "cfrg@irtf.org" Subject: Re: [Cfrg] Adopting "AES-GCM-SIV: Nonce Misuse-Resistant Authenticated Encryption" as a CFRG document ---- Some clarifications X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Apr 2016 17:55:53 -0000 --===============1516255697== Content-Type: multipart/alternative; boundary="===============1656538972==" MIME-Version: 1.0 --===============1656538972== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 SWYgaXQgd2FzIG9ubHkgdGhlIG5hdGl2ZSBNYWMgT1MgWCBhc3NlbWJsZXIgKHdob3NlIEdBUyBp cyBrbm93biB0byBiZSBtdWNoIGJlaGluZCB0aGUgc3RhbmRhcmQpIGl0IHdvdWxkbid0IGJlIHNv IGJhZC4KCkJ1dCBhcyBJIHNhaWQgLSBJJ3ZlIHRyaWVkIG1vc3QgZXZlcnkgb3RoZXIgYXNzZW1i bGVyLCBpbmNsdWRpbmcgdGhlICJhbGwtcG93ZXJmdWwiIFlBU00gdGhhdCB1c3VhbGx5IGNhbiBw cm9jZXNzIHdoYXRldmVyIEkgdGhyb3cgYXQgaXQuIFlBU00gZmFpbGVkIGFzIHdlbGwuCgpJJ2Qg YXBwcmVjaWF0ZSBpZiB5b3UgY291bGQgcmVsZWFzZSBhICJtb3JlIHBvcnRhYmxlIiBoYW5kLXR1 bmVkIHZlcnNpb24gdGhhdCBjb3VsZCBjb21waWxlLCBlLmcuLCB1bmRlciBZYXNtLTEuMy4wICh0 aGUgY3VycmVudCBzdGFibGUgdmVyc2lvbikuCgpDIGludHJpbnNpY3Mgd291bGQgYWxzbyBiZSBn cmVhdCAtIGJ1dCBob3BlZnVsbHkgbm90IGF0IHRoZSBjb3N0IG9mIGhhbmQtdHVuZWQgY29kZS4K ClRoYW5rcyEKClNlbnTCoGZyb23CoG15wqBCbGFja0JlcnJ5wqAxMMKgc21hcnRwaG9uZcKgb27C oHRoZSBWZXJpem9uwqBXaXJlbGVzc8KgNEfCoExURcKgbmV0d29yay4KRnJvbTogR3Vlcm9uLCBT aGF5ClNlbnQ6IFN1bmRheSwgQXByaWwgMTAsIDIwMTYgMDk6MzkKVG86IEJsdW1lbnRoYWwsIFVy aSAtIDA1NTMgLSBNSVRMTDsgQWRhbSBMYW5nbGV5OyBBbmR5IEx1dG9taXJza2kKUmVwbHkgVG86 IEd1ZXJvbiwgU2hheQpDYzogWWVodWRhIExpbmRlbGw7IGNmcmdAaXJ0Zi5vcmc7IEFkYW0gTGFu Z2xleTsgU2hheSBHdWVyb24KU3ViamVjdDogUmVbMl06IFtDZnJnXSBBZG9wdGluZyAiQUVTLUdD TS1TSVY6IE5vbmNlIE1pc3VzZS1SZXNpc3RhbnQgQXV0aGVudGljYXRlZCBFbmNyeXB0aW9uIiBh cyBhIENGUkcgZG9jdW1lbnQgLS0tLSBTb21lIGNsYXJpZmljYXRpb25zCgrCoAo+Pj4gQlRXLCB3 aGF0IGFzc2VtYmxlciBpcyB0aGUgb3B0aW1pemVkIGNvZGUgc3VwcG9zZWQgdG8gd29yayB3aXRo PwoKVGhlIGNvZGUgdGhhdCBpcyBjdXJyZW50bHkgcG9zdGVkIHdhcyBjb21waWxlZCBhbmQgdGVz dGVkIHVuZGVyIFJlZCBIYXQgTGludXgsIEZlZG9yYSByZWxlYXNlIDIzLCB1c2luZyBHQ0MgNC44 LjIgJiBHTlUgYXNzZW1ibHkgdmVyc2lvbiAyLjI1LgrCoApNQUMgT1MgZG9lcyBub3QgZWFzaWx5 IGNoZXcgdGhpcyBhc3NlbWJsZXIgc3ludGF4LCBhbmQgc29tZSB3b3JrIG5lZWRzIHRvIGJlIGRv bmUgYXJvdW5kIGl0LiBIb3dldmVyLCBJIHdpbGwgc29vbiBwb3N0IGEgQyAoaW50cmluc2ljcykg dmVyc2lvbiBvZiB0aGUgY29kZSwgdGhhdCBzaG91bGQgY29tcGlsZSBvbiBhbGwgcGxhdGZvcm1z IChvZiBjb3Vyc2UsIGF0IHRoZSBjb3N0IG9mIGdpdmluZyB1cCBzb21lIHBlcmZvcm1hbmNlIHRo YXQgaGFuZCB0dW5lZCBhc3NlbWJsZXIgYWNoaWV2ZXMpLgrCoApSZWdhcmRzLCBTaGF5CsKgCsKg CsKgCsKgCsKgCsKgCsKgCsKgCsKgCsKgCsKgCgrCoAoKwqAKwqAKLS0tLS0tIE9yaWdpbmFsIE1l c3NhZ2UgLS0tLS0tCkZyb206ICJCbHVtZW50aGFsLCBVcmkgLSAwNTUzIC0gTUlUTEwiIDx1cmlA bGwubWl0LmVkdT4KVG86ICJBZGFtIExhbmdsZXkiIDxhZ2xAaW1wZXJpYWx2aW9sZXQub3JnPjsg IkFuZHkgTHV0b21pcnNraSIgPGx1dG9AYW1hY2FwaXRhbC5uZXQ+CkNjOiAiWWVodWRhIExpbmRl bGwiIDx5ZWh1ZGEubGluZGVsbEBiaXUuYWMuaWw+OyAiY2ZyZ0BpcnRmLm9yZyIgPGNmcmdAaXJ0 Zi5vcmc+OyAiQWRhbSBMYW5nbGV5IiA8YWdsQGdvb2dsZS5jb20+ClNlbnQ6IDQvOC8yMDE2IDU6 NDA6MjcgQU0KU3ViamVjdDogUmU6IFtDZnJnXSBBZG9wdGluZyAiQUVTLUdDTS1TSVY6IE5vbmNl IE1pc3VzZS1SZXNpc3RhbnQgQXV0aGVudGljYXRlZCBFbmNyeXB0aW9uIiBhcyBhIENGUkcgZG9j dW1lbnQgLS0tLSBTb21lIGNsYXJpZmljYXRpb25zCsKgCkJUVywgd2hhdCBhc3NlbWJsZXIgaXMg dGhlIG9wdGltaXplZCBjb2RlIHN1cHBvc2VkIHRvIHdvcmsgd2l0aD8KwqAKSSdtIG9uIE1hYyBP U1ggKDEwLjEwLjUgYW5kIDEwLjExLjQpIHVzaW5nIFhjb2RlIDcuMi4xIGFuZCA3LjMgY29ycmVz cG9uZGluZ2x5LiBCb3RoIHN5c3RlbXMgYWxzbyBoYXZlIGdjYy01LjMgYW5kIGNsYW5nLTMuNy4g SSBhbHNvIHTigI5yaWVkIG5hc20sIHlhc20uIE5vdGhpbmcgd29ya3MuIFdvdWxkIGxpa2Ugc29t ZSBndWlkYW5jZS7CoArCoApTZW50wqBmcm9twqBtecKgQmxhY2tCZXJyecKgMTDCoHNtYXJ0cGhv bmXCoG9uwqB0aGUgVmVyaXpvbsKgV2lyZWxlc3PCoDRHwqBMVEXCoG5ldHdvcmsuCsKgwqBPcmln aW5hbCBNZXNzYWdlIMKgCkZyb206IEFkYW0gTGFuZ2xleQpTZW50OiBUaHVyc2RheSwgQXByaWwg NywgMjAxNiAxOTo1NQpUbzogQW5keSBMdXRvbWlyc2tpCkNjOiBZZWh1ZGEgTGluZGVsbDsgY2Zy Z0BpcnRmLm9yZzsgQWRhbSBMYW5nbGV5ClN1YmplY3Q6IFJlOiBbQ2ZyZ10gQWRvcHRpbmcgIkFF Uy1HQ00tU0lWOiBOb25jZSBNaXN1c2UtUmVzaXN0YW50IEF1dGhlbnRpY2F0ZWQgRW5jcnlwdGlv biIgYXMgYSBDRlJHIGRvY3VtZW50IC0tLS0gU29tZSBjbGFyaWZpY2F0aW9ucwrCoApPbiBGcmks IEFwciA4LCAyMDE2IGF0IDg6MTYgQU0sIEFuZHkgTHV0b21pcnNraSA8bHV0b0BhbWFjYXBpdGFs Lm5ldD4gd3JvdGU6CsKgQ2FuIHlvdSBjbGFyaWZ5IHRoZSBkcmFmdD8KwqAKV2lsbCBkbyBhcyBz b29uIGFzIEknbSBhYmxlICh3aGljaCBzaG91bGQgYmUgbmV4dCB3ZWVrKS4KwqAKwqAKQ2hlZXJz CsKgCkFHTArCoAotLQpBZGFtIExhbmdsZXkgYWdsQGltcGVyaWFsdmlvbGV0Lm9yZyBodHRwczov L3d3dy5pbXBlcmlhbHZpb2xldC5vcmcKwqAKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18KQ2ZyZyBtYWlsaW5nIGxpc3QKQ2ZyZ0BpcnRmLm9yZwpodHRwczov L3d3dy5pcnRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2NmcmcKwqAKCg== --===============1656538972== Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable =
If it was only the native Mac OS X assembler (whose = GAS is known to be much behind the standard) it wouldn't be so bad.

But as I said - I've tried most every other assembler, inclu= ding the "all-powerful" YASM that usually can process whatever I throw at i= t. YASM failed as well.

<= /div>
I'd appreciate if you could r= elease a "more portable" hand-tuned version that could compile, e.g., under= Yasm-1.3.0 (the current stable version).

C intrinsic= s would also be great - but hopefully not at the cost of hand-tuned code.

Thanks!
= =

= =
Sent from my BlackBerry 10 smart= phone on the Verizon Wireless 4G LTE net= work.
= =
From: Gueron, Shay
Sent: Sunday, Apr= il 10, 2016 09:39
To: Blumenthal, Uri - 0553 - MITLL; Adam= Langley; Andy Lutomirski
Reply To: Gueron, Shay
Cc: Yehuda Lindell; cfrg@irtf.org; Adam Langley; Shay Gueron
<= div>Subject: Re[2]: [Cfrg] Adopting "AES-GCM-SIV: Nonce Misuse-Resis= tant Authenticated Encryption" as a CFRG document ---- Some clarifications<= /div>

 
>>> BTW, w= hat assembler is the optimized code supposed to work with?

The code that is currently posted was compiled and tested under Red Hat Lin= ux, Fedora release 23, using GCC 4.8.2 & GNU assembly version 2.25.
 
MAC OS does not easily chew this assembler syntax, and some work needs= to be done around it. However, I will soon post a C (intrinsics) version o= f the code, that should compile on all platforms (of course, at the cost of= giving up some performance that hand tuned assembler achieves).
 
Regards, Shay
 
 
 
 
 
 
 
 
 
 

 

 

 
 
------ Original Message ------
From: "Blumenthal, Uri - 0553 - MITLL" <uri@ll.mit.edu>
To: "Adam Langley" <agl@i= mperialviolet.org>; "Andy Lutomirski" <luto@amacapital.net>
Cc: "Yehuda Lindell" <y= ehuda.lindell@biu.ac.il>; "cfrg@irtf.org" <cfrg@irtf.org>; "Adam Langley" <agl@google.com>
Sent: 4/8/2016 5:40:27 AM
Subject: Re: [Cfrg] Adopting "AES-GCM-SIV: Nonce Misuse-Resistant Auth= enticated Encryption" as a CFRG document ---- Some clarifications
 
BTW, what assembler is the optimized code supposed to work with?
 
I'm on Mac OSX (10.10.5 and 10.11.4) using Xcode 7.2.1 and 7.3 corresp= ondingly. Both systems also have gcc-5.3 and clang-3.7. I also t=E2=80=8Eri= ed nasm, yasm. Nothing works. Would like some guidance. 
 
Sent from my BlackBerry 10 smartphone on=  the Verizon Wireless 4G LTE network.
  Original Message  
From: Adam Langley
Sent: Thursday, April 7, 2016 19:55
To: Andy Lutomirski
Cc: Yehuda Lindell; cfrg@irtf.org= ; Adam Langley
Subject: Re: [Cfrg] Adopting "AES-GCM-SIV: Nonce Misuse-Resistant Auth= enticated Encryption" as a CFRG document ---- Some clarifications
 
On Fri, Apr 8, 2016 at 8:16 AM, Andy Lutomirski <luto@amacapital.net> wrote:
 Can you clarify the draft?
 
Will do as soon as I'm able (which should be next week).
 
 
Cheers
 
AGL
 
--
 
_______________________________________________
Cfrg mailing list
 

--===============1656538972==-- --===============1516255697== Content-Type: application/x-pkcs7-signature; name="smime.p7s" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExDTALBglghkgBZQMEAgEwgAYJKoZIhvcNAQcBAACggg7NMIIE 6jCCA9KgAwIBAgIKMz1Y1wAAAABunjANBgkqhkiG9w0BAQsFADBRMQswCQYDVQQGEwJVUzEfMB0G A1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRM TCBDQS0zMB4XDTE2MDExNDE3MzU1MloXDTE5MDExMzE3MzU1MlowYTELMAkGA1UEBhMCVVMxHzAd BgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDzANBgNVBAsTBlBlb3BsZTEgMB4GA1UEAxMX Qmx1bWVudGhhbC5VcmkuNTAwMTA1ODQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCz HVEw2ojNZjWEnTASyJaQIvzziBmrH07FzMEY2xFGNDJpss38CcFRjfRx1EyEp7BrFdAXC2pHjFwa gFr+McYdXZiKEci0Mzna2uibsMDVbhlT6TwtmAL6QzdtjN28dn+7vQUkRUWUm9VVaBVVxUgX3f2l oEZsJNvWb7C8vj2DZF/uEt/EU/9KcUuodMgCR4zYLFVpNh1U6tCYACNDNtj/nmNjubtez1Y56zjZ AVOXZWsjNCPrC2jVwDdg1AIcs5ayDMOC2p1F95kSxWsJwinKfSe8p2/YR/cwUo8ljFoBPj60AGW3 WjaJyKXK+ZgJwjwl9gG/pg2T4mQhIAIZWZQ9AgMBAAGjggGyMIIBrjAdBgNVHQ4EFgQUtKJz3aEd G/MvxjE38EW6PHdcUDQwDgYDVR0PAQH/BAQDAgbAMB8GA1UdIwQYMBaAFNdgZg57SY11TA39z0be yMcSh8q/MDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXRjcmwvTExD QTMwZgYIKwYBBQUHAQEEWjBYMC0GCCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0 dG8vTExDQTMwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLmxsLm1pdC5lZHUvb2NzcDA9BgkrBgEE AYI3FQcEMDAuBiYrBgEEAYI3FQiDg+Udh+ynZoathxWD6vBFhbahHx2Fy94yh/+KcwIBZAIBBjAi BgNVHSUBAf8EGDAWBggrBgEFBQcDBAYKKwYBBAGCNwoDDDAYBgNVHSAEETAPMA0GCyqGSIb3EgIB AwEIMBkGA1UdEQQSMBCBDnVyaUBsbC5taXQuZWR1MCcGCSsGAQQBgjcUAgQaHhgATABMAFUAcwBl AHIAUwBpAGcALQBTAFcwDQYJKoZIhvcNAQELBQADggEBAJTu0/WcX0ebe9UfUMslvy9fC2aCQong cVcEKlEjU8IvCKa6YpZHQKTVXQ3e4KKvw1DgzFvq8/rOv87Woj45q8smgNyivgAMCnrT7a6B/9Kn 85l9BjeoLMPLypvsmz1l7oX45NPr3LF4VEMzxqczdovS14woPKdegEKQYyPSZGhKTCCe/9FhtgEc 3gfVyE1mH6ZNeDEalr7nx7F0qemhh3QN6i6XPrudzv9el5JeovPedZ0JqDT0ctXj6ECYOiEyEfJm 85C5QGmpjLmCM99gAmgpP5Tx6APB/tvcUw/mgt4HOvqavGkvUkoJ8XEEwt9AgXaznS626Kb8RpAh w2zN2yMwggTqMIID0qADAgECAgozPVjXAAAAAG6eMA0GCSqGSIb3DQEBCwUAMFExCzAJBgNVBAYT AlVTMR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxEzARBgNV BAMTCk1JVExMIENBLTMwHhcNMTYwMTE0MTczNTUyWhcNMTkwMTEzMTczNTUyWjBhMQswCQYDVQQG EwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEPMA0GA1UECxMGUGVvcGxlMSAw HgYDVQQDExdCbHVtZW50aGFsLlVyaS41MDAxMDU4NDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBALMdUTDaiM1mNYSdMBLIlpAi/POIGasfTsXMwRjbEUY0MmmyzfwJwVGN9HHUTISnsGsV 0BcLakeMXBqAWv4xxh1dmIoRyLQzOdra6JuwwNVuGVPpPC2YAvpDN22M3bx2f7u9BSRFRZSb1VVo FVXFSBfd/aWgRmwk29ZvsLy+PYNkX+4S38RT/0pxS6h0yAJHjNgsVWk2HVTq0JgAI0M22P+eY2O5 u17PVjnrONkBU5dlayM0I+sLaNXAN2DUAhyzlrIMw4LanUX3mRLFawnCKcp9J7ynb9hH9zBSjyWM WgE+PrQAZbdaNonIpcr5mAnCPCX2Ab+mDZPiZCEgAhlZlD0CAwEAAaOCAbIwggGuMB0GA1UdDgQW BBS0onPdoR0b8y/GMTfwRbo8d1xQNDAOBgNVHQ8BAf8EBAMCBsAwHwYDVR0jBBgwFoAU12BmDntJ jXVMDf3PRt7IxxKHyr8wMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC5sbC5taXQuZWR1L2dl dGNybC9MTENBMzBmBggrBgEFBQcBAQRaMFgwLQYIKwYBBQUHMAKGIWh0dHA6Ly9jcmwubGwubWl0 LmVkdS9nZXR0by9MTENBMzAnBggrBgEFBQcwAYYbaHR0cDovL29jc3AubGwubWl0LmVkdS9vY3Nw MD0GCSsGAQQBgjcVBwQwMC4GJisGAQQBgjcVCIOD5R2H7Kdmhq2HFYPq8EWFtqEfHYXL3jKH/4pz AgFkAgEGMCIGA1UdJQEB/wQYMBYGCCsGAQUFBwMEBgorBgEEAYI3CgMMMBgGA1UdIAQRMA8wDQYL KoZIhvcSAgEDAQgwGQYDVR0RBBIwEIEOdXJpQGxsLm1pdC5lZHUwJwYJKwYBBAGCNxQCBBoeGABM AEwAVQBzAGUAcgBTAGkAZwAtAFMAVzANBgkqhkiG9w0BAQsFAAOCAQEAlO7T9ZxfR5t71R9QyyW/ L18LZoJCieBxVwQqUSNTwi8IprpilkdApNVdDd7goq/DUODMW+rz+s6/ztaiPjmryyaA3KK+AAwK etPtroH/0qfzmX0GN6gsw8vKm+ybPWXuhfjk0+vcsXhUQzPGpzN2i9LXjCg8p16AQpBjI9JkaEpM IJ7/0WG2ARzeB9XITWYfpk14MRqWvufHsXSp6aGHdA3qLpc+u53O/16Xkl6i8951nQmoNPRy1ePo QJg6ITIR8mbzkLlAaamMuYIz32ACaCk/lPHoA8H+29xTD+aC3gc6+pq8aS9SSgnxcQTC30CBdrOd LrbopvxGkCHDbM3bIzCCBO0wggPVoAMCAQICCjM4lI8AAAAAbpYwDQYJKoZIhvcNAQELBQAwUTEL MAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsTA1BL STETMBEGA1UEAxMKTUlUTEwgQ0EtMzAeFw0xNjAxMTQxNzMwMzlaFw0xOTAxMTMxNzMwMzlaMGEx CzAJBgNVBAYTAlVTMR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQ8wDQYDVQQLEwZQ ZW9wbGUxIDAeBgNVBAMTF0JsdW1lbnRoYWwuVXJpLjUwMDEwNTg0MIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEA4xQ2hom9O5hwXTWlTDaY/fuIiWvivQHEzd8volNcoLbxxuHKLXgwX++2 TdbsHbfpaHVtAvF8huN7Lkn6Taf6MCzlBJRWoAJz6hwLwFCMLJeQI853KST/u/FIuLt+GjDbHXT/ kGbvRyNkIPj+njA9uY5I8m0/XUDMV2aTtqEwc55Vo2CCLXWYStQ1maiEdGre59mIwkkLGTV9JSeC cK7Yx2Ba2D552QtH9QdjO1eeCEvOtwhMn7uV6LaGcfGLh8GKSkhavNEhIenDAy3U3tWQI1sbJ28i guuK63krciNj1TfbgVnfjpXhqCAI1aIKTCiotKUkR3ArsA8BnpKUFbmyvQIDAQABo4IBtTCCAbEw HQYDVR0OBBYEFPFPxYiZomy2ZdvinDW1VhNj2YqbMA4GA1UdDwEB/wQEAwIFIDAfBgNVHSMEGDAW gBTXYGYOe0mNdUwN/c9G3sjHEofKvzAzBgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLmxsLm1p dC5lZHUvZ2V0Y3JsL0xMQ0EzMGYGCCsGAQUFBwEBBFowWDAtBggrBgEFBQcwAoYhaHR0cDovL2Ny bC5sbC5taXQuZWR1L2dldHRvL0xMQ0EzMCcGCCsGAQUFBzABhhtodHRwOi8vb2NzcC5sbC5taXQu ZWR1L29jc3AwPQYJKwYBBAGCNxUHBDAwLgYmKwYBBAGCNxUIg4PlHYfsp2aGrYcVg+rwRYW2oR8d hevQcIPr7SACAWQCAQUwJQYDVR0lBB4wHAYEVR0lAAYIKwYBBQUHAwQGCisGAQQBgjcKAwQwGAYD VR0gBBEwDzANBgsqhkiG9xICAQMBCDAZBgNVHREEEjAQgQ51cmlAbGwubWl0LmVkdTAnBgkrBgEE AYI3FAIEGh4YAEwATABVAHMAZQByAEUAbgBjAC0AUwBXMA0GCSqGSIb3DQEBCwUAA4IBAQAW7r7P ZtIEuVPCSblXPqrbVdgVkNIw3qV6WHz/8TfK1UnETx3tkjFGhR+TjEYYXhiZHaIFlTZzK4x8UH6X 3NM/MqLZQ98cFxDVlGOTKEJqRBgdpLBaoDHddtW6s0d1mPOC3KLH6MNDKKZV7PJrzu056M8DPj7R mbNJqadj8wZL1nTW7Nq/+8FyT+v6S3ecz78sETYU4KFXtWjeIryJFPLL5CjIIL+WWjrKJ2lvCUun VGJr75NELwyUSEDUUdM6UKTiqfuFf14TGUYcUCdw41U44fUP6RypuwERYRa90ACeqHAo8syxeYrL GtVbIcexJQSJNHF4XqepizC6hjV92swJMYIB8TCCAe0CAQEwXzBRMQswCQYDVQQGEwJVUzEfMB0G A1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRM TCBDQS0zAgozPVjXAAAAAG6eMAsGCWCGSAFlAwQCAaBpMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTE2MDQxMDE3NTU1NVowLwYJKoZIhvcNAQkEMSIEIAxZtkgYZtS+ +lFDofpToh9QT1uFijDTIPCtmtmwAACwMAsGCSqGSIb3DQEBCwSCAQBXXf+cPGkiJjgZ/C/HC2b0 IK2JzZ3DLznB5MLsPICAcgXLBDLwHKFuCJS/B1oM24PpxOvs/VD2r21GjYffTvO9ItzErh5KEyPQ aPy4lMgHrZY4dFsKLPKAvSj0bhctHqwzkwtWCnYUqfxtML9VnCW1IDFKQ5UX3vvRBi8buhPxhUOv nhlp97x9TAdDAHf35bz9W03HF8J9GGVKvwce2gnGKGTfHMzJ623zOMauSZlYk38Q7vKinCd2fYcp V3dk23Q/vY9JmtjvAsdUBu8pRAGFHQs9dlqkk74gIZpszHCBp89B5gSa7yiz+F1RhUCK9X+uJbJ5 RdhOcnTv9kl2ppzwAAAAAAAA --===============1516255697==-- From nobody Sun Apr 10 20:22:01 2016 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBB1512DB2D for ; Sun, 10 Apr 2016 20:21:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l4ews4ZaOjUg for ; Sun, 10 Apr 2016 20:21:58 -0700 (PDT) Received: from calvin.win.tue.nl (calvin.win.tue.nl [131.155.70.11]) by ietfa.amsl.com (Postfix) with SMTP id 918FB12DFF9 for ; Sun, 10 Apr 2016 20:21:57 -0700 (PDT) Received: (qmail 22928 invoked from network); 11 Apr 2016 03:22:20 -0000 Received: from ein.win.tue.nl (HELO hyperelliptic.org) (131.155.70.18) by calvin.win.tue.nl with SMTP; 11 Apr 2016 03:22:20 -0000 Received: (qmail 11524 invoked by uid 1004); 11 Apr 2016 03:22:20 -0000 Date: Mon, 11 Apr 2016 05:22:20 +0200 From: Tanja Lange To: Phillip Hallam-Baker Message-ID: <20160411032220.GB2556@ein.win.tue.nl> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: "cfrg@irtf.org" Subject: Re: [Cfrg] A big, big Elliptic Curve X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Apr 2016 03:22:00 -0000 > As mentioned in the meeting, QC attacks don't use the same algorithms > as conventional attacks and so the difficulty of breaking Curve 25519 > is considerably less than breaking RSA2048. > Could you point me to sources for this? There is an old paper by Proos and Zalka which has claims like this, but more recent work by Roetteler and Steinwandt properly considers reversibility and ends up taking longer (time & qubits) for a 160 bit curve than 1024 bit RSA. They did detailed work for binary curves and last I talked to them were looking into odd characteristic. The jury is still out for larger curves and larger RSA but between a 256-bit curve DLP and a 2048 RSA; I'd be surprised if RSA was harder. > Interpreting the NSA advice is error prone. But the straight reading > would be 'we think it more likely that a quantum computer will be > built that can break current ECC schemes before someone works out how > to break RSA 3096. > If I take them at face value they basically say: Don't complain if we ask you to upgrade to new crypto soon; here, as a concession you may continue using the old stuff as long as it is not super small. I'd rather not speculate about their intention and whether those are in our interest or not. Tanja From nobody Mon Apr 11 07:33:37 2016 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DCBB12EF96 for ; Mon, 11 Apr 2016 07:33:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.9 X-Spam-Level: X-Spam-Status: No, score=-0.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_NAME_DR=1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id No-hZQo9uDkM for ; Mon, 11 Apr 2016 07:33:34 -0700 (PDT) Received: from mail.katezarealty.com (cvps8815162906.hostwindsdns.com [104.168.158.213]) by ietfa.amsl.com (Postfix) with ESMTP id D342D12EF95 for ; Mon, 11 Apr 2016 07:33:33 -0700 (PDT) Received: from iMassi.local (unknown [63.88.3.14]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.katezarealty.com (Postfix) with ESMTPSA id DE82837423E7 for ; Mon, 11 Apr 2016 10:33:32 -0400 (EDT) To: cfrg@irtf.org From: "Dr. Pala" Organization: OpenCA Labs Message-ID: <570BB5BC.5000705@openca.org> Date: Mon, 11 Apr 2016 10:33:32 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------090402000908030405070503" Archived-At: Subject: [Cfrg] Quantum Computing and Crypto Policies X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Apr 2016 14:33:35 -0000 This is a multi-part message in MIME format. --------------090402000908030405070503 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Hi all, At the CFRG meeting, I have appreciated the presentation about QC in the sense that inspired to think about the future in a more practical way (although there was probably not much agreement on how to proceed forward). I have also been following the conversation about the post-quantum computing crypto resistance and I am trying to figure out - given what we know about possible quantum computing which, as Tim pointed out during the meeting, is still very little - what types of policies can be implemented today that would allow us to be a bit more resilient to attacks in the post quantum-computing environment (i.e., not being taken by surprise since deploying of new crypto can take several years in the real world despite the algorithm agility we have in current standards). I will try to summarize the two main points: 1. Symmetric crypto is still relatively secure. Using 256bits keys (e.g., AES 256) should provide enough confidentiality for the time being (this is already a common practice in the industry as the overhead compared to 128bits is negligible) - so we are relatively safe here. 2. Given the physical limitations when it comes to be able to have QC with high number of qbits, it seems that when it comes to Asymmetric crypto, ECDSA (given the limited number of bits and the impossibility to extend the number of bits without defining new curves) is the weakest choice compared to RSA with very long keys (e.g., 8K or 16K bits keys or even bigger...). In other words, given this scenario and setting aside considerations about signature sizes (although, we have seen an increase in computing resources in terms of processing power, bandwidth, and storage it seems that signature size is a big concern - AFAIK, mostly driven by IoT and similar environments - even more than 10yrs ago! and many WGs are using the size argument over the security argument in their specifications and suggestions), the more flexible and forward-secure choice would be to start using "oversized" RSA keys for asymmetric and for symmetric we can keep using AES 256 with relative confidence (assuming, as I said, that no new quantum-specific algorithms are discovered...) Does this summarizes the current situation? Are these (very simplistic) considerations correct? Anybody disagree with these statements? Why? Cheers, Max -- Massimiliano Pala, PhD Director at OpenCA Labs twitter: @openca --------------090402000908030405070503 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Hi all,

At the CFRG meeting, I have appreciated the presentation about QC in the sense that inspired to think about the future in a more practical way (although there was probably not much agreement on how to proceed forward).

I have also been following the conversation about the post-quantum computing crypto resistance and I am trying to figure out - given what we know about possible quantum computing which, as Tim pointed out during the meeting, is still very little - what types of policies can be implemented today that would allow us to be a bit more resilient to attacks in the post quantum-computing environment (i.e., not being taken by surprise since deploying of new crypto can take several years in the real world despite the algorithm agility we have in current standards). I will try to summarize the two main points:
  1. Symmetric crypto is still relatively secure. Using 256bits keys (e.g., AES 256) should provide enough confidentiality for the time being (this is already a common practice in the industry as the overhead compared to 128bits is negligible) - so we are relatively safe here.
  2. Given the physical limitations when it comes to be able to have QC with high number of qbits, it seems that when it comes to Asymmetric crypto, ECDSA (given the limited number of bits and the impossibility to extend the number of bits without defining new curves) is the weakest choice compared to RSA with very long keys (e.g., 8K or 16K bits keys or even bigger...).

In other words, given this scenario and setting aside considerations about signature sizes (although, we have seen an increase in computing resources in terms of processing power, bandwidth, and storage it seems that signature size is a big concern - AFAIK, mostly driven by IoT and similar environments - even more than 10yrs ago! and many WGs are using the size argument over the security argument in their specifications and suggestions), the more flexible and forward-secure choice would be to start using "oversized" RSA keys for asymmetric and for symmetric we can keep using AES 256 with relative confidence (assuming, as I said, that no new quantum-specific algorithms are discovered...)

Does this summarizes the current situation? Are these (very simplistic) considerations correct? Anybody disagree with these statements? Why?

Cheers,
Max
 

-- 
Massimiliano Pala, PhD
Director at OpenCA Labs
twitter: @openca
--------------090402000908030405070503-- From nobody Mon Apr 11 08:14:10 2016 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F45512F021 for ; Mon, 11 Apr 2016 08:14:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.196 X-Spam-Level: X-Spam-Status: No, score=-5.196 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.996] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sUbF82UeYUOy for ; Mon, 11 Apr 2016 08:14:04 -0700 (PDT) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E31C112F020 for ; Mon, 11 Apr 2016 08:14:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1460387644; x=1491923644; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=GnPLNrmJdQp1k+VpuqWIe76f/ZltGP2NYbpAPDI/8Gw=; b=d2d5LiGvBJMd84/flFJyGc6j0bzbCt16jsEFKjDtwZd6/Ls2ypqXUdkU 6uc5nlOsp4Bq7HWtHOBQIkQu1OGq0PzxhYJUC2lNLBGZ7VAzEMlBBzgFw jLLBt5QqApxD3+a/5pqNvwbmDu38xNnR/idVCJuIg7Hgnj69OIBgZjbhY BqPgOos3K8AioG/cgEcm9aMuV25gfnDQcz5WTRtG4nbSrzWgh8H3w5OHW kFDYvXG67rg8lbhCXsqpTjjvqEYbMro6WXfgry5LL2HLcLlrLfvNWGmKQ evpQ+9HViANjIa/5d7v33PmlyPDO8LxmJ6UhA2DDaum5nVWHmefR+GA/e w==; X-IronPort-AV: E=Sophos;i="5.24,462,1454929200"; d="scan'208";a="79421764" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.106 - Outgoing - Outgoing Received: from uxchange10-fe2.uoa.auckland.ac.nz ([130.216.4.106]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 12 Apr 2016 03:13:41 +1200 Received: from UXCN10-5.UoA.auckland.ac.nz ([169.254.5.33]) by uxchange10-fe2.UoA.auckland.ac.nz ([130.216.4.106]) with mapi id 14.03.0266.001; Tue, 12 Apr 2016 03:13:41 +1200 From: Peter Gutmann To: Stephen Farrell , Ilari Liusvaara , Mike Hamburg Thread-Topic: [Cfrg] A big, big Elliptic Curve Thread-Index: AQHRkzmOIRB/QVVmEESPQH/JwSMSzZ+CqMCAgAAFWgCAAAMggIACMWfi Date: Mon, 11 Apr 2016 15:13:40 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73F4C56B9C@uxcn10-5.UoA.auckland.ac.nz> References: <858AE939-7119-49DA-A9C2-79B1DF5DC8BB@shiftleft.org> <20160410173148.GA8578@LK-Perkele-V2.elisa-laajakaista.fi>, <570A90A3.5010607@cs.tcd.ie> In-Reply-To: <570A90A3.5010607@cs.tcd.ie> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.6.3.5] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "cfrg@irtf.org" Subject: Re: [Cfrg] A big, big Elliptic Curve X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Apr 2016 15:14:08 -0000 Stephen Farrell writes:=0A= =0A= >The solution to this quandry I think is for us to base decisions on whatev= er=0A= >openly available evidence we have, but on nothing else. (So we ought not I= MO=0A= >factor in press-releases from anyone.)=0A= =0A= +1. "We have evidence of X that we can't show you, but we know you'd agree= =0A= with us if you saw it" is so 1990s crypto wars. Go with published, proven= =0A= facts, not rumours and innuendo from an organisation with a track record of= =0A= subverting crypto.=0A= =0A= Peter.= From nobody Mon Apr 11 13:48:47 2016 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 951F612F455 for ; Mon, 11 Apr 2016 13:48:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.996 X-Spam-Level: X-Spam-Status: No, score=-2.996 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=tc26.ru Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LAdhDPgbaOTx for ; Mon, 11 Apr 2016 13:48:44 -0700 (PDT) Received: from mail.tc26.ru (mail.tc26.ru [188.40.163.82]) by ietfa.amsl.com (Postfix) with ESMTP id DFB1712F456 for ; Mon, 11 Apr 2016 13:48:43 -0700 (PDT) Received: from mail.tc26.ru (localhost [127.0.0.1]) by mail.tc26.ru (Postfix) with ESMTPSA id 2E26D3003E7; Mon, 11 Apr 2016 23:48:40 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.10.3 mail.tc26.ru 2E26D3003E7 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tc26.ru; s=mx; t=1460407721; bh=vsEF9e1pSpqtnlhKuF82kpvbKVj2zdFfZrUuuTzRyls=; h=Date:From:Subject:To:In-Reply-To:References:From; b=bZb6TdrP1WeMZwBlanKFLwEMs79nhtKEWCrgkMzUvw/EpiHb1HyMCstHwE9z1ht14 ZdfipKHuZdbcCgF21CnoBJbDxFrYpd8a8YQKpBHYtKAzN1kVn446lKRoKg1NKPvtBL o19yGUgrrLrmitcQzcS9DnfrUYV9KKy3YctbSzeA= Mime-Version: 1.0 Date: Mon, 11 Apr 2016 20:48:39 +0000 Content-Type: multipart/alternative; boundary="--=_RainLoop_458_425210050.1460407719" Message-ID: X-Mailer: RainLoop/1.9.3.365 From: "Grigory Marshalko" To: "Dr. Pala" , cfrg@irtf.org In-Reply-To: <570BB5BC.5000705@openca.org> References: <570BB5BC.5000705@openca.org> X-KLMS-Rule-ID: 1 X-KLMS-Message-Action: clean X-KLMS-AntiSpam-Lua-Profiles: 94495 [Apr 11 2016] X-KLMS-AntiSpam-Version: 5.5.9.33 X-KLMS-AntiSpam-Envelope-From: marshalko_gb@tc26.ru X-KLMS-AntiSpam-Rate: 0 X-KLMS-AntiSpam-Status: not_detected X-KLMS-AntiSpam-Method: none X-KLMS-AntiSpam-Moebius-Timestamps: 4067419, 4067447, 4067327 X-KLMS-AntiSpam-Info: LuaCore: 419 419 24d92320b28ecafcc7e43d1a024ab7fa6f09466f, eprint.iacr.org:7.1.1; tc26.ru:7.1.1; 127.0.0.200:7.1.3; mail.tc26.ru:7.1.1; arxiv.org:4.0.4,7.1.1; d41d8cd98f00b204e9800998ecf8427e.com:7.1.1; 127.0.0.199:7.1.2, Auth:dkim=none X-KLMS-AntiSpam-Interceptor-Info: scan successful X-KLMS-AntiPhishing: Clean, 2016/04/11 08:42:06 X-KLMS-AntiVirus: Kaspersky Security 8.0 for Linux Mail Server, version 8.0.1.721, bases: 2016/04/11 09:40:00 #7475791 X-KLMS-AntiVirus-Status: Clean, skipped Archived-At: Subject: Re: [Cfrg] [MASSMAIL] Quantum Computing and Crypto Policies X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Apr 2016 20:48:46 -0000 ----=_RainLoop_458_425210050.1460407719 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Not only described issues.=0ATwo recent papers also address the post-quan= tum security of block cipher modes and MACs.=0Ahttp://arxiv.org/pdf/1602.= 05973.pdf (http://arxiv.org/pdf/1602.05973.pdf)=0Ahttps://eprint.iacr.org= /2016/197.pdf (https://eprint.iacr.org/2016/197.pdf)=0ARegards,=0AGrigory= Marshalko,=0Aexpert,=0ATechnical committee for standardisation "Cryptogr= aphy and security mechanisms" (TC 26)=0Awww.tc26.ru=0A=0A11 =D0=B0=D0=BF= =D1=80=D0=B5=D0=BB=D1=8F 2016 =D0=B3., 17:33, "Dr. Pala" =D0=BD=D0=B0=D0= =BF=D0=B8=D1=81=D0=B0=D0=BB:=0AHi all,=0A=0AAt the CFRG meeting, I have a= ppreciated the presentation about QC in the sense that inspired to think = about the future in a more practical way (although there was probably not= much agreement on how to proceed forward).=0A=0AI have also been followi= ng the conversation about the post-quantum computing crypto resistance an= d I am trying to figure out - given what we know about possible quantum c= omputing which, as Tim pointed out during the meeting, is still very litt= le - what types of policies can be implemented today that would allow us = to be a bit more resilient to attacks in the post quantum-computing envir= onment (i.e., not being taken by surprise since deploying of new crypto c= an take several years in the real world despite the algorithm agility we = have in current standards). I will try to summarize the two main points:= =0A * Symmetric crypto is still relatively secure. Using 256bits keys (e.= g., AES 256) should provide enough confidentiality for the time being (th= is is already a common practice in the industry as the overhead compared = to 128bits is negligible) - so we are relatively safe here.=0A * Given th= e physical limitations when it comes to be able to have QC with high numb= er of qbits, it seems that when it comes to Asymmetric crypto, ECDSA (giv= en the limited number of bits and the impossibility to extend the number = of bits without defining new curves) is the weakest choice compared to RS= A with very long keys (e.g., 8K or 16K bits keys or even bigger...).=0A I= n other words, given this scenario and setting aside considerations about= signature sizes (although, we have seen an increase in computing resourc= es in terms of processing power, bandwidth, and storage it seems that sig= nature size is a big concern - AFAIK, mostly driven by IoT and similar en= vironments - even more than 10yrs ago! and many WGs are using the size ar= gument over the security argument in their specifications and suggestions= ), the more flexible and forward-secure choice would be to start using "o= versized" RSA keys for asymmetric and for symmetric we can keep using AES= 256 with relative confidence (assuming, as I said, that no new quantum-s= pecific algorithms are discovered...)=0A=0A Does this summarizes the curr= ent situation? Are these (very simplistic) considerations correct? Anybod= y disagree with these statements? Why?=0A=0A Cheers,=0AMax=0A=C2=A0=0A=0A= -- Massimiliano Pala, PhD Director at OpenCA Labs twitter: @openca ----=_RainLoop_458_425210050.1460407719 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable
N= ot only described issues.
Two recent papers also address the post-quan= tum security of block cipher modes and MACs.
http://arxiv.org/pdf/1602.05973.pdf
https://eprint.iacr.org/2016/19= 7.pdf
Regards,
Grigory Marshalko,
expert,
Technical commi= ttee for standardisation "Cryptography and security mechanisms" (TC 26)www.tc26.ru

11 =D0=B0=D0=BF=D1=80=D0=B5=D0=BB=D1=8F 2016 =D0=B3.= , 17:33, "Dr. Pala" <director@openca.org> =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB:
Hi all,

At the CF= RG meeting, I have appreciated the presentation about QC in the sense tha= t inspired to think about the future in a more practical way (although th= ere was probably not much agreement on how to proceed forward).

I = have also been following the conversation about the post-quantum computin= g crypto resistance and I am trying to figure out - given what we know ab= out possible quantum computing which, as Tim pointed out during the meeti= ng, is still very little - what types of policies can be implemented toda= y that would allow us to be a bit more resilient to attacks in the post q= uantum-computing environment (i.e., not being taken by surprise since dep= loying of new crypto can take several years in the real world despite the= algorithm agility we have in current standards). I will try to summarize= the two main points:
  1. Symmetric crypto is still relatively secure.= Using 256bits keys (e.g., AES 256) should provide enough confidentiality= for the time being (this is already a common practice in the industry as= the overhead compared to 128bits is negligible) - so we are relatively s= afe here.
  2. Given the physical limitations when it comes to be able= to have QC with high number of qbits, it seems that when it comes to Asy= mmetric crypto, ECDSA (given the limited number of bits and the impossibi= lity to extend the number of bits without defining new curves) is the wea= kest choice compared to RSA with very long keys (e.g., 8K or 16K bits key= s or even bigger...).

In other words, given this scenario and= setting aside considerations about signature sizes (although, we have se= en an increase in computing resources in terms of processing power, bandw= idth, and storage it seems that signature size is a big concern - AFAIK, = mostly driven by IoT and similar environments - even more than 10yrs ago!= and many WGs are using the size argument over the security argument in t= heir specifications and suggestions), the more flexible and forward-secur= e choice would be to start using "oversized" RSA keys for asymmetric and = for symmetric we can keep using AES 256 with relative confidence (assumin= g, as I said, that no new quantum-specific algorithms are discovered...)<= /p>

Does this summarizes the current situation? Are these (very simplis= tic) considerations correct? Anybody disagree with these statements? Why?=

Cheers,
Max
=C2=A0

-- =0AMassimiliano Pa=
la, PhD=0ADirector at OpenCA Labs=0Atwitter: @openca
----=_RainLoop_458_425210050.1460407719-- From nobody Mon Apr 11 14:02:10 2016 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1403312DF69 for ; Mon, 11 Apr 2016 14:02:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.516 X-Spam-Level: X-Spam-Status: No, score=-15.516 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TlSMmdSUDZOC for ; Mon, 11 Apr 2016 14:02:05 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB38112DF1E for ; Mon, 11 Apr 2016 14:02:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=20718; q=dns/txt; s=iport; t=1460408524; x=1461618124; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=Ic/P0hzO4JKT4uowwwIj0iDE0khZU47GYFIpKR9xA/E=; b=hhwpe6V6EvlD2IaupCtRL2rXIGSnvrY7KSZfOJAemvtZHYTAc3E0Wc79 0Orl3m+3RbqnJv14sJ5qItGlsDsjUC60cRFFbrQHpWi5Ech31Ngkiih90 5L+em9pvEpVIKzoDMY7vlqxLb/pLt/kw6se8lPsMZ5hPT8/uRmYcF7NNk s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AyBQBeEAxX/4YNJK1cgmtMU30GtWiCZ?= =?us-ascii?q?IQPFwEFhXACHIESOxEBAQEBAQEBZSeEQQEBAQICIwocIh4CAQYCEQQBASgDAgI?= =?us-ascii?q?CMBQJCAIEARIIiB8OkC6dF5IaAQEBAQEBAQEBAQEBAQEBAQEBAQEBFYYhhEuCX?= =?us-ascii?q?oE7CgZDCYISOBOCQwWITY83AYV2iA6CPIxYjyUBDycsggQZgUpsAYhHAR8ffgE?= =?us-ascii?q?BAQ?= X-IronPort-AV: E=Sophos; i="5.24,470,1454976000"; d="scan'208,217"; a="95278773" Received: from alln-core-12.cisco.com ([173.36.13.134]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 11 Apr 2016 21:02:03 +0000 Received: from XCH-RTP-010.cisco.com (xch-rtp-010.cisco.com [64.101.220.150]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id u3BL23Ef029074 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 11 Apr 2016 21:02:03 GMT Received: from xch-rtp-006.cisco.com (64.101.220.146) by XCH-RTP-010.cisco.com (64.101.220.150) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 11 Apr 2016 17:02:02 -0400 Received: from xch-rtp-006.cisco.com ([64.101.220.146]) by XCH-RTP-006.cisco.com ([64.101.220.146]) with mapi id 15.00.1104.009; Mon, 11 Apr 2016 17:02:02 -0400 From: "Scott Fluhrer (sfluhrer)" To: Grigory Marshalko , "Dr. Pala" , "cfrg@irtf.org" Thread-Topic: [Cfrg] [MASSMAIL] Quantum Computing and Crypto Policies Thread-Index: AQHRlDOQCZn1/g8DvkWjYwrzs7h/xJ+FPutw Date: Mon, 11 Apr 2016 21:02:02 +0000 Message-ID: <9b3261feb368462a87e6772b1740d9ec@XCH-RTP-006.cisco.com> References: <570BB5BC.5000705@openca.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.98.2.62] Content-Type: multipart/alternative; boundary="_000_9b3261feb368462a87e6772b1740d9ecXCHRTP006ciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [Cfrg] [MASSMAIL] Quantum Computing and Crypto Policies X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Apr 2016 21:02:08 -0000 --_000_9b3261feb368462a87e6772b1740d9ecXCHRTP006ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhlc2UgcGFwZXJzIGFzc3VtZSBhIHZlcnkgb2JzY3VyZSBhdHRhY2sgbW9kZWw7IHdoZXJlIHRo ZSBhdHRhY2tlciBjYW4gZ2VuZXJhdGUgYSBwbGFpbnRleHQgdGhhdCBpcyBhIHN1cGVycG9zaXRp b24gb2Ygc2V2ZXJhbCBwb3NzaWJsZSB2YWx1ZXMsIGFuZCBoYXZlIHRoZSBkZXZpY2UgZ2VuZXJh dGUgYSBjaXBoZXJ0ZXh0IHRoYXQgaXMgYSBzdXBlcnBvc2l0aW9uIG9mIHRoZSBlbmNyeXB0aW9u IG9mIHRoZSB2YXJpb3VzIHZhbHVlcy4NCg0KV2UgYXNzdW1lIHRoYXQgd2l0aGluIGEgUXVhbnR1 bSBDb21wdXRlciwgd2Ugc29tZWhvdyBtYWludGFpbiBjb2hlcmVuY2Ugb2YgdGhlIHZhcmlvdXMg cXVhbnR1bSBzdGF0ZXM7IGhvd2V2ZXIgdGhpcyBhdHRhY2sgbW9kZWwgYXNrcyB0aGF0IHRoaXMg Y29oZXJlbmN5IGlzIG5vdCBkaXNydXB0ZWQgd2hlbiB0aGUgcXVlcmllcyBsZWF2ZSB0aGUgUXVh bnR1bSBDb21wdXRlci4gIFJlYWxpc3RpY2FsbHksIGl0IGlzIGhhcmQgdG8gc2VlIGhvdyB0aGlz IGNvdWxkIGJlIGltcGxlbWVudGVkIG92ZXIgYSBuZXR3b3JrLiAgUXVhbnR1bSBTdXBlcnBvc2l0 aW9uIGlzIHF1aXRlIGRlbGljYXRlOyBpbiBmYWN0LCB0aGUgbWFpbiBwcm9ibGVtIHdlIGhhdmUg aW4gYnVpbGRpbmcgYSBRdWFudHVtIENvbXB1dGVyIGlzIGhvdyB0byBtYWludGFpbiBjb2hlcmVu Y2Ugb3ZlciBhIG5vbnRyaXZpYWwgcGVyaW9kIG9mIHRpbWUg4oCTIGl0IHdvdWxkIGFwcGVhciB0 byBiZSB1bmxpa2VseSB0aGF0IHRoZSBkZXZpY2UgdW5kZXIgYXR0YWNrIHdvdWxkIGJlIGhlbHBm dWwgZW5vdWdoIHRvIHRoZSBhdHRhY2tlciB0byBnbyB0aHJvdWdoIHRoYXQgZWZmb3J0Lg0KDQpO b3csIGZvciB0b3RhbGx5IHB1YmxpYyBvcGVyYXRpb25zIChoYXNoaW5nLCBwdWJsaWMga2V5IGVu Y3J5cHRpb24sIHNpZ25hdHVyZSB2ZXJpZmljYXRpb24sIHdoaXRlYm94IGNyeXB0b2dyYXBoeSks IHRoZXNlIHNvcnRzIG9mIGF0dGFja3MgYXJlIHBsYXVzaWJsZSAoYmVjYXVzZSBzb21lb25lIHdp dGggYSBRdWFudHVtIENvbXB1dGVyIGNhbiBwZXJmb3JtIHRoZW0gZW50aXJlbHkgd2l0aGluIHRo ZSBRdWFudHVtIENvbXB1dGVyLCBhbmQgc28gZ28gdGhyb3VnaCB0aGUgZWZmb3J0IG9mIG1haW50 YWluaW5nIGNvaGVyZW5jZSBvdmVyIHRoZSBlbnRpcmUgb3BlcmF0aW9uKS4gIEhvd2V2ZXIsIGZv ciBhdHRhY2tpbmcgZGV2aWNlcyBvbiB0aGUgaW50ZXJuZXQsIHdlbGwsIGl04oCZcyBsZXNzIGlu dGVyZXN0aW5nLg0KDQpGcm9tOiBDZnJnIFttYWlsdG86Y2ZyZy1ib3VuY2VzQGlydGYub3JnXSBP biBCZWhhbGYgT2YgR3JpZ29yeSBNYXJzaGFsa28NClNlbnQ6IE1vbmRheSwgQXByaWwgMTEsIDIw MTYgNDo0OSBQTQ0KVG86IERyLiBQYWxhOyBjZnJnQGlydGYub3JnDQpTdWJqZWN0OiBSZTogW0Nm cmddIFtNQVNTTUFJTF0gUXVhbnR1bSBDb21wdXRpbmcgYW5kIENyeXB0byBQb2xpY2llcw0KDQpO b3Qgb25seSBkZXNjcmliZWQgaXNzdWVzLg0KVHdvIHJlY2VudCBwYXBlcnMgYWxzbyBhZGRyZXNz IHRoZSBwb3N0LXF1YW50dW0gc2VjdXJpdHkgb2YgYmxvY2sgY2lwaGVyIG1vZGVzIGFuZCBNQUNz Lg0KaHR0cDovL2FyeGl2Lm9yZy9wZGYvMTYwMi4wNTk3My5wZGYNCmh0dHBzOi8vZXByaW50Lmlh Y3Iub3JnLzIwMTYvMTk3LnBkZg0KUmVnYXJkcywNCkdyaWdvcnkgTWFyc2hhbGtvLA0KZXhwZXJ0 LA0KVGVjaG5pY2FsIGNvbW1pdHRlZSBmb3Igc3RhbmRhcmRpc2F0aW9uICJDcnlwdG9ncmFwaHkg YW5kIHNlY3VyaXR5IG1lY2hhbmlzbXMiIChUQyAyNikNCnd3dy50YzI2LnJ1PGh0dHA6Ly93d3cu dGMyNi5ydT4NCg0KMTEg0LDQv9GA0LXQu9GPIDIwMTYg0LMuLCAxNzozMywgIkRyLiBQYWxhIiA8 ZGlyZWN0b3JAb3BlbmNhLm9yZzxtYWlsdG86JTIyRHIuJTIwUGFsYSUyMiUyMCUzY2RpcmVjdG9y QG9wZW5jYS5vcmclM2U+PiDQvdCw0L/QuNGB0LDQuzoNCkhpIGFsbCwNCg0KQXQgdGhlIENGUkcg bWVldGluZywgSSBoYXZlIGFwcHJlY2lhdGVkIHRoZSBwcmVzZW50YXRpb24gYWJvdXQgUUMgaW4g dGhlIHNlbnNlIHRoYXQgaW5zcGlyZWQgdG8gdGhpbmsgYWJvdXQgdGhlIGZ1dHVyZSBpbiBhIG1v cmUgcHJhY3RpY2FsIHdheSAoYWx0aG91Z2ggdGhlcmUgd2FzIHByb2JhYmx5IG5vdCBtdWNoIGFn cmVlbWVudCBvbiBob3cgdG8gcHJvY2VlZCBmb3J3YXJkKS4NCg0KSSBoYXZlIGFsc28gYmVlbiBm b2xsb3dpbmcgdGhlIGNvbnZlcnNhdGlvbiBhYm91dCB0aGUgcG9zdC1xdWFudHVtIGNvbXB1dGlu ZyBjcnlwdG8gcmVzaXN0YW5jZSBhbmQgSSBhbSB0cnlpbmcgdG8gZmlndXJlIG91dCAtIGdpdmVu IHdoYXQgd2Uga25vdyBhYm91dCBwb3NzaWJsZSBxdWFudHVtIGNvbXB1dGluZyB3aGljaCwgYXMg VGltIHBvaW50ZWQgb3V0IGR1cmluZyB0aGUgbWVldGluZywgaXMgc3RpbGwgdmVyeSBsaXR0bGUg LSB3aGF0IHR5cGVzIG9mIHBvbGljaWVzIGNhbiBiZSBpbXBsZW1lbnRlZCB0b2RheSB0aGF0IHdv dWxkIGFsbG93IHVzIHRvIGJlIGEgYml0IG1vcmUgcmVzaWxpZW50IHRvIGF0dGFja3MgaW4gdGhl IHBvc3QgcXVhbnR1bS1jb21wdXRpbmcgZW52aXJvbm1lbnQgKGkuZS4sIG5vdCBiZWluZyB0YWtl biBieSBzdXJwcmlzZSBzaW5jZSBkZXBsb3lpbmcgb2YgbmV3IGNyeXB0byBjYW4gdGFrZSBzZXZl cmFsIHllYXJzIGluIHRoZSByZWFsIHdvcmxkIGRlc3BpdGUgdGhlIGFsZ29yaXRobSBhZ2lsaXR5 IHdlIGhhdmUgaW4gY3VycmVudCBzdGFuZGFyZHMpLiBJIHdpbGwgdHJ5IHRvIHN1bW1hcml6ZSB0 aGUgdHdvIG1haW4gcG9pbnRzOg0KDQogIDEuICBTeW1tZXRyaWMgY3J5cHRvIGlzIHN0aWxsIHJl bGF0aXZlbHkgc2VjdXJlLiBVc2luZyAyNTZiaXRzIGtleXMgKGUuZy4sIEFFUyAyNTYpIHNob3Vs ZCBwcm92aWRlIGVub3VnaCBjb25maWRlbnRpYWxpdHkgZm9yIHRoZSB0aW1lIGJlaW5nICh0aGlz IGlzIGFscmVhZHkgYSBjb21tb24gcHJhY3RpY2UgaW4gdGhlIGluZHVzdHJ5IGFzIHRoZSBvdmVy aGVhZCBjb21wYXJlZCB0byAxMjhiaXRzIGlzIG5lZ2xpZ2libGUpIC0gc28gd2UgYXJlIHJlbGF0 aXZlbHkgc2FmZSBoZXJlLg0KICAyLiAgR2l2ZW4gdGhlIHBoeXNpY2FsIGxpbWl0YXRpb25zIHdo ZW4gaXQgY29tZXMgdG8gYmUgYWJsZSB0byBoYXZlIFFDIHdpdGggaGlnaCBudW1iZXIgb2YgcWJp dHMsIGl0IHNlZW1zIHRoYXQgd2hlbiBpdCBjb21lcyB0byBBc3ltbWV0cmljIGNyeXB0bywgRUNE U0EgKGdpdmVuIHRoZSBsaW1pdGVkIG51bWJlciBvZiBiaXRzIGFuZCB0aGUgaW1wb3NzaWJpbGl0 eSB0byBleHRlbmQgdGhlIG51bWJlciBvZiBiaXRzIHdpdGhvdXQgZGVmaW5pbmcgbmV3IGN1cnZl cykgaXMgdGhlIHdlYWtlc3QgY2hvaWNlIGNvbXBhcmVkIHRvIFJTQSB3aXRoIHZlcnkgbG9uZyBr ZXlzIChlLmcuLCA4SyBvciAxNksgYml0cyBrZXlzIG9yIGV2ZW4gYmlnZ2VyLi4uKS4NCg0KSW4g b3RoZXIgd29yZHMsIGdpdmVuIHRoaXMgc2NlbmFyaW8gYW5kIHNldHRpbmcgYXNpZGUgY29uc2lk ZXJhdGlvbnMgYWJvdXQgc2lnbmF0dXJlIHNpemVzIChhbHRob3VnaCwgd2UgaGF2ZSBzZWVuIGFu IGluY3JlYXNlIGluIGNvbXB1dGluZyByZXNvdXJjZXMgaW4gdGVybXMgb2YgcHJvY2Vzc2luZyBw b3dlciwgYmFuZHdpZHRoLCBhbmQgc3RvcmFnZSBpdCBzZWVtcyB0aGF0IHNpZ25hdHVyZSBzaXpl IGlzIGEgYmlnIGNvbmNlcm4gLSBBRkFJSywgbW9zdGx5IGRyaXZlbiBieSBJb1QgYW5kIHNpbWls YXIgZW52aXJvbm1lbnRzIC0gZXZlbiBtb3JlIHRoYW4gMTB5cnMgYWdvISBhbmQgbWFueSBXR3Mg YXJlIHVzaW5nIHRoZSBzaXplIGFyZ3VtZW50IG92ZXIgdGhlIHNlY3VyaXR5IGFyZ3VtZW50IGlu IHRoZWlyIHNwZWNpZmljYXRpb25zIGFuZCBzdWdnZXN0aW9ucyksIHRoZSBtb3JlIGZsZXhpYmxl IGFuZCBmb3J3YXJkLXNlY3VyZSBjaG9pY2Ugd291bGQgYmUgdG8gc3RhcnQgdXNpbmcgIm92ZXJz aXplZCIgUlNBIGtleXMgZm9yIGFzeW1tZXRyaWMgYW5kIGZvciBzeW1tZXRyaWMgd2UgY2FuIGtl ZXAgdXNpbmcgQUVTIDI1NiB3aXRoIHJlbGF0aXZlIGNvbmZpZGVuY2UgKGFzc3VtaW5nLCBhcyBJ IHNhaWQsIHRoYXQgbm8gbmV3IHF1YW50dW0tc3BlY2lmaWMgYWxnb3JpdGhtcyBhcmUgZGlzY292 ZXJlZC4uLikNCg0KRG9lcyB0aGlzIHN1bW1hcml6ZXMgdGhlIGN1cnJlbnQgc2l0dWF0aW9uPyBB cmUgdGhlc2UgKHZlcnkgc2ltcGxpc3RpYykgY29uc2lkZXJhdGlvbnMgY29ycmVjdD8gQW55Ym9k eSBkaXNhZ3JlZSB3aXRoIHRoZXNlIHN0YXRlbWVudHM/IFdoeT8NCg0KQ2hlZXJzLA0KTWF4DQoN Cg0KLS0NCg0KTWFzc2ltaWxpYW5vIFBhbGEsIFBoRA0KDQpEaXJlY3RvciBhdCBPcGVuQ0EgTGFi cw0KDQp0d2l0dGVyOiBAb3BlbmNhDQo= --_000_9b3261feb368462a87e6772b1740d9ecXCHRTP006ciscocom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpA Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDIg MiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNv Tm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAw MXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIs InNlcmlmIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNp dGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsN Cgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwDQoJe21zby1z dHlsZS1wcmlvcml0eTo5OTsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmln aHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsN Cglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJp ZiI7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRN TCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAx cHQ7DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCnAu TXNvQWNldGF0ZSwgbGkuTXNvQWNldGF0ZSwgZGl2Lk1zb0FjZXRhdGUNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbWFyZ2lu OjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjguMHB0Ow0KCWZvbnQt ZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLkhUTUxQcmVmb3JtYXR0ZWRDaGFy DQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltc28tc3R5bGUt cHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIjsNCglmb250 LWZhbWlseTpDb25zb2xhczt9DQpzcGFuLkVtYWlsU3R5bGUyMA0KCXttc28tc3R5bGUtdHlwZTpw ZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNv bG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5CYWxsb29uVGV4dENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkJh bGxvb24gVGV4dCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxp bms6IkJhbGxvb24gVGV4dCI7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO30N Ci5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6 ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1h cmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6 V29yZFNlY3Rpb24xO30NCi8qIExpc3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJe21zby1s aXN0LWlkOjE5Njk4OTgxNjI7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi05MTkxNTk2MjY7fQ0K b2wNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KLS0+ PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9 ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBt c28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0 PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0K PC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0K PGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxhIG5hbWU9 Il9NYWlsRW5kQ29tcG9zZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNr Ij5UaGVzZSBwYXBlcnMgYXNzdW1lIGEgdmVyeSBvYnNjdXJlIGF0dGFjayBtb2RlbDsgd2hlcmUg dGhlIGF0dGFja2VyIGNhbiBnZW5lcmF0ZSBhIHBsYWludGV4dCB0aGF0IGlzIGEgc3VwZXJwb3Np dGlvbiBvZiBzZXZlcmFsIHBvc3NpYmxlDQogdmFsdWVzLCBhbmQgaGF2ZSB0aGUgZGV2aWNlIGdl bmVyYXRlIGEgY2lwaGVydGV4dCB0aGF0IGlzIGEgc3VwZXJwb3NpdGlvbiBvZiB0aGUgZW5jcnlw dGlvbiBvZiB0aGUgdmFyaW91cyB2YWx1ZXMuPG86cD48L286cD48L3NwYW4+PC9hPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFj ayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5XZSBhc3N1bWUgdGhhdCB3aXRo aW4gYSBRdWFudHVtIENvbXB1dGVyLCB3ZSBzb21laG93IG1haW50YWluIGNvaGVyZW5jZSBvZiB0 aGUgdmFyaW91cyBxdWFudHVtIHN0YXRlczsgaG93ZXZlciB0aGlzIGF0dGFjayBtb2RlbCBhc2tz IHRoYXQgdGhpcyBjb2hlcmVuY3kgaXMgbm90DQogZGlzcnVwdGVkIHdoZW4gdGhlIHF1ZXJpZXMg bGVhdmUgdGhlIFF1YW50dW0gQ29tcHV0ZXIuJm5ic3A7IFJlYWxpc3RpY2FsbHksIGl0IGlzIGhh cmQgdG8gc2VlIGhvdyB0aGlzIGNvdWxkIGJlIGltcGxlbWVudGVkIG92ZXIgYSBuZXR3b3JrLiAm bmJzcDtRdWFudHVtIFN1cGVycG9zaXRpb24gaXMgcXVpdGUgZGVsaWNhdGU7IGluIGZhY3QsIHRo ZSBtYWluIHByb2JsZW0gd2UgaGF2ZSBpbiBidWlsZGluZyBhIFF1YW50dW0gQ29tcHV0ZXIgaXMg aG93IHRvIG1haW50YWluDQogY29oZXJlbmNlIG92ZXIgYSBub250cml2aWFsIHBlcmlvZCBvZiB0 aW1lIOKAkyBpdCB3b3VsZCBhcHBlYXIgdG8gYmUgdW5saWtlbHkgdGhhdCB0aGUgZGV2aWNlIHVu ZGVyIGF0dGFjayB3b3VsZCBiZSBoZWxwZnVsIGVub3VnaCB0byB0aGUgYXR0YWNrZXIgdG8gZ28g dGhyb3VnaCB0aGF0IGVmZm9ydC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+Tm93LCBmb3IgdG90YWxseSBwdWJsaWMgb3BlcmF0 aW9ucyAoaGFzaGluZywgcHVibGljIGtleSBlbmNyeXB0aW9uLCBzaWduYXR1cmUgdmVyaWZpY2F0 aW9uLCB3aGl0ZWJveCBjcnlwdG9ncmFwaHkpLCB0aGVzZSBzb3J0cyBvZiBhdHRhY2tzIGFyZSBw bGF1c2libGUgKGJlY2F1c2UNCiBzb21lb25lIHdpdGggYSBRdWFudHVtIENvbXB1dGVyIGNhbiBw ZXJmb3JtIHRoZW0gZW50aXJlbHkgd2l0aGluIHRoZSBRdWFudHVtIENvbXB1dGVyLCBhbmQgc28g Z28gdGhyb3VnaCB0aGUgZWZmb3J0IG9mIG1haW50YWluaW5nIGNvaGVyZW5jZSBvdmVyIHRoZSBl bnRpcmUgb3BlcmF0aW9uKS4mbmJzcDsgSG93ZXZlciwgZm9yIGF0dGFja2luZyBkZXZpY2VzIG9u IHRoZSBpbnRlcm5ldCwgd2VsbCwgaXTigJlzIGxlc3MgaW50ZXJlc3RpbmcuPC9zcGFuPjxzcGFu IGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBz dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBp biAwaW4gMGluIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt dG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3Nw YW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1Rh aG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gQ2ZyZyBbbWFpbHRvOmNmcmctYm91 bmNlc0BpcnRmLm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+R3JpZ29yeSBNYXJzaGFsa288YnI+ DQo8Yj5TZW50OjwvYj4gTW9uZGF5LCBBcHJpbCAxMSwgMjAxNiA0OjQ5IFBNPGJyPg0KPGI+VG86 PC9iPiBEci4gUGFsYTsgY2ZyZ0BpcnRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW0Nm cmddIFtNQVNTTUFJTF0gUXVhbnR1bSBDb21wdXRpbmcgYW5kIENyeXB0byBQb2xpY2llczxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7Ij5Ob3Qgb25seSBkZXNjcmliZWQgaXNzdWVzLjxicj4NClR3byBy ZWNlbnQgcGFwZXJzIGFsc28gYWRkcmVzcyB0aGUgcG9zdC1xdWFudHVtIHNlY3VyaXR5IG9mIGJs b2NrIGNpcGhlciBtb2RlcyBhbmQgTUFDcy48YnI+DQo8YSBocmVmPSJodHRwOi8vYXJ4aXYub3Jn L3BkZi8xNjAyLjA1OTczLnBkZiI+aHR0cDovL2FyeGl2Lm9yZy9wZGYvMTYwMi4wNTk3My5wZGY8 L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly9lcHJpbnQuaWFjci5vcmcvMjAxNi8xOTcucGRmIj5o dHRwczovL2VwcmludC5pYWNyLm9yZy8yMDE2LzE5Ny5wZGY8L2E+PGJyPg0KUmVnYXJkcyw8YnI+ DQpHcmlnb3J5IE1hcnNoYWxrbyw8YnI+DQpleHBlcnQsPGJyPg0KVGVjaG5pY2FsIGNvbW1pdHRl ZSBmb3Igc3RhbmRhcmRpc2F0aW9uICZxdW90O0NyeXB0b2dyYXBoeSBhbmQgc2VjdXJpdHkgbWVj aGFuaXNtcyZxdW90OyAoVEMgMjYpPGJyPg0KPGEgaHJlZj0iaHR0cDovL3d3dy50YzI2LnJ1Ij53 d3cudGMyNi5ydTwvYT48YnI+DQo8YnI+DQoxMSDQsNC/0YDQtdC70Y8gMjAxNiDQsy4sIDE3OjMz LCAmcXVvdDtEci4gUGFsYSZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOiUyMkRyLiUyMFBhbGEl MjIlMjAlM2NkaXJlY3RvckBvcGVuY2Eub3JnJTNlIiB0YXJnZXQ9Il9ibGFuayI+ZGlyZWN0b3JA b3BlbmNhLm9yZzwvYT4mZ3Q7INC90LDQv9C40YHQsNC7OjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hp dGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFs JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPkhpIGFsbCw8YnI+DQo8 YnI+DQpBdCB0aGUgQ0ZSRyBtZWV0aW5nLCBJIGhhdmUgYXBwcmVjaWF0ZWQgdGhlIHByZXNlbnRh dGlvbiBhYm91dCBRQyBpbiB0aGUgc2Vuc2UgdGhhdCBpbnNwaXJlZCB0byB0aGluayBhYm91dCB0 aGUgZnV0dXJlIGluIGEgbW9yZSBwcmFjdGljYWwgd2F5IChhbHRob3VnaCB0aGVyZSB3YXMgcHJv YmFibHkgbm90IG11Y2ggYWdyZWVtZW50IG9uIGhvdyB0byBwcm9jZWVkIGZvcndhcmQpLjxicj4N Cjxicj4NCkkgaGF2ZSBhbHNvIGJlZW4gZm9sbG93aW5nIHRoZSBjb252ZXJzYXRpb24gYWJvdXQg dGhlIHBvc3QtcXVhbnR1bSBjb21wdXRpbmcgY3J5cHRvIHJlc2lzdGFuY2UgYW5kIEkgYW0gdHJ5 aW5nIHRvIGZpZ3VyZSBvdXQgLSBnaXZlbiB3aGF0IHdlIGtub3cgYWJvdXQgcG9zc2libGUgcXVh bnR1bSBjb21wdXRpbmcgd2hpY2gsIGFzIFRpbSBwb2ludGVkIG91dCBkdXJpbmcgdGhlIG1lZXRp bmcsIGlzIHN0aWxsIHZlcnkgbGl0dGxlIC0gd2hhdCB0eXBlcw0KIG9mIHBvbGljaWVzIGNhbiBi ZSBpbXBsZW1lbnRlZCB0b2RheSB0aGF0IHdvdWxkIGFsbG93IHVzIHRvIGJlIGEgYml0IG1vcmUg cmVzaWxpZW50IHRvIGF0dGFja3MgaW4gdGhlIHBvc3QgcXVhbnR1bS1jb21wdXRpbmcgZW52aXJv bm1lbnQgKGkuZS4sIG5vdCBiZWluZyB0YWtlbiBieSBzdXJwcmlzZSBzaW5jZSBkZXBsb3lpbmcg b2YgbmV3IGNyeXB0byBjYW4gdGFrZSBzZXZlcmFsIHllYXJzIGluIHRoZSByZWFsIHdvcmxkIGRl c3BpdGUgdGhlIGFsZ29yaXRobQ0KIGFnaWxpdHkgd2UgaGF2ZSBpbiBjdXJyZW50IHN0YW5kYXJk cykuIEkgd2lsbCB0cnkgdG8gc3VtbWFyaXplIHRoZSB0d28gbWFpbiBwb2ludHM6PG86cD48L286 cD48L3NwYW4+PC9wPg0KPG9sIHN0YXJ0PSIxIiB0eXBlPSIxIj4NCjxsaSBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0iY29sb3I6YmxhY2s7bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzE7YmFja2dyb3VuZDp3aGl0 ZSI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlh bCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5TeW1tZXRyaWMgY3J5cHRvIGlzIHN0aWxs IHJlbGF0aXZlbHkgc2VjdXJlLiBVc2luZyAyNTZiaXRzIGtleXMgKGUuZy4sIEFFUyAyNTYpIHNo b3VsZCBwcm92aWRlIGVub3VnaCBjb25maWRlbnRpYWxpdHkgZm9yIHRoZSB0aW1lIGJlaW5nICh0 aGlzIGlzIGFscmVhZHkgYSBjb21tb24gcHJhY3RpY2UgaW4gdGhlIGluZHVzdHJ5IGFzIHRoZQ0K IG92ZXJoZWFkIGNvbXBhcmVkIHRvIDEyOGJpdHMgaXMgbmVnbGlnaWJsZSkgLSBzbyB3ZSBhcmUg cmVsYXRpdmVseSBzYWZlIGhlcmUuPG86cD48L286cD48L3NwYW4+PC9saT48bGkgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9ImNvbG9yOmJsYWNrO21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0OmwwIGxldmVsMSBsZm8xO2JhY2tncm91bmQ6 d2hpdGUiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+R2l2ZW4gdGhlIHBoeXNpY2FsIGxp bWl0YXRpb25zIHdoZW4gaXQgY29tZXMgdG8gYmUgYWJsZSB0byBoYXZlIFFDIHdpdGggaGlnaCBu dW1iZXIgb2YgcWJpdHMsIGl0IHNlZW1zIHRoYXQgd2hlbiBpdCBjb21lcyB0byBBc3ltbWV0cmlj IGNyeXB0bywgRUNEU0EgKGdpdmVuIHRoZSBsaW1pdGVkIG51bWJlciBvZiBiaXRzIGFuZCB0aGUg aW1wb3NzaWJpbGl0eQ0KIHRvIGV4dGVuZCB0aGUgbnVtYmVyIG9mIGJpdHMgd2l0aG91dCBkZWZp bmluZyBuZXcgY3VydmVzKSBpcyB0aGUgd2Vha2VzdCBjaG9pY2UgY29tcGFyZWQgdG8gUlNBIHdp dGggdmVyeSBsb25nIGtleXMgKGUuZy4sIDhLIG9yIDE2SyBiaXRzIGtleXMgb3IgZXZlbiBiaWdn ZXIuLi4pLjxvOnA+PC9vOnA+PC9zcGFuPjwvbGk+PC9vbD4NCjxwIHN0eWxlPSJiYWNrZ3JvdW5k OndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtB cmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5JbiBvdGhlciB3 b3JkcywgZ2l2ZW4gdGhpcyBzY2VuYXJpbyBhbmQgc2V0dGluZyBhc2lkZSBjb25zaWRlcmF0aW9u cyBhYm91dCBzaWduYXR1cmUgc2l6ZXMgKGFsdGhvdWdoLCB3ZSBoYXZlIHNlZW4gYW4gaW5jcmVh c2UgaW4gY29tcHV0aW5nIHJlc291cmNlcyBpbg0KIHRlcm1zIG9mIHByb2Nlc3NpbmcgcG93ZXIs IGJhbmR3aWR0aCwgYW5kIHN0b3JhZ2UgaXQgc2VlbXMgdGhhdCBzaWduYXR1cmUgc2l6ZSBpcyBh IGJpZyBjb25jZXJuIC0gQUZBSUssIG1vc3RseSBkcml2ZW4gYnkgSW9UIGFuZCBzaW1pbGFyIGVu dmlyb25tZW50cyAtIGV2ZW4gbW9yZSB0aGFuIDEweXJzIGFnbyEgYW5kIG1hbnkgV0dzIGFyZSB1 c2luZyB0aGUgc2l6ZSBhcmd1bWVudCBvdmVyIHRoZSBzZWN1cml0eSBhcmd1bWVudCBpbiB0aGVp cg0KIHNwZWNpZmljYXRpb25zIGFuZCBzdWdnZXN0aW9ucyksIHRoZSBtb3JlIGZsZXhpYmxlIGFu ZCBmb3J3YXJkLXNlY3VyZSBjaG9pY2Ugd291bGQgYmUgdG8gc3RhcnQgdXNpbmcgJnF1b3Q7b3Zl cnNpemVkJnF1b3Q7IFJTQSBrZXlzIGZvciBhc3ltbWV0cmljIGFuZCBmb3Igc3ltbWV0cmljIHdl IGNhbiBrZWVwIHVzaW5nIEFFUyAyNTYgd2l0aCByZWxhdGl2ZSBjb25maWRlbmNlIChhc3N1bWlu ZywgYXMgSSBzYWlkLCB0aGF0IG5vIG5ldyBxdWFudHVtLXNwZWNpZmljDQogYWxnb3JpdGhtcyBh cmUgZGlzY292ZXJlZC4uLik8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBzdHlsZT0iYmFja2dy b3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+RG9lcyB0 aGlzIHN1bW1hcml6ZXMgdGhlIGN1cnJlbnQgc2l0dWF0aW9uPyBBcmUgdGhlc2UgKHZlcnkgc2lt cGxpc3RpYykgY29uc2lkZXJhdGlvbnMgY29ycmVjdD8gQW55Ym9keSBkaXNhZ3JlZSB3aXRoIHRo ZXNlIHN0YXRlbWVudHM/IFdoeT88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBzdHlsZT0iYmFj a2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+Q2hl ZXJzLDxicj4NCk1heDxicj4NCiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwcmUgc3R5 bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+LS0gPG86cD48 L286cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBz dHlsZT0iY29sb3I6YmxhY2siPk1hc3NpbWlsaWFubyBQYWxhLCBQaEQ8bzpwPjwvbzpwPjwvc3Bh bj48L3ByZT4NCjxwcmUgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJjb2xv cjpibGFjayI+RGlyZWN0b3IgYXQgT3BlbkNBIExhYnM8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4N CjxwcmUgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+ dHdpdHRlcjogQG9wZW5jYTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_9b3261feb368462a87e6772b1740d9ecXCHRTP006ciscocom_-- From nobody Mon Apr 11 14:35:35 2016 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CBE012F2E8 for ; Mon, 11 Apr 2016 14:35:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.516 X-Spam-Level: X-Spam-Status: No, score=-15.516 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 15dnoR7NEvXa for ; Mon, 11 Apr 2016 14:35:31 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 212A212F2D7 for ; Mon, 11 Apr 2016 14:35:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=24648; q=dns/txt; s=iport; t=1460410530; x=1461620130; h=mime-version:subject:from:in-reply-to:date:cc:message-id: references:to; bh=96nnzIWtPHy4x6qpwAmR7Wi3kMZCuF6lEo5w6jQE9nY=; b=bUEp2lvLAyMuYbNMcFSNxtskF8eliY4zlIFwQE7Rj3VdH9VM90Us3lKs DmaB5XBYH1PS4j6vgA71ZPe1P5OFx9dmDe64vMHjEhy3PICkdaiDXKBlj Bb/CJsC+9hzTL4M8hGBBje64Hui4XVy71jY25NRA3HOc0GVOe+qglCVsG U=; X-IronPort-AV: E=Sophos; i="5.24,470,1454976000"; d="scan'208,217"; a="90649780" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 11 Apr 2016 21:35:29 +0000 Received: from rtp-mcgrew-8914.cisco.com (rtp-mcgrew-8914.cisco.com [10.117.10.229]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id u3BLZSXG026506 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 11 Apr 2016 21:35:28 GMT Content-Type: multipart/alternative; boundary="Apple-Mail=_08B214B9-37AD-4670-B4BA-8A78CD4A3330" Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: David McGrew In-Reply-To: <9b3261feb368462a87e6772b1740d9ec@XCH-RTP-006.cisco.com> Date: Mon, 11 Apr 2016 17:35:27 -0400 Message-Id: <7348154A-6DDD-4737-8FBC-D18A4FBF21A5@cisco.com> References: <570BB5BC.5000705@openca.org> <9b3261feb368462a87e6772b1740d9ec@XCH-RTP-006.cisco.com> To: "Scott Fluhrer (sfluhrer)" , Grigory Marshalko X-Mailer: Apple Mail (2.3112) Archived-At: Cc: "cfrg@irtf.org" Subject: Re: [Cfrg] [MASSMAIL] Quantum Computing and Crypto Policies X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Apr 2016 21:35:34 -0000 --Apple-Mail=_08B214B9-37AD-4670-B4BA-8A78CD4A3330 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Scott and Grigory, > On Apr 11, 2016, at 5:02 PM, Scott Fluhrer (sfluhrer) = wrote: >=20 > These papers assume a very obscure attack model; where the attacker = can generate a plaintext that is a superposition of several possible = values, and have the device generate a ciphertext that is a = superposition of the encryption of the various values. <> <> > =20 > We assume that within a Quantum Computer, we somehow maintain = coherence of the various quantum states; however this attack model asks = that this coherency is not disrupted when the queries leave the Quantum = Computer. Realistically, it is hard to see how this could be = implemented over a network. Quantum Superposition is quite delicate; in = fact, the main problem we have in building a Quantum Computer is how to = maintain coherence over a nontrivial period of time =E2=80=93 it would = appear to be unlikely that the device under attack would be helpful = enough to the attacker to go through that effort. > =20 > Now, for totally public operations (hashing, public key encryption, = signature verification, whitebox cryptography), these sorts of attacks = are plausible (because someone with a Quantum Computer can perform them = entirely within the Quantum Computer, and so go through the effort of = maintaining coherence over the entire operation). However, for = attacking devices on the internet, well, it=E2=80=99s less interesting. thanks for bringing these works into the discussion. To add some more = detail and emphasis to Scott=E2=80=99s point: the attack model in these = works does not correspond to any current use of cryptography. =46rom = http://arxiv.org/pdf/1602.05973.pdf = : "We consider here a much = stronger model [than the quantum random oracle] in which, in addition to = local quantum operations, an adversary is granted an access to a = possibly remote cryptographic oracle in superposition of the inputs, and = obtains the corresponding superposition of outputs.=E2=80=9D In other = words, the results show that if you use a quantum computer to implement = your secret-key crypto scheme, and then you let the attacker use your = quantum computer, you can expect your scheme to be broken (if it is on = the list of schemes they can attack). =20 While this is a very interesting research result, the attack model is = far from any current or anticipated use of secret-key cryptography, and = thus it would be wrong to attempt to use these results to inform us in = what sort of algorithms we should be using on the Internet. =20 best David=20 > =20 > From: Cfrg [mailto:cfrg-bounces@irtf.org] On Behalf Of Grigory = Marshalko > Sent: Monday, April 11, 2016 4:49 PM > To: Dr. Pala; cfrg@irtf.org > Subject: Re: [Cfrg] [MASSMAIL] Quantum Computing and Crypto Policies > =20 > Not only described issues. > Two recent papers also address the post-quantum security of block = cipher modes and MACs. > http://arxiv.org/pdf/1602.05973.pdf = > https://eprint.iacr.org/2016/197.pdf = > Regards, > Grigory Marshalko, > expert, > Technical committee for standardisation "Cryptography and security = mechanisms" (TC 26) > www.tc26.ru >=20 > 11 =D0=B0=D0=BF=D1=80=D0=B5=D0=BB=D1=8F 2016 =D0=B3., 17:33, "Dr. = Pala" > =D0=BD=D0=B0=D0=BF=D0= =B8=D1=81=D0=B0=D0=BB: > Hi all, >=20 > At the CFRG meeting, I have appreciated the presentation about QC in = the sense that inspired to think about the future in a more practical = way (although there was probably not much agreement on how to proceed = forward). >=20 > I have also been following the conversation about the post-quantum = computing crypto resistance and I am trying to figure out - given what = we know about possible quantum computing which, as Tim pointed out = during the meeting, is still very little - what types of policies can be = implemented today that would allow us to be a bit more resilient to = attacks in the post quantum-computing environment (i.e., not being taken = by surprise since deploying of new crypto can take several years in the = real world despite the algorithm agility we have in current standards). = I will try to summarize the two main points: > Symmetric crypto is still relatively secure. Using 256bits keys (e.g., = AES 256) should provide enough confidentiality for the time being (this = is already a common practice in the industry as the overhead compared to = 128bits is negligible) - so we are relatively safe here. > Given the physical limitations when it comes to be able to have QC = with high number of qbits, it seems that when it comes to Asymmetric = crypto, ECDSA (given the limited number of bits and the impossibility to = extend the number of bits without defining new curves) is the weakest = choice compared to RSA with very long keys (e.g., 8K or 16K bits keys or = even bigger...). > In other words, given this scenario and setting aside considerations = about signature sizes (although, we have seen an increase in computing = resources in terms of processing power, bandwidth, and storage it seems = that signature size is a big concern - AFAIK, mostly driven by IoT and = similar environments - even more than 10yrs ago! and many WGs are using = the size argument over the security argument in their specifications and = suggestions), the more flexible and forward-secure choice would be to = start using "oversized" RSA keys for asymmetric and for symmetric we can = keep using AES 256 with relative confidence (assuming, as I said, that = no new quantum-specific algorithms are discovered...) >=20 > Does this summarizes the current situation? Are these (very = simplistic) considerations correct? Anybody disagree with these = statements? Why? >=20 > Cheers, > Max > =20 >=20 > --=20 > Massimiliano Pala, PhD > Director at OpenCA Labs > twitter: @openca > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > https://www.irtf.org/mailman/listinfo/cfrg --Apple-Mail=_08B214B9-37AD-4670-B4BA-8A78CD4A3330 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi Scott and Grigory,


 
We assume that within a = Quantum Computer, we somehow maintain coherence of the various quantum = states; however this attack model asks that this coherency is not = disrupted when the queries leave the Quantum Computer.  = Realistically, it is hard to see how this could be implemented over a = network.  Quantum Superposition is quite delicate; in fact, the = main problem we have in building a Quantum Computer is how to maintain = coherence over a nontrivial period of time =E2=80=93 it would appear to = be unlikely that the device under attack would be helpful enough to the = attacker to go through that effort.
 
Now, for totally public operations (hashing, = public key encryption, signature verification, whitebox cryptography), = these sorts of attacks are plausible (because someone with a Quantum = Computer can perform them entirely within the Quantum Computer, and so = go through the effort of maintaining coherence over the entire = operation).  However, for attacking devices on the internet, well, = it=E2=80=99s less = interesting.


thanks for bringing = these works into the discussion.  To add some more detail and = emphasis to Scott=E2=80=99s point: the attack model in these works does = not correspond to any current use of cryptography.  From http://arxiv.org/pdf/1602.05973.pdf:  "We consider = here a much stronger model [than the quantum random oracle] in which, in = addition to local quantum operations, an adversary is granted an access = to a possibly remote cryptographic oracle in superposition of the = inputs, and obtains the corresponding superposition of outputs.=E2=80= =9D   In other words, the results show that if you use a quantum = computer to implement your secret-key crypto scheme, and then you let = the attacker use your quantum computer, you can expect your scheme to be = broken (if it is on the list of schemes they can attack). =   

While this is a very = interesting research result, the attack model is far from any current or = anticipated use of secret-key cryptography, and thus it would be wrong = to attempt to use these results to inform us in what sort of algorithms = we should be using on the Internet.   

best

David 


 
From: Cfrg [mailto:cfrg-bounces@irtf.org] On Behalf = Of Grigory = Marshalko
Sent: Monday, April 11, 2016 4:49 = PM
To: Dr. Pala; cfrg@irtf.org
Subject: Re: [Cfrg] [MASSMAIL] = Quantum Computing and Crypto Policies
 
Not only described = issues.
Two recent papers also address the post-quantum = security of block cipher modes and MACs.
http://arxiv.org/pdf/1602.05973.pdf
https://eprint.iacr.org/2016/197.pdf
Regards,
Grigory Marshalko,
expert,
Technical committee for standardisation = "Cryptography and security mechanisms" (TC 26)
www.tc26.ru

11 = =D0=B0=D0=BF=D1=80=D0=B5=D0=BB=D1=8F 2016 =D0=B3., 17:33, "Dr. Pala" = <director@openca.org> =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0= =D0=BB:
Hi all,

At the CFRG = meeting, I have appreciated the presentation about QC in the sense that = inspired to think about the future in a more practical way (although = there was probably not much agreement on how to proceed forward).

I have also been following the conversation = about the post-quantum computing crypto resistance and I am trying to = figure out - given what we know about possible quantum computing which, = as Tim pointed out during the meeting, is still very little - what types = of policies can be implemented today that would allow us to be a bit = more resilient to attacks in the post quantum-computing environment = (i.e., not being taken by surprise since deploying of new crypto can = take several years in the real world despite the algorithm agility we = have in current standards). I will try to summarize the two main = points:
  1. Symmetric crypto is = still relatively secure. Using 256bits keys (e.g., AES 256) should = provide enough confidentiality for the time being (this is already a = common practice in the industry as the overhead compared to 128bits is = negligible) - so we are relatively safe here.
  2. Given the physical = limitations when it comes to be able to have QC with high number of = qbits, it seems that when it comes to Asymmetric crypto, ECDSA (given = the limited number of bits and the impossibility to extend the number of = bits without defining new curves) is the weakest choice compared to RSA = with very long keys (e.g., 8K or 16K bits keys or even bigger...).

In other words, given = this scenario and setting aside considerations about signature sizes = (although, we have seen an increase in computing resources in terms of = processing power, bandwidth, and storage it seems that signature size is = a big concern - AFAIK, mostly driven by IoT and similar environments - = even more than 10yrs ago! and many WGs are using the size argument over = the security argument in their specifications and suggestions), the more = flexible and forward-secure choice would be to start using "oversized" = RSA keys for asymmetric and for symmetric we can keep using AES 256 with = relative confidence (assuming, as I said, that no new quantum-specific = algorithms are discovered...)

Does this summarizes the current situation? Are = these (very simplistic) considerations correct? Anybody disagree with = these statements? Why?

Cheers,
Max
 

-- 
Massimiliano Pala, =
PhD
Director at OpenCA =
Labs
twitter: @openca
_______________________________________________
Cfrg mailing = list
Cfrg@irtf.org
https://www.irtf.org/mailman/listinfo/cfrg

= --Apple-Mail=_08B214B9-37AD-4670-B4BA-8A78CD4A3330-- From nobody Tue Apr 12 02:28:17 2016 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D36212EAC5 for ; Tue, 12 Apr 2016 02:28:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.996 X-Spam-Level: X-Spam-Status: No, score=-2.996 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=tc26.ru Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xA0iDOTwCo8V for ; Tue, 12 Apr 2016 02:28:12 -0700 (PDT) Received: from mail.tc26.ru (mail.tc26.ru [188.40.163.82]) by ietfa.amsl.com (Postfix) with ESMTP id 6E0B712EABB for ; Tue, 12 Apr 2016 02:28:12 -0700 (PDT) Received: from mail.tc26.ru (localhost [127.0.0.1]) by mail.tc26.ru (Postfix) with ESMTPSA id A2E2D300322; Tue, 12 Apr 2016 12:28:10 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.10.3 mail.tc26.ru A2E2D300322 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tc26.ru; s=mx; t=1460453291; bh=8HBcb4ZG3sj+4JnU4ZhijfEt6GPDEkgbi4OPFpfAy28=; h=Date:From:Subject:To:Cc:In-Reply-To:References:From; b=W4uZ5lwu+Sm2K3qiBBjrS6PgKKN/LK236jHvM7ymDcVFNOB3sLb7DPayVSYJjY1bJ 1jflO8B6yuoTsh3VUDoV4ZWu6LJNMp7ALSgQiGojc40FHtawwlDEH+OcolT5Jwivth PAnS0CS23OdmoxRA0NdM3UHu7LIprYLVYJOg+x7E= Mime-Version: 1.0 Date: Tue, 12 Apr 2016 09:28:10 +0000 Content-Type: multipart/alternative; boundary="--=_RainLoop_448_322431678.1460453290" Message-ID: X-Mailer: RainLoop/1.9.3.365 From: "Grigory Marshalko" To: "David McGrew" , "Scott Fluhrer (sfluhrer)" In-Reply-To: <7348154A-6DDD-4737-8FBC-D18A4FBF21A5@cisco.com> References: <7348154A-6DDD-4737-8FBC-D18A4FBF21A5@cisco.com> <570BB5BC.5000705@openca.org> <9b3261feb368462a87e6772b1740d9ec@XCH-RTP-006.cisco.com> X-KLMS-Rule-ID: 1 X-KLMS-Message-Action: clean X-KLMS-AntiSpam-Lua-Profiles: 94519 [Apr 12 2016] X-KLMS-AntiSpam-Version: 5.5.9.33 X-KLMS-AntiSpam-Envelope-From: marshalko_gb@tc26.ru X-KLMS-AntiSpam-Rate: 0 X-KLMS-AntiSpam-Status: not_detected X-KLMS-AntiSpam-Method: none X-KLMS-AntiSpam-Moebius-Timestamps: 4068408, 4068438, 4067474 X-KLMS-AntiSpam-Info: LuaCore: 419 419 24d92320b28ecafcc7e43d1a024ab7fa6f09466f, 127.0.0.200:7.1.3; mail.tc26.ru:7.1.1; eprint.iacr.org:7.1.1; www.tc26.ru:7.1.1; www.irtf.org:7.1.1; arxiv.org:4.0.4,7.1.1; d41d8cd98f00b204e9800998ecf8427e.com:7.1.1; 127.0.0.199:7.1.2; tc26.ru:7.1.1, Auth:dkim=none X-KLMS-AntiSpam-Interceptor-Info: scan successful X-KLMS-AntiPhishing: Clean, 2016/04/11 08:42:06 X-KLMS-AntiVirus: Kaspersky Security 8.0 for Linux Mail Server, version 8.0.1.721, bases: 2016/04/11 19:38:00 #7480646 X-KLMS-AntiVirus-Status: Clean, skipped Archived-At: Cc: cfrg@irtf.org Subject: Re: [Cfrg] [MASSMAIL] Quantum Computing and Crypto Policies X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2016 09:28:15 -0000 ----=_RainLoop_448_322431678.1460453290 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi David and Scott,=0A=0AI completely agree with you, nevertheless I supp= ose It should be usefull at least to keep this pubs in mind as a possible= new trend of research=0A=0ARegards,=0AGrigory Marshalko,=0Aexpert,=0ATec= hnical committee for standardisation "Cryptography and security mechanism= s" (TC 26)=0Awww.tc26.ru=0A=0A12 =D0=B0=D0=BF=D1=80=D0=B5=D0=BB=D1=8F 201= 6 =D0=B3., 00:35, "David McGrew" =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0= =BB:=0AHi Scott and Grigory,=0A=C2=A0=0A=C2=A0=0AOn Apr 11, 2016, at 5:02= PM, Scott Fluhrer (sfluhrer) wrote:=C2=A0=0AThese papers assume a very = obscure attack model; where the attacker can generate a plaintext that is= a superposition of several possible values, and have the device generate= a ciphertext that is a superposition of the encryption of the various va= lues.=C2=A0=0A =C2=A0We assume that within a Quantum Computer, we somehow= maintain coherence of the various quantum states; however this attack mo= del asks that this coherency is not disrupted when the queries leave the = Quantum Computer.=C2=A0 Realistically, it is hard to see how this could b= e implemented over a network. =C2=A0Quantum Superposition is quite delica= te; in fact, the main problem we have in building a Quantum Computer is h= ow to maintain coherence over a nontrivial period of time =E2=80=93 it wo= uld appear to be unlikely that the device under attack would be helpful e= nough to the attacker to go through that effort.=0A=0A =C2=A0Now, for tot= ally public operations (hashing, public key encryption, signature verific= ation, whitebox cryptography), these sorts of attacks are plausible (beca= use someone with a Quantum Computer can perform them entirely within the = Quantum Computer, and so go through the effort of maintaining coherence o= ver the entire operation).=C2=A0 However, for attacking devices on the in= ternet, well, it=E2=80=99s less interesting.=0Athanks for bringing these = works into the discussion. =C2=A0To add some more detail and emphasis to = Scott=E2=80=99s point: the attack model in these works does not correspon= d to any current use of cryptography. =C2=A0From=C2=A0http://arxiv.org/pd= f/1602.05973.pdf (http://arxiv.org/pdf/1602.05973.pdf): =C2=A0"We conside= r here a much stronger model [than the quantum random oracle] in which, i= n addition to local quantum operations, an adversary is granted an access= to a possibly remote cryptographic oracle in superposition of the inputs= , and obtains the corresponding=C2=A0superposition of outputs.=E2=80=9D = =C2=A0 In other words, the results show that if you use a quantum compute= r to implement your secret-key crypto scheme, and then you let the attack= er use your quantum computer, you can expect your scheme to be broken (if= it is on the list of schemes they can attack). =C2=A0=C2=A0=0A=0AWhile t= his is a very interesting research result, the attack model is far from a= ny current or anticipated use of secret-key cryptography, and thus it wou= ld be wrong to attempt to use these results to inform us in what sort of = algorithms we should be using on the Internet. =C2=A0=C2=A0=0A=0Abest=0A= =0ADavid=C2=A0=0A=C2=A0=0A =C2=A0=0AFrom:=C2=A0Cfrg [mailto:cfrg-bounces@= irtf.org (mailto:cfrg-bounces@irtf.org)]=C2=A0On Behalf Of=C2=A0Grigory M= arshalko=0ASent:=C2=A0Monday, April 11, 2016 4:49 PM=0ATo:=C2=A0Dr. Pala;= cfrg@irtf.org (mailto:cfrg@irtf.org)=0ASubject:=C2=A0Re: [Cfrg] [MASSMAI= L] Quantum Computing and Crypto Policies=0ANot only described issues.=0AT= wo recent papers also address the post-quantum security of block cipher m= odes and MACs.=0Ahttp://arxiv.org/pdf/1602.05973.pdf (http://arxiv.org/pd= f/1602.05973.pdf)=0Ahttps://eprint.iacr.org/2016/197.pdf (https://eprint.= iacr.org/2016/197.pdf)=0ARegards,=0AGrigory Marshalko,=0Aexpert,=0ATechni= cal committee for standardisation "Cryptography and security mechanisms" = (TC 26)=0Awww.tc26.ru (http://www.tc26.ru/)=0A=0A11 =D0=B0=D0=BF=D1=80=D0= =B5=D0=BB=D1=8F 2016 =D0=B3., 17:33, "Dr. Pala" =D0=BD=D0=B0=D0=BF=D0=B8= =D1=81=D0=B0=D0=BB:=0A=0AHi all,=0A=0AAt the CFRG meeting, I have appreci= ated the presentation about QC in the sense that inspired to think about = the future in a more practical way (although there was probably not much = agreement on how to proceed forward).=0A=0AI have also been following the= conversation about the post-quantum computing crypto resistance and I am= trying to figure out - given what we know about possible quantum computi= ng which, as Tim pointed out during the meeting, is still very little - w= hat types of policies can be implemented today that would allow us to be = a bit more resilient to attacks in the post quantum-computing environment= (i.e., not being taken by surprise since deploying of new crypto can tak= e several years in the real world despite the algorithm agility we have i= n current standards). I will try to summarize the two main points:=0A * S= ymmetric crypto is still relatively secure. Using 256bits keys (e.g., AES= 256) should provide enough confidentiality for the time being (this is a= lready a common practice in the industry as the overhead compared to 128b= its is negligible) - so we are relatively safe here.=0A * Given the physi= cal limitations when it comes to be able to have QC with high number of q= bits, it seems that when it comes to Asymmetric crypto, ECDSA (given the = limited number of bits and the impossibility to extend the number of bits= without defining new curves) is the weakest choice compared to RSA with = very long keys (e.g., 8K or 16K bits keys or even bigger...).=0A In other= words, given this scenario and setting aside considerations about signat= ure sizes (although, we have seen an increase in computing resources in t= erms of processing power, bandwidth, and storage it seems that signature = size is a big concern - AFAIK, mostly driven by IoT and similar environme= nts - even more than 10yrs ago! and many WGs are using the size argument = over the security argument in their specifications and suggestions), the = more flexible and forward-secure choice would be to start using "oversize= d" RSA keys for asymmetric and for symmetric we can keep using AES 256 wi= th relative confidence (assuming, as I said, that no new quantum-specific= algorithms are discovered...)=0A=0A Does this summarizes the current sit= uation? Are these (very simplistic) considerations correct? Anybody disag= ree with these statements? Why?=0A=0A Cheers,=0AMax=0A=C2=A0=0A=0A -- =0A= =0A Massimiliano Pala, PhD=0A=0A Director at OpenCA Labs=0A=0A twitter: @= openca_______________________________________________=0ACfrg mailing list= =0ACfrg@irtf.org (mailto:Cfrg@irtf.org)=0Ahttps://www.irtf.org/mailman/li= stinfo/cfrg (https://www.irtf.org/mailman/listinfo/cfrg) ----=_RainLoop_448_322431678.1460453290 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable
H= i David and Scott,

I completely agree with you, nevertheless I sup= pose It should be usefull at least to keep this pubs in mind as a possibl= e new trend of research

Regards,
Grigory Marshalko,
expert,<= br>Technical committee for standardisation "Cryptography and security mec= hanisms" (TC 26)
www.tc26.ru

12 =D0=B0=D0=BF=D1=80=D0=B5=D0=BB= =D1=8F 2016 =D0=B3., 00:35, "David McGrew" <mcgrew@cisco.com> =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB:
Hi Scott and Grigory,
=C2=A0=
=C2=A0
On Apr 11, 2016, at 5:02 PM, Sc= ott Fluhrer (sfluhrer) <sfluhrer@cisco.com> wrote:
=C2=A0
=C2=A0

<= span style=3D"font-size: 11pt;font-family: Calibri, sans-serif">=C2=A0

We assume that within a Quantum Computer, we s= omehow maintain coherence of the various quantum states; however this att= ack model asks that this coherency is not disrupted when the queries leav= e the Quantum Computer.=C2=A0 Realistically, it is hard to see how this c= ould be implemented over a network. =C2=A0Quantum Superposition is quite = delicate; in fact, the main problem we have in building a Quantum Compute= r is how to maintain coherence over a nontrivial period of time =E2=80=93= it would appear to be unlikely that the device under attack would be hel= pful enough to the attacker to go through that effort.

=C2=A0

Now, for totally public ope= rations (hashing, public key encryption, signature verification, whitebox= cryptography), these sorts of attacks are plausible (because someone wit= h a Quantum Computer can perform them entirely within the Quantum Compute= r, and so go through the effort of maintaining coherence over the entire = operation).=C2=A0 However, for attacking devices on the internet, well, i= t=E2=80=99s less interesting.
<= /div>
thanks for bringing these works into the discus= sion. =C2=A0To add some more detail and emphasis to Scott=E2=80=99s point= : the attack model in these works does not correspond to any current use = of cryptography. =C2=A0From=C2=A0http:= //arxiv.org/pdf/1602.05973.pdf: =C2=A0"We consider here a much strong= er model [than the quantum random oracle] in which, in addition to local = quantum operations, an adversary is granted an access to a possibly remot= e cryptographic oracle in superposition of the inputs, and obtains the co= rresponding=C2=A0superposition of outputs.=E2=80=9D =C2=A0 In other words= , the results show that if you use a quantum computer to implement your s= ecret-key crypto scheme, and then you let the attacker use your quantum c= omputer, you can expect your scheme to be broken (if it is on the list of= schemes they can attack). =C2=A0=C2=A0
While this i= s a very interesting research result, the attack model is far from any cu= rrent or anticipated use of secret-key cryptography, and thus it would be= wrong to attempt to use these results to inform us in what sort of algor= ithms we should be using on the Internet. =C2=A0=C2=A0
best
David=C2=A0


= =C2=A0

=C2=A0

From:=C2=A0Cfrg [mailto:cfrg-bounces@irtf.org]=C2=A0On Behal= f Of=C2=A0Grigory Marshalko
Sent:=C2=A0<= /span>Monday, April 11, 2016 4:49 PM
To:=C2=A0Dr. = Pala; cfrg@irtf.org
Subject:=C2= =A0Re: [Cfrg] [MASSMAIL] Quantum Computing and Crypto Policies
Not only = described issues.
Two recent papers also address the post-quantum secu= rity of block cipher modes and MACs.
http://arxiv.org/pdf= /1602.05973.pdf
https://eprint.iacr.org/2016/197.pdf=
Regards,
Grigory Marshalko,
expert,
Technical committee = for standardisation "Cryptography and security mechanisms" (TC 26)
www.tc= 26.ru

11 =D0=B0=D0=BF=D1=80=D0=B5=D0=BB=D1=8F 2016 =D0=B3., 17= :33, "Dr. Pala" <director@openca.org&= gt; =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB:
Hi all,

At the CFRG meeting, I hav= e appreciated the presentation about QC in the sense that inspired to thi= nk about the future in a more practical way (although there was probably = not much agreement on how to proceed forward).

I have also been fo= llowing the conversation about the post-quantum computing crypto resistan= ce and I am trying to figure out - given what we know about possible quan= tum computing which, as Tim pointed out during the meeting, is still very= little - what types of policies can be implemented today that would allo= w us to be a bit more resilient to attacks in the post quantum-computing = environment (i.e., not being taken by surprise since deploying of new cry= pto can take several years in the real world despite the algorithm agilit= y we have in current standards). I will try to summarize the two main poi= nts:
    =
  1. Symmetric crypto is still relatively se= cure. Using 256bits keys (e.g., AES 256) should provide enough confidenti= ality for the time being (this is already a common practice in the indust= ry as the overhead compared to 128bits is negligible) - so we are relativ= ely safe here.
  2. Given the phy= sical limitations when it comes to be able to have QC with high number of= qbits, it seems that when it comes to Asymmetric crypto, ECDSA (given th= e limited number of bits and the impossibility to extend the number of bi= ts without defining new curves) is the weakest choice compared to RSA wit= h very long keys (e.g., 8K or 16K bits keys or even bigger...).

In other words, given th= is scenario and setting aside considerations about signature sizes (altho= ugh, we have seen an increase in computing resources in terms of processi= ng power, bandwidth, and storage it seems that signature size is a big co= ncern - AFAIK, mostly driven by IoT and similar environments - even more = than 10yrs ago! and many WGs are using the size argument over the securit= y argument in their specifications and suggestions), the more flexible an= d forward-secure choice would be to start using "oversized" RSA keys for = asymmetric and for symmetric we can keep using AES 256 with relative conf= idence (assuming, as I said, that no new quantum-specific algorithms are = discovered...)

Does t= his summarizes the current situation? Are these (very simplistic) conside= rations correct? Anybody disagree with these statements? Why?

<= p style=3D"margin-right: 0in;margin-left: 0in;font-size: 12pt;font-family= : 'Times New Roman', serif;background-color: white;background-position: i= nitial initial;background-repeat: initial initial">Cheers,
Max
=C2=A0
<= /p>
-- 
Massimiliano Pala, PhD
Director at Ope=
nCA Labs
tw=
itter: @openca
_______________________________________________
Cfrg mailing list

Cfrg@irtf.org
https= ://www.irtf.org/mailman/listinfo/cfrg
=
----=_RainLoop_448_322431678.1460453290-- From nobody Tue Apr 12 13:22:19 2016 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35B0F12DEA7 for ; Tue, 12 Apr 2016 13:22:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zAovfoSnFgNk for ; Tue, 12 Apr 2016 13:22:13 -0700 (PDT) Received: from smtp-p01.blackberry.com (smtp-p01.blackberry.com [208.65.78.88]) by ietfa.amsl.com (Postfix) with ESMTP id D363612DE9F for ; Tue, 12 Apr 2016 13:22:12 -0700 (PDT) Received: from xct101cnc.rim.net ([10.65.161.201]) by mhs212cnc.rim.net with ESMTP/TLS/AES256-SHA; 12 Apr 2016 17:59:16 -0400 Received: from XMB116CNC.rim.net ([fe80::45d:f4fe:6277:5d1b]) by XCT101CNC.rim.net ([fe80::9c22:d9c:c906:c488%16]) with mapi id 14.03.0210.002; Tue, 12 Apr 2016 16:21:58 -0400 From: Dan Brown To: "cfrg@irtf.org" , "cfrg@ietf.org" Thread-Topic: Re-examine HMAC for non-MAC uses? Thread-Index: AdGU9o8Ranwwyq5vTIOnveNdXuTb6w== Date: Tue, 12 Apr 2016 20:21:58 +0000 Message-ID: <810C31990B57ED40B2062BA10D43FBF5F26ADE@XMB116CNC.rim.net> Accept-Language: en-US, en-CA Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.160.246] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [Cfrg] Re-examine HMAC for non-MAC uses? X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2016 20:22:18 -0000 >From http://eprint.iacr.org/2016/360 "Aside from the issue of the tightness gaps, there is another fundamental r= eason why the theorems in [12, 14, 57] about security of NMAC and HMAC under the PRF-assu= mption offer little practical assurance. To the best of our knowledge, the PRF-ass= umption has never been seriously studied for the compression functions used in MD5, SHA1, or = SHA256; in fact, we are not aware of a single paper that treats this question. Moreove= r, when those compression functions were constructed, the PRF-property was not regarded as something = that had to be satisfied - rather, they were constructed for the purpose of coll= ision-resistance and pre-image resistance. Thus, in the case of the concrete hash functions = used in practice, we have no evidence that could rule out attacks on the PRF-property ... We conclude this section with a recommendation. Standards bodies should ree= xamine - taking into account tightness gaps - the security of all standardized pro= tocols that use HMAC for non-MAC purposes such as key derivation or passwords. The same sho= uld be done for HMAC-protocols using hash functions such as MD5 or SHA1 that are n= ot believed to have weak collision-resistance in the sense of [17]." Do some (newly proposed and amendable) IETF protocols still use HMAC for ke= y derivation, e.g. TLS (via HKDF)? If so, then should CFRG, per the academ= ic recommendation above, re-examine such usage? I've occasionally wondered= similar things, but I do not yet have any clear thoughts on the issue. =20 Best regards, Daniel Brown Research In Motion Limited From nobody Tue Apr 12 13:22:29 2016 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6969912DE9F for ; Tue, 12 Apr 2016 13:22:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OibRhvqFdebI for ; Tue, 12 Apr 2016 13:22:13 -0700 (PDT) Received: from smtp-p01.blackberry.com (smtp-p01.blackberry.com [208.65.78.88]) by ietfa.amsl.com (Postfix) with ESMTP id D353612DD92 for ; Tue, 12 Apr 2016 13:22:12 -0700 (PDT) Received: from xct101cnc.rim.net ([10.65.161.201]) by mhs212cnc.rim.net with ESMTP/TLS/AES256-SHA; 12 Apr 2016 17:59:16 -0400 Received: from XMB116CNC.rim.net ([fe80::45d:f4fe:6277:5d1b]) by XCT101CNC.rim.net ([fe80::9c22:d9c:c906:c488%16]) with mapi id 14.03.0210.002; Tue, 12 Apr 2016 16:21:58 -0400 From: Dan Brown To: "cfrg@irtf.org" , "cfrg@ietf.org" Thread-Topic: Re-examine HMAC for non-MAC uses? Thread-Index: AdGU9o8Ranwwyq5vTIOnveNdXuTb6w== Date: Tue, 12 Apr 2016 20:21:58 +0000 Message-ID: <810C31990B57ED40B2062BA10D43FBF5F26ADE@XMB116CNC.rim.net> Accept-Language: en-US, en-CA Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.160.246] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [Cfrg] Re-examine HMAC for non-MAC uses? X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2016 20:22:19 -0000 >From http://eprint.iacr.org/2016/360 "Aside from the issue of the tightness gaps, there is another fundamental r= eason why the theorems in [12, 14, 57] about security of NMAC and HMAC under the PRF-assu= mption offer little practical assurance. To the best of our knowledge, the PRF-ass= umption has never been seriously studied for the compression functions used in MD5, SHA1, or = SHA256; in fact, we are not aware of a single paper that treats this question. Moreove= r, when those compression functions were constructed, the PRF-property was not regarded as something = that had to be satisfied - rather, they were constructed for the purpose of coll= ision-resistance and pre-image resistance. Thus, in the case of the concrete hash functions = used in practice, we have no evidence that could rule out attacks on the PRF-property ... We conclude this section with a recommendation. Standards bodies should ree= xamine - taking into account tightness gaps - the security of all standardized pro= tocols that use HMAC for non-MAC purposes such as key derivation or passwords. The same sho= uld be done for HMAC-protocols using hash functions such as MD5 or SHA1 that are n= ot believed to have weak collision-resistance in the sense of [17]." Do some (newly proposed and amendable) IETF protocols still use HMAC for ke= y derivation, e.g. TLS (via HKDF)? If so, then should CFRG, per the academ= ic recommendation above, re-examine such usage? I've occasionally wondered= similar things, but I do not yet have any clear thoughts on the issue. =20 Best regards, Daniel Brown Research In Motion Limited From nobody Tue Apr 12 18:31:55 2016 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1732412D915 for ; Tue, 12 Apr 2016 18:31:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_20=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DbwCtLIOsA-G for ; Tue, 12 Apr 2016 18:31:51 -0700 (PDT) Received: from mail.proper.com (Opus1.Proper.COM [207.182.41.91]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E06312D6E6 for ; Tue, 12 Apr 2016 18:31:45 -0700 (PDT) Received: from [10.32.60.122] (50-1-98-216.dsl.dynamic.fusionbroadband.com [50.1.98.216]) (authenticated bits=0) by mail.proper.com (8.15.2/8.14.9) with ESMTPSA id u3D1Vgsw073916 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 12 Apr 2016 18:31:43 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: mail.proper.com: Host 50-1-98-216.dsl.dynamic.fusionbroadband.com [50.1.98.216] claimed to be [10.32.60.122] From: "Paul Hoffman" To: cfrg@irtf.org Date: Tue, 12 Apr 2016 18:31:41 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.4r5234) Archived-At: Subject: [Cfrg] Exposing the private key by signing "too many times" X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2016 01:31:53 -0000 Greetings again. I regularly hear from non-cryptographers that they once heard that you have to be careful not to sign "too many times" with the same public/private pair because doing so will expose the private key. I'm interested in the history of this belief. Are there any papers about the history of signature algorithms where this might have been true, or papers on the history of this belief? --Paul Hoffman From nobody Tue Apr 12 19:01:53 2016 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1E8912DA65 for ; Tue, 12 Apr 2016 19:01:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.4 X-Spam-Level: X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CyyZLT-7bq89 for ; Tue, 12 Apr 2016 19:01:50 -0700 (PDT) Received: from mail-lf0-x233.google.com (mail-lf0-x233.google.com [IPv6:2a00:1450:4010:c07::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1297B12D9EE for ; Tue, 12 Apr 2016 19:01:50 -0700 (PDT) Received: by mail-lf0-x233.google.com with SMTP id j11so49863847lfb.1 for ; Tue, 12 Apr 2016 19:01:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc; bh=CKqOAz7C5Zk/pf2SVkopqojzrvOGmDpe349fmgfUHIY=; b=GKK0/4S0HaGENb4p2ose02GVpVkXN+c0gYXJtwqQPuWqUqXm/ER8PHf7KtsIwF/lHE d+rRML2Hzf+FBANINrFXKHkFNYieSAgV0rOCc9lJ4wDDeY9PF8avWGv1RZT48+ZrYrKH Hr2mFczIHvSBRxOdIW1x/plLa391jxrmr/ftiCERiwX50yRZVsETuG7GDDo8vlrnIGr2 be7GFsvq1KT7gLPc1j9Do2jTjk/SkkV7i/palrc5yaoXfM5U+q6/GZ317L3C/Hie1p8M ygf/+bypsK2vztWbLizvtaFSwmCbKGL/pIX2IIXzrgd+oXjmU9zde8rdqrz6WVrv315I 3LUw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=CKqOAz7C5Zk/pf2SVkopqojzrvOGmDpe349fmgfUHIY=; b=KvziRx7b5TQbTY5ESE+rmxrkjfDEQ5bA3UAc1YtG1pkeFyrZ2Nig62SUTe14OjFXEj k0nHeGDlKLH4EbKDF93/cDtAFhOch0pFVCrfTCdZmktvb4eCyqA3B4a7EhHdjGb55fZz BOunVs1gSlsjJ9fKIZx+sEbeIq3XLAKhtPXtUG7hPvCMBN5xQL8SujrTvErjN2IvIK8m t92CBLEyMniUSQtN9Mockkqz+tm5DS4mD+XOj1ZHbxZ7igUNaYTrTI2GRdgcheePBf3n kblYFlcOlBPj+vJcOK1I29kLiTFubVaZUOiuW2ZXuHQ1DDdHOaVork11Rz+m4UGfHR3g 5Egg== X-Gm-Message-State: AOPr4FXLIVWpmeUgkj/eSUkqT5hilly7EsN8nqwTk57aJWZXNYoXdXsLg9aSXbgAw0JkmXHhW89BeTSanUke3A== MIME-Version: 1.0 X-Received: by 10.112.85.43 with SMTP id e11mr3027816lbz.80.1460512908249; Tue, 12 Apr 2016 19:01:48 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.112.151.67 with HTTP; Tue, 12 Apr 2016 19:01:48 -0700 (PDT) In-Reply-To: References: Date: Tue, 12 Apr 2016 23:01:48 -0300 X-Google-Sender-Auth: hrWeSWdDqDIvF2ibMrDd-XxxbEU Message-ID: From: Phillip Hallam-Baker To: Paul Hoffman Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "cfrg@irtf.org" Subject: Re: [Cfrg] Exposing the private key by signing "too many times" X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2016 02:01:52 -0000 Probably some confused bunnies who have been told that if you reuse a random secret in DSA, bad things happen On Tue, Apr 12, 2016 at 10:31 PM, Paul Hoffman wrote: > Greetings again. I regularly hear from non-cryptographers that they once > heard that you have to be careful not to sign "too many times" with the same > public/private pair because doing so will expose the private key. I'm > interested in the history of this belief. Are there any papers about the > history of signature algorithms where this might have been true, or papers > on the history of this belief? > > --Paul Hoffman > > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > https://www.irtf.org/mailman/listinfo/cfrg From nobody Tue Apr 12 19:05:30 2016 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE8C112DA2F for ; Tue, 12 Apr 2016 19:05:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.197 X-Spam-Level: X-Spam-Status: No, score=-5.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.996, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 01mnm7wsxwad for ; Tue, 12 Apr 2016 19:05:27 -0700 (PDT) Received: from limerock03.mail.cornell.edu (limerock03.mail.cornell.edu [128.84.13.243]) by ietfa.amsl.com (Postfix) with ESMTP id 9D37F12D85A for ; Tue, 12 Apr 2016 19:05:26 -0700 (PDT) X-CornellRouted: This message has been Routed already. Received: from exchange.cornell.edu (sf-e2013-01.exchange.cornell.edu [10.22.40.48]) by limerock03.mail.cornell.edu (8.14.4/8.14.4_cu) with ESMTP id u3D25OTp023843 for ; Tue, 12 Apr 2016 22:05:24 -0400 Received: from sf-e2013-07.exchange.cornell.edu (10.22.40.54) by sf-e2013-01.exchange.cornell.edu (10.22.40.48) with Microsoft SMTP Server (TLS) id 15.0.1130.7; Tue, 12 Apr 2016 22:05:24 -0400 Received: from mail-wm0-f48.google.com (74.125.82.48) by exchange.cornell.edu (10.22.40.54) with Microsoft SMTP Server (TLS) id 15.0.1130.7 via Frontend Transport; Tue, 12 Apr 2016 22:05:23 -0400 Received: by mail-wm0-f48.google.com with SMTP id v188so148797772wme.1 for ; Tue, 12 Apr 2016 19:05:23 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=iohvgH9ahA9FbUh3YxtE4L8RBJ3VXgwAnLXV0/D7pIM=; b=RwbjYDaaPPH6qVPH9zJJMHEuN15bUjcHr3hlO+uzaq9JcWKJGJDas3/Gq1DF5FQ6t0 KJFfhdRTdvf5Q0frjCHhEWLE8Q7et/KJqFZEDuFSaLFrgDd7/XLBONJ1slwRiSdTh/gL hOzJXGjN5TCHoHi8f5KyqKBc8Cq82bPEpL/pR709X43S0xbc1qRbOM3jA44jOD50b6ku tXtyBmVq2rCNRGpnYX6I2M0LYF7lLBcd9WfNFiTZgDn9S21BziVESe7M8Rd2qAsa8UTs IQxCC+KOh2+D7tYdQCMtW55yKp9sE7k8pZhxcyaiC6vs2OG88ZDOpsjBsE5P+Q7Sw3Ns AX0Q== X-Gm-Message-State: AD7BkJK5fxUeKHrCRH9hCoId8sben97BRCISt7XK530BrdyAwWffg9JqPnbayoi0DKflVsdvmneKrYr8pShKrQNTaJz9JmD7X1gEA8TCX0D0Aqu0jmbRwQwwszohF2a0eY14roCBxDLhC3XDjPa3gj6M2H8= X-Received: by 10.28.177.132 with SMTP id a126mr26766539wmf.86.1460513123018; Tue, 12 Apr 2016 19:05:23 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.28.177.132 with SMTP id a126mr26766533wmf.86.1460513122846; Tue, 12 Apr 2016 19:05:22 -0700 (PDT) Received: by 10.28.217.149 with HTTP; Tue, 12 Apr 2016 19:05:22 -0700 (PDT) In-Reply-To: References: Date: Tue, 12 Apr 2016 22:05:22 -0400 Message-ID: From: Paul Grubbs To: Paul Hoffman Content-Type: multipart/alternative; boundary="001a114534c6e09f560530543593" Received-SPF: Neutral (sf-e2013-01.exchange.cornell.edu: 74.125.82.48 is neither permitted nor denied by domain of pag225@cornell.edu) X-ORG-HybridRouting: 737af48ba79ab5db06efa015fd99a58b Archived-At: Cc: "cfrg@irtf.org" Subject: Re: [Cfrg] Exposing the private key by signing "too many times" X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2016 02:05:29 -0000 --001a114534c6e09f560530543593 Content-Type: text/plain; charset="UTF-8" This might not be what you mean, but historically some of the first signature constructions were what are called 'one-time signatures', which means basically what it says. Modern signature constructions are proved secure relative to a definition that allows multiple signings with the same key, though. In the realm of hash-based signatures this still comes up, because some hash-based signatures bootstrap a one-time or 'few-time' signature to a many-time signature. This is (I think) how XMSS and SPHINCS work, though I am not an expert in this area. On Tue, Apr 12, 2016 at 9:31 PM, Paul Hoffman wrote: > Greetings again. I regularly hear from non-cryptographers that they once > heard that you have to be careful not to sign "too many times" with the > same public/private pair because doing so will expose the private key. I'm > interested in the history of this belief. Are there any papers about the > history of signature algorithms where this might have been true, or papers > on the history of this belief? > > --Paul Hoffman > > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > https://www.irtf.org/mailman/listinfo/cfrg > --001a114534c6e09f560530543593 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
This might not be what you mean, but historically some of = the first signature constructions were what are called 'one-time signat= ures', which means basically what it says. Modern signature constructio= ns are proved secure relative to a definition that allows multiple signings= with the same key, though. In the realm of hash-based signatures this stil= l comes up, because some hash-based signatures bootstrap a one-time or '= ;few-time' signature to a many-time signature. This is (I think) how XM= SS and SPHINCS work, though I am not an expert in this area.

On Tue, Apr 12, 2016 at 9:= 31 PM, Paul Hoffman <paul.hoffman@vpnc.org> wrote:
Greetings again. I regularly hear from non-cry= ptographers that they once heard that you have to be careful not to sign &q= uot;too many times" with the same public/private pair because doing so= will expose the private key. I'm interested in the history of this bel= ief. Are there any papers about the history of signature algorithms where t= his might have been true, or papers on the history of this belief?

--Paul Hoffman

_______________________________________________
Cfrg mailing list
Cfrg@irtf.org
https://www.irtf.org/mailman/listinfo/cfrg

--001a114534c6e09f560530543593-- From nobody Tue Apr 12 19:07:20 2016 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C256412DC2D for ; Tue, 12 Apr 2016 19:07:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.4 X-Spam-Level: X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SCDwhrBLV8iF for ; Tue, 12 Apr 2016 19:07:17 -0700 (PDT) Received: from mail-lf0-x234.google.com (mail-lf0-x234.google.com [IPv6:2a00:1450:4010:c07::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E5E6312DB94 for ; Tue, 12 Apr 2016 19:07:16 -0700 (PDT) Received: by mail-lf0-x234.google.com with SMTP id c126so50110108lfb.2 for ; Tue, 12 Apr 2016 19:07:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc; bh=cRjBLSptnTFm/880na5XXvl3CRDZK7Lrkv7qtmk6upc=; b=p8laKvYfoDBgsm3mESWMfYlHsCXo/zFuLNFdFz/KrcaWE6GjIjpOOFtP91+JcwG9DI 22LHO6d8oXdETb2jn/Zv+wCnO1T5SZL8pm3G927/slFKjLoIhFitfsgaC62tHEDPFRwC QwuFjfmhfYeiQ4tPaM058Jxk9COfJG03XvnuDKonUoZCbqgkbGXJwjvkENxcmK9W2XwE 0Th4xA2AQqN1Z6STZxqo6iNXnksApToSZH1AO4Mdd8xzEbyXvx/C0O+hf6DggeCOPqbB fPWbQbYth14psDilkgRNNxt/tHP3rfDYZc/Xp4xHsu0NtF4qCwG9lx4I4zs9Z/ScLPoN r2cA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=cRjBLSptnTFm/880na5XXvl3CRDZK7Lrkv7qtmk6upc=; b=eNQ5B/3nEpkZftlsgJelDjHwXWiXwSamM6lP8F0T3o9kMNTVWZ0MA2oDJTyRpPBbV6 Acbjhbj+7XcciFFF4f5EbIpAeyRPDx+jKTwZxkAk/iCYLxDo7rsq4Y0mx82U8a2dX8dd qFAfIXvmb29QxFIwrBupyBknvikWfHAmAbs0S/yFgrQAp4tzSz2nhkdYfSTqSGItU3Ln d1w4uzWbfFBh2cHpbK+gFQYXDk5PFR8/6HhTzbxYT9hYrhO5cG6KHYNK4k9DvpQsJ++e YLIZlz9NZBt2+X3bSFrA5D1mMuPohm6im2poMjVnfuACRW17pL3+e5m4TvtWUCfC7Doo ydiA== X-Gm-Message-State: AOPr4FWEAPlgZHGJKLOGNJU9YWjxRCdutYtGJr3zhEShEu35PkYYI9avY7RP/7pucZlIFSpY8In2v5hAr2DNQg== MIME-Version: 1.0 X-Received: by 10.112.181.38 with SMTP id dt6mr2891003lbc.114.1460513235192; Tue, 12 Apr 2016 19:07:15 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.112.151.67 with HTTP; Tue, 12 Apr 2016 19:07:15 -0700 (PDT) In-Reply-To: References: Date: Tue, 12 Apr 2016 23:07:15 -0300 X-Google-Sender-Auth: vvk66iCYpVDIW8wxEtnoOYYxMTQ Message-ID: From: Phillip Hallam-Baker To: Paul Grubbs Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "cfrg@irtf.org" , Paul Hoffman Subject: Re: [Cfrg] Exposing the private key by signing "too many times" X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2016 02:07:19 -0000 Ah yes, look at Lamport hash sigs, can only use those once! On Tue, Apr 12, 2016 at 11:05 PM, Paul Grubbs wrote: > This might not be what you mean, but historically some of the first > signature constructions were what are called 'one-time signatures', which > means basically what it says. Modern signature constructions are proved > secure relative to a definition that allows multiple signings with the same > key, though. In the realm of hash-based signatures this still comes up, > because some hash-based signatures bootstrap a one-time or 'few-time' > signature to a many-time signature. This is (I think) how XMSS and SPHINCS > work, though I am not an expert in this area. > > On Tue, Apr 12, 2016 at 9:31 PM, Paul Hoffman wrote: >> >> Greetings again. I regularly hear from non-cryptographers that they once >> heard that you have to be careful not to sign "too many times" with the same >> public/private pair because doing so will expose the private key. I'm >> interested in the history of this belief. Are there any papers about the >> history of signature algorithms where this might have been true, or papers >> on the history of this belief? >> >> --Paul Hoffman >> >> _______________________________________________ >> Cfrg mailing list >> Cfrg@irtf.org >> https://www.irtf.org/mailman/listinfo/cfrg > > > > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > https://www.irtf.org/mailman/listinfo/cfrg > From nobody Tue Apr 12 21:54:52 2016 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F31E12E105 for ; Tue, 12 Apr 2016 21:54:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.896 X-Spam-Level: X-Spam-Status: No, score=-2.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.996] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ypdjP_7-I6mi for ; Tue, 12 Apr 2016 21:54:49 -0700 (PDT) Received: from jupiter.mumble.net (jupiter.mumble.net [74.50.56.165]) by ietfa.amsl.com (Postfix) with ESMTP id CFF8F12E0D9 for ; Tue, 12 Apr 2016 21:54:48 -0700 (PDT) Received: by jupiter.mumble.net (Postfix, from userid 1014) id 7FC5D60319; Wed, 13 Apr 2016 04:53:23 +0000 (UTC) From: Taylor R Campbell To: Paul Hoffman In-reply-to: (paul.hoffman@vpnc.org) Date: Wed, 13 Apr 2016 04:54:47 +0000 Sender: Taylor R Campbell User-Agent: IMAIL/1.21; Edwin/3.116; MIT-Scheme/9.1.99 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20160413045323.7FC5D60319@jupiter.mumble.net> Archived-At: Cc: cfrg@irtf.org Subject: Re: [Cfrg] Exposing the private key by signing "too many times" X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2016 04:54:51 -0000 Date: Tue, 12 Apr 2016 18:31:41 -0700 From: "Paul Hoffman" Greetings again. I regularly hear from non-cryptographers that they once heard that you have to be careful not to sign "too many times" with the same public/private pair because doing so will expose the private key. I'm interested in the history of this belief. Are there any papers about the history of signature algorithms where this might have been true, or papers on the history of this belief? One of the patented post-quantum candidates, the NTRU signature scheme, exhibits this property -- summary and references can be found at the Wikipedia article: https://en.wikipedia.org/wiki/NTRUSign From nobody Tue Apr 12 22:06:10 2016 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FE3512DEA8 for ; Tue, 12 Apr 2016 22:06:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XADk6tF6dVur for ; Tue, 12 Apr 2016 22:06:07 -0700 (PDT) Received: from ipxbvo.tcif.telstra.com.au (ipxbvo.tcif.telstra.com.au [203.35.135.204]) by ietfa.amsl.com (Postfix) with ESMTP id 122AC12DAF1 for ; Tue, 12 Apr 2016 22:06:05 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.24,478,1454936400"; d="scan'208";a="71685529" Received: from unknown (HELO ipcavi.tcif.telstra.com.au) ([10.97.217.200]) by ipobvi.tcif.telstra.com.au with ESMTP; 13 Apr 2016 15:06:03 +1000 X-IronPort-AV: E=McAfee;i="5700,7163,8133"; a="105403966" Received: from wsmsg3703.srv.dir.telstra.com ([172.49.40.171]) by ipcavi.tcif.telstra.com.au with ESMTP; 13 Apr 2016 15:06:03 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by wsmsg3703.srv.dir.telstra.com ([fe80::9c60:bf5:3f86:2ec%11]) with mapi; Wed, 13 Apr 2016 15:06:03 +1000 From: "Manger, James" To: Paul Hoffman , "cfrg@irtf.org" Date: Wed, 13 Apr 2016 15:06:01 +1000 Thread-Topic: [Cfrg] Exposing the private key by signing "too many times" Thread-Index: AdGVJEj2Pfv6jHYFRcWgKX3Wd0f+SwAHPn0Q Message-ID: <255B9BB34FB7D647A506DC292726F6E13BCF9A46B6@WSMSG3153V.srv.dir.telstra.com> References: In-Reply-To: Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Cfrg] Exposing the private key by signing "too many times" X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2016 05:06:09 -0000 Sign "too many times" and you might be the victim of an adaptive chosen-cip= hertect attack, a la Bleichenbacher's million message attack. That doesn't = expose the private RSA key, but it does expose a symmetric session key encr= ypted for that key. This might contribute to the belief you mention. -- James Manger -----Original Message----- From: Cfrg [mailto:cfrg-bounces@irtf.org] On Behalf Of Paul Hoffman Sent: Wednesday, 13 April 2016 11:32 AM To: cfrg@irtf.org Subject: [Cfrg] Exposing the private key by signing "too many times" Greetings again. I regularly hear from non-cryptographers that they once=20 heard that you have to be careful not to sign "too many times" with the=20 same public/private pair because doing so will expose the private key.=20 I'm interested in the history of this belief. Are there any papers about=20 the history of signature algorithms where this might have been true, or=20 papers on the history of this belief? --Paul Hoffman _______________________________________________ Cfrg mailing list Cfrg@irtf.org https://www.irtf.org/mailman/listinfo/cfrg From nobody Thu Apr 14 03:32:11 2016 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EC6E12DF65 for ; Thu, 14 Apr 2016 03:32:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=securityinnovation.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7zXcaN2NpwuY for ; Thu, 14 Apr 2016 03:32:08 -0700 (PDT) Received: from mail-qk0-x236.google.com (mail-qk0-x236.google.com [IPv6:2607:f8b0:400d:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA7C312DEE3 for ; Thu, 14 Apr 2016 03:32:07 -0700 (PDT) Received: by mail-qk0-x236.google.com with SMTP id n130so27823093qke.3 for ; Thu, 14 Apr 2016 03:32:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=securityinnovation.com; s=google; h=date:from:to:message-id:in-reply-to:references:subject:mime-version; bh=tveBzhP0PdkwuaCx2vVMuUs3ie4zRZs8j1QNQqQPGNY=; b=MyCTGZK2IAYfj2biJFVFnXgTU5L6doKsHG6qsJMQQECS4W5i3sNu+wAzvBV/f5LjRu 9noELUHaQpJ1uM6h2KYEDZovZVnAmtORVoWklvL46nmBaOEK3+quDxXs1/gwVCvLnWod aXnCT6/EVwOrisIXXMvIUviRK5+w28xldCzcA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:message-id:in-reply-to:references :subject:mime-version; bh=tveBzhP0PdkwuaCx2vVMuUs3ie4zRZs8j1QNQqQPGNY=; b=Njwp+kNgSOhV3mRQ0pOFAvf6BgqUj4TJ82x5fAlX/L2I/4dElLm7R91y4+URPvHvbq HNksDx/F/IJmcvDEiNW5Id3I87UnoIx8vUmUC1IRfDNnZiVfYzzgRxJ3PHeikEYkWDS5 ONUrCiFVuwmWqSh7bouvPJqAw8T8leoHot72snjTJ7FwuP7FibphwnitCcQkHM64we8T H602FogxWsfy47LOVfNtOIaA57NlT62qjSyrigoYQ+PljBMR1YqL4djzyN/LTNIPNkvt YMz8SlJpk7BMdcRarZlat2YV/MWs5B757JZi3ATCrkFe7x9Q/ZIvWNIJoRY3AsQOpl+t 5t9A== X-Gm-Message-State: AOPr4FUkfOUEAxsHD38EYFKzPSZ29YDIgqJqy4MQ3nv5sgajotEYM+ErUuU51B5LmoqOj73V X-Received: by 10.55.77.216 with SMTP id a207mr17407257qkb.80.1460629926798; Thu, 14 Apr 2016 03:32:06 -0700 (PDT) Received: from Williams-MBP-2.home (pool-173-48-177-186.bstnma.fios.verizon.net. [173.48.177.186]) by smtp.gmail.com with ESMTPSA id b85sm17693999qhc.23.2016.04.14.03.32.05 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 14 Apr 2016 03:32:05 -0700 (PDT) Date: Thu, 14 Apr 2016 06:32:04 -0400 From: William Whyte To: Paul Hoffman , =?utf-8?Q?Manger=2C_James?= , "=?utf-8?Q?cfrg=40irtf.org?=" Message-ID: In-Reply-To: <255B9BB34FB7D647A506DC292726F6E13BCF9A46B6@WSMSG3153V.srv.dir.telstra.com> References: <255B9BB34FB7D647A506DC292726F6E13BCF9A46B6@WSMSG3153V.srv.dir.telstra.com> X-Mailer: Airmail (351) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="570f71a4_64c12919_70b8" Archived-At: Subject: Re: [Cfrg] Exposing the private key by signing "too many times" X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2016 10:32:09 -0000 --570f71a4_64c12919_70b8 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline I think the concern isn't a crypto concern but an implementation concern. There's folklore knowledge of side-channel attacks, and folklore belief that every time you use the key it's vulnerable to a software attack. Root CA keys are airgapped because every time they're brought online there's a risk they are used to sign something they shouldn't. So this isn't a threat that can be addressed by looking at details of particular algorithms, it's to do with key usage. It does seem like common sense that the longer a key's life, the greater the risk that it gets compromised while active, so having some key rollover policy is probably good practice. Cheers, William On April 13, 2016 at 1:06:15 AM, Manger, James (james.h.manger@team.telstra.com) wrote: Sign "too many times" and you might be the victim of an adaptive chosen-ciphertect attack, a la Bleichenbacher's million message attack. That doesn't expose the private RSA key, but it does expose a symmetric session key encrypted for that key. This might contribute to the belief you mention. -- James Manger -----Original Message----- From: Cfrg [mailto:cfrg-bounces@irtf.org] On Behalf Of Paul Hoffman Sent: Wednesday, 13 April 2016 11:32 AM To: cfrg@irtf.org Subject: [Cfrg] Exposing the private key by signing "too many times" Greetings again. I regularly hear from non-cryptographers that they once heard that you have to be careful not to sign "too many times" with the same public/private pair because doing so will expose the private key. I'm interested in the history of this belief. Are there any papers about the history of signature algorithms where this might have been true, or papers on the history of this belief? --Paul Hoffman _______________________________________________ Cfrg mailing list Cfrg@irtf.org https://www.irtf.org/mailman/listinfo/cfrg _______________________________________________ Cfrg mailing list Cfrg@irtf.org https://www.irtf.org/mailman/listinfo/cfrg --570f71a4_64c12919_70b8 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
Hello everyone -
 
I uploaded an asm code version for MAC OS. It is in the Github reposit= ory (https://github.= com/Shay-Gueron/AES-GCM-SIV).
 
Now it is the code for the 128-bit key variant (the 256-bit key varian= t will be uploaded next week).
 
Regards, Shay
 
------ Original Message ------
From: "Blumenthal, Uri - 0553 - MITLL" <uri@ll.mit.edu>
To: "Gueron, Shay" <shay.g= ueron@gmail.com>
Cc: "cfrg@irtf.org" <cfrg@irtf.org= >
Sent: 4/10/2016 10:55:48 AM
Subject: Re: Re[2]: [Cfrg] Adopting "AES-GCM-SIV: Nonce Misuse-Resista= nt Authenticated Encryption" as a CFRG document ---- Some clarifications
 
If= it was only the native Mac OS X assembler (whose GAS is known to be much= behind the standard) it wouldn't be so bad.
Bu= t as I said - I've tried most every other assembler, including the "all-pow= erful" YASM that usually can process whatever I throw at it. YASM failed= as well.
I'= d appreciate if you could release a "more portable" hand-tuned version that= could compile, e.g., under Yasm-1.3.0 (the current stable version).
C= intrinsics would also be great - but hopefully not at the cost of hand-tun= ed code.
Th= anks!
Sent from&= nbsp;my BlackBerry 10 smartphone on the Veriz= on Wireless 4G LTE network.
From: Gueron, Shay
Sent: Sunday, April 10, 2016 09:39
To: Blumenthal, Uri - 0553 - MITLL; Adam Langley; Andy Lutomirs= ki
Reply To: Gueron, Shay
Cc: Yehuda Lindell; cfrg@irtf.= org; Adam Langley; Shay Gueron
Subject: Re[2]: [Cfrg] Adopting "AES-GCM-SIV: Nonce Misuse-Resi= stant Authenticated Encryption" as a CFRG document ---- Some clarifications=

 
>>> BTW, = what assembler is the optimized code supposed to work with?=20

The code that is currently posted was compiled and tested under= Red Hat Linux, Fedora release 23, using GCC 4.8.2 & GNU assembly versi= on 2.25.
 
MAC OS does not easily chew this assembler syntax, and some work needs= to be done around it. However, I will soon post a C (intrinsics) version= of the code, that should compile on all platforms (of course, at the cost= of giving up some performance that hand tuned assembler achieves).
 
Regards, Shay
 
 
 
 
 
 
 
 
 
 

 

 

 
 
------ Original Message ------
From: "Blumenthal, Uri - 0553 - MITLL" <uri@ll.mit.edu>
To: "Adam Langley" <agl@i= mperialviolet.org>; "Andy Lutomirski" <luto@amacapital.net>
Cc: "Yehuda Lindell" <y= ehuda.lindell@biu.ac.il>; "cfrg@irt= f.org" <cfrg@irtf.org>; "Ada= m Langley" <agl@google.com>
Sent: 4/8/2016 5:40:27 AM
Subject: Re: [Cfrg] Adopting "AES-GCM-SIV: Nonce Misuse-Resistant Auth= enticated Encryption" as a CFRG document ---- Some clarifications
 
BTW, what assembler is the optimized code supposed to work with?
 
I'm on Mac OSX (10.10.5 and 10.11.4) using Xcode 7.2.1 and 7.3 corresp= ondingly. Both systems also have gcc-5.3 and clang-3.7. I also t=E2=80=8E= ried nasm, yasm. Nothing works. Would like some guidance. 
 
Sent from my BlackBerry 10 smartphone on=  the Verizon Wireless 4G LTE network.
  Original Message  
From: Adam Langley
Sent: Thursday, April 7, 2016 19:55
To: Andy Lutomirski
Cc: Yehuda Lindell; cfrg@irtf.org= ; Adam Langley
Subject: Re: [Cfrg] Adopting "AES-GCM-SIV: Nonce Misuse-Resistant Auth= enticated Encryption" as a CFRG document ---- Some clarifications
 
On Fri, Apr 8, 2016 at 8:16 AM, Andy Lutomirski <luto@amacapital.net> wrote:
 Can you clarify the draft?
 
Will do as soon as I'm able (which should be next week).
 
 
Cheers
 
AGL
 
--
 
_______________________________________________
Cfrg mailing list
 

--------=_MB014A11CC-AAF5-450B-8966-179E7BA6E999-- From nobody Thu Apr 14 12:12:16 2016 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 141DE12E0A5 for ; Thu, 14 Apr 2016 12:12:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.998 X-Spam-Level: X-Spam-Status: No, score=-2.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.996, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mrochek.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pMDIJzTpcAiY for ; Thu, 14 Apr 2016 12:12:14 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [68.183.62.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC88312E043 for ; Thu, 14 Apr 2016 12:12:14 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01PZ03T07R6800JZC6@mauve.mrochek.com> for cfrg@irtf.org; Thu, 14 Apr 2016 12:12:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=mrochek.com; s=mauve; t=1460661125; bh=mxXiIEteuOnPKhWXgEN7UMsWVW7Zc9JY5yCmBaRlhlo=; h=From:Cc:Date:Subject:In-reply-to:References:To; b=mvocGcAj44IrWxK2b/952ofYBw+FwaCpoGqCGQTwWId+eqHWAcNFZQ3Bpr2bSaX+b 1vpvlv9JrZ12aVCl+pln9qwBk6uISSY1lBeq/rUR7Y2oxHdMTsprcPaKAysjzEttOJ UH5uAs80Z0KMjiGQw89Ly5OI5XZyO1YH7TKanqFg= MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: TEXT/PLAIN; CHARSET=us-ascii Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01PYL04N2GJK00005M@mauve.mrochek.com> (original mail from NED@mauve.mrochek.com) for cfrg@irtf.org; Thu, 14 Apr 2016 12:12:03 -0700 (PDT) From: ned+cfrg@mrochek.com Message-id: <01PZ03SYW51800005M@mauve.mrochek.com> Date: Thu, 14 Apr 2016 12:03:03 -0700 (PDT) In-reply-to: "Your message dated Thu, 14 Apr 2016 19:05:27 +0200" <20160414170527.GA22878@bolet.org> References: <20160414144442.5709908.79799.15426@certicom.com> <20160414170527.GA22878@bolet.org> To: Thomas Pornin Archived-At: Cc: Dan Brown , "cfrg@irtf.org" Subject: Re: [Cfrg] Exposing the private key by signing "too many times" X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2016 19:12:16 -0000 There are also several so-called "lattice attacks", mostly based on work done on modular polynomial factorization by Dan Coppersmith. AFAIK all of these attacks assume that either some bits of the ephemeral are leaked (e.g., by a timing attack), or that there's some way to control the value of some bits of the ephemeral key (e.g., so-called glitch attacks). In such circumstances the results of some number (sometimes quite small) of signature operations are used to extract the private key. See for example: http://www.hpl.hp.com/techreports/1999/HPL-1999-90.pdf Ned > On Thu, Apr 14, 2016 at 02:44:43PM +0000, Dan Brown wrote: > > Long ago DSA allowed biased ephemeral secrets, which Bleichenbacher > > exploited to extract the private key. > > > > Not aware of history or survey papers on topic, sorry. > The attack is described in this report from Serge Vaudenay (section 5): > http://www.ipa.go.jp/security/enc/CRYPTREC/fy15/doc/1002_reportDSA.pdf > Serge says that the attack was announced in February 2001; apparently, > according to that CHES 2013 article: > http://www.iacr.org/archive/ches2013/80860105/80860105.pdf > the attack was also presented and discussed at an IEEE P1363 WG meeting > on November 15th, 2000. > To my knowledge it was never formally published. > Conceptually, this is a generalization of the dreaded "secret value > reuse". If you reuse the same k value in two distinct signatures (with > the same private key) then the private key is revealed. Bleichenbacher's > attack generalizes that result into leveraging a selection bias; plain > reuse just being an awfully large selection bias. > --Thomas Pornin > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > https://www.irtf.org/mailman/listinfo/cfrg From nobody Thu Apr 14 14:12:40 2016 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E24412D8E4 for ; Thu, 14 Apr 2016 14:12:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.4 X-Spam-Level: X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hxQTj8-N6KUV for ; Thu, 14 Apr 2016 14:12:36 -0700 (PDT) Received: from mail-ig0-x241.google.com (mail-ig0-x241.google.com [IPv6:2607:f8b0:4001:c05::241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C1C6D12D7A9 for ; Thu, 14 Apr 2016 14:12:36 -0700 (PDT) Received: by mail-ig0-x241.google.com with SMTP id kb1so565702igb.3 for ; Thu, 14 Apr 2016 14:12:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc; bh=UhsGPMt8Qe9eMnXnOhiUUj1rveiUnwsWcUm0YDW+1L4=; b=lbjWrwq+mouL7rcU/cmXjGP6opxC4ta/oMA0t7sFZ7cjVRts/MHQT/bSZqcaiG5X2x BHFnsIV889d3zmcMiate+LOZLcICl/uYkOEvCNcGfZL0m3G8/7duFH6/uDS+klebRbgb ibNfP8TIaxVj+7jJk6YCxcGlO0GMTlTOk8oDcBSQy+N22v8XoDW3FUYbo+IJrlRbNZza GWudRKJSOFiext9q6jkIp0HwEj0iUlLZcyXML+QNaXNHeYnQQbit3fC/krIqWtnzqfK7 reStLQRJ3YgN2W0XtqD5SP2bW7wuMuzH7SNIHImaXpnKfki/jr6LkLUhLoEQsgA1Wr6w y9MQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=UhsGPMt8Qe9eMnXnOhiUUj1rveiUnwsWcUm0YDW+1L4=; b=TKtk3eD1c3X3rfaMDqgIyukJ1mfuQlzp9Bio4cYAvnlBOdb7Yfpy7K9garhAc8/puE YnBIYwyLMh6DFVz3VcvKXjKfP/BjylNMJQ4XR0EqWMQM5x2eWNnr+bd+lEy9lcEmDUHh q67o116ZBBewWFkJfOXDZgf8M+hZvlKbmaxWEjV6GL6xQeoHfyiHfNCdoV5q7DbWunBK lOJRJI80dLihQf45mXfd7yQWHBnBXSu7Q/V2PEXSRfAO7eHlpi8MG4+Q38Rcvvg5V6Jc Vha4REB4OvkqnFIMd4Tgpd6Z8OZAyM4wg4O5vaQYjIMUkgH/CxtxHoBdAXjoPWxRjCA3 WhUA== X-Gm-Message-State: AOPr4FUn9XCMm0e2jOO0J+DP2Iakb6oaqodHYAe/Tb6GHKDBW4+eTIjdDhlhb8y8mHNQ7tcrqJ+fZdXZLVSszg== MIME-Version: 1.0 X-Received: by 10.50.93.42 with SMTP id cr10mr884681igb.24.1460668356186; Thu, 14 Apr 2016 14:12:36 -0700 (PDT) Sender: alangley@gmail.com Received: by 10.79.117.133 with HTTP; Thu, 14 Apr 2016 14:12:36 -0700 (PDT) In-Reply-To: References: Date: Thu, 14 Apr 2016 14:12:36 -0700 X-Google-Sender-Auth: s81Ip4CYL1WMviYwQ80oyhYc7Ts Message-ID: From: Adam Langley To: Andy Lutomirski Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Yehuda Lindell , "cfrg@irtf.org" , Adam Langley Subject: Re: [Cfrg] Adopting "AES-GCM-SIV: Nonce Misuse-Resistant Authenticated Encryption" as a CFRG document ---- Some clarifications X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2016 21:12:38 -0000 On Thu, Apr 7, 2016 at 4:55 PM, Adam Langley wrote: > Will do as soon as I'm able (which should be next week). -03 is hopefully clearer on this point: https://tools.ietf.org/html/draft-gueron-gcmsiv-03#section-4 Cheers AGL -- Adam Langley agl@imperialviolet.org https://www.imperialviolet.org From nobody Fri Apr 15 08:47:36 2016 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB7FC12DCD2 for ; Fri, 15 Apr 2016 08:47:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.679 X-Spam-Level: X-Spam-Status: No, score=-1.679 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=azet.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id elcA6x2HqbSN for ; Fri, 15 Apr 2016 08:47:33 -0700 (PDT) Received: from mail-pf0-x22c.google.com (mail-pf0-x22c.google.com [IPv6:2607:f8b0:400e:c00::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD8A012DC6A for ; Fri, 15 Apr 2016 08:47:33 -0700 (PDT) Received: by mail-pf0-x22c.google.com with SMTP id e128so57854696pfe.3 for ; Fri, 15 Apr 2016 08:47:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=azet.org; s=gmail; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references; bh=2SH1rf7j4jpXY8NOwrlv9vhXOSqRWK92vjJgpvRnNWo=; b=iekjQEOL4hJEGb1QwC2bDYYF4szRilNOnwyNqlP3QF0csjNbaxNveZxwiClqPaWFby gU9IfKh5xG/MTXnBhIFyFZB5DWjlgpQ+mUH7D/W+fyk+7oKtUjPY2vE7OFw9RwDNP0+f nvgH0pQxH8ImHrOe3fYfqVb0GYW2CbLLit3gY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references; bh=2SH1rf7j4jpXY8NOwrlv9vhXOSqRWK92vjJgpvRnNWo=; b=enm4HjSBIEF/11DnF0MrQTgkCQ3wHTaziFEt6N1VomMG9rXSyoyLCx08nbp+7nywFw nXdn6Ckd40XW/6ebslpVWv73VQMPBPPRO1eIsp3cVAiNNqt84UlI9LBZGtJOJKw3+VXe Ne9QN2P9WDKzcVwbiC7mZJw0aWpzTksrweDxS+ielH72UTAcpaG3uXXPotfY/8ypXTvM EVNuMPF6/5Gn7HCigvAp66hIiXXti79ibTQ75HD+fyK39liM0OQ3bEtwU7Wpot8P4EOG mpaxGg+jnI+JIvvHdyFYEy6h0z+h6g/ymv2a46Oj43w912wlGOp3Tp/9pinsINXybXVd unnQ== X-Gm-Message-State: AOPr4FUYSKrCG3xMD2qfUkzTq8S2p3np5afHcYkNgrPGQnG3VcNEfbEDtOC4GpDN6rHL5g== X-Received: by 10.98.19.151 with SMTP id 23mr30426427pft.31.1460735253465; Fri, 15 Apr 2016 08:47:33 -0700 (PDT) Received: from [172.20.10.7] (ppp-49-237-179-54.revip6.asianet.co.th. [49.237.179.54]) by smtp.gmail.com with ESMTPSA id r70sm12388907pfb.74.2016.04.15.08.47.29 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 15 Apr 2016 08:47:31 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_C089C029-0D7D-4AAB-A91E-0A2C3F2BA901"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) X-Pgp-Agent: GPGMail 2.6b2 From: Aaron Zauner In-Reply-To: Date: Fri, 15 Apr 2016 22:48:07 +0700 Message-Id: <3654AD02-4508-48BB-A8AE-A125AFA6D1E3@azet.org> References: X-Mailer: Apple Mail (2.3112) Archived-At: Cc: Yehuda Lindell , "cfrg@irtf.org" , Adam Langley Subject: Re: [Cfrg] Adopting "AES-GCM-SIV: Nonce Misuse-Resistant Authenticated Encryption" as a CFRG document ---- Some clarifications X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2016 15:47:34 -0000 --Apple-Mail=_C089C029-0D7D-4AAB-A91E-0A2C3F2BA901 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, Went through past discussion on the proposal, the draft and (also) = noticed the security considerations section and Adam's reply over here: = https://www.ietf.org/mail-archive/web/cfrg/current/msg08030.html So I think it's worth noting in the document that this proposal isn't = "as" nonce misuse resistant to the extent that some people may assume it = is by the title/abstract. i.e. GCM-SIV speaks of "Fully nonce misuse = resistance" while AES-GCM-SIV uses the term "Nonce misuse resistance" - = it may be well worth going into more detail in the draft on the matter = and clarifying. Please correct me if I'm completely off-course here. Aaron --Apple-Mail=_C089C029-0D7D-4AAB-A91E-0A2C3F2BA901 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJXEQ04AAoJEOTbZJL9ubXVUAQP/jgaKgbAKTZY4dnSlJsowga3 w48r7IlJ9pqgAI8XS4FjNUlpVdtXhZt0AR8wBgXFMdzsmOrOZS5sK5RXofLKtRV6 ORgkVBm+T0t3nmEuVt3XQ1KcTGcx2PLMz3LozULLH9+vVIDu4dAICplo1kQAxqQV SrepISy3UNJv4mjQ9L03yhrf8lY6y4GxKdJO9DaJBUcs2HgBO/BIkfQwXLj3iO7i EDAClZ1d7A6SO88TKrc8uUiUU6ygrwEQN6bWLSHdYBxsCMobB7JUbRa1Qd9vg6ZR i/8jVz9tfucmyChzYvg4pTLlL87T8cst3rXNowdJ7htvGbQ0PvOHc98ELIAvkoXj DlVck4kygPKMMiECFujd9BooqpJn0IKjGotpiwbrkQI4NFUr9feQ6PXGqULL98R/ 4fbXSWdklEQgBB4SV9fICyh4pLhuVnQAg1FDVste+NZUXYAG+ECytgsTL2M5Yldy 9lhg+hTQqmRg0B22qSXrPyDIyu76kcqQ8NTf8+UdkzNUzDFdFDPc00KQAsb2jDoS KUbAw0pv9Oldj8lCe042ioV+wmX7JAh8zdwWiG/x3XIQmnHaKjJfA/iBx0IpLZ00 bvzLyslH4bTnCpCdoFEVpK7t73rmL0Y9QcHx28IYuJwAoZDJ9mqNBPBMoQ1B+F9A SPJwMt3DT0WJjwbTOzHm =KZg3 -----END PGP SIGNATURE----- --Apple-Mail=_C089C029-0D7D-4AAB-A91E-0A2C3F2BA901-- From nobody Fri Apr 15 09:07:30 2016 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1850C12DD53 for ; Fri, 15 Apr 2016 09:07:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s7O1PLkGFrxR for ; Fri, 15 Apr 2016 09:07:27 -0700 (PDT) Received: from mail-pa0-x235.google.com (mail-pa0-x235.google.com [IPv6:2607:f8b0:400e:c03::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B4EFB12D9A4 for ; Fri, 15 Apr 2016 09:07:27 -0700 (PDT) Received: by mail-pa0-x235.google.com with SMTP id zm5so56623400pac.0 for ; Fri, 15 Apr 2016 09:07:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:cc:date:message-id:in-reply-to:reply-to:user-agent :mime-version; bh=lbffyT4R6hL36iCm39Froj12xjDdRglzs1pRxPoVciA=; b=xW+fYby0u7nnIIqxDs/tnMUgEQC6kXWUrte3B45Yu1wNa5Gteao0CDF4q8ut1VNkt4 PTpUFmsaWG4GGFZtndcOf5wmh0uMy3j1eDxC+S6EUmUwiTLpHNrEAjVFnx4wd4HkjgF5 1sgravsOvNNBswGAcI9FSG3WkP2XrbZRyso1bdfHWjUibwZEe14kZP4BylsuYowizfTn q6E7Jeqn8Fph8f6Fo0AuI6v92NOq9sbgC8ULjC3v0WUNEDvaU3R4ZCLGjZPvfklo8RN/ txsEO96Pc4XjJtoOiY2Xmo/UNgOJ30KwPDoWnfGgPY5fK5eiuZCoTYQoB000Ry6VZTyo zYNQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:subject:cc:date:message-id:in-reply-to :reply-to:user-agent:mime-version; bh=lbffyT4R6hL36iCm39Froj12xjDdRglzs1pRxPoVciA=; b=BR5WunWXWHZ2RKOJx34bPhQD4coobR3TvfC5bft58leDwR0KgwiDMr6qjvMAG/qEG8 ooJQ9wpz+qkqduN79P02gy5Em9b/W9+TCLj6STrHQdZDSVH2WOHaUnDe8tvuI8I7++Sr DquNHtd7UUhlSItCuf25xiefXN3XDSDSSalpbNjgpOqsqCjNL/5o4w41uI9o+WEqVJYw tZjj7DIPm38pIRe8j3apRmuJ7dCztekuoBsWybN7/WfRizYoWVN0qt0w82wUJY9DSQhq nvEuj3E3HsmFdqjd8mWgCDxzVALqpYXqzmGuGgUXR04n7SAUJ7MWcLH/K83buIcvuDwh 7pSQ== X-Gm-Message-State: AOPr4FUweK89V9IZOsQujlhbZpoh3tUTg923cpbnorvBtozPKf3z/S2keNMbpGVJC8w3fw== X-Received: by 10.66.235.9 with SMTP id ui9mr30563664pac.135.1460736447336; Fri, 15 Apr 2016 09:07:27 -0700 (PDT) Received: from [10.21.154.252] ([68.65.169.12]) by smtp.gmail.com with ESMTPSA id s197sm65702133pfs.62.2016.04.15.09.07.26 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 15 Apr 2016 09:07:26 -0700 (PDT) From: "Gueron, Shay" To: "Aaron Zauner" Date: Fri, 15 Apr 2016 16:06:23 +0000 Message-Id: In-Reply-To: <3654AD02-4508-48BB-A8AE-A125AFA6D1E3@azet.org> User-Agent: eM_Client/6.0.24316.0 Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="------=_MB647053A6-386A-4866-B4D9-87CDA73074CE" Archived-At: Cc: Yehuda Lindell , "cfrg@irtf.org" , Adam Langley Subject: Re: [Cfrg] Adopting "AES-GCM-SIV: Nonce Misuse-Resistant Authenticated Encryption" as a CFRG document ---- Some clarifications X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: "Gueron, Shay" List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2016 16:07:30 -0000 --------=_MB647053A6-386A-4866-B4D9-87CDA73074CE Content-Type: text/plain; format=flowed; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Aaron, Thanks for the comment, but I believe your conclusion is wrong.. AES-GCM-SIV (128/256 bit key) which is proposed for CFRG is a fully=20 nonce misuse resistant authenticated encryption scheme. This means that=20 repeating a nonce will not leak any information except if the same nonce= =20 and the same message is encrypted. In that case, an adversary could only= =20 know that the two identical message were encrypted (this cannot be=20 avoided in any deterministic scheme). The security margins of the CCS2015 paper (original scheme) were proven=20 there. The CFRG submission extends the number of times that a single key=20 (either 128 or 256 bits) can be used - and gets better bounds - at the=20 cost of extra key expansion, as specified (we will publish the improved=20 bounds). However, if a user chooses to send many (e.g., 2^48) messages and always= =20 repeat the same nonce, then AES-GCM-SIV simply reduces to the GCM-SIV of= =20 the CCS2015 paper. Basically, it would behave similarly to AES-GCM with=20 a random 96-bit nonce (this is also inevitable under such a "nonce=20 abuse" scenario in a SIV construction). I hope this clarifies the situation. Thanks, Shay ------ Original Message ------ From: "Aaron Zauner" To: Cc: "Yehuda Lindell" ; "cfrg@irtf.org"=20 ; "Adam Langley" Sent: 4/15/2016 8:48:07 AM Subject: Re: [Cfrg] Adopting "AES-GCM-SIV: Nonce Misuse-Resistant=20 Authenticated Encryption" as a CFRG document ---- Some clarifications >Hi, > >Went through past discussion on the proposal, the draft and (also)=20 >noticed the security considerations section and Adam's reply over here:= =20 >https://www.ietf.org/mail-archive/web/cfrg/current/msg08030.html > >So I think it's worth noting in the document that this proposal isn't=20 >"as" nonce misuse resistant to the extent that some people may assume=20 >it is by the title/abstract. i.e. GCM-SIV speaks of "Fully nonce misuse= =20 >resistance" while AES-GCM-SIV uses the term "Nonce misuse resistance" -= =20 >it may be well worth going into more detail in the draft on the matter=20 >and clarifying. Please correct me if I'm completely off-course here. > >Aaron --------=_MB647053A6-386A-4866-B4D9-87CDA73074CE Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Hi Aaron,
 
Thanks for the comment, but I believe your conclusion is not correct.<= /DIV>
 
AES-GCM-SIV (128/256 bit key) which is proposed for CFRG is a fully= nonce misuse resistant authenticated encryption scheme.
 
This means the following: repeating a nonce will not leak any informat= ion except if the same nonce and the same message is encrypted. In that = case, an adversary could only know that the two identical message were encr= ypted (this cannot be avoided in any deterministic scheme).
 
Of course, there are limits to the number of times messaged can be = encrypted with the same key. The security margins of the CCS2015 paper (ori= ginal scheme) were proven there.
 
The CFRG submission extends the number of times that a single key (eit= her 128 or 256 bits) can be used - and gets better bounds - at the cost = of extra key expansion, as specified (we will publish the improved bounds).=
 
However, if a user chooses to use the scheme to send many (e.g., ~2^48= ) messages while always repeating the same nonce, then AES-GCM-SIV simply= reduces to the GCM-SIV of the CCS2015 paper (and the synthetic IV's will,= at high probability, collide). This is inevitable under such a "nonce abuse" scenario. Basically,= this case would behave similarly to AES-GCM with a random 96-bit nonce,= used ~2^48 with the= same key.
 
What else can be expected?
 
I hope this clarifies the situation.
 
Thanks, Shay
 
------ Original Message ------
From: "Aaron Zauner" <azet@azet.or= g>
To:
Cc: "Yehuda Lindell" <y= ehuda.lindell@biu.ac.il>; "cfrg@irt= f.org" <cfrg@irtf.org>; "Ada= m Langley" <agl@google.com>
Sent: 4/15/2016 8:48:07 AM
Subject: Re: [Cfrg] Adopting "AES-GCM-SIV: Nonce Misuse-Resistant Auth= enticated Encryption" as a CFRG document ---- Some clarifications
 
Hi,
 
Went through past discussion on the proposal, the draft and (also) = noticed the security considerations section and Adam's reply over here: = https://www.ietf.org/mail-archive/web/cfrg/current/msg08030.html
 
So I think it's worth noting in the document that this proposal isn't= "as" nonce misuse resistant to the extent that some people may assume it= is by the title/abstract. i.e. GCM-SIV speaks of "Fully nonce misuse resis= tance" while AES-GCM-SIV uses the term "Nonce misuse resistance" - it may= be well worth going into more detail in the draft on the matter and clarif= ying. Please correct me if I'm completely off-course here.
 
Aaron
--------=_MB1E3448CF-2CBE-4528-A1C9-E70FB36A39B6-- From nobody Fri Apr 15 09:28:45 2016 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E53A412E107 for ; Fri, 15 Apr 2016 09:28:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nthpermutation-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V7aLwdJrQyBy for ; Fri, 15 Apr 2016 09:28:42 -0700 (PDT) Received: from mail-pf0-x22d.google.com (mail-pf0-x22d.google.com [IPv6:2607:f8b0:400e:c00::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD59312DF30 for ; Fri, 15 Apr 2016 09:28:42 -0700 (PDT) Received: by mail-pf0-x22d.google.com with SMTP id e128so58164207pfe.3 for ; Fri, 15 Apr 2016 09:28:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nthpermutation-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=pfr00x/wrX+Ti2zafs4snS542u/pvbM5QOuyH++oZPQ=; b=fFYNBtiW9lnpUiLltfMyK3653NgzoIWJU0YXA6m8EK0dadnw4cVYtoS0C6g/5TcRUx OiVI4gCg0fSKNnkX3no4x1Np88aYWK0Jgdu/Vv4bB1etoo3yiTcUEXZ/LKf1hxLBnmDx OEvGVculpQRe/dGkakZ4+iA/58FOlkcezyJ6vggM6/op8Fe+5SIyiL/JNp0SYWzogDO+ A+P3N06REIGbLIqgxzQMLG5FSq2OxiV8AIkwKI5McEAYmeWRrDnvm1BJDIaAUZ5eciEW FmC8HvUJKaYRgg4oyfz4CNSNArjutsEiGISgfrQ3G3VDHaoOHG7nBVAnEOmb+lu8O07Z nbUg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=pfr00x/wrX+Ti2zafs4snS542u/pvbM5QOuyH++oZPQ=; b=KSQwEKlDf1UwCxf4YMHywHJxpQSzEFiX7EitH2uwhGwC6uDoMhkaydf7PRIYhX9gUt zzicBIG+bxmKC7PaTG7irrNJRppwUVYj7MeAIi6zHJDF24cticTUdiys0ZbPLr2kvn2f 2CqMcO6YSZ3HY6sBzivCW2RlOhwdJKii2P1777G3IYtBfhY4hszEnfm6ySBgylfIByqu 3P0PEpNIo8IZa/1kUC8CEBlT7f3QsNYI5qEuI+D0b8YXUaFonLeVLOemcjJjikbEuG+C Ot44yvt4PZtWScXPY73eC0Cpu9FgHZC2d/0UfLZltQS2SkvUK00ldIpizpLlvrZtM0PR 6jEA== X-Gm-Message-State: AOPr4FXapMA8r1zf3I6Wm2h2Z7x2L6TZZsN20r9keB8oB0M9A4PzqXiuVYdsimkn1gELJw== X-Received: by 10.98.65.215 with SMTP id g84mr30344985pfd.94.1460737722210; Fri, 15 Apr 2016 09:28:42 -0700 (PDT) Received: from [10.90.130.63] (soi.silverspringnet.com. [74.121.22.10]) by smtp.gmail.com with ESMTPSA id d19sm65744680pfj.92.2016.04.15.09.28.41 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 15 Apr 2016 09:28:41 -0700 (PDT) To: cfrg@irtf.org References: From: Michael StJohns Message-ID: <571116B0.4050204@nthpermutation.com> Date: Fri, 15 Apr 2016 12:28:32 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Cfrg] Adopting "AES-GCM-SIV: Nonce Misuse-Resistant Authenticated Encryption" as a CFRG document ---- Some clarifications X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2016 16:28:44 -0000 On 4/15/2016 12:06 PM, Gueron, Shay wrote: > This means that repeating a nonce will not leak any information except > if the same nonce and the same message is encrypted. In that case, an > adversary could only know that the two identical message were > encrypted (this cannot be avoided in any deterministic scheme). Is there any other scheme currently in use in our protocols (TLS, IPSEC, etc) that has the property that identical messages under the same key/nonce (or key IV) are encrypted identically? I've been reading this thread only intermittently and perhaps I missed the discussion, but the above property seems to be a "bad thing"(tm) in the general scheme of things. Perhaps it can be mitigated by specific protocols with specific techniques but that seems to be contrary to the idea that this is an idiot-proof (in terms of implementation) improvement over AES-GCM itself. Mike From nobody Fri Apr 15 09:53:36 2016 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7EA812D138 for ; Fri, 15 Apr 2016 09:53:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=azet.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1SBxKIMg7sOR for ; Fri, 15 Apr 2016 09:53:31 -0700 (PDT) Received: from mail-pa0-x232.google.com (mail-pa0-x232.google.com [IPv6:2607:f8b0:400e:c03::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C824112DEE8 for ; Fri, 15 Apr 2016 09:45:48 -0700 (PDT) Received: by mail-pa0-x232.google.com with SMTP id zm5so56907730pac.0 for ; Fri, 15 Apr 2016 09:45:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=azet.org; s=gmail; h=subject:mime-version:from:in-reply-to:date:cc:message-id:references :to; bh=YJTim+q6c7mzB03Mkv1n93W7icFGADxEH0/3v2yVmr0=; b=ReBp0d6HxYZbhwkNf/bwhIF1TQ0BgjSA+avtygQMJfRv2tSSvNg1YFMFnGmMAtNhEi LDNs61LwXWtsEKAUNyto1kbg1juk1YsLVA2LakPOTXvjCQ+FN3b39QZik+EcqmWXXlL+ vlFczpeGtano+qdJHNaCwfdj0vn0y396Pukc4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:mime-version:from:in-reply-to:date:cc :message-id:references:to; bh=YJTim+q6c7mzB03Mkv1n93W7icFGADxEH0/3v2yVmr0=; b=eTaWUth0pXwdCpaJW0tpA7PhdBdi4L5mUg9n2SqLTaDfdbr2S6JD6mDJ+1AgZmFy6j mAK/8C+Nzn//ZE9I1LfVDl09aczUhwhKgo2BEE//z5jGQchnU1FyOBUIBbJUfEdx2aK5 yaiyo1Zy1TwWRgpxvlbULOEpm4PRn40K9knFKoP9O2BFi9hf8LuUQqBfUYYYY8zkpfAF JE1S4TSE5DpiiYaraWgclP+23YSWHLDpNx/jvJ0vQRka2SaPeOyNeVCfgR62QcOX+Tgp 37nEVccLVnsyKRNdcgWZSu7GBBdoGrKPulkcyJpgb3/E8gmZIfHDExDTy8bw2MyQaYDr wiyw== X-Gm-Message-State: AOPr4FVSXPUytLXGu2Wn/bHHvmscIopPHSMlgStKYAioezIY4k4y2qcR80U58gSBGy/QDQ== X-Received: by 10.66.251.132 with SMTP id zk4mr30898447pac.50.1460738748364; Fri, 15 Apr 2016 09:45:48 -0700 (PDT) Received: from [172.20.10.7] (ppp-49-237-179-54.revip6.asianet.co.th. [49.237.179.54]) by smtp.gmail.com with ESMTPSA id f12sm65847244pfd.87.2016.04.15.09.45.44 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 15 Apr 2016 09:45:46 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) Content-Type: multipart/signed; boundary="Apple-Mail=_6CB16246-ACAB-4EB2-B806-710981EBCC83"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.6b2 From: Aaron Zauner In-Reply-To: Date: Fri, 15 Apr 2016 23:46:21 +0700 Message-Id: References: To: "Gueron, Shay" X-Mailer: Apple Mail (2.3112) Archived-At: Cc: Yehuda Lindell , "cfrg@irtf.org" , Adam Langley Subject: Re: [Cfrg] Adopting "AES-GCM-SIV: Nonce Misuse-Resistant Authenticated Encryption" as a CFRG document ---- Some clarifications X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2016 16:53:33 -0000 --Apple-Mail=_6CB16246-ACAB-4EB2-B806-710981EBCC83 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, > On 15 Apr 2016, at 23:13, Gueron, Shay wrote: > This means the following: repeating a nonce will not leak any = information except if the same nonce and the same message is encrypted. = In that case, an adversary could only know that the two identical = message were encrypted (this cannot be avoided in any deterministic = scheme). >=20 > Of course, there are limits to the number of times messaged can be = encrypted with the same key. The security margins of the CCS2015 paper = (original scheme) were proven there. >=20 > The CFRG submission extends the number of times that a single key = (either 128 or 256 bits) can be used - and gets better bounds - at the = cost of extra key expansion, as specified (we will publish the improved = bounds). Thanks for the clarification on that part. > However, if a user chooses to use the scheme to send many (e.g., = ~2^48) messages while always repeating the same nonce, then AES-GCM-SIV = simply reduces to the GCM-SIV of the CCS2015 paper (and the synthetic = IV's will, at high probability, collide). This is inevitable under such = a "nonce abuse" scenario. Basically, this case would behave similarly to = AES-GCM with a random 96-bit nonce, used ~2^48 with the same key. Ok, so I did understand this correctly in the first place. That's = actually of some concern to me, we've seen some implementations (most = Cavium based, AFAICT) in the wild that use random 96-bit nonces with = AES-GCM [0], some actually repeat them [1]. Likewise it's probable that = implementers may err with AES-GCM-SIV and repeat messages under the same = nonce ~2^48 times in some scenarios. > What else can be expected? The explanation you provided above (w.r.t. repeating messages under a = single nonce ~2^48 times) is quite sufficient, may I suggest it gets = added to the security consideration section so implementers might not = repeat the same mistake with this particular design? Thanks for your time & feedback, Aaron [0] https://www-01.ibm.com/support/docview.wss?uid=3Dswg21979604 [1] = https://kb.radware.com/Questions/SecurityAdvisory/Public/Security-Advisory= -Explicit-Initialization-Vector-f --Apple-Mail=_6CB16246-ACAB-4EB2-B806-710981EBCC83 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJXERreAAoJEOTbZJL9ubXVq1YP/j5AlJaWmk8y+jog6LiAuPTs uxVa9OJGiUZC1+SPGFcv8jNaQobymen4/n00Jg6xaWK0YxqzcmbdllSLrf1BO2CG 0by+LSwxaihu+DHha7/Q6ul19Ro03ENjPuSWnXwV1oNErR9y9ZIUb8D+xmDEeHem Xq/1hJ4P2AbVEaCZcECqb7u1R1YZ0PEBFrRrrd+v0poNNDgPkI3VUrkL7KPwAVvx 1n8Q8a8mBHvkJAAClnZKoPIS/JTQOjv4vIf6DsSAF4RlEP11ki6RO75TW9TQJnZ4 v7mh+9PCA5z2PbWl+if4bjUEQn65gvIgCodHp1k7R7yH3vZqhYfU56t939n0u1vU kga+f0cL1Yk7FcDGUeczBWhVXEzvhEtj7pCHaEJcqRqvbyheKqeHUo9NaEXI3Ib/ Aki3N2VXiBgoFCBVN/g6PWLyQmJCW01FKR2sQtvUWLBTEnnHTFmy43n4Vo38yjXh 048BUilsI/B+sw0GDvT9O2yi5iIa3DNIJuyG//Uk55GVD7/LsEK4AfmglJWStTHB 3lbfL/b5udYersEou0FLhirrucj/TaULUzt7FvpLEIxbj+TLoKLAmW5CakrEy7mj y8/2RpFIg+E/S5tdsi4Okyy+bA0O9RKU0FiaKq35hxqMX07vlVLbm1CADnQ/oPV3 GswQMZ3UYmQKE1rF9w+Z =FioG -----END PGP SIGNATURE----- --Apple-Mail=_6CB16246-ACAB-4EB2-B806-710981EBCC83-- From nobody Fri Apr 15 10:05:08 2016 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2C1812E2FE for ; Fri, 15 Apr 2016 10:05:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AUzgmDArWE2E for ; Fri, 15 Apr 2016 10:05:05 -0700 (PDT) Received: from mail-pf0-x236.google.com (mail-pf0-x236.google.com [IPv6:2607:f8b0:400e:c00::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E5AF312D161 for ; Fri, 15 Apr 2016 10:05:04 -0700 (PDT) Received: by mail-pf0-x236.google.com with SMTP id 184so58815441pff.0 for ; Fri, 15 Apr 2016 10:05:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:cc:date:message-id:in-reply-to:reply-to:user-agent :mime-version:content-transfer-encoding; bh=G0LWHYQ4sxE17DPEK4+5DKng/ea5tJ6XMVH5Gr04nOQ=; b=gnENxLCeg7ciPRO9El4jYAaho8c5tRo8Z3Ep5jDYAIoXyCq3rJHuolaGqhlNDnR4/G neIcgBGRmQ0Gv5qbZAwBKqmcWUOLuD9LBRzpL0VkjVHl4rF00zbebTGmtQBkiYSwOQZg dBLwvbBHmgWWJMr3YmfDKPqRzwd7Z+2TPZc8OCLHi3e15/9APS3KXn2j7BBrfrTEJuwd 7Koo8QMbfzYE78kgLN3LrgVou3l1tWixW16xCifN0iPGGUFTG/AWpHWi1GYmObEl3I/U v7mFvpL5s/vY1TViaj+gdSEZPNeK8hh+djNBH5F3+TyttbKrvewJLHJOacxBEeZzPtOv yLnw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:subject:cc:date:message-id:in-reply-to :reply-to:user-agent:mime-version:content-transfer-encoding; bh=G0LWHYQ4sxE17DPEK4+5DKng/ea5tJ6XMVH5Gr04nOQ=; b=mHg82LtcWeqVB9yKvV4JIPObzaoMzoGJDeNrNlesUK/Q2MfFZWuaol9qGeHxivltUX vNU/pXw8SQ3EleQiGS77Qpda8TXlLYPhvm9Q7VO1sgWj+d1q2c1pisng1XA9hhe1P/+i NdnHNRZWTvXlHfOBW8JGGO000AlZ6XVrHL8Gu4VrddirQEHGfy2ECa6l6YvefHDGICFT OobdtjlmX3wvAQW63osqOkx5u+EnY3LFybQRT36QbpNDBefolxBeeAN2x8Puws9kceZm fEDfpFQu2cd1h50c/bYbBAABZfbtOLoVBU4Vkp4uttnGuAx83QSUGrSQ14NpKjXCJ+DA MFPg== X-Gm-Message-State: AOPr4FX//vU5kxX3KO8lO8fKPKIOHEoVxsriTQseMB37nS6KfhbL0WGZ7h/C0JI0jMqc3w== X-Received: by 10.98.64.144 with SMTP id f16mr30663081pfd.159.1460739904330; Fri, 15 Apr 2016 10:05:04 -0700 (PDT) Received: from [10.72.121.23] (gapX2.stanford.edu. [171.64.70.51]) by smtp.gmail.com with ESMTPSA id vv8sm66127648pab.22.2016.04.15.10.05.03 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 15 Apr 2016 10:05:03 -0700 (PDT) From: "Gueron, Shay" To: "Aaron Zauner" Date: Fri, 15 Apr 2016 17:04:53 +0000 Message-Id: In-Reply-To: User-Agent: eM_Client/6.0.24316.0 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Yehuda Lindell , "cfrg@irtf.org" , Adam Langley Subject: Re: [Cfrg] Adopting "AES-GCM-SIV: Nonce Misuse-Resistant Authenticated Encryption" as a CFRG document ---- Some clarifications X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: "Gueron, Shay" List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2016 17:05:07 -0000 Hi - Sure, we can add the comment to the next revision. (In any case, this follows from the security bounds, but spelling this=20 out in the CFRG document would not hurt) [ About using AES-GCM with a random IV 2^48 times: this violates the=20 guidelines of AES-GCM spec (=20 http://csrc.nist.gov/publications/nistpubs/800-38D/SP-800-38D.pdf,=20 section 8.3). ] Regards, Shay ------ Original Message ------ From: "Aaron Zauner" To: "Gueron, Shay" Cc: "Yehuda Lindell" ; "cfrg@irtf.org"=20 ; "Adam Langley" Sent: 4/15/2016 9:46:21 AM Subject: Re: [Cfrg] Adopting "AES-GCM-SIV: Nonce Misuse-Resistant=20 Authenticated Encryption" as a CFRG document ---- Some clarifications >Hi, > >> On 15 Apr 2016, at 23:13, Gueron, Shay wrote: >> This means the following: repeating a nonce will not leak any=20 >>information except if the same nonce and the same message is=20 >>encrypted. In that case, an adversary could only know that the two=20 >>identical message were encrypted (this cannot be avoided in any=20 >>deterministic scheme). >> >> Of course, there are limits to the number of times messaged can be=20 >>encrypted with the same key. The security margins of the CCS2015 paper= =20 >>(original scheme) were proven there. >> >> The CFRG submission extends the number of times that a single key=20 >>(either 128 or 256 bits) can be used - and gets better bounds - at the= =20 >>cost of extra key expansion, as specified (we will publish the=20 >>improved bounds). > >Thanks for the clarification on that part. > >> However, if a user chooses to use the scheme to send many (e.g.,=20 >>~2^48) messages while always repeating the same nonce, then=20 >>AES-GCM-SIV simply reduces to the GCM-SIV of the CCS2015 paper (and=20 >>the synthetic IV's will, at high probability, collide). This is=20 >>inevitable under such a "nonce abuse" scenario. Basically, this case=20 >>would behave similarly to AES-GCM with a random 96-bit nonce, used=20 >>~2^48 with the same key. > >Ok, so I did understand this correctly in the first place. That's=20 >actually of some concern to me, we've seen some implementations (most=20 >Cavium based, AFAICT) in the wild that use random 96-bit nonces with=20 >AES-GCM [0], some actually repeat them [1]. Likewise it's probable that= =20 >implementers may err with AES-GCM-SIV and repeat messages under the=20 >same nonce ~2^48 times in some scenarios. > >> What else can be expected? > >The explanation you provided above (w.r.t. repeating messages under a=20 >single nonce ~2^48 times) is quite sufficient, may I suggest it gets=20 >added to the security consideration section so implementers might not=20 >repeat the same mistake with this particular design? > >Thanks for your time & feedback, >Aaron > >[0] https://www-01.ibm.com/support/docview.wss?uid=3Dswg21979604 >[1]=20 >https://kb.radware.com/Questions/SecurityAdvisory/Public/Security-Advisory= -Explicit-Initialization-Vector-f From nobody Fri Apr 15 10:13:46 2016 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2575D12DA81 for ; Fri, 15 Apr 2016 10:13:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.4 X-Spam-Level: X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DWOgaAGoqTUe for ; Fri, 15 Apr 2016 10:13:43 -0700 (PDT) Received: from mail-io0-x236.google.com (mail-io0-x236.google.com [IPv6:2607:f8b0:4001:c06::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 68BE512D9D7 for ; Fri, 15 Apr 2016 10:13:43 -0700 (PDT) Received: by mail-io0-x236.google.com with SMTP id 2so141087062ioy.1 for ; Fri, 15 Apr 2016 10:13:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-transfer-encoding; bh=MxORDeVztTu8/L3k5JfJgzO1zrpoe/mInSDIubKlX8U=; b=hXOTWg7Le5JhF0JRP9RObJI1rJtcsHWw4EdTbVp8uY74DezsbF3L7Ag76AVLFHiGHz rjha3tAj7kiJOpwM3EW4p4GJbBZIS2NJx+7jdI/rS33cgCdQpmwYO+rF6mc9fTWjjo9D jvioB7VOSrf7/jVI/4ZZE3j7REsXSg9U6tzzPnNZ+a+v+P0pYEwtRUcqeYAPjyHoHoLP iT8xn/Iaf8FrU+jGs6qjYsMvfQk1Yb8BoUMUbsl6pGs+UbE2BGgb7a8UHrpC9VWRar4h tDs7pkfQq7zAcuWcrJLEU4KjAymGpCepaTVCgO0KSPKk2h/19n97jnta4e3bK6su34xM JVJw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc:content-transfer-encoding; bh=MxORDeVztTu8/L3k5JfJgzO1zrpoe/mInSDIubKlX8U=; b=fsGth7K517OrEg3CxqMn9hmHDgy4f8WugegTOvCe5OUXyXYrUwIJJ5MLuBkhFCrFxD c47CWQdpk+aiNI8IifdpByQwVZRQWwHJjHI8YzT9u5YIdrfzdqcoTMdn9fuhK+i4/Dxq 83PB7dtYiPoRSbhXz1ol4nLD7B1aZxDTTICz2IpHbLzDJQSTxSnKMey3zplQT4BIGpoH lyJWzTS/G9EDSYnpSKPuGpgkPbBRfF+q8iwXGHLlM9ewSnNhUka9vFWk7nSlLmLCjLkl U8riYsMneul2g92n3X522syucd0wyLEW/2e/UkENPzJXOaD+dkNMmrHtFqOoGCPiLvPH Hn0Q== X-Gm-Message-State: AOPr4FWg5APdgV83WKGOlM9kiuKx6siaBjXQiBhbEVLNwTSrw5RZoFZuYhTo8xZtuDXEh2SuklMKcLQoaWKi2g== MIME-Version: 1.0 X-Received: by 10.107.151.8 with SMTP id z8mr23026064iod.191.1460740422738; Fri, 15 Apr 2016 10:13:42 -0700 (PDT) Sender: alangley@gmail.com Received: by 10.79.117.133 with HTTP; Fri, 15 Apr 2016 10:13:42 -0700 (PDT) In-Reply-To: <571116B0.4050204@nthpermutation.com> References: <571116B0.4050204@nthpermutation.com> Date: Fri, 15 Apr 2016 10:13:42 -0700 X-Google-Sender-Auth: MmcawHykaVZfZ8SvUXTkMooZJhQ Message-ID: From: Adam Langley To: Michael StJohns Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "cfrg@irtf.org" Subject: Re: [Cfrg] Adopting "AES-GCM-SIV: Nonce Misuse-Resistant Authenticated Encryption" as a CFRG document ---- Some clarifications X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2016 17:13:45 -0000 On Fri, Apr 15, 2016 at 9:28 AM, Michael StJohns w= rote: > Is there any other scheme currently in use in our protocols (TLS, IPSEC, > etc) that has the property that identical messages under the same key/non= ce > (or key IV) are encrypted identically? I think all encryption schemes have this property if I understand you. Given a fixed (key, nonce, message), all AEADs should be deterministic, i.e. will produce a fixed ciphertext. That includes AES-GCM, ChaCha20-Poly1305, AES-CCM etc For CBC modes, some people consider them to be functions of (key, message)=E2=86=92ciphertext, in which case the random IV makes them non-deterministic in that model. But if considered to be a function of (key, message, IV)=E2=86=92ciphertext then they, too, are deterministic too= . Cheers AGL --=20 Adam Langley agl@imperialviolet.org https://www.imperialviolet.org From nobody Fri Apr 15 10:21:57 2016 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9729312E70B for ; Fri, 15 Apr 2016 10:21:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=azet.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cI-PiW41dO0y for ; Fri, 15 Apr 2016 10:21:42 -0700 (PDT) Received: from mail-pa0-x236.google.com (mail-pa0-x236.google.com [IPv6:2607:f8b0:400e:c03::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C7DF312E731 for ; Fri, 15 Apr 2016 10:21:42 -0700 (PDT) Received: by mail-pa0-x236.google.com with SMTP id fs9so38333690pac.2 for ; Fri, 15 Apr 2016 10:21:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=azet.org; s=gmail; h=subject:mime-version:from:in-reply-to:date:cc:message-id:references :to; bh=UGFIeixecYeuuCvxSiN5bPGAkyj/VAHjIhWEFHPAX/g=; b=P+pl4daSWsMeeoWPbdnk7LSIMDmQKvu6Sp2vxQE8s6QcN4tLaYShKKDcBkGrPpm/mW uOUeo9lkgqZB7vG6iJxS/Ul07rDbiMbPikZT6+SzSeX7X5PYCofkDymRMBpQDebkqhBy xEHoqu8pTuqRRPaCxBfcRNT7qv/W9YSJpvqDg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:mime-version:from:in-reply-to:date:cc :message-id:references:to; bh=UGFIeixecYeuuCvxSiN5bPGAkyj/VAHjIhWEFHPAX/g=; b=dU+Yq4z6aWIrTq1gxdJuFMVjmxqmztFaJdXFtqu+I1XXBGlrjzbWaRekn3gHHLgles 5OIFn4S8aDYZdAlhG++H3qhizsxNulGBOgs/SexV/aCyOt4CLVeu45iJTFTlYCedO8f4 OMzqedIMLOoXjvG8sX3XfkCStS2eDCsYzEsWduguI9KTDzN2E3oCFOaSxikihYQJf4y7 rh2JzZlTJDeF0l9iBglPvDLUcivkrebNHLvYk90QXZIsWoRZO7h7ItqEEoqpMafJmWko QPxhDVm8A04QY1cVFuP3KpXnMS05tH+HoVWpR1nbXNUsGuH36vA+/8hC4ZpBP8vb3cG0 +Byg== X-Gm-Message-State: AOPr4FV6ZWdB4PeoSQo20auT5li+VznK6qYUNpsm+DdyFdvVaV8+6+PYATmcPZ/Hi3qM/g== X-Received: by 10.66.48.164 with SMTP id m4mr31044182pan.57.1460740902331; Fri, 15 Apr 2016 10:21:42 -0700 (PDT) Received: from [192.168.0.137] (ppp-119-76-65-60.revip17.asianet.co.th. [119.76.65.60]) by smtp.gmail.com with ESMTPSA id r65sm66010730pfa.27.2016.04.15.10.21.31 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 15 Apr 2016 10:21:39 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) Content-Type: multipart/signed; boundary="Apple-Mail=_D97255E9-8DA8-4D6F-ACA3-D5D9D6BF6CAA"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.6b2 From: Aaron Zauner In-Reply-To: Date: Sat, 16 Apr 2016 00:22:05 +0700 Message-Id: <06550747-D138-45A2-B0CB-B3680460C853@azet.org> References: To: "Gueron, Shay" X-Mailer: Apple Mail (2.3112) Archived-At: Cc: Yehuda Lindell , "cfrg@irtf.org" , Adam Langley Subject: Re: [Cfrg] Adopting "AES-GCM-SIV: Nonce Misuse-Resistant Authenticated Encryption" as a CFRG document ---- Some clarifications X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2016 17:21:50 -0000 --Apple-Mail=_D97255E9-8DA8-4D6F-ACA3-D5D9D6BF6CAA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, > On 16 Apr 2016, at 00:04, Gueron, Shay wrote: >=20 > Hi - >=20 > Sure, we can add the comment to the next revision. >=20 > (In any case, this follows from the security bounds, but spelling this = out in the CFRG document would not hurt) I think the clearer the wording here, the better the outcome in the = understanding of implementers, not all are mathematicians or = cryptographers themselves. > [ About using AES-GCM with a random IV 2^48 times: this violates the = guidelines of AES-GCM spec ( = http://csrc.nist.gov/publications/nistpubs/800-38D/SP-800-38D.pdf, = section 8.3). ] I am aware of that. Joux provided a comment on the matter during the = NIST specification phase: = http://csrc.nist.gov/groups/ST/toolkit/BCM/documents/comments/800-38_Serie= s-Drafts/GCM/Joux_comments.pdf (section 3) The problem here is not the spec itself - it's human error and = misunderstanding during implementation phase. I feel nonce-misuse = resistant modes should effectively prevent such scenarios in the first = place. At least that was my understanding until today. Aaron --Apple-Mail=_D97255E9-8DA8-4D6F-ACA3-D5D9D6BF6CAA Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJXESM+AAoJEOTbZJL9ubXVlnEP/3tFyj56Eh3HsS4+qR6LFpMU U4SqBM2stuvkaIKxbVN24yM6QNy5hP18HUk6dBSCxNy8S2VDqJfG+VFwjzPzF8Xh lxaOOCnYL/sMWhjzfTZycf3Mf7o5fBf2o126wNb0q+HUs/hyfSp2S6Ia1L1Fqb+2 UD8hxypAXBPiQFca9yBjM0nfyErnUpq6zJrZ5Jmcg+gsEsA9piNvJJTd2Q0nZZIn jhgeSMy+kJjB0wwzK6O/kpOg+MGHXqUVt9LsUvhAHRdXtNjKr4ajFpZJblbnSPeQ WjQmkhdmcW7dE0Aqi4E5epejsMUGqW6urY5l+HGUA+0LXABFSqKPR2OXAPuYfFAx YGWsE2Y+toAD3Q6mOiwWYq3ttnE0ZV9w61c400H/Y19vbs4spWtmo4w1CgaN381B hcTaXaghjQ4+vfi29v//5EJOiCt7GixBGqNaoRqGnwBDWPGyR37TzsrAWaM4bdqD 0fGX0nowhr4rizgS3HzR92b+YvUzI744EWnF3cF/KmLKa2P3MFyFPReL/goqSk+/ uSaf39fQ/g2KZr8u08TVmqJHeBE6eXVMIkgKNtHxldFlyONH1/tQUA3AJD4MnM6h s9FluhksyjnTZPYb7QhSSbyYs4PPjHY76/xgF841ohXQWtbOL1QK08I+zARTyYmh NncNn8lY1d1jbAh4PMe6 =LfUA -----END PGP SIGNATURE----- --Apple-Mail=_D97255E9-8DA8-4D6F-ACA3-D5D9D6BF6CAA-- From nobody Fri Apr 15 13:46:22 2016 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50FF312D7BF for ; Fri, 15 Apr 2016 13:46:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YmKTxAEgRYQY for ; Fri, 15 Apr 2016 13:46:20 -0700 (PDT) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id 2817912D63C for ; Fri, 15 Apr 2016 13:46:20 -0700 (PDT) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 1580E1022400A; Fri, 15 Apr 2016 13:46:19 -0700 (PDT) Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Fri, 15 Apr 2016 13:46:19 -0700 (PDT) Message-ID: <7a32ee823d39c1d80de6c179837451ab.squirrel@www.trepanning.net> In-Reply-To: <571116B0.4050204@nthpermutation.com> References: <571116B0.4050204@nthpermutation.com> Date: Fri, 15 Apr 2016 13:46:19 -0700 (PDT) From: "Dan Harkins" To: "Michael StJohns" User-Agent: SquirrelMail/1.4.14 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Archived-At: Cc: cfrg@irtf.org Subject: Re: [Cfrg] Adopting "AES-GCM-SIV: Nonce Misuse-Resistant Authenticated Encryption" as a CFRG document ---- Some clarifications X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2016 20:46:21 -0000 On Fri, April 15, 2016 9:28 am, Michael StJohns wrote: > On 4/15/2016 12:06 PM, Gueron, Shay wrote: >> This means that repeating a nonce will not leak any information except >> if the same nonce and the same message is encrypted. In that case, an >> adversary could only know that the two identical message were >> encrypted (this cannot be avoided in any deterministic scheme). > > Is there any other scheme currently in use in our protocols (TLS, IPSEC, > etc) that has the property that identical messages under the same > key/nonce (or key IV) are encrypted identically? Way back at IETF70 I proposed some ciphersuites for TLS using AES-SIV (RFC 5297). AES-SIV has the same nonce-misuse properties as AES-GCM-SIV but it's a 2-pass cipher mode. The general response I received can be summarized as "we don't need nonce misuse because the nonce is not part of the API that Joe User, who may be ignorant of nonce usage issues, calls and everyone writing a TLS implementation knows what he or she is doing so it's not a problem." Of course, times change and so do opinions. regards, Dan. From nobody Fri Apr 15 18:00:31 2016 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49A2912D70B for ; Fri, 15 Apr 2016 18:00:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nthpermutation-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B8JFJgEn9FlQ for ; Fri, 15 Apr 2016 18:00:29 -0700 (PDT) Received: from mail-pf0-x230.google.com (mail-pf0-x230.google.com [IPv6:2607:f8b0:400e:c00::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E6B1012D0F1 for ; Fri, 15 Apr 2016 18:00:28 -0700 (PDT) Received: by mail-pf0-x230.google.com with SMTP id n1so61757293pfn.2 for ; Fri, 15 Apr 2016 18:00:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nthpermutation-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=XaMmTFBlV/2JI8O/EmWvkAlVWPksTZuIaWBC/9hif2E=; b=L+HZwjgdOrsaEACghIgHvGfVIJpckchz4F5rPkMYs/3XoSMsLsH6klTWFHBmc2NbdF +QRb39EvEjjlPziwUWEClEpT99BUNzXyVWODL55SHDifoCmpZUekdWx9raLSP6xQxifF hPA7/rrxDZZHd/7MqXbhdpfzf1xD2nmSWG+Y5Xo8/o92/+kiNSaS7oryhCsw/sCWYNbL C+xLcAyvl+RNx8K+sSezT3exRR32EeI86V4WRfrjQ1CKLs+TSuQduJv0bXKAriLpK8h0 VXABQAv7B8yI1Gif/MbCPIHPRAx6Y8yz/JQHlaRV0cKsemPJYIofWMpssf6aTe9EN4DF BUaw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=XaMmTFBlV/2JI8O/EmWvkAlVWPksTZuIaWBC/9hif2E=; b=VpoLL7Ef7PCDYIi4X+2dfBHKOiwJyHuKp5t+F9WvS2u1f9NIiwrEFstn57oTw+pK62 u5mo7G7ms9sKlI+3ROLoLbX0mvM2ORIXx1GO7sHZrQe8ppSjdBOG5H7m86YPvVAP708e lcF6JFik9qKRM54CKQo5qkI26iJwyNC53qb8DD2cZ2MbmlSYa+H9ns9aER58+womobR4 FJPNBvv1SCZU0CDj2YBsqcbyiQqSrjkNrIVMZOH5svfQkkW4ZlMY3uHzy2Q0CV7yXfHo 4nLTFVwmBeuAvJ5ZrXaA6YAgd139G6G5TRLjQxaHDtAlbJ7HabUKw0HLFO8rNGZx1Q6m YTpw== X-Gm-Message-State: AOPr4FV/JVyEjwOC3uiSAZENa2F8p+pmMoNEACKeXhsZBuxe1tR82Qu87+oryWWLYUxIAA== X-Received: by 10.98.11.205 with SMTP id 74mr33272517pfl.98.1460768428360; Fri, 15 Apr 2016 18:00:28 -0700 (PDT) Received: from [100.44.155.40] ([100.44.155.40]) by smtp.gmail.com with ESMTPSA id m87sm67277044pfj.38.2016.04.15.18.00.27 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 15 Apr 2016 18:00:27 -0700 (PDT) To: Adam Langley References: <571116B0.4050204@nthpermutation.com> From: Michael StJohns Message-ID: <57118EB7.9080907@nthpermutation.com> Date: Fri, 15 Apr 2016 21:00:39 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "cfrg@irtf.org" Subject: Re: [Cfrg] Adopting "AES-GCM-SIV: Nonce Misuse-Resistant Authenticated Encryption" as a CFRG document ---- Some clarifications X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Apr 2016 01:00:30 -0000 On 4/15/2016 1:13 PM, Adam Langley wrote: > On Fri, Apr 15, 2016 at 9:28 AM, Michael StJohns wrote: >> Is there any other scheme currently in use in our protocols (TLS, IPSEC, >> etc) that has the property that identical messages under the same key/nonce >> (or key IV) are encrypted identically? > I think all encryption schemes have this property if I understand you. > > Given a fixed (key, nonce, message), all AEADs should be > deterministic, i.e. will produce a fixed ciphertext. That includes > AES-GCM, ChaCha20-Poly1305, AES-CCM etc > > For CBC modes, some people consider them to be functions of (key, > message)→ciphertext, in which case the random IV makes them > non-deterministic in that model. But if considered to be a function of > (key, message, IV)→ciphertext then they, too, are deterministic too. Hi Adam - thanks for the question. That's not exactly what I mean/meant. In TLS, the same message (record, etc) sent under the same key and IV/NONCE (as produced by the TLS PRF/KDF functions or produced randomly) will provide different ciphertext based on the fact that the record counter changes with each message. That counter doesn't necessarily have to be part of the authenticated data in an AEAD cipher as the nonce formation is somewhat external to processing (with the exception of the block counter). To get the equivalent behavior for AES-GCM-SIV, you need to ensure there is some sort of per-message unique mixin (unique within the association duration at least) that causes the tag to be different which causes the nonce to be different. *sigh* Let me try it another way. Take generic AES-GCM, a key and a random association nonce. We form the message nonce from the concatenation of the association nonce and a message id or counter. We form the block nonce from the concatenation of the message nonce and the block counter. We encrypt the block nonce to provide the data to be XOR'd. The message and AD that we encrypt and protect need not include the message id - as long as we can derive it or count it, we don't have to send it and it will not be included under the cryptographic calculations. This mostly doesn't matter, because if either end gets the counter wrong, the message fails to authenticate at the receiver. That's not the case for AES-GCM-SIV. If the message ID is not part of the data provided (either payload to be encrypted or associated AD) to the POLYVAL function, you will have identical tags for identical messages leading to identical ciphertext for identical plain text. It turns out that this mostly doesn't matter to TLS or IPSEC as they both MAC the message sequence number so that's going to be covered by any AEAD Associated Data integrity processing and result in a different cipher text for the same message even with AES-GCM-SIV. But I remember arguments about removing the sequence number in other protocols to save space (e.g. its running over TLS - what do we need a sequence number in the record for? ) and I worry that this nuance might be missed in future protocols that use this cipher mode. Mike > > > Cheers > > AGL > From nobody Sat Apr 16 11:53:05 2016 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CA0B12DF17 for ; Sat, 16 Apr 2016 11:53:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.896 X-Spam-Level: X-Spam-Status: No, score=-2.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.996] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vHIbTqoK8C6i for ; Sat, 16 Apr 2016 11:53:02 -0700 (PDT) Received: from jupiter.mumble.net (jupiter.mumble.net [74.50.56.165]) by ietfa.amsl.com (Postfix) with ESMTP id F197A12DEF7 for ; Sat, 16 Apr 2016 11:53:01 -0700 (PDT) Received: by jupiter.mumble.net (Postfix, from userid 1014) id D031360319; Sat, 16 Apr 2016 18:51:33 +0000 (UTC) From: Taylor R Campbell To: "Dan Harkins" In-reply-to: <7a32ee823d39c1d80de6c179837451ab.squirrel@www.trepanning.net> (dharkins@lounge.org) Date: Sat, 16 Apr 2016 18:53:00 +0000 Sender: Taylor R Campbell User-Agent: IMAIL/1.21; Edwin/3.116; MIT-Scheme/9.1.99 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20160416185133.D031360319@jupiter.mumble.net> Archived-At: Cc: cfrg@irtf.org Subject: Re: [Cfrg] Adopting "AES-GCM-SIV: Nonce Misuse-Resistant Authenticated Encryption" as a CFRG document ---- Some clarifications X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Apr 2016 18:53:03 -0000 Date: Fri, 15 Apr 2016 13:46:19 -0700 (PDT) From: "Dan Harkins" Way back at IETF70 I proposed some ciphersuites for TLS using AES-SIV (RFC 5297). AES-SIV has the same nonce-misuse properties as AES-GCM-SIV but it's a 2-pass cipher mode. The general response I received can be summarized as "we don't need nonce misuse because the nonce is not part of the API that Joe User, who may be ignorant of nonce usage issues, calls and everyone writing a TLS implementation knows what he or she is doing so it's not a problem." I drafted the following message in reply: `For TLS, it is not a matter of ``all the implementors know what they're doing''. Rather, if you reuse a nonce, your implementation is simply broken and will immediately, noisily fail to interoperate. `For that case, AES-GCM-SIV is strictly less secure than AES-GCM because AES-GCM-SIV effectively uses randomly chosen 96-bit nonces and hence has a small birthday bound before an accidental internal nonce reuse (which is catastrophic). AES-GCM nonces, in contrast, are guaranteed never to repeat in a TLS conversation.' But then, on fact-checking myself, I discovered that the AES-GCM cipher suites in TLS (RFC 5288) do not actually mandate the use of the message sequence number as the nonce, which would have the fail-early fail-closed effect I described -- instead the senders pick nonces on their own arbitrarily and transmit them alongside the message, and the receivers accept any nonces they receive. From nobody Sat Apr 16 12:37:38 2016 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DB2412DD1A for ; Sat, 16 Apr 2016 12:37:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mtgR7vGb3yAz for ; Sat, 16 Apr 2016 12:37:36 -0700 (PDT) Received: from mail-wm0-x235.google.com (mail-wm0-x235.google.com [IPv6:2a00:1450:400c:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A10C812DCAA for ; Sat, 16 Apr 2016 12:37:35 -0700 (PDT) Received: by mail-wm0-x235.google.com with SMTP id v188so70758814wme.1 for ; Sat, 16 Apr 2016 12:37:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=k41DbbjVsVkSLEIPdh/FZ5kuJsrVSqBbQBunLqi9Jvs=; b=e+26kFKKT+Qyx+j85PhIqYZXuUGMSTq2TZyNGr2rYeZ0+kRrmt4CoD7AnuPFRpjLXi 7SiACIV3bdXTk/LP0H0fZmGCV18li/4HXk3lqia31YYuyfZx6tVvwhFxNJRezmwzROti 8mECwNZV7Z1kFi9BE2oia0+Jyt1u5iP9BtsNVTO1vlq0lRr2LkTY8NuOc3ni+SvHiKuV jAFfk0L6tPfmN1QRS27CJf8QKpK6l0GQoWT9vOSNbru0Wikue332EyBBohGu+cZtgcJm m/+aLiWXjFmqJEY2lQUOYW8LQUIDK+trPQKXcYAMSLyWCBhPLt7G+JFl8Zbk3wIysERK qZoQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=k41DbbjVsVkSLEIPdh/FZ5kuJsrVSqBbQBunLqi9Jvs=; b=K8UtaaDonAk7QAc84gkeTuZjJlHdKM2m5i8AAg2NoszyD8Ko2dH9/fTFiw6x6QRoQF CiGQ7+o2Gm8g427drvNludNw4u6/AUY9LM4Pm7tkyTuNLfxVePGsyzuKIEMi3gp677BU eeSGqabwyszslv4IU5LaX8ujO5IbVoHn8DQ7vJ4mAdGpOys2i3MujRWiS1f3jB2tIp4b LqnF33mOd2VY74cYczKO54WwxrT65vFtPyGPj/o3L3yPyvyRGa0GjnZvizTO++3UMvH2 9kumKZ9igZSEKSBEEX18jfIz3yY+VTjtNk1aWCVATbtVRfuuroJoufKVoPMSK1o5xCdp yuLw== X-Gm-Message-State: AOPr4FWQHzMDnyY0gzLsFdtC6CPS3I14UMgk+LRdVF7nCr6BlCLNK9WR58j/0jd9CFYBmA== X-Received: by 10.194.65.227 with SMTP id a3mr15769459wjt.149.1460835454177; Sat, 16 Apr 2016 12:37:34 -0700 (PDT) Received: from yoavs-mbp-2.lan (85-10-244-169.clients.your-server.de. [85.10.244.169]) by smtp.gmail.com with ESMTPSA id c144sm44952629wmd.0.2016.04.16.12.37.32 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 16 Apr 2016 12:37:33 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Yoav Nir In-Reply-To: <20160416185133.D031360319@jupiter.mumble.net> Date: Sat, 16 Apr 2016 21:35:17 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <886711D7-759E-4DAA-A5D0-E53D1D687DE0@gmail.com> References: <20160416185133.D031360319@jupiter.mumble.net> To: Taylor R Campbell X-Mailer: Apple Mail (2.3124) Archived-At: Cc: cfrg@irtf.org Subject: Re: [Cfrg] Adopting "AES-GCM-SIV: Nonce Misuse-Resistant Authenticated Encryption" as a CFRG document ---- Some clarifications X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Apr 2016 19:37:37 -0000 > On 16 Apr 2016, at 8:53 PM, Taylor R Campbell = wrote: >=20 > Date: Fri, 15 Apr 2016 13:46:19 -0700 (PDT) > From: "Dan Harkins" >=20 > Way back at IETF70 I proposed some ciphersuites for TLS using > AES-SIV (RFC 5297). AES-SIV has the same nonce-misuse properties > as AES-GCM-SIV but it's a 2-pass cipher mode. The general response > I received can be summarized as "we don't need nonce misuse because > the nonce is not part of the API that Joe User, who may be ignorant > of nonce usage issues, calls and everyone writing a TLS = implementation > knows what he or she is doing so it's not a problem." >=20 > I drafted the following message in reply: >=20 > `For TLS, it is not a matter of ``all the implementors know what > they're doing''. Rather, if you reuse a nonce, your implementation > is simply broken and will immediately, noisily fail to interoperate. >=20 > `For that case, AES-GCM-SIV is strictly less secure than AES-GCM > because AES-GCM-SIV effectively uses randomly chosen 96-bit nonces > and hence has a small birthday bound before an accidental internal > nonce reuse (which is catastrophic). AES-GCM nonces, in contrast, > are guaranteed never to repeat in a TLS conversation.' >=20 > But then, on fact-checking myself, I discovered that the AES-GCM > cipher suites in TLS (RFC 5288) do not actually mandate the use of the > message sequence number as the nonce, which would have the fail-early > fail-closed effect I described -- instead the senders pick nonces on > their own arbitrarily and transmit them alongside the message, and the > receivers accept any nonces they receive. That is true. However, most implementers have used the record number as = nonce, and TLS 1.3 makes this mandatory and implicit. Yoav From nobody Sun Apr 17 09:58:22 2016 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12A8B12DEE1 for ; Sun, 17 Apr 2016 09:58:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GryIzWSP66N8 for ; Sun, 17 Apr 2016 09:58:17 -0700 (PDT) Received: from mail-pf0-x22e.google.com (mail-pf0-x22e.google.com [IPv6:2607:f8b0:400e:c00::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 96A4812DE97 for ; Sun, 17 Apr 2016 09:58:17 -0700 (PDT) Received: by mail-pf0-x22e.google.com with SMTP id 184so72952804pff.0 for ; Sun, 17 Apr 2016 09:58:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:cc:date:message-id:in-reply-to:reply-to:user-agent :mime-version; bh=hmgZInwHXVeERHC26Lvn60WJ2NTNCU2AbDtaUHQGoJY=; b=tGWSQG0M7TDs/gPPVtviG/8yHmb+Q9Vg144B/kF3RRO+cpfELPIQBUIZTRfVFHrkQz Bh9JDOUedWV6pN77uaku2noWCsZwdL0jirBDuqnQPcpJZv3l7kx+Gtnex73fssGOf7uR HfONh6JoKYKG45QUjFffk+D10nC6cwUfnq27qgOFqtWZxi4zJcbJD6SVi/cNgnMARSpw gXHLrHvwoRYwHZ0uEjKFXD1CxPEgt2PHDIK1OvufboC4910dc3R36bsOZ6wtcfg1N9FT mDb62+Z2y+0LrfAfzeRD9JdFOOYHwxEloS1YwHbM4kJRlHU4wOkEfSrphquXNPkcmbGD qKLg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:subject:cc:date:message-id:in-reply-to :reply-to:user-agent:mime-version; bh=hmgZInwHXVeERHC26Lvn60WJ2NTNCU2AbDtaUHQGoJY=; b=ChtbXUAE3SzOfi5yEP6OMxPY/b+uqUaTM+N9k+dXSEisQKwPo70Zaey+vP3sWsSu9A SciY4FLDNYGB4sbN3ja9aoqmFne5URCtjjUwxogiYLl4bOmCF38df0yfUABuMDCET4HI rrCwwQ0cN3DZFidAnqUQ0aGGbWF9hVkwnWhE1ScGSMcqAMFPEkXHH6FssCAzdslqLIxc 9gAtEXfgk65dlxj0HCDz7gCnqY25rzSygmrGFQfve9dE7KcU1DtHLNOGClybYjdqlLxp dBKsdQnCJYC992WpwW0LWtMxJlPDqvNF5p1rVJmo+gxS8mIENzu8AxPabHIyjRCTnCVJ A94g== X-Gm-Message-State: AOPr4FWKJVyg55CO1Q0INDoYozCAoGgQkFbMnWFQomVtDhzvMddNMEjx5zyXnFUIIrbWJA== X-Received: by 10.98.1.69 with SMTP id 66mr44946024pfb.10.1460912297171; Sun, 17 Apr 2016 09:58:17 -0700 (PDT) Received: from [10.254.181.148] ([192.55.54.42]) by smtp.gmail.com with ESMTPSA id q72sm77805633pfa.70.2016.04.17.09.58.15 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sun, 17 Apr 2016 09:58:16 -0700 (PDT) From: "Gueron, Shay" To: "Gueron, Shay" , "Blumenthal, Uri - 0553 - MITLL" Date: Sun, 17 Apr 2016 16:58:08 +0000 Message-Id: In-Reply-To: User-Agent: eM_Client/6.0.24316.0 Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="------=_MBBF8BC8F6-EB0A-49C6-9F8D-7597A1806D48" Archived-At: Cc: Yehuda Lindell , "cfrg@irtf.org" , Adam Langley Subject: Re: [Cfrg] Adopting "AES-GCM-SIV: Nonce Misuse-Resistant Authenticated Encryption" as a CFRG document ---- Some clarifications X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: "Gueron, Shay" List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Apr 2016 16:58:20 -0000 --------=_MBBF8BC8F6-EB0A-49C6-9F8D-7597A1806D48 Content-Type: text/plain; format=flowed; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hello everyone - The asm code for MAC OS, for the 256-bit key is now also uploaded into=20 the Github repository (https://github.com/Shay-Gueron/AES-GCM-SIV). Regards, Shay ------ Original Message ------ From: "Gueron, Shay" To: "Blumenthal, Uri - 0553 - MITLL" Cc: "cfrg@irtf.org" ; "Shay Gueron"=20 ; "Yehuda Lindell" ;=20 "Adam Langley" Sent: 4/14/2016 11:09:08 AM Subject: Re[4]: [Cfrg] Adopting "AES-GCM-SIV: Nonce Misuse-Resistant=20 Authenticated Encryption" as a CFRG document ---- Some clarifications >Hello everyone - > >I uploaded an asm code version for MAC OS. It is in the Github=20 >repository (https://github.com/Shay-Gueron/AES-GCM-SIV). > >Now it is the code for the 128-bit key variant (the 256-bit key variant= =20 >will be uploaded next week). > >Regards, Shay > >------ Original Message ------ >From: "Blumenthal, Uri - 0553 - MITLL" >To: "Gueron, Shay" >Cc: "cfrg@irtf.org" >Sent: 4/10/2016 10:55:48 AM >Subject: Re: Re[2]: [Cfrg] Adopting "AES-GCM-SIV: Nonce=20 >Misuse-Resistant Authenticated Encryption" as a CFRG document ---- Some= =20 >clarifications > >>If it was only the native Mac OS X assembler (whose GAS is known to be= =20 >>much behind the standard) it wouldn't be so bad. >> >>But as I said - I've tried most every other assembler, including the=20 >>"all-powerful" YASM that usually can process whatever I throw at it.=20 >>YASM failed as well. >> >>I'd appreciate if you could release a "more portable" hand-tuned=20 >>version that could compile, e.g., under Yasm-1.3.0 (the current stable= =20 >>version). >> >>C intrinsics would also be great - but hopefully not at the cost of=20 >>hand-tuned code. >> >>Thanks! >> >>Sent from my BlackBerry 10 smartphone on the Verizon Wireless 4G LTE=20 >>network. >>From: Gueron, Shay >>Sent: Sunday, April 10, 2016 09:39 >>To: Blumenthal, Uri - 0553 - MITLL; Adam Langley; Andy Lutomirski >>Reply To: Gueron, Shay >>Cc: Yehuda Lindell; cfrg@irtf.org; Adam Langley; Shay Gueron >>Subject: Re[2]: [Cfrg] Adopting "AES-GCM-SIV: Nonce Misuse-Resistant=20 >>Authenticated Encryption" as a CFRG document ---- Some clarifications >> >> >> >>> BTW, what assembler is the optimized code supposed to work with? >> >>The code that is currently posted was compiled and tested under Red=20 >>Hat Linux, Fedora release 23, using GCC 4.8.2 & GNU assembly version=20 >>2.25. >> >>MAC OS does not easily chew this assembler syntax, and some work needs= =20 >>to be done around it. However, I will soon post a C (intrinsics)=20 >>version of the code, that should compile on all platforms (of course,=20 >>at the cost of giving up some performance that hand tuned assembler=20 >>achieves). >> >>Regards, Shay >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >>------ Original Message ------ >>From: "Blumenthal, Uri - 0553 - MITLL" >>To: "Adam Langley" ; "Andy Lutomirski"=20 >> >>Cc: "Yehuda Lindell" ; "cfrg@irtf.org"=20 >>; "Adam Langley" >>Sent: 4/8/2016 5:40:27 AM >>Subject: Re: [Cfrg] Adopting "AES-GCM-SIV: Nonce Misuse-Resistant=20 >>Authenticated Encryption" as a CFRG document ---- Some clarifications >> >>>BTW, what assembler is the optimized code supposed to work with? >>> >>>I'm on Mac OSX (10.10.5 and 10.11.4) using Xcode 7.2.1 and 7.3=20 >>>correspondingly. Both systems also have gcc-5.3 and clang-3.7. I also= =20 >>>t=E2=80=8Eried nasm, yasm. Nothing works. Would like some guidance. >>> >>>Sent from my BlackBerry 10 smartphone on the Verizon Wireless 4G LTE=20 >>>network. >>> Original Message >>>From: Adam Langley >>>Sent: Thursday, April 7, 2016 19:55 >>>To: Andy Lutomirski >>>Cc: Yehuda Lindell; cfrg@irtf.org; Adam Langley >>>Subject: Re: [Cfrg] Adopting "AES-GCM-SIV: Nonce Misuse-Resistant=20 >>>Authenticated Encryption" as a CFRG document ---- Some clarifications >>> >>>On Fri, Apr 8, 2016 at 8:16 AM, Andy Lutomirski = =20 >>>wrote: >>>> Can you clarify the draft? >>> >>>Will do as soon as I'm able (which should be next week). >>> >>> >>>Cheers >>> >>>AGL >>> >>>-- >>>Adam Langley agl@imperialviolet.orghttps://www.imperialviolet.org/ >>> >>>_______________________________________________ >>>Cfrg mailing list >>>Cfrg@irtf.org >>>https://www.irtf.org/mailman/listinfo/cfrg >>> >> --------=_MBBF8BC8F6-EB0A-49C6-9F8D-7597A1806D48 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Hello everyone -
 
The asm code for MAC OS, for the 256-bit key is now also uploaded into= the Github repository (https://github.com/Shay-Gueron/AES-GCM-SIV).
 
Regards, Shay
 
------ Original Message ------
From: "Gueron, Shay" <shay= .gueron@gmail.com>
To: "Blumenthal, Uri - 0553 - MITLL" <uri@ll.mit.edu>
Cc: "cfrg@irtf.org" <cfrg@irtf.org= >; "Shay Gueron" <shay.g= ueron@gmail.com>; "Yehuda Lindell" <Yehuda.Lindell@biu.ac.il>; "Adam Langley" <agl@google.com>
Sent: 4/14/2016 11:09:08 AM
Subject: Re[4]: [Cfrg] Adopting "AES-GCM-SIV: Nonce Misuse-Resistant= Authenticated Encryption" as a CFRG document ---- Some clarifications
 
Hello everyone -
 
I uploaded an asm code version for MAC OS. It is in the Github reposit= ory (https://github.= com/Shay-Gueron/AES-GCM-SIV).
 
Now it is the code for the 128-bit key variant (the 256-bit key varian= t will be uploaded next week).
 
Regards, Shay
 
------ Original Message ------
From: "Blumenthal, Uri - 0553 - MITLL" <uri@ll.mit.edu>
To: "Gueron, Shay" <shay.g= ueron@gmail.com>
Sent: 4/10/2016 10:55:48 AM
Subject: Re: Re[2]: [Cfrg] Adopting "AES-GCM-SIV: Nonce Misuse-Resista= nt Authenticated Encryption" as a CFRG document ---- Some clarifications
 
If= it was only the native Mac OS X assembler (whose GAS is known to be much= behind the standard) it wouldn't be so bad.
Bu= t as I said - I've tried most every other assembler, including the "all-pow= erful" YASM that usually can process whatever I throw at it. YASM failed= as well.
I'= d appreciate if you could release a "more portable" hand-tuned version that= could compile, e.g., under Yasm-1.3.0 (the current stable version).
C= intrinsics would also be great - but hopefully not at the cost of hand-tun= ed code.
Th= anks!
Sent from&= nbsp;my BlackBerry 10 smartphone on the Veriz= on Wireless 4G LTE network.
From: Gueron, Shay
Sent: Sunday, April 10, 2016 09:39
To: Blumenthal, Uri - 0553 - MITLL; Adam Langley; Andy Lutomirs= ki
Reply To: Gueron, Shay
Cc: Yehuda Lindell; cfrg@irtf.= org; Adam Langley; Shay Gueron
Subject: Re[2]: [Cfrg] Adopting "AES-GCM-SIV: Nonce Misuse-Resi= stant Authenticated Encryption" as a CFRG document ---- Some clarifications=

 
>>> BTW, = what assembler is the optimized code supposed to work with?=20

The code that is currently posted was compiled and tested under= Red Hat Linux, Fedora release 23, using GCC 4.8.2 & GNU assembly versi= on 2.25.
 
MAC OS does not easily chew this assembler syntax, and some work needs= to be done around it. However, I will soon post a C (intrinsics) version= of the code, that should compile on all platforms (of course, at the cost= of giving up some performance that hand tuned assembler achieves).
 
Regards, Shay
 
 
 
 
 
 
 
 
 
 

 

 

 
 
------ Original Message ------
From: "Blumenthal, Uri - 0553 - MITLL" <uri@ll.mit.edu>
To: "Adam Langley" <agl@i= mperialviolet.org>; "Andy Lutomirski" <luto@amacapital.net>
Cc: "Yehuda Lindell" <y= ehuda.lindell@biu.ac.il>; "cfrg@irt= f.org" <cfrg@irtf.org>; "Ada= m Langley" <agl@google.com>
Sent: 4/8/2016 5:40:27 AM
Subject: Re: [Cfrg] Adopting "AES-GCM-SIV: Nonce Misuse-Resistant Auth= enticated Encryption" as a CFRG document ---- Some clarifications
 
BTW, what assembler is the optimized code supposed to work with?
 
I'm on Mac OSX (10.10.5 and 10.11.4) using Xcode 7.2.1 and 7.3 corresp= ondingly. Both systems also have gcc-5.3 and clang-3.7. I also t=E2=80=8E= ried nasm, yasm. Nothing works. Would like some guidance. 
 
Sent from my BlackBerry 10 smartphone on=  the Verizon Wireless 4G LTE network.
  Original Message  
From: Adam Langley
Sent: Thursday, April 7, 2016 19:55
To: Andy Lutomirski
Cc: Yehuda Lindell; cfrg@irtf.org= ; Adam Langley
Subject: Re: [Cfrg] Adopting "AES-GCM-SIV: Nonce Misuse-Resistant Auth= enticated Encryption" as a CFRG document ---- Some clarifications
 
On Fri, Apr 8, 2016 at 8:16 AM, Andy Lutomirski <luto@amacapital.net> wrote:
 Can you clarify the draft?
 
Will do as soon as I'm able (which should be next week).
 
 
Cheers
 
AGL
 
--
 
_______________________________________________
Cfrg mailing list
 

--------=_MBBF8BC8F6-EB0A-49C6-9F8D-7597A1806D48-- From nobody Sun Apr 17 10:10:59 2016 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 862A012E047 for ; Sun, 17 Apr 2016 10:10:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.194 X-Spam-Level: X-Spam-Status: No, score=-5.194 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.996, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q7SVGmEfxRHZ for ; Sun, 17 Apr 2016 10:10:53 -0700 (PDT) Received: from llmx2.ll.mit.edu (LLMX2.LL.MIT.EDU [129.55.12.48]) by ietfa.amsl.com (Postfix) with ESMTP id C13BC12DE16 for ; Sun, 17 Apr 2016 10:10:53 -0700 (PDT) Received: from LLE2K10-HUB02.mitll.ad.local (LLE2K10-HUB02.mitll.ad.local) by llmx2.ll.mit.edu (unknown) with ESMTP id u3HH9Oxt040413; Sun, 17 Apr 2016 13:09:24 -0400 From: "Blumenthal, Uri - 0553 - MITLL" To: "Gueron, Shay" , "Gueron, Shay" Thread-Topic: Re[5]: [Cfrg] Adopting "AES-GCM-SIV: Nonce Misuse-Resistant Authenticated Encryption" as a CFRG document ---- Some clarifications Thread-Index: AdGYzBYJ4qEcPFXeE064ovYZBx4Nsw== Date: Sun, 17 Apr 2016 17:10:48 +0000 Message-ID: <20160417171049.18280531.98400.63798@ll.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="===============1522455917==" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-04-17_12:, , signatures=0 X-Proofpoint-Spam-Details: rule=inbound_notspam policy=inbound score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1603290000 definitions=main-1604170260 Archived-At: Cc: Yehuda Lindell , "cfrg@irtf.org" , Adam Langley Subject: Re: [Cfrg] Adopting "AES-GCM-SIV: Nonce Misuse-Resistant Authenticated Encryption" as a CFRG document ---- Some clarifications X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Apr 2016 17:10:57 -0000 --===============1522455917== Content-Type: multipart/alternative; boundary="===============1866733500==" MIME-Version: 1.0 --===============1866733500== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 VGhhbmsgeW91IHZlcnkgbXVjaCEgSSd2ZSB0cmllZCB0aGUgMTI4LWJpdCBzbyBmYXIsIGFuZCBj b25maXJtIHRoYXQg4oCOaXQgY29tcGlsZXMgJiBydW5zIGZpbmUgb24gTWFjIE9TIFguCgpTZW50 wqBmcm9twqBtecKgQmxhY2tCZXJyecKgMTDCoHNtYXJ0cGhvbmXCoG9uwqB0aGUgVmVyaXpvbsKg V2lyZWxlc3PCoDRHwqBMVEXCoG5ldHdvcmsuCkZyb206IEd1ZXJvbiwgU2hheQpTZW50OiBTdW5k YXksIEFwcmlsIDE3LCAyMDE2IDEyOjU4ClRvOiBHdWVyb24sIFNoYXk7IEJsdW1lbnRoYWwsIFVy aSAtIDA1NTMgLSBNSVRMTApSZXBseSBUbzogR3Vlcm9uLCBTaGF5CkNjOiBjZnJnQGlydGYub3Jn OyBZZWh1ZGEgTGluZGVsbDsgQWRhbSBMYW5nbGV5OyBTaGF5IEd1ZXJvbgpTdWJqZWN0OiBSZVs1 XTogW0NmcmddIEFkb3B0aW5nICJBRVMtR0NNLVNJVjogTm9uY2UgTWlzdXNlLVJlc2lzdGFudCBB dXRoZW50aWNhdGVkIEVuY3J5cHRpb24iIGFzIGEgQ0ZSRyBkb2N1bWVudCAtLS0tIFNvbWUgY2xh cmlmaWNhdGlvbnMKCkhlbGxvIGV2ZXJ5b25lIC0KwqAKVGhlIGFzbSBjb2RlIGZvciBNQUMgT1Ms IGZvciB0aGUgMjU2LWJpdCBrZXkgaXMgbm93IGFsc28gdXBsb2FkZWQgaW50byB0aGUgR2l0aHVi IHJlcG9zaXRvcnkgKGh0dHBzOi8vZ2l0aHViLmNvbS9TaGF5LUd1ZXJvbi9BRVMtR0NNLVNJViku CsKgClJlZ2FyZHMsIFNoYXkKwqAKLS0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0tCkZyb206 ICJHdWVyb24sIFNoYXkiIDxzaGF5Lmd1ZXJvbkBnbWFpbC5jb20+ClRvOiAiQmx1bWVudGhhbCwg VXJpIC0gMDU1MyAtIE1JVExMIiA8dXJpQGxsLm1pdC5lZHU+CkNjOiAiY2ZyZ0BpcnRmLm9yZyIg PGNmcmdAaXJ0Zi5vcmc+OyAiU2hheSBHdWVyb24iIDxzaGF5Lmd1ZXJvbkBnbWFpbC5jb20+OyAi WWVodWRhIExpbmRlbGwiIDxZZWh1ZGEuTGluZGVsbEBiaXUuYWMuaWw+OyAiQWRhbSBMYW5nbGV5 IiA8YWdsQGdvb2dsZS5jb20+ClNlbnQ6IDQvMTQvMjAxNiAxMTowOTowOCBBTQpTdWJqZWN0OiBS ZVs0XTogW0NmcmddIEFkb3B0aW5nICJBRVMtR0NNLVNJVjogTm9uY2UgTWlzdXNlLVJlc2lzdGFu dCBBdXRoZW50aWNhdGVkIEVuY3J5cHRpb24iIGFzIGEgQ0ZSRyBkb2N1bWVudCAtLS0tIFNvbWUg Y2xhcmlmaWNhdGlvbnMKwqAKSGVsbG8gZXZlcnlvbmUgLQrCoApJIHVwbG9hZGVkIGFuIGFzbSBj b2RlIHZlcnNpb24gZm9yIE1BQyBPUy4gSXQgaXMgaW4gdGhlIEdpdGh1YiByZXBvc2l0b3J5ICho dHRwczovL2dpdGh1Yi5jb20vU2hheS1HdWVyb24vQUVTLUdDTS1TSVYpLgrCoApOb3cgaXQgaXMg dGhlIGNvZGUgZm9yIHRoZSAxMjgtYml0IGtleSB2YXJpYW50ICh0aGUgMjU2LWJpdCBrZXkgdmFy aWFudCB3aWxsIGJlIHVwbG9hZGVkIG5leHQgd2VlaykuCsKgClJlZ2FyZHMsIFNoYXkKwqAKLS0t LS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0tCkZyb206ICJCbHVtZW50aGFsLCBVcmkgLSAwNTUz IC0gTUlUTEwiIDx1cmlAbGwubWl0LmVkdT4KVG86ICJHdWVyb24sIFNoYXkiIDxzaGF5Lmd1ZXJv bkBnbWFpbC5jb20+CkNjOiAiY2ZyZ0BpcnRmLm9yZyIgPGNmcmdAaXJ0Zi5vcmc+ClNlbnQ6IDQv MTAvMjAxNiAxMDo1NTo0OCBBTQpTdWJqZWN0OiBSZTogUmVbMl06IFtDZnJnXSBBZG9wdGluZyAi QUVTLUdDTS1TSVY6IE5vbmNlIE1pc3VzZS1SZXNpc3RhbnQgQXV0aGVudGljYXRlZCBFbmNyeXB0 aW9uIiBhcyBhIENGUkcgZG9jdW1lbnQgLS0tLSBTb21lIGNsYXJpZmljYXRpb25zCsKgCklmIGl0 IHdhcyBvbmx5IHRoZSBuYXRpdmUgTWFjIE9TIFggYXNzZW1ibGVyICh3aG9zZSBHQVMgaXMga25v d24gdG8gYmUgbXVjaCBiZWhpbmQgdGhlIHN0YW5kYXJkKSBpdCB3b3VsZG4ndCBiZSBzbyBiYWQu CgpCdXQgYXMgSSBzYWlkIC0gSSd2ZSB0cmllZCBtb3N0IGV2ZXJ5IG90aGVyIGFzc2VtYmxlciwg aW5jbHVkaW5nIHRoZSAiYWxsLXBvd2VyZnVsIiBZQVNNIHRoYXQgdXN1YWxseSBjYW4gcHJvY2Vz cyB3aGF0ZXZlciBJIHRocm93IGF0IGl0LiBZQVNNIGZhaWxlZCBhcyB3ZWxsLgoKSSdkIGFwcHJl Y2lhdGUgaWYgeW91IGNvdWxkIHJlbGVhc2UgYSAibW9yZSBwb3J0YWJsZSIgaGFuZC10dW5lZCB2 ZXJzaW9uIHRoYXQgY291bGQgY29tcGlsZSwgZS5nLiwgdW5kZXIgWWFzbS0xLjMuMCAodGhlIGN1 cnJlbnQgc3RhYmxlIHZlcnNpb24pLgoKQyBpbnRyaW5zaWNzIHdvdWxkIGFsc28gYmUgZ3JlYXQg LSBidXQgaG9wZWZ1bGx5IG5vdCBhdCB0aGUgY29zdCBvZiBoYW5kLXR1bmVkIGNvZGUuCgpUaGFu a3MhCgpTZW50wqBmcm9twqBtecKgQmxhY2tCZXJyecKgMTDCoHNtYXJ0cGhvbmXCoG9uwqB0aGXC oFZlcml6b24gV2lyZWxlc3PCoDRHwqBMVEXCoG5ldHdvcmsuCkZyb206IEd1ZXJvbiwgU2hheQpT ZW50OiBTdW5kYXksIEFwcmlsIDEwLCAyMDE2IDA5OjM5ClRvOiBCbHVtZW50aGFsLCBVcmkgLSAw NTUzIC0gTUlUTEw7IEFkYW0gTGFuZ2xleTsgQW5keSBMdXRvbWlyc2tpClJlcGx5IFRvOiBHdWVy b24sIFNoYXkKQ2M6IFllaHVkYSBMaW5kZWxsOyBjZnJnQGlydGYub3JnOyBBZGFtIExhbmdsZXk7 IFNoYXkgR3Vlcm9uClN1YmplY3Q6IFJlWzJdOiBbQ2ZyZ10gQWRvcHRpbmcgIkFFUy1HQ00tU0lW OiBOb25jZSBNaXN1c2UtUmVzaXN0YW50IEF1dGhlbnRpY2F0ZWQgRW5jcnlwdGlvbiIgYXMgYSBD RlJHIGRvY3VtZW50IC0tLS0gU29tZSBjbGFyaWZpY2F0aW9ucwoKwqAKPj4+IEJUVywgd2hhdCBh c3NlbWJsZXIgaXMgdGhlIG9wdGltaXplZCBjb2RlIHN1cHBvc2VkIHRvIHdvcmsgd2l0aD8KClRo ZSBjb2RlIHRoYXQgaXMgY3VycmVudGx5IHBvc3RlZCB3YXMgY29tcGlsZWQgYW5kIHRlc3RlZCB1 bmRlciBSZWQgSGF0IExpbnV4LCBGZWRvcmEgcmVsZWFzZSAyMywgdXNpbmcgR0NDIDQuOC4yICYg R05VIGFzc2VtYmx5IHZlcnNpb24gMi4yNS4KwqAKTUFDIE9TIGRvZXMgbm90IGVhc2lseSBjaGV3 IHRoaXMgYXNzZW1ibGVyIHN5bnRheCwgYW5kIHNvbWUgd29yayBuZWVkcyB0byBiZSBkb25lIGFy b3VuZCBpdC4gSG93ZXZlciwgSSB3aWxsIHNvb24gcG9zdCBhIEMgKGludHJpbnNpY3MpIHZlcnNp b24gb2YgdGhlIGNvZGUsIHRoYXQgc2hvdWxkIGNvbXBpbGUgb24gYWxsIHBsYXRmb3JtcyAob2Yg Y291cnNlLCBhdCB0aGUgY29zdCBvZiBnaXZpbmcgdXAgc29tZSBwZXJmb3JtYW5jZSB0aGF0IGhh bmQgdHVuZWQgYXNzZW1ibGVyIGFjaGlldmVzKS4KwqAKUmVnYXJkcywgU2hheQrCoArCoArCoArC oArCoArCoArCoArCoArCoArCoArCoAoKwqAKCsKgCsKgCi0tLS0tLSBPcmlnaW5hbCBNZXNzYWdl IC0tLS0tLQpGcm9tOiAiQmx1bWVudGhhbCwgVXJpIC0gMDU1MyAtIE1JVExMIiA8dXJpQGxsLm1p dC5lZHU+ClRvOiAiQWRhbSBMYW5nbGV5IiA8YWdsQGltcGVyaWFsdmlvbGV0Lm9yZz47ICJBbmR5 IEx1dG9taXJza2kiIDxsdXRvQGFtYWNhcGl0YWwubmV0PgpDYzogIlllaHVkYSBMaW5kZWxsIiA8 eWVodWRhLmxpbmRlbGxAYml1LmFjLmlsPjsgImNmcmdAaXJ0Zi5vcmciIDxjZnJnQGlydGYub3Jn PjsgIkFkYW0gTGFuZ2xleSIgPGFnbEBnb29nbGUuY29tPgpTZW50OiA0LzgvMjAxNiA1OjQwOjI3 IEFNClN1YmplY3Q6IFJlOiBbQ2ZyZ10gQWRvcHRpbmcgIkFFUy1HQ00tU0lWOiBOb25jZSBNaXN1 c2UtUmVzaXN0YW50IEF1dGhlbnRpY2F0ZWQgRW5jcnlwdGlvbiIgYXMgYSBDRlJHIGRvY3VtZW50 IC0tLS0gU29tZSBjbGFyaWZpY2F0aW9ucwrCoApCVFcsIHdoYXQgYXNzZW1ibGVyIGlzIHRoZSBv cHRpbWl6ZWQgY29kZSBzdXBwb3NlZCB0byB3b3JrIHdpdGg/CsKgCkknbSBvbiBNYWMgT1NYICgx MC4xMC41IGFuZCAxMC4xMS40KSB1c2luZyBYY29kZSA3LjIuMSBhbmQgNy4zIGNvcnJlc3BvbmRp bmdseS4gQm90aCBzeXN0ZW1zIGFsc28gaGF2ZSBnY2MtNS4zIGFuZCBjbGFuZy0zLjcuIEkgYWxz byB04oCOcmllZCBuYXNtLCB5YXNtLiBOb3RoaW5nIHdvcmtzLiBXb3VsZCBsaWtlIHNvbWUgZ3Vp ZGFuY2UuwqAKwqAKU2VudMKgZnJvbcKgbXnCoEJsYWNrQmVycnnCoDEwwqBzbWFydHBob25lwqBv bsKgdGhlIFZlcml6b27CoFdpcmVsZXNzwqA0R8KgTFRFwqBuZXR3b3JrLgrCoMKgT3JpZ2luYWwg TWVzc2FnZSDCoApGcm9tOiBBZGFtIExhbmdsZXkKU2VudDogVGh1cnNkYXksIEFwcmlsIDcsIDIw MTYgMTk6NTUKVG86IEFuZHkgTHV0b21pcnNraQpDYzogWWVodWRhIExpbmRlbGw7IGNmcmdAaXJ0 Zi5vcmc7IEFkYW0gTGFuZ2xleQpTdWJqZWN0OiBSZTogW0NmcmddIEFkb3B0aW5nICJBRVMtR0NN LVNJVjogTm9uY2UgTWlzdXNlLVJlc2lzdGFudCBBdXRoZW50aWNhdGVkIEVuY3J5cHRpb24iIGFz IGEgQ0ZSRyBkb2N1bWVudCAtLS0tIFNvbWUgY2xhcmlmaWNhdGlvbnMKwqAKT24gRnJpLCBBcHIg OCwgMjAxNiBhdCA4OjE2IEFNLCBBbmR5IEx1dG9taXJza2kgPGx1dG9AYW1hY2FwaXRhbC5uZXQ+ IHdyb3RlOgrCoENhbiB5b3UgY2xhcmlmeSB0aGUgZHJhZnQ/CsKgCldpbGwgZG8gYXMgc29vbiBh cyBJJ20gYWJsZSAod2hpY2ggc2hvdWxkIGJlIG5leHQgd2VlaykuCsKgCsKgCkNoZWVycwrCoApB R0wKwqAKLS0KQWRhbSBMYW5nbGV5IGFnbEBpbXBlcmlhbHZpb2xldC5vcmcgaHR0cHM6Ly93d3cu aW1wZXJpYWx2aW9sZXQub3JnLwrCoApfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXwpDZnJnIG1haWxpbmcgbGlzdApDZnJnQGlydGYub3JnCmh0dHBzOi8vd3d3 LmlydGYub3JnL21haWxtYW4vbGlzdGluZm8vY2ZyZwrCoAoKCg== --===============1866733500== Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable =
Thank you very much! I've tried the 128-bit so far, = and confirm that =E2=80=8Eit compiles & runs fine on Mac OS X.
= =

= = =
Sent from = my BlackBerry 10 smartphone on the Verizon&nb= sp;Wireless 4G LTE network.
= = =
From: Gueron, Sha= y
Sent: Sunday, April 17, 2016 12:58
To: = Gueron, Shay; Blumenthal, Uri - 0553 - MITLL
Reply To: Gue= ron, Shay
Cc: cfrg@irtf.org; Yehuda Lindell; Adam Langley;= Shay Gueron
Subject: Re[5]: [Cfrg] Adopting "AES-GCM-SIV:= Nonce Misuse-Resistant Authenticated Encryption" as a CFRG document ---- S= ome clarifications

Hello everyone -
 
The asm code for MAC OS, for the 256-bit key is now also uploaded into= the Github repository (https://github.com/Shay-Gueron/AES-GCM-SIV).
 
Regards, Shay
 
------ Original Message ------
From: "Gueron, Shay" <shay= .gueron@gmail.com>
To: "Blumenthal, Uri - 0553 - MITLL" <uri@ll.mit.edu>
Cc: "cfrg@irtf.org" <cfrg@irtf.org= >; "Shay Gueron" <shay.g= ueron@gmail.com>; "Yehuda Lindell" <Yehuda.Lindell@biu.ac.il>; "Adam Langley" <agl@google.com>
Sent: 4/14/2016 11:09:08 AM
Subject: Re[4]: [Cfrg] Adopting "AES-GCM-SIV: Nonce Misuse-Resistant A= uthenticated Encryption" as a CFRG document ---- Some clarifications
 
Hello everyone -
 
I uploaded an asm code version for MAC OS. It is in the Github reposit= ory (https://github.com/Shay-Gueron/AES-GCM-SIV).
 
Now it is the code for the 128-bit key variant (the 256-bit key varian= t will be uploaded next week).
 
Regards, Shay
 
------ Original Message ------
From: "Blumenthal, Uri - 0553 - MITLL" <uri@ll.mit.edu>
To: "Gueron, Shay" <shay.g= ueron@gmail.com>
Sent: 4/10/2016 10:55:48 AM
Subject: Re: Re[2]: [Cfrg] Adopting "AES-GCM-SIV: Nonce Misuse-Resista= nt Authenticated Encryption" as a CFRG document ---- Some clarifications
 
If it was only the native Mac OS X assembler (whose GAS is known to be much= behind the standard) it wouldn't be so bad.

But as I said - I've tried most every other assembler, including the "all-p= owerful" YASM that usually can process whatever I throw at it. YASM failed = as well.

I'd appreciate if you could release a "more portable" hand-tuned version th= at could compile, e.g., under Yasm-1.3.0 (the current stable version).

C intrinsics would also be great - but hopefully not at the cost of hand-tu= ned code.

Thanks!

Sent from my BlackBerry 10 smartphone on = ;the Verizon Wireless 4G LTE network.
From: Gueron, Shay
Sent: Sunday, April 10, 2016 09:39
To: Blumenthal, Uri - 0553 - MITLL; Adam Langley; Andy Lutomirs= ki
Reply To: Gueron, Shay
Cc: Yehuda Lindell; cfrg@irtf.= org; Adam Langley; Shay Gueron
Subject: Re[2]: [Cfrg] Adopting "AES-GCM-SIV: Nonce Misuse-Resi= stant Authenticated Encryption" as a CFRG document ---- Some clarifications=

 
>>> BTW, w= hat assembler is the optimized code supposed to work with?

The code that is currently posted was compiled and tested under Red Hat Lin= ux, Fedora release 23, using GCC 4.8.2 & GNU assembly version 2.25.
 
MAC OS does not easily chew this assembler syntax, and some work needs= to be done around it. However, I will soon post a C (intrinsics) version o= f the code, that should compile on all platforms (of course, at the cost of= giving up some performance that hand tuned assembler achieves).
 
Regards, Shay
 
 
 
 
 
 
 
 
 
 

 

 

 
 
------ Original Message ------
From: "Blumenthal, Uri - 0553 - MITLL" <uri@ll.mit.edu>
To: "Adam Langley" <agl@i= mperialviolet.org>; "Andy Lutomirski" <luto@amacapital.net>
Cc: "Yehuda Lindell" <y= ehuda.lindell@biu.ac.il>; "cfrg@irt= f.org" <cfrg@irtf.org>; "Ada= m Langley" <agl@google.com>
Sent: 4/8/2016 5:40:27 AM
Subject: Re: [Cfrg] Adopting "AES-GCM-SIV: Nonce Misuse-Resistant Auth= enticated Encryption" as a CFRG document ---- Some clarifications
 
BTW, what assembler is the optimized code supposed to work with?
 
I'm on Mac OSX (10.10.5 and 10.11.4) using Xcode 7.2.1 and 7.3 corresp= ondingly. Both systems also have gcc-5.3 and clang-3.7. I also t=E2=80=8Eri= ed nasm, yasm. Nothing works. Would like some guidance. 
 
Sent from my BlackBerry 10 smartphone on=  the Verizon Wireless 4G LTE network.
  Original Message  
From: Adam Langley
Sent: Thursday, April 7, 2016 19:55
To: Andy Lutomirski
Cc: Yehuda Lindell; cfrg@irtf.org= ; Adam Langley
Subject: Re: [Cfrg] Adopting "AES-GCM-SIV: Nonce Misuse-Resistant Auth= enticated Encryption" as a CFRG document ---- Some clarifications
 
On Fri, Apr 8, 2016 at 8:16 AM, Andy Lutomirski <luto@amacapital.net> wrote:
 Can you clarify the draft?
 
Will do as soon as I'm able (which should be next week).
 
 
Cheers
 
AGL
 
--
 
_______________________________________________
Cfrg mailing list
 


--===============1866733500==-- --===============1522455917== Content-Type: application/x-pkcs7-signature; name="smime.p7s" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExDTALBglghkgBZQMEAgEwgAYJKoZIhvcNAQcBAACggg7NMIIE 6jCCA9KgAwIBAgIKMz1Y1wAAAABunjANBgkqhkiG9w0BAQsFADBRMQswCQYDVQQGEwJVUzEfMB0G A1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRM TCBDQS0zMB4XDTE2MDExNDE3MzU1MloXDTE5MDExMzE3MzU1MlowYTELMAkGA1UEBhMCVVMxHzAd BgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDzANBgNVBAsTBlBlb3BsZTEgMB4GA1UEAxMX Qmx1bWVudGhhbC5VcmkuNTAwMTA1ODQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCz HVEw2ojNZjWEnTASyJaQIvzziBmrH07FzMEY2xFGNDJpss38CcFRjfRx1EyEp7BrFdAXC2pHjFwa gFr+McYdXZiKEci0Mzna2uibsMDVbhlT6TwtmAL6QzdtjN28dn+7vQUkRUWUm9VVaBVVxUgX3f2l oEZsJNvWb7C8vj2DZF/uEt/EU/9KcUuodMgCR4zYLFVpNh1U6tCYACNDNtj/nmNjubtez1Y56zjZ AVOXZWsjNCPrC2jVwDdg1AIcs5ayDMOC2p1F95kSxWsJwinKfSe8p2/YR/cwUo8ljFoBPj60AGW3 WjaJyKXK+ZgJwjwl9gG/pg2T4mQhIAIZWZQ9AgMBAAGjggGyMIIBrjAdBgNVHQ4EFgQUtKJz3aEd G/MvxjE38EW6PHdcUDQwDgYDVR0PAQH/BAQDAgbAMB8GA1UdIwQYMBaAFNdgZg57SY11TA39z0be yMcSh8q/MDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXRjcmwvTExD QTMwZgYIKwYBBQUHAQEEWjBYMC0GCCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0 dG8vTExDQTMwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLmxsLm1pdC5lZHUvb2NzcDA9BgkrBgEE AYI3FQcEMDAuBiYrBgEEAYI3FQiDg+Udh+ynZoathxWD6vBFhbahHx2Fy94yh/+KcwIBZAIBBjAi BgNVHSUBAf8EGDAWBggrBgEFBQcDBAYKKwYBBAGCNwoDDDAYBgNVHSAEETAPMA0GCyqGSIb3EgIB AwEIMBkGA1UdEQQSMBCBDnVyaUBsbC5taXQuZWR1MCcGCSsGAQQBgjcUAgQaHhgATABMAFUAcwBl AHIAUwBpAGcALQBTAFcwDQYJKoZIhvcNAQELBQADggEBAJTu0/WcX0ebe9UfUMslvy9fC2aCQong cVcEKlEjU8IvCKa6YpZHQKTVXQ3e4KKvw1DgzFvq8/rOv87Woj45q8smgNyivgAMCnrT7a6B/9Kn 85l9BjeoLMPLypvsmz1l7oX45NPr3LF4VEMzxqczdovS14woPKdegEKQYyPSZGhKTCCe/9FhtgEc 3gfVyE1mH6ZNeDEalr7nx7F0qemhh3QN6i6XPrudzv9el5JeovPedZ0JqDT0ctXj6ECYOiEyEfJm 85C5QGmpjLmCM99gAmgpP5Tx6APB/tvcUw/mgt4HOvqavGkvUkoJ8XEEwt9AgXaznS626Kb8RpAh w2zN2yMwggTqMIID0qADAgECAgozPVjXAAAAAG6eMA0GCSqGSIb3DQEBCwUAMFExCzAJBgNVBAYT AlVTMR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxEzARBgNV BAMTCk1JVExMIENBLTMwHhcNMTYwMTE0MTczNTUyWhcNMTkwMTEzMTczNTUyWjBhMQswCQYDVQQG EwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEPMA0GA1UECxMGUGVvcGxlMSAw HgYDVQQDExdCbHVtZW50aGFsLlVyaS41MDAxMDU4NDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBALMdUTDaiM1mNYSdMBLIlpAi/POIGasfTsXMwRjbEUY0MmmyzfwJwVGN9HHUTISnsGsV 0BcLakeMXBqAWv4xxh1dmIoRyLQzOdra6JuwwNVuGVPpPC2YAvpDN22M3bx2f7u9BSRFRZSb1VVo FVXFSBfd/aWgRmwk29ZvsLy+PYNkX+4S38RT/0pxS6h0yAJHjNgsVWk2HVTq0JgAI0M22P+eY2O5 u17PVjnrONkBU5dlayM0I+sLaNXAN2DUAhyzlrIMw4LanUX3mRLFawnCKcp9J7ynb9hH9zBSjyWM WgE+PrQAZbdaNonIpcr5mAnCPCX2Ab+mDZPiZCEgAhlZlD0CAwEAAaOCAbIwggGuMB0GA1UdDgQW BBS0onPdoR0b8y/GMTfwRbo8d1xQNDAOBgNVHQ8BAf8EBAMCBsAwHwYDVR0jBBgwFoAU12BmDntJ jXVMDf3PRt7IxxKHyr8wMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC5sbC5taXQuZWR1L2dl dGNybC9MTENBMzBmBggrBgEFBQcBAQRaMFgwLQYIKwYBBQUHMAKGIWh0dHA6Ly9jcmwubGwubWl0 LmVkdS9nZXR0by9MTENBMzAnBggrBgEFBQcwAYYbaHR0cDovL29jc3AubGwubWl0LmVkdS9vY3Nw MD0GCSsGAQQBgjcVBwQwMC4GJisGAQQBgjcVCIOD5R2H7Kdmhq2HFYPq8EWFtqEfHYXL3jKH/4pz AgFkAgEGMCIGA1UdJQEB/wQYMBYGCCsGAQUFBwMEBgorBgEEAYI3CgMMMBgGA1UdIAQRMA8wDQYL KoZIhvcSAgEDAQgwGQYDVR0RBBIwEIEOdXJpQGxsLm1pdC5lZHUwJwYJKwYBBAGCNxQCBBoeGABM AEwAVQBzAGUAcgBTAGkAZwAtAFMAVzANBgkqhkiG9w0BAQsFAAOCAQEAlO7T9ZxfR5t71R9QyyW/ L18LZoJCieBxVwQqUSNTwi8IprpilkdApNVdDd7goq/DUODMW+rz+s6/ztaiPjmryyaA3KK+AAwK etPtroH/0qfzmX0GN6gsw8vKm+ybPWXuhfjk0+vcsXhUQzPGpzN2i9LXjCg8p16AQpBjI9JkaEpM IJ7/0WG2ARzeB9XITWYfpk14MRqWvufHsXSp6aGHdA3qLpc+u53O/16Xkl6i8951nQmoNPRy1ePo QJg6ITIR8mbzkLlAaamMuYIz32ACaCk/lPHoA8H+29xTD+aC3gc6+pq8aS9SSgnxcQTC30CBdrOd LrbopvxGkCHDbM3bIzCCBO0wggPVoAMCAQICCjM4lI8AAAAAbpYwDQYJKoZIhvcNAQELBQAwUTEL MAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsTA1BL STETMBEGA1UEAxMKTUlUTEwgQ0EtMzAeFw0xNjAxMTQxNzMwMzlaFw0xOTAxMTMxNzMwMzlaMGEx CzAJBgNVBAYTAlVTMR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQ8wDQYDVQQLEwZQ ZW9wbGUxIDAeBgNVBAMTF0JsdW1lbnRoYWwuVXJpLjUwMDEwNTg0MIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEA4xQ2hom9O5hwXTWlTDaY/fuIiWvivQHEzd8volNcoLbxxuHKLXgwX++2 TdbsHbfpaHVtAvF8huN7Lkn6Taf6MCzlBJRWoAJz6hwLwFCMLJeQI853KST/u/FIuLt+GjDbHXT/ kGbvRyNkIPj+njA9uY5I8m0/XUDMV2aTtqEwc55Vo2CCLXWYStQ1maiEdGre59mIwkkLGTV9JSeC cK7Yx2Ba2D552QtH9QdjO1eeCEvOtwhMn7uV6LaGcfGLh8GKSkhavNEhIenDAy3U3tWQI1sbJ28i guuK63krciNj1TfbgVnfjpXhqCAI1aIKTCiotKUkR3ArsA8BnpKUFbmyvQIDAQABo4IBtTCCAbEw HQYDVR0OBBYEFPFPxYiZomy2ZdvinDW1VhNj2YqbMA4GA1UdDwEB/wQEAwIFIDAfBgNVHSMEGDAW gBTXYGYOe0mNdUwN/c9G3sjHEofKvzAzBgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLmxsLm1p dC5lZHUvZ2V0Y3JsL0xMQ0EzMGYGCCsGAQUFBwEBBFowWDAtBggrBgEFBQcwAoYhaHR0cDovL2Ny bC5sbC5taXQuZWR1L2dldHRvL0xMQ0EzMCcGCCsGAQUFBzABhhtodHRwOi8vb2NzcC5sbC5taXQu ZWR1L29jc3AwPQYJKwYBBAGCNxUHBDAwLgYmKwYBBAGCNxUIg4PlHYfsp2aGrYcVg+rwRYW2oR8d hevQcIPr7SACAWQCAQUwJQYDVR0lBB4wHAYEVR0lAAYIKwYBBQUHAwQGCisGAQQBgjcKAwQwGAYD VR0gBBEwDzANBgsqhkiG9xICAQMBCDAZBgNVHREEEjAQgQ51cmlAbGwubWl0LmVkdTAnBgkrBgEE AYI3FAIEGh4YAEwATABVAHMAZQByAEUAbgBjAC0AUwBXMA0GCSqGSIb3DQEBCwUAA4IBAQAW7r7P ZtIEuVPCSblXPqrbVdgVkNIw3qV6WHz/8TfK1UnETx3tkjFGhR+TjEYYXhiZHaIFlTZzK4x8UH6X 3NM/MqLZQ98cFxDVlGOTKEJqRBgdpLBaoDHddtW6s0d1mPOC3KLH6MNDKKZV7PJrzu056M8DPj7R mbNJqadj8wZL1nTW7Nq/+8FyT+v6S3ecz78sETYU4KFXtWjeIryJFPLL5CjIIL+WWjrKJ2lvCUun VGJr75NELwyUSEDUUdM6UKTiqfuFf14TGUYcUCdw41U44fUP6RypuwERYRa90ACeqHAo8syxeYrL GtVbIcexJQSJNHF4XqepizC6hjV92swJMYIB8TCCAe0CAQEwXzBRMQswCQYDVQQGEwJVUzEfMB0G A1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRM TCBDQS0zAgozPVjXAAAAAG6eMAsGCWCGSAFlAwQCAaBpMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTE2MDQxNzE3MTA0N1owLwYJKoZIhvcNAQkEMSIEIMV9Zo9LLPN+ 1gLCrLfPaLMghI1ZCRhNv7KhwGR/OBNcMAsGCSqGSIb3DQEBCwSCAQAe3TcnApeWg+HvJBE1F2XM m917yGrK3UtkFxLDgnKRWqbrqKaV90mVg7hxqQfXg+VUJuUKAHB457AqSdpiukbRB3k/0w/9Ljis 3itDVX9LnLiHD5kvBYNUcMFcYpFpZAwq7KHgbvo83Ea6PZqVaoUNp5gyUaQVd0tBQULNhLXMeIAU nZ07VskmwxS90o2jNommLLvHMn1kryZSkqBu4ss3KjawAUYSqZi3UmkaaxkPHPVeXcWwNvnWuCLt umKUabY2Nnk3sdsNiSKKy6LP/Lp5MReOhl97HGJa62G242HxlfDZzMoQLaepuFgexRRwp3UUYI6U +txq9Y7tn6gyYBDGAAAAAAAA --===============1522455917==-- From nobody Sun Apr 17 10:25:35 2016 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9587712D1D1 for ; Sun, 17 Apr 2016 10:25:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.4 X-Spam-Level: X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pFQM7J7U756T for ; Sun, 17 Apr 2016 10:25:33 -0700 (PDT) Received: from mail-ig0-x242.google.com (mail-ig0-x242.google.com [IPv6:2607:f8b0:4001:c05::242]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F3B7012D1D8 for ; Sun, 17 Apr 2016 10:25:32 -0700 (PDT) Received: by mail-ig0-x242.google.com with SMTP id kb1so8418843igb.3 for ; Sun, 17 Apr 2016 10:25:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc; bh=AYV6xX+m2X6NHTnChXiOCgO7Oyv74moKURUaZGItgWk=; b=IEwpiIoHusaxQNBei809QUkHVLv3DbXW5CYH0MFm7DSvgYu3a5Sb1tvSI1VbbUkEtC zUqd+GZGQ0U9J6mG+Rib38V6/T3RaUcJj3TVGUcqQUveQCm7FF4lzVRmMFi4Mdm1ifqZ 3bYAunE3ttr6kBwYTgTiHhR9OT+wBPTvktPS1v8lL465V9/QTQRzeq3Y425Yxv8jJggN V7AhYqq08rdhAygnb57p5eFIBlR+4LjU+nNm7Wk0WDFTeSd4TEzbkBhIEOOczI1eJrn7 S69AtqV7qwLozAJ7IJ4MUS09U6Joerf2QC24EdfCbDUidaZ7m8E6JGAW3VNGPbKJhi7I Qrzw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=AYV6xX+m2X6NHTnChXiOCgO7Oyv74moKURUaZGItgWk=; b=NYnLtsiYmGSt/Q8UPu9mjuLvEXxO6zuRIqtuX1ANdyhKI5U3KDGV0j9XuFWbzrimkf 74VAoZ+7d5mm3mefc8TpQGj13HFFtDysgVXaoIy9OsqH4Plc2KSfD9ti4fBuEf+LbSCH oecepjymgrPxztkdJCUttwOOcE+pW7dI8ADrovwUl4CYn8YUAmRf/AYTeGV/rTxUoE04 ODTUfRjwokQtsWrZLicVCj4Y+TlBHa9nlEW0a9WJyzIG+DythX/X2L4Yj36n+rHJC7Ui Dv1ACAQaCFkJPfb8kR58m0nc3L5GaOlvOJF/I52uqxO+IgdfNg6viXDmGzUiC3xYut+6 AMEw== X-Gm-Message-State: AOPr4FV6q8Ua5+1EWso+r7V7kSwagtU7KNeAheDnwKR39xlzrZs5od8ZN5Mechc3IuQWCr6Ge5sOcXxOswrkbA== MIME-Version: 1.0 X-Received: by 10.50.8.97 with SMTP id q1mr15294071iga.26.1460913932306; Sun, 17 Apr 2016 10:25:32 -0700 (PDT) Sender: alangley@gmail.com Received: by 10.79.117.133 with HTTP; Sun, 17 Apr 2016 10:25:32 -0700 (PDT) In-Reply-To: <57118EB7.9080907@nthpermutation.com> References: <571116B0.4050204@nthpermutation.com> <57118EB7.9080907@nthpermutation.com> Date: Sun, 17 Apr 2016 10:25:32 -0700 X-Google-Sender-Auth: aDGFlt23OizyDrId6fZV2K6RgLw Message-ID: From: Adam Langley To: Michael StJohns Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "cfrg@irtf.org" Subject: Re: [Cfrg] Adopting "AES-GCM-SIV: Nonce Misuse-Resistant Authenticated Encryption" as a CFRG document ---- Some clarifications X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Apr 2016 17:25:34 -0000 On Fri, Apr 15, 2016 at 6:00 PM, Michael StJohns wrote: > That's not exactly what I mean/meant. In TLS, the same message (record, > etc) sent under the same key and IV/NONCE (as produced by the TLS PRF/KDF > functions or produced randomly) will provide different ciphertext based on > the fact that the record counter changes with each message. That counter > doesn't necessarily have to be part of the authenticated data in an AEAD > cipher as the nonce formation is somewhat external to processing (with the > exception of the block counter). > > To get the equivalent behavior for AES-GCM-SIV, you need to ensure there is > some sort of per-message unique mixin (unique within the association > duration at least) that causes the tag to be different which causes the > nonce to be different. That's correct and, in the case of TLS, I'd suggest that the sequence number be used as the nonce in order to make sure that equal messages don't produce equal ciphertexts. Although, to be clear, I'm not suggesting that AES-GCM-SIV be used in TLS or in any situation where a counter nonce is easy. Transport security is generally a situation where a single sender can just use a counter and, in those cases, AES-GCM is better. But there are situations where nonce management is a problem (i.e. where there are multiple machines encrypting with a single key) and, for that, I think AES-GCM-SIV is pretty attractive because one can reasonably use a random nonce. Cheers AGL From nobody Mon Apr 18 00:16:50 2016 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CAD312D771 for ; Mon, 18 Apr 2016 00:16:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.996 X-Spam-Level: X-Spam-Status: No, score=-2.996 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isode.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zc9DJ3KHREbZ for ; Mon, 18 Apr 2016 00:16:48 -0700 (PDT) Received: from waldorf.isode.com (waldorf.isode.com [62.232.206.188]) by ietfa.amsl.com (Postfix) with ESMTP id 3A79812D69B for ; Mon, 18 Apr 2016 00:16:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1460963807; d=isode.com; s=selector; i=@isode.com; bh=4brxqin7FrqY7OhOA8k6S4drFidPbjxd6bb774/F0EA=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=tszAYTMH12EUWKND/xfMu2vIb1ojH8aqeC4KuNFTNll7TlqRjmFdbvyXYbChRFv7D7FufU 9zMYsydvPJjk+GblaRSQAkTAjgiZp/8PXYV+AIMINYbY8RpKTmJjwxYJZyXnfkk/bvJrQV xXJ25xIOT9rhzGptXQLUhMNG+4YCAAE=; Received: from [192.168.0.6] (cpc5-nmal20-2-0-cust24.19-2.cable.virginm.net [92.234.84.25]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Mon, 18 Apr 2016 08:16:46 +0100 X-SMTP-Protocol-Errors: PIPELINING From: Alexey Melnikov Date: Mon, 18 Apr 2016 08:23:53 +0100 Message-Id: To: "cfrg@irtf.org" X-Mailer: iPad Mail (13E238) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary=Apple-Mail-C5C9421B-999E-4939-AE29-5F6575BB743A Content-Transfer-Encoding: 7bit Archived-At: Subject: [Cfrg] RGLC on draft-irtf-cfrg-pake-reqs-02 X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2016 07:16:49 -0000 --Apple-Mail-C5C9421B-999E-4939-AE29-5F6575BB743A Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable This message starts 2 weeks CFRG Last Call on "Requirements for PAKE schemes= " (draft-irtf-cfrg-pake-reqs-02.txt). Please send your reviews, statements i= n support of publication (or not) before May 2nd. These can be sent to the m= ailing list or, if you prefer, directly to CFRG chairs. Thank you, Alexey, On behalf of CFRG chairs. --Apple-Mail-C5C9421B-999E-4939-AE29-5F6575BB743A Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit

This message starts 2 weeks CFRG Last Call on "Requirements for PAKE schemes" (draft-irtf-cfrg-pake-reqs-02.txt). Please send your reviews, statements in support of publication (or not) before May 2nd. These can be sent to the mailing list or, if you prefer, directly to CFRG chairs.


Thank you,
Alexey,
On behalf of CFRG chairs.

--Apple-Mail-C5C9421B-999E-4939-AE29-5F6575BB743A-- From nobody Mon Apr 18 00:22:11 2016 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F7AD12DB2B for ; Mon, 18 Apr 2016 00:22:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.788 X-Spam-Level: X-Spam-Status: No, score=-2.788 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-0.996, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (bad RSA signature)" header.d=azet.sk Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6HlgOoAZBZlk for ; Mon, 18 Apr 2016 00:22:08 -0700 (PDT) Received: from smtp2.azet.sk (smtp-07-out.s.azet.sk [91.235.53.32]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA97D12DB29 for ; Mon, 18 Apr 2016 00:22:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=azet.sk; s=azet; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:From:References:To:Subject; bh=xVA2WrA5Ox/96KPPfPHien5t1bIh51e82yFERSDsV/8=; b=aift1ik1MwhgN9AUmwCBfXnjt5oc7fGjqagjDzu7b0vIh/+CrFRgT665hnWzL1O8Z4A43/KlBAasa8+9y2cmLbW1zPVkANwVwWUXHi5JqanuqHTb2HiWlCY3Fda6VnjpoU960u9nC78QZmfafdsHpbbQSVu4kkCDi7lO91iyHWw=; Received: from smtp-02-auth.e.etech.sk ([10.11.2.101] helo=smtp.azet.sk) by smtp2.azet.sk stage1 with esmtp (Exim MailCleaner) id 1as3VV-0005qc-QD for from ; Mon, 18 Apr 2016 09:22:05 +0200 Received: from 127.0.0.1 (unknown [80.255.3.122]) (Authenticated sender: fedor.brunner@azet.sk) by smtp.azet.sk (Postfix) with ESMTPA id F405988 for ; Mon, 18 Apr 2016 09:21:57 +0200 (CEST) X-SenderID: Sendmail Sender-ID Filter v1.0.0 smtp.azet.sk F405988 Authentication-Results: smtp.azet.sk; sender-id=fail (NotPermitted) header.from=fedor.brunner@azet.sk; auth=pass (PLAIN); spf=fail (NotPermitted) smtp.mfrom=fedor.brunner@azet.sk To: cfrg@irtf.org References: <571116B0.4050204@nthpermutation.com> <57118EB7.9080907@nthpermutation.com> From: Fedor Brunner X-Enigmail-Draft-Status: N1110 Message-ID: <57148B14.7020507@azet.sk> Date: Mon, 18 Apr 2016 09:21:56 +0200 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-MailCleaner-DMARC: quarantine Archived-At: Subject: Re: [Cfrg] Adopting "AES-GCM-SIV: Nonce Misuse-Resistant Authenticated Encryption" as a CFRG document ---- Some clarifications X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2016 07:22:10 -0000 Adam Langley: > On Fri, Apr 15, 2016 at 6:00 PM, Michael StJohns wrote: >> That's not exactly what I mean/meant. In TLS, the same message (record, >> etc) sent under the same key and IV/NONCE (as produced by the TLS PRF/KDF >> functions or produced randomly) will provide different ciphertext based on >> the fact that the record counter changes with each message. That counter >> doesn't necessarily have to be part of the authenticated data in an AEAD >> cipher as the nonce formation is somewhat external to processing (with the >> exception of the block counter). >> >> To get the equivalent behavior for AES-GCM-SIV, you need to ensure there is >> some sort of per-message unique mixin (unique within the association >> duration at least) that causes the tag to be different which causes the >> nonce to be different. > > That's correct and, in the case of TLS, I'd suggest that the sequence > number be used as the nonce in order to make sure that equal messages > don't produce equal ciphertexts. Although, to be clear, I'm not > suggesting that AES-GCM-SIV be used in TLS or in any situation where a > counter nonce is easy. Transport security is generally a situation > where a single sender can just use a counter and, in those cases, > AES-GCM is better. > > But there are situations where nonce management is a problem (i.e. > where there are multiple machines encrypting with a single key) and, > for that, I think AES-GCM-SIV is pretty attractive because one can > reasonably use a random nonce. https://cr.yp.to/papers.html#xsalsa XSalsa20 is Salsa20 cipher with nonce extended to 192 bits. So there is no need to manage nonces, they can be generated with RNG. Could you please describe applications where you would prefer AES-GCM-SIV over XSalsa20+Poly1305 > > > Cheers > > AGL > > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > https://www.irtf.org/mailman/listinfo/cfrg > > From nobody Mon Apr 18 02:29:38 2016 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5041C12D150 for ; Mon, 18 Apr 2016 02:29:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=rhul.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fG_wR37Omh9i for ; Mon, 18 Apr 2016 02:29:35 -0700 (PDT) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0657.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::657]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AFD9F12D143 for ; Mon, 18 Apr 2016 02:29:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rhul.onmicrosoft.com; s=selector1-rhul-ac-uk; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=YkQD2e1MIvu/wxozEmIxOtmR7fz2pE6aDb3Cq93yy/s=; b=sweEFzFVdxGw2+jEXGM6z6pb9KKI4HgB9fwgHPW2ZyRTTinYhJFT8w+PHPMVF44S4mzGm0yGX5gj5uy1HHKpG01P14/nw/x2ZqeLRBZjghKICJqLsXcOPQKxcEkHaGLP5+Hb6Sw3QYu3a+BSQS7FX7KFe3BgjdNku53layH5NyM= Received: from VI1PR03MB1822.eurprd03.prod.outlook.com (10.166.42.148) by VI1PR03MB1822.eurprd03.prod.outlook.com (10.166.42.148) with Microsoft SMTP Server (TLS) id 15.1.466.19; Mon, 18 Apr 2016 09:29:16 +0000 Received: from VI1PR03MB1822.eurprd03.prod.outlook.com ([10.166.42.148]) by VI1PR03MB1822.eurprd03.prod.outlook.com ([10.166.42.148]) with mapi id 15.01.0466.022; Mon, 18 Apr 2016 09:29:16 +0000 From: "Paterson, Kenny" To: "cfrg@irtf.org" Thread-Topic: Adopting "AES-GCM-SIV: Nonce Misuse-Resistant Authenticated Encryption" as a CFRG document Thread-Index: AQHRiP7+wUFnuBtreUe1MCzt43wYjp+PqI2A Date: Mon, 18 Apr 2016 09:29:16 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.2.160219 authentication-results: irtf.org; dkim=none (message not signed) header.d=none;irtf.org; dmarc=none action=none header.from=rhul.ac.uk; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [92.4.66.92] x-ms-office365-filtering-correlation-id: a220ec95-b585-4438-175a-08d3676be9a4 x-microsoft-exchange-diagnostics: 1; VI1PR03MB1822; 5:aTRXWjXTcyyOnu4blaLX1r335n7PwXvuA2ca/w8x27HiS2KZAai8bsgQD1j9m5VRPksvxYViecS2Fu2KkBMtU0rIPsmPv14uEcBE0FdQI7ri4NBbA2fmKtPCIxZEtRGH21pkwa6TeXE0tfoEuo7lUlwqZ7/bySdSAOLghgyOOcECVZZgFAHwYfiqI7oY6Lu6; 24:dXUrfgQlJPxlpPclPJg0n/kbO4KBsGquTYdmqH6zOCRjlzdOExYRXdpPjjGQufYGhRUS12tVcCbtBphXaNvsuskbaWVOOX8OfeyWAYhzMPc=; 7:SGjKnzbGADNCwtTY7/crmeG1kk8fC5lY25Pyly7XeF0kQCe9zXf4v/KtJlGVbNsLGlqBy6mZKClz5exYgDU3jFxu3RVMu62mxtCjNzrDCqE1w8lTck7BEzzWM354k0uZ0VqHrv9AB+wlpsuy06DUNBbFlwh6heUQBDRca9aRh316+HSue0iI4P4AyTZLcEC+S5tNfFDIPocxT7JUKKRSeA== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:VI1PR03MB1822; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(9101521026)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001); SRVR:VI1PR03MB1822; BCL:0; PCL:0; RULEID:; SRVR:VI1PR03MB1822; x-forefront-prvs: 0916FC3A18 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(24454002)(110136002)(83506001)(586003)(4326007)(1096002)(230783001)(5002640100001)(19580395003)(19580405001)(1220700001)(10400500002)(189998001)(102836003)(122556002)(3846002)(2906002)(4001350100001)(36756003)(2501003)(6116002)(1730700002)(5640700001)(81166005)(5008740100001)(74482002)(5004730100002)(3280700002)(86362001)(11100500001)(92566002)(3660700001)(50986999)(15975445007)(66066001)(76176999)(54356999)(87936001)(2950100001)(77096005)(2351001)(106116001); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR03MB1822; H:VI1PR03MB1822.eurprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: text/plain; charset="utf-8" Content-ID: <1BE0BFDBCDDA4B4FB9B30B857714FBF1@eurprd03.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: rhul.ac.uk X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Apr 2016 09:29:16.7440 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2efd699a-1922-4e69-b601-108008d28a2e X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR03MB1822 Archived-At: Cc: Yehuda Lindell , Adam Langley Subject: Re: [Cfrg] Adopting "AES-GCM-SIV: Nonce Misuse-Resistant Authenticated Encryption" as a CFRG document X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2016 09:29:37 -0000 RGVhciBDRlJHLA0KDQpDaGFpcnMgaGFkIGFza2VkIGZvciBkaXNjdXNzaW9uIG9uIHdoZXRoZXIg dGhlIEFFUy1HQ00tU0lWIGRvY3VtZW50IHNob3VsZA0KYmUgYWRvcHRlZCBhcyBhIENGUkcgZG9j dW1lbnQgKHNlZSBiZWxvdykuIFRoZSBjaGFpcnMgaGF2ZSBiZWVuIGZvbGxvd2luZw0KdGhlIGVu c3VpbmcgZGlzY3Vzc2lvbnMgd2l0aCBpbnRlcmVzdC4gVGFraW5nIGFsbCB0aGUgZGlzY3Vzc2lv biBpbnRvDQphY2NvdW50LCBvdXIgdmlldyBpcyB0aGF0IHRoZXJlIGlzIHJvdWdoIGNvbnNlbnN1 cyB0byBhZG9wdCB0aGUNCkFFUy1HQ00tU0lWIGRyYWZ0IGFzIGEgQ0ZSRyBkb2N1bWVudC4NCg0K UmVnYXJkcywNCg0KS2VubnkgKGZvciB0aGUgY2hhaXJzKQ0KDQoNCg0KT24gMjgvMDMvMjAxNiAx NTozNCwgIlBhdGVyc29uLCBLZW5ueSIgPEtlbm55LlBhdGVyc29uQHJodWwuYWMudWs+IHdyb3Rl Og0KDQo+RGVhciBDRlJHLA0KPg0KPlNoYXksIEFkYW0gYW5kIFllaHVkYSBoYXZlIGFza2VkIHRo ZSBDRlJHIGNoYWlycyB3aGV0aGVyIHRoZWlyIGRyYWZ0IGZvcg0KPkFFUy1HQ00tU0lWIGNhbiBi ZSBhZG9wdGVkIGFzIGEgQ0ZSRyBkb2N1bWVudC4gV2UgYXJlIG1pbmRlZCB0byBkbyBzbywgYnV0 DQo+Zmlyc3Qgd2FudGVkIHRvIGNhbnZhc3MgbWVtYmVycyBvZiB0aGUgZ3JvdXAgZm9yIHRoZWly IG9waW5pb25zIG9uIHRha2luZw0KPnRoaXMgc3RlcC4NCj4NCj5XZSBhcmUgYXdhcmUgb2YgdGhl IG9uLWdvaW5nIENBRVNBUiBjb21wZXRpdGlvbiBmb3IgQUVBRCBzY2hlbWVzLg0KPkFFUy1HQ00t U0lWIGlzIG5vdCBhIENBRVNBUiBjYW5kaWRhdGUuIENGUkcgYWRvcHRpbmcgdGhpcyBkb2N1bWVu dCBzaG91bGQNCj5ub3QgYmUgaW50ZXJwcmV0ZWQgYXMgY29tcGV0aW5nIHdpdGggb3IgcHJlLWVt cHRpbmcgdGhlIHJlc3VsdHMgb2YgdGhhdA0KPnZlcnkgdmFsdWFibGUgYWN0aXZpdHkuIEluZGVl ZCwgb25jZSBDQUVTQVIgaXMgY29tcGxldGUsIHdlIGhvcGUgdGhhdCBzb21lDQo+b3IgYWxsIG9m IHRoZSBjb21wZXRpdGlvbiB3aW5uZXJzIHdpbGwgZW5kIHVwIGJlaW5nIHR1cm5lZCBpbnRvIFJG Q3MgdW5kZXINCj50aGUgYXVzcGljZXMgb2YgQ0ZSRy4NCj4NCj5SZWdhcmRzLA0KPg0KPktlbm55 IChmb3IgdGhlIGNoYWlycykNCj4NCj4NCj5PbiAwNi8wMy8yMDE2IDAzOjUwLCAiQ2ZyZyBvbiBi ZWhhbGYgb2YgU2hheSBHdWVyb24iDQo+PGNmcmctYm91bmNlc0BpcnRmLm9yZyBvbiBiZWhhbGYg b2Ygc2hheS5ndWVyb25AZ21haWwuY29tPiB3cm90ZToNCj4NCj4+SGVsbG8gQ0ZSRywNCj4+DQo+ PiANCj4+V2Ugd291bGQgbGlrZSB0byBkcmF3IHlvdXIgYXR0ZW50aW9uIHRvIG91ciBuZXcgc3Vi bWlzc2lvbiBkcmFmdCBlbnRpdGxlZA0KPj7igJxBRVMtR0NNLVNJVjogTm9uY2UgTWlzdXNlLVJl c2lzdGFudCBBdXRoZW50aWNhdGVkIEVuY3J5cHRpb27igJ0uIFBvc3RlZCBvbg0KPj5odHRwczov L3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtZ3Vlcm9uLWdjbXNpdi0wMC50eHQN Cj4+IA0KPj5UaGUgc3VibWlzc2lvbiBzcGVjaWZpZXMgdHdvIGF1dGhlbnRpY2F0ZWQgZW5jcnlw dGlvbiBhbGdvcml0aG1zIHRoYXQgYXJlDQo+Pm5vbmNlIG1pc3VzZS1yZXNpc3RhbnQuIFRoZWly IHBlcmZvcm1hbmNlIGlzIGV4cGVjdGVkIHRvIGJlIHJvdWdobHkgb24NCj4+cGFyIHdpdGggQUVT LUdDTSwNCj4+IHdoZW4gcnVuIG9uIG1vZGVybiBwcm9jZXNzb3JzIHRoYXQgaGF2ZSBBRVMgaW5z dHJ1Y3Rpb25zLg0KPj4gDQo+PlNlY3VyaXR5IGFuZCBwZXJmb3JtYW5jZSBhbmFseXNpcyBjYW4g YmUgZm91bmQgaW4gUy4gR3Vlcm9uIGFuZCBZLg0KPj5MaW5kZWxsLiBHQ00tU0lWOiBGdWxsIE5v bmNlIE1pc3VzZS1SZXNpc3RhbnQgQXV0aGVudGljYXRlZCBFbmNyeXB0aW9uIGF0DQo+PlVuZGVy IE9uZSBDeWNsZQ0KPj4gcGVyIEJ5dGUuIEluIDIybmQgQUNNIENDUywgcGFnZXMgMTA5LTExOSwg MjAxNS4NCj4+IA0KPj5XZSBob3BlIHRoYXQgdGhlIENGUkcgd2lsbCB0YWtlIHRoaXMgdXAgYXMg YSB3b3JraW5nLWdyb3VwIGl0ZW0uDQo+PiANCj4+VGhhbmsgeW91LA0KPj4NCj4+IA0KPj5TaGF5 IEd1ZXJvbiwgQWRhbSBMYW5nbGV5LCBZZWh1ZGEgTGluZGVsbA0KPj4gDQo+Pg0KPj4NCj4NCg0K From nobody Mon Apr 18 11:29:54 2016 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F14012E517 for ; Mon, 18 Apr 2016 11:29:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.197 X-Spam-Level: X-Spam-Status: No, score=-5.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.996, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1uBZFFOi0UPF for ; Mon, 18 Apr 2016 11:29:50 -0700 (PDT) Received: from limerock03.mail.cornell.edu (limerock03.mail.cornell.edu [128.84.13.243]) by ietfa.amsl.com (Postfix) with ESMTP id C06C512E50A for ; Mon, 18 Apr 2016 11:29:46 -0700 (PDT) X-CornellRouted: This message has been Routed already. Received: from exchange.cornell.edu (sf-e2013-08.exchange.cornell.edu [10.22.40.55]) by limerock03.mail.cornell.edu (8.14.4/8.14.4_cu) with ESMTP id u3IITj3b026986 for ; Mon, 18 Apr 2016 14:29:45 -0400 Received: from sf-e2013-03.exchange.cornell.edu (10.22.40.50) by sf-e2013-08.exchange.cornell.edu (10.22.40.55) with Microsoft SMTP Server (TLS) id 15.0.1130.7; Mon, 18 Apr 2016 14:29:45 -0400 Received: from mail-wm0-f72.google.com (74.125.82.72) by exchange.cornell.edu (10.22.40.50) with Microsoft SMTP Server (TLS) id 15.0.1130.7 via Frontend Transport; Mon, 18 Apr 2016 14:29:45 -0400 Received: by mail-wm0-f72.google.com with SMTP id w143so76315588wmw.2 for ; Mon, 18 Apr 2016 11:29:45 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=KxsYb2YBgqHaRbSv7Clef2bc7lM4/IJGidkVoL1bBCA=; b=clvnKECapyaA7hmL9oeHNBUl2Z56karqUwk5C+8J+mhKscokgy5yZVdtzbmrPV+blu mHpccFlrIFSSyAFMskbPUnIIxgErtRDf/3OxKLkM/B1X3pDOVd3yxKEktbG805yqdAIJ RTYGvn1uu6DwZWm9flIMRC3vMtAecglfjrT3l+mTWsGaVosfkcd0s+vyeyVZfY/v5d1h ROSqdbRRQd4xynxs0tODe28Ks2KX+SLzapPA2ffW7bECMTyPOoAxBlgQuHgfxwnIXDiR 3rU8Q+oxgCJe1Jbtobu3YD1c/8P72HeMQkejM8URHMrC7vd9X9pp+aJBQUFu2AIe/K/Y u5zA== X-Gm-Message-State: AOPr4FWkMe/NLpySqx7ie+hmbf2oSmeLd03Wi3mijgbz9sKh/hi9RwgIPkGmXf6NGq6as5bo3lFAXJfJRt1pmCcKSu7RBKRky7TgIkUPA3ZVxWRf7HBR6MHGOj4UHE+JKAyNfhmc5N2We9B1aQWsLjNj2ZE= X-Received: by 10.194.186.242 with SMTP id fn18mr40595534wjc.65.1461004122751; Mon, 18 Apr 2016 11:28:42 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.194.186.242 with SMTP id fn18mr40595518wjc.65.1461004122558; Mon, 18 Apr 2016 11:28:42 -0700 (PDT) Received: by 10.28.217.149 with HTTP; Mon, 18 Apr 2016 11:28:42 -0700 (PDT) In-Reply-To: <57148B14.7020507@azet.sk> References: <571116B0.4050204@nthpermutation.com> <57118EB7.9080907@nthpermutation.com> <57148B14.7020507@azet.sk> Date: Mon, 18 Apr 2016 14:28:42 -0400 Message-ID: From: Paul Grubbs To: Fedor Brunner Content-Type: multipart/alternative; boundary="047d7bb04deabdcec50530c687f8" Received-SPF: Neutral (sf-e2013-08.exchange.cornell.edu: 74.125.82.72 is neither permitted nor denied by domain of pag225@cornell.edu) X-ORG-HybridRouting: 7d01ca72d992f9ad6ddb93b21fb51d08 Archived-At: Cc: "cfrg@irtf.org" Subject: Re: [Cfrg] Adopting "AES-GCM-SIV: Nonce Misuse-Resistant Authenticated Encryption" as a CFRG document ---- Some clarifications X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2016 18:29:52 -0000 --047d7bb04deabdcec50530c687f8 Content-Type: text/plain; charset="UTF-8" In some settings using AES for data encryption is required by law, regulation, or best practices. I doubt the use of AES in Poly1305 would pass muster, since it's only authenticating and not encrypting. On Mon, Apr 18, 2016 at 3:21 AM, Fedor Brunner wrote: > Adam Langley: > > On Fri, Apr 15, 2016 at 6:00 PM, Michael StJohns > wrote: > >> That's not exactly what I mean/meant. In TLS, the same message (record, > >> etc) sent under the same key and IV/NONCE (as produced by the TLS > PRF/KDF > >> functions or produced randomly) will provide different ciphertext based > on > >> the fact that the record counter changes with each message. That > counter > >> doesn't necessarily have to be part of the authenticated data in an AEAD > >> cipher as the nonce formation is somewhat external to processing (with > the > >> exception of the block counter). > >> > >> To get the equivalent behavior for AES-GCM-SIV, you need to ensure > there is > >> some sort of per-message unique mixin (unique within the association > >> duration at least) that causes the tag to be different which causes the > >> nonce to be different. > > > > That's correct and, in the case of TLS, I'd suggest that the sequence > > number be used as the nonce in order to make sure that equal messages > > don't produce equal ciphertexts. Although, to be clear, I'm not > > suggesting that AES-GCM-SIV be used in TLS or in any situation where a > > counter nonce is easy. Transport security is generally a situation > > where a single sender can just use a counter and, in those cases, > > AES-GCM is better. > > > > But there are situations where nonce management is a problem (i.e. > > where there are multiple machines encrypting with a single key) and, > > for that, I think AES-GCM-SIV is pretty attractive because one can > > reasonably use a random nonce. > > https://cr.yp.to/papers.html#xsalsa > > XSalsa20 is Salsa20 cipher with nonce extended to 192 bits. So there is > no need to manage nonces, they can be generated with RNG. Could you > please describe applications where you would prefer AES-GCM-SIV over > XSalsa20+Poly1305 > > > > > > > Cheers > > > > AGL > > > > _______________________________________________ > > Cfrg mailing list > > Cfrg@irtf.org > > https://www.irtf.org/mailman/listinfo/cfrg > > > > > > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > https://www.irtf.org/mailman/listinfo/cfrg > --047d7bb04deabdcec50530c687f8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
In some settings using AES for data encryption is required= by law, regulation, or best practices. I doubt the use of AES in Poly1305 = would pass muster, since it's only authenticating and not encrypting.= =C2=A0

On Mo= n, Apr 18, 2016 at 3:21 AM, Fedor Brunner <fedor.brunner@azet.sk&g= t; wrote:
Adam Langley:
> On Fri, Apr 15, 2016 at 6:00 PM, Michael StJohns <= msj@nthpermutation.com> wr= ote:
>> That's not exactly what I mean/meant.=C2=A0 In TLS, the same m= essage (record,
>> etc) sent under the same key and IV/NONCE (as produced by the TLS = PRF/KDF
>> functions or produced randomly) will provide different ciphertext = based on
>> the fact that the record counter changes with each message.=C2=A0 = That counter
>> doesn't necessarily have to be part of the authenticated data = in an AEAD
>> cipher as the nonce formation is somewhat external to processing (= with the
>> exception of the block counter).
>>
>> To get the equivalent behavior for AES-GCM-SIV, you need to ensure= there is
>> some sort of per-message unique mixin (unique within the associati= on
>> duration at least) that causes the tag to be different which cause= s the
>> nonce to be different.
>
> That's correct and, in the case of TLS, I'd suggest that the s= equence
> number be used as the nonce in order to make sure that equal messages<= br> > don't produce equal ciphertexts. Although, to be clear, I'm no= t
> suggesting that AES-GCM-SIV be used in TLS or in any situation where a=
> counter nonce is easy. Transport security is generally a situation
> where a single sender can just use a counter and, in those cases,
> AES-GCM is better.
>
> But there are situations where nonce management is a problem (i.e.
> where there are multiple machines encrypting with a single key) and, > for that, I think AES-GCM-SIV is pretty attractive because one can
> reasonably use a random nonce.

https://cr.yp.to/papers.html#xsalsa

XSalsa20 is Salsa20 cipher with nonce extended to 192 bits. So there is
no need to manage nonces, they can be generated with RNG. Could you
please describe applications where you would prefer AES-GCM-SIV over
XSalsa20+Poly1305

>
>
> Cheers
>
> AGL
>
> _______________________________________________
> Cfrg mailing list
> Cfrg@irtf.org
> https://www.irtf.org/mailman/listinfo/cfrg
>
>

_______________________________________________
Cfrg mailing list
Cfrg@irtf.org
https://www.irtf.org/mailman/listinfo/cfrg

--047d7bb04deabdcec50530c687f8-- From nobody Mon Apr 18 22:44:44 2016 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF47412DB22 for ; Mon, 18 Apr 2016 22:44:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7cv2qzA5FtJi for ; Mon, 18 Apr 2016 22:44:41 -0700 (PDT) Received: from mail-vk0-x232.google.com (mail-vk0-x232.google.com [IPv6:2607:f8b0:400c:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1048F12D88F for ; Mon, 18 Apr 2016 22:44:41 -0700 (PDT) Received: by mail-vk0-x232.google.com with SMTP id t129so6920167vkg.2 for ; Mon, 18 Apr 2016 22:44:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=J46ImOvFjrFcAATt8ktWV7F6KYmGHuwThqwyxbclDiE=; b=fZ6IVlFsp6nXBaMtEqUBc7J00SP9vg1jpZ/PtWLb5jD7c49oLS5wEC4aUFxIoWQSTz GRAJzluqfC3MuFIP6QkojtPtDL7qVVvIFI3zAO0jMCB7nV1F3N76mYEXtdblY4ZHrU1v TKB50tCxl3W0tq0t66v0fnCpYzgNw9aGMWY5KXOhrIfuwu5dWYvUhNhmonCvQUTQGjet O/m7iSYWY/BONSGn+JSgFLKmOA/HsAZMihSZYr0Lf2OFBtkqt7V0on0ETl1ajCRp/imJ 9gesbi7vQpE88Pg+rAaqJ+wOTF7C34BPo4Wrs61xNSSGxagJwWjbGKx6+/RrK/Ab9OY2 4pyA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=J46ImOvFjrFcAATt8ktWV7F6KYmGHuwThqwyxbclDiE=; b=iOFRAb9vXULuN/aesoIh3ILW7ExFpeM6a6yLhPG0HLjDTf1KW8/D9RlF6tRdmOrg1a GiTMvu+yDqyfXXAVTtkXEoX0n+6YCDPGisKtJy4w6dlA+lEd+U4zTiOMzd2t5w2nRdul /otxxSjE5kXY/WfV+m6Win3pVBX8Pc4Y8z2wjSeVozfZ5NuH1Y/99uIGGfEZSFeIEa+k EmVdQxdaeXmGkRNVFGL7vNJe7w1FBo+1+NROlpuBzMIXCdAfIouh5V9Ljt0iw3P+S+mF kVJMsuKRu58e42VH9rQ6dwUdE5mjp4l5kK0A3ClvtiYyB/dNO76VMpDs072LVTB/En1m 9nkQ== X-Gm-Message-State: AOPr4FUvTeV27i/80y+mISsMexAwbDxOD1kRiqy2KfBmhzz1q3JTMsmPX+utVEGyCuVSAF6rd9+fR5j5D9rcVQ== MIME-Version: 1.0 X-Received: by 10.176.7.98 with SMTP id h89mr572389uah.55.1461044680131; Mon, 18 Apr 2016 22:44:40 -0700 (PDT) Received: by 10.31.107.5 with HTTP; Mon, 18 Apr 2016 22:44:40 -0700 (PDT) In-Reply-To: References: <38634A9C401D714A92BB13BBA9CCD34F167B5300@mail-essen-01.secunet.de> <38634A9C401D714A92BB13BBA9CCD34F167B8267@mail-essen-01.secunet.de> Date: Tue, 19 Apr 2016 08:44:40 +0300 Message-ID: From: "Stanislav V. Smyshlyaev" To: =?UTF-8?Q?Schmidt=2C_J=C3=B6rn=2DMarc?= Content-Type: multipart/alternative; boundary=94eb2c1232242913000530cff970 Archived-At: Cc: "cfrg@irtf.org" Subject: Re: [Cfrg] The SESPAKE protocol and PAKE requirements X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2016 05:44:43 -0000 --94eb2c1232242913000530cff970 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Dear J=C3=B6rn, Thank you for an updated version of the draft =E2=80=93 we'll revise it one= more time in a week (a week prior to the deadline marked by Alexey yesterday). Now I'd like only to mention a small misprint: "Cryptograpic" in reference [P1363]. Thank you for your work on the draft. Kindest regards, Stanislav 2016-02-25 8:39 GMT+03:00 Stanislav V. Smyshlyaev : > Dear J=C3=B6rn, > Thank you very much for your comments! SESPAKE will of course work with > any underlying hash/HMAC/elliptic curve/PBKDF and we=E2=80=99ll prepare a= new > version of our draft which will explicitly stress it. > I do not insist on addition of any specific words about primitives > specification in the requirements draft. In contrary to the question with > counters handling (our previous discussion), I think it is ok if this iss= ue > will be addressed by any author of a draft at his own discretion. > > Kindest regards, > Stanislav > > > 2016-02-23 9:52 GMT+03:00 Schmidt, J=C3=B6rn-Marc < > Joern-Marc.Schmidt@secunet.com>: > >> Dear Stanislav, >> >> Thank you for your input! >> >> >What do you think about defining a policy of algorithm usage in PAKE >> protocols? >> >For example, in the current version of SESPAKE RFC draft we are based o= n >> Russian standards =E2=80=93 GOST R 34.11-2012 hash and HMAC, but of cour= se the >> >document that refers only to GOSTs cannot become a CFRG document. >> >> >Shouldn't we require multi-algorithm support =E2=80=93 as in the PAKE >> requirements, as in our SESPAKE? >> >> You mean to add a requirement to state which algorithms can be used as >> underlying primitives? >> I haven't analyzed SESPAKE in detail - but wouldn't it work with any >> cryptographic hash function? >> In case a PAKE requires a special property of the underlying hash >> function/cipher/etc., I think this could be covered with >> "R2: A PAKE scheme SHOULD come with a security proof and clearly state >> its assumptions and models." by adding a sentence about useful primitive= s. >> >> I personally would leave it up to the designer of the PAKE scheme to >> decide whether the scheme mentions a specific primitive (e.g. is specifi= ed >> using AES & SHA2) or leaves it up to the implementer (e.g. speaking of >> block cipher & hash function in an abstract manner). Do you think we sho= uld >> push in one direction in the requirements draft? >> >> Best regards, >> >> J=C3=B6rn >> >> >> >> > --94eb2c1232242913000530cff970 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Dear J=C3=B6rn,
Thank you for an updated version of the= draft =E2=80=93 we'll revise it one more time in a week (a week prior = to the deadline marked by Alexey yesterday).

Now I'd like only t= o mention a small misprint: "Cryptograpic" in reference [P1363].<= br>
Thank you for your work on the draft.

Kindest regards,
Stanislav


2016-02-25 8:39 GMT+03:00 Stanislav V. Smysh= lyaev <smyshsv@gmail.com>:
Dear J= =C3=B6rn,
Thank you very much for your comments! SESPAKE will of = course work with any underlying hash/HMAC/elliptic curve/PBKDF and we=E2=80= =99ll prepare a new version of our draft which will explicitly stress it.
I do not insist on addition of any specific words about primitives= specification in the requirements draft. In contrary to the question with = counters handling (our previous discussion), I think it is ok if this issue= will be addressed by any author of a draft at his own discretion.

Kindest regards,
Stanislav

<= /div>

2016-02-23 9:52 GMT+03:00 Schmidt, J=C3=B6rn= -Marc <Joern-Marc.Schmidt@secunet.com>:
Dear Stanislav,

Thank you for your input!

>What do you think about defining a policy of algorithm usage in PAKE pr= otocols?
>For example, in the current version of SESPAKE RFC draft we are based o= n Russian standards =E2=80=93 GOST R 34.11-2012 hash and HMAC, but of cours= e the >document that refers only to GOSTs cannot become a CFRG document.=

>Shouldn't we require multi-algorithm support =E2=80=93 as in the PA= KE requirements, as in our SESPAKE?

You mean to add a requirement to state which algorithms can be used = as underlying primitives?
I haven't analyzed SESPAKE in detail - but wouldn't it work with an= y cryptographic hash function?
In case a PAKE requires a special property of the underlying hash function/= cipher/etc., I think this could be covered with
"R2: A PAKE scheme SHOULD come with a security proof and clearly state= its assumptions and models." by adding a sentence about useful primit= ives.

I personally would leave it up to the designer of the PAKE scheme to decide= whether the scheme mentions a specific primitive (e.g. is specified using = AES & SHA2) or leaves it up to the implementer (e.g. speaking of block = cipher & hash function in an abstract manner). Do you think we should p= ush in one direction in the requirements draft?

Best regards,

J=C3=B6rn





--94eb2c1232242913000530cff970-- From nobody Tue Apr 19 07:41:58 2016 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24E0912DE93 for ; Tue, 19 Apr 2016 07:41:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.4 X-Spam-Level: X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UWn2f7Q823eh for ; Tue, 19 Apr 2016 07:41:54 -0700 (PDT) Received: from mail-ig0-x242.google.com (mail-ig0-x242.google.com [IPv6:2607:f8b0:4001:c05::242]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C631912DDDB for ; Tue, 19 Apr 2016 07:41:54 -0700 (PDT) Received: by mail-ig0-x242.google.com with SMTP id kb1so2615319igb.3 for ; Tue, 19 Apr 2016 07:41:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc; bh=6gfdkoO+VlWgSzU8AJ5c8RMIDs/w7pxTqItrXx/YwUY=; b=SdscVS1n3eLoFtdxjK2aMFNyd5LhI2nWZoyhEJ0P9ud8o4JlagYmUsbl2IFOT1HXjn DxYJrSmd2HTwZZF9NOHvAAdNx0sXQ2WWnSYzm33N/hHVwENUJCNc9xKTgFXmsmyk00rR Doujn/MVa2cyoGmLWeI+3wp/SP9mvhyaPA6A9HesseB8EyrriB9QvWSdBaPbN88x/L03 KCtATimR0PyaVY834tfhN2hRqdkpQYpuKcN2XgtuP4T+nyjfxb7aEiqf6pLBnZQe+1Ft 85zVfhhQc8QZER6auNgv/2zCOGAUKF5mtUj+uN0j6cXq8Dlfn5nMRSrPS/rJa2RVrf4P Qo0g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=6gfdkoO+VlWgSzU8AJ5c8RMIDs/w7pxTqItrXx/YwUY=; b=bf4YR0zqkztpihXnXZuXHc5mHfuUgBi0+TnIkhEqozbpt5e0+vKnovS4/w0bKPEdah OApBKUAhgk/awXve6YleZDQzrJhwN8YbOs6YkAbldgVZjyxZiKGl+8UAonNVNYdyG8Wo N3e+sJ0OQsbmidQOu1GwtMbKxvSMMpI+8ieZv6HDTXTCpbfEvK4hR9qsi9Pdc5BxcavC qr+FyOPk3UsIklZ15H8KQrgPiAGmepBU7RbvmmNMnhgMLajq8i6bXTw8L6XFo6EymQpZ xQSqxPHkORADYoZrS+nlDo1JXvI4Cjkx9lyv/cTq2IC7LtGJac1O8GZ6R0U9lw2hpukq ASFw== X-Gm-Message-State: AOPr4FXEXng0hgCe5cYg0MVI2SGdGolt5xfmOeW7I3AVMbpZjnciMrcrT+w7d/fcLXxCY8aIkm6QAd6seWA5pw== MIME-Version: 1.0 X-Received: by 10.50.144.163 with SMTP id sn3mr26017601igb.26.1461076913997; Tue, 19 Apr 2016 07:41:53 -0700 (PDT) Sender: alangley@gmail.com Received: by 10.79.117.133 with HTTP; Tue, 19 Apr 2016 07:41:53 -0700 (PDT) In-Reply-To: <57148B14.7020507@azet.sk> References: <571116B0.4050204@nthpermutation.com> <57118EB7.9080907@nthpermutation.com> <57148B14.7020507@azet.sk> Date: Tue, 19 Apr 2016 07:41:53 -0700 X-Google-Sender-Auth: JmmEoZQPHw03yaNGzoNKf6NRo90 Message-ID: From: Adam Langley To: Fedor Brunner Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "cfrg@irtf.org" Subject: Re: [Cfrg] Adopting "AES-GCM-SIV: Nonce Misuse-Resistant Authenticated Encryption" as a CFRG document ---- Some clarifications X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2016 14:41:57 -0000 On Mon, Apr 18, 2016 at 12:21 AM, Fedor Brunner wrote: > XSalsa20 is Salsa20 cipher with nonce extended to 192 bits. So there is > no need to manage nonces, they can be generated with RNG. Could you > please describe applications where you would prefer AES-GCM-SIV over > XSalsa20+Poly1305 Basically the increasing levels of hardware support for AES-GCM make it compelling from a performance point of view. (Storing the extra twelve bytes of nonce /might/ be a concern in some cases but I'm not sure about that.) Cheers AGL -- Adam Langley agl@imperialviolet.org https://www.imperialviolet.org From nobody Tue Apr 19 10:20:16 2016 Return-Path: X-Original-To: cfrg@ietf.org Delivered-To: cfrg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 32A1B12E33C; Tue, 19 Apr 2016 10:20:12 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.19.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160419172012.31593.81597.idtracker@ietfa.amsl.com> Date: Tue, 19 Apr 2016 10:20:12 -0700 Archived-At: Cc: cfrg@ietf.org Subject: [Cfrg] I-D Action: draft-irtf-cfrg-gcmsiv-00.txt X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.17 List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2016 17:20:12 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Crypto Forum of the IETF. Title : AES-GCM-SIV: Nonce Misuse-Resistant Authenticated Encryption Authors : Shay Gueron Adam Langley Yehuda Lindell Filename : draft-irtf-cfrg-gcmsiv-00.txt Pages : 89 Date : 2016-04-19 Abstract: This memo specifies two authenticated encryption algorithms that are nonce misuse-resistant - that is that they do not fail catastrophically if a nonce is repeated. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-irtf-cfrg-gcmsiv/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-irtf-cfrg-gcmsiv-00 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/ From nobody Tue Apr 19 17:41:09 2016 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5408312E882 for ; Tue, 19 Apr 2016 17:41:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id llmegwrVZPoT for ; Tue, 19 Apr 2016 17:41:06 -0700 (PDT) Received: from mx0a-0016f401.pphosted.com (mx0a-0016f401.pphosted.com [67.231.148.174]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5DFDC12E87D for ; Tue, 19 Apr 2016 17:41:05 -0700 (PDT) Received: from pps.filterd (m0045849.ppops.net [127.0.0.1]) by mx0a-0016f401.pphosted.com (8.16.0.11/8.16.0.11) with SMTP id u3K0bVMN002611; Tue, 19 Apr 2016 17:40:56 -0700 Received: from sc-exch04.marvell.com ([199.233.58.184]) by mx0a-0016f401.pphosted.com with ESMTP id 22bjrka87j-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 19 Apr 2016 17:40:55 -0700 Received: from SC-EXCH03.marvell.com (10.93.176.83) by SC-EXCH04.marvell.com (10.93.176.84) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 19 Apr 2016 17:40:54 -0700 Received: from SC-EXCH03.marvell.com ([fe80::6cb0:4dfa:f3f3:b8b6]) by SC-EXCH03.marvell.com ([fe80::6cb0:4dfa:f3f3:b8b6%21]) with mapi id 15.00.1104.000; Tue, 19 Apr 2016 17:40:54 -0700 From: Paul Lambert To: Adam Langley , Fedor Brunner Thread-Topic: [Cfrg] Adopting "AES-GCM-SIV: Nonce Misuse-Resistant Authenticated Encryption" as a CFRG document ---- Some clarifications Thread-Index: AQHRjz0eCl+0tbAEE0qYWZc1FNrwpZ9/ncuAgAAK8oCACtLdAIABN6yAgAAFG4CAAAYwAIAADJ8AgACCd4CAAqWBAIAA6bAAgAINQICAADIDgA== Date: Wed, 20 Apr 2016 00:40:54 +0000 Message-ID: References: <571116B0.4050204@nthpermutation.com> <57118EB7.9080907@nthpermutation.com> <57148B14.7020507@azet.sk> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.3.160329 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.94.250.30] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-04-20_01:, , signatures=0 X-Proofpoint-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1603290000 definitions=main-1604200008 Archived-At: Cc: "cfrg@irtf.org" Subject: Re: [Cfrg] Adopting "AES-GCM-SIV: Nonce Misuse-Resistant Authenticated Encryption" as a CFRG document ---- Some clarifications X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2016 00:41:08 -0000 >On Mon, Apr 18, 2016 at 12:21 AM, Fedor Brunner >wrote: >> XSalsa20 is Salsa20 cipher with nonce extended to 192 bits. So there is >> no need to manage nonces, they can be generated with RNG. Could you >> please describe applications where you would prefer AES-GCM-SIV over >> XSalsa20+Poly1305 > >Basically the increasing levels of hardware support for AES-GCM make >it compelling from a performance point of view. Yes =8A GCM is becoming the preferred hardware encryption algorithm for it= =B9s performance. GCM is being designed into most layer 2 encryption protocols and the associated hardware. Encryption hardware is a significant investment in a chip and given the dominance of AES it is unlikely that an additional cipher (like Salsa20) will be added broadly to hardware for a very long time. =20 > >(Storing the extra twelve bytes of nonce /might/ be a concern in some >cases but I'm not sure about that.) Yes - that will be an issue for many existing designs. It=B9s still a much smaller change for a design that moving to Salsa or any other new cipher. Nonce misuse-resistance is quite valuable in ad-hoc multicast environments. It will be interesting to see how AES-GCM-SIV maps into the formats of a multicast encryption protocols (like ad-hoc encrypted multicast in 802.11). This nonce resistance is a mode I=B9ve been hoping would get support for many years for ad-hoc multicast environments. In particular, it solves the n^2 key setup problems of 802.11 IBSS. Paul > > >Cheers > >AGL > >--=20 >Adam Langley agl@imperialviolet.org https://www.imperialviolet.org > >_______________________________________________ >Cfrg mailing list >Cfrg@irtf.org >https://www.irtf.org/mailman/listinfo/cfrg From nobody Tue Apr 19 19:13:40 2016 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE7A212EA06 for ; Tue, 19 Apr 2016 19:13:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.896 X-Spam-Level: X-Spam-Status: No, score=-2.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.996] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XR1MdzbLWmBQ for ; Tue, 19 Apr 2016 19:13:38 -0700 (PDT) Received: from jupiter.mumble.net (jupiter.mumble.net [74.50.56.165]) by ietfa.amsl.com (Postfix) with ESMTP id 180D312EA08 for ; Tue, 19 Apr 2016 19:13:37 -0700 (PDT) Received: by jupiter.mumble.net (Postfix, from userid 1014) id 5285C6031B; Wed, 20 Apr 2016 02:12:08 +0000 (UTC) From: Taylor R Campbell To: Fedor Brunner In-reply-to: <57148B14.7020507@azet.sk> (fedor.brunner@azet.sk) Date: Wed, 20 Apr 2016 02:13:36 +0000 Sender: Taylor R Campbell User-Agent: IMAIL/1.21; Edwin/3.116; MIT-Scheme/9.1.99 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20160420021208.5285C6031B@jupiter.mumble.net> Archived-At: Cc: cfrg@irtf.org Subject: Re: [Cfrg] Adopting "AES-GCM-SIV: Nonce Misuse-Resistant Authenticated Encryption" as a CFRG document ---- Some clarifications X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2016 02:13:39 -0000 Date: Mon, 18 Apr 2016 09:21:56 +0200 From: Fedor Brunner Adam Langley: > But there are situations where nonce management is a problem (i.e. > where there are multiple machines encrypting with a single key) and, > for that, I think AES-GCM-SIV is pretty attractive because one can > reasonably use a random nonce. https://cr.yp.to/papers.html#xsalsa XSalsa20 is Salsa20 cipher with nonce extended to 192 bits. So there is no need to manage nonces, they can be generated with RNG. Could you please describe applications where you would prefer AES-GCM-SIV over XSalsa20+Poly1305 For NaCl crypto_secretbox_xsalsa20poly1305, nonce reuse -- e.g., due to a buggy random number generator -- is catastrophic: an eavesdropper learns the xor of two unknown-plaintext messages, or the content of one unknown-plaintext message given one known-plaintext message, and can forge arbitrarily many future messages. For AES-GCM-SIV, nonce reuse enables the attacker to distinguish duplicate messages from distinct messages, but is not otherwise harmful. Resistance to nonce reuse for AEAD is part of why there is an entire AES-style crypto competition dedicated to AEAD schemes, CAESAR . AES-GCM-SIV was not submitted because it was put together too recently. The creators of AES-GCM-SIV and chairs of the CFRG evidently decided that it would be better to sidestep the competition and endorse crypto that is, lacking hardware support, either unusably slow or vulnerable to timing side channels, recommending it for general-purpose use on the internet. It's easy to say `all the hardware now supports it'. It's much harder to audit all the applications you're using to confirm that they actually take advantage of the hardware support across umpteen layers of software abstractions and do not render your keys vulnerable to extraction by someone over the internet with a watch. From nobody Tue Apr 19 23:27:35 2016 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E39B12D5FD; Tue, 19 Apr 2016 23:27:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KVFRTG5kkcv6; Tue, 19 Apr 2016 23:27:32 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [162.247.75.118]) by ietfa.amsl.com (Postfix) with ESMTP id D7F4812D908; Tue, 19 Apr 2016 23:27:28 -0700 (PDT) Received: from fifthhorseman.net (ool-6c3a0662.static.optonline.net [108.58.6.98]) by che.mayfirst.org (Postfix) with ESMTPSA id 7CFF6F991; Wed, 20 Apr 2016 02:27:26 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id 2B43B20051; Wed, 20 Apr 2016 02:27:26 -0400 (EDT) From: Daniel Kahn Gillmor To: cfrg@ietf.org, draft-irtf-cfrg-eddsa.all@ietf.org User-Agent: Notmuch/0.21+128~g620f892 (http://notmuchmail.org) Emacs/24.5.1 (x86_64-pc-linux-gnu) Date: Wed, 20 Apr 2016 02:27:22 -0400 Message-ID: <87bn543id1.fsf@alice.fifthhorseman.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Archived-At: Cc: =?utf-8?B?T25kxZllaiBTdXLDvQ==?= , Robert Edmonds , Benjamin Kaduk , Martin Thomson Subject: [Cfrg] draft-irtf-cfrg-eddsa -- one final proposal for domain separation (context labels) for ed25519 X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2016 06:27:34 -0000 --=-=-= Content-Type: text/plain Hi all-- in draft-irtf-cfrg-eddsa-05, there is a context label defined for ed448, but no such label is defined for ed25519. (the "context label" is a way to provide domain separation between signatures made in different contexts, avoiding cross-protocol attacks) people seem OK with domain separation for ed448, but we've rejected it for ed25519 to achieve backward compatibility with existing signatures, and to avoid API changes to existing ed25519 libraries, as discussed in threads like [0]. I wanted to float one final middle-ground proposal that would allow us to align the APIs between the two by adding an optional context parameter to ed25519/ed25519ph. If this isn't acceptable, please consider instead the proposed additional Security Considerations toward the end of this message. The proposal for including optional context labels in 25519 is simple: * in Table 1: Parameters of Ed25519, change H(x) from "SHA-512(x)" to "SHA-512(context || x)", and change PH(x) to "context || x". * change the sentence describing the ph variant that follows the table to: Ed25519ph is the same but with PH being SHA-512(context || x) instead, i.e., the input is hashed using SHA-512 before signing with Ed25519. If "context" is unspecified by the user it is treated as the empty string and, the result is exactly the same as the current description. This is also easy for someone to implement with existing ed25519 libraries with no API change: just concatenate before signing or verifying. This would mean that a signature with a context label for 25519 is not separated from a signature *without* a context label (a weaker domain separation than we're offering in ed448), but it at least provides a standard way for protocols that want to make domain-separated signatures to do so, which might help us to encourage domain separation in standards which contemplate the use of either Ed448 or Ed25519 (their abstract APIs are alignable). I also think we need some text explaining the difference between the two approaches. If we adopt the above proposal, we could add something like this to the Security Considerations or section 10.3 ("Use of contexts"): ---------- Note that the domain separation for Ed25519 and Ed25519ph is weaker than the domain separation for Ed448 and Ed448ph in two ways: (a) Signatures that do not use context labels can potentially collide with signatures that use context labels. This can only be mitigated by never using the same key in multiple domains without having a domain-specific context label for each use. (b) Signature domains that use context labels where one context label is a prefix of the other may also have collisions. This can be mitigated by always choosing a context labels that consist of printable ASCII characters followed by a single zero-valued octet. This weaker domain separation is accepted in Ed25519 due to widespread existing context-free deployment and the desire to avoid breaking backward compatibility. For Ed448, which is not yet as widely deployed, the dom() function's stronger domain separation guarantees are preferred. ---------- If we do not adopt the above changes, and leave ed25519 and ed25519ph without any attempt at domain separation, we also probably need a bit of text explaining why one primitive has domain separation and the other does not, probably in either Security Considerations or section 10.3. Otherwise, future people reading the draft would need to track down messages like those in [0] to understand the asymmetry. A proposal for text in this scenario: ----------- Note that only Ed448 offers strong domain separation via context labels, while Ed25519 lacks this capability. This is due to a desire to retain backward compatibility with existing Ed25519 deployments, and to leave the Ed25519 API as simple as possible. If an application or protocol needs domain separation in situations where Ed25519 may be used, a weaker form of domain separation may be had by prepending a context label (fixed octet string) to the message before signing or verifying, using a different context label for each signature domain. For the prehash variant, prepend the context to the message before pre-hashing. To avoid collisions between domains when using this weaker form of domain separation, context labels should consist of only printable ASCII characters followed by a single-valued octet. ----------- What do folks think? --dkg [0] see for example Ilari's response here to Bryan Ford at Message-Id: 20151211202214.GA5522@LK-Perkele-V2.elisa-laajakaista.fi https://www.ietf.org/mail-archive/web/cfrg/current/msg07713.html and the "On the differences of Ed25519/448 and how it affects a vote on twoshakes-d" thread starting at Message-Id: CAA4PzX18bcS_awPg-YDAoo90537Ot=s_nf7k_Vt75OVSdvtDrQ@mail.gmail.com https://www.ietf.org/mail-archive/web/cfrg/current/msg07665.html --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQJ8BAEBCgBmBQJXFyFKXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFREIyRTc0RjU2RkNGMkI2NzI5N0I3MzUy NEVDRkY1QUZGNjgzNzBBAAoJECTs/1r/aDcK/EYP/3rOemLK3EAH+81asyRZoCCc UD6jpAacoWINjQJk//Y7csegWyeismtbaQ5b8oFr+CLZ0YQCv6vJjn/L//PAlWf7 omL5vWqkpluwZ6+0Y5x1zihuty5J5s1TWmxpdwbT8xm1j77XQ0MRS3NuJjV+gpS9 hynCOSU8YNlMJBoBQVvNSubknbFkEchAdKbGskXIW2BvD/YKH/Nix7fjcaOymWAZ xtZAHfKdrb7g7IUQxCCf2a0OCepOJBRaOF5c5OrOrZu2I/X400Gz8DAoINefxmDG 5RKITWhTvvhvBECaE3dmR1jwHQgM5xEM9WokpkWduAzCnGe9ZQDBeMJlCy/WrWyq Y44jDE81c8k4r0+/Ggoq0hZ0H3jTbaW+0bQpgn5fo4FB53F0K4pnXthvIH3FaqBz k89cmAS7QAMnRowPs+JDYLUXGqB4oBEtQtiNeP+gUG40T+AYwaAhioxdD3m4cnD3 Ogdsr4vk7pAaE9TPi/WWj1T5q5+UeF3rbJ+VwAde5h4IGcEBIA5I458uaVmUHW1M uCcvdmKERDGTRofhtYu/G8l/4vwj7mD1Egn8orHU3/Wpe/jVHVn2d4jX9CWYSsXt YLYWsTwd5lhq1iuABKqZdeA+2aSD7OLHzUYdId+VK/qNzCNPOnSun0Hy8/a5yXH0 wFzpKDrOIWxafxZrl30F =rDWD -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Apr 20 00:18:54 2016 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FD2F12EC59 for ; Wed, 20 Apr 2016 00:18:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.788 X-Spam-Level: X-Spam-Status: No, score=-2.788 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-0.996, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (bad RSA signature)" header.d=azet.sk Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R9oiXcXIgGPR for ; Wed, 20 Apr 2016 00:18:50 -0700 (PDT) Received: from smtp2.azet.sk (smtp-07-out.s.azet.sk [91.235.53.32]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B1FF512DA62 for ; Wed, 20 Apr 2016 00:18:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=azet.sk; s=azet; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:From:Cc:References:To:Subject; bh=BrYv+dKWn02ERoZ8o6Ig+glHwVQabko3Pl8cb1PAmV4=; b=YlOPXPTEV4HD7pcAsfTTVKNA4zmpSkBkUTf0vMkXgy+HVKyBy1N5llYC4xgVanQcY26VzlVq4kBSuv/sPsiVqcTu7tTwVyA3irC4L5/FfZxJyApcKU6OYzklrhh6huMfazzobRlxgHPdRDpoPc+2u8kvbspOYe43jYusFMFeenk=; Received: from smtp-01-auth.e.etech.sk ([10.11.2.100] helo=smtp.azet.sk) by smtp2.azet.sk stage1 with esmtp (Exim MailCleaner) id 1asmPP-0003QX-Ik from ; Wed, 20 Apr 2016 09:18:47 +0200 Received: from 127.0.0.1 (unknown [146.0.43.126]) (Authenticated sender: fedor.brunner@azet.sk) by smtp.azet.sk (Postfix) with ESMTPA id 552D387; Wed, 20 Apr 2016 09:18:31 +0200 (CEST) X-SenderID: Sendmail Sender-ID Filter v1.0.0 smtp.azet.sk 552D387 Authentication-Results: smtp.azet.sk; sender-id=fail (NotPermitted) header.from=fedor.brunner@azet.sk; auth=pass (PLAIN); spf=fail (NotPermitted) smtp.mfrom=fedor.brunner@azet.sk To: Taylor R Campbell References: <20160420021208.5285C6031B@jupiter.mumble.net> From: Fedor Brunner X-Enigmail-Draft-Status: N1110 Message-ID: <57172D46.5060505@azet.sk> Date: Wed, 20 Apr 2016 09:18:30 +0200 MIME-Version: 1.0 In-Reply-To: <20160420021208.5285C6031B@jupiter.mumble.net> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-MailCleaner-DMARC: quarantine Archived-At: Cc: cfrg@irtf.org Subject: Re: [Cfrg] Adopting "AES-GCM-SIV: Nonce Misuse-Resistant Authenticated Encryption" as a CFRG document ---- Some clarifications X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2016 07:18:53 -0000 Taylor R Campbell: > Date: Mon, 18 Apr 2016 09:21:56 +0200 > From: Fedor Brunner > > Adam Langley: > > But there are situations where nonce management is a problem (i.e. > > where there are multiple machines encrypting with a single key) and, > > for that, I think AES-GCM-SIV is pretty attractive because one can > > reasonably use a random nonce. > > https://cr.yp.to/papers.html#xsalsa > > XSalsa20 is Salsa20 cipher with nonce extended to 192 bits. So there is > no need to manage nonces, they can be generated with RNG. Could you > please describe applications where you would prefer AES-GCM-SIV over > XSalsa20+Poly1305 > > For NaCl crypto_secretbox_xsalsa20poly1305, nonce reuse -- e.g., due > to a buggy random number generator -- is catastrophic: an eavesdropper > learns the xor of two unknown-plaintext messages, or the content of > one unknown-plaintext message given one known-plaintext message, and > can forge arbitrarily many future messages. For most application you want to have forward secrecy. To have forward secrecy you need to generate ephemeral keys using working random number generator. So most applications already require correctly working RNG. > > For AES-GCM-SIV, nonce reuse enables the attacker to distinguish > duplicate messages from distinct messages, but is not otherwise > harmful. > > Resistance to nonce reuse for AEAD is part of why there is an entire > AES-style crypto competition dedicated to AEAD schemes, CAESAR > . AES-GCM-SIV was not > submitted because it was put together too recently. > > The creators of AES-GCM-SIV and chairs of the CFRG evidently decided > that it would be better to sidestep the competition and endorse crypto > that is, lacking hardware support, either unusably slow or vulnerable > to timing side channels, recommending it for general-purpose use on > the internet. I think a note about side channels should be added to Section 9 Security Considerations. > > It's easy to say `all the hardware now supports it'. It's much harder > to audit all the applications you're using to confirm that they > actually take advantage of the hardware support across umpteen layers > of software abstractions and do not render your keys vulnerable to > extraction by someone over the internet with a watch. > > From nobody Wed Apr 20 00:37:26 2016 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B5F312EC82 for ; Wed, 20 Apr 2016 00:37:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LrZIDLM3q5eN for ; Wed, 20 Apr 2016 00:37:24 -0700 (PDT) Received: from mail-wm0-x22e.google.com (mail-wm0-x22e.google.com [IPv6:2a00:1450:400c:c09::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 04E7212EC7E for ; Wed, 20 Apr 2016 00:37:23 -0700 (PDT) Received: by mail-wm0-x22e.google.com with SMTP id e201so39666640wme.0 for ; Wed, 20 Apr 2016 00:37:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=U8V4JFD0mJH5vznIBLXpnCWlsZikNzTXIG1duTFENko=; b=Fak+C3CniQbq1DmQA7w4hG+hfeTxuyaiYz8Ydn0OmmKceTPIockpuEn4yBe5zNM8dU Mq8h330JroyGB/LuPge+9gBBQu9FRL0Wv9L0Vr5H0w6xtNZyxrDAXk2wjDCHFzBxxkgI 1w3zUk1OgTq8McZmV9xqKz9pjOIuiTFfNgxhzYmsYhTkxiz0N6Lcy9B0sNIhUY7RR3Md D7KAnSo6BTRHxo8g99BkrzGKM+4qx12l/dK6n6XpN/0o6mCqHZ7cgEHL93A0AN+CzXpL kUIHDJcBzDzwQjMHy8jYwVUA0TYbtoSco9iU1i7ayGCvT2MNJm7wpzzOPnaQWEb/51mX Or+Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=U8V4JFD0mJH5vznIBLXpnCWlsZikNzTXIG1duTFENko=; b=lpa4KJwzqJW4K4DuvETPnESqzPaIy9q8qvFdgrm8CLIuEUaFVnCPD5a6GOkiDlRxTE TCKOzjpTvtzITKWD+Man2ryXV3ZmMH6lixuK/Bb02Za8FCpualQ2Aw5SqygBKtr0Evs6 TE9Z4dCfqJCUbAog7i4jZG08wZXyauxQKkLCe/pOOeKuVd8/lqEUlZbFpAffwBAyXl4/ YnE6/gC59wVydKFOC3dRlEOdA+nIX60Ya47XQbJudtd+SxDy3dme4N3YwA4jFttzqvTg aXXrnonX5QQDzZP2qtJJ1Zncu00aFUlIo6CxBqQ5t6oO9ADDKtZjmkCMIp4H/CCjy649 73qQ== X-Gm-Message-State: AOPr4FXryibWCb9Igs9C3wVYmBj0qEQtmWzEWFWxjDAVsqqllU2dHRq9ULkhocpN3zpNPg== X-Received: by 10.194.134.3 with SMTP id pg3mr6990237wjb.141.1461137841404; Wed, 20 Apr 2016 00:37:21 -0700 (PDT) Received: from tsf-436-wpa-5-044.epfl.ch (tsf-436-wpa-5-044.epfl.ch. [128.179.141.44]) by smtp.gmail.com with ESMTPSA id r2sm4120762wjm.8.2016.04.20.00.37.19 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 20 Apr 2016 00:37:19 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_67D21FAA-F6B4-400A-A50A-6A412016B125"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Bryan Ford In-Reply-To: <20160420021208.5285C6031B@jupiter.mumble.net> Date: Wed, 20 Apr 2016 09:37:18 +0200 Message-Id: <2D9489C8-326D-4425-A3A5-DF0C1B8D3CE5@gmail.com> References: <20160420021208.5285C6031B@jupiter.mumble.net> To: Taylor R Campbell X-Mailer: Apple Mail (2.3124) Archived-At: Cc: cfrg@irtf.org Subject: Re: [Cfrg] Adopting "AES-GCM-SIV: Nonce Misuse-Resistant Authenticated Encryption" as a CFRG document ---- Some clarifications X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2016 07:37:25 -0000 --Apple-Mail=_67D21FAA-F6B4-400A-A50A-6A412016B125 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Apr 20, 2016, at 4:13 AM, Taylor R Campbell = wrote: > The creators of AES-GCM-SIV and chairs of the CFRG evidently decided > that it would be better to sidestep the competition and endorse crypto > that is, lacking hardware support, either unusably slow or vulnerable > to timing side channels, recommending it for general-purpose use on > the internet. I have to say I was also quite surprised by the declaration that there = is =E2=80=9Crough consensus=E2=80=9D to adopt. While I haven=E2=80=99t = been following this thread extremely closely, what I remember seeing is: - 2-3 messages (mostly early on in the thread) explicitly opposed to = adoption due to this concern about sidestepping the CAESAR competition - 2-3 messages expressing explicit support for adoption - A whole bunch of E-mails discussing various technical issues, but = neither explicitly supporting or opposing adoption as far as I could = tell. I admit I did not do any kind of precise tally on any basis, this is = merely my impression, which is why the adoption declaration took me by = surprise. I personally also have deep concerns about CFRG hastily adopting an AEAD = proposal that has not received the careful scrutiny that the CAESAR = competitors are receiving, especially not primarily on the basis of = performance claims. I have not seen evidence of an urgent need for a = misuse-resistant AEAD scheme to be standardized =E2=80=9Cright now=E2=80=9D= - and if there were an urgent need, the CFRG should at least choose = among those CAESAR competitors still in the running (after the first = round) that seem to have received the greatest analysis and community = support so far. Again just my $.02 B --Apple-Mail=_67D21FAA-F6B4-400A-A50A-6A412016B125 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJ+DCCBK8w ggOXoAMCAQICEQDgI8sVEoNTia1hbnpUZ2shMA0GCSqGSIb3DQEBCwUAMG8xCzAJBgNVBAYTAlNF MRQwEgYDVQQKEwtBZGRUcnVzdCBBQjEmMCQGA1UECxMdQWRkVHJ1c3QgRXh0ZXJuYWwgVFRQIE5l dHdvcmsxIjAgBgNVBAMTGUFkZFRydXN0IEV4dGVybmFsIENBIFJvb3QwHhcNMTQxMjIyMDAwMDAw WhcNMjAwNTMwMTA0ODM4WjCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hl c3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNV BAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWls IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAibEN2npTGU5wUh28VqYGJre4SeCW 51Gr8fBaE0kVo7SMG2C8elFCp3mMpCLfF2FOkdV2IwoU00oCf7YdCYBupQQ92bq7Fv6hh6kuQ1JD FnyvMlDIpk9a6QjYz5MlnHuI6DBk5qT4VoD9KiQUMxeZrETlaYujRgZLwjPU6UCfBrCxrJNAubUI kzqcKlOjENs9IGE8VQOO2U52JQIhKfqjfHF2T+7hX4Hp+1SA28N7NVK3hN4iPSwwLTF/Wb1SN7Az aS1D6/rWpfGXd2dRjNnuJ+u8pQc4doykqTj/34z1A6xJvsr3c5k6DzKrnJU6Ez0ORjpXdGFQvsZA P8vk4p+iIQIDAQABo4IBFzCCARMwHwYDVR0jBBgwFoAUrb2YejS0Jvf6xCZU7wO94CTLVBowHQYD VR0OBBYEFJJha4LhoqCqT+xn8cKj97SAAMHsMA4GA1UdDwEB/wQEAwIBhjASBgNVHRMBAf8ECDAG AQH/AgEAMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDARBgNVHSAECjAIMAYGBFUdIAAw RAYDVR0fBD0wOzA5oDegNYYzaHR0cDovL2NybC51c2VydHJ1c3QuY29tL0FkZFRydXN0RXh0ZXJu YWxDQVJvb3QuY3JsMDUGCCsGAQUFBwEBBCkwJzAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNl cnRydXN0LmNvbTANBgkqhkiG9w0BAQsFAAOCAQEAGypurFXBOquIxdjtzVXzqmthK8AJECOZD8Vm am+x9bS1d14PAmEA330F/hKzpICAAPz7HVtqcgIKQbwFusFY1SbC6tVNhPv+gpjPWBvjImOcUvi7 BTarfVil3qs7Y+Xa1XPv7OD7e+Kj//BCI5zKto1NPuRLGAOyqC3U2LtCS5BphRDbpjc06HvgARCl nMo6x59PiDRuimXQGoq7qdzKyjbR9PzCZCk1r9axp3ER0gNDsY8+muyeMlP0dpLKhjQHuSzK5hxK 2JkNwYbikJL7WkJqIyEQ6WXH9dW7fuqMhSACYurROgcsWcWZM/I4ieW26RZ6H3kU9koQGib6fIr7 mzCCBUEwggQpoAMCAQICEBalm03EcGSFWgbYcpp5puowDQYJKoZIhvcNAQELBQAwgZsxCzAJBgNV BAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAY BgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQg QXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xNTA2MjQwMDAwMDBaFw0xNjA2 MjMyMzU5NTlaMCYxJDAiBgkqhkiG9w0BCQEWFWJyeW5vc2F1cnVzQGdtYWlsLmNvbTCCASIwDQYJ KoZIhvcNAQEBBQADggEPADCCAQoCggEBAMA89U5ktW7a1k5qjaiycbEbBjLucLdRfzKh5us59o1a Qi0iRQfo1BEq6rG4MTvXburjxUdzuTCaDgOJ+g6PFKNfJP5H2lH962EXCNeJYKOwhpZtwVzpfsPV 8iKw7XjPwPiW4E7Ut7M1UHoN57yUy60/047gyYpZirf4lpv1G//cFcLKIMNB/GGK5YXNlBNalvMY Z/CK1yo8cf3s83gI4KGGE65RL1i3WpAFjwaffp5V6kp3PdiIXuKL8kO2HWID/McrynKKb46ARFzC joiV2qHn27LQiMwBwoDUxzfgCAxAl0uWaFgBqLmcws4lCIXN8jIHp6CNLKKyHHXWukv/EqUCAwEA AaOCAfMwggHvMB8GA1UdIwQYMBaAFJJha4LhoqCqT+xn8cKj97SAAMHsMB0GA1UdDgQWBBSlca2J DhGBY+vVSOfJ1I+3I9NqLzAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAX BggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYM KwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BT MF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET1NIQTI1NkNs aWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgZAGCCsGAQUFBwEBBIGDMIGA MFgGCCsGAQUFBzAChkxodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01PRE9TSEEyNTZDbGllbnRB dXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2Nz cC5jb21vZG9jYS5jb20wIAYDVR0RBBkwF4EVYnJ5bm9zYXVydXNAZ21haWwuY29tMA0GCSqGSIb3 DQEBCwUAA4IBAQAMNIE1FhYCtEA9JMwLoNKtQ4hZDcnUKYRcRihDhAHIKSTJtFQKBchp1MBTCP4P 1lfgdDHG+06Rv65VAKfBsjqMZmPQylvsxZg5kPJ5BPVgShQxGl5RSlMN3qLDcSbQt/6uPv9U+Vgq 8StMI6fIRSbbPwyKyZyM8gUnxR34dxzJ+mSGi0kdtUE36FIabTeXtjFVXN/2jDOrsvm8IHlp8nJM 23nHuqUsJyyIYFbaRKhApoMAzC5gynlg6APV2hz/JYlKSJABwpxZjYAtpyz5rQVIi2pPWs2Te2cd faykisGAOu/7nJtlcEGMCSd61tM43matZPa3MuBiko8kuzj0RMigMYIDwzCCA78CAQEwgbAwgZsx CzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZv cmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBD bGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQFqWbTcRwZIVaBthymnmm 6jAJBgUrDgMCGgUAoIIB5zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xNjA0MjAwNzM3MTlaMCMGCSqGSIb3DQEJBDEWBBRgemx+gYej3I1fYStwJb0GW7GuzDCBwQYJ KwYBBAGCNxAEMYGzMIGwMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVz dGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UE AxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwg Q0ECEBalm03EcGSFWgbYcpp5puowgcMGCyqGSIb3DQEJEAILMYGzoIGwMIGbMQswCQYDVQQGEwJH QjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQK ExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UEAxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhl bnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEBalm03EcGSFWgbYcpp5puowDQYJKoZIhvcN AQEBBQAEggEAtQjIm1xl4qYlKHT7/edYFTIh9sxI7gIprpv5zrREWkqkca/Jfzfx0gHzQrONXMmx +MG7k5yiaM+bnyk+W32+0UWIDniCoPnkaZ72URL8IN19EgvnrMwKf2rQ0qIgzpMD6k5L6ph5C+w0 uyEx8Wg6MYDSZ+CnlFMN2mYWKvYeB1ynjxF+6Pb3BBKEjfkrQFhz2pswJtHP6/HXU30sFXzA8wem L+eHlRvkYFPpkUbK1Ed4xqODeZu7U6uB4VQmlfMYFIj7wps0E3/DCl99qtleY4h+x30PaM5WKOH8 bd9ZJ/BKEhj58e7gyMKcQiC5CMl4PapshTLQ4X2E0K3yzoPy0wAAAAAAAA== --Apple-Mail=_67D21FAA-F6B4-400A-A50A-6A412016B125-- From nobody Wed Apr 20 01:44:11 2016 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D70F12DD78; Wed, 20 Apr 2016 01:44:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=rhul.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jd4aar5ILtU5; Wed, 20 Apr 2016 01:44:07 -0700 (PDT) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0682.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::682]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E680212D7BA; Wed, 20 Apr 2016 01:44:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rhul.onmicrosoft.com; s=selector1-rhul-ac-uk; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=g7lR2BVhr1ROcXY6xAEq4nBjDSm5FxXwdhmG/YVK95A=; b=ATAFBc8kkaelk4mkFlvbz08gP629lPcaMEvlWCAFasD11+Avolm9XeU4icndntIqXizZKcBg7kkoh5jH+odlo+7KVeEAaMMIUmEFcvwZ5fSyhWkjQ1jexPFVuPqccDkz/PXAIL/frVA9TgkTxCmaHvzEIDSeN4p3ylUBPiCJKoU= Received: from VI1PR03MB1822.eurprd03.prod.outlook.com (10.166.42.148) by VI1PR03MB1824.eurprd03.prod.outlook.com (10.166.42.150) with Microsoft SMTP Server (TLS) id 15.1.466.19; Wed, 20 Apr 2016 08:43:50 +0000 Received: from VI1PR03MB1822.eurprd03.prod.outlook.com ([10.166.42.148]) by VI1PR03MB1822.eurprd03.prod.outlook.com ([10.166.42.148]) with mapi id 15.01.0466.022; Wed, 20 Apr 2016 08:43:50 +0000 From: "Paterson, Kenny" To: Daniel Kahn Gillmor , "cfrg@ietf.org" , "draft-irtf-cfrg-eddsa.all@ietf.org" Thread-Topic: draft-irtf-cfrg-eddsa -- one final proposal for domain separation (context labels) for ed25519 Thread-Index: AQHRms27mjB4fMkE2EOrRhA6598tIZ+SnOqA Date: Wed, 20 Apr 2016 08:43:50 +0000 Message-ID: References: <87bn543id1.fsf@alice.fifthhorseman.net> In-Reply-To: <87bn543id1.fsf@alice.fifthhorseman.net> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.2.160219 authentication-results: fifthhorseman.net; dkim=none (message not signed) header.d=none;fifthhorseman.net; dmarc=none action=none header.from=rhul.ac.uk; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [92.4.66.92] x-ms-office365-filtering-correlation-id: bf883e4b-55f4-493d-4d8b-08d368f7e571 x-microsoft-exchange-diagnostics: 1; VI1PR03MB1824; 5:44bzpYqbkFIhfOphJBz4+8B0Wq1J2n+6AY9vfPDk23zr0Zerzh4NT8tUr4lCyhHF6ZhSxFFpsXS69bf4OD8O9UI2Bd7eeKbzRNszZO6DG4k3vauOWjhIzJG8orPtgSQfiyOse4C02HHzUk7YvHoifilprpjH1dawoG8+/Ye2CVUuwL/2WfWy3oRl2PrNo9tf; 24:HE0RL4xeXHTEcb/Y/5Y9qI6AIV7R6bI6b2c9JcQTt1udzfDuyNSS2phLe/8r3wmKyhGqu2AlMjjp9AbDFFFbJXjVLed//qCCEoTJRiv/sa0=; 7:KO4aQZE+9VIQI66q/+KLTt9LYGppDpShcvjNIzSFIAshF23SEqDXP/BPaI4iKeuQBtQTNxY04tBnykbdYnZOqGhwj1jW4kRAYW5hAVEwNnZYmdj63w1hgkXuakxrj2s9Aioo1th8kI6euSm59C3uFxZdya7DrQj/PziRfbYpy61ojIQsBOc4SB5Wn5tTTZvi0rbgawrxDdR9p6S6VspjQQ== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:VI1PR03MB1824; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(9101521026)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001); SRVR:VI1PR03MB1824; BCL:0; PCL:0; RULEID:; SRVR:VI1PR03MB1824; x-forefront-prvs: 0918748D70 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(24454002)(53754006)(5004730100002)(122556002)(66066001)(5008740100001)(4326007)(11100500001)(5001770100001)(92566002)(4001350100001)(3280700002)(10400500002)(586003)(102836003)(1096002)(3846002)(6116002)(189998001)(81166005)(74482002)(77096005)(1220700001)(2950100001)(15975445007)(2900100001)(3660700001)(87936001)(54356999)(2906002)(76176999)(50986999)(19580405001)(106116001)(19580395003)(86362001)(2201001)(36756003)(5002640100001)(83506001)(230783001)(561944003)(2501003); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR03MB1824; H:VI1PR03MB1822.eurprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: text/plain; charset="utf-8" Content-ID: <75D9269B442AF543816A808758C2B13E@eurprd03.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: rhul.ac.uk X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Apr 2016 08:43:50.4053 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2efd699a-1922-4e69-b601-108008d28a2e X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR03MB1824 Archived-At: Cc: =?utf-8?B?T25kxZllaiBTdXLDvQ==?= , Robert Edmonds , Benjamin Kaduk , Martin Thomson Subject: Re: [Cfrg] draft-irtf-cfrg-eddsa -- one final proposal for domain separation (context labels) for ed25519 X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2016 08:44:10 -0000 SGkgRGFuaWVsLA0KDQpZb3VyIHByb3Bvc2FsIHNlZW1zIHRvIG1lIHRvIGJlIGEgdmVyeSBzZW5z aWJsZSBpZGVhLg0KDQpXZSBhcmUgcXVpdGUga2VlbiB0byBnZXQgZHJhZnQtaXJ0Zi1jZnJnLWVk ZHNhICJzaGlwcGVkIiwgYXMgaXQncyBuZWVkZWQNCmVsc2V3aGVyZSBpbiBJRVRGIGFuZCBkZXBl bmRlbmNpZXMgYXJlIGJ1aWxkaW5nIHVwLg0KDQpTbywgQGFsbCwgbGV0J3MgdHJ5IHRvIGhhdmUg YSBxdWljayBkaXNjdXNzaW9uIG9uIHRoZSBwcm9wb3NhbCBhbmQgc2VlIGlmDQphbnkgcmVhc29u cyBlbWVyZ2UgZm9yIG5vdCBhZG9wdGluZyBpdC4NCg0KQ2hlZXJzLA0KDQpLZW5ueSANCg0KDQoN Ck9uIDIwLzA0LzIwMTYgMDc6MjcsICJEYW5pZWwgS2FobiBHaWxsbW9yIiA8ZGtnQGZpZnRoaG9y c2VtYW4ubmV0PiB3cm90ZToNCg0KPkhpIGFsbC0tDQo+DQo+aW4gZHJhZnQtaXJ0Zi1jZnJnLWVk ZHNhLTA1LCB0aGVyZSBpcyBhIGNvbnRleHQgbGFiZWwgZGVmaW5lZCBmb3IgZWQ0NDgsDQo+YnV0 IG5vIHN1Y2ggbGFiZWwgaXMgZGVmaW5lZCBmb3IgZWQyNTUxOS4gICh0aGUgImNvbnRleHQgbGFi ZWwiIGlzIGEgd2F5DQo+dG8gcHJvdmlkZSBkb21haW4gc2VwYXJhdGlvbiBiZXR3ZWVuIHNpZ25h dHVyZXMgbWFkZSBpbiBkaWZmZXJlbnQNCj5jb250ZXh0cywgYXZvaWRpbmcgY3Jvc3MtcHJvdG9j b2wgYXR0YWNrcykNCj4NCj5wZW9wbGUgc2VlbSBPSyB3aXRoIGRvbWFpbiBzZXBhcmF0aW9uIGZv ciBlZDQ0OCwgYnV0IHdlJ3ZlIHJlamVjdGVkIGl0DQo+Zm9yIGVkMjU1MTkgdG8gYWNoaWV2ZSBi YWNrd2FyZCBjb21wYXRpYmlsaXR5IHdpdGggZXhpc3Rpbmcgc2lnbmF0dXJlcywNCj5hbmQgdG8g YXZvaWQgQVBJIGNoYW5nZXMgdG8gZXhpc3RpbmcgZWQyNTUxOSBsaWJyYXJpZXMsIGFzIGRpc2N1 c3NlZCBpbg0KPnRocmVhZHMgbGlrZSBbMF0uDQo+DQo+SSB3YW50ZWQgdG8gZmxvYXQgb25lIGZp bmFsIG1pZGRsZS1ncm91bmQgcHJvcG9zYWwgdGhhdCB3b3VsZCBhbGxvdyB1cw0KPnRvIGFsaWdu IHRoZSBBUElzIGJldHdlZW4gdGhlIHR3byBieSBhZGRpbmcgYW4gb3B0aW9uYWwgY29udGV4dA0K PnBhcmFtZXRlciB0byBlZDI1NTE5L2VkMjU1MTlwaC4gIElmIHRoaXMgaXNuJ3QgYWNjZXB0YWJs ZSwgcGxlYXNlDQo+Y29uc2lkZXIgaW5zdGVhZCB0aGUgcHJvcG9zZWQgYWRkaXRpb25hbCBTZWN1 cml0eSBDb25zaWRlcmF0aW9ucyB0b3dhcmQNCj50aGUgZW5kIG9mIHRoaXMgbWVzc2FnZS4NCj4N Cj5UaGUgcHJvcG9zYWwgZm9yIGluY2x1ZGluZyBvcHRpb25hbCBjb250ZXh0IGxhYmVscyBpbiAy NTUxOSBpcyBzaW1wbGU6DQo+DQo+ICogaW4gVGFibGUgMTogUGFyYW1ldGVycyBvZiBFZDI1NTE5 LCBjaGFuZ2UgSCh4KSBmcm9tICJTSEEtNTEyKHgpIiB0bw0KPiAgICJTSEEtNTEyKGNvbnRleHQg fHwgeCkiLCBhbmQgY2hhbmdlIFBIKHgpIHRvICJjb250ZXh0IHx8IHgiLg0KPg0KPiAqIGNoYW5n ZSB0aGUgc2VudGVuY2UgZGVzY3JpYmluZyB0aGUgcGggdmFyaWFudCB0aGF0IGZvbGxvd3MgdGhl IHRhYmxlDQo+ICAgdG86DQo+DQo+ICAgIEVkMjU1MTlwaCBpcyB0aGUgc2FtZSBidXQgd2l0aCBQ SCBiZWluZyBTSEEtNTEyKGNvbnRleHQgfHwgeCkNCj4gICAgaW5zdGVhZCwgaS5lLiwgdGhlIGlu cHV0IGlzIGhhc2hlZCB1c2luZyBTSEEtNTEyIGJlZm9yZSBzaWduaW5nIHdpdGgNCj4gICAgRWQy NTUxOS4NCj4NCj5JZiAiY29udGV4dCIgaXMgdW5zcGVjaWZpZWQgYnkgdGhlIHVzZXIgaXQgaXMg dHJlYXRlZCBhcyB0aGUgZW1wdHkNCj5zdHJpbmcgYW5kLCB0aGUgcmVzdWx0IGlzIGV4YWN0bHkg dGhlIHNhbWUgYXMgdGhlIGN1cnJlbnQgZGVzY3JpcHRpb24uDQo+VGhpcyBpcyBhbHNvIGVhc3kg Zm9yIHNvbWVvbmUgdG8gaW1wbGVtZW50IHdpdGggZXhpc3RpbmcgZWQyNTUxOQ0KPmxpYnJhcmll cyB3aXRoIG5vIEFQSSBjaGFuZ2U6IGp1c3QgY29uY2F0ZW5hdGUgYmVmb3JlIHNpZ25pbmcgb3IN Cj52ZXJpZnlpbmcuDQo+DQo+VGhpcyB3b3VsZCBtZWFuIHRoYXQgYSBzaWduYXR1cmUgd2l0aCBh IGNvbnRleHQgbGFiZWwgZm9yIDI1NTE5IGlzIG5vdA0KPnNlcGFyYXRlZCBmcm9tIGEgc2lnbmF0 dXJlICp3aXRob3V0KiBhIGNvbnRleHQgbGFiZWwgKGEgd2Vha2VyIGRvbWFpbg0KPnNlcGFyYXRp b24gdGhhbiB3ZSdyZSBvZmZlcmluZyBpbiBlZDQ0OCksIGJ1dCBpdCBhdCBsZWFzdCBwcm92aWRl cyBhDQo+c3RhbmRhcmQgd2F5IGZvciBwcm90b2NvbHMgdGhhdCB3YW50IHRvIG1ha2UgZG9tYWlu LXNlcGFyYXRlZCBzaWduYXR1cmVzDQo+dG8gZG8gc28sIHdoaWNoIG1pZ2h0IGhlbHAgdXMgdG8g ZW5jb3VyYWdlIGRvbWFpbiBzZXBhcmF0aW9uIGluDQo+c3RhbmRhcmRzIHdoaWNoIGNvbnRlbXBs YXRlIHRoZSB1c2Ugb2YgZWl0aGVyIEVkNDQ4IG9yIEVkMjU1MTkgKHRoZWlyDQo+YWJzdHJhY3Qg QVBJcyBhcmUgYWxpZ25hYmxlKS4NCj4NCj4NCj5JIGFsc28gdGhpbmsgd2UgbmVlZCBzb21lIHRl eHQgZXhwbGFpbmluZyB0aGUgZGlmZmVyZW5jZSBiZXR3ZWVuIHRoZSB0d28NCj5hcHByb2FjaGVz LiAgSWYgd2UgYWRvcHQgdGhlIGFib3ZlIHByb3Bvc2FsLCB3ZSBjb3VsZCBhZGQgc29tZXRoaW5n IGxpa2UNCj50aGlzIHRvIHRoZSBTZWN1cml0eSBDb25zaWRlcmF0aW9ucyBvciBzZWN0aW9uIDEw LjMgKCJVc2Ugb2YgY29udGV4dHMiKToNCj4NCj4tLS0tLS0tLS0tDQo+ICBOb3RlIHRoYXQgdGhl IGRvbWFpbiBzZXBhcmF0aW9uIGZvciBFZDI1NTE5IGFuZCBFZDI1NTE5cGggaXMgd2Vha2VyDQo+ ICB0aGFuIHRoZSBkb21haW4gc2VwYXJhdGlvbiBmb3IgRWQ0NDggYW5kIEVkNDQ4cGggaW4gdHdv IHdheXM6DQo+DQo+ICAgIChhKSBTaWduYXR1cmVzIHRoYXQgZG8gbm90IHVzZSBjb250ZXh0IGxh YmVscyBjYW4gcG90ZW50aWFsbHkNCj4gIGNvbGxpZGUgd2l0aCBzaWduYXR1cmVzIHRoYXQgdXNl IGNvbnRleHQgbGFiZWxzLiAgVGhpcyBjYW4gb25seSBiZQ0KPiAgbWl0aWdhdGVkIGJ5IG5ldmVy IHVzaW5nIHRoZSBzYW1lIGtleSBpbiBtdWx0aXBsZSBkb21haW5zIHdpdGhvdXQNCj4gIGhhdmlu ZyBhIGRvbWFpbi1zcGVjaWZpYyBjb250ZXh0IGxhYmVsIGZvciBlYWNoIHVzZS4NCj4NCj4gICAg KGIpIFNpZ25hdHVyZSBkb21haW5zIHRoYXQgdXNlIGNvbnRleHQgbGFiZWxzIHdoZXJlIG9uZSBj b250ZXh0DQo+ICBsYWJlbCBpcyBhIHByZWZpeCBvZiB0aGUgb3RoZXIgbWF5IGFsc28gaGF2ZSBj b2xsaXNpb25zLiAgVGhpcyBjYW4gYmUNCj4gIG1pdGlnYXRlZCBieSBhbHdheXMgY2hvb3Npbmcg YSBjb250ZXh0IGxhYmVscyB0aGF0IGNvbnNpc3Qgb2YNCj4gIHByaW50YWJsZSBBU0NJSSBjaGFy YWN0ZXJzIGZvbGxvd2VkIGJ5IGEgc2luZ2xlIHplcm8tdmFsdWVkIG9jdGV0Lg0KPg0KPiAgVGhp cyB3ZWFrZXIgZG9tYWluIHNlcGFyYXRpb24gaXMgYWNjZXB0ZWQgaW4gRWQyNTUxOSBkdWUgdG8g d2lkZXNwcmVhZA0KPiAgZXhpc3RpbmcgY29udGV4dC1mcmVlIGRlcGxveW1lbnQgYW5kIHRoZSBk ZXNpcmUgdG8gYXZvaWQgYnJlYWtpbmcNCj4gIGJhY2t3YXJkIGNvbXBhdGliaWxpdHkuIEZvciBF ZDQ0OCwgd2hpY2ggaXMgbm90IHlldCBhcyB3aWRlbHkNCj4gIGRlcGxveWVkLCB0aGUgZG9tKCkg ZnVuY3Rpb24ncyBzdHJvbmdlciBkb21haW4gc2VwYXJhdGlvbiBndWFyYW50ZWVzDQo+ICBhcmUg cHJlZmVycmVkLg0KPi0tLS0tLS0tLS0NCj4NCj5JZiB3ZSBkbyBub3QgYWRvcHQgdGhlIGFib3Zl IGNoYW5nZXMsIGFuZCBsZWF2ZSBlZDI1NTE5IGFuZCBlZDI1NTE5cGgNCj53aXRob3V0IGFueSBh dHRlbXB0IGF0IGRvbWFpbiBzZXBhcmF0aW9uLCB3ZSBhbHNvIHByb2JhYmx5IG5lZWQgYSBiaXQg b2YNCj50ZXh0IGV4cGxhaW5pbmcgd2h5IG9uZSBwcmltaXRpdmUgaGFzIGRvbWFpbiBzZXBhcmF0 aW9uIGFuZCB0aGUgb3RoZXINCj5kb2VzIG5vdCwgcHJvYmFibHkgaW4gZWl0aGVyIFNlY3VyaXR5 IENvbnNpZGVyYXRpb25zIG9yIHNlY3Rpb24gMTAuMy4NCj5PdGhlcndpc2UsIGZ1dHVyZSBwZW9w bGUgcmVhZGluZyB0aGUgZHJhZnQgd291bGQgbmVlZCB0byB0cmFjayBkb3duDQo+bWVzc2FnZXMg bGlrZSB0aG9zZSBpbiBbMF0gdG8gdW5kZXJzdGFuZCB0aGUgYXN5bW1ldHJ5Lg0KPg0KPkEgcHJv cG9zYWwgZm9yIHRleHQgaW4gdGhpcyBzY2VuYXJpbzoNCj4NCj4tLS0tLS0tLS0tLQ0KPiAgTm90 ZSB0aGF0IG9ubHkgRWQ0NDggb2ZmZXJzIHN0cm9uZyBkb21haW4gc2VwYXJhdGlvbiB2aWEgY29u dGV4dA0KPiAgbGFiZWxzLCB3aGlsZSBFZDI1NTE5IGxhY2tzIHRoaXMgY2FwYWJpbGl0eS4gIFRo aXMgaXMgZHVlIHRvIGEgZGVzaXJlDQo+ICB0byByZXRhaW4gYmFja3dhcmQgY29tcGF0aWJpbGl0 eSB3aXRoIGV4aXN0aW5nIEVkMjU1MTkgZGVwbG95bWVudHMsDQo+ICBhbmQgdG8gbGVhdmUgdGhl IEVkMjU1MTkgQVBJIGFzIHNpbXBsZSBhcyBwb3NzaWJsZS4NCj4NCj4gIElmIGFuIGFwcGxpY2F0 aW9uIG9yIHByb3RvY29sIG5lZWRzIGRvbWFpbiBzZXBhcmF0aW9uIGluIHNpdHVhdGlvbnMNCj4g IHdoZXJlIEVkMjU1MTkgbWF5IGJlIHVzZWQsIGEgd2Vha2VyIGZvcm0gb2YgZG9tYWluIHNlcGFy YXRpb24gbWF5IGJlDQo+ICBoYWQgYnkgcHJlcGVuZGluZyBhIGNvbnRleHQgbGFiZWwgKGZpeGVk IG9jdGV0IHN0cmluZykgdG8gdGhlIG1lc3NhZ2UNCj4gIGJlZm9yZSBzaWduaW5nIG9yIHZlcmlm eWluZywgdXNpbmcgYSBkaWZmZXJlbnQgY29udGV4dCBsYWJlbCBmb3IgZWFjaA0KPiAgc2lnbmF0 dXJlIGRvbWFpbi4gIEZvciB0aGUgcHJlaGFzaCB2YXJpYW50LCBwcmVwZW5kIHRoZSBjb250ZXh0 IHRvIHRoZQ0KPiAgbWVzc2FnZSBiZWZvcmUgcHJlLWhhc2hpbmcuDQo+DQo+ICBUbyBhdm9pZCBj b2xsaXNpb25zIGJldHdlZW4gZG9tYWlucyB3aGVuIHVzaW5nIHRoaXMgd2Vha2VyIGZvcm0gb2YN Cj4gIGRvbWFpbiBzZXBhcmF0aW9uLCBjb250ZXh0IGxhYmVscyBzaG91bGQgY29uc2lzdCBvZiBv bmx5IHByaW50YWJsZQ0KPiAgQVNDSUkgY2hhcmFjdGVycyBmb2xsb3dlZCBieSBhIHNpbmdsZS12 YWx1ZWQgb2N0ZXQuDQo+LS0tLS0tLS0tLS0NCj4NCj5XaGF0IGRvIGZvbGtzIHRoaW5rPw0KPg0K PiAgICAgLS1ka2cNCj4NCj4NCj5bMF0gc2VlIGZvciBleGFtcGxlIElsYXJpJ3MgcmVzcG9uc2Ug aGVyZSB0byBCcnlhbiBGb3JkIGF0IE1lc3NhZ2UtSWQ6DQo+ICAgIDIwMTUxMjExMjAyMjE0LkdB NTUyMkBMSy1QZXJrZWxlLVYyLmVsaXNhLWxhYWpha2Fpc3RhLmZpDQo+ICAgIGh0dHBzOi8vd3d3 LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvY2ZyZy9jdXJyZW50L21zZzA3NzEzLmh0bWwNCj4N Cj4gICAgYW5kIHRoZSAiT24gdGhlIGRpZmZlcmVuY2VzIG9mIEVkMjU1MTkvNDQ4IGFuZCBob3cg aXQgYWZmZWN0cyBhIHZvdGUNCj4gICAgb24gdHdvc2hha2VzLWQiIHRocmVhZCBzdGFydGluZyBh dCBNZXNzYWdlLUlkOg0KPiAgICBDQUE0UHpYMThiY1NfYXdQZy1ZREFvbzkwNTM3T3Q9c19uZjdr X1Z0NzVPVlNkdnREclFAbWFpbC5nbWFpbC5jb20NCj4gICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbC1hcmNoaXZlL3dlYi9jZnJnL2N1cnJlbnQvbXNnMDc2NjUuaHRtbA0KDQo= From nobody Wed Apr 20 01:47:31 2016 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B6B712DB50 for ; Wed, 20 Apr 2016 01:47:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=rhul.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id omm-wVdwRsbx for ; Wed, 20 Apr 2016 01:47:29 -0700 (PDT) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01on0060.outbound.protection.outlook.com [104.47.2.60]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8AB9F12DFF1 for ; Wed, 20 Apr 2016 01:37:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rhul.onmicrosoft.com; s=selector1-rhul-ac-uk; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=ngGSDHRV9ahy6cNEbvKzfRk9UR6cP7cLSEhmnGqIOVM=; b=jqHv/ViOvD0tPBwefIFHA8kE47DLkkePFoFOlc54d+KmgmFvneW0SkhgO7hgb06CI3F6IeltQfNcQI0DpLm8o8/y7zgpBmfiWarzjo4EQxrQhevG9BJ0rURmutav0RM9zg+9vAjByVdvrcWcMxAOF5ISzd94C1LYMXiLSytrxN8= Received: from VI1PR03MB1822.eurprd03.prod.outlook.com (10.166.42.148) by VI1PR03MB1822.eurprd03.prod.outlook.com (10.166.42.148) with Microsoft SMTP Server (TLS) id 15.1.466.19; Wed, 20 Apr 2016 08:37:42 +0000 Received: from VI1PR03MB1822.eurprd03.prod.outlook.com ([10.166.42.148]) by VI1PR03MB1822.eurprd03.prod.outlook.com ([10.166.42.148]) with mapi id 15.01.0466.022; Wed, 20 Apr 2016 08:37:42 +0000 From: "Paterson, Kenny" To: Taylor R Campbell , Fedor Brunner Thread-Topic: [Cfrg] Adopting "AES-GCM-SIV: Nonce Misuse-Resistant Authenticated Encryption" as a CFRG document ---- Some clarifications Thread-Index: AQHRmqo+0oGWPD0QJUGvgVhD1FkOHJ+Sm34A Date: Wed, 20 Apr 2016 08:37:42 +0000 Message-ID: References: <57148B14.7020507@azet.sk> <20160420021208.5285C6031B@jupiter.mumble.net> In-Reply-To: <20160420021208.5285C6031B@jupiter.mumble.net> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.2.160219 authentication-results: mumble.net; dkim=none (message not signed) header.d=none;mumble.net; dmarc=none action=none header.from=rhul.ac.uk; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [92.4.66.92] x-ms-office365-filtering-correlation-id: 7a7850f8-1146-4857-f10a-08d368f70a00 x-microsoft-exchange-diagnostics: 1; VI1PR03MB1822; 5:L0sQAa49126YuXW63MyQia4TQOapHp4XndZPB9Pq8jR7vC+Bqss6IEunTSBDKlMVYzMfmXjOhFwNVuGHuPDJOG+V14D+RC8jwl9vB6PCNAqP0pm7/UaugZCTvjWiBwxG7WXmEu6GBFg2i49fVBEqFlisOvnTXsoszXuU7UZPSGMmvc0rV/EvkmtGIk3BaX0+; 24:qsa8ugNxKmP1ZtXYBZUZFInzJkL0HA9zjp/EAC966ixh505uHYHyw4A6mURU+O67yRQG5JJC+YQdRpVZWP6xQgj07VeusCgvtYHaG0cPQFY=; 7:phtfLyWrmlNk1bn05geWfqiuGfbUhfbNrSkwEl5+sS2OowLGEANlWh2SzmK8EFTMGlEBk4viBAV30cECL+yUJP9iT/nL9Nqtal5XwBRf6heXQgTL8EIiavO/69QNyQQw/AzLU08J2Bcs4Nrk/mdKWgn0l/YCNEyL9MyEOPI9/gHoQ7N+BlTfbepCp1tiZbyl9kwkbHju+5lqXITyogLU9w== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:VI1PR03MB1822; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(9101521026)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046); SRVR:VI1PR03MB1822; BCL:0; PCL:0; RULEID:; SRVR:VI1PR03MB1822; x-forefront-prvs: 0918748D70 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(24454002)(5004730100002)(5008740100001)(74482002)(87936001)(81166005)(11100500001)(6116002)(92566002)(2950100001)(66066001)(76176999)(54356999)(106116001)(77096005)(3280700002)(86362001)(15975445007)(50986999)(3660700001)(5002640100001)(102836003)(189998001)(19580405001)(10400500002)(1220700001)(1096002)(586003)(83506001)(2906002)(3846002)(2900100001)(4326007)(19580395003)(5001770100001)(122556002)(230783001)(4001350100001)(36756003); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR03MB1822; H:VI1PR03MB1822.eurprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: rhul.ac.uk X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Apr 2016 08:37:42.2322 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2efd699a-1922-4e69-b601-108008d28a2e X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR03MB1822 Archived-At: Cc: "cfrg@irtf.org" Subject: Re: [Cfrg] Adopting "AES-GCM-SIV: Nonce Misuse-Resistant Authenticated Encryption" as a CFRG document ---- Some clarifications X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2016 08:47:30 -0000 SGkNCg0KT24gMjAvMDQvMjAxNiAwMzoxMywgIkNmcmcgb24gYmVoYWxmIG9mIFRheWxvciBSIENh bXBiZWxsIg0KPGNmcmctYm91bmNlc0BpcnRmLm9yZyBvbiBiZWhhbGYgb2YgY2FtcGJlbGwrY2Zy Z0BtdW1ibGUubmV0PiB3cm90ZToNCj4NCj5UaGUgY3JlYXRvcnMgb2YgQUVTLUdDTS1TSVYgYW5k IGNoYWlycyBvZiB0aGUgQ0ZSRyBldmlkZW50bHkgZGVjaWRlZA0KPnRoYXQgaXQgd291bGQgYmUg YmV0dGVyIHRvIHNpZGVzdGVwIHRoZSBjb21wZXRpdGlvbiBhbmQgZW5kb3JzZSBjcnlwdG8NCj50 aGF0IGlzLCBsYWNraW5nIGhhcmR3YXJlIHN1cHBvcnQsIGVpdGhlciB1bnVzYWJseSBzbG93IG9y IHZ1bG5lcmFibGUNCj50byB0aW1pbmcgc2lkZSBjaGFubmVscywgcmVjb21tZW5kaW5nIGl0IGZv ciBnZW5lcmFsLXB1cnBvc2UgdXNlIG9uDQo+dGhlIGludGVybmV0Lg0KDQpBcyB3ZSBzYWlkIHJp Z2h0IGJhY2sgYXQgdGhlIHN0YXJ0LCBDRlJHIGFkb3B0aW5nIEFFUy1HQ00tU0lWIGRvZXMgbm90 DQpwcmVjbHVkZSB1cyBmcm9tIGFsc28gYWRvcHRpbmcgb3RoZXIgYWxnb3JpdGhtcyB3aGVuIHRo ZXkgZXZlbnR1YWxseQ0KZW1lcmdlIGZyb20gdGhlIENBRVNBUiBwcm9jZXNzLiBJbmRlZWQsIHdl IGxvb2sgZm9yd2FyZCB0byB0aGF0IGhhcHBlbmluZy4NClRoZXJlJ3MgY2VydGFpbmx5IG5vdGhp bmcgZGVmaW5pdGl2ZSBvciBmaW5hbCBhYm91dCBBRVMtR0NNLVNJViBhcyBmYXIgYXMNCndlIGFy ZSBjb25jZXJuZWQuIA0KDQpNb3Jlb3ZlciwgYXMgY2hhaXJzLCB3ZSBkbyBub3QgImVuZG9yc2Ui IGFueXRoaW5nLCBub3IgYXJlIHdlIGRlbGliZXJhdGVseQ0Kc2lkZS1zdGVwcGluZyB0aGUgQ0FF U0FSIGNvbXBldGl0aW9uLiBSYXRoZXIsIHdlIGhhdmUgdGhlIGRpZmZpY3VsdCB0YXNrDQpvZiBh dHRlbXB0aW5nIHRvIGJhbGFuY2UgdGhlIGludGVyZXN0cyBhbmQgbmVlZHMgb2Ygc29tZSBwYXJ0 aWNpcGFudHMgaW4NCnRoZSBncm91cCBhZ2FpbnN0IHRob3NlIG9mIG90aGVycy4NCg0KSXQncyBm aW5lIHRoYXQgeW91IGRpc2FncmVlIG9uIHdoZXJlIHdlJ3ZlIHN0cnVjayB0aGUgYmFsYW5jZSBp biB0aGlzDQpjYXNlLCBidXQgcGxlYXNlIGRvIHVuZGVyc3RhbmQgdGhhdCB0aGVzZSBkZWNpc2lv bnMgYXJlIG5vdCBibGFjayBhbmQNCndoaXRlLg0KDQpSZWdhcmRzLA0KDQpLZW5ueQ0KDQo+DQo+ DQo+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj5DZnJn IG1haWxpbmcgbGlzdA0KPkNmcmdAaXJ0Zi5vcmcNCj5odHRwczovL3d3dy5pcnRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL2NmcmcNCg0K From nobody Wed Apr 20 02:04:27 2016 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9498612E61F for ; Wed, 20 Apr 2016 02:04:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o2fEjAig5Ujr for ; Wed, 20 Apr 2016 02:04:23 -0700 (PDT) Received: from mail-ig0-x22a.google.com (mail-ig0-x22a.google.com [IPv6:2607:f8b0:4001:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 14B2A12EA82 for ; Wed, 20 Apr 2016 02:04:21 -0700 (PDT) Received: by mail-ig0-x22a.google.com with SMTP id gy3so122878640igb.0 for ; Wed, 20 Apr 2016 02:04:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=Ai7aFdSjYdvVA3U2v8Ef1YZ4xLnxOc5aHwV5Bqpg6Lg=; b=plKYKhVNNdXXoHx+mMp8sBO3lDwKVzC2c25IvQfgUfXipIC9z6vGsDWarGKfVla+D+ xQZUufNuEFpHvYegnR9RBLaNBY/yoX9OyH+kFJZ6SzVBRTxoEA4s/z74uJNqYB4gzn1X xnM+/H/+4w2xmd9sQfjZjfy8zfXjNbtGDMi4MQIeNHqaWUPUaHnaUEs9+Z6pFeDtaGgP qrJxwJg1jSnqvdb3Ivk0OvNMG3bPXfekKwTtCFX7VjYtuxfOUxNVpqVY135xazB047RR xSMBwX0cYTrmTAoV0XooRvkPggZ2wf4OYdAwG1CrBRtqKn+iBKJhCIA4UpqxyaM5pjyc jc4Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=Ai7aFdSjYdvVA3U2v8Ef1YZ4xLnxOc5aHwV5Bqpg6Lg=; b=JfdKwH3h4JoiUrsOd0S80J5S4ggX1Ts6YW0EUAk4L+ruqT9ABWqP9fQySNCGgxXh5q TDH2Ro2LsgsmeNf4/4SMVO5lNF2xESopT2AH2gvnd23PHQHjnznSdZwf3SF3b8te7x0g H3wZgXwZ5KJDnv85J7lCLQu95Dsn9kt0u6NhgaIhUnBT8UaIc8QSHHJhKl9lvYOQ6qwn TB31U8LVeEqqb0rN3iUcdihfs/H8NKqKvMdB28+OX/kFQFvKGtlqIN2s0CF9TBF0FfyW asiPpyueCmZZBtaaTyshH1mcyTxHTBnXMWieEzUIt/Bx3v3K5SBJ1iK1lJmpDkUdTvJV B4Sg== X-Gm-Message-State: AOPr4FWjnU+VPppkhbcWx7A6WRryEn2d/LtNP/9j63Nx3JxwtrvKwxrDxRekTbnPvd54bGUe8oEhli0xbB0pYQ== MIME-Version: 1.0 X-Received: by 10.50.119.131 with SMTP id ku3mr2065155igb.75.1461143061212; Wed, 20 Apr 2016 02:04:21 -0700 (PDT) Received: by 10.79.34.161 with HTTP; Wed, 20 Apr 2016 02:04:21 -0700 (PDT) In-Reply-To: References: <57148B14.7020507@azet.sk> <20160420021208.5285C6031B@jupiter.mumble.net> Date: Wed, 20 Apr 2016 17:04:21 +0800 Message-ID: From: Thomas Peyrin To: "Paterson, Kenny" Content-Type: multipart/alternative; boundary=001a11348b0a213aba0530e6e15f Archived-At: Cc: "cfrg@irtf.org" Subject: Re: [Cfrg] Adopting "AES-GCM-SIV: Nonce Misuse-Resistant Authenticated Encryption" as a CFRG document ---- Some clarifications X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2016 09:04:25 -0000 --001a11348b0a213aba0530e6e15f Content-Type: text/plain; charset=UTF-8 Hi, Sorry to continue this discussion, but I'm still dubious on the consideration of AES-GCM-SIV. I think there are two questions here: - the first one is why do we need to push an AEAD now, while the CAESAR competition will lead to a selected portfolio in a few years ? - the second is if we really want to have an AEAD now, why looking at AES-GCM-SIV only, while there are candidates from the CAESAR competitions (that have probably been much more analysed than AES-GCM-SIV and thus present a direct important advantage) ? I understand the explanations for the first point (considering an AEAD now doesn't preclude from having CAESAR candidates later as well), but I don't understand for the second point. Why do we need to wait for the end of CAESAR competition before considering CAESAR candidates instead of AES-GCM-SIV ? I believe we should at least take a short look at the current algorithms available now, and not only AES-GCM-SIV ? Cheers, Thomas. 2016-04-20 16:37 GMT+08:00 Paterson, Kenny : > Hi > > On 20/04/2016 03:13, "Cfrg on behalf of Taylor R Campbell" > wrote: > > > >The creators of AES-GCM-SIV and chairs of the CFRG evidently decided > >that it would be better to sidestep the competition and endorse crypto > >that is, lacking hardware support, either unusably slow or vulnerable > >to timing side channels, recommending it for general-purpose use on > >the internet. > > As we said right back at the start, CFRG adopting AES-GCM-SIV does not > preclude us from also adopting other algorithms when they eventually > emerge from the CAESAR process. Indeed, we look forward to that happening. > There's certainly nothing definitive or final about AES-GCM-SIV as far as > we are concerned. > > Moreover, as chairs, we do not "endorse" anything, nor are we deliberately > side-stepping the CAESAR competition. Rather, we have the difficult task > of attempting to balance the interests and needs of some participants in > the group against those of others. > > It's fine that you disagree on where we've struck the balance in this > case, but please do understand that these decisions are not black and > white. > > Regards, > > Kenny > > > > > > >_______________________________________________ > >Cfrg mailing list > >Cfrg@irtf.org > >https://www.irtf.org/mailman/listinfo/cfrg > > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > https://www.irtf.org/mailman/listinfo/cfrg > --001a11348b0a213aba0530e6e15f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

Sorry to continue this discussion, = but I'm still dubious on the consideration of AES-GCM-SIV. I think ther= e are two questions here:
- the first one is why do we n= eed to push an AEAD now, while the CAESAR competition will lead to a select= ed portfolio in a few years ?
- the second is if we=C2=A0really= =C2=A0want to have an AEAD now, why looking at AES-GCM-SIV only, while ther= e are candidates from the CAESAR competitions (that have probably been much= more analysed than AES-GCM-SIV and thus present a direct important advanta= ge) ?

I understand the explanations for the first = point (considering an AEAD now doesn't preclude from having CAESAR cand= idates later as well), but I don't understand for the second point. Why= do we need to wait for the end of CAESAR competition before considering CA= ESAR candidates instead of AES-GCM-SIV ? I believe we should at least take = a short look at the current algorithms available now, and not only AES-GCM-= SIV ?

Cheers,

Thomas.


2016-04-20 16:37 GMT+08:00 Paterson, Kenny <Kenny.Paterson@r= hul.ac.uk>:
Hi

On 20/04/2016 03:13, "Cfrg on behalf of Taylor R Campbell"
<cfrg-bounces@irtf.org on b= ehalf of campbell+cfrg@mumble= .net> wrote:
>
>The creators of AES-GCM-SIV and chairs of the CFRG evidently decided >that it would be better to sidestep the competition and endorse crypto<= br> >that is, lacking hardware support, either unusably slow or vulnerable >to timing side channels, recommending it for general-purpose use on
>the internet.

As we said right back at the start, CFRG adopting AES-GCM-SIV does not
preclude us from also adopting other algorithms when they eventually
emerge from the CAESAR process. Indeed, we look forward to that happening.<= br> There's certainly nothing definitive or final about AES-GCM-SIV as far = as
we are concerned.

Moreover, as chairs, we do not "endorse" anything, nor are we del= iberately
side-stepping the CAESAR competition. Rather, we have the difficult task of attempting to balance the interests and needs of some participants in the group against those of others.

It's fine that you disagree on where we've struck the balance in th= is
case, but please do understand that these decisions are not black and
white.

Regards,

Kenny

>
>
>_______________________________________________
>Cfrg mailing list
>Cfrg@irtf.org
>https://www.irtf.org/mailman/listinfo/cfrg

_______________________________________________
Cfrg mailing list
Cfrg@irtf.org
https://www.irtf.org/mailman/listinfo/cfrg

--001a11348b0a213aba0530e6e15f-- From nobody Wed Apr 20 04:27:06 2016 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81EF612E6B8; Wed, 20 Apr 2016 04:27:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.697 X-Spam-Level: X-Spam-Status: No, score=-3.697 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5BYU-U2JfMnS; Wed, 20 Apr 2016 04:27:03 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [23.79.238.175]) by ietfa.amsl.com (Postfix) with ESMTP id DA35C12E474; Wed, 20 Apr 2016 04:27:02 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 00BBF433453; Wed, 20 Apr 2016 11:27:02 +0000 (GMT) Received: from prod-mail-relay11.akamai.com (prod-mail-relay11.akamai.com [172.27.118.250]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id DE7E4433405; Wed, 20 Apr 2016 11:27:01 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1461151621; bh=r6RNmqg2/zM2kDtxviUdceTnMe1FITsne2UQPR6ZaDU=; l=271; h=From:To:CC:Date:References:In-Reply-To:From; b=ZcyS/ewhN9gn8+WZp4TTGQdIj+5RqmDMtzQZoIlcXbsw82qE0oGrofbW9JiTEFkQe dDiN16/TuUp9+68oACgNVckFN5dGpMMvSNZooBsquBhDL+QTLJsq+evU8FJji+1fPp 0+zPqVpv+kG0//XhoKtmyoEy9gEvJVLvW+xHB7F0= Received: from email.msg.corp.akamai.com (ecp.msg.corp.akamai.com [172.27.123.34]) by prod-mail-relay11.akamai.com (Postfix) with ESMTP id DB09E1FC94; Wed, 20 Apr 2016 11:27:01 +0000 (GMT) Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb2.msg.corp.akamai.com (172.27.123.102) with Microsoft SMTP Server (TLS) id 15.0.1130.7; Wed, 20 Apr 2016 07:27:01 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1130.005; Wed, 20 Apr 2016 07:27:00 -0400 From: "Salz, Rich" To: "Paterson, Kenny" , Daniel Kahn Gillmor , "cfrg@ietf.org" , "draft-irtf-cfrg-eddsa.all@ietf.org" Thread-Topic: draft-irtf-cfrg-eddsa -- one final proposal for domain separation (context labels) for ed25519 Thread-Index: AQHRmuDTKGniidh4CkS+OmW+eFDFMZ+SuPhg Date: Wed, 20 Apr 2016 11:27:00 +0000 Message-ID: <11c960b5f1fa42aaaf4cd0a6961332ec@usma1ex-dag1mb1.msg.corp.akamai.com> References: <87bn543id1.fsf@alice.fifthhorseman.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.32.81] Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: =?iso-8859-2?Q?Ond=F8ej_Sur=FD?= , Robert Edmonds , "Kaduk, Ben" , Martin Thomson Subject: Re: [Cfrg] draft-irtf-cfrg-eddsa -- one final proposal for domain separation (context labels) for ed25519 X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2016 11:27:04 -0000 This is okay with me, except for one pedantic clarification. "Empty string= " has a specific meaning in C, it's a single NUL byte. Since our other use= s of context including the NUL terminator, to avoid prefix attacks, then I = think the wording needs some editing. From nobody Wed Apr 20 05:51:27 2016 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E666612E23C; Wed, 20 Apr 2016 05:51:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Nw6SreXPtkg; Wed, 20 Apr 2016 05:51:24 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [162.247.75.118]) by ietfa.amsl.com (Postfix) with ESMTP id C92BC12E19D; Wed, 20 Apr 2016 05:51:24 -0700 (PDT) Received: from fifthhorseman.net (ool-6c3a0662.static.optonline.net [108.58.6.98]) by che.mayfirst.org (Postfix) with ESMTPSA id 80B32F991; Wed, 20 Apr 2016 08:51:22 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id 5EF7D1FF0B; Wed, 20 Apr 2016 08:51:22 -0400 (EDT) From: Daniel Kahn Gillmor To: "Salz\, Rich" , "Paterson\, Kenny" , "cfrg\@ietf.org" , "draft-irtf-cfrg-eddsa.all\@ietf.org" In-Reply-To: <11c960b5f1fa42aaaf4cd0a6961332ec@usma1ex-dag1mb1.msg.corp.akamai.com> References: <87bn543id1.fsf@alice.fifthhorseman.net> <11c960b5f1fa42aaaf4cd0a6961332ec@usma1ex-dag1mb1.msg.corp.akamai.com> User-Agent: Notmuch/0.21+128~g620f892 (http://notmuchmail.org) Emacs/24.5.1 (x86_64-pc-linux-gnu) Date: Wed, 20 Apr 2016 08:51:22 -0400 Message-ID: <87ziso1m0l.fsf@alice.fifthhorseman.net> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Cc: =?utf-8?B?T25kxZllaiBTdXLDvQ==?= , Robert Edmonds , "Kaduk, Ben" , Martin Thomson Subject: Re: [Cfrg] draft-irtf-cfrg-eddsa -- one final proposal for domain separation (context labels) for ed25519 X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2016 12:51:26 -0000 On Wed 2016-04-20 07:27:00 -0400, Salz, Rich wrote: > This is okay with me, except for one pedantic clarification. "Empty > string" has a specific meaning in C, it's a single NUL byte. Since > our other uses of context including the NUL terminator, to avoid > prefix attacks, then I think the wording needs some editing. the "empty string" message in my message was not part of the proposed wording change to the draft, but i can see how it might be confusing if it were to make it into an edit. If we need additional clarification in the draft to avoid confusion, i propose: If no context label is supplied, it is treated as an octet string of zero length; that is, (context || x) is the same as x. Regards, --dkg From nobody Wed Apr 20 06:00:03 2016 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B748012B055; Wed, 20 Apr 2016 06:00:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.697 X-Spam-Level: X-Spam-Status: No, score=-3.697 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NrKPT7a2xmy3; Wed, 20 Apr 2016 06:00:00 -0700 (PDT) Received: from prod-mail-xrelay08.akamai.com (prod-mail-xrelay08.akamai.com [96.6.114.112]) by ietfa.amsl.com (Postfix) with ESMTP id 8D36112D644; Wed, 20 Apr 2016 06:00:00 -0700 (PDT) Received: from prod-mail-xrelay08.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id D76A9200030; Wed, 20 Apr 2016 12:59:59 +0000 (GMT) Received: from prod-mail-relay09.akamai.com (prod-mail-relay09.akamai.com [172.27.22.68]) by prod-mail-xrelay08.akamai.com (Postfix) with ESMTP id C1A24200025; Wed, 20 Apr 2016 12:59:59 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1461157199; bh=etQod02SGueFLPeJ4aRYfYrgla0rz6PCDj69V98WAFw=; l=149; h=From:To:CC:Date:References:In-Reply-To:From; b=ySJFXr6jsORvitnedsRF2OnMiLi1ZrgtmgqyTv8YNzSNuwLQ9ufn5eAoip9ZHM/YA +f3bi2kPpXCfHjTEGH8Ih0ormYIApGC9X4HuvovBbDHdqSX19jRFgtzNYWkflf8YP9 xHl/iKCQTwUDlxx/sFxeJAtGdEzXaar1Mpdl9UZw= Received: from email.msg.corp.akamai.com (usma1ex-cas1.msg.corp.akamai.com [172.27.123.30]) by prod-mail-relay09.akamai.com (Postfix) with ESMTP id A93B41E07C; Wed, 20 Apr 2016 12:59:59 +0000 (GMT) Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb2.msg.corp.akamai.com (172.27.123.102) with Microsoft SMTP Server (TLS) id 15.0.1130.7; Wed, 20 Apr 2016 08:59:58 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1130.005; Wed, 20 Apr 2016 08:59:59 -0400 From: "Salz, Rich" To: Daniel Kahn Gillmor , "Paterson, Kenny" , "cfrg@ietf.org" , "draft-irtf-cfrg-eddsa.all@ietf.org" Thread-Topic: draft-irtf-cfrg-eddsa -- one final proposal for domain separation (context labels) for ed25519 Thread-Index: AQHRmuDTKGniidh4CkS+OmW+eFDFMZ+SuPhggABbAgD//79IgA== Date: Wed, 20 Apr 2016 12:59:58 +0000 Message-ID: References: <87bn543id1.fsf@alice.fifthhorseman.net> <11c960b5f1fa42aaaf4cd0a6961332ec@usma1ex-dag1mb1.msg.corp.akamai.com> <87ziso1m0l.fsf@alice.fifthhorseman.net> In-Reply-To: <87ziso1m0l.fsf@alice.fifthhorseman.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.32.81] Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: =?iso-8859-2?Q?Ond=F8ej_Sur=FD?= , Robert Edmonds , "Kaduk, Ben" , Martin Thomson Subject: Re: [Cfrg] draft-irtf-cfrg-eddsa -- one final proposal for domain separation (context labels) for ed25519 X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2016 13:00:02 -0000 > If no context label is supplied, it is treated as an octet string of > zero length; that is, (context || x) is the same as x. Works for me! From nobody Wed Apr 20 07:30:04 2016 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A470E12D9CC; Wed, 20 Apr 2016 07:30:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.896 X-Spam-Level: X-Spam-Status: No, score=-2.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.996] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o_viQEA2BRj7; Wed, 20 Apr 2016 07:29:58 -0700 (PDT) Received: from welho-filter4.welho.com (welho-filter4.welho.com [83.102.41.26]) by ietfa.amsl.com (Postfix) with ESMTP id A010212D991; Wed, 20 Apr 2016 07:29:58 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter4.welho.com (Postfix) with ESMTP id EFE1B4F8B; Wed, 20 Apr 2016 17:29:56 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp3.welho.com ([IPv6:::ffff:83.102.41.86]) by localhost (welho-filter4.welho.com [::ffff:83.102.41.26]) (amavisd-new, port 10024) with ESMTP id BWwH54jAJMNf; Wed, 20 Apr 2016 17:29:56 +0300 (EEST) Received: from LK-Perkele-V2 (87-100-143-35.bb.dnainternet.fi [87.100.143.35]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp3.welho.com (Postfix) with ESMTPSA id A82D52310; Wed, 20 Apr 2016 17:29:56 +0300 (EEST) Date: Wed, 20 Apr 2016 17:29:53 +0300 From: Ilari Liusvaara To: Daniel Kahn Gillmor Message-ID: <20160420142953.GA23528@LK-Perkele-V2.elisa-laajakaista.fi> References: <87bn543id1.fsf@alice.fifthhorseman.net> <11c960b5f1fa42aaaf4cd0a6961332ec@usma1ex-dag1mb1.msg.corp.akamai.com> <87ziso1m0l.fsf@alice.fifthhorseman.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <87ziso1m0l.fsf@alice.fifthhorseman.net> User-Agent: Mutt/1.5.24 (2015-08-30) Sender: ilariliusvaara@welho.com Archived-At: Cc: Robert Edmonds , "draft-irtf-cfrg-eddsa.all@ietf.org" , "cfrg@ietf.org" , =?utf-8?B?T25kxZllaiBTdXLDvQ==?= , "Kaduk, Ben" , Martin Thomson Subject: Re: [Cfrg] draft-irtf-cfrg-eddsa -- one final proposal for domain separation (context labels) for ed25519 X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2016 14:30:01 -0000 On Wed, Apr 20, 2016 at 08:51:22AM -0400, Daniel Kahn Gillmor wrote: > On Wed 2016-04-20 07:27:00 -0400, Salz, Rich wrote: > > This is okay with me, except for one pedantic clarification. "Empty > > string" has a specific meaning in C, it's a single NUL byte. Since > > our other uses of context including the NUL terminator, to avoid > > prefix attacks, then I think the wording needs some editing. Eh, I thought the other uses had length prefixing to avoid prefix attacks? > the "empty string" message in my message was not part of the proposed > wording change to the draft, but i can see how it might be confusing if > it were to make it into an edit. > > If we need additional clarification in the draft to avoid confusion, i > propose: > > If no context label is supplied, it is treated as an octet string of > zero length; that is, (context || x) is the same as x. Also, anyone up to some quick analysis to show that doesn't interact harmfully with Ed25519 when using the same keys? Also, that wouldn't solve the troublesome interaction between Ed25519 and Ed25519ph... -Ilari From nobody Wed Apr 20 08:57:41 2016 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0328F12D688; Wed, 20 Apr 2016 08:57:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oYvgEK50NJUx; Wed, 20 Apr 2016 08:57:39 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [162.247.75.118]) by ietfa.amsl.com (Postfix) with ESMTP id AEF7012D528; Wed, 20 Apr 2016 08:57:39 -0700 (PDT) Received: from fifthhorseman.net (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id AE085F991; Wed, 20 Apr 2016 11:57:36 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id 532911FF1D; Wed, 20 Apr 2016 11:57:36 -0400 (EDT) From: Daniel Kahn Gillmor To: Ilari Liusvaara In-Reply-To: <20160420142953.GA23528@LK-Perkele-V2.elisa-laajakaista.fi> References: <87bn543id1.fsf@alice.fifthhorseman.net> <11c960b5f1fa42aaaf4cd0a6961332ec@usma1ex-dag1mb1.msg.corp.akamai.com> <87ziso1m0l.fsf@alice.fifthhorseman.net> <20160420142953.GA23528@LK-Perkele-V2.elisa-laajakaista.fi> User-Agent: Notmuch/0.21+128~g620f892 (http://notmuchmail.org) Emacs/24.5.1 (x86_64-pc-linux-gnu) Date: Wed, 20 Apr 2016 11:57:36 -0400 Message-ID: <87potk1de7.fsf@alice.fifthhorseman.net> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Cc: Robert Edmonds , "draft-irtf-cfrg-eddsa.all@ietf.org" , "cfrg@ietf.org" , =?utf-8?B?T25kxZllaiBTdXLDvQ==?= , "Kaduk, Ben" , Martin Thomson Subject: Re: [Cfrg] draft-irtf-cfrg-eddsa -- one final proposal for domain separation (context labels) for ed25519 X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2016 15:57:41 -0000 On Wed 2016-04-20 10:29:53 -0400, Ilari Liusvaara wrote: > On Wed, Apr 20, 2016 at 08:51:22AM -0400, Daniel Kahn Gillmor wrote: >> On Wed 2016-04-20 07:27:00 -0400, Salz, Rich wrote: >> > This is okay with me, except for one pedantic clarification. "Empty >> > string" has a specific meaning in C, it's a single NUL byte. Since >> > our other uses of context including the NUL terminator, to avoid >> > prefix attacks, then I think the wording needs some editing. > > Eh, I thought the other uses had length prefixing to avoid prefix attacks? they do, but we can't have that while still preserving backward compatibility with the deployed implementations of ed25519, and while making it relatively easy to use with ed25519 libraries that don't offer explicit contexts. If you wanted to do a length-prefixed context, but apply it only in the case where the context exists (has non-zero length), that's another option that would preserve backward compatibility with the deployed base. But i think that's marginally more complicated to reason about and to implement, and it still doesn't address the potential for collision between contextualized and context-free domains, so i'm not sure what we'd gain. >> the "empty string" message in my message was not part of the proposed >> wording change to the draft, but i can see how it might be confusing if >> it were to make it into an edit. >> >> If we need additional clarification in the draft to avoid confusion, i >> propose: >> >> If no context label is supplied, it is treated as an octet string of >> zero length; that is, (context || x) is the same as x. > > Also, anyone up to some quick analysis to show that doesn't interact > harmfully with Ed25519 when using the same keys? eh? this is specifically and only about how to apply a context label in Ed25519 and Ed25519ph, since it's already defined for Ed448 -- what do you mean "interact harmfully with Ed25519" ? > Also, that wouldn't solve the troublesome interaction between Ed25519 > and Ed25519ph... That's true, this proposal doesn't try to solve that problem. I hope it can be evaluated independently. --dkg From nobody Wed Apr 20 08:59:21 2016 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FE4B12D0A9 for ; Wed, 20 Apr 2016 08:59:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.4 X-Spam-Level: X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dpXWFM1ZjxAC for ; Wed, 20 Apr 2016 08:59:18 -0700 (PDT) Received: from mail-io0-x233.google.com (mail-io0-x233.google.com [IPv6:2607:f8b0:4001:c06::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 85E7812D1BE for ; Wed, 20 Apr 2016 08:59:18 -0700 (PDT) Received: by mail-io0-x233.google.com with SMTP id 2so56929812ioy.1 for ; Wed, 20 Apr 2016 08:59:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-transfer-encoding; bh=TtSAEZD3EgmZBnwIL54K5/rN4v80y0UBpQNgUtdTFwk=; b=l7NgnkH0MO4jbgcqA/bWfERz4umkEJCfbXk0EZ4sFpBnLpiK5wVXuZt7ICQFYfocGs hj74mqGRDDs8ulgJg8ocCK+F1UkVD0ib3csBY/xyPqLDtTbXYbzOVQIbxKGbNkgV9yOa /OGlDqFoOP3ov4I2D8/7pg1SKGK+uB3v4vC08bG3wZk/tdXLls6rrx4KTdpB6An7F4Wr s+WaELJABvPGeJVkzTvdWtC8/mJmg3skhkgN5NpgAbB9NUtmeiBWQ9bbDJT62JeRPLTu JQZZsJTPjSALUS1zymYL1f7OGQVhMHqez41F4JsxwxqFvzWxgObopoMNtyyNdMxPV98Z 686g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc:content-transfer-encoding; bh=TtSAEZD3EgmZBnwIL54K5/rN4v80y0UBpQNgUtdTFwk=; b=Wr8ePBr3szN7pkmtTo3XKowRBn8fx3ICxaJfi6qRNnWxDRHZ1JLI44hkzapRJnPQtC EtrEjPl3BQ4WtwBWSvNHLenvc92DaxHzFS3dgudCdUkd4J4kv3L1BXMYCnTmUh9cVIBN m7Jjl4w73lSO90fTuEB7HN4i+4fBHzDyytmCQB0qfOF4Xw9zaW8BihspQt6bHYQUwaGo zNVSGGi7Ms270ktbzZ6jddm6/+yLDByCgAjISftGM7/BsR1YfsUT3SxLJY24MRHgtVoM Kj2rEOnFYuKUngpB7LmQ9Na4YhGnAU/NHgrO9ZLqmB06CoTL5h3rtA3OAFSSUpH6HLeW tQsA== X-Gm-Message-State: AOPr4FWoglhdsLVHWxb1l6K6C/lHjuv0Yamv221IxsDXjj2Zg69O94yQApUNG8Ud/Q1tf5CdT5BGD/xSxzhUAA== MIME-Version: 1.0 X-Received: by 10.107.184.8 with SMTP id i8mr10692906iof.96.1461167957763; Wed, 20 Apr 2016 08:59:17 -0700 (PDT) Sender: alangley@gmail.com Received: by 10.79.117.133 with HTTP; Wed, 20 Apr 2016 08:59:17 -0700 (PDT) In-Reply-To: References: <57148B14.7020507@azet.sk> <20160420021208.5285C6031B@jupiter.mumble.net> Date: Wed, 20 Apr 2016 08:59:17 -0700 X-Google-Sender-Auth: T7oxr64DYNlltvB7K4aUV_6bJLo Message-ID: From: Adam Langley To: Thomas Peyrin Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "cfrg@irtf.org" Subject: Re: [Cfrg] Adopting "AES-GCM-SIV: Nonce Misuse-Resistant Authenticated Encryption" as a CFRG document ---- Some clarifications X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2016 15:59:20 -0000 On Wed, Apr 20, 2016 at 2:04 AM, Thomas Peyrin wr= ote: > I understand the explanations for the first point (considering an AEAD no= w > doesn't preclude from having CAESAR candidates later as well), but I don'= t > understand for the second point. Why do we need to wait for the end of > CAESAR competition before considering CAESAR candidates instead of > AES-GCM-SIV ? I believe we should at least take a short look at the curre= nt > algorithms available now, and not only AES-GCM-SIV ? Many CAESAR candidates may be "better designed" in the same way that XSalsa20-Poly1305 is, in some sense, "better designed" than AES-GCM-SIV: i.e. it uses operations that are independently useful on CPUs and so more performant (with fewer tricks) than the binary fields of AES and GHASH/POLYVAL. But dedicated hardware for AES-GCM is now fairly common in many environments and it's very hard for anything to beat the performance and power efficiency of this dedicated hardware. (Which seems a little like cheating, but that's where we are.) Thus AES-GCM is the default for encrypting large amounts of data. But in situations where a counter nonce isn't possible a significant amount of worry has to go into convincing ourselves that a duplicate nonce isn't possible. So what we want is AES-GCM=E2=80=94but with less worr= y. Same underlying primitives, basically the same speed, same API, but no detonation if nonce uniqueness slips for some crazy reason. Since this is so so closely related to AES-GCM, I don't think that volumes of analysis can be directly compared with CAESAR candidates: AES is nearly axiomatic now and so doesn't need the sorts of analysis that something like NORX warrants. I know that some CAESAR candidates are based around AES for this reason and in order to take advantage of hardware support. If you have one in mind then it should be considered, but I believe that AES-GCM-SIV is very useful as a tweak of AES-GCM and I'm not sure what an alternative would usefully provide without venturing into being "more exciting". I would like CAESAR to produce a primitive that provides cool features like AEZ's (any maybe other's) arbitrary block size. But, for now, I would welcome a slightly more robust AES-GCM. Cheers AGL From nobody Wed Apr 20 09:26:07 2016 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE9B112E996 for ; Wed, 20 Apr 2016 09:26:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.193 X-Spam-Level: X-Spam-Status: No, score=-5.193 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.996, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2-zsc-pMK9KB for ; Wed, 20 Apr 2016 09:26:01 -0700 (PDT) Received: from llmx2.ll.mit.edu (LLMX2.LL.MIT.EDU [129.55.12.48]) by ietfa.amsl.com (Postfix) with ESMTP id 27BAE12E993 for ; Wed, 20 Apr 2016 09:26:00 -0700 (PDT) Received: from LLE2K10-HUB01.mitll.ad.local (LLE2K10-HUB01.mitll.ad.local) by llmx2.ll.mit.edu (unknown) with ESMTP id u3KGOVkG010127; Wed, 20 Apr 2016 12:24:31 -0400 From: "Blumenthal, Uri - 0553 - MITLL" To: Thomas Peyrin , "Paterson, Kenny" Thread-Topic: [Cfrg] Adopting "AES-GCM-SIV: Nonce Misuse-Resistant Authenticated Encryption" as a CFRG document ---- Some clarifications Thread-Index: AQHRmqo+cBDJFfpWREmYbD5sdatNi5+SzYgAgAAHcoCAADhKgA== Date: Wed, 20 Apr 2016 16:25:59 +0000 Message-ID: References: <57148B14.7020507@azet.sk> <20160420021208.5285C6031B@jupiter.mumble.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.2.160219 x-originating-ip: [172.25.177.156] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha384; boundary="B_3543999949_156929" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-04-20_11:, , signatures=0 X-Proofpoint-Spam-Details: rule=inbound_notspam policy=inbound score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1603290000 definitions=main-1604200263 Archived-At: Cc: "cfrg@irtf.org" Subject: Re: [Cfrg] Adopting "AES-GCM-SIV: Nonce Misuse-Resistant Authenticated Encryption" as a CFRG document ---- Some clarifications X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2016 16:26:04 -0000 --B_3543999949_156929 Content-type: multipart/alternative; boundary="B_3543999949_153074" --B_3543999949_153074 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable > Sorry to continue this discussion, but I'm still dubious on the considera= tion > of AES-GCM-SIV. I think there are two questions here: > - the first one is why do we need to push an AEAD now, while the CAESAR > competition will lead to a selected portfolio in a few years ? Because we don=E2=80=99t want to wait for =E2=80=9Ca few years=E2=80=9D. > - the second is if we really want to have an AEAD now, why looking at > AES-GCM-SIV only, while there are candidates from the CAESAR competitions > (that have probably been much more analysed than AES-GCM-SIV and thus pre= sent > a direct important advantage) ? I doubt the other candidates have been =E2=80=9Cmuch more analysed=E2=80=9D. Also, (a)= I=E2=80=99m happy with the analysis that accompanies AES-GCM-SIV, and (b) I=E2=80=99m well-aw= are of the limitations of =E2=80=9Csecurity proofs=E2=80=9D that more and more algorithms a= re coming with nowadays. But if you see a problem with GCM-SIV security proofs (or assumptions they=E2=80=99re based on), by all means speak up. > Why do we need to wait for the end of CAESAR competition before consideri= ng > CAESAR candidates instead of AES-GCM-SIV ? I believe we should at least t= ake a > short look at the current algorithms available now, and not only AES-GCM-= SIV ? Fine with me. Take a short look and write a draft for another algorithm. Explaining what properties you need that are missing in GCM-SIV would be nice too. --B_3543999949_153074 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable
S= orry to continue this discussion, but I'm still dubious on the consideration= of AES-GCM-SIV. I think there are two questions here:
- = the first one is why do we need to push an AEAD now, while the CAESAR compet= ition will lead to a selected portfolio in a few years ?

Because we don’t wan= t to wait for “a few years”.

- the second is if we really want to have a= n AEAD now, why looking at AES-GCM-SIV only, while there are candidates from= the CAESAR competitions (that have probably been much more analysed than AE= S-GCM-SIV and thus present a direct important advantage) ?

I d= oubt the other candidates have been “much more analysed”.  = Also, (a) I’m happy with the analysis that accompanies AES-GCM-SIV, an= d (b) I’m well-aware of the limitations of “security proofs̶= 1; that more and more algorithms are coming with nowadays.

But if you see a problem with GCM-SIV security proofs (or assumption= s they’re based on), by all means speak up.

Why do we need to wait for the end of CAESAR competiti= on before considering CAESAR candidates instead of AES-GCM-SIV ? I believe we should at least ta= ke a short look at the current algorithms available now, and not only AES-GC= M-SIV ?

Fine with m= e. Take a short look and write a draft for another algorithm. Explaining wha= t properties you need that are missing  in GCM-SIV would be nice too. --B_3543999949_153074-- --B_3543999949_156929 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIQ4AYJKoZIhvcNAQcCoIIQ0TCCEM0CAQExDzANBglghkgBZQMEAgIFADALBgkqhkiG9w0B BwGggg6fMIIE6jCCA9KgAwIBAgIKMztKZQAAAABumTANBgkqhkiG9w0BAQsFADBRMQswCQYD VQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJ MRMwEQYDVQQDEwpNSVRMTCBDQS0zMB4XDTE2MDExNDE3MzMzN1oXDTE5MDExMzE3MzMzN1ow YTELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDzANBgNV BAsTBlBlb3BsZTEgMB4GA1UEAxMXQmx1bWVudGhhbC5VcmkuNTAwMTA1ODQwggEiMA0GCSqG SIb3DQEBAQUAA4IBDwAwggEKAoIBAQDqifs8K0OoodbmOo5G/j2+p2ibbOsEoJ9GJjK8K1Iw 6iig59a3EuNB6NR4tAR3INwjjUwMCa4o8ysnk1hN32B3HPrK5Z8++Y/xcX5iP1L6fc51YQ5C /EGvrSbjuPLvt19SNfVdwcuoc842Sgk9N/HemdwmvcqJkwzWDsuxKikI2clT1N5LTAaPMkhr HVuYOHBE0mCXjHjFnYuHsEXyVvUZLxziDgduV9WKbC90Z1NZMXB6ZeQTACUWgMfpFrE12LKb fvOmxepCBfCPbGB3ZyG+FaUdtQoCEAbGTnY7nCedQFn7pV1hppCt4jjLVlOpgYc3dPmyiXsL nhDQZ5ptmks/AgMBAAGjggGyMIIBrjAdBgNVHQ4EFgQUiXqPublGfd0sWKNk/BObT6Oorzgw DgYDVR0PAQH/BAQDAgbAMB8GA1UdIwQYMBaAFNdgZg57SY11TA39z0beyMcSh8q/MDMGA1Ud HwQsMCowKKAmoCSGImh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXRjcmwvTExDQTMwZgYIKwYB BQUHAQEEWjBYMC0GCCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8vTExD QTMwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLmxsLm1pdC5lZHUvb2NzcDA9BgkrBgEEAYI3 FQcEMDAuBiYrBgEEAYI3FQiDg+Udh+ynZoathxWD6vBFhbahHx2Fy94yh/+KcwIBZAIBBjAi BgNVHSUBAf8EGDAWBggrBgEFBQcDBAYKKwYBBAGCNwoDDDAYBgNVHSAEETAPMA0GCyqGSIb3 EgIBAwEIMBkGA1UdEQQSMBCBDnVyaUBsbC5taXQuZWR1MCcGCSsGAQQBgjcUAgQaHhgATABM AFUAcwBlAHIAUwBpAGcALQBTAFcwDQYJKoZIhvcNAQELBQADggEBAK7HM6o1IolvkCJrlsjj N1+0Z2JG8anwkHkVKAg/K9qUD0LE9zbnK3kZRGZsljJUDG+hMWmTWCkx0TTzbg/BeVrypVPD 7rn1Tagi9QBV2eJhdBZRHWOcsteRldUukKbMw74hkNGH9o/p/FFZYMA0kHnA7XfECilF9Yl6 uKDv1lbjuWdgcKD1FdEj7rL/IdX0wKJVUKjwLG1RQZel1nuwyRjVtXWz8IUMJXRsYHf6uSzy YoNBeZuWyMx/J5c0ACKXXs1O721GPJ5U5gcEaQ/b8lwQGcOgPk28RPwgiBF3f5TgrTa7QxGf ozmNsTj1OV1vU0vjqKrg7USi9q0xTdGUIyowggS8MIIDpKADAgECAgEpMA0GCSqGSIb3DQEB BQUAMFQxCzAJBgNVBAYTAlVTMR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQww CgYDVQQLEwNQS0kxFjAUBgNVBAMTDU1JVExMIFJvb3QgQ0EwHhcNMTMxMjE3MDAwMDAwWhcN MjAxMjMxMjM1OTU5WjBRMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFi b3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBDQS0zMIIBIjANBgkqhkiG 9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2jBSdW18tuW1tNxG6h8B0kqckFZQAAtoHCkvUpUEX6jF vBd8mQI53GyLYRuAo4HWJpe7/izFXOfSJDs6UM5ovvCOfXg2bJgDYlBC9JDcLBFIn0nppOu9 RvpjWSixtC56crwJ5Us5QPdtxtKdek5LJXl2oKw3w8lihUixePbxWad1m7ZMKKagvm9zTybP 6FumKRxeYJjSpB2+cAYjoGGEbSVHyx8uzHm6xAoBMHxa8by+yDz8Jzk6sP9iilgP3iXSGoCA mhyBzvlQQ5QNNWP+Emo9jz/ukKhYVB/VwdxtoquPAqn4ifDAIaM9dtb05cy1gXAFSP3Z/iUk xyBZZUORfwIDAQABo4IBmjCCAZYwEgYDVR0TAQH/BAgwBgEB/wIBADAdBgNVHQ4EFgQU12Bm DntJjXVMDf3PRt7IxxKHyr8wHwYDVR0jBBgwFoAUZ6p6z/QKprlytYqg0p3yEMND7SkwDgYD VR0PAQH/BAQDAgGGMGYGCCsGAQUFBwEBBFowWDAtBggrBgEFBQcwAoYhaHR0cDovL2NybC5s bC5taXQuZWR1L2dldHRvP0xMUkNBMCcGCCsGAQUFBzABhhtodHRwOi8vb2NzcC5sbC5taXQu ZWR1L29jc3AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC5sbC5taXQuZWR1L2dldGNy bD9MTFJDQTCBkgYDVR0gBIGKMIGHMA0GCyqGSIb3EgIBAwEGMA0GCyqGSIb3EgIBAwEIMA0G CyqGSIb3EgIBAwEHMA0GCyqGSIb3EgIBAwEJMA0GCyqGSIb3EgIBAwEKMA0GCyqGSIb3EgIB AwELMA0GCyqGSIb3EgIBAwEOMA0GCyqGSIb3EgIBAwEPMA0GCyqGSIb3EgIBAwEQMA0GCSqG SIb3DQEBBQUAA4IBAQAsf9HBn72qU7UTgkxarjAc7iynhcDEgWwezYKtd/SLGSQ0DhtzIV/L TCxqULjOd+H+HTqMJXB8+nHnzhyqQ43RsnGZOFT5RfzPh94db/ZJ3ql244DwlJI7yXBA2DkZ cEEgOWC9bHcrElzU6NnigahSW5odVJrhmH/XhQAcMS77E5H62yyxK1WPPgcBipGVnu1xSHbT iHe7DqfWQ2tVMLUf23XYhIua94kJsQd4jSh71NVD0e7F4snAoqQMI98MzDYeLOkjlzKRs77r /aMsPAKx6nMaOvRL7Cy0Pjp51i2qFkbGmX8ofnh2kerjTTvRJ/g22r1MV8RR1PktjMsNOsPf MIIE7TCCA9WgAwIBAgIKMziUjwAAAABuljANBgkqhkiG9w0BAQsFADBRMQswCQYDVQQGEwJV UzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYD VQQDEwpNSVRMTCBDQS0zMB4XDTE2MDExNDE3MzAzOVoXDTE5MDExMzE3MzAzOVowYTELMAkG A1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDzANBgNVBAsTBlBl b3BsZTEgMB4GA1UEAxMXQmx1bWVudGhhbC5VcmkuNTAwMTA1ODQwggEiMA0GCSqGSIb3DQEB AQUAA4IBDwAwggEKAoIBAQDjFDaGib07mHBdNaVMNpj9+4iJa+K9AcTN3y+iU1ygtvHG4cot eDBf77ZN1uwdt+lodW0C8XyG43suSfpNp/owLOUElFagAnPqHAvAUIwsl5AjzncpJP+78Ui4 u34aMNsddP+QZu9HI2Qg+P6eMD25jkjybT9dQMxXZpO2oTBznlWjYIItdZhK1DWZqIR0at7n 2YjCSQsZNX0lJ4JwrtjHYFrYPnnZC0f1B2M7V54IS863CEyfu5XotoZx8YuHwYpKSFq80SEh 6cMDLdTe1ZAjWxsnbyKC64rreStyI2PVN9uBWd+OleGoIAjVogpMKKi0pSRHcCuwDwGekpQV ubK9AgMBAAGjggG1MIIBsTAdBgNVHQ4EFgQU8U/FiJmibLZl2+KcNbVWE2PZipswDgYDVR0P AQH/BAQDAgUgMB8GA1UdIwQYMBaAFNdgZg57SY11TA39z0beyMcSh8q/MDMGA1UdHwQsMCow KKAmoCSGImh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXRjcmwvTExDQTMwZgYIKwYBBQUHAQEE WjBYMC0GCCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8vTExDQTMwJwYI KwYBBQUHMAGGG2h0dHA6Ly9vY3NwLmxsLm1pdC5lZHUvb2NzcDA9BgkrBgEEAYI3FQcEMDAu BiYrBgEEAYI3FQiDg+Udh+ynZoathxWD6vBFhbahHx2F69Bwg+vtIAIBZAIBBTAlBgNVHSUE HjAcBgRVHSUABggrBgEFBQcDBAYKKwYBBAGCNwoDBDAYBgNVHSAEETAPMA0GCyqGSIb3EgIB AwEIMBkGA1UdEQQSMBCBDnVyaUBsbC5taXQuZWR1MCcGCSsGAQQBgjcUAgQaHhgATABMAFUA cwBlAHIARQBuAGMALQBTAFcwDQYJKoZIhvcNAQELBQADggEBABbuvs9m0gS5U8JJuVc+qttV 2BWQ0jDepXpYfP/xN8rVScRPHe2SMUaFH5OMRhheGJkdogWVNnMrjHxQfpfc0z8yotlD3xwX ENWUY5MoQmpEGB2ksFqgMd121bqzR3WY84Lcosfow0MoplXs8mvO7TnozwM+PtGZs0mpp2Pz BkvWdNbs2r/7wXJP6/pLd5zPvywRNhTgoVe1aN4ivIkU8svkKMggv5ZaOsonaW8JS6dUYmvv k0QvDJRIQNRR0zpQpOKp+4V/XhMZRhxQJ3DjVTjh9Q/pHKm7ARFhFr3QAJ6ocCjyzLF5issa 1Vshx7ElBIk0cXhep6mLMLqGNX3azAkxggIFMIICAQIBATBfMFExCzAJBgNVBAYTAlVTMR8w HQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxEzARBgNVBAMT Ck1JVExMIENBLTMCCjM7SmUAAAAAbpkwDQYJYIZIAWUDBAICBQCgeTA/BgkqhkiG9w0BCQQx MgQwgQDxoeR6Jvwdri5ATH1Nx/xgn81GSDOqUNB/q6vbFrhLztJaLGEi/hwUEVpsKF3fMBgG CSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE2MDQyMDE2MjU0OVow DQYJKoZIhvcNAQEBBQAEggEA427ESowCFbEzlj0ExmNH//393dEHfdVyPZAnnC9TeW3g/Xq5 cpxquQfv8C57TWZl0bqOm/SYZmCreIfxTLaRh+JYkAr2KumA5OxAr9R+B5BhaAA0gDbY1dnv q+Ky7MzIIy3SQBM9+VWDzN06mxtvaBhctdXqBFv/nPTTG+2j6pVRj66B+Nf7okszrDOb/dzs lm1Y1C+zdGZ6bYIBfkb436OISAcZ5QspxdI3dRt8DpCb7hnEVVVCIpeTIy10H38a/opo5tzI ntcQyt+4s/8sp162tWiOKMtoOB9uOlqnDJHOXd97jSNqYtLaazwybmyVixUC97pzch7R3ivD 6/0lfA== --B_3543999949_156929-- From nobody Wed Apr 20 09:35:32 2016 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49FEF12EA44 for ; Wed, 20 Apr 2016 09:35:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L6ZBk68gpPGm for ; Wed, 20 Apr 2016 09:35:29 -0700 (PDT) Received: from mail-io0-x229.google.com (mail-io0-x229.google.com [IPv6:2607:f8b0:4001:c06::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D9AF12E970 for ; Wed, 20 Apr 2016 09:35:29 -0700 (PDT) Received: by mail-io0-x229.google.com with SMTP id g185so58037358ioa.2 for ; Wed, 20 Apr 2016 09:35:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=7pHjrlHr9gMasOxXQqzSS4tHM6TWLv3gfxAyIfXYlG8=; b=jL/p5d1EhspyXLjRanYlq236s6Sjs9yfrXnSknrqFSxQ1s/r+R1in+t63LSCPwh2t4 MC8xep4Dbf1F1S2v4SC31Y+eFiZxdd1IJwHmwdWrREE3bx/xgWV6JmEXSJg+0XtktXPD jfqoiO543Naz09Zs0+fnCYWkes7Zsn1oP0fnYwiZY8m9fo1zPq7Udo0YP4hVtmC+NAA5 wMaSIMMoFeKjE/zQ1qlxk+V/2BFqc9icD2qfhqtNDA32vW0fYZ8o0Fj2zS905SGIHxj/ JnSPNJe4xh95XEhOA/pU9XM3Y5GnhUpIHPnx1h0OgFxi3pqdU6LUu9zsrodkbDLeVRxo wjYQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=7pHjrlHr9gMasOxXQqzSS4tHM6TWLv3gfxAyIfXYlG8=; b=IAIkw3cg8vzX2dy9c+kGSCI1l0hIdhey2v5PJNhhgbPSBR3IFZ/5CG2U9xuTqF5Dpg rpjNEn+dcqlHsrVaeAkHO7OoFQuFvbtyaiyZmFOpD9Ui/Jxm5OxiyhCDpBKLIWQZtx9z 8Ic6RPEtl0rVtwS29c+perOvamYUaibm+C319LjTb7WsfJg3jeTZz/MV8cZBNs42iuJI iP3Y22BYlcAA/3yFfwq3XrKv0GWY9LJEiv0YJwZ+37woerJk6ONqXZzTP84p2OCRKWCx KdsCJtiUIaZ0vVoB6b2q1VWu8o1msKdShUKMwhl1aBhqVOMZ6x5UI1JOmesL0bmuPoKz 5bpw== X-Gm-Message-State: AOPr4FUNA2j8HUpeOogPaxdLwb1JGWzcI3ky5vxYOWtYjGiDOJL4zwT+j4Uyre/bgRwufJPpyy8cs+tORO15XQ== MIME-Version: 1.0 X-Received: by 10.107.168.233 with SMTP id e102mr12411409ioj.55.1461170128513; Wed, 20 Apr 2016 09:35:28 -0700 (PDT) Received: by 10.79.34.161 with HTTP; Wed, 20 Apr 2016 09:35:28 -0700 (PDT) In-Reply-To: References: <57148B14.7020507@azet.sk> <20160420021208.5285C6031B@jupiter.mumble.net> Date: Thu, 21 Apr 2016 00:35:28 +0800 Message-ID: From: Thomas Peyrin To: Adam Langley Content-Type: multipart/alternative; boundary=001a114278d47774810530ed2e57 Archived-At: Cc: "cfrg@irtf.org" Subject: Re: [Cfrg] Adopting "AES-GCM-SIV: Nonce Misuse-Resistant Authenticated Encryption" as a CFRG document ---- Some clarifications X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2016 16:35:31 -0000 --001a114278d47774810530ed2e57 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Indeed, if the goal is to have an AES-based AEAD candidate that offers some kind of misuse resistance, there are quite a few among the CAESAR designs (AEZ being indeed on of them) 2016-04-20 23:59 GMT+08:00 Adam Langley : > On Wed, Apr 20, 2016 at 2:04 AM, Thomas Peyrin > wrote: > > I understand the explanations for the first point (considering an AEAD > now > > doesn't preclude from having CAESAR candidates later as well), but I > don't > > understand for the second point. Why do we need to wait for the end of > > CAESAR competition before considering CAESAR candidates instead of > > AES-GCM-SIV ? I believe we should at least take a short look at the > current > > algorithms available now, and not only AES-GCM-SIV ? > > Many CAESAR candidates may be "better designed" in the same way that > XSalsa20-Poly1305 is, in some sense, "better designed" than > AES-GCM-SIV: i.e. it uses operations that are independently useful on > CPUs and so more performant (with fewer tricks) than the binary fields > of AES and GHASH/POLYVAL. > > But dedicated hardware for AES-GCM is now fairly common in many > environments and it's very hard for anything to beat the performance > and power efficiency of this dedicated hardware. (Which seems a little > like cheating, but that's where we are.) > > Thus AES-GCM is the default for encrypting large amounts of data. But > in situations where a counter nonce isn't possible a significant > amount of worry has to go into convincing ourselves that a duplicate > nonce isn't possible. So what we want is AES-GCM=E2=80=94but with less wo= rry. > Same underlying primitives, basically the same speed, same API, but no > detonation if nonce uniqueness slips for some crazy reason. > > Since this is so so closely related to AES-GCM, I don't think that > volumes of analysis can be directly compared with CAESAR candidates: > AES is nearly axiomatic now and so doesn't need the sorts of analysis > that something like NORX warrants. > > I know that some CAESAR candidates are based around AES for this > reason and in order to take advantage of hardware support. If you have > one in mind then it should be considered, but I believe that > AES-GCM-SIV is very useful as a tweak of AES-GCM and I'm not sure what > an alternative would usefully provide without venturing into being > "more exciting". I would like CAESAR to produce a primitive that > provides cool features like AEZ's (any maybe other's) arbitrary block > size. But, for now, I would welcome a slightly more robust AES-GCM. > > > Cheers > > AGL > --001a114278d47774810530ed2e57 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Indeed, if the goal is to have an AES-based AEAD candidate= that offers some kind of misuse resistance, there are quite a few among th= e CAESAR designs (AEZ being indeed on of them)=C2=A0

2016-04-20 23:59 GMT+08:00 Adam La= ngley <agl@imperialviolet.org>:
On Wed, Apr 20, 2016 at 2:04 AM, Thomas Peyrin = <thomas.peyrin@gmail.com&= gt; wrote:
> I understand the explanations for the first point (considering an AEAD= now
> doesn't preclude from having CAESAR candidates later as well), but= I don't
> understand for the second point. Why do we need to wait for the end of=
> CAESAR competition before considering CAESAR candidates instead of
> AES-GCM-SIV ? I believe we should at least take a short look at the cu= rrent
> algorithms available now, and not only AES-GCM-SIV ?

Many CAESAR candidates may be "better designed" in the sam= e way that
XSalsa20-Poly1305 is, in some sense, "better designed" than
AES-GCM-SIV: i.e. it uses operations that are independently useful on
CPUs and so more performant (with fewer tricks) than the binary fields
of AES and GHASH/POLYVAL.

But dedicated hardware for AES-GCM is now fairly common in many
environments and it's very hard for anything to beat the performance and power efficiency of this dedicated hardware. (Which seems a little
like cheating, but that's where we are.)

Thus AES-GCM is the default for encrypting large amounts of data. But
in situations where a counter nonce isn't possible a significant
amount of worry has to go into convincing ourselves that a duplicate
nonce isn't possible. So what we want is AES-GCM=E2=80=94but with less = worry.
Same underlying primitives, basically the same speed, same API, but no
detonation if nonce uniqueness slips for some crazy reason.

Since this is so so closely related to AES-GCM, I don't think that
volumes of analysis can be directly compared with CAESAR candidates:
AES is nearly axiomatic now and so doesn't need the sorts of analysis that something like NORX warrants.

I know that some CAESAR candidates are based around AES for this
reason and in order to take advantage of hardware support. If you have
one in mind then it should be considered, but I believe that
AES-GCM-SIV is very useful as a tweak of AES-GCM and I'm not sure what<= br> an alternative would usefully provide without venturing into being
"more exciting". I would like CAESAR to produce a primitive that<= br> provides cool features like AEZ's (any maybe other's) arbitrary blo= ck
size. But, for now, I would welcome a slightly more robust AES-GCM.


Cheers

AGL

--001a114278d47774810530ed2e57-- From nobody Wed Apr 20 09:48:29 2016 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE22012E0D5 for ; Wed, 20 Apr 2016 09:48:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4apM_jZ3kGae for ; Wed, 20 Apr 2016 09:48:26 -0700 (PDT) Received: from mail-io0-x229.google.com (mail-io0-x229.google.com [IPv6:2607:f8b0:4001:c06::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D06A12DFE1 for ; Wed, 20 Apr 2016 09:48:26 -0700 (PDT) Received: by mail-io0-x229.google.com with SMTP id g185so58437149ioa.2 for ; Wed, 20 Apr 2016 09:48:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=ap5XJSnmFHOcEVQV6M/mhepVeAxen6rOopcwMFRADj0=; b=z2lDJr6trRd52Dq2hYZpAdJjlED9heKqB5wPT0BN70Z/dS7PJ3ZgGTxM1gdfxdAhCH RBDfGIVS2YikCNB37AUf00u4HxE0FCtF8lMX2GsiwZU7hg1ivWkSGQ42C32yXQdMe1tm Ax6390xBM6S9fKAVMBrkrt9ovygJ/2xBGtHPameU82Q8LtXXzeogbnuL6sIoz7P1PU2H VjdT76fj7zgHxkp/NwD9WFUzyttggIPU3lqEV29hSlVYnAmwVkDUFYVcL61vpUbVSG4k TituZ7emGnTTUOoCgWwXw2GhDoSuzYTCU81r/rtQY5TApzPYigsvvEcrA4rZLQRo7WUA eIVA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=ap5XJSnmFHOcEVQV6M/mhepVeAxen6rOopcwMFRADj0=; b=GEfxA6RCUydA1k9/sIYr1gjP3T8j4TaH+MTFpHp37Iri79cQzTI3Dc6uS0ges30lAO aTdPsLsUSQV+b147/MiryiFMLs63sGnkx57d13tBUsKn4suLCQVw1hSGR0uNWNnlhNUO 4jFpz7+by7jYINGwJU1AVhkxRbg87Uf7NzrSq2Id948k511+ln9y356KoB9a/wfG0qEb MU8SPFEKnXI7MOVTaoRKi731ZckZtmgwA03paGynbO/aj3p5FJk4XsroPc7P1Bz3TqDa T6am2OMR/6W5Ixkr6v4GffXzlKJLTXw6c1D5RhqdogsyP2KRpcTwOXU7Rf8YNZ9y9DVi pX4Q== X-Gm-Message-State: AOPr4FXA5EO6rDV7UPrN1Wd/VyTb7fc/YhoKyy6xGQRozbioAAl/A1ja6Y9m8bKzIdZU9smwltMgPzc+xdPxhQ== MIME-Version: 1.0 X-Received: by 10.107.168.233 with SMTP id e102mr12481416ioj.55.1461170905871; Wed, 20 Apr 2016 09:48:25 -0700 (PDT) Received: by 10.79.34.161 with HTTP; Wed, 20 Apr 2016 09:48:25 -0700 (PDT) In-Reply-To: References: <57148B14.7020507@azet.sk> <20160420021208.5285C6031B@jupiter.mumble.net> Date: Thu, 21 Apr 2016 00:48:25 +0800 Message-ID: From: Thomas Peyrin To: "Blumenthal, Uri - 0553 - MITLL" Content-Type: multipart/alternative; boundary=001a114278d4cd24c90530ed5c0d Archived-At: Cc: "cfrg@irtf.org" Subject: Re: [Cfrg] Adopting "AES-GCM-SIV: Nonce Misuse-Resistant Authenticated Encryption" as a CFRG document ---- Some clarifications X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2016 16:48:27 -0000 --001a114278d4cd24c90530ed5c0d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 2016-04-21 0:25 GMT+08:00 Blumenthal, Uri - 0553 - MITLL : > But if you see a problem with GCM-SIV security proofs (or assumptions > they=E2=80=99re based on), by all means speak up. > > I don't think I have ever said that ? > Fine with me. Take a short look and write a draft for another algorithm. > Explaining what properties you need that are missing in GCM-SIV would be > nice too. > Perhaps before writing a draft for all CAESAR candidates (or even AES-based CAESAR candidates), we could spend a little time discussing what would be the advantages of the various options we have at hand ? I would say for 2nd round AES-based CAESAR candidates that provide some kind of misuse resistance, we should consider AES-COPA, AEZ, Deoxys, ElmD, POET and SHELL (I hope I didn't forget any). Thomas. --001a114278d4cd24c90530ed5c0d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



--001a114278d4cd24c90530ed5c0d-- From nobody Wed Apr 20 11:07:37 2016 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C66912E383; Wed, 20 Apr 2016 11:07:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eFhyh2UISt9U; Wed, 20 Apr 2016 11:07:34 -0700 (PDT) Received: from odin.smetech.net (x-bolt-wan.smeinc.net [209.135.219.146]) by ietfa.amsl.com (Postfix) with ESMTP id 8FC1812E2CA; Wed, 20 Apr 2016 11:07:34 -0700 (PDT) Received: from localhost (ronin.smetech.net [209.135.209.5]) by odin.smetech.net (Postfix) with ESMTP id 6CB469A4003; Wed, 20 Apr 2016 14:07:34 -0400 (EDT) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([209.135.209.4]) by localhost (ronin.smeinc.net [209.135.209.5]) (amavisd-new, port 10024) with ESMTP id NrW1dyfxgvzK; Wed, 20 Apr 2016 13:52:06 -0400 (EDT) Received: from [192.168.2.100] (pool-108-51-128-219.washdc.fios.verizon.net [108.51.128.219]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id D2E609A4002; Wed, 20 Apr 2016 14:07:33 -0400 (EDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Russ Housley In-Reply-To: <11c960b5f1fa42aaaf4cd0a6961332ec@usma1ex-dag1mb1.msg.corp.akamai.com> Date: Wed, 20 Apr 2016 14:07:32 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <87bn543id1.fsf@alice.fifthhorseman.net> <11c960b5f1fa42aaaf4cd0a6961332ec@usma1ex-dag1mb1.msg.corp.akamai.com> To: "Salz, Rich" , Daniel Kahn Gillmor X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: "draft-irtf-cfrg-eddsa.all@ietf.org" , "cfrg@ietf.org" Subject: Re: [Cfrg] draft-irtf-cfrg-eddsa -- one final proposal for domain separation (context labels) for ed25519 X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2016 18:07:35 -0000 On Apr 20, 2016, at 7:27 AM, Salz, Rich wrote: > This is okay with me, except for one pedantic clarification. "Empty = string" has a specific meaning in C, it's a single NUL byte. Since our = other uses of context including the NUL terminator, to avoid prefix = attacks, then I think the wording needs some editing. +1 It would be better to say that an =93empty context=94 consists of zero = bytes (or octets if you prefer). Russ From nobody Wed Apr 20 11:26:24 2016 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB37112E572; Wed, 20 Apr 2016 11:26:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.196 X-Spam-Level: X-Spam-Status: No, score=-0.196 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_PSBL=2.7, RP_MATCHES_RCVD=-0.996] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gc2kq068btu8; Wed, 20 Apr 2016 11:26:21 -0700 (PDT) Received: from welho-filter2.welho.com (welho-filter2.welho.com [83.102.41.24]) by ietfa.amsl.com (Postfix) with ESMTP id B7D5612E31A; Wed, 20 Apr 2016 11:26:21 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter2.welho.com (Postfix) with ESMTP id 62C2C31C9; Wed, 20 Apr 2016 21:26:20 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp3.welho.com ([IPv6:::ffff:83.102.41.86]) by localhost (welho-filter2.welho.com [::ffff:83.102.41.24]) (amavisd-new, port 10024) with ESMTP id fI1CxkyvEAVY; Wed, 20 Apr 2016 21:26:20 +0300 (EEST) Received: from LK-Perkele-V2 (87-100-143-35.bb.dnainternet.fi [87.100.143.35]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp3.welho.com (Postfix) with ESMTPSA id 2B0492310; Wed, 20 Apr 2016 21:26:20 +0300 (EEST) Date: Wed, 20 Apr 2016 21:26:17 +0300 From: Ilari Liusvaara To: Daniel Kahn Gillmor Message-ID: <20160420182617.GA23652@LK-Perkele-V2.elisa-laajakaista.fi> References: <87bn543id1.fsf@alice.fifthhorseman.net> <11c960b5f1fa42aaaf4cd0a6961332ec@usma1ex-dag1mb1.msg.corp.akamai.com> <87ziso1m0l.fsf@alice.fifthhorseman.net> <20160420142953.GA23528@LK-Perkele-V2.elisa-laajakaista.fi> <87potk1de7.fsf@alice.fifthhorseman.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <87potk1de7.fsf@alice.fifthhorseman.net> User-Agent: Mutt/1.5.24 (2015-08-30) Sender: ilariliusvaara@welho.com Archived-At: Cc: Robert Edmonds , "draft-irtf-cfrg-eddsa.all@ietf.org" , "cfrg@ietf.org" , =?utf-8?B?T25kxZllaiBTdXLDvQ==?= , "Kaduk, Ben" , Martin Thomson Subject: Re: [Cfrg] draft-irtf-cfrg-eddsa -- one final proposal for domain separation (context labels) for ed25519 X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2016 18:26:24 -0000 On Wed, Apr 20, 2016 at 11:57:36AM -0400, Daniel Kahn Gillmor wrote: > On Wed 2016-04-20 10:29:53 -0400, Ilari Liusvaara wrote: > > On Wed, Apr 20, 2016 at 08:51:22AM -0400, Daniel Kahn Gillmor wrote: > > >> the "empty string" message in my message was not part of the proposed > >> wording change to the draft, but i can see how it might be confusing if > >> it were to make it into an edit. > >> > >> If we need additional clarification in the draft to avoid confusion, i > >> propose: > >> > >> If no context label is supplied, it is treated as an octet string of > >> zero length; that is, (context || x) is the same as x. > > > > Also, anyone up to some quick analysis to show that doesn't interact > > harmfully with Ed25519 when using the same keys? > > eh? this is specifically and only about how to apply a context label in > Ed25519 and Ed25519ph, since it's already defined for Ed448 -- what do > you mean "interact harmfully with Ed25519" ? Suppose attacker can get signatures for arbitrary (context,message) pairs under some key, can he forge a signature for some (context',message') under that key that he didn't see? > > Also, that wouldn't solve the troublesome interaction between Ed25519 > > and Ed25519ph... > > That's true, this proposal doesn't try to solve that problem. I hope it > can be evaluated independently. I actually once implemented variant of Ed25519 with contexts done like Ed448. Separate variant, so needed its own keys. It would be very easy to build Ed25519ph-like scheme by just using SHA-512(msg) as prehash and marking the message as prehashed (there is no need for context in inner hash). -Ilari From nobody Wed Apr 20 13:51:32 2016 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15DFE12EB26 for ; Wed, 20 Apr 2016 13:51:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.219 X-Spam-Level: X-Spam-Status: No, score=-4.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ubeBIjXAf833 for ; Wed, 20 Apr 2016 13:51:29 -0700 (PDT) Received: from calvin.win.tue.nl (calvin.win.tue.nl [131.155.70.11]) by ietfa.amsl.com (Postfix) with SMTP id F0DB612EB0D for ; Wed, 20 Apr 2016 13:51:27 -0700 (PDT) Received: (qmail 22140 invoked by uid 1017); 20 Apr 2016 20:51:51 -0000 Received: from unknown (unknown) by unknown with QMTP; 20 Apr 2016 20:51:51 -0000 Received: (qmail 28702 invoked by uid 1000); 20 Apr 2016 20:51:20 -0000 Date: 20 Apr 2016 20:51:20 -0000 Message-ID: <20160420205120.28700.qmail@cr.yp.to> From: "D. J. Bernstein" To: cfrg@ietf.org Mail-Followup-To: cfrg@ietf.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Cfrg] draft-irtf-cfrg-eddsa -- one final proposal for domain separation (context labels) for ed25519 X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2016 20:51:31 -0000 Paterson, Kenny writes: > We are quite keen to get draft-irtf-cfrg-eddsa "shipped", as it's needed > elsewhere in IETF and dependencies are building up. Do any of those dependencies rely on having the signed object be something other than a message? I sent CFRG a message "Side inputs to signature systems" back in September that raises several different objections to the "context" concept. I believe that all of the objections remain valid. I didn't notice until now that the concept was still under consideration; sorry! ---Dan From nobody Wed Apr 20 14:41:34 2016 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26D7A12E983; Wed, 20 Apr 2016 14:41:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gJKYlafcohUe; Wed, 20 Apr 2016 14:41:31 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [162.247.75.118]) by ietfa.amsl.com (Postfix) with ESMTP id 716FE12E7C4; Wed, 20 Apr 2016 14:41:31 -0700 (PDT) Received: from fifthhorseman.net (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id 6E4BFF991; Wed, 20 Apr 2016 17:41:28 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id 54A381FFE0; Wed, 20 Apr 2016 17:41:28 -0400 (EDT) From: Daniel Kahn Gillmor To: Ilari Liusvaara In-Reply-To: <20160420182617.GA23652@LK-Perkele-V2.elisa-laajakaista.fi> References: <87bn543id1.fsf@alice.fifthhorseman.net> <11c960b5f1fa42aaaf4cd0a6961332ec@usma1ex-dag1mb1.msg.corp.akamai.com> <87ziso1m0l.fsf@alice.fifthhorseman.net> <20160420142953.GA23528@LK-Perkele-V2.elisa-laajakaista.fi> <87potk1de7.fsf@alice.fifthhorseman.net> <20160420182617.GA23652@LK-Perkele-V2.elisa-laajakaista.fi> User-Agent: Notmuch/0.21+128~g620f892 (http://notmuchmail.org) Emacs/24.5.1 (x86_64-pc-linux-gnu) Date: Wed, 20 Apr 2016 17:41:28 -0400 Message-ID: <87bn540xh3.fsf@alice.fifthhorseman.net> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Cc: Robert Edmonds , "draft-irtf-cfrg-eddsa.all@ietf.org" , "cfrg@ietf.org" , =?utf-8?B?T25kxZllaiBTdXLDvQ==?= , "Kaduk, Ben" , Martin Thomson Subject: Re: [Cfrg] draft-irtf-cfrg-eddsa -- one final proposal for domain separation (context labels) for ed25519 X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2016 21:41:33 -0000 On Wed 2016-04-20 14:26:17 -0400, Ilari Liusvaara wrote: > On Wed, Apr 20, 2016 at 11:57:36AM -0400, Daniel Kahn Gillmor wrote: >> On Wed 2016-04-20 10:29:53 -0400, Ilari Liusvaara wrote: >> > Also, anyone up to some quick analysis to show that doesn't interact >> > harmfully with Ed25519 when using the same keys? >> >> eh? this is specifically and only about how to apply a context label in >> Ed25519 and Ed25519ph, since it's already defined for Ed448 -- what do >> you mean "interact harmfully with Ed25519" ? > > Suppose attacker can get signatures for arbitrary (context,message) pairs > under some key, can he forge a signature for some (context',message') under > that key that he didn't see? sure, by definition if context' is a prefix of context, and message' is just the concatenation of (context - context' || message), then it's a viable forgery. This is the price we pay for backward compatibility, but it's actually a *better* situation than we have without a recommended way to use a context label. Without a context label, any arbitrary message can be treated as a "forgery" by simply replaying it in a different context. (e.g. i sign an ASN.1 sequence of two integers, and you understand it as signed finite-field DHE params, but i wanted you to understand it as an RSA public key) With a context label, for every domain that defines a sane context (e.g. the guidance i suggested of printable-ascii followed by '\0'), we can rule out inter-domain replay as a successful forgery because no context will be a prefix of any other context. Furthermore, in practice, if we don't specify a standard way to use a context label for domain separation in Ed25519, different schemes may apply the context label in different ways, potentially allowing for some message collision. >> > Also, that wouldn't solve the troublesome interaction between Ed25519 >> > and Ed25519ph... >> >> That's true, this proposal doesn't try to solve that problem. I hope it >> can be evaluated independently. > > I actually once implemented variant of Ed25519 with contexts done like > Ed448. Separate variant, so needed its own keys. It would be very easy > to build Ed25519ph-like scheme by just using SHA-512(msg) as prehash > and marking the message as prehashed (there is no need for context in > inner hash). i'm sure we could propose an entirely new variant that has the same robustness as Ed448, but it would fail the backward compatibility goals that i thought the group (including you) had previously identified. In my proposal here, i am trying to work within those constraints. Are you saying that Ed25519ph doesn't need the backward compatibility? If you're proposing a fix to a separate problem, is it something we can consider separately? --dkg From nobody Wed Apr 20 15:12:10 2016 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC1F112DF1C for ; Wed, 20 Apr 2016 15:12:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YuLycIsfsIEk for ; Wed, 20 Apr 2016 15:12:07 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [162.247.75.118]) by ietfa.amsl.com (Postfix) with ESMTP id 5E91212DD6C for ; Wed, 20 Apr 2016 15:12:07 -0700 (PDT) Received: from fifthhorseman.net (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id 289E7F991; Wed, 20 Apr 2016 18:12:05 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id EEA9020061; Wed, 20 Apr 2016 18:12:05 -0400 (EDT) From: Daniel Kahn Gillmor To: "D. J. Bernstein" , cfrg@ietf.org In-Reply-To: <20160420205120.28700.qmail@cr.yp.to> References: <20160420205120.28700.qmail@cr.yp.to> User-Agent: Notmuch/0.21+128~g620f892 (http://notmuchmail.org) Emacs/24.5.1 (x86_64-pc-linux-gnu) Date: Wed, 20 Apr 2016 18:12:05 -0400 Message-ID: <878u080w22.fsf@alice.fifthhorseman.net> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [Cfrg] draft-irtf-cfrg-eddsa -- one final proposal for domain separation (context labels) for ed25519 X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2016 22:12:09 -0000 On Wed 2016-04-20 16:51:20 -0400, D. J. Bernstein wrote: > I sent CFRG a message "Side inputs to signature systems" back in > September that raises several different objections to the "context" > concept. I believe that all of the objections remain valid. I didn't > notice until now that the concept was still under consideration; sorry! The context label is explicitly in place in Ed448 in the current draft, but not in Ed25519. Your concerns are reasonable, but i don't think they're insurmountable or that they warrant the removal of Ed448: > * Are cryptographic libraries supposed to change their signature > APIs to allow an extra side input? A library that implements a signature scheme that has a context string needs to provide an API for it, yes. For signature schemes where the context string is optional (which is all of them, afaict), the context label should be optional. Libraries that implement such a scheme can continue to offer the traditional API (without a context label) of course. We've already seen some primitives adopt this approach, including the "info" parameter for HKDF-Expand (https://tools.ietf.org/html/rfc5869#section-2.3). This isn't a traditional asymmetric signature scheme, but it's an addition to the API compared to earlier KDFs (e.g. PBKDF2 didn't have such a context label). > * What exactly are the format and semantics of this input? For > example, how exactly would this side input be used to stop the TLS > bug mentioned above? We're actually doing exactly this in TLS 1.3, but doing it in an ad-hoc way: basically using the prefix approach in some places (e.g. server CertificateVerify and client CertificateVerify in TLS 1.3 are prefixed with distinct context strings: https://tools.ietf.org/html/draft-ietf-tls-tls13-12#section-6.3.4), and switching our KDF to HKDF in others (key expansion, etc https://tools.ietf.org/html/draft-ietf-tls-tls13-12#section-7.1). > * What happens when someone wants to use more of these inputs? I'm not sure what you mean here. You mean more context labels? the goal here is one distinct context label per domain. the only purpose of the context label is domain separation. why would you want more than one? > * How should libraries handle all of the signature standards that > don't support this input? Not all signature schemes take the same set of parameters (e.g. public keys and secret keys have different structures in different messages). A library that wants to offer a generic signature scheme where the user doesn't know anything about the mechanism in use could accept a context label (byte array and length) and a message (bytearray and length). if the signature scheme supports an explicit context, it would use it. If not, it could use the concatenation approach described above. > * More to the point, how is this supposed to be better than having > the application sign a more informative message, using the > traditional concept of a signature system? "more informative" assumes that you know exactly how any bytestring is going to be interpreted in every other context. If we define a standard way that a signature or key derivation domain can distinguish itself from any other domain, then we can avoid cross-protocol attacks for every scheme that adopts this standard. Without it, each protocol will define how it thinks it should structure a message that is "informative enough" to be distinct from every other signed message in every other protocol -- but how will this be determined without cross-protocol coordination? This mechanism offers a means for cross-protocol coordination by selection of distinct context strings. (for signature schemes like Ed448 that aren't using the prefix-approach, the only requirement is context string uniqueness, since they are prefix-resistant) Does this make it seem more palatable? This isn't a strictly cryptographic property, it's a mechanism to facilitate larger cross-protocol coordination. Regards, --dkg From nobody Wed Apr 20 15:36:24 2016 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83E7B12E426; Wed, 20 Apr 2016 15:36:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 76_bjjN1YGLx; Wed, 20 Apr 2016 15:36:20 -0700 (PDT) Received: from mail-vk0-x22e.google.com (mail-vk0-x22e.google.com [IPv6:2607:f8b0:400c:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF2C412E7EF; Wed, 20 Apr 2016 15:36:07 -0700 (PDT) Received: by mail-vk0-x22e.google.com with SMTP id t129so77391115vkg.2; Wed, 20 Apr 2016 15:36:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=phjtetQQfPveie6Pe0f+NRr6teBmOlXUxFRh+KmBOvQ=; b=QX7v4yZgILiAylMhFbjf4vWt/sWljW8TSVmTefEEUx3eVyAFb0YogTOHP0NMcMB64g Gg92wQIOnmbSt7A36dN7gFy6GeUhTT/vacBFrwO5Zf5yh6G1u2q7Akh7dSfr48z/8nBD Rvk6sMuvZXucUUd6SGdVbpbphYO26iOFnk9+UBRzC472aUHTHkjxYbVrVww33rlbsEWM ZnuoR8gUijwR3NiMxFQpF81Mj9l4h73r1aEK7t8anitNrFem4kve1CYlEVtvkf3KEdxm op4RXdXt85sGwRv9zaORsSitLZy6mcD7DaAzawdjuVTZ7VMU1jDz6dmDQACV5lt6yDB+ yqMg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=phjtetQQfPveie6Pe0f+NRr6teBmOlXUxFRh+KmBOvQ=; b=TlI9Y8k3mfrU9YMC7WGKfUYB3Novj4S3+20XOAiZwcY+mfdWpLWqypm10lrvyFzxLf q7BBuDY93uf+0gGpAfEmAdiaKDTeQn3KPFYs6VB6dpCJz5iu9f2jhuFtnpxcNc40hRnA 22cL/jsH33h2+jKRuEihoONq2NtTjFl9xKZHiF30xpPnd/8XwFmTy9BVenxQeaBkHARK Uo9JnnuJEUmL+5Eet2rON89HKPyzeA9IG+KXr3Ytt6uBQf3Q+SDUYCbymNSWPanLSgug O4tZdBmY4fpcNgItsYRvSKBPqmm8ZkvImEww6dv0rFLpwLWZ0I/iqCd0tJ/fNTB4hgcf XDWw== X-Gm-Message-State: AOPr4FUB6z23EkQCrg58naV4gGcc3nrlyhlagS9oxHoWjdhZ9Xmhx5s1AHEyw1rmrB4cNeSmTwXJQM7zLdHDgw== MIME-Version: 1.0 X-Received: by 10.176.1.74 with SMTP id 68mr5230180uak.56.1461191766708; Wed, 20 Apr 2016 15:36:06 -0700 (PDT) Received: by 10.176.64.68 with HTTP; Wed, 20 Apr 2016 15:36:06 -0700 (PDT) Received: by 10.176.64.68 with HTTP; Wed, 20 Apr 2016 15:36:06 -0700 (PDT) In-Reply-To: References: <87bn543id1.fsf@alice.fifthhorseman.net> <11c960b5f1fa42aaaf4cd0a6961332ec@usma1ex-dag1mb1.msg.corp.akamai.com> <87ziso1m0l.fsf@alice.fifthhorseman.net> <20160420142953.GA23528@LK-Perkele-V2.elisa-laajakaista.fi> <87potk1de7.fsf@alice.fifthhorseman.net> <20160420182617.GA23652@LK-Perkele-V2.elisa-laajakaista.fi> <87bn540xh3.fsf@alice.fifthhorseman.net> Date: Wed, 20 Apr 2016 15:36:06 -0700 Message-ID: From: Watson Ladd To: Daniel Kahn Gillmor Content-Type: multipart/alternative; boundary=001a113e213e341a8c0530f238e5 Archived-At: Cc: "draft-irtf-cfrg-eddsa.all@ietf.org" , "cfrg@ietf.org" , Robert Edmonds , =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= , Benjamin Kaduk , Martin Thomson Subject: Re: [Cfrg] draft-irtf-cfrg-eddsa -- one final proposal for domain separation (context labels) for ed25519 X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2016 22:36:22 -0000 --001a113e213e341a8c0530f238e5 Content-Type: text/plain; charset=UTF-8 On Apr 20, 2016 2:41 PM, "Daniel Kahn Gillmor" wrote: > > On Wed 2016-04-20 14:26:17 -0400, Ilari Liusvaara wrote: > > On Wed, Apr 20, 2016 at 11:57:36AM -0400, Daniel Kahn Gillmor wrote: > >> On Wed 2016-04-20 10:29:53 -0400, Ilari Liusvaara wrote: > >> > Also, anyone up to some quick analysis to show that doesn't interact > >> > harmfully with Ed25519 when using the same keys? > >> > >> eh? this is specifically and only about how to apply a context label in > >> Ed25519 and Ed25519ph, since it's already defined for Ed448 -- what do > >> you mean "interact harmfully with Ed25519" ? > > > > Suppose attacker can get signatures for arbitrary (context,message) pairs > > under some key, can he forge a signature for some (context',message') under > > that key that he didn't see? > > sure, by definition if context' is a prefix of context, and message' is > just the concatenation of (context - context' || message), then it's a > viable forgery. > > This is the price we pay for backward compatibility, but it's actually a > *better* situation than we have without a recommended way to use a > context label. > > Without a context label, any arbitrary message can be treated as a > "forgery" by simply replaying it in a different context. (e.g. i sign > an ASN.1 sequence of two integers, and you understand it as signed > finite-field DHE params, but i wanted you to understand it as an RSA > public key) Cryptographers have understood since the 1990s the importance of not using keys across protocols and signing all information affecting interpretation of signed data. Protocols which rely on a context cannot work with RSA - PSS or ECDSA. They can simply specify preappending the context to work with all signature schemes. > > With a context label, for every domain that defines a sane context > (e.g. the guidance i suggested of printable-ascii followed by '\0'), we > can rule out inter-domain replay as a successful forgery because no > context will be a prefix of any other context. > > Furthermore, in practice, if we don't specify a standard way to use a > context label for domain separation in Ed25519, different schemes may > apply the context label in different ways, potentially allowing for some > message collision. > > >> > Also, that wouldn't solve the troublesome interaction between Ed25519 > >> > and Ed25519ph... > >> > >> That's true, this proposal doesn't try to solve that problem. I hope it > >> can be evaluated independently. > > > > I actually once implemented variant of Ed25519 with contexts done like > > Ed448. Separate variant, so needed its own keys. It would be very easy > > to build Ed25519ph-like scheme by just using SHA-512(msg) as prehash > > and marking the message as prehashed (there is no need for context in > > inner hash). > > i'm sure we could propose an entirely new variant that has the same > robustness as Ed448, but it would fail the backward compatibility goals > that i thought the group (including you) had previously identified. In > my proposal here, i am trying to work within those constraints. Are you > saying that Ed25519ph doesn't need the backward compatibility? > > If you're proposing a fix to a separate problem, is it something we can > consider separately? > > --dkg > > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > https://www.irtf.org/mailman/listinfo/cfrg --001a113e213e341a8c0530f238e5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Apr 20, 2016 2:41 PM, "Daniel Kahn Gillmor" <
dkg@fifthhorseman.net> wrote:
>
> On Wed 2016-04-20 14:26:17 -0400, Ilari Liusvaara wrote:
> > On Wed, Apr 20, 2016 at 11:57:36AM -0400, Daniel Kahn Gillmor wro= te:
> >> On Wed 2016-04-20 10:29:53 -0400, Ilari Liusvaara wrote:
> >> > Also, anyone up to some quick analysis to show that does= n't interact
> >> > harmfully with Ed25519 when using the same keys?
> >>
> >> eh?=C2=A0 this is specifically and only about how to apply a = context label in
> >> Ed25519 and Ed25519ph, since it's already defined for Ed4= 48 -- what do
> >> you mean "interact harmfully with Ed25519" ?
> >
> > Suppose attacker can get signatures for arbitrary (context,messag= e) pairs
> > under some key, can he forge a signature for some (context',m= essage') under
> > that key that he didn't see?
>
> sure, by definition if context' is a prefix of context, and messag= e' is
> just the concatenation of (context - context' || message), then it= 's a
> viable forgery.
>
> This is the price we pay for backward compatibility, but it's actu= ally a
> *better* situation than we have without a recommended way to use a
> context label.
>
> Without a context label, any arbitrary message can be treated as a
> "forgery" by simply replaying it in a different context. (e.= g. i sign
> an ASN.1 sequence of two integers, and you understand it as signed
> finite-field DHE params, but i wanted you to understand it as an RSA > public key)

Cryptographers have understood since the 1990s the importanc= e of not using keys across protocols and signing all information affecting = interpretation of signed data.

Protocols which rely on a context cannot work with RSA - PSS= or ECDSA. They can simply specify preappending the context to work with al= l signature schemes.

>
> With a context label, for every domain that defines a sane context
> (e.g. the guidance i suggested of printable-ascii followed by '\0&= #39;), we
> can rule out inter-domain replay as a successful forgery because no > context will be a prefix of any other context.
>
> Furthermore, in practice, if we don't specify a standard way to us= e a
> context label for domain separation in Ed25519, different schemes may<= br> > apply the context label in different ways, potentially allowing for so= me
> message collision.
>
> >> > Also, that wouldn't solve the troublesome interactio= n between Ed25519
> >> > and Ed25519ph...
> >>
> >> That's true, this proposal doesn't try to solve that = problem.=C2=A0 I hope it
> >> can be evaluated independently.
> >
> > I actually once implemented variant of Ed25519 with contexts done= like
> > Ed448. Separate variant, so needed its own keys. It would be very= easy
> > to build Ed25519ph-like scheme by just using SHA-512(msg) as preh= ash
> > and marking the message as prehashed (there is no need for contex= t in
> > inner hash).
>
> i'm sure we could propose an entirely new variant that has the sam= e
> robustness as Ed448, but it would fail the backward compatibility goal= s
> that i thought the group (including you) had previously identified. In=
> my proposal here, i am trying to work within those constraints.=C2=A0 = Are you
> saying that Ed25519ph doesn't need the backward compatibility?
>
> If you're proposing a fix to a separate problem, is it something w= e can
> consider separately?
>
> =C2=A0 =C2=A0--dkg
>
> _______________________________________________
> Cfrg mailing list
> Cfrg@irtf.org
> https://www.irt= f.org/mailman/listinfo/cfrg

--001a113e213e341a8c0530f238e5-- From nobody Wed Apr 20 16:38:35 2016 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 667F412E65A for ; Wed, 20 Apr 2016 16:38:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.197 X-Spam-Level: X-Spam-Status: No, score=-5.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ayTa4GfZDiET for ; Wed, 20 Apr 2016 16:38:31 -0700 (PDT) Received: from dmz-mailsec-scanner-4.mit.edu (dmz-mailsec-scanner-4.mit.edu [18.9.25.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C512012E24B for ; Wed, 20 Apr 2016 16:38:31 -0700 (PDT) X-AuditID: 1209190f-ca3ff70000004b9e-10-571812f6c954 Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by (Symantec Messaging Gateway) with SMTP id 35.C5.19358.6F218175; Wed, 20 Apr 2016 19:38:30 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id u3KNcT80030648; Wed, 20 Apr 2016 19:38:30 -0400 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id u3KNcPSe011844 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 20 Apr 2016 19:38:28 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id u3KNcP0X003295; Wed, 20 Apr 2016 19:38:25 -0400 (EDT) Date: Wed, 20 Apr 2016 19:38:25 -0400 (EDT) From: Benjamin Kaduk To: "D. J. Bernstein" In-Reply-To: <878u080w22.fsf@alice.fifthhorseman.net> Message-ID: References: <20160420205120.28700.qmail@cr.yp.to> <878u080w22.fsf@alice.fifthhorseman.net> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrBIsWRmVeSWpSXmKPExsUixCmqrftNSCLcYNZ5GYuju9pYLI5+38Ns 0dr9mcmB2aOrN8rjbHc7q8eSJT+ZApijuGxSUnMyy1KL9O0SuDLmHi8quCtUMenjGuYGxm7+ LkYODgkBE4mGPXpdjFwcQgJtTBJX3n9hgXA2Mkos+f2ODcI5xCQx+81+dgingVHi4cRrQGWc HCwC2hJrL69gB7HZBFQkZr7ZyAZiiwDZjydcYAKxmQXsJH6v/cMKYgsLlEicmHsSrIZTwFTi 3PYjLCBn8Ao4SlycXQwSFhKIkrjw9RTYeFEBHYnV+6eA2bwCghInZz5hgRipJbF8+jaWCYwC s5CkZiFJLWBkWsUom5JbpZubmJlTnJqsW5ycmJeXWqRropebWaKXmlK6iREcoJL8OxjnNHgf YhTgYFTi4Q2oFQ8XYk0sK67MPcQoycGkJMr74hdQiC8pP6UyI7E4I76oNCe1+BCjBAezkgjv TQGJcCHelMTKqtSifJiUNAeLkjgvIwMDg5BAemJJanZqakFqEUxWhoNDSYKXCxiJQoJFqemp FWmZOSUIaSYOTpDhPEDDrwiCDC8uSMwtzkyHyJ9iVJQS5y0FSQiAJDJK8+B6wQlkN5PqK0Zx oFeEeSNAVvAAkw9c9yugwUxAg/nvioIMLklESEk1MHpIB61/fVRnCp9Qa3ulQMuFhU4vjZdZ 3DhfP/HPybvl+g/l+TTDpH/V3Nh8Yf+Mk5O+Tbv6pKEqb9WB6RI6+y9KcNnPWuQXw/IgI3aj nCD7sitbFyZ4+mw7OF0qkFH/1Kt7VXds5r5ca7RpxoqZHV9d77tWbEpmYzcTKgswqyl1Udzx UVrXb4YSS3FGoqEWc1FxIgCw6j/m+wIAAA== Archived-At: Cc: cfrg@ietf.org Subject: Re: [Cfrg] draft-irtf-cfrg-eddsa -- one final proposal for domain separation (context labels) for ed25519 X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2016 23:38:34 -0000 On Wed, 20 Apr 2016, Daniel Kahn Gillmor wrote: > On Wed 2016-04-20 16:51:20 -0400, D. J. Bernstein wrote: > > > * More to the point, how is this supposed to be better than having > > the application sign a more informative message, using the > > traditional concept of a signature system? > > "more informative" assumes that you know exactly how any bytestring is > going to be interpreted in every other context. To perhaps step back a bit, a signature scheme taking an optional context label input with specified semantics (i.e., the label is prepended, recommended to end with a NUL byte, etc.) is a way to strongly suggest that application protocols using that signature scheme provide such "more informative message"s, and gives guidance as to what the structure of the more informative message could be. I don't really care if the application protocol makes its message being signed more informative (i.e., specific to the particular protocol message at hand) by manually putting that data at the front of its signing input and ignoring the context input, or by using the context input. I just want it to happen, since that improves the overall safety of the internet. > If we define a standard way that a signature or key derivation domain > can distinguish itself from any other domain, then we can avoid > cross-protocol attacks for every scheme that adopts this standard. > > Without it, each protocol will define how it thinks it should structure > a message that is "informative enough" to be distinct from every other > signed message in every other protocol -- but how will this be > determined without cross-protocol coordination? This mechanism offers a > means for cross-protocol coordination by selection of distinct context > strings. (for signature schemes like Ed448 that aren't using the > prefix-approach, the only requirement is context string uniqueness, > since they are prefix-resistant) Having a contetx input to newly specified signature schemes (and a registry to ensure global prefix-uniqueness, which dkg and Martin and I are working on a draft for) is a way to help protocol designers that aren't cryptographers do the right thing, cryptographically speaking. Perhaps there are better ways to encourage this behavior, but this is the best proposal I've seen so far, for this issue. -Ben From nobody Wed Apr 20 21:39:55 2016 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 815BB12D197; Wed, 20 Apr 2016 21:39:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.196 X-Spam-Level: X-Spam-Status: No, score=-0.196 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_PSBL=2.7, RP_MATCHES_RCVD=-0.996] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id COYJWziOYpEs; Wed, 20 Apr 2016 21:39:52 -0700 (PDT) Received: from welho-filter2.welho.com (welho-filter2.welho.com [83.102.41.24]) by ietfa.amsl.com (Postfix) with ESMTP id 5BCB612D0E7; Wed, 20 Apr 2016 21:39:51 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter2.welho.com (Postfix) with ESMTP id 012FF2F90; Thu, 21 Apr 2016 07:39:51 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp1.welho.com ([IPv6:::ffff:83.102.41.84]) by localhost (welho-filter2.welho.com [::ffff:83.102.41.24]) (amavisd-new, port 10024) with ESMTP id sOjlqeIuVNIG; Thu, 21 Apr 2016 07:39:50 +0300 (EEST) Received: from LK-Perkele-V2 (87-100-143-35.bb.dnainternet.fi [87.100.143.35]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp1.welho.com (Postfix) with ESMTPSA id 8D525C4; Thu, 21 Apr 2016 07:39:50 +0300 (EEST) Date: Thu, 21 Apr 2016 07:39:47 +0300 From: Ilari Liusvaara To: Daniel Kahn Gillmor Message-ID: <20160421043947.GA24394@LK-Perkele-V2.elisa-laajakaista.fi> References: <87bn543id1.fsf@alice.fifthhorseman.net> <11c960b5f1fa42aaaf4cd0a6961332ec@usma1ex-dag1mb1.msg.corp.akamai.com> <87ziso1m0l.fsf@alice.fifthhorseman.net> <20160420142953.GA23528@LK-Perkele-V2.elisa-laajakaista.fi> <87potk1de7.fsf@alice.fifthhorseman.net> <20160420182617.GA23652@LK-Perkele-V2.elisa-laajakaista.fi> <87bn540xh3.fsf@alice.fifthhorseman.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <87bn540xh3.fsf@alice.fifthhorseman.net> User-Agent: Mutt/1.5.24 (2015-08-30) Sender: ilariliusvaara@welho.com Archived-At: Cc: Robert Edmonds , "draft-irtf-cfrg-eddsa.all@ietf.org" , "cfrg@ietf.org" , =?utf-8?B?T25kxZllaiBTdXLDvQ==?= , "Kaduk, Ben" , Martin Thomson Subject: Re: [Cfrg] draft-irtf-cfrg-eddsa -- one final proposal for domain separation (context labels) for ed25519 X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2016 04:39:54 -0000 On Wed, Apr 20, 2016 at 05:41:28PM -0400, Daniel Kahn Gillmor wrote: > On Wed 2016-04-20 14:26:17 -0400, Ilari Liusvaara wrote: > > On Wed, Apr 20, 2016 at 11:57:36AM -0400, Daniel Kahn Gillmor wrote: > >> On Wed 2016-04-20 10:29:53 -0400, Ilari Liusvaara wrote: > >> > Also, anyone up to some quick analysis to show that doesn't interact > >> > harmfully with Ed25519 when using the same keys? > >> > >> eh? this is specifically and only about how to apply a context label in > >> Ed25519 and Ed25519ph, since it's already defined for Ed448 -- what do > >> you mean "interact harmfully with Ed25519" ? > > > > Suppose attacker can get signatures for arbitrary (context,message) pairs > > under some key, can he forge a signature for some (context',message') under > > that key that he didn't see? > > sure, by definition if context' is a prefix of context, and message' is > just the concatenation of (context - context' || message), then it's a > viable forgery. H(x)=SHA-512(context||x) without any lengths or separators does not behave that way. It does not have trivially computable collisions (but easily computed ones might still exist, or worse, a way to extract the private key). That is, signature for ('abc','def') is not expected to validate for ('abcd','ef'). It is also not possible to compute the result using stock Ed25519 code with any non-empty context. > Without a context label, any arbitrary message can be treated as a > "forgery" by simply replaying it in a different context. (e.g. i sign > an ASN.1 sequence of two integers, and you understand it as signed > finite-field DHE params, but i wanted you to understand it as an RSA > public key) Contexts were never meant to help with internally-inconsistent protocol (e.g. TLS ServerKeyExchange signatures), only between different protocols possibly sharing keys. > With a context label, for every domain that defines a sane context > (e.g. the guidance i suggested of printable-ascii followed by '\0'), we > can rule out inter-domain replay as a successful forgery because no > context will be a prefix of any other context. Also, contexts cause large amount of API problems. And it is very easy to use in spec without understanding the problems, resulting spec that is very annoying to implement. > Furthermore, in practice, if we don't specify a standard way to use a > context label for domain separation in Ed25519, different schemes may > apply the context label in different ways, potentially allowing for some > message collision. There is absolutely no working way to apply contexts using stock Ed25519 implementations that isn't utterly broken. > >> > Also, that wouldn't solve the troublesome interaction between Ed25519 > >> > and Ed25519ph... > >> > >> That's true, this proposal doesn't try to solve that problem. I hope it > >> can be evaluated independently. > > > > I actually once implemented variant of Ed25519 with contexts done like > > Ed448. Separate variant, so needed its own keys. It would be very easy > > to build Ed25519ph-like scheme by just using SHA-512(msg) as prehash > > and marking the message as prehashed (there is no need for context in > > inner hash). > > i'm sure we could propose an entirely new variant that has the same > robustness as Ed448, but it would fail the backward compatibility goals > that i thought the group (including you) had previously identified. In > my proposal here, i am trying to work within those constraints. Are you > saying that Ed25519ph doesn't need the backward compatibility? I don't think Ed25519ph needs backward compatiblity. > If you're proposing a fix to a separate problem, is it something we can > consider separately? It is closely related in any space to stick contexts to would also be space to stick the hash flag to. -Ilari From nobody Wed Apr 20 22:47:10 2016 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DCF712E97F for ; Wed, 20 Apr 2016 22:47:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=sbcglobal.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fe-ZdvFUwW2Z for ; Wed, 20 Apr 2016 22:47:07 -0700 (PDT) Received: from nm25-vm8.access.bullet.mail.gq1.yahoo.com (nm25-vm8.access.bullet.mail.gq1.yahoo.com [216.39.63.233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC38C12E985 for ; Wed, 20 Apr 2016 22:47:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sbcglobal.net; s=s2048; t=1461217626; bh=ghiRhTeFVkDLz6+fpGbuIwG04vyDTl0aCI1Cy1wUbOQ=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From:Subject; b=JHbTi6eTs+pM9i4yqKZ/lVHd2ABrPKs013t2dL16HAylZ80eJcLgMjdSKiSCrNdAO0ymJtHzihGsONx0hhqvhI1ELAWyJiBszgq4bUTQa1pVJENxJGITO/jNZhnnlUsQVzgdxCHJ9OOZMJuir0naBYv5a9eKmBAHua40MkxKzYufcBQNGiyy0a6nJXB7EuvzuMtUBAapIV728LcUjV0HmwmkYltBX9ykBCB15Ki4xLmQbdDnUN+SFNHxawtzQ6FVgBwAx327HdBFpB+2unshFZX6YvwYk/bVDrTOhbT/Ven/L6Syd7dB9y7rliPECio5ErbBjCKu0dn1vFi5bv2ywA== Received: from [216.39.60.176] by nm25.access.bullet.mail.gq1.yahoo.com with NNFMP; 21 Apr 2016 05:47:06 -0000 Received: from [67.195.22.118] by tm12.access.bullet.mail.gq1.yahoo.com with NNFMP; 21 Apr 2016 05:47:06 -0000 Received: from [127.0.0.1] by smtp113.sbc.mail.gq1.yahoo.com with NNFMP; 21 Apr 2016 05:47:06 -0000 X-Yahoo-Newman-Id: 280323.73969.bm@smtp113.sbc.mail.gq1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: sygdBa8VM1k1Qr0MGqmd2WFXmU.l1bbfZxQmR9Wsn_3eRB3 OT7l6R10fH2UPMQUOdRQJH3KXy6g4z9MGFIZhw6mLqNHjT0IPM2IPzzFs0HE GGbyBwGv.cyk2egeOpyKdYV_2neW1Hqai1nkFLTR4rQDjcebH3NXqcD3fjv6 kPtACt_rA_sBsWOfZj1sDxz6uHTwnASsBiQSK3wBL_2y2Sgc.5LQYDwNOv7K BaJkujvryxcfyQcG_Or3tX349vNrVYcYmuSox1AbYAbzCprklMoAVylaxufV QKhxecUkPhVLm.b6jlR8FPHA_9EXEV5U59LzkjR7J4oXGn8yGb422nO9PH5N 7.t9VX98N7wAEPrTeob8UZhT3jtOgOaMXBpaY6JDxw8Qj6.xKsldHVkfnhpo CHRL4X02c071JHA_WZo6q.jxpHfQVuNWhaVpR6p7Igvws41r_fQlMcYztjpS 4Y7VRFD8xedKR1XYbhzT6szyTposkFhpsVt05CxIbaBvXgdBdlRntSVfjkuJ W5GpYGa5m6W5cElR9OJzFAcZ8Yf.bUE9Z1yZYK7Lnnz2Z.iitwn4xydcU X-Yahoo-SMTP: nOrmCa6swBAE50FabWnlVFUpgFVJ9Gbi__8U5mpvhtQq7tTV1g-- To: Benjamin Kaduk , "D. J. Bernstein" References: <20160420205120.28700.qmail@cr.yp.to> <878u080w22.fsf@alice.fifthhorseman.net> From: David Jacobson Message-ID: <57186958.1040907@sbcglobal.net> Date: Wed, 20 Apr 2016 22:47:04 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: cfrg@ietf.org Subject: Re: [Cfrg] draft-irtf-cfrg-eddsa -- one final proposal for domain separation (context labels) for ed25519 X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2016 05:47:08 -0000 On 4/20/16 4:38 PM, Benjamin Kaduk wrote: > On Wed, 20 Apr 2016, Daniel Kahn Gillmor wrote: > >> On Wed 2016-04-20 16:51:20 -0400, D. J. Bernstein wrote: >> >>> * More to the point, how is this supposed to be better than having >>> the application sign a more informative message, using the >>> traditional concept of a signature system? >> "more informative" assumes that you know exactly how any bytestring is >> going to be interpreted in every other context. > To perhaps step back a bit, a signature scheme taking an optional context > label input with specified semantics (i.e., the label is prepended, > recommended to end with a NUL byte, etc.) is a way to strongly suggest > that application protocols using that signature scheme provide such "more > informative message"s, and gives guidance as to what the structure of the > more informative message could be. If you want to include a NUL byte to separate the context from the following stuff, then to avoid ambiguity you need to require that the context not contain any NUL bytes. And this rules out general binary blobs as context values, including general ASN.1 objects. NIST Special Publication 800-108 (about key derivation functions) made this mistake. Even though Section 7.4 requires a 1-to-1 mapping from inputs to the internal blob send to the PRF, the constructs used in Section 5 does not achieve that requirement when the label is allowed to be an object that contains a NUL byte. --David > > I don't really care if the application protocol makes its message being > signed more informative (i.e., specific to the particular protocol message > at hand) by manually putting that data at the front of its signing input > and ignoring the context input, or by using the context input. I just > want it to happen, since that improves the overall safety of the internet. > >> If we define a standard way that a signature or key derivation domain >> can distinguish itself from any other domain, then we can avoid >> cross-protocol attacks for every scheme that adopts this standard. >> >> Without it, each protocol will define how it thinks it should structure >> a message that is "informative enough" to be distinct from every other >> signed message in every other protocol -- but how will this be >> determined without cross-protocol coordination? This mechanism offers a >> means for cross-protocol coordination by selection of distinct context >> strings. (for signature schemes like Ed448 that aren't using the >> prefix-approach, the only requirement is context string uniqueness, >> since they are prefix-resistant) > Having a contetx input to newly specified signature schemes (and a > registry to ensure global prefix-uniqueness, which dkg and Martin and I > are working on a draft for) is a way to help protocol designers that > aren't cryptographers do the right thing, cryptographically speaking. > Perhaps there are better ways to encourage this behavior, but this is the > best proposal I've seen so far, for this issue. > > -Ben > > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > https://www.irtf.org/mailman/listinfo/cfrg > From nobody Wed Apr 20 22:58:26 2016 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A77012DE66 for ; Wed, 20 Apr 2016 22:58:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oRqLZtLr7Y5k for ; Wed, 20 Apr 2016 22:58:23 -0700 (PDT) Received: from mail-ig0-x22c.google.com (mail-ig0-x22c.google.com [IPv6:2607:f8b0:4001:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E762C12D1E2 for ; Wed, 20 Apr 2016 22:58:22 -0700 (PDT) Received: by mail-ig0-x22c.google.com with SMTP id g8so71822058igr.0 for ; Wed, 20 Apr 2016 22:58:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=2B+8cZAIP4y77OwnrdKD5zpl/u4+YMZ4GcNUdkOj1+0=; b=xTEDvjoVeBCobpGlKJTfYNZVy2R9XdqmPn6Xo5hNljUKhDpmvRHMU0/V7ggQampsX6 aqP7SgGSQrOyhd1gUU46x+B0M9Rqo3ZkVcCCGXs9gJs1UDdM1H0Ti689eEwafLubtnmv EJtX7z7BCW5RuIkA1/WsihYJigVvqkZ0QEfS2i42eFvtMebWztkyhFQf6TzpJHZ0H2QW RfE2iZA32QbWu4btuR2Xfxj9uzpNa9C38RdA+IXaiz6TWdiNZ/EqgcqIdWpAvWgiS3bP ICzsWLCOhWaf7R5PH8yG1FS/RPdI08FCXqeDSvXLAMN27TiC4S60bW8/zL5hZFYTkhvU bVSw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=2B+8cZAIP4y77OwnrdKD5zpl/u4+YMZ4GcNUdkOj1+0=; b=amwnUNAjbPTUVW+ykCzRjiQTJTvoL/niVkI3ooO/wESXsxRzZ6xWXUPgIX+VfrXeOb W1vXa7cBrq6TsEvAGAmQW/ZBvyLRgGzhvulzl0pfqPSQO8aFifgwjjFrzGFfedunXBV2 oUoG08x6V3b+BQhrbpuv89RcaHvGrRb9j+CEPxLjEvKwOA032k/snpjv8s72YZhvlVRS 4L+klg5xPlFx0To5m7faLtu3Tv6zqq1EzduJ71Q5ABw5sYEwn+5RtJLx0p+jJuxaWV/s v8Lw2ssq7PKHduzoPTdpmMDxDekSZ0xtr8z2LAGY3tloe3lL5Bq0f+Mz004lnGur5kDv Z8qQ== X-Gm-Message-State: AOPr4FWjE7+B0A2JHLrBwba2YwV0Dmm+TVsgcLR3MAh5rt5eIOl916AcX3qbOya3KZsaDKd4c0YfIHYd2t173A== MIME-Version: 1.0 X-Received: by 10.50.23.80 with SMTP id k16mr1421897igf.94.1461218302301; Wed, 20 Apr 2016 22:58:22 -0700 (PDT) Received: by 10.36.43.82 with HTTP; Wed, 20 Apr 2016 22:58:22 -0700 (PDT) In-Reply-To: <57186958.1040907@sbcglobal.net> References: <20160420205120.28700.qmail@cr.yp.to> <878u080w22.fsf@alice.fifthhorseman.net> <57186958.1040907@sbcglobal.net> Date: Thu, 21 Apr 2016 15:58:22 +1000 Message-ID: From: Martin Thomson To: David Jacobson Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: cfrg@ietf.org, "D. J. Bernstein" Subject: Re: [Cfrg] draft-irtf-cfrg-eddsa -- one final proposal for domain separation (context labels) for ed25519 X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2016 05:58:24 -0000 On 21 April 2016 at 15:47, David Jacobson wrote: > If you want to include a NUL byte to separate the context from the following > stuff, then to avoid ambiguity you need to require that the context not > contain any NUL bytes. And this rules out general binary blobs as context > values, including general ASN.1 objects. Yes, we can be more concrete if you like: It's possible to say that only necessary requirement is that no label be a prefix of any other. One way of doing that is with a proper bijective mapping like the length-and-value encoding used in Ed448. However, that makes zero-length contexts incompatible with existing, context-free signatures; or to retcon existing uses into being good citizens. BTW, the plan is to submit this as a -00 soon, but here's our recommendation: https://unicorn-wg.github.io/context-labels/#rfc.section.4 I'm sure that this will stimulate many fruitful discussions, much like this one. From nobody Thu Apr 21 07:38:01 2016 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8280712DD66 for ; Thu, 21 Apr 2016 07:38:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.896 X-Spam-Level: X-Spam-Status: No, score=-2.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.996] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rtk78wE1KZh1 for ; Thu, 21 Apr 2016 07:37:58 -0700 (PDT) Received: from welho-filter2.welho.com (welho-filter2.welho.com [83.102.41.24]) by ietfa.amsl.com (Postfix) with ESMTP id 8E34812DD23 for ; Thu, 21 Apr 2016 07:37:58 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter2.welho.com (Postfix) with ESMTP id 5450F310D; Thu, 21 Apr 2016 17:37:56 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp2.welho.com ([IPv6:::ffff:83.102.41.85]) by localhost (welho-filter2.welho.com [::ffff:83.102.41.24]) (amavisd-new, port 10024) with ESMTP id jecleo4DhWhR; Thu, 21 Apr 2016 17:37:56 +0300 (EEST) Received: from LK-Perkele-V2 (87-100-143-35.bb.dnainternet.fi [87.100.143.35]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp2.welho.com (Postfix) with ESMTPSA id 1C2D021C; Thu, 21 Apr 2016 17:37:56 +0300 (EEST) Date: Thu, 21 Apr 2016 17:37:53 +0300 From: Ilari Liusvaara To: David Jacobson Message-ID: <20160421143752.GA24969@LK-Perkele-V2.elisa-laajakaista.fi> References: <20160420205120.28700.qmail@cr.yp.to> <878u080w22.fsf@alice.fifthhorseman.net> <57186958.1040907@sbcglobal.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <57186958.1040907@sbcglobal.net> User-Agent: Mutt/1.5.24 (2015-08-30) Sender: ilariliusvaara@welho.com Archived-At: Cc: cfrg@ietf.org Subject: Re: [Cfrg] draft-irtf-cfrg-eddsa -- one final proposal for domain separation (context labels) for ed25519 X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2016 14:38:00 -0000 On Wed, Apr 20, 2016 at 10:47:04PM -0700, David Jacobson wrote: > On 4/20/16 4:38 PM, Benjamin Kaduk wrote: > >On Wed, 20 Apr 2016, Daniel Kahn Gillmor wrote: > > If you want to include a NUL byte to separate the context from the following > stuff, then to avoid ambiguity you need to require that the context not > contain any NUL bytes. And this rules out general binary blobs as context > values, including general ASN.1 objects. You really don't want ASN.1 objects, JSON serializations or anything like that as context values. Those values are supposed to be at most name of the protocol and possibly version thereof (if one decides to use those at all). -Ilari From nobody Thu Apr 21 11:31:20 2016 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF64612E851; Thu, 21 Apr 2016 11:31:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.197 X-Spam-Level: X-Spam-Status: No, score=-5.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3THLgNd9VG0h; Thu, 21 Apr 2016 11:30:59 -0700 (PDT) Received: from dmz-mailsec-scanner-8.mit.edu (dmz-mailsec-scanner-8.mit.edu [18.7.68.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4191712EB10; Thu, 21 Apr 2016 11:30:59 -0700 (PDT) X-AuditID: 12074425-c6bff70000005f72-41-57191c6228eb Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by (Symantec Messaging Gateway) with SMTP id B9.25.24434.26C19175; Thu, 21 Apr 2016 14:30:58 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id u3LIUuur032358; Thu, 21 Apr 2016 14:30:57 -0400 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id u3LIUp0v009671 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 21 Apr 2016 14:30:54 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id u3LIUoND026561; Thu, 21 Apr 2016 14:30:50 -0400 (EDT) Date: Thu, 21 Apr 2016 14:30:50 -0400 (EDT) From: Benjamin Kaduk To: Ilari Liusvaara In-Reply-To: <20160421043947.GA24394@LK-Perkele-V2.elisa-laajakaista.fi> Message-ID: References: <87bn543id1.fsf@alice.fifthhorseman.net> <11c960b5f1fa42aaaf4cd0a6961332ec@usma1ex-dag1mb1.msg.corp.akamai.com> <87ziso1m0l.fsf@alice.fifthhorseman.net> <20160420142953.GA23528@LK-Perkele-V2.elisa-laajakaista.fi> <87potk1de7.fsf@alice.fifthhorseman.net> <20160420182617.GA23652@LK-Perkele-V2.elisa-laajakaista.fi> <87bn540xh3.fsf@alice.fifthhorseman.net> <20160421043947.GA24394@LK-Perkele-V2.elisa-laajakaista.fi> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprNKsWRmVeSWpSXmKPExsUixCmqrJskIxlu8PsZp0Xj5kZWi6O72lgs Wrs/M1lcX/eU3eLftseMFu93T2exuHbmH6PF9d1PmRw4PCYfWcDs8attLrPH2e52Vo+ds+6y eyxZ8pPJ48LhHmaP291z2ALYo7hsUlJzMstSi/TtErgyjnS9YS5YIVWxp/kKUwPjM5EuRk4O CQETiaX/tjB1MXJxCAm0MUncOfGFDcLZyCixa88vKOcQk8Sjm8+YIZwGRonzXYsZQfpZBLQl +h5tYgGx2QRUJGa+2cgGYosI6EkcX3eRFaSBWeA7k8TE42eYQRLCAiUSJ+aeBCviFPCQeH7v PVgzr4CjxII3exkhNlxnlrjxaxlYkaiAjsTq/VOgigQlTs58AmYzC2hJLJ++jWUCo8AsJKlZ SFILGJlWMcqm5Fbp5iZm5hSnJusWJyfm5aUW6Vro5WaW6KWmlG5iBMUBu4vqDsY5f70OMQpw MCrx8HLIS4QLsSaWFVfmHmKU5GBSEuVlY5EMF+JLyk+pzEgszogvKs1JLT7EKMHBrCTCGyMB lONNSaysSi3Kh0lJc7AoifMyMjAwCAmkJ5akZqemFqQWwWRlODiUJHgZpYEaBYtS01Mr0jJz ShDSTBycIMN5gIY7SoEMLy5IzC3OTIfIn2JUlBLntQNJCIAkMkrz4HrBaWo3k+orRnGgV4R5 zUBW8ABTHFz3K6DBTECD+e+KggwuSURISTUw+ujvmz1B2pqp8djUoMlvvy4uvsk01d0i92bj 1MdN5hF+DXabVfY7sD2Z86uAm2ciw5Hs2wdq99x5xZ4j/ez+pOSd91fMCFnAxHox28anQrHu QJXZJ0YDzdXRyZxbllfHxs5+OXNTxYG57Jbzz/zYKhiYzKP7+e3mF7X8byf+PszVfZ9zh0eo lhJLcUaioRZzUXEiAGDZEbcuAwAA Archived-At: Cc: "draft-irtf-cfrg-eddsa.all@ietf.org" , Robert Edmonds , "cfrg@ietf.org" , =?ISO-8859-2?Q?Ond=F8ej_Sur=FD?= , "Kaduk, Ben" Subject: Re: [Cfrg] draft-irtf-cfrg-eddsa -- one final proposal for domain separation (context labels) for ed25519 X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2016 18:31:17 -0000 On Thu, 21 Apr 2016, Ilari Liusvaara wrote: > On Wed, Apr 20, 2016 at 05:41:28PM -0400, Daniel Kahn Gillmor wrote: > > On Wed 2016-04-20 14:26:17 -0400, Ilari Liusvaara wrote: > > > On Wed, Apr 20, 2016 at 11:57:36AM -0400, Daniel Kahn Gillmor wrote: > > >> On Wed 2016-04-20 10:29:53 -0400, Ilari Liusvaara wrote: > > >> > Also, anyone up to some quick analysis to show that doesn't interact > > >> > harmfully with Ed25519 when using the same keys? > > >> > > >> eh? this is specifically and only about how to apply a context label in > > >> Ed25519 and Ed25519ph, since it's already defined for Ed448 -- what do > > >> you mean "interact harmfully with Ed25519" ? > > > > > > Suppose attacker can get signatures for arbitrary (context,message) pairs > > > under some key, can he forge a signature for some (context',message') under > > > that key that he didn't see? > > > > sure, by definition if context' is a prefix of context, and message' is > > just the concatenation of (context - context' || message), then it's a > > viable forgery. > > H(x)=SHA-512(context||x) without any lengths or separators does not behave > that way. It does not have trivially computable collisions (but easily > computed ones might still exist, or worse, a way to extract the private key). > > That is, signature for ('abc','def') is not expected to validate for > ('abcd','ef'). I think I'm confused. Surely if I set chunk = { 'a', 'b', 'c', 'd', 'e', 'f'} containing six octets, then SHA-512(chunk) is the same, whether I construct chunk from 'abc','def' or 'abcd','ef'. So you must be talking about something else, but I'm not sure what. > It is also not possible to compute the result using stock Ed25519 code > with any non-empty context. Can you be more specific? Is the complaint just that one would need to use a temporary buffer and copy the data to be signed in order to put in the prefix? > > With a context label, for every domain that defines a sane context > > (e.g. the guidance i suggested of printable-ascii followed by '\0'), we > > can rule out inter-domain replay as a successful forgery because no > > context will be a prefix of any other context. > > Also, contexts cause large amount of API problems. And it is very easy > to use in spec without understanding the problems, resulting spec that > is very annoying to implement. >From where I am sitting, it seems like there are two options: does the signing API include a context input? If yes, use that input; if no, prepend the context to the message to be signed in my own code. What am I missing? > > i'm sure we could propose an entirely new variant that has the same > > robustness as Ed448, but it would fail the backward compatibility goals > > that i thought the group (including you) had previously identified. In > > my proposal here, i am trying to work within those constraints. Are you > > saying that Ed25519ph doesn't need the backward compatibility? > > I don't think Ed25519ph needs backward compatiblity. I am mostly inclined to agree, which gives some useful flexibility here. > > If you're proposing a fix to a separate problem, is it something we can > > consider separately? > > It is closely related in any space to stick contexts to would also be space > to stick the hash flag to. Sure. -Ben From nobody Thu Apr 21 12:46:04 2016 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA57212E627 for ; Thu, 21 Apr 2016 12:46:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=amacapital-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y6JmwkRo-jjb for ; Thu, 21 Apr 2016 12:46:01 -0700 (PDT) Received: from mail-ob0-x233.google.com (mail-ob0-x233.google.com [IPv6:2607:f8b0:4003:c01::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D8ED912DD31 for ; Thu, 21 Apr 2016 12:46:00 -0700 (PDT) Received: by mail-ob0-x233.google.com with SMTP id bg3so38046043obb.1 for ; Thu, 21 Apr 2016 12:46:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amacapital-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=sfiwdFy6ugmRnOd5U+/y/MX7j1lJYtrLgRSLmB1vBHw=; b=XDGJPhyCSTZIiLaVmg4FVTvO5j+IAX2yYUkHc+1i1D9lAP0v+YDz2e0cHahd9Y7mrW lOh3gUaHo2172odCaBNJ8oeRNirNzxzRQOxonU2VHkgD7wd5pq2yDKRDgTZEWz/JTS8b XXUz8kud95WE57LzJ4vZMd4jiylIQBHaqtDPUeBIJJhZJmvP1y4Rh5H19wa7T833838H 5YSUASkAauEIODu4uqgT1hzhAEjvLspE4R8eijMh//rTeBCQUP+vxMHJWY86H8XENCPP y+Luti4ako3I8gnYX1I+ewCu6cW9UyNToukYZnJqwmoRkNFSSrVT2c2vvR5P2DnMCpjP LFIg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=sfiwdFy6ugmRnOd5U+/y/MX7j1lJYtrLgRSLmB1vBHw=; b=T21J1WvIcS33qXo0taV3U56dFSkqZN3oMSvm/aQW+KyzQ5x8B6sNA8O+Vt7JRDVgOg +cgBfONmAighfrMdx+K0g9f/16qKKh2mqCThVC3JnjcEt/lQ0n+L0ETLMQ32DWMp+C2Z eAwCPFYGCUFZOXAIhdFZgma5vDu9r2wWp2EKJxv/uZNb7x0r2cKFPKXCevW5gKV84NtE HvJ/4T/SONGkINCctnrteWErXuS6w42KuU4iYSbWwN4vz2USjbUrgdWIHJPUNBfv55hv N4F45cuY1Kk8nBzzzs1KjAcdYSNn8AibGhoUdLJvhidmfu0Jk3wK4S17y9k5cYAPfmlr 4oVQ== X-Gm-Message-State: AOPr4FXZe8CtAzS49TX2MqXa+rZZYXrXw5+fcEFgx/GITSD8UQLOmLN+jlQQ1fu2WF/qtlL+ZY1EzTCYf9Ay9Vxm X-Received: by 10.182.233.131 with SMTP id tw3mr7319671obc.80.1461267960047; Thu, 21 Apr 2016 12:46:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.202.80.135 with HTTP; Thu, 21 Apr 2016 12:45:40 -0700 (PDT) In-Reply-To: References: From: Andy Lutomirski Date: Thu, 21 Apr 2016 12:45:40 -0700 Message-ID: To: Adam Langley Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Yehuda Lindell , "cfrg@irtf.org" , Adam Langley Subject: Re: [Cfrg] Adopting "AES-GCM-SIV: Nonce Misuse-Resistant Authenticated Encryption" as a CFRG document ---- Some clarifications X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2016 19:46:03 -0000 On Thu, Apr 14, 2016 at 2:12 PM, Adam Langley wrote: > On Thu, Apr 7, 2016 at 4:55 PM, Adam Langley wrote: >> Will do as soon as I'm able (which should be next week). > > -03 is hopefully clearer on this point: > https://tools.ietf.org/html/draft-gueron-gcmsiv-03#section-4 This is much clearer to me. However: This record-encryption key is defined as the concatenation of the result of encrypting, using the AES key, the nonce with the least-significant bit of the first byte set to zero and then to one. Why is it designed this way? This has the odd property that the record encryption key is the same for two messages with nonces that differ only in the LSB of the first byte. Alternative designs include: a) Concatenate the results of encrypting the nonce and the none with the LSB of the first byte flipped. b) Concatenate the results of encrypting the nonce and the nonce + 1. Both of these will have related nonces generate related keys, but at least they won't generate the *same* key. It still seems to be that performance for short block sizes may be rather poor given the key setup needed. --Andy From nobody Thu Apr 21 12:50:32 2016 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0AC112DF6E; Thu, 21 Apr 2016 12:50:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.896 X-Spam-Level: X-Spam-Status: No, score=-2.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.996] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9wShNMEIBsyp; Thu, 21 Apr 2016 12:50:19 -0700 (PDT) Received: from welho-filter3.welho.com (welho-filter3.welho.com [83.102.41.25]) by ietfa.amsl.com (Postfix) with ESMTP id 079AB12DB98; Thu, 21 Apr 2016 12:50:19 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter3.welho.com (Postfix) with ESMTP id EA58431B2; Thu, 21 Apr 2016 22:50:17 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp2.welho.com ([IPv6:::ffff:83.102.41.85]) by localhost (welho-filter3.welho.com [::ffff:83.102.41.25]) (amavisd-new, port 10024) with ESMTP id A75kdi1HlfXt; Thu, 21 Apr 2016 22:50:17 +0300 (EEST) Received: from LK-Perkele-V2 (87-100-143-35.bb.dnainternet.fi [87.100.143.35]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp2.welho.com (Postfix) with ESMTPSA id 9D85321C; Thu, 21 Apr 2016 22:50:17 +0300 (EEST) Date: Thu, 21 Apr 2016 22:50:14 +0300 From: Ilari Liusvaara To: Benjamin Kaduk Message-ID: <20160421195014.GA26169@LK-Perkele-V2.elisa-laajakaista.fi> References: <87bn543id1.fsf@alice.fifthhorseman.net> <11c960b5f1fa42aaaf4cd0a6961332ec@usma1ex-dag1mb1.msg.corp.akamai.com> <87ziso1m0l.fsf@alice.fifthhorseman.net> <20160420142953.GA23528@LK-Perkele-V2.elisa-laajakaista.fi> <87potk1de7.fsf@alice.fifthhorseman.net> <20160420182617.GA23652@LK-Perkele-V2.elisa-laajakaista.fi> <87bn540xh3.fsf@alice.fifthhorseman.net> <20160421043947.GA24394@LK-Perkele-V2.elisa-laajakaista.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Sender: ilariliusvaara@welho.com Archived-At: Cc: =?utf-8?B?T25kxZllaiBTdXLDvQ==?= , "draft-irtf-cfrg-eddsa.all@ietf.org" , "Kaduk, Ben" , "cfrg@ietf.org" Subject: Re: [Cfrg] draft-irtf-cfrg-eddsa -- one final proposal for domain separation (context labels) for ed25519 X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2016 19:50:29 -0000 On Thu, Apr 21, 2016 at 02:30:50PM -0400, Benjamin Kaduk wrote: > On Thu, 21 Apr 2016, Ilari Liusvaara wrote: > > > On Wed, Apr 20, 2016 at 05:41:28PM -0400, Daniel Kahn Gillmor wrote: > > > > H(x)=SHA-512(context||x) without any lengths or separators does not behave > > that way. It does not have trivially computable collisions (but easily > > computed ones might still exist, or worse, a way to extract the private key). > > > > That is, signature for ('abc','def') is not expected to validate for > > ('abcd','ef'). > > I think I'm confused. Surely if I set chunk = { 'a', 'b', 'c', 'd', 'e', > 'f'} containing six octets, then SHA-512(chunk) is the same, whether I > construct chunk from 'abc','def' or 'abcd','ef'. So you must be talking > about something else, but I'm not sure what. I actually implemented the scheme (modifying the python reference implementation in the draft (modifying H(x) to be SHA512(context|x)). - Modified and base scheme generate identical signatures and validate identical signatures for empty context (as expected). - Signature of ('abc','def') is different from signature of ('abcd','ef') and does not cross-validate. Nor does either cross-validate with ('',abcdef). > > It is also not possible to compute the result using stock Ed25519 code > > with any non-empty context. > > Can you be more specific? Is the complaint just that one would need to > use a temporary buffer and copy the data to be signed in order to put in > the prefix? No. I am saying you can't put in the prefix unless you have Ed25519 implementation modified to support it. Buffering the message won't help. > > > With a context label, for every domain that defines a sane context > > > (e.g. the guidance i suggested of printable-ascii followed by '\0'), we > > > can rule out inter-domain replay as a successful forgery because no > > > context will be a prefix of any other context. > > > > Also, contexts cause large amount of API problems. And it is very easy > > to use in spec without understanding the problems, resulting spec that > > is very annoying to implement. > > >From where I am sitting, it seems like there are two options: does the > signing API include a context input? If yes, use that input; if no, > prepend the context to the message to be signed in my own code. What am I > missing? This does not work. -Ilari From nobody Thu Apr 21 13:00:32 2016 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91ECF12E1B3 for ; Thu, 21 Apr 2016 13:00:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.194 X-Spam-Level: X-Spam-Status: No, score=-5.194 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.996, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LXgMRBkTAzhJ for ; Thu, 21 Apr 2016 13:00:29 -0700 (PDT) Received: from llmx2.ll.mit.edu (LLMX2.LL.MIT.EDU [129.55.12.48]) by ietfa.amsl.com (Postfix) with ESMTP id CA50912E0F1 for ; Thu, 21 Apr 2016 13:00:28 -0700 (PDT) Received: from LLE2K10-HUB01.mitll.ad.local (LLE2K10-HUB01.mitll.ad.local) by llmx2.ll.mit.edu (unknown) with ESMTP id u3LJwtKC035369; Thu, 21 Apr 2016 15:58:55 -0400 From: "Blumenthal, Uri - 0553 - MITLL" To: Andy Lutomirski , Adam Langley Thread-Topic: [Cfrg] Adopting "AES-GCM-SIV: Nonce Misuse-Resistant Authenticated Encryption" as a CFRG document ---- Some clarifications Thread-Index: AQHRjz1rcBDJFfpWREmYbD5sdatNi59/a4CAgAAK8YCACtLeAIAK6AgA///BA4A= Date: Thu, 21 Apr 2016 20:00:23 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.2.160219 x-originating-ip: [172.25.177.156] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha384; boundary="B_3544099213_1175752" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-04-21_14:, , signatures=0 X-Proofpoint-Spam-Details: rule=inbound_notspam policy=inbound score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1603290000 definitions=main-1604210313 Archived-At: Cc: Yehuda Lindell , "cfrg@irtf.org" , Adam Langley Subject: Re: [Cfrg] Adopting "AES-GCM-SIV: Nonce Misuse-Resistant Authenticated Encryption" as a CFRG document ---- Some clarifications X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2016 20:00:30 -0000 --B_3544099213_1175752 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable >>-03 is hopefully clearer on this point: >> https://tools.ietf.org/html/draft-gueron-gcmsiv-03#section-4 > >This is much clearer to me. > >However: > > This record-encryption > key is defined as the concatenation of the result of encrypting, > using the AES key, the nonce with the least-significant bit of the > first byte set to zero and then to one. > >Why is it designed this way? This has the odd property that the >record encryption key is the same for two messages with nonces that >differ only in the LSB of the first byte. You=E2=80=99re right! >Alternative designs include: > >a) Concatenate the results of encrypting the nonce and the none with >the LSB of the first byte flipped. > >b) Concatenate the results of encrypting the nonce and the nonce + 1. Have we all forgot the good ol=E2=80=99 OFB mode? This seems a perfect use case for it. Take the 128-bit nonce as the seed and crank AES-256 engine twice to get two 128-bit pseudorandom blocks. Concatenate them and use as the record key. Same performance as what you=E2=80=99re getting, better security - an= d the advantage of staying with standardized block cipher modes :). >It still seems to be that performance for short block sizes may be >rather poor given the key setup needed. Can=E2=80=99t comment, but frankly don=E2=80=99t care much. --B_3544099213_1175752 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIQ4AYJKoZIhvcNAQcCoIIQ0TCCEM0CAQExDzANBglghkgBZQMEAgIFADALBgkqhkiG9w0B BwGggg6fMIIE6jCCA9KgAwIBAgIKMztKZQAAAABumTANBgkqhkiG9w0BAQsFADBRMQswCQYD VQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJ MRMwEQYDVQQDEwpNSVRMTCBDQS0zMB4XDTE2MDExNDE3MzMzN1oXDTE5MDExMzE3MzMzN1ow YTELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDzANBgNV BAsTBlBlb3BsZTEgMB4GA1UEAxMXQmx1bWVudGhhbC5VcmkuNTAwMTA1ODQwggEiMA0GCSqG SIb3DQEBAQUAA4IBDwAwggEKAoIBAQDqifs8K0OoodbmOo5G/j2+p2ibbOsEoJ9GJjK8K1Iw 6iig59a3EuNB6NR4tAR3INwjjUwMCa4o8ysnk1hN32B3HPrK5Z8++Y/xcX5iP1L6fc51YQ5C /EGvrSbjuPLvt19SNfVdwcuoc842Sgk9N/HemdwmvcqJkwzWDsuxKikI2clT1N5LTAaPMkhr HVuYOHBE0mCXjHjFnYuHsEXyVvUZLxziDgduV9WKbC90Z1NZMXB6ZeQTACUWgMfpFrE12LKb fvOmxepCBfCPbGB3ZyG+FaUdtQoCEAbGTnY7nCedQFn7pV1hppCt4jjLVlOpgYc3dPmyiXsL nhDQZ5ptmks/AgMBAAGjggGyMIIBrjAdBgNVHQ4EFgQUiXqPublGfd0sWKNk/BObT6Oorzgw DgYDVR0PAQH/BAQDAgbAMB8GA1UdIwQYMBaAFNdgZg57SY11TA39z0beyMcSh8q/MDMGA1Ud HwQsMCowKKAmoCSGImh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXRjcmwvTExDQTMwZgYIKwYB BQUHAQEEWjBYMC0GCCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8vTExD QTMwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLmxsLm1pdC5lZHUvb2NzcDA9BgkrBgEEAYI3 FQcEMDAuBiYrBgEEAYI3FQiDg+Udh+ynZoathxWD6vBFhbahHx2Fy94yh/+KcwIBZAIBBjAi BgNVHSUBAf8EGDAWBggrBgEFBQcDBAYKKwYBBAGCNwoDDDAYBgNVHSAEETAPMA0GCyqGSIb3 EgIBAwEIMBkGA1UdEQQSMBCBDnVyaUBsbC5taXQuZWR1MCcGCSsGAQQBgjcUAgQaHhgATABM AFUAcwBlAHIAUwBpAGcALQBTAFcwDQYJKoZIhvcNAQELBQADggEBAK7HM6o1IolvkCJrlsjj N1+0Z2JG8anwkHkVKAg/K9qUD0LE9zbnK3kZRGZsljJUDG+hMWmTWCkx0TTzbg/BeVrypVPD 7rn1Tagi9QBV2eJhdBZRHWOcsteRldUukKbMw74hkNGH9o/p/FFZYMA0kHnA7XfECilF9Yl6 uKDv1lbjuWdgcKD1FdEj7rL/IdX0wKJVUKjwLG1RQZel1nuwyRjVtXWz8IUMJXRsYHf6uSzy YoNBeZuWyMx/J5c0ACKXXs1O721GPJ5U5gcEaQ/b8lwQGcOgPk28RPwgiBF3f5TgrTa7QxGf ozmNsTj1OV1vU0vjqKrg7USi9q0xTdGUIyowggS8MIIDpKADAgECAgEpMA0GCSqGSIb3DQEB BQUAMFQxCzAJBgNVBAYTAlVTMR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQww CgYDVQQLEwNQS0kxFjAUBgNVBAMTDU1JVExMIFJvb3QgQ0EwHhcNMTMxMjE3MDAwMDAwWhcN MjAxMjMxMjM1OTU5WjBRMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFi b3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBDQS0zMIIBIjANBgkqhkiG 9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2jBSdW18tuW1tNxG6h8B0kqckFZQAAtoHCkvUpUEX6jF vBd8mQI53GyLYRuAo4HWJpe7/izFXOfSJDs6UM5ovvCOfXg2bJgDYlBC9JDcLBFIn0nppOu9 RvpjWSixtC56crwJ5Us5QPdtxtKdek5LJXl2oKw3w8lihUixePbxWad1m7ZMKKagvm9zTybP 6FumKRxeYJjSpB2+cAYjoGGEbSVHyx8uzHm6xAoBMHxa8by+yDz8Jzk6sP9iilgP3iXSGoCA mhyBzvlQQ5QNNWP+Emo9jz/ukKhYVB/VwdxtoquPAqn4ifDAIaM9dtb05cy1gXAFSP3Z/iUk xyBZZUORfwIDAQABo4IBmjCCAZYwEgYDVR0TAQH/BAgwBgEB/wIBADAdBgNVHQ4EFgQU12Bm DntJjXVMDf3PRt7IxxKHyr8wHwYDVR0jBBgwFoAUZ6p6z/QKprlytYqg0p3yEMND7SkwDgYD VR0PAQH/BAQDAgGGMGYGCCsGAQUFBwEBBFowWDAtBggrBgEFBQcwAoYhaHR0cDovL2NybC5s bC5taXQuZWR1L2dldHRvP0xMUkNBMCcGCCsGAQUFBzABhhtodHRwOi8vb2NzcC5sbC5taXQu ZWR1L29jc3AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC5sbC5taXQuZWR1L2dldGNy bD9MTFJDQTCBkgYDVR0gBIGKMIGHMA0GCyqGSIb3EgIBAwEGMA0GCyqGSIb3EgIBAwEIMA0G CyqGSIb3EgIBAwEHMA0GCyqGSIb3EgIBAwEJMA0GCyqGSIb3EgIBAwEKMA0GCyqGSIb3EgIB AwELMA0GCyqGSIb3EgIBAwEOMA0GCyqGSIb3EgIBAwEPMA0GCyqGSIb3EgIBAwEQMA0GCSqG SIb3DQEBBQUAA4IBAQAsf9HBn72qU7UTgkxarjAc7iynhcDEgWwezYKtd/SLGSQ0DhtzIV/L TCxqULjOd+H+HTqMJXB8+nHnzhyqQ43RsnGZOFT5RfzPh94db/ZJ3ql244DwlJI7yXBA2DkZ cEEgOWC9bHcrElzU6NnigahSW5odVJrhmH/XhQAcMS77E5H62yyxK1WPPgcBipGVnu1xSHbT iHe7DqfWQ2tVMLUf23XYhIua94kJsQd4jSh71NVD0e7F4snAoqQMI98MzDYeLOkjlzKRs77r /aMsPAKx6nMaOvRL7Cy0Pjp51i2qFkbGmX8ofnh2kerjTTvRJ/g22r1MV8RR1PktjMsNOsPf MIIE7TCCA9WgAwIBAgIKMziUjwAAAABuljANBgkqhkiG9w0BAQsFADBRMQswCQYDVQQGEwJV UzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYD VQQDEwpNSVRMTCBDQS0zMB4XDTE2MDExNDE3MzAzOVoXDTE5MDExMzE3MzAzOVowYTELMAkG A1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDzANBgNVBAsTBlBl b3BsZTEgMB4GA1UEAxMXQmx1bWVudGhhbC5VcmkuNTAwMTA1ODQwggEiMA0GCSqGSIb3DQEB AQUAA4IBDwAwggEKAoIBAQDjFDaGib07mHBdNaVMNpj9+4iJa+K9AcTN3y+iU1ygtvHG4cot eDBf77ZN1uwdt+lodW0C8XyG43suSfpNp/owLOUElFagAnPqHAvAUIwsl5AjzncpJP+78Ui4 u34aMNsddP+QZu9HI2Qg+P6eMD25jkjybT9dQMxXZpO2oTBznlWjYIItdZhK1DWZqIR0at7n 2YjCSQsZNX0lJ4JwrtjHYFrYPnnZC0f1B2M7V54IS863CEyfu5XotoZx8YuHwYpKSFq80SEh 6cMDLdTe1ZAjWxsnbyKC64rreStyI2PVN9uBWd+OleGoIAjVogpMKKi0pSRHcCuwDwGekpQV ubK9AgMBAAGjggG1MIIBsTAdBgNVHQ4EFgQU8U/FiJmibLZl2+KcNbVWE2PZipswDgYDVR0P AQH/BAQDAgUgMB8GA1UdIwQYMBaAFNdgZg57SY11TA39z0beyMcSh8q/MDMGA1UdHwQsMCow KKAmoCSGImh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXRjcmwvTExDQTMwZgYIKwYBBQUHAQEE WjBYMC0GCCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8vTExDQTMwJwYI KwYBBQUHMAGGG2h0dHA6Ly9vY3NwLmxsLm1pdC5lZHUvb2NzcDA9BgkrBgEEAYI3FQcEMDAu BiYrBgEEAYI3FQiDg+Udh+ynZoathxWD6vBFhbahHx2F69Bwg+vtIAIBZAIBBTAlBgNVHSUE HjAcBgRVHSUABggrBgEFBQcDBAYKKwYBBAGCNwoDBDAYBgNVHSAEETAPMA0GCyqGSIb3EgIB AwEIMBkGA1UdEQQSMBCBDnVyaUBsbC5taXQuZWR1MCcGCSsGAQQBgjcUAgQaHhgATABMAFUA cwBlAHIARQBuAGMALQBTAFcwDQYJKoZIhvcNAQELBQADggEBABbuvs9m0gS5U8JJuVc+qttV 2BWQ0jDepXpYfP/xN8rVScRPHe2SMUaFH5OMRhheGJkdogWVNnMrjHxQfpfc0z8yotlD3xwX ENWUY5MoQmpEGB2ksFqgMd121bqzR3WY84Lcosfow0MoplXs8mvO7TnozwM+PtGZs0mpp2Pz BkvWdNbs2r/7wXJP6/pLd5zPvywRNhTgoVe1aN4ivIkU8svkKMggv5ZaOsonaW8JS6dUYmvv k0QvDJRIQNRR0zpQpOKp+4V/XhMZRhxQJ3DjVTjh9Q/pHKm7ARFhFr3QAJ6ocCjyzLF5issa 1Vshx7ElBIk0cXhep6mLMLqGNX3azAkxggIFMIICAQIBATBfMFExCzAJBgNVBAYTAlVTMR8w HQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxEzARBgNVBAMT Ck1JVExMIENBLTMCCjM7SmUAAAAAbpkwDQYJYIZIAWUDBAICBQCgeTA/BgkqhkiG9w0BCQQx MgQw6uVJkxGn+tb/Snk9B2kqYmWBgHuOQpJSfAukF5/Cwn4kqMvCmqC7lm9MS4zK/zM2MBgG CSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE2MDQyMTIwMDAxM1ow DQYJKoZIhvcNAQEBBQAEggEAV63zpVMMVl1UhilBEO8QzQu9269+h7oSf4e5NLSVu34ACoHf accuDR5673SbPUKnLkZ/Rw0e86g0w1p/Xrc5ECppXNIDbggjdjnabD0y1hErz+X77QmcQCML APo79VqfKFO+b+b6ebWIReuvWTdQ5+RlCVNbh8gZpOdF/jUN800qrklJaiuYQBdcQnDH0rNZ g9HTrJGF5wfk1OkwJg+nkBqqGZM1BXyZpshAjdtx2gti49gxWbQU/aRWzCB7QqNZljBlEF1a Bo4CRJY7CK3OexHmaJJXFJjjOwI4vc/DmLoHmKJNj0rxXCbubft4t2adz+du76viumdTBsjN eB8a9g== --B_3544099213_1175752-- From nobody Thu Apr 21 13:07:03 2016 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 595C212E4FC for ; Thu, 21 Apr 2016 13:07:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hLnEGHSOaJZ5 for ; Thu, 21 Apr 2016 13:07:00 -0700 (PDT) Received: from mail-ob0-x235.google.com (mail-ob0-x235.google.com [IPv6:2607:f8b0:4003:c01::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 82D9512E41F for ; Thu, 21 Apr 2016 13:07:00 -0700 (PDT) Received: by mail-ob0-x235.google.com with SMTP id j9so38281544obd.3 for ; Thu, 21 Apr 2016 13:07:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=fyNQO9QS5LgBPqrALgins7jGxH++xUgXF/KLk6USSIw=; b=b5BZbhkz4zyp9YFM2QhWJ33NOc3MtMwQFm4ibagoAOCJfIo3BLWO5wNb5aer0jxwk7 ibqYjW7O5QPtNf8gx2f2PKcf1hWddJNX9Y0SfMuUxEIfy14FcjakMZPMAQwRCluIkqw8 /Cm4PlgiMlZBUrZGplRrzocMr4Rwhfqxad+JaHk7+Gef1mS99z+qf6wc1u1ZYMoXujEo gtLsy9ve/3GWKmeuDzRHIVpkLlU2VgP+k8anf4yYGOgKRtp+eTn5ENNJGs3G2bYdraAJ 8/2AyGvuMoqMsj1IjlE6kYvkWSbButIsnj3CFFQcZGiv61pW6xayUAomkwGNgIDG8fJZ /qHA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=fyNQO9QS5LgBPqrALgins7jGxH++xUgXF/KLk6USSIw=; b=CqgSenJj6h7cR0TkxJs1rqm1egtoJcg9+mCszErYFQf/ftyHf2eq0EtJ1G4CycL5cl guq8pBWNO0oDNXjDh2C/09z+fw23kbauDw78cvgEd0UNG48BBEYVg8zotL+uSy5XhwEX E7+qnY+J+nArzXoqCvQkkbhqaLimga0D8w2TfEIOo3z6mIcVyzWzb2DGyus8ZlZjAgNs NnToclHWVBQ/TQfvIJm5WqYsO+qVxkwTyJvii2zTqe2lcthSgeA+RqNLh4VoX9T2ucQm ErvqzBsbKdQE5j536apJXJWDZ5fzVrvSwaGOymSG+6evEhlHtfnj/ZCSd0KkeAfmDgE4 xXuw== X-Gm-Message-State: AOPr4FWGBcjFNJLquXxMuSZPUP0nQ2VQgGUbTMWcwfa3o1dVWT8rNWYnRkdhprTtqiigLyDjyo/2D/VWAq2DWg== MIME-Version: 1.0 X-Received: by 10.182.110.231 with SMTP id id7mr6961506obb.10.1461269219843; Thu, 21 Apr 2016 13:06:59 -0700 (PDT) Received: by 10.157.43.102 with HTTP; Thu, 21 Apr 2016 13:06:59 -0700 (PDT) In-Reply-To: References: Date: Thu, 21 Apr 2016 23:06:59 +0300 Message-ID: From: Shay Gueron To: Andy Lutomirski Content-Type: multipart/alternative; boundary=089e0115f536c5251905310440d4 Archived-At: Cc: Adam Langley , Yehuda Lindell , "cfrg@irtf.org" , Adam Langley Subject: Re: [Cfrg] Adopting "AES-GCM-SIV: Nonce Misuse-Resistant Authenticated Encryption" as a CFRG document ---- Some clarifications X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2016 20:07:02 -0000 --089e0115f536c5251905310440d4 Content-Type: text/plain; charset=UTF-8 Andy, Addressing your concern: >>> This has the odd property that the >>> record encryption key is the same for two messages with nonces that >>> differ only in the LSB of the first byte. This is not the case. What the spec states means the following: The record encryption key is derived by AES256 (NONCE[127:1] || 0) || AES256 (NONCE[127:1] || 1) I hope this helps clarifying. Regards, Shay 2016-04-21 22:45 GMT+03:00 Andy Lutomirski : > On Thu, Apr 14, 2016 at 2:12 PM, Adam Langley > wrote: > > On Thu, Apr 7, 2016 at 4:55 PM, Adam Langley > wrote: > >> Will do as soon as I'm able (which should be next week). > > > > -03 is hopefully clearer on this point: > > https://tools.ietf.org/html/draft-gueron-gcmsiv-03#section-4 > > This is much clearer to me. > > However: > > This record-encryption > key is defined as the concatenation of the result of encrypting, > using the AES key, the nonce with the least-significant bit of the > first byte set to zero and then to one. > > Why is it designed this way? This has the odd property that the > record encryption key is the same for two messages with nonces that > differ only in the LSB of the first byte. > > Alternative designs include: > > a) Concatenate the results of encrypting the nonce and the none with > the LSB of the first byte flipped. > > b) Concatenate the results of encrypting the nonce and the nonce + 1. > > Both of these will have related nonces generate related keys, but at > least they won't generate the *same* key. > > It still seems to be that performance for short block sizes may be > rather poor given the key setup needed. > > --Andy > --089e0115f536c5251905310440d4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Andy,=C2=A0
Addressing your concern:=C2=A0
>>> This has the odd property t= hat the
>>>=C2=A0record encryption key is the same for two messages with nonces= that
>>>=C2=A0differ only in the LSB of the first byte.
This is not the case. What the spec states mean= s the following:=C2=A0
The record encryption key is d= erived by

AES256 (NONCE[127:= 1] || 0) || AES256 (NONCE[127:1] || 1) =C2=A0

I hope this helps clarifying.=C2=A0
Regards, Shay=C2=A0




2016-04-21= 22:45 GMT+03:00 Andy Lutomirski <luto@amacapital.net>:
On Thu, Apr 14, 2016 at 2:12 PM, Adam = Langley <agl@imperialviolet.or= g> wrote:
> On Thu, Apr 7, 2016 at 4:55 PM, Adam Langley <agl@imperialviolet.org> wrote:
>> Will do as soon as I'm able (which should be next week).
>
> -03 is hopefully clearer on this point:
> https://tools.ietf.org/html/draft-g= ueron-gcmsiv-03#section-4

This is much clearer to me.

However:

=C2=A0 =C2=A0This record-encryption
=C2=A0 =C2=A0key is defined as the concatenation of the result of encryptin= g,
=C2=A0 =C2=A0using the AES key, the nonce with the least-s= ignificant bit of the
=C2=A0 =C2=A0first byte set to zero and then to one.

Why is it designed this way?=C2=A0 This has the odd property that th= e
record encryption key is the same for two messages with nonces that
differ only in the LSB of the first byte.

Alternative designs include:

a) Concatenate the results of encrypting the nonce and the none with
the LSB of the first byte flipped.

b) Concatenate the results of encrypting the nonce and the nonce + 1.

Both of these will have related nonces generate related keys, but at
least they won't generate the *same* key.

It still seems to be that performance for short block sizes may be
rather poor given the key setup needed.

--Andy

--089e0115f536c5251905310440d4-- From nobody Thu Apr 21 13:11:42 2016 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DABFE12E080 for ; Thu, 21 Apr 2016 13:11:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.193 X-Spam-Level: X-Spam-Status: No, score=-5.193 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.996, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eBsTffCGlNiT for ; Thu, 21 Apr 2016 13:11:39 -0700 (PDT) Received: from llmx2.ll.mit.edu (LLMX2.LL.MIT.EDU [129.55.12.48]) by ietfa.amsl.com (Postfix) with ESMTP id D431C12E04D for ; Thu, 21 Apr 2016 13:11:38 -0700 (PDT) Received: from LLE2K10-HUB02.mitll.ad.local (LLE2K10-HUB02.mitll.ad.local) by llmx2.ll.mit.edu (unknown) with ESMTP id u3LKA5Be044468; Thu, 21 Apr 2016 16:10:05 -0400 From: "Blumenthal, Uri - 0553 - MITLL" To: Shay Gueron , Andy Lutomirski Thread-Topic: [Cfrg] Adopting "AES-GCM-SIV: Nonce Misuse-Resistant Authenticated Encryption" as a CFRG document ---- Some clarifications Thread-Index: AQHRjz1rcBDJFfpWREmYbD5sdatNi59/a4CAgAAK8YCACtLeAIAK6AgAgAAF9YD//74rAA== Date: Thu, 21 Apr 2016 20:11:33 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.2.160219 x-originating-ip: [172.25.177.156] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha384; boundary="B_3544099882_1252712" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-04-21_14:, , signatures=0 X-Proofpoint-Spam-Details: rule=inbound_notspam policy=inbound score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1603290000 definitions=main-1604210315 Archived-At: Cc: Adam Langley , Yehuda Lindell , "cfrg@irtf.org" , Adam Langley Subject: Re: [Cfrg] Adopting "AES-GCM-SIV: Nonce Misuse-Resistant Authenticated Encryption" as a CFRG document ---- Some clarifications X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2016 20:11:41 -0000 --B_3544099882_1252712 Content-type: multipart/alternative; boundary="B_3544099882_1220352" --B_3544099882_1220352 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable I=E2=80=99m afraid Andy is correct. Say one record has its nonce xxxx=E2=80=A6xxxx0 (12= 7 bits plus 0), and another record has its nonce xxx=E2=80=A6xxx1. The record key produced for both records will be the same, because it clobbers/ignores the LSB. Again, why don=E2=80=99t you just use AES256-OFB to produce 256-bit record key? --=20 Regards, Uri Blumenthal From: Cfrg on behalf of Shay Gueron Date: Thursday, April 21, 2016 at 16:06 To: Andy Lutomirski Cc: Adam Langley , Yehuda Lindell , CFRG , Adam Langley Subject: Re: [Cfrg] Adopting "AES-GCM-SIV: Nonce Misuse-Resistant Authenticated Encryption" as a CFRG document ---- Some clarifications > Andy,=20 >=20 > Addressing your concern: >>>> >>> This has the odd property that the >>>> >>> record encryption key is the same for two messages with nonces tha= t >>>> >>> differ only in the LSB of the first byte. > This is not the case. What the spec states means the following: > The record encryption key is derived by >=20 > AES256 (NONCE[127:1] || 0) || AES256 (NONCE[127:1] || 1) >=20 > I hope this helps clarifying. > Regards, Shay=20 --B_3544099882_1220352 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable
I’m afraid An= dy is correct. Say one record has its nonce xxxx…xxxx0 (127 bits plus = 0), and another record has its nonce xxx…xxx1. The record key produced= for both records will be the same, because it clobbers/ignores the LSB.

Again, why don’t you just use AES256-OFB to prod= uce 256-bit record key?
-- 
Regards,
Uri Blumenthal

<= div style=3D"font-family:Calibri; font-size:11pt; text-align:left; color:black= ; BORDER-BOTTOM: medium none; BORDER-LEFT: medium none; PADDING-BOTTOM: 0in;= PADDING-LEFT: 0in; PADDING-RIGHT: 0in; BORDER-TOP: #b5c4df 1pt solid; BORDE= R-RIGHT: medium none; PADDING-TOP: 3pt">From:= Cfrg <cfrg-bounces@irtf.o= rg> on behalf of Shay Gueron <shay.gueron@gmail.com>
Date: Thursday, April 21, 2016 at 16:06
To= : Andy Lutomirski <luto@amac= apital.net>
Cc: Adam Langle= y <agl@imperialviolet.org>= , Yehuda Lindell <yehuda.lindel= l@biu.ac.il>, CFRG <cfrg@irtf.org>, Adam Langley <agl@google.com&= gt;
Subject: Re: [Cfrg] Adopting "= AES-GCM-SIV: Nonce Misuse-Resistant Authenticated Encryption" as a CFRG docu= ment ---- Some clarifications

Andy, 

Addressing your concern: 
>>> This has the odd= property that the
>>> record encryption key is the same for two messages with n= onces that
>>> differ only in the LSB of the first byte.
This is not the case. What the spec states means the = following: 
The record encryption key is derived by=

AES256 (NONCE[127:1] || 0) || AES256 = (NONCE[127:1] || 1)  

I hope thi= s helps clarifying. 
Re= gards, Shay 
--B_3544099882_1220352-- --B_3544099882_1252712 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIQ4AYJKoZIhvcNAQcCoIIQ0TCCEM0CAQExDzANBglghkgBZQMEAgIFADALBgkqhkiG9w0B BwGggg6fMIIE6jCCA9KgAwIBAgIKMztKZQAAAABumTANBgkqhkiG9w0BAQsFADBRMQswCQYD VQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJ MRMwEQYDVQQDEwpNSVRMTCBDQS0zMB4XDTE2MDExNDE3MzMzN1oXDTE5MDExMzE3MzMzN1ow YTELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDzANBgNV BAsTBlBlb3BsZTEgMB4GA1UEAxMXQmx1bWVudGhhbC5VcmkuNTAwMTA1ODQwggEiMA0GCSqG SIb3DQEBAQUAA4IBDwAwggEKAoIBAQDqifs8K0OoodbmOo5G/j2+p2ibbOsEoJ9GJjK8K1Iw 6iig59a3EuNB6NR4tAR3INwjjUwMCa4o8ysnk1hN32B3HPrK5Z8++Y/xcX5iP1L6fc51YQ5C /EGvrSbjuPLvt19SNfVdwcuoc842Sgk9N/HemdwmvcqJkwzWDsuxKikI2clT1N5LTAaPMkhr HVuYOHBE0mCXjHjFnYuHsEXyVvUZLxziDgduV9WKbC90Z1NZMXB6ZeQTACUWgMfpFrE12LKb fvOmxepCBfCPbGB3ZyG+FaUdtQoCEAbGTnY7nCedQFn7pV1hppCt4jjLVlOpgYc3dPmyiXsL nhDQZ5ptmks/AgMBAAGjggGyMIIBrjAdBgNVHQ4EFgQUiXqPublGfd0sWKNk/BObT6Oorzgw DgYDVR0PAQH/BAQDAgbAMB8GA1UdIwQYMBaAFNdgZg57SY11TA39z0beyMcSh8q/MDMGA1Ud HwQsMCowKKAmoCSGImh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXRjcmwvTExDQTMwZgYIKwYB BQUHAQEEWjBYMC0GCCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8vTExD QTMwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLmxsLm1pdC5lZHUvb2NzcDA9BgkrBgEEAYI3 FQcEMDAuBiYrBgEEAYI3FQiDg+Udh+ynZoathxWD6vBFhbahHx2Fy94yh/+KcwIBZAIBBjAi BgNVHSUBAf8EGDAWBggrBgEFBQcDBAYKKwYBBAGCNwoDDDAYBgNVHSAEETAPMA0GCyqGSIb3 EgIBAwEIMBkGA1UdEQQSMBCBDnVyaUBsbC5taXQuZWR1MCcGCSsGAQQBgjcUAgQaHhgATABM AFUAcwBlAHIAUwBpAGcALQBTAFcwDQYJKoZIhvcNAQELBQADggEBAK7HM6o1IolvkCJrlsjj N1+0Z2JG8anwkHkVKAg/K9qUD0LE9zbnK3kZRGZsljJUDG+hMWmTWCkx0TTzbg/BeVrypVPD 7rn1Tagi9QBV2eJhdBZRHWOcsteRldUukKbMw74hkNGH9o/p/FFZYMA0kHnA7XfECilF9Yl6 uKDv1lbjuWdgcKD1FdEj7rL/IdX0wKJVUKjwLG1RQZel1nuwyRjVtXWz8IUMJXRsYHf6uSzy YoNBeZuWyMx/J5c0ACKXXs1O721GPJ5U5gcEaQ/b8lwQGcOgPk28RPwgiBF3f5TgrTa7QxGf ozmNsTj1OV1vU0vjqKrg7USi9q0xTdGUIyowggS8MIIDpKADAgECAgEpMA0GCSqGSIb3DQEB BQUAMFQxCzAJBgNVBAYTAlVTMR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQww CgYDVQQLEwNQS0kxFjAUBgNVBAMTDU1JVExMIFJvb3QgQ0EwHhcNMTMxMjE3MDAwMDAwWhcN MjAxMjMxMjM1OTU5WjBRMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFi b3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBDQS0zMIIBIjANBgkqhkiG 9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2jBSdW18tuW1tNxG6h8B0kqckFZQAAtoHCkvUpUEX6jF vBd8mQI53GyLYRuAo4HWJpe7/izFXOfSJDs6UM5ovvCOfXg2bJgDYlBC9JDcLBFIn0nppOu9 RvpjWSixtC56crwJ5Us5QPdtxtKdek5LJXl2oKw3w8lihUixePbxWad1m7ZMKKagvm9zTybP 6FumKRxeYJjSpB2+cAYjoGGEbSVHyx8uzHm6xAoBMHxa8by+yDz8Jzk6sP9iilgP3iXSGoCA mhyBzvlQQ5QNNWP+Emo9jz/ukKhYVB/VwdxtoquPAqn4ifDAIaM9dtb05cy1gXAFSP3Z/iUk xyBZZUORfwIDAQABo4IBmjCCAZYwEgYDVR0TAQH/BAgwBgEB/wIBADAdBgNVHQ4EFgQU12Bm DntJjXVMDf3PRt7IxxKHyr8wHwYDVR0jBBgwFoAUZ6p6z/QKprlytYqg0p3yEMND7SkwDgYD VR0PAQH/BAQDAgGGMGYGCCsGAQUFBwEBBFowWDAtBggrBgEFBQcwAoYhaHR0cDovL2NybC5s bC5taXQuZWR1L2dldHRvP0xMUkNBMCcGCCsGAQUFBzABhhtodHRwOi8vb2NzcC5sbC5taXQu ZWR1L29jc3AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC5sbC5taXQuZWR1L2dldGNy bD9MTFJDQTCBkgYDVR0gBIGKMIGHMA0GCyqGSIb3EgIBAwEGMA0GCyqGSIb3EgIBAwEIMA0G CyqGSIb3EgIBAwEHMA0GCyqGSIb3EgIBAwEJMA0GCyqGSIb3EgIBAwEKMA0GCyqGSIb3EgIB AwELMA0GCyqGSIb3EgIBAwEOMA0GCyqGSIb3EgIBAwEPMA0GCyqGSIb3EgIBAwEQMA0GCSqG SIb3DQEBBQUAA4IBAQAsf9HBn72qU7UTgkxarjAc7iynhcDEgWwezYKtd/SLGSQ0DhtzIV/L TCxqULjOd+H+HTqMJXB8+nHnzhyqQ43RsnGZOFT5RfzPh94db/ZJ3ql244DwlJI7yXBA2DkZ cEEgOWC9bHcrElzU6NnigahSW5odVJrhmH/XhQAcMS77E5H62yyxK1WPPgcBipGVnu1xSHbT iHe7DqfWQ2tVMLUf23XYhIua94kJsQd4jSh71NVD0e7F4snAoqQMI98MzDYeLOkjlzKRs77r /aMsPAKx6nMaOvRL7Cy0Pjp51i2qFkbGmX8ofnh2kerjTTvRJ/g22r1MV8RR1PktjMsNOsPf MIIE7TCCA9WgAwIBAgIKMziUjwAAAABuljANBgkqhkiG9w0BAQsFADBRMQswCQYDVQQGEwJV UzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYD VQQDEwpNSVRMTCBDQS0zMB4XDTE2MDExNDE3MzAzOVoXDTE5MDExMzE3MzAzOVowYTELMAkG A1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDzANBgNVBAsTBlBl b3BsZTEgMB4GA1UEAxMXQmx1bWVudGhhbC5VcmkuNTAwMTA1ODQwggEiMA0GCSqGSIb3DQEB AQUAA4IBDwAwggEKAoIBAQDjFDaGib07mHBdNaVMNpj9+4iJa+K9AcTN3y+iU1ygtvHG4cot eDBf77ZN1uwdt+lodW0C8XyG43suSfpNp/owLOUElFagAnPqHAvAUIwsl5AjzncpJP+78Ui4 u34aMNsddP+QZu9HI2Qg+P6eMD25jkjybT9dQMxXZpO2oTBznlWjYIItdZhK1DWZqIR0at7n 2YjCSQsZNX0lJ4JwrtjHYFrYPnnZC0f1B2M7V54IS863CEyfu5XotoZx8YuHwYpKSFq80SEh 6cMDLdTe1ZAjWxsnbyKC64rreStyI2PVN9uBWd+OleGoIAjVogpMKKi0pSRHcCuwDwGekpQV ubK9AgMBAAGjggG1MIIBsTAdBgNVHQ4EFgQU8U/FiJmibLZl2+KcNbVWE2PZipswDgYDVR0P AQH/BAQDAgUgMB8GA1UdIwQYMBaAFNdgZg57SY11TA39z0beyMcSh8q/MDMGA1UdHwQsMCow KKAmoCSGImh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXRjcmwvTExDQTMwZgYIKwYBBQUHAQEE WjBYMC0GCCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8vTExDQTMwJwYI KwYBBQUHMAGGG2h0dHA6Ly9vY3NwLmxsLm1pdC5lZHUvb2NzcDA9BgkrBgEEAYI3FQcEMDAu BiYrBgEEAYI3FQiDg+Udh+ynZoathxWD6vBFhbahHx2F69Bwg+vtIAIBZAIBBTAlBgNVHSUE HjAcBgRVHSUABggrBgEFBQcDBAYKKwYBBAGCNwoDBDAYBgNVHSAEETAPMA0GCyqGSIb3EgIB AwEIMBkGA1UdEQQSMBCBDnVyaUBsbC5taXQuZWR1MCcGCSsGAQQBgjcUAgQaHhgATABMAFUA cwBlAHIARQBuAGMALQBTAFcwDQYJKoZIhvcNAQELBQADggEBABbuvs9m0gS5U8JJuVc+qttV 2BWQ0jDepXpYfP/xN8rVScRPHe2SMUaFH5OMRhheGJkdogWVNnMrjHxQfpfc0z8yotlD3xwX ENWUY5MoQmpEGB2ksFqgMd121bqzR3WY84Lcosfow0MoplXs8mvO7TnozwM+PtGZs0mpp2Pz BkvWdNbs2r/7wXJP6/pLd5zPvywRNhTgoVe1aN4ivIkU8svkKMggv5ZaOsonaW8JS6dUYmvv k0QvDJRIQNRR0zpQpOKp+4V/XhMZRhxQJ3DjVTjh9Q/pHKm7ARFhFr3QAJ6ocCjyzLF5issa 1Vshx7ElBIk0cXhep6mLMLqGNX3azAkxggIFMIICAQIBATBfMFExCzAJBgNVBAYTAlVTMR8w HQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxEzARBgNVBAMT Ck1JVExMIENBLTMCCjM7SmUAAAAAbpkwDQYJYIZIAWUDBAICBQCgeTA/BgkqhkiG9w0BCQQx MgQwg3cJEc8v1bAqtN77aR+IybgwolJqinmI/vhKngijAP8oAFUAjnI1OSjSYmJvQtuSMBgG CSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE2MDQyMTIwMTEyMlow DQYJKoZIhvcNAQEBBQAEggEAFEQlV6dta7anFyHsAQgQNOjEg++Zc9VUJfdYFaCV0Q+FINCb ceMsTVsNzCJoio7pzPMGz4n1AMP9hbSFh5iUeMPC+KhBKqg7kGDBMT0UqeqtvOSEHnplYFor Hj0QbiKKiersuc8TyLs3r4ZyERKyqJRdv+SLT2DLVWT5/sDjvfqhPYo3gNF3xqGJGcdz9Dts 2gspSRrn0oKyPHJQZAQZ0LjUQ4VI+KBlMTbOXngYlKbotU95yXgy1MSeeIFLdKeqJKd9wDL3 OaNnVG/RGtrAKlPRSvc9aSWvlxz8kAq2s3FPmANDwkezsH/9rwABPWb/POcKOozYrcI4qwhu u/wM7A== --B_3544099882_1252712-- From nobody Thu Apr 21 13:28:13 2016 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF87812E23A for ; Thu, 21 Apr 2016 13:28:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.4 X-Spam-Level: X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1HP7Ex15CKSX for ; Thu, 21 Apr 2016 13:28:09 -0700 (PDT) Received: from mail-ig0-x235.google.com (mail-ig0-x235.google.com [IPv6:2607:f8b0:4001:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C3A1B12E21E for ; Thu, 21 Apr 2016 13:28:09 -0700 (PDT) Received: by mail-ig0-x235.google.com with SMTP id bi2so5339485igb.0 for ; Thu, 21 Apr 2016 13:28:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-transfer-encoding; bh=GJqEwc6sYCo8fDzsspWN657GZu0lkPthjCDPovcCY+M=; b=deYOZl0nuZHPXHhqSu8uieuuJdb4z7RmtLULk50No+v3Vfin6XBaYfkq/G23wjzox6 TElDVv22YTvTVw8sjASgsxC66CkgP2zyxgAtlcr0JoJnRefec0TgbGKOgsHrKBLle9h2 /+W7atoyLiuQ3bZsdEINALvj2NagzdPbORqH0pVjCydvo4yEEQI6B02pTgveuhPIfDmx F6DQFhe84Y6KBzllg9uRAuXrvUUHiZgUv1nwQWfcy/p/R4lWlwb/b7GJZjxjyjpTke2A SXbaUmsz5SFQVmRJOAi21F1+fBc7VItyhosXZX2WU2/J++ba++szmHGQRDwtH2d71srQ UdCw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc:content-transfer-encoding; bh=GJqEwc6sYCo8fDzsspWN657GZu0lkPthjCDPovcCY+M=; b=kNwcLu9543Xw/xF2cahGHJX7TL8uaDWOeAYVqBNrfG0V2V2SvMBMK/pddSIXiYOoYf dCBIVcxoxHKtEY3rpjFvbqf3UEdb4WPKz1xNrhJjjjkZ2Mk8i9wUiBfpo33ZfS0IeTqd m77whJRFbdJ1LAL95kM8HclWUMClCFysyTTHgMry1bX4lWcxp4ni+5gspgZ5o+78GLQX eA0Wvzjop/XIxGgOJZVMiCI1PdV6Zv4ZZod+W0In8BylHRRCesYil0AIKurlt1+EGSiO XPt8ldMB++jLJYxHm5lm1uXhTq9n7BaEczLCVSHnU3dB614Ak3UhzEIZkv2FM5TQYbbZ 6SgQ== X-Gm-Message-State: AOPr4FUzaHwEDrhQNt1lk1fr1LmDHiCCnD8foNbn0X4vg2L7BYBiAamKwv95ywgRf6bsr4aUldbUK1mT57yfrw== MIME-Version: 1.0 X-Received: by 10.50.8.97 with SMTP id q1mr6299912iga.26.1461270489196; Thu, 21 Apr 2016 13:28:09 -0700 (PDT) Sender: alangley@gmail.com Received: by 10.79.117.133 with HTTP; Thu, 21 Apr 2016 13:28:08 -0700 (PDT) In-Reply-To: References: Date: Thu, 21 Apr 2016 13:28:08 -0700 X-Google-Sender-Auth: M2OgTCmAXaXzpb_mzD2TNl749kc Message-ID: From: Adam Langley To: "Blumenthal, Uri - 0553 - MITLL" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Yehuda Lindell , "cfrg@irtf.org" , Adam Langley Subject: Re: [Cfrg] Adopting "AES-GCM-SIV: Nonce Misuse-Resistant Authenticated Encryption" as a CFRG document ---- Some clarifications X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2016 20:28:11 -0000 On Thu, Apr 21, 2016 at 1:11 PM, Blumenthal, Uri - 0553 - MITLL wrote: > I=E2=80=99m afraid Andy is correct. Say one record has its nonce xxxx=E2= =80=A6xxxx0 (127 > bits plus 0), and another record has its nonce xxx=E2=80=A6xxx1. The reco= rd key > produced for both records will be the same, because it clobbers/ignores t= he > LSB. That is what I understood when I wrote those words. I might have misunderstood Shay however! This is the reason that the Security Considerations section mentions that it's only safe to repeat an nonce 2^31 (rather than 2^32) times with the AES-256 version. Cheers AGL From nobody Thu Apr 21 13:35:13 2016 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A594212D13A for ; Thu, 21 Apr 2016 13:35:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.195 X-Spam-Level: X-Spam-Status: No, score=-5.195 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.996, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wm9QKqZVo36R for ; Thu, 21 Apr 2016 13:35:11 -0700 (PDT) Received: from llmx2.ll.mit.edu (LLMX2.LL.MIT.EDU [129.55.12.48]) by ietfa.amsl.com (Postfix) with ESMTP id 3616012D4FE for ; Thu, 21 Apr 2016 13:35:06 -0700 (PDT) Received: from LLE2K10-HUB01.mitll.ad.local (LLE2K10-HUB01.mitll.ad.local) by llmx2.ll.mit.edu (unknown) with ESMTP id u3LKXWLH013578; Thu, 21 Apr 2016 16:33:32 -0400 From: "Blumenthal, Uri - 0553 - MITLL" To: Adam Langley Thread-Topic: [Cfrg] Adopting "AES-GCM-SIV: Nonce Misuse-Resistant Authenticated Encryption" as a CFRG document ---- Some clarifications Thread-Index: AdGcDUYLcBDJFfpWREmYbD5sdatNiw== Date: Thu, 21 Apr 2016 20:34:59 +0000 Message-ID: <20160421203508.18280531.2616.64664@ll.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="===============1020408215==" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-04-21_15:, , signatures=0 X-Proofpoint-Spam-Details: rule=inbound_notspam policy=inbound score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1603290000 definitions=main-1604210322 Archived-At: Cc: Yehuda Lindell , "cfrg@irtf.org" , Adam Langley Subject: Re: [Cfrg] Adopting "AES-GCM-SIV: Nonce Misuse-Resistant Authenticated Encryption" as a CFRG document ---- Some clarifications X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2016 20:35:12 -0000 --===============1020408215== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable For the 3rd time: why not generate record key using AES-OFB? Sent=C2=A0from=C2=A0my=C2=A0BlackBerry=C2=A010=C2=A0smartphone=C2=A0on=C2= =A0the Verizon=C2=A0Wireless=C2=A04G=C2=A0LTE=C2=A0network. =C2=A0 Original Message =C2=A0 From: Adam Langley Sent: Thursday, April 21, 2016 16:28 To: Blumenthal, Uri - 0553 - MITLL Cc: Shay Gueron; Andy Lutomirski; Yehuda Lindell; cfrg@irtf.org; Adam Langl= ey Subject: Re: [Cfrg] Adopting "AES-GCM-SIV: Nonce Misuse-Resistant Authentic= ated Encryption" as a CFRG document ---- Some clarifications On Thu, Apr 21, 2016 at 1:11 PM, Blumenthal, Uri - 0553 - MITLL wrote: > I=E2=80=99m afraid Andy is correct. Say one record has its nonce xxxx=E2= =80=A6xxxx0 (127 > bits plus 0), and another record has its nonce xxx=E2=80=A6xxx1. The reco= rd key > produced for both records will be the same, because it clobbers/ignores t= he > LSB. That is what I understood when I wrote those words. I might have misunderstood Shay however! This is the reason that the Security Considerations section mentions that it's only safe to repeat an nonce 2^31 (rather than 2^32) times with the AES-256 version. Cheers AGL --===============1020408215== Content-Type: application/x-pkcs7-signature; name="smime.p7s" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExDTALBglghkgBZQMEAgEwgAYJKoZIhvcNAQcBAACggg7NMIIE 6jCCA9KgAwIBAgIKMz1Y1wAAAABunjANBgkqhkiG9w0BAQsFADBRMQswCQYDVQQGEwJVUzEfMB0G A1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRM TCBDQS0zMB4XDTE2MDExNDE3MzU1MloXDTE5MDExMzE3MzU1MlowYTELMAkGA1UEBhMCVVMxHzAd BgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDzANBgNVBAsTBlBlb3BsZTEgMB4GA1UEAxMX Qmx1bWVudGhhbC5VcmkuNTAwMTA1ODQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCz HVEw2ojNZjWEnTASyJaQIvzziBmrH07FzMEY2xFGNDJpss38CcFRjfRx1EyEp7BrFdAXC2pHjFwa gFr+McYdXZiKEci0Mzna2uibsMDVbhlT6TwtmAL6QzdtjN28dn+7vQUkRUWUm9VVaBVVxUgX3f2l oEZsJNvWb7C8vj2DZF/uEt/EU/9KcUuodMgCR4zYLFVpNh1U6tCYACNDNtj/nmNjubtez1Y56zjZ AVOXZWsjNCPrC2jVwDdg1AIcs5ayDMOC2p1F95kSxWsJwinKfSe8p2/YR/cwUo8ljFoBPj60AGW3 WjaJyKXK+ZgJwjwl9gG/pg2T4mQhIAIZWZQ9AgMBAAGjggGyMIIBrjAdBgNVHQ4EFgQUtKJz3aEd G/MvxjE38EW6PHdcUDQwDgYDVR0PAQH/BAQDAgbAMB8GA1UdIwQYMBaAFNdgZg57SY11TA39z0be yMcSh8q/MDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXRjcmwvTExD QTMwZgYIKwYBBQUHAQEEWjBYMC0GCCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0 dG8vTExDQTMwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLmxsLm1pdC5lZHUvb2NzcDA9BgkrBgEE AYI3FQcEMDAuBiYrBgEEAYI3FQiDg+Udh+ynZoathxWD6vBFhbahHx2Fy94yh/+KcwIBZAIBBjAi BgNVHSUBAf8EGDAWBggrBgEFBQcDBAYKKwYBBAGCNwoDDDAYBgNVHSAEETAPMA0GCyqGSIb3EgIB AwEIMBkGA1UdEQQSMBCBDnVyaUBsbC5taXQuZWR1MCcGCSsGAQQBgjcUAgQaHhgATABMAFUAcwBl AHIAUwBpAGcALQBTAFcwDQYJKoZIhvcNAQELBQADggEBAJTu0/WcX0ebe9UfUMslvy9fC2aCQong cVcEKlEjU8IvCKa6YpZHQKTVXQ3e4KKvw1DgzFvq8/rOv87Woj45q8smgNyivgAMCnrT7a6B/9Kn 85l9BjeoLMPLypvsmz1l7oX45NPr3LF4VEMzxqczdovS14woPKdegEKQYyPSZGhKTCCe/9FhtgEc 3gfVyE1mH6ZNeDEalr7nx7F0qemhh3QN6i6XPrudzv9el5JeovPedZ0JqDT0ctXj6ECYOiEyEfJm 85C5QGmpjLmCM99gAmgpP5Tx6APB/tvcUw/mgt4HOvqavGkvUkoJ8XEEwt9AgXaznS626Kb8RpAh w2zN2yMwggTqMIID0qADAgECAgozPVjXAAAAAG6eMA0GCSqGSIb3DQEBCwUAMFExCzAJBgNVBAYT AlVTMR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxEzARBgNV BAMTCk1JVExMIENBLTMwHhcNMTYwMTE0MTczNTUyWhcNMTkwMTEzMTczNTUyWjBhMQswCQYDVQQG EwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEPMA0GA1UECxMGUGVvcGxlMSAw HgYDVQQDExdCbHVtZW50aGFsLlVyaS41MDAxMDU4NDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBALMdUTDaiM1mNYSdMBLIlpAi/POIGasfTsXMwRjbEUY0MmmyzfwJwVGN9HHUTISnsGsV 0BcLakeMXBqAWv4xxh1dmIoRyLQzOdra6JuwwNVuGVPpPC2YAvpDN22M3bx2f7u9BSRFRZSb1VVo FVXFSBfd/aWgRmwk29ZvsLy+PYNkX+4S38RT/0pxS6h0yAJHjNgsVWk2HVTq0JgAI0M22P+eY2O5 u17PVjnrONkBU5dlayM0I+sLaNXAN2DUAhyzlrIMw4LanUX3mRLFawnCKcp9J7ynb9hH9zBSjyWM WgE+PrQAZbdaNonIpcr5mAnCPCX2Ab+mDZPiZCEgAhlZlD0CAwEAAaOCAbIwggGuMB0GA1UdDgQW BBS0onPdoR0b8y/GMTfwRbo8d1xQNDAOBgNVHQ8BAf8EBAMCBsAwHwYDVR0jBBgwFoAU12BmDntJ jXVMDf3PRt7IxxKHyr8wMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC5sbC5taXQuZWR1L2dl dGNybC9MTENBMzBmBggrBgEFBQcBAQRaMFgwLQYIKwYBBQUHMAKGIWh0dHA6Ly9jcmwubGwubWl0 LmVkdS9nZXR0by9MTENBMzAnBggrBgEFBQcwAYYbaHR0cDovL29jc3AubGwubWl0LmVkdS9vY3Nw MD0GCSsGAQQBgjcVBwQwMC4GJisGAQQBgjcVCIOD5R2H7Kdmhq2HFYPq8EWFtqEfHYXL3jKH/4pz AgFkAgEGMCIGA1UdJQEB/wQYMBYGCCsGAQUFBwMEBgorBgEEAYI3CgMMMBgGA1UdIAQRMA8wDQYL KoZIhvcSAgEDAQgwGQYDVR0RBBIwEIEOdXJpQGxsLm1pdC5lZHUwJwYJKwYBBAGCNxQCBBoeGABM AEwAVQBzAGUAcgBTAGkAZwAtAFMAVzANBgkqhkiG9w0BAQsFAAOCAQEAlO7T9ZxfR5t71R9QyyW/ L18LZoJCieBxVwQqUSNTwi8IprpilkdApNVdDd7goq/DUODMW+rz+s6/ztaiPjmryyaA3KK+AAwK etPtroH/0qfzmX0GN6gsw8vKm+ybPWXuhfjk0+vcsXhUQzPGpzN2i9LXjCg8p16AQpBjI9JkaEpM IJ7/0WG2ARzeB9XITWYfpk14MRqWvufHsXSp6aGHdA3qLpc+u53O/16Xkl6i8951nQmoNPRy1ePo QJg6ITIR8mbzkLlAaamMuYIz32ACaCk/lPHoA8H+29xTD+aC3gc6+pq8aS9SSgnxcQTC30CBdrOd LrbopvxGkCHDbM3bIzCCBO0wggPVoAMCAQICCjM4lI8AAAAAbpYwDQYJKoZIhvcNAQELBQAwUTEL MAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsTA1BL STETMBEGA1UEAxMKTUlUTEwgQ0EtMzAeFw0xNjAxMTQxNzMwMzlaFw0xOTAxMTMxNzMwMzlaMGEx CzAJBgNVBAYTAlVTMR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQ8wDQYDVQQLEwZQ ZW9wbGUxIDAeBgNVBAMTF0JsdW1lbnRoYWwuVXJpLjUwMDEwNTg0MIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEA4xQ2hom9O5hwXTWlTDaY/fuIiWvivQHEzd8volNcoLbxxuHKLXgwX++2 TdbsHbfpaHVtAvF8huN7Lkn6Taf6MCzlBJRWoAJz6hwLwFCMLJeQI853KST/u/FIuLt+GjDbHXT/ kGbvRyNkIPj+njA9uY5I8m0/XUDMV2aTtqEwc55Vo2CCLXWYStQ1maiEdGre59mIwkkLGTV9JSeC cK7Yx2Ba2D552QtH9QdjO1eeCEvOtwhMn7uV6LaGcfGLh8GKSkhavNEhIenDAy3U3tWQI1sbJ28i guuK63krciNj1TfbgVnfjpXhqCAI1aIKTCiotKUkR3ArsA8BnpKUFbmyvQIDAQABo4IBtTCCAbEw HQYDVR0OBBYEFPFPxYiZomy2ZdvinDW1VhNj2YqbMA4GA1UdDwEB/wQEAwIFIDAfBgNVHSMEGDAW gBTXYGYOe0mNdUwN/c9G3sjHEofKvzAzBgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLmxsLm1p dC5lZHUvZ2V0Y3JsL0xMQ0EzMGYGCCsGAQUFBwEBBFowWDAtBggrBgEFBQcwAoYhaHR0cDovL2Ny bC5sbC5taXQuZWR1L2dldHRvL0xMQ0EzMCcGCCsGAQUFBzABhhtodHRwOi8vb2NzcC5sbC5taXQu ZWR1L29jc3AwPQYJKwYBBAGCNxUHBDAwLgYmKwYBBAGCNxUIg4PlHYfsp2aGrYcVg+rwRYW2oR8d hevQcIPr7SACAWQCAQUwJQYDVR0lBB4wHAYEVR0lAAYIKwYBBQUHAwQGCisGAQQBgjcKAwQwGAYD VR0gBBEwDzANBgsqhkiG9xICAQMBCDAZBgNVHREEEjAQgQ51cmlAbGwubWl0LmVkdTAnBgkrBgEE AYI3FAIEGh4YAEwATABVAHMAZQByAEUAbgBjAC0AUwBXMA0GCSqGSIb3DQEBCwUAA4IBAQAW7r7P ZtIEuVPCSblXPqrbVdgVkNIw3qV6WHz/8TfK1UnETx3tkjFGhR+TjEYYXhiZHaIFlTZzK4x8UH6X 3NM/MqLZQ98cFxDVlGOTKEJqRBgdpLBaoDHddtW6s0d1mPOC3KLH6MNDKKZV7PJrzu056M8DPj7R mbNJqadj8wZL1nTW7Nq/+8FyT+v6S3ecz78sETYU4KFXtWjeIryJFPLL5CjIIL+WWjrKJ2lvCUun VGJr75NELwyUSEDUUdM6UKTiqfuFf14TGUYcUCdw41U44fUP6RypuwERYRa90ACeqHAo8syxeYrL GtVbIcexJQSJNHF4XqepizC6hjV92swJMYIB8TCCAe0CAQEwXzBRMQswCQYDVQQGEwJVUzEfMB0G A1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRM TCBDQS0zAgozPVjXAAAAAG6eMAsGCWCGSAFlAwQCAaBpMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTE2MDQyMTIwMzUwN1owLwYJKoZIhvcNAQkEMSIEICu0gsuZPg93 pKYOum9s2oJ3Fbspnk+5hBMMUUt9GpZoMAsGCSqGSIb3DQEBCwSCAQCgV7iXn25th7zhsdB+Sh0a +krZJSjRkV86pPfPxKO/KL7GlFLb0iegPYRLRTEuN7ruWLBQl2d02qtkCkNTk1G8zQ24D/uDrxJO 36MpJRtdIp/Fm1/Akzff1eqt7R61d/u6EK7dyLqYumMnw4jWl1nMtrMzr5zGdpe85HCVLDmCKsy6 K+t7J2t1rQbvxJXke4wOQQCg002zADb4HujIwhCKXtgnP/yCJkVRpXtL//GRBtQONvlw8Js2HPkx EiUEfseDpXnNE7DFqpHLLUKkw6jXFaYGCEcg2vSDXdBB+P0Olb1In3fEHrknkIW1GI2AyQWW4xFK NRP0i9V9kaFcAOm/AAAAAAAA --===============1020408215==-- From nobody Thu Apr 21 13:38:45 2016 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09C3712E04C for ; Thu, 21 Apr 2016 13:38:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.929 X-Spam-Level: X-Spam-Status: No, score=-1.929 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_WEB=0.77, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gb7T_dgqjeLz for ; Thu, 21 Apr 2016 13:38:41 -0700 (PDT) Received: from mail-wm0-x234.google.com (mail-wm0-x234.google.com [IPv6:2a00:1450:400c:c09::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6EFFC12D92C for ; Thu, 21 Apr 2016 13:38:41 -0700 (PDT) Received: by mail-wm0-x234.google.com with SMTP id n3so151427862wmn.0 for ; Thu, 21 Apr 2016 13:38:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:cc:date:message-id:in-reply-to:reply-to:user-agent :mime-version; bh=sdMTEOKRvK1FQnTm6XC5VFE2x4Madw4NA+b2So0ZoXc=; b=NWERuSv5I7XX3ftDsZjR54VtNvv9V787biHHICne1hDhjlgJwlImQO3BRfVBYOzaGF tY+r/KdliwNTrcbuVfpIVmFbllpfHiOQ2A+E833d1cdoH8KeY8yAEOoa11kKthF3PTCg Gl8uEyTdVKKEwX9f+WTxfLlv3MRT60Vx67JA/8IXRit9rpHMcOMn1nU8gVm/M6UliU4j yaCP79BNIKANiZqXWTw+dEBPYfEQVSIebYpiccWnFdomiGri2e92JAnC23GYTYUMyYSR 6sTwkAk2X9HkM+AeIPVPa+dBpsIRqbgasuZdePw6OZFcK0kKpaVDt+ZepZNmG6xJ9x3B EfUA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:subject:cc:date:message-id:in-reply-to :reply-to:user-agent:mime-version; bh=sdMTEOKRvK1FQnTm6XC5VFE2x4Madw4NA+b2So0ZoXc=; b=dXssdnMOvxzOwH+ROVoEo9t59sNMEw4YtwTEoath/RrttngVmvmV9vK/Pt2fVRVM+i wjbHoGb19JZvEIKMSJCfbndqPHU3wYJsgfCmMXScVmBKb/ENmk+s2te3lsWvKElEAE5u 29cF1rsC3oNd6k9TBefn09ykG0F+7ZgF7FjLHP4F6HErka79ITGrmBnM38jmZEZTfYRV AmByBnz9/2Bc/c82/nPV04TvAD8DkVI78ugEBYDiux0hNvjqapuGKco28LlGGJQ/sivb g56DyOgb0h4SyAk/G/qWtxdXFmXHV1ILYAK+dZeq5TywGxZVfoQ4aGjoaQYaS/bkpQKh PTZQ== X-Gm-Message-State: AOPr4FVsf9d/9CzeyLiRUfjv53Wamqs+Xz/NiqsIN1X4xzgMLrggNSkA4++gCY5Q/aZLtw== X-Received: by 10.194.105.42 with SMTP id gj10mr16702325wjb.49.1461271119976; Thu, 21 Apr 2016 13:38:39 -0700 (PDT) Received: from [10.0.0.8] (bzq-79-176-18-212.red.bezeqint.net. [79.176.18.212]) by smtp.gmail.com with ESMTPSA id g78sm16664723wme.21.2016.04.21.13.38.36 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 21 Apr 2016 13:38:38 -0700 (PDT) From: "Gueron, Shay" To: "Blumenthal, Uri - 0553 - MITLL" , "Andy Lutomirski" Date: Thu, 21 Apr 2016 20:38:33 +0000 Message-Id: In-Reply-To: User-Agent: eM_Client/6.0.24316.0 Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="------=_MBE2A97618-334F-4B4D-96E8-D9D266BA8CDF" Archived-At: Cc: Adam Langley , Yehuda Lindell , "cfrg@irtf.org" , Adam Langley Subject: Re: [Cfrg] Adopting "AES-GCM-SIV: Nonce Misuse-Resistant Authenticated Encryption" as a CFRG document ---- Some clarifications X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: "Gueron, Shay" List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2016 20:38:44 -0000 --------=_MBE2A97618-334F-4B4D-96E8-D9D266BA8CDF Content-Type: text/plain; format=flowed; charset=utf-8 Content-Transfer-Encoding: quoted-printable OK, I did not understand what Andy meant... Indeed, for deriving the encryption in the 256-bit key case, the nonce=20 has effectively 127 bits. Repeating this (127-bit) nonce degenerates the encryption to using the=20 same 256-bit key. Still, the CTR mode encryption that follows, is not going to leak=20 information unless the same message (with the same 127-bit IV) is=20 encrypted. In such, the equality of the message is revelaed. But this is= =20 the nature of the deterministic processing, and this is what the nonce=20 misuse resistance provides. Of course, there is another consideration: if on top of all this, there=20 is a collision in the 96 bits of the CTR mode IV, which is derived from=20 the POLYAVAL universal hash (and the nonce). This is addressed in the=20 security considerations section. (as promised, exact bounds will follow in a paper that we will soon=20 release) Regards, Shay ------ Original Message ------ From: "Blumenthal, Uri - 0553 - MITLL" To: "Shay Gueron" ; "Andy Lutomirski"=20 Cc: "Adam Langley" ; "Yehuda Lindell"=20 ; "cfrg@irtf.org" ; "Adam=20 Langley" Sent: 4/21/2016 11:11:33 PM Subject: Re: [Cfrg] Adopting "AES-GCM-SIV: Nonce Misuse-Resistant=20 Authenticated Encryption" as a CFRG document ---- Some clarifications >I=E2=80=99m afraid Andy is correct. Say one record has its nonce xxxx=E2= =80=A6xxxx0=20 >(127 bits plus 0), and another record has its nonce xxx=E2=80=A6xxx1. The= =20 >record key produced for both records will be the same, because it=20 >clobbers/ignores the LSB. > >Again, why don=E2=80=99t you just use AES256-OFB to produce 256-bit record= key? >-- >Regards, >Uri Blumenthal > >From: Cfrg on behalf of Shay Gueron=20 > >Date: Thursday, April 21, 2016 at 16:06 >To: Andy Lutomirski >Cc: Adam Langley , Yehuda Lindell=20 >, CFRG , Adam Langley=20 > >Subject: Re: [Cfrg] Adopting "AES-GCM-SIV: Nonce Misuse-Resistant=20 >Authenticated Encryption" as a CFRG document ---- Some clarifications > >>Andy, >> >>Addressing your concern: >> >>> This has the odd property that the >> >>> record encryption key is the same for two messages with nonces=20 >>that >> >>> differ only in the LSB of the first byte. >>This is not the case. What the spec states means the following: >>The record encryption key is derived by >> >>AES256 (NONCE[127:1] || 0) || AES256 (NONCE[127:1] || 1) >> >>I hope this helps clarifying. >>Regards, Shay --------=_MBE2A97618-334F-4B4D-96E8-D9D266BA8CDF Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
OK, I did not understand what Andy meant...
 
Indeed, for deriving the encryption in the 256-bit key case, the nonce= has effectively 127 bits.
 
Repeating this (127-bit) nonce degenerates the encryption to using = the same 256-bit key.
 
Still, the CTR mode encryption that follows, is not going to leak info= rmation unless the same message (with the same 127-bit IV) is encrypted.= In such, the equality of the message is revelaed. But this is the nature= of the deterministic processing, and this is what the nonce misuse resista= nce provides.
 
Of course, there is another consideration: if on top of all this, ther= e is a collision in the 96 bits of the CTR mode IV, which is derived from= the POLYAVAL universal hash (and the nonce). This is addressed in the secu= rity considerations section.
(as promised, exact bounds will follow in a paper that we will soon= release)
 
Regards, Shay
 
 
------ Original Message ------
From: "Blumenthal, Uri - 0553 - MITLL" <uri@ll.mit.edu>
To: "Shay Gueron" <shay.gu= eron@gmail.com>; "Andy Lutomirski" <luto@amacapital.net>
Cc: "Adam Langley" <agl@i= mperialviolet.org>; "Yehuda Lindell" <yehuda.lindell@biu.ac.il>; "cfrg@irtf.org" <cfrg@irtf.org>; "Adam Langley" <agl@google.com>
Sent: 4/21/2016 11:11:33 PM
Subject: Re: [Cfrg] Adopting "AES-GCM-SIV: Nonce Misuse-Resistant Auth= enticated Encryption" as a CFRG document ---- Some clarifications
 
I=E2=80=99m afraid Andy is correct. Say one record has its nonce xxxx= =E2=80=A6xxxx0 (127 bits plus 0), and another record has its nonce xxx=E2= =80=A6xxx1. The record key produced for both records will be the same, beca= use it clobbers/ignores the LSB.

Again, why don=E2=80=99t you just use AES256-OFB to produce 256-bit= record key?
-- 
Regards,
Uri Blumenthal

From: Cfrg <cfrg-bounces@irtf.org> on behalf of Shay Gueron <shay.gueron@gmail.com>
Date: Thursday, April 21, 2016 at 16:06
To: Andy Lutomirski <luto@amacapital.net>
Cc: Adam Langley <agl@imperialviolet.org>, Yehuda Lindell <yehuda.lindell@biu.ac.il>, CFRG <cfrg@irtf.org>, Adam Langley <agl@google.com>
Subject: Re: [Cfrg] Adopting "AES-GCM-SIV: Nonce= Misuse-Resistant Authenticated Encryption" as a CFRG document ---- Some= clarifications

Andy, 

Addressing your concern: 
>>> This has the= odd property that the
>>> record = encryption key is the same for two messages with nonces that
>>> differ = only in the LSB of the first byte.
This is not the case. What the spec states means the followi= ng: 
The record encryption key is derived by

AES256 (NONCE[127:1] || 0)= || AES256 (NONCE[127:1] || 1)  

I hope this helps clarifying. 
Regards, Shay 
=
--------=_MBE2A97618-334F-4B4D-96E8-D9D266BA8CDF-- From nobody Thu Apr 21 13:43:21 2016 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DDA412E250; Thu, 21 Apr 2016 13:43:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dveVY2p27I-u; Thu, 21 Apr 2016 13:43:19 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [162.247.75.118]) by ietfa.amsl.com (Postfix) with ESMTP id 46AF712DD27; Thu, 21 Apr 2016 13:43:19 -0700 (PDT) Received: from fifthhorseman.net (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id 895A7F991; Thu, 21 Apr 2016 16:43:15 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id 6BDFB2038F; Thu, 21 Apr 2016 16:43:15 -0400 (EDT) From: Daniel Kahn Gillmor To: Ilari Liusvaara , Benjamin Kaduk In-Reply-To: <20160421195014.GA26169@LK-Perkele-V2.elisa-laajakaista.fi> References: <87bn543id1.fsf@alice.fifthhorseman.net> <11c960b5f1fa42aaaf4cd0a6961332ec@usma1ex-dag1mb1.msg.corp.akamai.com> <87ziso1m0l.fsf@alice.fifthhorseman.net> <20160420142953.GA23528@LK-Perkele-V2.elisa-laajakaista.fi> <87potk1de7.fsf@alice.fifthhorseman.net> <20160420182617.GA23652@LK-Perkele-V2.elisa-laajakaista.fi> <87bn540xh3.fsf@alice.fifthhorseman.net> <20160421043947.GA24394@LK-Perkele-V2.elisa-laajakaista.fi> <20160421195014.GA26169@LK-Perkele-V2.elisa-laajakaista.fi> User-Agent: Notmuch/0.21+128~g620f892 (http://notmuchmail.org) Emacs/24.5.1 (x86_64-pc-linux-gnu) Date: Thu, 21 Apr 2016 16:43:15 -0400 Message-ID: <87zismzo9o.fsf@alice.fifthhorseman.net> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Cc: =?utf-8?B?T25kxZllaiBTdXLDvQ==?= , "draft-irtf-cfrg-eddsa.all@ietf.org" , "Kaduk, Ben" , "cfrg@ietf.org" Subject: Re: [Cfrg] draft-irtf-cfrg-eddsa -- one final proposal for domain separation (context labels) for ed25519 X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2016 20:43:20 -0000 On Thu 2016-04-21 15:50:14 -0400, Ilari Liusvaara wrote: > I actually implemented the scheme (modifying the python reference > implementation in the draft (modifying H(x) to be SHA512(context|x)). > > - Modified and base scheme generate identical signatures and validate > identical signatures for empty context (as expected). > - Signature of ('abc','def') is different from signature of ('abcd','ef') > and does not cross-validate. Nor does either cross-validate with > ('',abcdef). Is this because you're including the NUL octet between the context and the signature, or for some other reason? if so, then i'd phrase it as: signature of ('abc\0', 'def') is different from signature of ('abcd\0', 'ef') which i think everyone would agree is the right outcome. Or are you talking about some other scheme? > [ben kaduk wrote:] >> From where I am sitting, it seems like there are two options: does >> the signing API include a context input? If yes, use that input; if >> no, prepend the context to the message to be signed in my own code. >> What am I missing? > > This does not work. Why not? Can you explain more? --dkg From nobody Thu Apr 21 13:54:29 2016 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A2F612E30E; Thu, 21 Apr 2016 13:54:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.217 X-Spam-Level: X-Spam-Status: No, score=-5.217 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bfiy6RrR0HJi; Thu, 21 Apr 2016 13:54:26 -0700 (PDT) Received: from dmz-mailsec-scanner-3.mit.edu (dmz-mailsec-scanner-3.mit.edu [18.9.25.14]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 55E8212DC05; Thu, 21 Apr 2016 13:54:26 -0700 (PDT) X-AuditID: 1209190e-cffff70000004bd5-51-57193e00768b Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by (Symantec Messaging Gateway) with SMTP id F1.75.19413.00E39175; Thu, 21 Apr 2016 16:54:25 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id u3LKsNa6027596; Thu, 21 Apr 2016 16:54:24 -0400 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id u3LKsJfh032517 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 21 Apr 2016 16:54:22 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id u3LKsIxI014518; Thu, 21 Apr 2016 16:54:18 -0400 (EDT) Date: Thu, 21 Apr 2016 16:54:18 -0400 (EDT) From: Benjamin Kaduk To: Daniel Kahn Gillmor In-Reply-To: <87zismzo9o.fsf@alice.fifthhorseman.net> Message-ID: References: <87bn543id1.fsf@alice.fifthhorseman.net> <11c960b5f1fa42aaaf4cd0a6961332ec@usma1ex-dag1mb1.msg.corp.akamai.com> <87ziso1m0l.fsf@alice.fifthhorseman.net> <20160420142953.GA23528@LK-Perkele-V2.elisa-laajakaista.fi> <87potk1de7.fsf@alice.fifthhorseman.net> <20160420182617.GA23652@LK-Perkele-V2.elisa-laajakaista.fi> <87bn540xh3.fsf@alice.fifthhorseman.net> <20160421043947.GA24394@LK-Perkele-V2.elisa-laajakaista.fi> <20160421195014.GA26169@LK-Perkele-V2.elisa-laajakaista.fi> <87zismzo9o.fsf@alice.fifthhorseman.net> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmplleLIzCtJLcpLzFFi42IR4hTV1mW0kww32J5q0bi5kdXi6K42FovW 7s9MFtfXPWW3eL97OovF9d1PmRzYPCYfWcDscba7ndVjyZKfTB4XDvcwe9zunsMWwBrFZZOS mpNZllqkb5fAlXHm7iHWgpMCFZfOt7I0MDbzdjFyckgImEgcnnOZrYuRi0NIoI1JYvbDw0wQ zkZGiZZtD5ghnENMElu6V7JAOA2MEqd7jzGD9LMIaEtMXTQPzGYTUJGY+WYjG4gtIqAvcebu BVYQm1mgm0ni6fFUEFtYoETixNyTYDWcAqYS/3pfg/XyCjhK/Jg4GWr1FxaJRS8WgCVEBXQk Vu+fwgJRJChxcuYTFoihWhLLp29jmcAoMAtJahaS1AJGplWMsim5Vbq5iZk5xanJusXJiXl5 qUW6xnq5mSV6qSmlmxjBoS3Jt4NxUoP3IUYBDkYlHl4OeYlwIdbEsuLK3EOMkhxMSqK8axUl w4X4kvJTKjMSizPii0pzUosPMUpwMCuJ8EZZAuV4UxIrq1KL8mFS0hwsSuK8jAwMDEIC6Ykl qdmpqQWpRTBZGQ4OJQneRTZAjYJFqempFWmZOSUIaSYOTpDhPEDDLUBqeIsLEnOLM9Mh8qcY FaXEeQVAEgIgiYzSPLhecOrZzaT6ilEc6BVh3h6QKh5g2oLrfgU0mAloMP9dUZDBJYkIKakG RvXiN9Zi3doL2vymCjToZD+IXOlWEdmVdF9uWRJHwM5YP4mv1Sw3JoheyQycWZoefNvZ3Hx1 cWkpn8inO9ENh74KZ/16q5j5K5f50Nopaxv6BGI1DNZKu3XcD9E2Wrsxls9bke/NVoGZc6tm Bc7SrBHt1fC2WHCk8FioaMjLR3y7Zh1/ZSqsxFKckWioxVxUnAgAC/2YXRgDAAA= Archived-At: Cc: =?ISO-8859-2?Q?Ond=F8ej_Sur=FD?= , "draft-irtf-cfrg-eddsa.all@ietf.org" , "Kaduk, Ben" , "cfrg@ietf.org" Subject: Re: [Cfrg] draft-irtf-cfrg-eddsa -- one final proposal for domain separation (context labels) for ed25519 X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2016 20:54:28 -0000 Hmm, Ilari's messages are not making it into either my MIT or my Akamai inbox; that's quite unfortunate. On Thu, 21 Apr 2016, Daniel Kahn Gillmor wrote: > On Thu 2016-04-21 15:50:14 -0400, Ilari Liusvaara wrote: > > I actually implemented the scheme (modifying the python reference > > implementation in the draft (modifying H(x) to be SHA512(context|x)). > > > > - Modified and base scheme generate identical signatures and validate > > identical signatures for empty context (as expected). > > - Signature of ('abc','def') is different from signature of ('abcd','ef') > > and does not cross-validate. Nor does either cross-validate with > > ('',abcdef). > > Is this because you're including