From nobody Sat Jul 1 14:58:55 2017 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 91A2E127137 for ; Sat, 1 Jul 2017 14:58:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=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 YUpu7bdiq2gd for ; Sat, 1 Jul 2017 14:58:52 -0700 (PDT) Received: from perseus.uberspace.de (perseus.uberspace.de [95.143.172.134]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E338F126BFD for ; Sat, 1 Jul 2017 14:58:51 -0700 (PDT) Received: (qmail 25203 invoked from network); 1 Jul 2017 21:58:49 -0000 Received: from localhost (HELO ?IPv6:2a01:2a8:8106:7b01:5a5:5673:5aac:3d14?) (127.0.0.1) by perseus.uberspace.de with SMTP; 1 Jul 2017 21:58:49 -0000 From: Philipp Jovanovic Content-Type: multipart/signed; boundary="Apple-Mail=_483BC09B-987C-414D-A11D-28621B4A0E0F"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Message-Id: <8AE29DD0-26FE-4AB6-A4A9-2BB9169BAB13@jovanovic.io> Date: Sat, 1 Jul 2017 23:58:47 +0200 To: cfrg@irtf.org X-Mailer: Apple Mail (2.3273) Archived-At: Subject: [Cfrg] Internet-Draft: Collective Edwards-Curve Digital Signature Algorithm X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Jul 2017 21:58:54 -0000 --Apple-Mail=_483BC09B-987C-414D-A11D-28621B4A0E0F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi CFRG, Here=E2=80=99s a first version of an Internet-Draft on =E2=80=9CCollective= Edwards-Curve Digital Signature Algorithms=E2=80=9D based on Ed25519 = and Ed448: https://datatracker.ietf.org/doc/draft-ford-cfrg-cosi/ We plan to give a short presentation on that topic at the next CFRG = meeting in Prague. Any feedback is more than welcome. Thanks! All the best, Philipp --Apple-Mail=_483BC09B-987C-414D-A11D-28621B4A0E0F Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEJ2105oKN5rKUY7SlsjtlYG7MZZwFAllYGxcACgkQsjtlYG7M ZZydjRAA2t6al5xQFyEVLKqMO2p4J28tQu+BzYCS3Lx5X7ecDPoXc2yJn0vf7tm2 6Wt23V2LoMwZowJvTyq7LYwjnm7ME2OAIVdaNliBZwIvxBD+zyBsN1MUdEYmHAG+ GmQie86BiHSKVDEpmNC8KlwkwpoYAY2YHdnojPHn1X1xb/5vpbaE84vvXk2y1H8n gT0TrhdVtd3yYtDo9SdVR5WZnE3I4fWPUhQ8lVK0r+DMtT/9xZPaEmQhZv89ckgI UnsNJ72z4HcLNxpX0RITNS3FVyifDP/72YTtYTspQPEC04CreVDTOH+H/irkxrOS LBQTc6VHHBdGHEKeJ9WW2jBeQc29UskxawzJa8AFgE8cd4dxdF2UzY9GZFpYQe/h 5wXV7eUUvQhEn3jwCtqkjE4Cb9zEEfo2QRyDo3Ym/EVLkpuZO3D3PInEo5QezNCh t+WsV/BcC8F+FlSYB3+btsGnfZ6K/6GudlUbZXZxpeKtsAhQqYfyv+KGBDothlfH yVALNpw30OnQwviurr0a7EOWgRFklPnShdyRT7uY93QP24AqGcE4bbGuLjwGQz3r xgDL+E/ir199woj+vrhUBI/6tRJQSdSB+IHRH+Fz2BT2ooZGjjWU3M+M+CzmhEIv SSO8tWsRnogyGU6KKdwk7C/wmBiAMTZ/71AdO4QguY06RyuNj6s= =4CVG -----END PGP SIGNATURE----- --Apple-Mail=_483BC09B-987C-414D-A11D-28621B4A0E0F-- From nobody Sun Jul 2 13:47:35 2017 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 62700129ACD for ; Sun, 2 Jul 2017 13:47:34 -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 uJjCwjnRH9xY for ; Sun, 2 Jul 2017 13:47:32 -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 23ABB129AC1 for ; Sun, 2 Jul 2017 13:47:32 -0700 (PDT) Received: by mail-lf0-x234.google.com with SMTP id b207so92765353lfg.2 for ; Sun, 02 Jul 2017 13:47:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ijySxrPCdDO1n3GyR5ToKGmd77qj3MRsX9Z9PjUPSwI=; b=Smq6UtQDAqqsIHrYxq+4SgIUOGVLS/LuYH4ONfRjBrqzCzFcWejLj3XzS4QvxAtHSA MjSBPJQEaoOSXWxD/848qjtaqiSuIrsTDfnxNpBSVqBPh/1PoJ9frraRU/yQJYzFG2cT CEMrLYE/Jknz/rcejx7LdB+A2k+BajXwPX+Q6D+bDq1ule7ilSvOIdUTD9dcy5yCmzK+ t4qLC4yZotYK9B2t4a6dZjcNl9dYhBAZDDZI//klVKxmApD85MThmXCGf91ww2z4VBc8 kB3t+R9MWfiiqULP7wHq4xENCiM2mb7DBuytg7TVADxqsv4TyIuPqbK4Zu0uBo1XZOAR mFBg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ijySxrPCdDO1n3GyR5ToKGmd77qj3MRsX9Z9PjUPSwI=; b=K1s0zUWHSREhbLbx2VmmMtBcgo50Fi0CCEt0j+au/qxMhUsBTtvLmAH8rrVGtePIG4 HyRt4lzDTverfnZ03doTCaOEv0ehAny3djINk47JTceFTEKQamJS/lvi8F4/UupoZQrL mRvOqNTrR5uoY+GA+AefiTOF3LhjcTMpcgEV35C6dU+kkLx0dlypqIACRTWvnk1jYINC Nxr1u90uShjUPo6B7Q0IwnKtVabWCUqQF0aWLnjoEGUB5LIthqQphp73k8H1jLiMNGsT +xYuxek4URiluiPNZ0UeLh4TTueWya9FnP1S3uC4n1oVJ7e6rHKEC7aJgrSfLhCrPK0I rwdw== X-Gm-Message-State: AKS2vOyUV85LGkkf6a5suQWWjjSnNIoRPK6v1ThtC2XqXnDhEHHeLnOl dab/5v83/yg06g== X-Received: by 10.25.89.65 with SMTP id n62mr10505398lfb.183.1499028450333; Sun, 02 Jul 2017 13:47:30 -0700 (PDT) Received: from [192.168.0.114] ([109.167.133.56]) by smtp.gmail.com with ESMTPSA id m16sm2194568ljb.26.2017.07.02.13.47.29 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 02 Jul 2017 13:47:29 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Oleg Andreev In-Reply-To: <8AE29DD0-26FE-4AB6-A4A9-2BB9169BAB13@jovanovic.io> Date: Sun, 2 Jul 2017 23:47:28 +0300 Cc: cfrg@irtf.org Content-Transfer-Encoding: quoted-printable Message-Id: <5E91769F-B102-4A49-9ED5-B789D4FED598@gmail.com> References: <8AE29DD0-26FE-4AB6-A4A9-2BB9169BAB13@jovanovic.io> To: Philipp Jovanovic X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Cfrg] Internet-Draft: Collective Edwards-Curve Digital Signature Algorithm X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Jul 2017 20:47:34 -0000 Hi, First of all: nice to see a simpler approach than a full SSSS-based = threshold signing scheme! After a quick glance at the spec, I have two security concerns: 1. It seems unsafe to add public keys directly (A =3D Sum[A_i]) without = multiplying them by their hashes (A =3D Sum[Hash(A_i)*A_i]). Without = that measure, it is possible to have A_j as a linear combination of = other public keys. See this discussion for details: = https://bitcointalk.org/index.php?topic=3D1377298.0 2. The signature does not commit to membership bitmask Z. Maybe it could = be argued that signature is not malleable (especially with an = improvement mentioned above), but to stay on safe side I think = committing to the exact set of signers is a good idea. Additionally, I'd suggest an improvement to the API. Since the scheme is = not a SSSS scheme, verifier needs to reconstruct the exact key from the = individual keys (4.3.5 Signature Verification). Current spec states that = verifier should know the set of these member-keys upfront. It could be = more practical to provide them as a part of the signature and commit = into the aggregate public key, so the setup process looks as simple as = non-aggregate one, or one using SSSS: just sharing a single aggregate = public key. This is how it could be done: 1. Organize all member keys in a merkle tree and compute it's root hash = `h`. 2. Compute intermediate aggregate key as `A =3D Sum[Hash(A_i)*A_i]`. 3. Compute aggregate public key with commitment to the merkle tree: `P =3D= Hash(A || h)*A`. 4. Signature will include: 1) necessary member keys according to bitmask Z. 2) merkle proof (necessary intermediate hashes needed to reconstruct = the root hash). 3) intermediate key A. 5. Verifier would reconstruct root hash h', compute `Hash(h' || A)*A` = and verify it matches the P. Then it will reconstruct actual = verification key `A' =3D A-T` and proceed with Schnorr protocol. The member keys part of the signature could be optional, so the keys = could be cached in case many signature from the same key are = continuously verified. Cheers, Oleg. > On 2 Jul 2017, at 00:58, Philipp Jovanovic = wrote: >=20 > Hi CFRG, >=20 > Here=E2=80=99s a first version of an Internet-Draft on =E2=80=9CCollecti= ve Edwards-Curve Digital Signature Algorithms=E2=80=9D based on Ed25519 = and Ed448: https://datatracker.ietf.org/doc/draft-ford-cfrg-cosi/ >=20 > We plan to give a short presentation on that topic at the next CFRG = meeting in Prague. >=20 > Any feedback is more than welcome. Thanks! >=20 > All the best, > Philipp > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > https://www.irtf.org/mailman/listinfo/cfrg From nobody Mon Jul 3 02:19:04 2017 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 D85DD13153C for ; Mon, 3 Jul 2017 02:19:01 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=onboardsecurity.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 qooRR35mYQwy for ; Mon, 3 Jul 2017 02:18:59 -0700 (PDT) Received: from mail-wr0-x22d.google.com (mail-wr0-x22d.google.com [IPv6:2a00:1450:400c:c0c::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 089ED131467 for ; Mon, 3 Jul 2017 02:18:59 -0700 (PDT) Received: by mail-wr0-x22d.google.com with SMTP id c11so231108691wrc.3 for ; Mon, 03 Jul 2017 02:18:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=onboardsecurity.com; s=google; h=mime-version:from:date:message-id:subject:to; bh=Z1gTlSynCtOcuW50Y7RjRygYEQ3AbaLcyqjUOpc/Dik=; b=g3su+1xvWftv/UJ36AbOPuqX9sqXdHyKOPCcslQrPwKWsEb6LQii5NQ4YNaahOI0Dk IdcoAIHfY2hCc+OprYlKiKZNXqEkdKSF15/SczNUibh2v2EUNOj73YYCTXgMEd79mSLY 81QHoAGAdwTqpY6LNWEr3YHaGLdWgKI+xUFi4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=Z1gTlSynCtOcuW50Y7RjRygYEQ3AbaLcyqjUOpc/Dik=; b=bhzutnopXxwC4MlyAHBn1SFK2FGcZmaMLLkKqowlrytALMnReBItBjKDYRjldvnufG aQ/SJlGLTQG5/+wBgwKETmYEkOeFFgXbzKoMpswL32f3f1Y9FsulPGtVnQ5/LDnuWjXn v4wHifdGfHEI1GsitCL9ApskoJ1whOmo4Q515dvsdyklYm08Opukyz4T3qwCoKXb/Do7 mC/U9W6Ddq5KUSJXbWf9hU6cW6HovWQvFm1JA7kEFxhaickFI1z7ZvPj2eG9tzG++Xoz IUHSipLRcqsvGqwXRErTq7icYqR2FHDJRZoUTMjPAYd43nKKmkpbRpd5vTPAHr3WPLtj D1Dg== X-Gm-Message-State: AKS2vOxLqu9HNx8GtNUOS0STrNQG3apgV3q+uoSA6Fpu1b2VKhP1Emkm jbbS0K2OaMdFhSIxtu5s5SFJ/RRthCQNN1rtww== X-Received: by 10.223.173.143 with SMTP id w15mr30116812wrc.113.1499073536839; Mon, 03 Jul 2017 02:18:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.30.71 with HTTP; Mon, 3 Jul 2017 02:18:35 -0700 (PDT) From: William Whyte Date: Mon, 3 Jul 2017 05:18:35 -0400 Message-ID: To: CFRG Content-Type: multipart/alternative; boundary="f403045cf65aa7eb2005536641db" Archived-At: Subject: [Cfrg] Call for papers: Security Standardization Research 2017 X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jul 2017 09:19:02 -0000 --f403045cf65aa7eb2005536641db Content-Type: text/plain; charset="UTF-8" Hi list, Please see below the call for papers for Security Standardization Research 2017, which I'm posting with the chairs' encouragement. This conference has proved to be a great venue for practitioners working on security for different standards to come together and exchange knowledge, and we'd love to get submissions from CFRG participants. Thanks! Best, William Call for Papers SSR 2017: 4th International conference on Security Standardisation Research 18th-19th December 2017, Royal Holloway, Egham, Surrey, UK http://www.ssresearch.eu/2017 SSR covers the full spectrum of research on security standardisation, including, but not restricted to, work on cryptographic techniques (including ANSI, IEEE, IETF, ISO/IEC JTC 1/SC 27, ITU-T and NIST), security management, security evaluation criteria, network security, privacy and identity management, smart cards and RFID tags, biometrics, security modules, and industry-specific security standards (e.g. those produced by the payments, telecommunications and computing industries for such things as payment protocols, mobile telephony and trusted computing). SSR will also accept Systematization of Knowledge (SoK) papers relating to security standardisation, which integrate experience and previous research, drawing new comprehensive conclusions. SoK papers should evaluate, systematize, and contextualize existing knowledge. They should provide a new viewpoint, offer a comprehensive taxonomy, or cast doubt on long-held beliefs, based on compelling evidence. A wide range of standards now cover many of aspects of cyber security. These documents have been published by national and international formal standardisation bodies, as well as by industry consortia. Many of these standards have become very widely used - to take just one example, the ISO/IEC 27000 series has become the internationally adopted basis for managing corporate information security. Still, new security standards are proposed very frequently, and existing security standards need revision often. Security standards are one of the most active areas for many standards bodies. There is currently intense attention on the methods for ensuring security within standardisation. SSR is a forum for identifying the conclusions from this process, and proposing improvements to achieve transparency, more unbiased results, and higher scientific quality. Papers offering research contributions to all aspects of security standardisation are solicited for submission to the SSR 2017 conference. Papers may present theory, applications or practical experience in the field of security standardisation, including, but not necessarily limited to: * access control * biometrics * cloud computing * critical national infrastructure (CNI) protection * critiques of standards * cryptanalysis * cryptographic protocols * cryptographic techniques * evaluation criteria * formal analysis of standards * identity management * industrial control systems security * internet security * intrusion detection * key management and PKIs * mobile security * network security * payment system security * privacy * RFID tag security * risk analysis * security controls * security management * security protocols * security services * security tokens * smart cards * telecommunications security * trusted computing * web security Submissions must be original, unpublished, and not submitted to another conference or journal for consideration for publication. Papers must be written in English. Each submitted paper should begin with a title, a short abstract, and a list of keywords. Papers should be at most 16 pages (excluding bibliography and appendices) in the standard LNCS format (see http://www.springer.com/computer/lncs?SGWID=0-164-0-0-0 for details). Reviewers are not obliged to read appendices, so the paper must be self-contained without them. Papers that do not adhere to these requirements will be rejected without consideration of their merits. Papers must be submitted using the EasyChair conference management system at: https://easychair.org/conferences/?conf=ssr2017 Accepted papers will be presented at the conference and published in the Springer-Verlag Lecture Notes in Computer Science (LNCS) series (www.springer.com/lncs). At least one author of each accepted paper must register for the conference. Instructions for the preparation of a final proceedings version will be sent to the authors of accepted papers. Papers must be submitted using the EasyChair conference management system at: https://easychair.org/conferences/?conf=ssr2017 Please send any enquiries to: webmaster@ssresearch.eu or: ssr2017@easychair.org Important dates Deadline for submissions: Monday, 17 July 2017 (anywhere on earth) Notifications to authors: Wednesday, 20 September 2017 Camera ready due: Monday, 9 October 2017 Conference: Monday/Tuesday, 18/19 December 2017 Conference organisation General Chair Chris Mitchell, RHUL, UK Programme Committee Chair Joshua Guttman, MITRE and WPI, USA William Whyte, USA Programme Committee: Steve Babbage, Vodafone Colin Boyd, NTNU Dan Brown, Certicom and BlackBerry Scott Cadzow, OnBoard Security Liqun Chen, University of Surrey Cas Cremers, University of Oxford Stephen Farrell, Trinity College Dublin Russ Housley, Vigil Security, LLC Catherine Meadows, NRL Karen Randall, Randall Consulting Ben Smyth, Huawei Douglas Stebila, McMaster University -- PLEASE UPDATE YOUR ADDRESS BOOKS WITH MY NEW ADDRESS: wwhyte@onboardsecurity.com --f403045cf65aa7eb2005536641db Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi list,

Please see below th= e call for papers for Security Standardization Research 2017, which I'm= posting with the chairs' encouragement. This conference has proved to = be a great venue for practitioners working on security for different standa= rds to come together and exchange knowledge, and we'd love to get submi= ssions from CFRG participants. Thanks!

Best,
=

William



=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 Call for= Papers

=C2=A0 SSR 2017: 4th International confer= ence on Security Standardisation Research
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 18t= h-1= 9th December 2017, Royal Hol= loway, Egham, Surrey, UK
=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=A0http://www.ssresearch.eu/2017

SSR covers the full = spectrum of research on security standardisation,
including, but not restricted = to, work on cryptographic techniques (including
ANSI, IEEE, IETF, ISO/IEC JTC 1/= SC 27, ITU-T and NIST), security management,
security evaluation criteria, netwo= rk security, privacy and identity
management, smart cards and RFID tags, biometr= ics, security modules, and
industry-specific security standards (e.g. those prod= uced by the payments,
telecommunications and computing industries for such thing= s as payment
protocols, mobile telephony and trusted computing).

SSR will also accept Systematization of Knowledge (SoK) papers r= elating to
security standardisation, which integrate experience and previous res= earch,
drawing new comprehensive conclusions. SoK papers should evaluate, system= atize,
and contextualize existing knowledge. They should provide a new viewpoint= ,
off= er a comprehensive taxonomy, or cast doubt on long-held beliefs, based on
compel= ling evidence.

A wide range of standards now cove= r many of aspects of cyber security. These
documents have been published by nati= onal and international formal
standardisation bodies, as well as by industry con= sortia. Many of these
standards have become very widely used - to take just one = example, the ISO/IEC
27000 series has become the internationally adopted basis f= or managing
corporate information security.

Still, new= security standards are proposed very frequently, and existing
security standard= s need revision often. Security standards are one of the most
active areas for m= any standards bodies. There is currently intense attention on
the methods for en= suring security within standardisation.

SSR is a = forum for identifying the conclusions from this process, and proposing
improveme= nts to achieve transparency, more unbiased results, and higher
scientific qualit= y.

Papers offering research contributions to all = aspects of security
standardisation are solicited for submission to the SSR 2017= conference. Papers
may present theory, applications or practical experience in = the field of
security standardisation, including, but not necessarily limited to= :
* a= ccess control
* biometrics
* cloud computing
* critical national infrastructure (CNI) prot= ection
* critiques of standards
* cryptanalysis
= * cryptographic protocols
* cryptographic tech= niques
* evaluation criteria
* formal analysis of standards
* identity management* industrial = control systems security
* internet security
* intrusion detection
* key management and= PKIs
* mobile security
* network security
* payment system security
* privacy
* RFID tag security<= /span>
* ris= k analysis
* security controls
* security management
* security protocols
* security services<= /span>
* sec= urity tokens
* smart cards
* telecommunications security
* trusted computing
* web security

Submissions must be original, unpublished, and not s= ubmitted to another
conference or journal for consideration for publication. Pap= ers must be written
in English. Each submitted paper should begin with a title, = a short abstract,
and a list of keywords. Papers should be at most 16 pages (exc= luding
bibliography and appendices) in the standard LNCS format (see
http://www.springer.com/computer/lncs?SGWID=3D0-164-0-0-0=C2=A0for details). Reviewers=
are not obl= iged to read appendices, so the paper must be self-contained without=
them.

Papers that do not adhere to these requirements will = be rejected without
consideration of their merits.

Pap= ers must be submitted using the EasyChair conference management system at:<= /span>
=C2= =A0=C2=A0https://= easychair.org/conferences/?conf=3Dssr2017

Accep= ted papers will be presented at the conference and published in the<= br style=3D"font-size:12.8px">Springer-Ver= lag Lecture Notes in Computer Science (LNCS) series
(www.springer.com/lncs). At l= east one author of each accepted paper must
register for the conference.<= br style=3D"font-size:12.8px">
Instructions for the preparation of a final proceedings = version will be sent to
the authors of accepted papers.

Papers must be submitted using the EasyChair conference management system= at:
= =C2=A0=C2=A0https= ://easychair.org/conferences/?conf=3Dssr2017
Please send any enquiries to:
=C2=A0= =C2=A0webmaster@ssresearch.eu
or:
=C2=A0=C2=A0ssr2017@easychair.org

Important dates

=C2=A0Deadline for submissio= ns: Monday, 17 July 2017 (anywhere on earth)
=C2=A0Notifications to authors: Wed= nesday, 20 September 2017
=C2=A0Camera ready due:=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0Monday, 9 October 2017
=C2=A0Conference:=C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Monday/Tuesday, 18/19 December 2017


Conference organisat= ion

General Chair

=C2= =A0Chris Mitchell, RHUL, UK

Programme Committee = Chair

<= span style=3D"font-size:12.8px">=C2=A0Joshua Guttman, MITRE and WPI, USA
=C2=A0W= illiam Whyte, USA


= Programme Committee:

=C2=A0Steve Babbage, Vodafon= e
=C2= =A0Colin Boyd, NTNU
=C2=A0Dan Brown, Certicom and BlackBerry
=C2=A0Scott Cadzow, OnBo= ard Security
=C2=A0Liqun Chen, University of Surrey
=C2=A0Cas Cremers, University of = Oxford
=C2=A0Stephen Farrell, Trinity College Dublin
=C2=A0Russ Housley, Vigil Securi= ty, LLC
=C2=A0Catherine Meadows, NRL
=C2=A0Karen Randall, Randall Consulting=C2=A0Ben Smy= th, Huawei
=C2=A0Douglas Stebila, McMaster University

--

PLEASE UPDATE YOUR ADDRESS BOOKS WITH MY NEW ADDRESS= : wwhyte@on= boardsecurity.com
--f403045cf65aa7eb2005536641db-- From nobody Mon Jul 3 10:34:30 2017 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 B1ADA129B77 for ; Mon, 3 Jul 2017 10:34:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 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.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=tugraz.at 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 H50S3-dt8bKd for ; Mon, 3 Jul 2017 10:34:24 -0700 (PDT) Received: from mailrelay.tugraz.at (mailrelay.tugraz.at [129.27.2.202]) (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 982AA131668 for ; Mon, 3 Jul 2017 10:34:22 -0700 (PDT) Received: from [10.27.152.210] (nat-hiding.iaik.tugraz.at [129.27.152.126]) (authenticated bits=0) by mailrelay3.tugraz.at (8.14.9/8.14.9) with ESMTP id v63HYGA9009014 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 3 Jul 2017 19:34:16 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tugraz.at; s=mailrelay; t=1499103260; bh=NiX2sI6wEg5N4l7+0uLeinJcYc/jcKwle1CTrdRvVXw=; h=Subject:To:References:Cc:From:Date:In-Reply-To; b=FjitOLg9m9Dtrx4lbqyRPYFNPbn/WBR5mWNRG7jpv3HMGk9AB3bDHlNSX0yl+aFnn +HEL9WUEdTtp1Ei4q1sQFT7l3L29lgxaoSF4sHiaocnITzEkY6JscqeyunklqLEyq7 TEWfCcsiJ2Ik2kuBqUtoBICPCZqNyNqu03TwuAw8= To: Philipp Jovanovic References: <8AE29DD0-26FE-4AB6-A4A9-2BB9169BAB13@jovanovic.io> Cc: cfrg@irtf.org From: Daniel Slamanig Message-ID: <11cc5d3f-ecf9-2fd0-825c-c8b441bd2813@tugraz.at> Date: Mon, 3 Jul 2017 19:34:15 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <8AE29DD0-26FE-4AB6-A4A9-2BB9169BAB13@jovanovic.io> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-TUG-Backscatter-control: lAa1Aa+Pa1hp/miybLoRww X-Spam-Scanner: SpamAssassin 3.003001 X-Spam-Score-relay: -1.7 X-Scanned-By: MIMEDefang 2.74 Archived-At: Subject: Re: [Cfrg] Internet-Draft: Collective Edwards-Curve Digital Signature Algorithm X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jul 2017 17:34:28 -0000 Hi Philipp, looks interesting! After looking at the protocol I also have some security concerns (related to what has been raised by Oleg in a previous mail). Not committing to Z as well as the actual sum of signers public keys A' in the computation of the hash c for the signature seems to be problematic. It seems to me that committing Z in the signature in plain as well as A' does not work given the later application of the signing procedure (where till the end of the protocol it is not clear who actually participates in the signing but c must be known at the beginning). Committing to neither of both however seems problematic as it does not fix the set of actual signers. This could be circumvented by allowing an honest leader to adapt the commitment to the final Z (and A') after it knows the signers without modifying the initially computed c using a chameleon hash (trapdoor commitment). I use P as a generator below, omit the brackets [a]P notation for scalar multiplication and write it from the perspective of the leader, i.e., the signer that initiates the protocol. The leader could choose chameleon hash parameters sk_ch=y for random y and pk_ch=(P,Y=yP) and add pk_ch and chameleon hash CH(Z'):=h(Z')P+u'Y for randomly chosen u' to the computation of c, i.e., set c=H(R||A||pk_ch||CH(Z')||S), where h() is a collision resistant hash function (this is just the standard way of constructing a chameleon hash from DL for arbitrary message spaces as propsed in [1]). If Z' is not yet known one simply sets Z' to some fixed string at the beginning, e.g., Z':=0. At the end of the protocol, when the leader knows the exact signers, it can update Z' to the final value Z and use sk_ch to compute a collision in the chameleon hash, i.e., such that CH(Z)=CH(Z') by solving h(Z')+u'y = h(Z)+uy for u. He then adds u and Z as well as pk_ch to the signature, i.e., sets it as (R,s,u,Z,pk_ch) and discards sk_ch and u'. If Z is known beforehand, one simply computes the chameleon hash once and does not need to compute a collision. Clearly, the use of a chameleon hash allows to simply adapt to the actual set of signers representing Z without modifying c (with the knowledge of sk_ch - but it does not work without the knowledge of sk_ch). This would resolve the issue with the unknown Z at the time of signing. Also, A is committed in the signature, but not the concrete A'=\sum A_i of keys used for computing the signature (I guess also due to the reason that one does not know the correct set of signers when computing the hash c). That can be problematic in a rogue key scenario in the current protocol, i.e., when not all signers need to prove knowledge of the secret key when they register their public keys but their public keys could be functions of other public keys (guess this could be a problem here). For instance, a malicious A^* could just take some key from A, say A_j, and compute and publish A^*=a^*A_j. And then given a collective signature (R,s,Z) where A_j participated, the signer can update s to s^* = s+a^*c as well as Z^* to exclude A_j and include A^* (as Z is not committed in the signature generation) and the signature (R,s^*,Z^*) will be a valid signature that certifies that A^* participated in signing - although he didn't. If Z is committed as proposed above and it is checked during the verification, then this should no longer work. One could also adapt the hash c=H(R||pk_ch||CH(Z'||A)||S) to include a chameleon hash to CH(Z||A'), where A' is the real set of signers that participated in the signature generation and is adapted before finalizing the signature when known as above. I hope that what I proposed is not just complete nonsense :) Also it produces quite a bit of an overhead. There may also be easier ways to avoid the issues. Some editorial issues: the message to be signed is sometimes called a satement S and later then message msg. S could be confusing as part of the signature is s and your semantic is that scalars are lowercase and points are uppercase. Also in 4.2 "Signature Generation" steps 2 and 3 are confusing as I guess that in the protocol all the signer compute their own [r_i]B values and R=\sum R_i instead of R=[r]B which would mean that they would send their r_i's (hope they will not do so). Also I find it somewhat confusing that the bitmask Z identifies the non-signers with a bit set to 1. Why not identifying the signers with a bit set to 1? Cheers, Daniel [1] Hugo Krawczyk, Tal Rabin: Chameleon Signatures. NDSS 2000 On 01.07.2017 23:58, Philipp Jovanovic wrote: > Hi CFRG, > > Here’s a first version of an Internet-Draft on “Collective Edwards-Curve Digital Signature Algorithms” based on Ed25519 and Ed448: https://datatracker.ietf.org/doc/draft-ford-cfrg-cosi/ > > We plan to give a short presentation on that topic at the next CFRG meeting in Prague. > > Any feedback is more than welcome. Thanks! > > All the best, > Philipp > > > > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > https://www.irtf.org/mailman/listinfo/cfrg > -- Dr. Daniel Slamanig Institute for Applied Information Processing and Communications Graz University of Technology Inffeldgasse 16a, 8010 Graz, Austria. Phone: +43 316 873 5509 http://www.iaik.tugraz.at From nobody Mon Jul 3 11:02:28 2017 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 38564129503; Mon, 3 Jul 2017 11:02:27 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: cfrg@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.55.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149910494717.22786.15402730565912249191@ietfa.amsl.com> Date: Mon, 03 Jul 2017 11:02:27 -0700 Archived-At: Subject: [Cfrg] I-D Action: draft-irtf-cfrg-re-keying-05.txt X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.22 List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jul 2017 18:02:27 -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 : Re-keying Mechanisms for Symmetric Keys Author : Stanislav Smyshlyaev Filename : draft-irtf-cfrg-re-keying-05.txt Pages : 47 Date : 2017-07-03 Abstract: A certain maximum amount of data can be safely encrypted when encryption is performed under a single key. This amount is called "key lifetime". This specification describes a variety of methods to increase the lifetime of symmetric keys. It provides external and internal re-keying mechanisms based on hash functions and on block ciphers, that can be used with modes of operations such as CTR, GCM, CCM, CBC, CFB, OFB and OMAC. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-irtf-cfrg-re-keying/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-irtf-cfrg-re-keying-05 https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-re-keying-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-irtf-cfrg-re-keying-05 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 Mon Jul 3 15:39:29 2017 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 03519131696 for ; Mon, 3 Jul 2017 15:39:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 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_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=tugraz.at 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 c4b5XiuPl-4C for ; Mon, 3 Jul 2017 15:39:18 -0700 (PDT) Received: from mailrelay.tugraz.at (mailrelay.tugraz.at [129.27.2.202]) (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 7918D131638 for ; Mon, 3 Jul 2017 15:39:18 -0700 (PDT) Received: from exchange.tugraz.at (exchange.tugraz.at [129.27.2.220]) by mailrelay3.tugraz.at (8.14.9/8.14.9) with ESMTP id v63MdEUY008925 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Tue, 4 Jul 2017 00:39:14 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tugraz.at; s=mailrelay; t=1499121556; bh=Q9ynHFeo9QLGUJMVTHoR2m0r7QXJPTYwdzsN1OCfQl4=; h=From:To:CC:Subject:Date; b=LZctkRqiK4AjgkgEv6eXj+Q2lmdHingvt+huyZh4FUs8vceLAWRqNCqDUEmPu7Sk4 ish0tN/NTgxZUqB3Ug2rE/1w753WjlNx9aQ1nIsvSMNJQCzOdeGgUHps2C4JUh1xXW iCTbHVnjqQbQBi2nN6ay39MowPJcZrx+nrn0wuP4= Received: from MBX0002.tugraz.local (2002:811b:3045::811b:3045) by MBX0002.tugraz.local (2002:811b:3045::811b:3045) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Tue, 4 Jul 2017 00:39:12 +0200 Received: from MBX0002.tugraz.local ([fe80::5556:4aaf:d0f8:46ec]) by MBX0002.tugraz.local ([fe80::5556:4aaf:d0f8:46ec%12]) with mapi id 15.00.1263.000; Tue, 4 Jul 2017 00:39:12 +0200 From: "Slamanig, Daniel" To: Philipp Jovanovic CC: "cfrg@irtf.org" Thread-Topic: [Cfrg] Internet-Draft: Collective Edwards-Curve Digital Signature Algorithm Thread-Index: AQHS9E0xFuwNyQq3DkK9EtFcxMSBZg== Date: Mon, 3 Jul 2017 22:39:12 +0000 Message-ID: <8a0d8aec-8640-4fad-a692-c405cd05973e@email.android.com> Accept-Language: de-AT, en-US Content-Language: de-AT X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted Content-Type: multipart/alternative; boundary="_000_8a0d8aec86404fada692c405cd05973eemailandroidcom_" MIME-Version: 1.0 X-TUG-Backscatter-control: lAa1Aa+Pa1hp/miybLoRww X-Spam-Scanner: SpamAssassin 3.003001 X-Spam-Score-relay: -1.9 X-Scanned-By: MIMEDefang 2.74 Archived-At: Subject: Re: [Cfrg] Internet-Draft: Collective Edwards-Curve Digital Signature Algorithm X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jul 2017 22:39:22 -0000 --_000_8a0d8aec86404fada692c405cd05973eemailandroidcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgYWdhaW4sDQoNCg0KRm9yIGluc3RhbmNlLCBhIG1hbGljaW91cyBBXiogY291bGQganVzdCB0 YWtlIHNvbWUga2V5IGZyb20gQSwNCnNheSBBX2osIGFuZCBjb21wdXRlIGFuZCBwdWJsaXNoIEFe Kj1hXipBX2ouDQoNCnNyeSwgdGhlcmUgaXMgYSB0eXBvLiBTaG91bGQgYmUgQV4qPWFeKlArQV9q IGFzc3VtaW5nIEFfaj1hX2pQLg0KDQpDaGVlcnMsDQpEYW5pZWwNCg0KIHRoZW4gZ2l2ZW4gYSBj b2xsZWN0aXZlDQpzaWduYXR1cmUgKFIscyxaKSB3aGVyZSBBX2ogcGFydGljaXBhdGVkLCB0aGUg c2lnbmVyIGNhbiB1cGRhdGUgcyB0byBzXioNCj0gcythXipjIGFzIHdlbGwgYXMgWl4qIHRvIGV4 Y2x1ZGUgQV9qIGFuZCBpbmNsdWRlIEFeKiAoYXMgWiBpcyBub3QNCmNvbW1pdHRlZCBpbiB0aGUg c2lnbmF0dXJlIGdlbmVyYXRpb24pIGFuZCB0aGUgc2lnbmF0dXJlIChSLHNeKixaXiopDQp3aWxs IGJlIGEgdmFsaWQgc2lnbmF0dXJlIHRoYXQgY2VydGlmaWVzIHRoYXQgQV4qIHBhcnRpY2lwYXRl ZCBpbg0Kc2lnbmluZyAtIGFsdGhvdWdoIGhlIGRpZG4ndC4NCg0KSWYgWiBpcyBjb21taXR0ZWQg YXMgcHJvcG9zZWQgYWJvdmUgYW5kIGl0IGlzIGNoZWNrZWQgZHVyaW5nIHRoZQ0KdmVyaWZpY2F0 aW9uLCB0aGVuIHRoaXMgc2hvdWxkIG5vIGxvbmdlciB3b3JrLiBPbmUgY291bGQgYWxzbyBhZGFw dCB0aGUNCmhhc2ggYz1IKFJ8fHBrX2NofHxDSChaJ3x8QSl8fFMpIHRvIGluY2x1ZGUgYSBjaGFt ZWxlb24gaGFzaCB0bw0KQ0goWnx8QScpLCB3aGVyZSBBJyBpcyB0aGUgcmVhbCBzZXQgb2Ygc2ln bmVycyB0aGF0IHBhcnRpY2lwYXRlZCBpbiB0aGUNCnNpZ25hdHVyZSBnZW5lcmF0aW9uIGFuZCBp cyBhZGFwdGVkIGJlZm9yZSBmaW5hbGl6aW5nIHRoZSBzaWduYXR1cmUgd2hlbg0Ka25vd24gYXMg YWJvdmUuDQoNCkkgaG9wZSB0aGF0IHdoYXQgSSBwcm9wb3NlZCBpcyBub3QganVzdCBjb21wbGV0 ZSBub25zZW5zZSA6KSBBbHNvIGl0DQpwcm9kdWNlcyBxdWl0ZSBhIGJpdCBvZiBhbiBvdmVyaGVh ZC4gVGhlcmUgbWF5IGFsc28gYmUgZWFzaWVyIHdheXMgdG8NCmF2b2lkIHRoZSBpc3N1ZXMuDQoN ClNvbWUgZWRpdG9yaWFsIGlzc3VlczogdGhlIG1lc3NhZ2UgdG8gYmUgc2lnbmVkIGlzIHNvbWV0 aW1lcyBjYWxsZWQgYQ0Kc2F0ZW1lbnQgUyBhbmQgbGF0ZXIgdGhlbiBtZXNzYWdlIG1zZy4gUyBj b3VsZCBiZSBjb25mdXNpbmcgYXMgcGFydCBvZg0KdGhlIHNpZ25hdHVyZSBpcyBzIGFuZCB5b3Vy IHNlbWFudGljIGlzIHRoYXQgc2NhbGFycyBhcmUgbG93ZXJjYXNlIGFuZA0KcG9pbnRzIGFyZSB1 cHBlcmNhc2UuIEFsc28gaW4gNC4yICJTaWduYXR1cmUgR2VuZXJhdGlvbiIgc3RlcHMgMiBhbmQg Mw0KYXJlIGNvbmZ1c2luZyBhcyBJIGd1ZXNzIHRoYXQgaW4gdGhlIHByb3RvY29sIGFsbCB0aGUg c2lnbmVyIGNvbXB1dGUNCnRoZWlyIG93biBbcl9pXUIgdmFsdWVzIGFuZCBSPVxzdW0gUl9pIGlu c3RlYWQgb2YgUj1bcl1CIHdoaWNoIHdvdWxkDQptZWFuIHRoYXQgdGhleSB3b3VsZCBzZW5kIHRo ZWlyIHJfaSdzIChob3BlIHRoZXkgd2lsbCBub3QgZG8gc28pLg0KDQpBbHNvIEkgZmluZCBpdCBz b21ld2hhdCBjb25mdXNpbmcgdGhhdCB0aGUgYml0bWFzayBaIGlkZW50aWZpZXMgdGhlDQpub24t c2lnbmVycyB3aXRoIGEgYml0IHNldCB0byAxLiBXaHkgbm90IGlkZW50aWZ5aW5nIHRoZSBzaWdu ZXJzIHdpdGggYQ0KYml0IHNldCB0byAxPw0KDQpDaGVlcnMsDQpEYW5pZWwNCg0KDQpbMV0gSHVn byBLcmF3Y3p5aywgVGFsIFJhYmluOiBDaGFtZWxlb24gU2lnbmF0dXJlcy4gTkRTUyAyMDAwDQoN Ck9uIDAxLjA3LjIwMTcgMjM6NTgsIFBoaWxpcHAgSm92YW5vdmljIHdyb3RlOg0KPiBIaSBDRlJH LA0KPg0KPiBIZXJl4oCZcyBhIGZpcnN0IHZlcnNpb24gb2YgYW4gSW50ZXJuZXQtRHJhZnQgb24g 4oCcQ29sbGVjdGl2ZSBFZHdhcmRzLUN1cnZlIERpZ2l0YWwgU2lnbmF0dXJlIEFsZ29yaXRobXPi gJ0gYmFzZWQgb24gRWQyNTUxOSBhbmQgRWQ0NDg6IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5v cmcvZG9jL2RyYWZ0LWZvcmQtY2ZyZy1jb3NpLw0KPg0KPiBXZSBwbGFuIHRvIGdpdmUgYSBzaG9y dCBwcmVzZW50YXRpb24gb24gdGhhdCB0b3BpYyBhdCB0aGUgbmV4dCBDRlJHIG1lZXRpbmcgaW4g UHJhZ3VlLg0KPg0KPiBBbnkgZmVlZGJhY2sgaXMgbW9yZSB0aGFuIHdlbGNvbWUuIFRoYW5rcyEN Cj4NCj4gQWxsIHRoZSBiZXN0LA0KPiBQaGlsaXBwDQo+DQo+DQo+DQo+IF9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IENmcmcgbWFpbGluZyBsaXN0DQo+ IENmcmdAaXJ0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaXJ0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9j ZnJnDQo+DQoNCg0KLS0NCkRyLiBEYW5pZWwgU2xhbWFuaWcNCkluc3RpdHV0ZSBmb3IgQXBwbGll ZCBJbmZvcm1hdGlvbiBQcm9jZXNzaW5nIGFuZCBDb21tdW5pY2F0aW9ucw0KR3JheiBVbml2ZXJz aXR5IG9mIFRlY2hub2xvZ3kNCkluZmZlbGRnYXNzZSAxNmEsIDgwMTAgR3JheiwgQXVzdHJpYS4N ClBob25lOiArNDMgMzE2IDg3MyA1NTA5DQpodHRwOi8vd3d3LmlhaWsudHVncmF6LmF0DQoNCl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpDZnJnIG1haWxp bmcgbGlzdA0KQ2ZyZ0BpcnRmLm9yZw0KaHR0cHM6Ly93d3cuaXJ0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9jZnJnDQoNCg== --_000_8a0d8aec86404fada692c405cd05973eemailandroidcom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5Pg0KPGRpdiBkaXI9ImF1 dG8iPg0KPGRpdj5IaSBhZ2Fpbiw8YnI+DQo8ZGl2IGNsYXNzPSJnbWFpbF9leHRyYSI+PGJyPg0K PC9kaXY+DQo8L2Rpdj4NCjxkaXYgZGlyPSJhdXRvIj4NCjxkaXYgY2xhc3M9ImdtYWlsX2V4dHJh Ij4NCjxkaXYgY2xhc3M9ImdtYWlsX3F1b3RlIj4NCjxibG9ja3F1b3RlIGNsYXNzPSJxdW90ZSIg c3R5bGU9Im1hcmdpbjowIDAgMCAuOGV4O2JvcmRlci1sZWZ0OjFweCAjY2NjIHNvbGlkO3BhZGRp bmctbGVmdDoxZXgiPg0KPGRpdj48Zm9udCBzaXplPSIyIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwcHQiPg0KPGRpdj48YnI+DQpGb3IgaW5zdGFuY2UsIGEgbWFsaWNpb3VzIEFeKiBjb3VsZCBq dXN0IHRha2Ugc29tZSBrZXkgZnJvbSBBLCA8YnI+DQpzYXkgQV9qLCBhbmQgY29tcHV0ZSBhbmQg cHVibGlzaCBBXio9YV4qQV9qLjwvZGl2Pg0KPC9zcGFuPjwvZm9udD48L2Rpdj4NCjwvYmxvY2tx dW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXYgZGlyPSJhdXRvIj48YnI+DQo8L2Rp dj4NCjxkaXYgZGlyPSJhdXRvIj5zcnksIHRoZXJlIGlzIGEgdHlwby4gU2hvdWxkIGJlIEFeKj1h XipQJiM0MztBX2ogYXNzdW1pbmcgQV9qPWFfalAuPC9kaXY+DQo8ZGl2IGRpcj0iYXV0byI+PGJy Pg0KPC9kaXY+DQo8ZGl2IGRpcj0iYXV0byI+Q2hlZXJzLDwvZGl2Pg0KPGRpdiBkaXI9ImF1dG8i PkRhbmllbDwvZGl2Pg0KPGRpdiBkaXI9ImF1dG8iPjxicj4NCjwvZGl2Pg0KPGRpdiBkaXI9ImF1 dG8iPjwvZGl2Pg0KPGRpdiBkaXI9ImF1dG8iPg0KPGRpdiBjbGFzcz0iZ21haWxfZXh0cmEiPg0K PGRpdiBjbGFzcz0iZ21haWxfcXVvdGUiPg0KPGJsb2NrcXVvdGUgY2xhc3M9InF1b3RlIiBzdHls ZT0ibWFyZ2luOjAgMCAwIC44ZXg7Ym9yZGVyLWxlZnQ6MXB4ICNjY2Mgc29saWQ7cGFkZGluZy1s ZWZ0OjFleCI+DQo8ZGl2Pjxmb250IHNpemU9IjIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTBw dCI+DQo8ZGl2PiZuYnNwO3RoZW4gZ2l2ZW4gYSBjb2xsZWN0aXZlIDxicj4NCnNpZ25hdHVyZSAo UixzLFopIHdoZXJlIEFfaiBwYXJ0aWNpcGF0ZWQsIHRoZSBzaWduZXIgY2FuIHVwZGF0ZSBzIHRv IHNeKiA8YnI+DQo9IHMmIzQzO2FeKmMgYXMgd2VsbCBhcyBaXiogdG8gZXhjbHVkZSBBX2ogYW5k IGluY2x1ZGUgQV4qIChhcyBaIGlzIG5vdCA8YnI+DQpjb21taXR0ZWQgaW4gdGhlIHNpZ25hdHVy ZSBnZW5lcmF0aW9uKSBhbmQgdGhlIHNpZ25hdHVyZSAoUixzXiosWl4qKSA8YnI+DQp3aWxsIGJl IGEgdmFsaWQgc2lnbmF0dXJlIHRoYXQgY2VydGlmaWVzIHRoYXQgQV4qIHBhcnRpY2lwYXRlZCBp biA8YnI+DQpzaWduaW5nIC0gYWx0aG91Z2ggaGUgZGlkbid0Ljxicj4NCjxicj4NCklmIFogaXMg Y29tbWl0dGVkIGFzIHByb3Bvc2VkIGFib3ZlIGFuZCBpdCBpcyBjaGVja2VkIGR1cmluZyB0aGUg PGJyPg0KdmVyaWZpY2F0aW9uLCB0aGVuIHRoaXMgc2hvdWxkIG5vIGxvbmdlciB3b3JrLiBPbmUg Y291bGQgYWxzbyBhZGFwdCB0aGUgPGJyPg0KaGFzaCBjPUgoUnx8cGtfY2h8fENIKFonfHxBKXx8 UykgdG8gaW5jbHVkZSBhIGNoYW1lbGVvbiBoYXNoIHRvIDxicj4NCkNIKFp8fEEnKSwgd2hlcmUg QScgaXMgdGhlIHJlYWwgc2V0IG9mIHNpZ25lcnMgdGhhdCBwYXJ0aWNpcGF0ZWQgaW4gdGhlIDxi cj4NCnNpZ25hdHVyZSBnZW5lcmF0aW9uIGFuZCBpcyBhZGFwdGVkIGJlZm9yZSBmaW5hbGl6aW5n IHRoZSBzaWduYXR1cmUgd2hlbiA8YnI+DQprbm93biBhcyBhYm92ZS48YnI+DQo8YnI+DQpJIGhv cGUgdGhhdCB3aGF0IEkgcHJvcG9zZWQgaXMgbm90IGp1c3QgY29tcGxldGUgbm9uc2Vuc2UgOikg QWxzbyBpdCA8YnI+DQpwcm9kdWNlcyBxdWl0ZSBhIGJpdCBvZiBhbiBvdmVyaGVhZC4gVGhlcmUg bWF5IGFsc28gYmUgZWFzaWVyIHdheXMgdG8gPGJyPg0KYXZvaWQgdGhlIGlzc3Vlcy48YnI+DQo8 YnI+DQpTb21lIGVkaXRvcmlhbCBpc3N1ZXM6IHRoZSBtZXNzYWdlIHRvIGJlIHNpZ25lZCBpcyBz b21ldGltZXMgY2FsbGVkIGEgPGJyPg0Kc2F0ZW1lbnQgUyBhbmQgbGF0ZXIgdGhlbiBtZXNzYWdl IG1zZy4gUyBjb3VsZCBiZSBjb25mdXNpbmcgYXMgcGFydCBvZiA8YnI+DQp0aGUgc2lnbmF0dXJl IGlzIHMgYW5kIHlvdXIgc2VtYW50aWMgaXMgdGhhdCBzY2FsYXJzIGFyZSBsb3dlcmNhc2UgYW5k IDxicj4NCnBvaW50cyBhcmUgdXBwZXJjYXNlLiBBbHNvIGluIDQuMiAmcXVvdDtTaWduYXR1cmUg R2VuZXJhdGlvbiZxdW90OyBzdGVwcyAyIGFuZCAzIDxicj4NCmFyZSBjb25mdXNpbmcgYXMgSSBn dWVzcyB0aGF0IGluIHRoZSBwcm90b2NvbCBhbGwgdGhlIHNpZ25lciBjb21wdXRlIDxicj4NCnRo ZWlyIG93biBbcl9pXUIgdmFsdWVzIGFuZCBSPVxzdW0gUl9pIGluc3RlYWQgb2YgUj1bcl1CIHdo aWNoIHdvdWxkIDxicj4NCm1lYW4gdGhhdCB0aGV5IHdvdWxkIHNlbmQgdGhlaXIgcl9pJ3MgKGhv cGUgdGhleSB3aWxsIG5vdCBkbyBzbykuPGJyPg0KPGJyPg0KQWxzbyBJIGZpbmQgaXQgc29tZXdo YXQgY29uZnVzaW5nIHRoYXQgdGhlIGJpdG1hc2sgWiBpZGVudGlmaWVzIHRoZSA8YnI+DQpub24t c2lnbmVycyB3aXRoIGEgYml0IHNldCB0byAxLiBXaHkgbm90IGlkZW50aWZ5aW5nIHRoZSBzaWdu ZXJzIHdpdGggYSA8YnI+DQpiaXQgc2V0IHRvIDE/PGJyPg0KPGJyPg0KQ2hlZXJzLDxicj4NCkRh bmllbDxicj4NCjxicj4NCjxicj4NClsxXSBIdWdvIEtyYXdjenlrLCBUYWwgUmFiaW46IENoYW1l bGVvbiBTaWduYXR1cmVzLiBORFNTIDIwMDA8YnI+DQo8YnI+DQpPbiAwMS4wNy4yMDE3IDIzOjU4 LCBQaGlsaXBwIEpvdmFub3ZpYyB3cm90ZTo8YnI+DQomZ3Q7IEhpIENGUkcsPGJyPg0KJmd0OyA8 YnI+DQomZ3Q7IEhlcmXigJlzIGEgZmlyc3QgdmVyc2lvbiBvZiBhbiBJbnRlcm5ldC1EcmFmdCBv biDigJxDb2xsZWN0aXZlIEVkd2FyZHMtQ3VydmUgRGlnaXRhbCBTaWduYXR1cmUgQWxnb3JpdGht c+KAnSBiYXNlZCBvbiBFZDI1NTE5IGFuZCBFZDQ0ODoNCjxhIGhyZWY9Imh0dHBzOi8vZGF0YXRy YWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWZvcmQtY2ZyZy1jb3NpLyI+aHR0cHM6Ly9kYXRhdHJh Y2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtZm9yZC1jZnJnLWNvc2kvPC9hPjxicj4NCiZndDsgPGJy Pg0KJmd0OyBXZSBwbGFuIHRvIGdpdmUgYSBzaG9ydCBwcmVzZW50YXRpb24gb24gdGhhdCB0b3Bp YyBhdCB0aGUgbmV4dCBDRlJHIG1lZXRpbmcgaW4gUHJhZ3VlLjxicj4NCiZndDsgPGJyPg0KJmd0 OyBBbnkgZmVlZGJhY2sgaXMgbW9yZSB0aGFuIHdlbGNvbWUuIFRoYW5rcyE8YnI+DQomZ3Q7IDxi cj4NCiZndDsgQWxsIHRoZSBiZXN0LDxicj4NCiZndDsgUGhpbGlwcDxicj4NCiZndDsgPGJyPg0K Jmd0OyA8YnI+DQomZ3Q7IDxicj4NCiZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX188YnI+DQomZ3Q7IENmcmcgbWFpbGluZyBsaXN0PGJyPg0KJmd0OyBD ZnJnQGlydGYub3JnPGJyPg0KJmd0OyA8YSBocmVmPSJodHRwczovL3d3dy5pcnRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL2NmcmciPmh0dHBzOi8vd3d3LmlydGYub3JnL21haWxtYW4vbGlzdGluZm8v Y2ZyZzwvYT48YnI+DQomZ3Q7IDxicj4NCjxicj4NCjxicj4NCi0tPGJyPg0KRHIuIERhbmllbCBT bGFtYW5pZzxicj4NCkluc3RpdHV0ZSBmb3IgQXBwbGllZCBJbmZvcm1hdGlvbiBQcm9jZXNzaW5n IGFuZCBDb21tdW5pY2F0aW9uczxicj4NCkdyYXogVW5pdmVyc2l0eSBvZiBUZWNobm9sb2d5PGJy Pg0KSW5mZmVsZGdhc3NlIDE2YSwgODAxMCBHcmF6LCBBdXN0cmlhLjxicj4NClBob25lOiAmIzQz OzQzIDMxNiA4NzMgNTUwOTxicj4NCjxhIGhyZWY9Imh0dHA6Ly93d3cuaWFpay50dWdyYXouYXQi Pmh0dHA6Ly93d3cuaWFpay50dWdyYXouYXQ8L2E+PGJyPg0KPGJyPg0KX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpDZnJnIG1haWxpbmcgbGlzdDxi cj4NCkNmcmdAaXJ0Zi5vcmc8YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pcnRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL2NmcmciPmh0dHBzOi8vd3d3LmlydGYub3JnL21haWxtYW4vbGlzdGluZm8v Y2ZyZzwvYT48YnI+DQo8L2Rpdj4NCjwvc3Bhbj48L2ZvbnQ+PC9kaXY+DQo8L2Jsb2NrcXVvdGU+ DQo8L2Rpdj4NCjxicj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4N Cg== --_000_8a0d8aec86404fada692c405cd05973eemailandroidcom_-- From nobody Tue Jul 4 07:06:29 2017 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 965A5129B30; Tue, 4 Jul 2017 07:06:27 -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_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 OT9sknmIc9uC; Tue, 4 Jul 2017 07:06:25 -0700 (PDT) Received: from EUR02-AM5-obe.outbound.protection.outlook.com (mail-eopbgr00061.outbound.protection.outlook.com [40.107.0.61]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 89BCD1320B3; Tue, 4 Jul 2017 07:06:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rhul.onmicrosoft.com; s=selector1-rhul-ac-uk; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=bR+KmH9PF9Y/mKw1doRTrglrsy6S0o2b/XdKye7bfdM=; b=JRbB142rGAbmXyNLeiEmgN7THXfyWbIuwocGeOUEnUStIYAA+HMaKrXCo1oFLz8TAEMeAuXbn2eCuSWOjvQokywLNxruWJ6yGjnDCyw9FcwbeN21qC7Vx6bAVBOcr87O68c31gZf1jW76FDHdPn9boFSfo+JLjvJ3se26JFqeww= Received: from AM4PR0301MB1906.eurprd03.prod.outlook.com (10.168.2.156) by AM4PR0301MB1907.eurprd03.prod.outlook.com (10.168.3.7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1220.11; Tue, 4 Jul 2017 14:06:09 +0000 Received: from AM4PR0301MB1906.eurprd03.prod.outlook.com ([fe80::482:61a:3f1b:be7a]) by AM4PR0301MB1906.eurprd03.prod.outlook.com ([fe80::482:61a:3f1b:be7a%14]) with mapi id 15.01.1220.018; Tue, 4 Jul 2017 14:06:08 +0000 From: "Paterson, Kenny" To: "draft-irtf-cfrg-argon2@ietf.org" CC: "cfrg@ietf.org" Thread-Topic: [Cfrg] I-D Action: draft-irtf-cfrg-argon2-02.txt Thread-Index: AQHSpud0G7Nvk2NWAEWKLkFqd0wSnqGoglCAgH4EpoCAHdlfgA== Date: Tue, 4 Jul 2017 14:06:08 +0000 Message-ID: References: <149061159741.30566.11599293166376872082@ietfa.amsl.com> 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.7.1.161129 authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=rhul.ac.uk; x-originating-ip: [134.219.227.30] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM4PR0301MB1907; 7:kt1u8aTkQK0xuzIwxmneyAqDlxgfQJUhqlG3sNtC5QxTMwzhSIYU0kb8Sxr5PjBJhwkjmHaEba4+FkfZ1szFkutm1rwUEqJlOVqhHzkiY6CSQFehrAqm8XFVwWhi3MH9WmQkcGKhQ818x7Sxt2z4tivEOXvMvGtqzRLBiubHdfqhYMyoLh5b9pi8Q1htuz6gt7I/ohIGhPwlcZCHFLmUfyIevpRkuf6Ezz+I+aXzVU4yfTKcDiK2GygxpHRJCo+iW4aluNBO7xyfIa+TwwooPJ6NPfrtnZYp/dmKQs/5rwAZewwyEghIC0uRYySPLs15rGwAkkYmdBW8OyI3Wy6xQ4DfTPaYXx7By3hNvzwsac9uq1zTNseGurybFRGNYpLbD2a/XHRcOuSpaRXXKzPxKnvYePkEfM9bgkPo2g2o8trXjgtbhLHxDWmROgkmIww4dIB00xrJCK/1IomnFJvHI4Ir5ld+JqOQFbJ+P1bv6v7I6TMh9faXUvYoCmUlLqV/ArmJWaZWwt6ox/lvkWfV/grsRlwMG+EBVNHsFNXMEFa6mEUkAnhX36IaxoooRWIbub09gYc3ZZNDA1/h45fK+QO0K2p8PGneFx58MIeOIulWkbezMkrJQ7X/jJwaQ1nXsp1WqiuQYDQE54ZkkyswUgGVi38BLjsrBIbz3ZbZ3F4nRrkXhQPd6x/QmHK38grYi1dco7jMPnhkdrhPMFqMVg/4Y9NMN0TFLaZT/1QrBmtivrI7Qv7nseIxmQSzw/VEExQGynvVfcuHlKHHG7Fqbxnxb5GjhkTyZQN6wLMA7Cs= x-forefront-antispam-report: SFV:SKI; SCL:-1SFV:NSPM; SFS:(10009020)(6009001)(39400400002)(39850400002)(39840400002)(39450400003)(39410400002)(377424004)(24454002)(377454003)(25786009)(53546010)(4326008)(3280700002)(66066001)(86362001)(3660700001)(551544002)(2900100001)(6506006)(6486002)(5660300001)(4001350100001)(76176999)(54356999)(50986999)(413944005)(966005)(72206003)(36756003)(478600001)(2906002)(8676002)(81166006)(8936002)(189998001)(230783001)(2351001)(14454004)(7736002)(74482002)(6512007)(5250100002)(305945005)(2950100002)(42882006)(6306002)(6916009)(99286003)(53936002)(6436002)(3846002)(6116002)(102836003)(5640700003)(450100002)(2501003)(110136004)(6246003)(38730400002)(229853002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM4PR0301MB1907; H:AM4PR0301MB1906.eurprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; x-ms-office365-filtering-correlation-id: e7998bf7-19a9-458a-c5ab-08d4c2e5d1a0 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:AM4PR0301MB1907; x-ms-traffictypediagnostic: AM4PR0301MB1907: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(125551606395959)(278178393323532)(158342451672863)(120809045254105)(236129657087228)(192374486261705)(48057245064654)(100405760836317)(148574349560750)(92977632026198); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(5005006)(8121501046)(3002001)(100000703101)(100105400095)(10201501046)(93006095)(93001095)(6041248)(20161123560025)(20161123555025)(20161123558100)(20161123562025)(201703131423075)(201702281528075)(201702281529075)(201703061421075)(201703061406153)(20161123564025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:AM4PR0301MB1907; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:AM4PR0301MB1907; x-forefront-prvs: 0358535363 spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM 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: 04 Jul 2017 14:06:08.5731 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2efd699a-1922-4e69-b601-108008d28a2e X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR0301MB1907 Archived-At: Subject: Re: [Cfrg] I-D Action: draft-irtf-cfrg-argon2-02.txt X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jul 2017 14:06:28 -0000 RGVhciBBcmdvbjIgYXV0aG9ycywNCg0KDQpZb3Ugd2lsbCBoYXZlIHNlZW4gdGhlIHR3byByZWNl bnQgQ0ZSRyByZXZpZXcgcGFuZWwgcmV2aWV3cyBmb3INCmRyYWZ0LWlydGYtY2ZyZy1hcmdvbjIt MDIudHh0Og0KDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL2NmcmcvY3Vy cmVudC9tc2cwOTE5OS5odG1sDQoNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93 ZWIvY2ZyZy9jdXJyZW50L21zZzA5MTk1Lmh0bWwNCg0KDQotIHRoYW5rcyB0byBSdXNzIEhvdXNs ZXkgYW5kIFN0YW5pc2xhdiBTbXlzaGx5YWV2IGZvciBwcmVwYXJpbmcgdGhlc2UuDQoNClBsZWFz ZSB3b3VsZCB5b3UgdGFrZSB0aGVzZSByZXZpZXdzIGludG8gYWNjb3VudCB3aGVuIHByZXBhcmlu ZyB0aGUgbmV4dA0KdmVyc2lvbiBvZiB5b3VyIGRyYWZ0PyBJdCB3b3VsZCBoZWxwZnVsIGlmIHlv dSB3b3VsZCBwb3N0IGEgcmVzcG9uc2UNCmV4cGxhaW5pbmcgaG93IHlvdSBoYXZlIGFkZHJlc3Nl ZCB0aGUgY29tbWVudHMgd2hlbiB5b3UgYXJlIHJlYWR5Lg0KDQooTm90ZSBhbHNvIHRoYXQgdGhl cmUgd2FzIGEgY3V0b2ZmIGZvciBuZXcgZHJhZnRzIHRoaXMgTW9uZGF5IHBhc3QgYmVjYXVzZQ0K b2YgdGhlIHVwY29taW5nIElFVEYgbWVldGluZy4pDQoNClJlZ2FyZHMNCg0KS2VubnkgKGZvciB0 aGUgY2hhaXJzKQ0KDQoNCk9uIDE1LzA2LzIwMTcgMTU6MTYsICJQYXRlcnNvbiwgS2VubnkiIDxL ZW5ueS5QYXRlcnNvbkByaHVsLmFjLnVrPiB3cm90ZToNCg0KPkRlYXIgQ0ZSRywNCj4NCj5EbWl0 cnkgS2hvdnJhdG92aWNoIGtpbmRseSBwcmVzZW50ZWQgdGhlIGxhdGVzdCBkcmFmdCBmb3IgQXJn b24yIGF0IHRoZQ0KPmludGVyaW0gQ0ZSRyBtZWV0aW5nIGluIFBhcmlzLiBGb3IgdGhvc2Ugb2Yg eW91IHdobyBjb3VsZCBub3QgYXR0ZW5kLCBoaXMNCj5zbGlkZXMgY2FuIGJlIGZvdW5kIGhlcmU6 DQo+DQo+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvcHJvY2VlZGluZ3MvaW50ZXJpbS0yMDE3LWNmcmct MDEvc2xpZGVzL3NsaWRlcy1pbnRlcmkNCj5tDQo+LTIwMTctY2ZyZy0wMS1zZXNzYS1hcmdvbjIt MDAucGRmDQo+DQo+DQo+TXkgc2Vuc2UgZnJvbSB0aGUgY29uc3RydWN0aXZlIGRpc2N1c3Npb24g dGhhdCB0b29rIHBsYWNlIGFmdGVyIERtaXRyeSdzDQo+dGFsayBpbiBQYXJpcyB3YXMgdGhhdCB0 aGVyZSBhcmUgbm93IG5vIHJlbWFpbmluZyBzZXJpb3VzIG9iamVjdGlvbnMgdG8NCj50aGUgcmVj b21tZW5kZWQgcGFyYW1ldGVycyBpbiB0aGUgbGF0ZXN0IHZlcnNpb24gb2YgdGhlIGRyYWZ0Og0K Pg0KPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlydGYtY2ZyZy1hcmdv bjIvDQo+DQo+DQo+SWYgdGhlcmUgYXJlIGZ1cnRoZXIgc3Vic3RhbnRpdmUgdGVjaG5pY2FsIGNv bW1lbnRzIGZyb20gdGhlIENGUkcNCj5tZW1iZXJzaGlwLCB0aGUgY2hhaXJzIHdvdWxkIGJlIGdy YXRlZnVsIGlmIHRoZXkgY291bGQgYmUgYnJvdWdodCB0byB0aGUNCj5saXN0IGluIHRoZSBuZXh0 IGZldyBkYXlzLg0KPg0KPkFzc3VtaW5nIHdlIGhhdmUgaW5kZWVkIHJlYWNoZWQgY29uc2Vuc3Vz LCB0aGVuIHdlIHdpbGwgYmUgaW4gYSBwb3NpdGlvbg0KPnRvIG1vdmUgdG8gbGFzdCBjYWxsIGZv ciB0aGlzIElELg0KPg0KPlRoYW5rcywNCj4NCj5LZW5ueSAoZm9yIHRoZSBjaGFpcnMpDQo+DQo+ DQo+T24gMjcvMDMvMjAxNyAxMTo1MSwgIkNmcmcgb24gYmVoYWxmIG9mIERtaXRyeSBLaG92cmF0 b3ZpY2giDQo+PGNmcmctYm91bmNlc0BpcnRmLm9yZyBvbiBiZWhhbGYgb2Yga2hvdnJhdG92aWNo QGdtYWlsLmNvbT4gd3JvdGU6DQo+DQo+PlNvbWUgY29tbWVudHMgb24gYSBuZXcgZHJhZnQ6VmFy aWFudHNBcmdvbjIgZmlsbHMgTSBieXRlcyBvZiBtZW1vcnkgaW4gVA0KPj5pdGVyYXRpb25zIG92 ZXINCj4+IGl0LCB3aXRoIE0gYW5kIFQgYmVpbmcgdGhlIHBhcmFtZXRlcnMgc3VwcGxpZWQgdG8g QXJnb24yIGFuZCBkZXRlcm1pbmluZw0KPj5pdHMgcGVyZm9ybWFuY2UuIFNwZWVkIG9uIGEgdHlw aWNhbCBzZXJ2ZXIgaXMgbGluZWFyIGluIHRoZSBNVCBwcm9kdWN0Lg0KPj4NCj4+VGhlIEFyZ29u MiBmYW1pbHkgaGFzIHRocmVlIHZhcmlhbnRzOiBJLCBELCBhbmQNCj4+IElELCB3aGljaCBkaWZm ZXIgaW4gdGhlIHdheSBvZiByZXVzaW5nIG1lbW9yeSB0aGF0IGhhcyBiZWVuIGZpbGxlZC4gVGhl DQo+PkkgdmFyaWFudCBtYWtlcyBxdWVyaWVzIHdpdGggcHJlZGljdGFibGUgYWRkcmVzc2VzLCB3 aGVyZWFzIEQgZGV0ZXJtaW5lcw0KPj50aGUgYWRkcmVzc2VzIG9uIHRoZSBmbHkgZGVwZW5kaW5n IG9uIHRoZSBjdXJyZW50IHN0YXRlIChhbmQgdGh1cyB0aGUNCj4+cGFzc3dvcmQpLiBUaGUgSUQg dmFyaWFudCBmb2xsb3dzIEkgZm9yIHRoZQ0KPj4gZmlyc3QgaGFsZiBvZiB0aGUgbWVtb3J5IHVz ZWQgYW5kIEQgZm9yIHRoZSByZXN0IGFuZCB3aGlsZSBvdmVyd3JpdGluZy4NCj4+U2lkZS1jaGFu bmVsc1RoZSBzaWRlLWNoYW5uZWwgYXR0YWNrcywgd2hpY2ggYXJlIG9mIHN0aWxsIHJpc2luZw0K Pj4gY29uY2VybiBpbiB0aGUgc2VjdXJpdHkgY29tbXVuaXR5LCBhcmUgYXBwbGljYWJsZSB0byB0 aGUgRCB2YXJpYW50IGFzDQo+PnRoZSBtZW1vcnkgYWRkcmVzc2VzIGFuZCB0aHVzIGluZm9ybWF0 aW9uIGFib3V0IHRoZSBwYXNzd29yZCBvciBvdGhlcg0KPj5zZWNyZXQgaW5wdXRzIGNhbiBiZSBk ZXRlcm1pbmVkIGZyb20gdGhlIHRpbWluZyBsZWFrcy4gVGhlIEkgdmFyaWFudCBpcw0KPj5jb21w bGV0ZWx5IGludnVsbmVyYWJsZSB0byB0aGlzIGF0dGFjaywgYW5kDQo+PiB0aGUgSUQgdmFyaWFu dCBwcm92aWRlcyBvbmx5IGEgY29uc3RhbnQgZmFjdG9yIGltcHJvdmVtZW50IGZvciB0aGUNCj4+ YXR0YWNrZXIuDQo+PkhhcmR3YXJlIGFuZCB0cmFkZW9mZnNUaGUgTSBhbmQgVCBwYXJhbWV0ZXJz IGRldGVybWluZSB0aGUgY29zdCBvZg0KPj5icnV0ZWZvcmNpbmcNCj4+IHBhc3N3b3JkcyBvbiBj dXN0b20gaGFyZHdhcmUsIHdoaWNoIGlzIHByb3BvcnRpb25hbCB0byBNMlQNCj4+IGlmIHdlIGZv bGxvdyB0aGUgdHJhZGl0aW9uYWwgdGltZS1hcmVhIHByb2R1Y3QgbWV0cmljLiBUaGUgdGltZS1t ZW1vcnkNCj4+dHJhZGVvZmYgYW5hbHlzaXMgWzJdIHNob3dzIHRoYXQgdGhlIGJydXRlZm9yY2Ug Y29zdCBmb3IgdGhlIEkgdmFyaWFudA0KPj5jYW4gYmUgY2hhbmdlZCB0byBNMlQvUShNLFQpDQo+ PiBmb3Igc29tZSBxdWFsaXR5IGZ1bmN0aW9uIFEuIEZvciBpbnN0YW5jZSwgUSgyMzAsMSk9NSwN Cj4+IFEoMjMwLDQpPTIuNS4NCj4+DQo+PlRoZSBEIHZhcmlhbnQgaXMgaW52dWxuZXJhYmxlIHRv IHRoZSBhcHByb2FjaCBbMl0sDQo+PiBhbmQgdGhlIHNhdmluZ3MgZmFjdG9yIGluIHRoZSBJRCB2 YXJpYW50IGlzIHVwcGVyIGJvdW5kZWQgYnkgZmFjdG9yIDINCj4+Zm9yIGFsbCBwYXJhbWV0ZXJz Lg0KPj5EZWZlbmRlciB0cmFkZW9mZiBhbmQgdWx0aW1hdGUNCj4+IHJlY29tbWVuZGF0aW9uc0lu IHB1YmxpYyBhbmQgcHJpdmF0ZSBjb252ZXJzYXRpb25zIHdpdGggc2VjdXJpdHkNCj4+IGFyY2hp dGVjdHMgaW4gdGhlIGluZHVzdHJ5IHdlIGxlYXJuZWQgdGhhdCB0aGUgYm90dGxlbmVjayBpbiBh IHN5c3RlbQ0KPj5lbXBsb3lpbmcgdGhlIHBhc3N3b3JkLWhhc2hpbmcgZnVuY3Rpb24gaXMgdGhl IGZ1bmN0aW9uIGxhdGVuY3kgcmF0aGVyDQo+PnRoYW4gbWVtb3J5IGNvc3RzLiBXZSB0aGVuIGFz c3VtZSB0aGF0IGEgcmF0aW9uYWwgZGVmZW5kZXIgd291bGQgbGlrZSB0bw0KPj5tYXhpbWl6ZSB0 aGUgYnJ1dGVmb3JjZSBjb3N0cyBmb3IgdGhlIGF0dGFja2VyDQo+PiBlcXVpcHBlZCB3aXRoIGEg bGlzdCBvZiBoYXNoZXMsIHNhbHRzLCBhbmQgdGltaW5nIGluZm9ybWF0aW9uLCBmb3IgZml4ZWQN Cj4+Y29tcHV0aW5nIHRpbWUgb24gdGhlDQo+PiBkZWZlbmRlcuKAmXMgbWFjaGluZS4gIEluIHRo aXMgYXNzdW1wdGlvbiB0aGUgZGVmZW5kZXIga2VlcHMgdGhlIE1UDQo+PnByb2R1Y3QgY29uc3Rh bnQgYW5kIG1heGltaXplcyB0aGUgbG9zc2VzIE0vUShNLFQpLg0KPj4gVGhlIGF1dGhvcnMgb2Yg WzJdIHByb3ZpZGVzIHVzIHdpdGggYXR0YWNrIGNvc3QgZXN0aW1hdGVzIGZvciBjb25zdGFudA0K Pj5NVCA9IDIyOCwyMzAsMjMyDQo+PiAobWVhc3VyZWQgaW4gaXRlcmF0aW9uLWJ5dGVzKQ0KPj4N Cj4+V2UgdWx0aW1hdGVseSByZWNvbW1lbmQgdGhlIElEIHZhcmlhbnQgd2l0aCBUPTEgYW5kIG1h eGltdW0gTSBhcyBhDQo+PmRlZmF1bHQgc2V0dGluZyBmb3IgYWxsIGVudmlyb25tZW50cywgd2hp Y2ggaXMgc2VjdXJlDQo+PiBhZ2FpbnN0IHNpZGUtY2hhbm5lbCBhdHRhY2tzIGFuZCBwcm9oaWJp dCBhZHZlcnNhcmlhbCBhZHZhbnRhZ2Ugb24NCj4+ZGVkaWNhdGVkIGJydXRlZm9yY2UgaGFyZHdh cmUuDQo+Pg0KPj4NCj4+UmVmZXJlbmNlc1sxXQ0KPj7igJxFZmZpY2llbnRseSBDb21wdXRpbmcg RGF0YS1JbmRlcGVuZGVudA0KPj4gTWVtb3J5LUhhcmQgRnVuY3Rpb25z4oCdIDxodHRwOi8vZXBy aW50LmlhY3Iub3JnLzIwMTYvMTE1LnBkZj4NCj4+WzJdDQo+PuKAnFRvd2FyZHMgUHJhY3RpY2Fs IEF0dGFja3Mgb24NCj4+IEFyZ29uMmkgYW5kIEJhbGxvb24gSGFzaGluZ+KAnSAgPGh0dHA6Ly9l cHJpbnQuaWFjci5vcmcvMjAxNi83NTkucGRmPg0KPj4NCj4+DQo+Pg0KPj4NCj4+DQo+Pk9uIE1v biwgTWFyIDI3LCAyMDE3IGF0IDEyOjQ2IFBNLCA8aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPiB3 cm90ZToNCj4+DQo+Pg0KPj5BIE5ldyBJbnRlcm5ldC1EcmFmdCBpcyBhdmFpbGFibGUgZnJvbSB0 aGUgb24tbGluZSBJbnRlcm5ldC1EcmFmdHMNCj4+ZGlyZWN0b3JpZXMuDQo+PlRoaXMgZHJhZnQg aXMgYSB3b3JrIGl0ZW0gb2YgdGhlIENyeXB0byBGb3J1bSBvZiB0aGUgSUVURi4NCj4+DQo+PiAg ICAgICAgVGl0bGUgICAgICAgICAgIDogVGhlIG1lbW9yeS1oYXJkIEFyZ29uMiBwYXNzd29yZCBo YXNoIGFuZA0KPj5wcm9vZi1vZi13b3JrIGZ1bmN0aW9uDQo+PiAgICAgICAgQXV0aG9ycyAgICAg ICAgIDogQWxleCBCaXJ5dWtvdg0KPj4gICAgICAgICAgICAgICAgICAgICAgICAgIERhbmllbCBE aW51DQo+PiAgICAgICAgICAgICAgICAgICAgICAgICAgRG1pdHJ5IEtob3ZyYXRvdmljaA0KPj4g ICAgICAgICAgICAgICAgICAgICAgICAgIFNpbW9uIEpvc2Vmc3Nvbg0KPj4gICAgICAgIEZpbGVu YW1lICAgICAgICA6IGRyYWZ0LWlydGYtY2ZyZy1hcmdvbjItMDIudHh0DQo+PiAgICAgICAgUGFn ZXMgICAgICAgICAgIDogMjYNCj4+ICAgICAgICBEYXRlICAgICAgICAgICAgOiAyMDE3LTAzLTI3 DQo+Pg0KPj5BYnN0cmFjdDoNCj4+ICAgVGhpcyBkb2N1bWVudCBkZXNjcmliZXMgdGhlIEFyZ29u MiBtZW1vcnktaGFyZCBmdW5jdGlvbiBmb3IgcGFzc3dvcmQNCj4+ICAgaGFzaGluZyBhbmQgcHJv b2Ytb2Ytd29yayBhcHBsaWNhdGlvbnMuICBXZSBwcm92aWRlIGFuIGltcGxlbWVudGVyDQo+PiAg IG9yaWVudGVkIGRlc2NyaXB0aW9uIHRvZ2V0aGVyIHdpdGggc2FtcGxlIGNvZGUgYW5kIHRlc3Qg dmVjdG9ycy4gIFRoZQ0KPj4gICBwdXJwb3NlIGlzIHRvIHNpbXBsaWZ5IGFkb3B0aW9uIG9mIEFy Z29uMiBmb3IgSW50ZXJuZXQgcHJvdG9jb2xzLg0KPj4NCj4+DQo+PlRoZSBJRVRGIGRhdGF0cmFj a2VyIHN0YXR1cyBwYWdlIGZvciB0aGlzIGRyYWZ0IGlzOg0KPj5odHRwczovL2RhdGF0cmFja2Vy LmlldGYub3JnL2RvYy9kcmFmdC1pcnRmLWNmcmctYXJnb24yLw0KPj4NCj4+VGhlcmUgYXJlIGFs c28gaHRtbGl6ZWQgdmVyc2lvbnMgYXZhaWxhYmxlIGF0Og0KPj5odHRwczovL3Rvb2xzLmlldGYu b3JnL2h0bWwvZHJhZnQtaXJ0Zi1jZnJnLWFyZ29uMi0wMg0KPj5odHRwczovL2RhdGF0cmFja2Vy LmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LWlydGYtY2ZyZy1hcmdvbjItMDINCj4+DQo+PkEgZGlm ZiBmcm9tIHRoZSBwcmV2aW91cyB2ZXJzaW9uIGlzIGF2YWlsYWJsZSBhdDoNCj4+aHR0cHM6Ly93 d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWlydGYtY2ZyZy1hcmdvbjItMDINCj4+DQo+ Pg0KPj5QbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJv bSB0aGUgdGltZSBvZg0KPj5zdWJtaXNzaW9uDQo+PnVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9u IGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQNCj4+dG9vbHMuaWV0Zi5vcmcgPGh0dHA6Ly90b29s cy5pZXRmLm9yZz4uDQo+Pg0KPj5JbnRlcm5ldC1EcmFmdHMgYXJlIGFsc28gYXZhaWxhYmxlIGJ5 IGFub255bW91cyBGVFAgYXQ6DQo+PmZ0cDovL2Z0cC5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMv DQo+Pg0KPj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K Pj5DZnJnIG1haWxpbmcgbGlzdA0KPj5DZnJnQGlydGYub3JnDQo+Pmh0dHBzOi8vd3d3LmlydGYu b3JnL21haWxtYW4vbGlzdGluZm8vY2ZyZw0KPj4NCj4+DQo+Pg0KPj4NCj4+DQo+Pg0KPj4NCj4+ LS0gDQo+PkJlc3QgcmVnYXJkcywNCj4+RG1pdHJ5IEtob3ZyYXRvdmljaA0KPj4NCj4+DQo+DQoN Cg== From nobody Wed Jul 5 00:43:47 2017 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 25691131AC2 for ; Wed, 5 Jul 2017 00:43:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.911 X-Spam-Level: X-Spam-Status: No, score=-2.911 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_H5=-1, RCVD_IN_MSPIKE_WL=-0.01, 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 kd7YpMvw_Q7J for ; Wed, 5 Jul 2017 00:43:43 -0700 (PDT) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01on0073.outbound.protection.outlook.com [104.47.0.73]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A33E131AC0 for ; Wed, 5 Jul 2017 00:43:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rhul.onmicrosoft.com; s=selector1-rhul-ac-uk; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=4GuChGlYQ/hR1tKLf2rRnjSyEhUMJ9xS0aSnrMtPZ7s=; b=A4U2U2HHULjIDof0/+VGbRzjvMuwCiFP7aMj6WhToWfPdFgDvoChXBa/1vCL5k1CR7Pw1pyIHTySLjx/IvrFUS0TvPzCsn5QB51CJ1kDPrPyNicaS2DnGKWVUjZir1DIgsiqYE/DlBWzlY87aJxMV/lijRjaOFKgd9/qBDOlTts= Received: from AM4PR0301MB1906.eurprd03.prod.outlook.com (10.168.2.156) by AM4PR0301MB1906.eurprd03.prod.outlook.com (10.168.2.156) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1220.11; Wed, 5 Jul 2017 07:43:39 +0000 Received: from AM4PR0301MB1906.eurprd03.prod.outlook.com ([fe80::482:61a:3f1b:be7a]) by AM4PR0301MB1906.eurprd03.prod.outlook.com ([fe80::482:61a:3f1b:be7a%14]) with mapi id 15.01.1220.018; Wed, 5 Jul 2017 07:43:38 +0000 From: "Paterson, Kenny" To: Shay Gueron , Adam Langley , Yehuda Lindell CC: "cfrg@irtf.org" Thread-Topic: Reviews of AES-GCM-SIV (draft-irtf-cfrg-gcmsiv-04.txt) Thread-Index: AQHS9WJqB08RIbvyeEucDrswwscvig== Date: Wed, 5 Jul 2017 07:43:38 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.1.161129 authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=rhul.ac.uk; x-originating-ip: [134.219.227.30] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM4PR0301MB1906; 7:m8uFUq2VLrz9uY6+PeuNxoa471Hnb4JBfLaqytYjvTMCwJg00A9d8AUXlIB3dSJ/jl7FzIiRRItjqwqMXRfDcetpwCNVuPHcrU4Xoy9WR4o4gNztOizrlRWo20/r2KXmIGHsT+nq1An5vcJGCDUC/O7H6dxu72qj6nj7VaPnG7EkMx+HBQ73qBLLDGxuz/m020ws9bmijcBRWsXKJx2Ur/cLeO7OqGwjDnORRnBZ5dhS6kcy3L3yDNijua1+gZKK7AxDR6JpIvOEgLAlaymViNyYSiHxCUI+64XgoNs3DC2WlYeXpG9P7lFGz8HtwkWoHR3285dEMWbkjdCCvOGRnhLYd2np9mXZFPy8LC++Kigur2dWTfiRH5vrohSZoxOpkWXYhXGJYQbsSzKXd+Y/dRceV7ULduh0G6pdlxfhInWN9oQnRGl0P0ta4A9t8IXAgce5bS6QqvZbKKqkdOemoCHOrXzRONITVf2oUy36ez87PTJW5y3nLtbemdnFdoEPj/o6Fzsg25QM9b9ucKVPvE4072rXqpUfomZF5dVxWxFb4RAvSZTXv7Mw3VBHZmexMgGLjzP+4EMlpM1fOV9laAHg55DsmF4OQWbydmtDbUnecT5E5zWDuJld2H38xcRdsri7oyxWLeva4TgFP5J0aaUnHaEodvxdBW9xx+DOYGwsBicEAFHCgi0g88e7lcA3Zvtn8BkmqAqE3CQcQioodeP6NdqIBQLYMslcYAGGdD/Y/lzVeoUOSnsi/mSeN4TKVUTePUXaador2HB5gK5G6J7C/2242tWFPJLOPZldXac= x-forefront-antispam-report: SFV:SKI; SCL:-1SFV:NSPM; SFS:(10009020)(6009001)(39840400002)(39410400002)(39450400003)(39850400002)(39400400002)(51694002)(54094003)(51444003)(66066001)(2906002)(99286003)(230783001)(50986999)(42882006)(54356999)(36756003)(7736002)(38730400002)(305945005)(106356001)(6512007)(81166006)(8936002)(8676002)(74482002)(53936002)(4326008)(3660700001)(6116002)(3846002)(102836003)(2900100001)(3280700002)(413944005)(6436002)(25786009)(72206003)(478600001)(14454004)(189998001)(39060400002)(83506001)(6486002)(6506006)(4001350100001)(5660300001)(5250100002)(86362001); DIR:OUT; SFP:1101; SCL:1; SRVR:AM4PR0301MB1906; H:AM4PR0301MB1906.eurprd03.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; x-ms-office365-filtering-correlation-id: 52276859-2461-4efe-f86b-08d4c3798ce2 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:AM4PR0301MB1906; x-ms-traffictypediagnostic: AM4PR0301MB1906: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(278178393323532)(278428928389397)(236129657087228)(192374486261705)(788757137089)(48057245064654)(148574349560750)(92977632026198)(247924648384137); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(100000703101)(100105400095)(93006095)(93001095)(6041248)(20161123555025)(20161123562025)(20161123560025)(201703131423075)(201702281528075)(201702281529075)(201703061421075)(201703061406153)(20161123564025)(20161123558100)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:AM4PR0301MB1906; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:AM4PR0301MB1906; x-forefront-prvs: 0359162B6D spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <01693C62E3B9AF42A7D1D1ACAF3F8772@eurprd03.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: rhul.ac.uk X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Jul 2017 07:43:38.7445 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2efd699a-1922-4e69-b601-108008d28a2e X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR0301MB1906 Archived-At: Subject: [Cfrg] Reviews of AES-GCM-SIV (draft-irtf-cfrg-gcmsiv-04.txt) X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jul 2017 07:43:46 -0000 RGVhciBBZGFtLCBTaGF5IGFuZCBZZWh1ZGEsDQoNCldlJ3ZlIG5vdyByZWNlaXZlZCAzIHJldmll d3Mgb24gZHJhZnQtaXJ0Zi1jZnJnLWdjbXNpdi0wNC50eHQgZnJvbSB0aGUNCkNGUkcgY3J5cHRv IHJldmlldyBwYW5lbCwgc2VlIGJlbG93IC0gdGhhbmtzIHRvIFNjb3R0IEZsdWhyZXIsIFRpYm9y IEphZ2VyDQphbmQgQmpvZXJuIFRhY2ttYW5uIGZvciBwcm9kdWNpbmcgdGhlc2UuDQoNClBsZWFz ZSByZWFkIHRoZXNlIHJldmlld3MgY2FyZWZ1bGx5IGFuZCB0YWtlIHRoZW0gaW50byBhY2NvdW50 IGluIHRoZSBuZXh0DQp2ZXJzaW9uIG9mIHlvdXIgZHJhZnQuIEl0IHdvdWxkIGJlIGhlbHBmdWwg aWYgeW91IGNvdWxkIHJlc3BvbmQgb24gbGlzdCBhcw0KdG8gaG93IHlvdSBoYXZlIGhhbmRsZWQg dGhlIHZhcmlvdXMgY29tbWVudHMuDQoNCk5vdGUgdGhhdCB5b3Ugd2lsbCBub3QgYmUgYWJsZSB0 byBwb3N0IGEgbmV3IGRyYWZ0IGZvciBhIHdoaWxlIGJlY2F1c2Ugb2YNCnRoZSBjdXRvZmYgaW4g YWR2YW5jZSBvZiB0aGUgZm9ydGhjb21pbmcgSUVURiBtZWV0aW5nLg0KDQpPbmNlIHRoZSBuZXh0 IHZlcnNpb24gaXMgYXZhaWxhYmxlLCB3ZSB3aWxsIGdvIHRvIGxhc3QgY2FsbC4NCg0KQmVzdCB3 aXNoZXMsDQoNCktlbm55IChmb3IgdGhlIGNoYWlycykNCg0KDQo9PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT0NClJldmlld2VyOiBTY290dCBGbHVocmVyDQoNClN1bW1hcnk6IEFsbW9zdCBS ZWFkeQ0KDQpNYWpvciBDb25jZXJuczoNCg0KTm9uZSAtIGZyb20gYSBzZWN1cml0eSBwZXJzcGVj dGl2ZSwgaXQgbG9va3MgcHJldHR5IGdvb2QNCg0KDQpNaW5vciBDb25jZXJuOg0KDQpPbmUgdGhp bmcgdGhhdCBtYXkgYmUgcHJvYmxlbWF0aWMgdG8gYW4gaW1wbGVtZW50b3Igd2FzIHRoZSBub25j ZXMgbGlzdGVkDQppbiB0aGUgdGVzdCB2ZWN0b3JzLiAgQUVTLUdDTS1TSVYgdGFrZXMgMTIgYnl0 ZSBub25jZXMsIHRoZSBub25jZXMgbGlzdGVkDQphcmUgMTYgYnl0ZXMgbG9uZy4gIFdoaWxlIHRo aXMgaXMgdW5saWtlbHkgdG8gYmUgYSBtYWpvciBzb3VyY2Ugb2YNCmNvbmZ1c2lvbiBmb3IgYW4g aW1wbGVtZW50YXRvciwgSSBzdWdnZXN0IHRoYXQgdGhlIG5vbmNlcyBiZSB0cmltbWVkIGRvd24N CmJlZm9yZSBwdWJsaXNoaW5nLg0KDQoNCk5pdHM6DQoNClRoZSBlbmNyeXB0aW9uL2RlY3J5cHRp b24gYWxnb3JpdGhtcyBhcmUgZ2l2ZW4gdXNpbmcgZmFpcmx5IHRlcnNlIEVuZ2xpc2gNCmRlc2Ny aXB0aW9ucy4gIFdoaWxlIHRoZXkgYXJlIG1vZGVyYXRlbHkgY2xlYXIgdG8gbWUsIEkgd29uZGVy IGlmIHRoZXknZA0KYmUgYXMgY2xlYXIgdG8gc29tZW9uZSBlbHNlOyBJJ20gd29uZGVyaW5nIGlm IGEgcHNldWRvY29kZSBkZXNjcmlwdGlvbg0Kd291bGQgd29yayBiZXR0ZXI/ICBPbiB0aGUgb3Ro ZXIgaGFuZCwgdGhlIHRlc3QgdmVjdG9ycyBnaXZlIGludGVybWVkaWF0ZQ0KY2lwaGVyc3RhdGVz ICh3aGljaCB3b3VsZCBoZWxwIGEgbG90KS4NCg0KV2hpbGUgdGhlIHRlc3QgdmVjdG9ycyBhcmUg cXVpdGUgZ29vZCBpbiBnZW5lcmFsLCB0aGV5IHVzZSBvbmx5IG9uZSBub25jZSwNCmFuZCB0d28g a2V5cyAob25lIGZvciBlYWNoIGtleSBsZW5ndGgpLiAgV2hpbGUgdGhlcmUgaXMgY2VydGFpbmx5 IHZhbHVlIGluDQpyZXVzaW5nIHRoZSBzYW1lIGtleSBhbmQgbm9uY2UgZm9yIHNsaWdodGx5IGRp ZmZlcmVudCBwbGFpbnRleHRzL0FBRHMsIEkNCmJlbGlldmUgdGhlcmUgd291bGQgYWxzbyBiZSB2 YWx1ZSBpbiBzaG93aW5nIGhvdyBkaWZmZXJlbnQga2V5cy9ub25jZXMNCndvcmsuICBPbmUgZXhh bXBsZTogYXQgb25lIHBvaW50LCAgQUVTLUdDTS1TSVYgeG9yJ3MgaW4gdGhlIG5vbmNlIGludG8g dGhlDQpQT0xZVkFMIHJlc3VsdC4gIElmIHNvbWVvbmUgZGlkIGFuIGluY29ycmVjdCBpbXBsZW1l bnRhdGlvbiB3aGVyZSAoc2F5KQ0KdGhleSBleGNsdXNpdmUtb3InZWQgb25seSB0aGUgZmlyc3Qg NCBvciA4IGJ5dGVzIG9mIHRoZSBub25jZSwgdGhlIGN1cnJlbnQNCnRlc3QgdmVjdG9ycyB3b3Vs ZCBzdGlsbCBwYXNzLg0KDQpUaGUgYnl0ZXMgaW4gdGhlIHRlc3QgdmVjdG9yIGFyZSBsaXN0ZWQg TFNCIHRvIE1TQi4gIFRoaXMgcmF0aGVyIGFzc3VtZXMNCnRoYXQgdGhlIGltcGxlbWVudG9yIGlz IHVzaW5nIGxpdHRsZS1lbmRpYW4gYnl0ZSBvcmRlcmluZzsgSSB3b3VsZCBzdWdnZXN0DQp0aGF0 IHRoaXMgYmUgY2hhbmdlZCB0byBhIG1vcmUgZW5kaWFuLW5ldXRyYWwgbm90YXRpb24gKHBvc3Np Ymx5IGJ5IGp1c3QNCm9taXR0ZWQgdGhlIExTQiBhbmQgTVNCIGxhYmVscykuDQoNCg0KDQo9PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT0NCj09PT09DQoNClJldmlld2VyOiBUaWJvciBKYWdlcg0KDQpTdW1tYXJ5 OiBhbG1vc3QgcmVhZHkNCg0KPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PQ0KTWFqb3IgY29uY2VybnM6DQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09DQoNCm5vbmUNCg0KPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0K TWlub3IgY29tbWVudHMgYW5kIHJlY29tbWVuZGF0aW9uczoNCj09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT0NCg0KDQpUaGUgZHJhZnQgaXMgc29tZXdoYXQgdW5jbGVhciB3 aGV0aGVyIHBsYWludGV4dHMgYW5kIGFkZGl0aW9uYWwgZGF0YQ0KKEFEKSBhcmUgYWx3YXlzIGFz c3VtZWQgdG8gYmUgZ2l2ZW4gYXMgKmJ5dGUqLXN0cmluZ3MsIG9yIHdoZXRoZXIgaXQgaXMNCmFs c28gcG9zc2libGUgdG8gZW5jcnlwdCBhcmJpdHJhcnktbGVuZ3RoICpiaXQqLXN0cmluZ3Mgd2hv c2UgbGVuZ3RoIGlzDQpub3QgYSBtdWx0aXBsZSBvZiA4Lg0KDQoNCk9uIHRoZSBvbmUgaGFuZCwg YXQgdGhlIGJlZ2lubmluZyBvZiBTZWN0aW9uIDQgaXQgaXMgY2xlYXJseSBzdGF0ZWQgdGhhdA0K dGhlIGVuY3J5cHRpb24gYWxnb3JpdGhtIHRha2VzICJhcmJpdHJhcnktbGVuZ3RoIHBsYWludGV4 dCAmIGFkZGl0aW9uYWwNCmRhdGEgKmJ5dGUqLXN0cmluZ3MiLg0KDQpPbiB0aGUgb3RoZXIgaGFu ZCwgdGhlbiBpdCB3b3VsZCBhbHNvIGJlIHNvbWV3aGF0IG1vcmUNCmludHVpdGl2ZS9jb25zaXN0 ZW50IHRvIGluY2x1ZGUNCnRoZSAqYnl0ZSotbGVuZ3RoIG9mIHBsYWludGV4dCBhbmQgQUQgaW4g dGhlIGxlbmd0aCBibG9jay4gVGhlIGN1cnJlbnQNCmRyYWZ0IGluY2x1ZGVzIHRoZSBiaXQtbGVu Z3RoLiAoVGhpcyBpcyBvZiBjb3Vyc2UgdGVjaG5pY2FsbHkgZmluZSBhbmQNCmVzc2VudGlhbGx5 IGp1c3QgYSBkaWZmZXJlbnQgbm90YXRpb24sIGJ1dCAqY291bGQqIGJlIG1pc2xlYWRpbmcgZm9y DQpkZXZlbG9wZXJzLikgQWxzbyB0aGUgZXhhbXBsZSBpbiBTZWN0aW9uIDggbWVudGlvbnMgdGhl IGJpdC1sZW5ndGggb2YNCnBsYWludGV4dC9BRC4NCg0KSGVuY2UsIEkgd2FudCB0byBzdWdnZXN0 IHRvIG1lbnRpb24gdGhpcyBhc3N1bXB0aW9uIGFib3V0IHRoZSBwbGFpbnRleHQNCmxlbmd0aCBt b3JlIGNsZWFybHkgLSBldmVuIGlmIGl0IHNlZW1zIHF1aXRlIHN0YW5kYXJkIGFuZCB3aWxsIG1v c3QNCmxpa2VseSBob2xkIGZvciBtb3N0IGFwcGxpY2F0aW9uIGFueXdheS4NCg0KSW4gdGhlIHdv cnN0IGNhc2UsIGlmIGEgZGV2ZWxvcGVyIG1pc3VuZGVyc3RhbmRzIHRoaXMgYW5kIGFsbG93cyB0 aGUNCmVuY3J5cHRpb24gd2l0aCBhcmJpdHJhcnkgYml0LWxlbmd0aCBwbGFpbnRleHQgYW5kIEFE LCB0aGVuIHRoaXMgbWF5DQplbmFibGUgdG8gYnJlYWsgdGhlIGludGVncml0eSBvZiBjaXBoZXJ0 ZXh0cyAoYXQgbGVhc3QgaW4gdGhlb3J5KSwgaWYNCnRoZSBieXRlbGVuKCkgZnVuY3Rpb24gaXMg aW1wbGVtZW50ZWQgaW4gdGhlIG5hdHVyYWwgd2F5Lg0KDQpMZXQgQyA9IEVuYyhrLG0sZCxuKSBi ZSBhIGNpcGhlcnRleHQsIGVuY3J5cHRpbmcgcGxhaW50ZXh0IG0gd2l0aCBrZXkgaywNCm5vbmNl IG4sIGFuZCBhZGRpdGlvbmFsIGRhdGEgZC4gU3VwcG9zZSB0aGF0IHxkfCA9IDcgYml0cywgYW5k IHRoYXQNCmJ5dGVsZW4oKSBpcyBpbXBsZW1lbnRlZCBzdWNoIHRoYXQgYnl0ZWxlbihkKSA9IDEg KHdoaWNoIHNlZW1zIG5hdHVyYWwsDQpldmVuIHRvdWdoIGJ5dGVsZW4oZCkgPSA3Lzggd291bGQg YWN0dWFsbHkgYmUgY29ycmVjdCkuIE5vdGUgdGhhdCB0aGUNCmVuY3J5cHRpb24gYWxnb3JpdGht IHBhZHMgZCB3aXRoIHplcm9lcyB0byBhIG11bHRpcGxlIG9mIDE2IGJ5dGVzIGJlZm9yZQ0KaXQg aXMgcHJvY2Vzc2VkIGJ5IFBPTFlWQUwsIHN1Y2ggdGhhdCBpbiBwYXJ0aWN1bGFyIGl0IGhvbGRz IHRoYXQNCg0KICBDID0gRW5jKGssbSxkLG4pID0gRW5jKGssbSxkfHwwLG4pDQoNCmFuZCB0aGUg ZGVjcnlwdGlvbiBhbGdvcml0aG0gYWNjZXB0cyBib3RoIGQgYW5kIGR8fDAgYXMgInZhbGlkIg0K YWRkaXRpb25hbCBkYXRhIGZvciBDLg0KDQpPZiBjb3Vyc2UgdGhpcyBhdHRhY2sgaXMgcmF0aGVy IHRoZW9yZXRpY2FsLCBidXQgaXQgY2FuIGVhc2lseSBiZQ0KYXZvaWRlZCBieSBlaXRoZXIgaW5j bHVkaW5nIHRoZSBwcmVjaXNlICpiaXQqLWxlbmd0aCBvZiBwbGFpbnRleHQgYW5kIEFEDQppbnRv IHRoZSBsZW5ndGggYmxvY2ssIG9yIGJ5IGxldHRpbmcgdGhlIGVuY3J5cHRpb24gYWxnb3JpdGht IGFib3J0LCBpZg0KdGhlIGxlbmd0aHMgb2YgcGxhaW50ZXh0cyBvciBBRCBhcmUgbm90IGEgbXVs dGlwbGUgb2YgOCBiaXRzIChhbmQgb25lDQpjb3VsZCBpZ25vcmUgdGhpcyBjaGVjayBpbiBhcHBs aWNhdGlvbnMgd2hlcmUgdGhpcyBpcyBndWFyYW50ZWVkIGJ5IHRoZQ0KZW52aXJvbm1lbnQgLSBi dXQgdGhpcyBpcyBvZiBjb3Vyc2Ugc29tZXRoaW5nIHRoYXQgb25seSB0aGUgYXBwbGljYXRpb24N CmRldmVsb3BlciBjYW4gZGVjaWRlKS4NCg0KDQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09DQpOaXRwaWNraW5nOg0KPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PQ0KDQpTZWN0aW9uIDEgIkludHJvZHVjdGlvbiIsIDFzdCBwYXJhZ3JhcGg6IEkg c3VnZ2VzdCB0byByZXBsYWNlDQogICIuLi50aGF0IGlzIGVhc2llciBmb3IgcHJhY3RpdGlvbmVy cyB0byB1c2UgY29ycmVjdGx5LiINCndpdGgNCiAgInRoYXQgaXMgZWFzaWVyIHRvIHVzZSBjb3Jy ZWN0bHkuIg0KDQoNCkluIFNlY3Rpb24gNCwgZmlyc3QgcGFyYWdyYXBoLCB0aGUgdGV4dCBzdWdn ZXN0cyB0aGF0IHBsYWludGV4dHMgYW5kDQphZGRpdGlvbmFsIGRhdGEgb2YgYXJiaXRyYXJ5IGxl bmd0aCBjYW4gYmUgZW5jcnlwdGVkLiBIb3dldmVyLCB0aGUNCmRlc2NyaXB0aW9uIG9mIHRoZSBk ZWNyeXB0aW9uIHByb2NlZHVyZSBpbiBTZWN0aW9uIDUgcmVqZWN0cyBjaXBoZXJ0ZXh0cw0Kb2Yg c2l6ZSBsYXJnZXIgdGhhbiAyXjM2KzE2IGJ5dGVzLCBhbmQgU2VjdGlvbiA2IGdpdmVzIHVwcGVy IGJvdW5kcyBvbg0KdGhlIHBsYWludGV4dCBhbmQgQUQgc2l6ZXMgUF9NQVggYW5kIEFfTUFYLg0K DQoNCkluIFNlY3Rpb24gNCwgbGFzdCBwYXJhZ3JhcGgsIHRoZSByZXN1bHQgb2YgZW5jcnlwdGlv biBpcyB0aGUgInJlc3VsdGluZw0KY2lwaGVydGV4dCAuLi4gZm9sbG93ZWQgYnkgdGhlIHRhZyIu IFRodXMsIGluIHRoaXMgbm90YXRpb24sIHRoZSB0YWcgaXMNCm5vdCBwYXJ0IG9mIHRoZSAiY2lw aGVydGV4dCIsIGJ1dCBpdCBpcyBzZXBhcmF0ZSBhbmQgc2VudCBhbG9uZyB3aXRoIHRoZQ0KY2lw aGVydGV4dC4NCkhvd2V2ZXIsIGF0IHRoZSBiZWdpbm5pbmcgb2YgU2VjdGlvbiA1LCBkZWNyeXB0 aW9uIGFsZ29yaXRobSByZWNlaXZlcyBhcw0KaW5wdXQga2V5LCBub25jZSwgQUQsIGFuZCBhIGNp cGhlcnRleHQsIGFuZCB0aGUgY2lwaGVydGV4dCBpcyBzcGxpdCBpbnRvDQp0aGUgZW5jcnlwdGVk IHBsYWludGV4dCBhbmQgdGhlIHRhZywgdGh1cyB0aGUgImNpcGhlcnRleHQiIGNvbnRhaW5zIHRo ZQ0KdGFnIGhlcmUuIE9uZSBjb3VsZCB1bmlmeSB0aGlzLCBieSBhbHdheXMgY29uc2lkZXJpbmcg dGhlIHRhZyBhcyBwYXJ0IG9mDQp0aGUgY2lwaGVydGV4dC4NCg0KDQpTZWN0aW9uIDgsIHZlcnkg dmVyeSBuaXRwaWNraW5nOiBPbmUgY291bGQgbWVudGlvbiBoZXJlIHRoYXQgdGhlDQpwbGFpbnRl eHQgYXJlIHRoZSBiaXQgc3RyaW5ncyBjb3JyZXNwb25kaW5nIHRvIHRoZSAqQVNDSUkgZW5jb2Rp bmcqIG9mDQoiSGVsbG8gd29ybGQiIGFuZCAiZXhhbXBsZSIuDQoNCg0KU2VjdGlvbiA4LCA1dGgg cGFyYWdyYXBoLCBhZ2FpbiB2ZXJ5IG5pdHBpY2tpbmc6IFNvbWUgZGV2ZWxvcGVycyBtYXkNCmhh dmUgZGlmZmljdWx0aWVzIGluIHVuZGVyc3RhbmRpbmcgaW1tZWRpYXRlbHkgd2hpY2ggbnVtYmVy cyBhcmUgZ2l2ZW4NCmluIGhleGFkZWNpbWFsIG5vdGF0aW9uLCBhbmQgd2hpY2ggaW4gZGVjaW1h bCBub3RhdGlvbi4gRm9yIGNsYXJpdHksIG9uZQ0KY291bGQgd3JpdGUgaGVyZSBzb21ldGhpbmcg bGlrZToNCiJleGFtcGxlIjogNyBjaGFyYWN0ZXJzID0gNTYgYml0cyA9IDB4MzggYml0cw0KIkhl bGxvIHdvcmxkIjogMTEgY2hhcmFjdGVycyA9IDg4IGJpdHMgPSAweDU4IGJpdHMNCg0KDQpTZWN0 aW9uIDksIDd0aCBwYXJhZ3JhcGg6ICJTdXp1a2kgZXQgYWwuIFttdWx0aWJpcnRoZGF5XSIsIHRo ZSByZWZlcmVuY2UNCmxpc3RzIEthenVoaXJvIGFzIGZpcnN0IGF1dGhvciwgc28gaXQgc2VlbXMg dGhpcyBzaG91bGQgYmUgS2F6dWhpcm8gZXQgYWwuDQoNCg0KSSBkaWQgbm90IGNoZWNrIHRoZSB0 ZXN0IHZlY3RvcnMuDQoNCg0KUmVnYXJkaW5nIFNjb3R0J3MgY29tbWVudCBvbiB0aGUgdmVyYmFs IGRlc2NyaXB0aW9uIG9mIHRoZSBlbmNyeXB0aW9uDQphbmQgZGVjcnlwdGlvbiBhbGdvcml0aG1z OiBJIGhhZCB0aGUgc2FtZSBpbXByZXNzaW9uLCBzb21lIHBzZXVkb2NvZGUNCm1heSBiZSBoZWxw ZnVsIHRvIGNsYXJpZnkgd2hhdCBpcyBoYXBwZW5pbmcgaGVyZS4NCg0KDQpBcGFydCBmcm9tIHRo ZSBhYm92ZSBtaW5vciBjb21tZW50cywgSSB0aGluayB0aGF0IHRoaXMgaXMgYW4gZXhjZWxsZW50 DQpSRkMsIHdoaWNoIGlzIHZlcnkgY2xlYXIsIHByZWNpc2UsIGVhc3kgdG8gdW5kZXJzdGFuZCwg YW5kDQp3ZWxsLXJlYWRhYmxlLiBUaGUgbGFyZ2UgbnVtYmVyIG9mIHRlc3QgdmVjdG9ycyB3aWxs IGNlcnRhaW5seSBiZQ0KY29uc2lkZXJlZCB2ZXJ5IGhlbHBmdWwgdG8gbWFueSBpbXBsZW1lbnRl cnMuIEkgdGhpbmsgaXQgaXMgdmVyeSB1c2VmdWwNCnRvIGhhdmUgYSBub25jZSBtaXN1c2UtcmVz aXN0YW50IGVuY3J5cHRpb24gc2NoZW1lIGRlZmluZWQgaW4gYW4gUkZDLCBpbg0KcGFydGljdWxh ciBpZiBpdCBpcyBhcyBjb21wZXRpdGl2ZSB3aXRoIHdlYWtlciBzb2x1dGlvbnMgcmVnYXJkaW5n DQppbXBsZW1lbnRhdGlvbmFsIGRpZmZpY3VsdHkgYW5kIGNvbXB1dGF0aW9uYWwgZWZmaWNpZW5j eSBhcyB0aGlzIG9uZS4NCg0KPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09DQo9PT09PQ0KDQpSZXZpZXdlcjog QmpvZXJuIFRhY2ttYW5uDQoNClN1bW1hcnk6IEFsbW9zdCByZWFkeQ0KDQpNYWpvciBpc3N1ZXM6 IG5vbmUNCg0KTWlub3IgaXNzdWVzOg0KDQpJIGZvdW5kIHRoZSBkZXNjcmlwdGlvbiBvZiB0aGUg ZW5jcnlwdGlvbiBtZXRob2QgY29tcHJlaGVuc2libGUgYnV0IGEgYml0DQp0b28gaW5mb3JtYWwu IE1heWJlIGEgcHNldWRvLWNvZGUgZGVzY3JpcHRpb24gbWF5IGJlIGVhc2llciB0byB1bmRlcnN0 YW5kPw0KDQpJbiB0aGF0IGRlc2NyaXB0aW9uLCBJIHN0dW1ibGVkIHBhcnRpY3VsYXJseSBvdmVy IHRoZSDigJxfbGVuZ3RoIGJsb2NrX+KAnSAtDQp3aHkgdGhlIHVuZGVyc2NvcmVzPyBBbHNvLCBJ IHRoaW5rIGl0IHdvdWxkIG1ha2Ugc2Vuc2UgdG8gZXhwbGljaXRseQ0KY2xhcmlmeSB0aGF0IHRo ZSAzMi1iaXQgY291bnRlciB2YWx1ZSBmb3IgdGhlIENUUiBwYXJ0IGlzIGV4cGxpY2l0bHkNCmFs bG93ZWQgdG8gb3ZlcmZsb3cuDQoNCk9uZSBhc3BlY3QgdGhhdCByZWFkIGEgYml0IGFyYml0cmFy eSB0byBtZSB3YXMgdGhlIGRvbWFpbiBzZXBhcmF0aW9uIGZvcg0KQUVTIGJ5IHNldHRpbmcgdGhl IGZpcnN0IGJpdCBvZiB0aGUgbGFzdCBieXRlIHRvIDEvMCwgYW5kIGluIHBhcnRpY3VsYXINCnRo YXQgc2VlbWVkIGEgYml0IHdhc3RlZnVsIHNpbmNlIGl0IGlzIGV2YWx1YXRlZCBvbmx5IG9uY2Ug d2l0aCB0aGUgYml0DQpzZXQgdG8gMC4gV291bGRuJ3QgaXQgYmUgc2ltcGxlciAoYW5kIHBvc3Np Ymx5IGV2ZW4gd2l0aCBiZXR0ZXIgc2VjdXJpdHksDQpidXQgYXQgdGhlIGNvc3Qgb2YgbGltaXRp bmcgdGhlIGxlbmd0aCB0byAyXjMyIC0gMSBibG9ja3MpIHRvIG5vdCBmaWRkbGUNCndpdGggdGhl IGJpdHMgYnV0IGp1c3QgdXNlIHRoZSBmaXJzdCBjb3VudGVyLWJsb2NrIHRvIGNvbXB1dGUgdGhl IHRhZz8NCk5vdGUgdGhhdCB0aGlzIHdvdWxkIGNlcnRhaW5seSByZXF1aXJlIHJlLWRvaW5nIHNv bWUgcGFydCBvZiB0aGUgc2VjdXJpdHkNCmFuYWx5c2lzLCBhbmQgdGhlIGdhaW5zIHNlZW0gbW9k ZXJhdGUsIHNvIEnigJltIGZpbmUgd2l0aCB0aGlzIGNvbW1lbnQgYmVpbmcNCmRpc2NhcmRlZC4g KEp1c3Qgd2FudGVkIHRvIG1ha2Ugc3VyZSBpdCBpcyBkaXNjYXJkZWQgY29uc2Npb3VzbHkuKQ0K DQpBZnRlciBkaXNjdXNzaW9uIHdpdGggdGhlIG90aGVyIHJldmlld2VyczogVGhlIGRyYWZ0IGlz IGFtYmlndW91cyB3aXRoDQpyZXNwZWN0IHRvIGJ5dGUtc3RyaW5ncyB2cy4gYml0LXN0cmluZ3Mu IE15IGludGVycHJldGF0aW9uLCBzdGVtbWluZyBmcm9tDQp0aGUgYmVnaW5uaW5nIG9mIFNlY3Rp b24gNCBleHBsaWNpdGx5IG1lbnRpb25pbmcgYnl0ZS1zdHJpbmdzLCBpcyB0aGF0IGFsbA0Kc3Ry aW5ncyBtdXN0IGJlIHByb3Blcmx5IGJ5dGUtYWxpZ25lZC4gQnV0IGdpdmVuIHRoYXQsIHVzaW5n DQpieXRlbGVuKGFkZGl0aW9uYWxfbGVuZ3RoKSAqIDggYW5kIGJ5dGVsZW4ocGxhaW50ZXh0KSAq IDgsIGkuZS4NCmJpdC1sZW5ndGgsIGlzIGNvbmZ1c2luZy4gSWYgdGhlIGRyYWZ0IGlzIHN1cHBv c2VkIHRvIGRlYWwgd2l0aA0KYnl0ZS1hbGlnbmVkIHN0cmluZ3Mgb25seSAod2hpY2ggYXBwZWFy cyBwcmFjdGljYWxseSBzZW5zaWJsZSksIHRoZW4gdGhpcw0Kc2hvdWxkIGJlIG1hZGUgY2xlYXIg aW4gdGhlIGRvY3VtZW50LCBhbmQgYnl0ZS1sZW5ndGggc2hvdWxkIGJlIHVzZWQgaW4NCnRoZSBl bmNyeXB0aW9uLiBPdGhlcndpc2UsIHRoZSBhbGdvcml0aG1zIGhhdmUgdG8gYmUgc3BlY2lmaWVk IG1vcmUNCmNsZWFybHkgZm9yIHRoZSBjYXNlIG9mIGJpdC1zdHJpbmdzIHRoYXQgYXJlIG5vdCBi eXRlLWFsaWduZWQuIEluIGVpdGhlcg0KY2FzZSwgdGhlIGRyYWZ0IHNob3VsZCBiZSBjbGFyaWZp ZWQgaW4gdGhpcyByZXNwZWN0Lg0KDQoNCg0K From nobody Wed Jul 5 03:28:29 2017 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 81E431317AE for ; Wed, 5 Jul 2017 03:28:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 jzRTfyzmh47Y for ; Wed, 5 Jul 2017 03:28:26 -0700 (PDT) Received: from mail-wm0-x244.google.com (mail-wm0-x244.google.com [IPv6:2a00:1450:400c:c09::244]) (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 1CE81131BC1 for ; Wed, 5 Jul 2017 03:28:26 -0700 (PDT) Received: by mail-wm0-x244.google.com with SMTP id p204so31547430wmg.1 for ; Wed, 05 Jul 2017 03:28:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=+PyS+9lD7mtA3dW5wLXrtAWnfbx0vmPon7xe3v19PXY=; b=BRt/W1G5lwdTklTJZV9hrCnm9bakvedsJUp/Dme9mAMz3KxNiDGt2tk7CQosZwBW4q et03ODS+Kr6/QOCC+8m+J97xUuLbwetpNXR2QuPpk7HQpfaJmf76213/ZjagnK/0ROaM 6n+NgvEWPyeNUDq6YMK1UhnX7NYZ/rn9Xwkz9f3tnuV/U+RgKUWqhEcMKvb0Cm0XSslT 3lJkQdw9+wTi6V/KFyfXXm3AGiYQBuz/nFKekN3dwQQa2Rq9W0+K4Hnhr50aDf82ZWRK Qwj2fqe9oWLl73246ItSUDpnbwBO0JdsUvBW0punpGF1SQpHTk9Cohu8g9RYmPhSHCuf zC9Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=+PyS+9lD7mtA3dW5wLXrtAWnfbx0vmPon7xe3v19PXY=; b=DXIXAan12HSaFlfJAUtkiLbxzhHB1Y15mB82u0kPkzriHC1Vk97Lw1Z5G0hKQgbN12 7xPYPqnCyyQ86DF03wCiwAfEVrEKZ4MtaoHqQNlfuJHTs1lUwEVqIuQxxGBtjBarg2z8 m69PWvzkXXvQ0dNAmIP39oSUeBM6vrqPnYaqthezCRvfACnhSHXN3u8Ktlp7OjYNtI7x zQZ0uoBVkm3Zk+IyM+6ftA2nn9ZPNAFqqYemexQbP4veeqVrSusGkpz2qozT1iEF9wHX DZmtZ5RRIAVf9pPD47IMpCskrnOv7sPwMbg2U8/vr6r2XQD1hkuA4FM8D8AzYpGOiXcR 4tkg== X-Gm-Message-State: AKS2vOyS7Anu4VUu7Iz4wBpethTuKFMydBGQGi16coT3uVcZKWFaKPgG yuPar9sP15E8h9xFaHM= X-Received: by 10.80.183.4 with SMTP id g4mr22097916ede.138.1499250504336; Wed, 05 Jul 2017 03:28:24 -0700 (PDT) Received: from [172.20.10.3] (58.229.197.178.dynamic.wless.zhbmb00p-cgnat.res.cust.swisscom.ch. [178.197.229.58]) by smtp.gmail.com with ESMTPSA id b6sm7041155ede.23.2017.07.05.03.28.20 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 05 Jul 2017 03:28:20 -0700 (PDT) From: Bryan Ford Message-Id: <646B4D24-AA38-4AFD-93AB-733AAFA71BFC@gmail.com> Content-Type: multipart/signed; boundary="Apple-Mail=_6C0B81F4-96C2-4328-A3F1-B45103099FCF"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Wed, 5 Jul 2017 12:28:14 +0200 In-Reply-To: <8AE29DD0-26FE-4AB6-A4A9-2BB9169BAB13@jovanovic.io> Cc: Philipp Jovanovic , Linus Gasser , Nicolas Gailly To: cfrg@irtf.org References: <8AE29DD0-26FE-4AB6-A4A9-2BB9169BAB13@jovanovic.io> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Cfrg] Internet-Draft: Collective Edwards-Curve Digital Signature Algorithm X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jul 2017 10:28:28 -0000 --Apple-Mail=_6C0B81F4-96C2-4328-A3F1-B45103099FCF Content-Type: multipart/alternative; boundary="Apple-Mail=_909F2D55-4C58-4BA0-8585-26BB59470AE7" --Apple-Mail=_909F2D55-4C58-4BA0-8585-26BB59470AE7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Thanks everyone for your great comments so far on our collective signing = draft. More detailed responses to follow soon. In the meantime, I just wanted to announce that we=E2=80=99ve moved the = =E2=80=9Csource=E2=80=9D for this Internet-Draft to this public GitHub = repo: https://github.com/dedis/doc/tree/master/cosi = =E2=80=A6and we=E2=80=99re happy to take patch requests there for = concrete textual fixes or suggestions anyone might like to propose. = However, let=E2=80=99s keep the main discussion here on the CFRG list. Thanks Bryan > On Jul 1, 2017, at 11:58 PM, Philipp Jovanovic = wrote: >=20 > Hi CFRG, >=20 > Here=E2=80=99s a first version of an Internet-Draft on =E2=80=9CCollecti= ve Edwards-Curve Digital Signature Algorithms=E2=80=9D based on Ed25519 = and Ed448: https://datatracker.ietf.org/doc/draft-ford-cfrg-cosi/ >=20 > We plan to give a short presentation on that topic at the next CFRG = meeting in Prague. >=20 > Any feedback is more than welcome. Thanks! >=20 > All the best, > Philipp --Apple-Mail=_909F2D55-4C58-4BA0-8585-26BB59470AE7 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Thanks everyone for your great comments so = far on our collective signing draft.  More detailed responses to = follow soon.

In = the meantime, I just wanted to announce that we=E2=80=99ve moved the = =E2=80=9Csource=E2=80=9D for this Internet-Draft to this public GitHub = repo:

https://github.com/dedis/doc/tree/master/cosi

=E2=80=A6and we=E2=80=99re= happy to take patch requests there for concrete textual fixes or = suggestions anyone might like to propose.  However, let=E2=80=99s = keep the main discussion here on the CFRG list.

Thanks
Bryan

On Jul 1, 2017, at 11:58 PM, Philipp = Jovanovic <philipp@jovanovic.io> wrote:

Hi = CFRG,

Here=E2=80=99s a first version of an = Internet-Draft on =E2=80=9CCollective Edwards-Curve Digital Signature = Algorithms=E2=80=9D based on Ed25519 and Ed448: https://datatracker.ietf.org/doc/draft-ford-cfrg-cosi/

We plan to give a short presentation on that = topic at the next CFRG meeting in Prague.

Any= feedback is more than welcome. Thanks!

All = the best,
Philipp

= --Apple-Mail=_909F2D55-4C58-4BA0-8585-26BB59470AE7-- --Apple-Mail=_6C0B81F4-96C2-4328-A3F1-B45103099FCF Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIcBAEBCAAGBQJZXL8/AAoJEGt1rlrP7+d//hoP/1Ml4Mfss7U1hmhPTsdpM1Z0 0q98pSyPwqDvm2GsMa/dR+oXjsO0GkY0RCmgZNH37cnurF3xKct+e0UwbKKxfs+d l2fc3zT5w+NfysZV6IzsW+Inr0Vg5jtHOg6w207POcgAwbb+O9MxWcP4vsvmF1Zv THcdIB/axHt4/VkNc27+LH6IIj94WRtfu3CNRlC8tE25UVkwHLD961FeXtvM3wuE +auD/UOkhS7dmZliH+oYuSFFbkl/GAP2A/FoS7iSTmyjDWSgAglxu57CmXobUtWd +WP9NiIQ0Ustl9fIyKQjbf74UANoqZsPOpkNDq1hNY9Nz4X9nd6sgPm4TtFtPsB+ hAYMZdm69YTrIVSjYkidTEb5wx+Fx4mcY6uKvqjaDXli4pURk4Z0UV8Np7bIwHft j6ThFncG5XflwzY8vd5e5KVmggdouVK42ATy82V1QFkGsjTOP9mqBqzAJ4fz89WR W5kDagp8kPS+JJEOVBgGIxLsEyNq5KCeQ0qBeumiBPUMKyJOBfrA+uJzzoFCmQk/ rlG9r6HYYCxwAulTQAirT+rI6d6kolxRhgFsGCydaWYG91/2nNeIgzJX7NY9pQHD nA9kZm7pZ591mO5AqFipTd4zuzvtoJngIHVGN9RFngYQblspucpnd2TaoJB1Zf/v Z/mOEdnRi3nBJYi5JZre =FFhx -----END PGP SIGNATURE----- --Apple-Mail=_6C0B81F4-96C2-4328-A3F1-B45103099FCF-- From nobody Wed Jul 5 05:26:25 2017 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 C450113173E for ; Wed, 5 Jul 2017 05:26:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 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_BLOCKED=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 LBD0OJ5384x0 for ; Wed, 5 Jul 2017 05:26:18 -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 60C34131CC6 for ; Wed, 5 Jul 2017 05:26:17 -0700 (PDT) Received: by mail-wm0-x236.google.com with SMTP id w126so220483112wme.0 for ; Wed, 05 Jul 2017 05:26:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=mwnvGsPBHKiwxHkqQU9vnOJU6rT1ABBo4eRs3iflN4Y=; b=FezNIpgSwHO8zVIWCVZBEQSD639KOc1Vwv6VxUDFgqOgfMn5enTnbO64IrDoydOnRf LUAm5NxS6mYvbNCJxVtwGjQypZwEvWMJORs84yULhXK4tDkBoF+TH8rRj7fvz+2nvWmr Pzqm4P1PX0zodLxBXM1Wwx5NN4teZ6I9mheqK5IWNI8WNTwDDC9pMSbfU+NM1ZQzFmzw /vnUEWoWgZ6zrdr7t0OeJBYfZvkovaY6hcF2aD3EqkKJ2b2qK1fdNgs3KzLvAoqs/Ms2 r+Mt9gaJA10aQ7wt9ViVcKndxjtV2ZiSGQPuFGsdaUQhk3NVHvikEsn6QG5p8uxSBxUK 9olg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=mwnvGsPBHKiwxHkqQU9vnOJU6rT1ABBo4eRs3iflN4Y=; b=qNdc/ccIyfRKSP2/nDzln53bMM1b4Vl9zHluiwo0/roli65yayPQmlSyIp8ya5ezkp LJBrSVm91Fvrd5aBYPqGJ3DYOcNKPi81Xqq4C3bX39f274SUtvxVnEe0i5cn6Ep84o+d Efnpp3jH/ilRVjUWOozdf3iDKCCE9gAX6aWOIvwxGtl7tTxZsIvQGSZB1L+yThBY6bcx yF8FtEUIe9tzyzoOXIYtHle8vD3t8BMNIOUuM+2hevR5rdMdcJaUlwjKc1SR8V3W9KdR n4KwhG/aO7Pc1V2+o+xiguT/ISXpOManfrGFyklCSwqfGUDY9Juu+GHv7oVDtXTZURhb 3iBQ== X-Gm-Message-State: AKS2vOyE7RLp7satfnSvJ1Fp8y3vDOSrpnb1T5JSOKMYPHY9RCPb/JK2 HqLL3pUGw8o9uvzYXRI= X-Received: by 10.80.182.90 with SMTP id c26mr18012347ede.55.1499257575765; Wed, 05 Jul 2017 05:26:15 -0700 (PDT) Received: from [172.20.10.3] (81.227.197.178.dynamic.wless.zhbmb00p-cgnat.res.cust.swisscom.ch. [178.197.227.81]) by smtp.gmail.com with ESMTPSA id r37sm5639975edd.19.2017.07.05.05.26.13 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 05 Jul 2017 05:26:14 -0700 (PDT) From: Bryan Ford Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_9B18970A-44D2-4314-BBB3-E8F2C5E69443"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Wed, 5 Jul 2017 14:26:11 +0200 In-Reply-To: <5E91769F-B102-4A49-9ED5-B789D4FED598@gmail.com> Cc: Philipp Jovanovic , cfrg@irtf.org To: Oleg Andreev References: <8AE29DD0-26FE-4AB6-A4A9-2BB9169BAB13@jovanovic.io> <5E91769F-B102-4A49-9ED5-B789D4FED598@gmail.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Cfrg] Internet-Draft: Collective Edwards-Curve Digital Signature Algorithm X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jul 2017 12:26:21 -0000 --Apple-Mail=_9B18970A-44D2-4314-BBB3-E8F2C5E69443 Content-Type: multipart/alternative; boundary="Apple-Mail=_18FCA772-5B90-4BA4-B589-9B20D2AD1544" --Apple-Mail=_18FCA772-5B90-4BA4-B589-9B20D2AD1544 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Oleg, Thanks so much for your extremely constructive feedback. Responding to = your points inline... > On Jul 2, 2017, at 10:47 PM, Oleg Andreev wrote: >=20 > First of all: nice to see a simpler approach than a full SSSS-based = threshold signing scheme! >=20 > After a quick glance at the spec, I have two security concerns: >=20 > 1. It seems unsafe to add public keys directly (A =3D Sum[A_i]) = without multiplying them by their hashes (A =3D Sum[Hash(A_i)*A_i]). = Without that measure, it is possible to have A_j as a linear combination = of other public keys. See this discussion for details: = https://bitcointalk.org/index.php?topic=3D1377298.0 Definitely, we=E2=80=99d like to consider incorporating delinearization = schemes like this if/when the WG adopts collective signing in some form = as a working group item. We=E2=80=99ve added an Issue on the GitHub = repo holding the internet-draft specifically for this = (https://github.com/dedis/doc/issues/1 = ). I seem to remember that this topic was already brought up on this list = months (years?) ago in the Ed25519/Ed448 discussion leading up to RFC = 8032, but delinearization mechanisms weren=E2=80=99t adopted at that = point - perhaps in part simply because collective/aggregate signing = wasn=E2=80=99t the focus of that work item. I don=E2=80=99t remember = all the details though - if anyone else has a clearer memory of exactly = when that discussion occurred and can find pointers to the relevant = parts of the CFRG mailing list archive, that would be great. > 2. The signature does not commit to membership bitmask Z. Maybe it = could be argued that signature is not malleable (especially with an = improvement mentioned above), but to stay on safe side I think = committing to the exact set of signers is a good idea. Indeed, we=E2=80=99ve considered this question, and included it as a = specific =E2=80=9Cpoint for discussion=E2=80=9D in section 9.2 of our = initial Internet-Draft. We also added an Issue to the draft=E2=80=99s = GitHub repo to expand this list of discussion points and move it to an = earlier, more prominent location in the draft (see = https://github.com/dedis/doc/issues/2 = ). The clear potential benefit of including the bitmask in the hash is to = strengthen the non-malleability of the collective signature. Suppose, = for example, I=E2=80=99m a member of a collective signing group and = participated in creating a particular collective signature S, for which = my bit in the bit mask is 1. With the current (simple) formulation, I = could take this signature S, and remove my =E2=80=9Cshare" of it (which = I can do because I know both my private key and my share of the private = Schnorr commit) to produce a new =E2=80=9Creduced=E2=80=9D signature = S=E2=80=99 without my share and with my bit in the bit mask set to 0. = The resulting modified signature S=E2=80=99 will be equally valid, just = with one fewer cosigners represented (i.e., me). =46rom one perspective, this =E2=80=9Cattack=E2=80=9D arguably = shouldn=E2=80=99t be a problem in most cases because the new signature = still correctly attests that all the (remaining) signers indeed signed = the message, and if I try to disclaim ever having signed it at all, = anyone who knows the original full signature S can just exhibit that as = proof. Any signature almost by definition can=E2=80=99t be taken as a = claim that someone else *didn=E2=80=99t* sign a message - because they = could have signed the same message in a completely separate, unrelated = signing process. Both the original signature S and the reduced = signature S=E2=80=99 will need to be checked by any verifier against = some policy anyway (e.g., a t-of-n threshold or a more complex policy), = so my reduction S=E2=80=99 will at best make it less likely to satisfy = whatever verification policy might be applied to it. Nevertheless, there have certainly been instances in which unexpected or = poorly-understood signature malleability properties have created = security problems in practical systems using malleable signing schemes, = so from a purist perspective of =E2=80=9Cany malleability is probably = bad and should be eliminated=E2=80=9D, it might be best to have the hash = cover the bit mask purely out of an abundance of caution. However, there=E2=80=99s another potential practical cost to enforcing = this non-malleability: I believe it conflicts with any provisions we = might want to make collective signing protocols =E2=80=9Crestart-proof=E2=80= =9D and prevent DoS attacks. This is another issue to be discussed - = for details see https://github.com/dedis/doc/issues/2 = and section IV.D of our CoSi = paper (http://dedis.cs.yale.edu/dissent/papers/witness-abs). In brief, any Schnorr collective signing protocol fundamentally must = have two phases, =E2=80=9Ccommit/challenge=E2=80=9D and =E2=80=9Cresponse=E2= =80=9D. If the commits and challenge depend on the exact bit mask of = participating cosigners, then if any of those cosigners appeared to be = online during the commit phase but then go offline (perhaps maliciously, = deliberately at the =E2=80=9Cworst possible moment=E2=80=9D) between the = commit/challenge and response phases, then the only way for the protocol = to complete is to restart from scratch without the =E2=80=9Cfailed=E2=80=9D= cosigner. If there are F colluding malicious cosigners in the group, = then they can go offline one-by-one in this way, forcing up to F = successive restarts, before the honest members of the cosigning group = can successfully create a valid collective signature. This is of course = a limited and potentially tolerable DoS attack, =E2=80=9Conly=E2=80=9D = O(N) in the group size, but still a consideration. We have considered collective signing protocol variations that would = eliminate this DoS vulnerability, by enabling the leader to continue the = collective-signing process without restarting, even if only a subset of = the cosigners present in the commit phase remain participants in the = response phase. Again, see section IV.D of our CoSi paper for details = (http://dedis.cs.yale.edu/dissent/papers/witness-abs). Of course such = provisions add complexity to the protocol, and we=E2=80=99re not at all = certain whether they=E2=80=99re worth the trouble, or if it=E2=80=99s = better just to require restarts and tolerate the (limited) DoS = vulnerability that restarting on cosigner failure creates. So this is = one of the particular =E2=80=9Cbalance=E2=80=9D issues I=E2=80=99d like = to see discussed further in this group. > Additionally, I'd suggest an improvement to the API. Since the scheme = is not a SSSS scheme, verifier needs to reconstruct the exact key from = the individual keys (4.3.5 Signature Verification). Current spec states = that verifier should know the set of these member-keys upfront. It could = be more practical to provide them as a part of the signature and commit = into the aggregate public key, so the setup process looks as simple as = non-aggregate one, or one using SSSS: just sharing a single aggregate = public key. >=20 > This is how it could be done: >=20 > 1. Organize all member keys in a merkle tree and compute it's root = hash `h`. > 2. Compute intermediate aggregate key as `A =3D Sum[Hash(A_i)*A_i]`. > 3. Compute aggregate public key with commitment to the merkle tree: `P = =3D Hash(A || h)*A`. > 4. Signature will include: > 1) necessary member keys according to bitmask Z. > 2) merkle proof (necessary intermediate hashes needed to = reconstruct the root hash). > 3) intermediate key A. > 5. Verifier would reconstruct root hash h', compute `Hash(h' || A)*A` = and verify it matches the P. Then it will reconstruct actual = verification key `A' =3D A-T` and proceed with Schnorr protocol. >=20 > The member keys part of the signature could be optional, so the keys = could be cached in case many signature from the same key are = continuously verified. Yes, I think something along these lines is a good alternative to = consider - in fact we suggested more-or-less exactly this approach in = Section IV.B of our CoSi paper = (http://dedis.cs.yale.edu/dissent/papers/witness-abs). The upside of this variation is that verifiers need to know only the = hash of the root of the Merkle =E2=80=9Ckey tree=E2=80=9D in order to = verify collective signatures. The downsides are (a) more complex = signing and verification protocols needing Merkle trees and the like, = (b) collective signatures themselves are no longer constant-size for a = given cosigning group size, and (c) collective signatures may have much = larger worst-case size due to the need to include one or more Merkle = proofs for missing or present public keys - up to N/2 Merkle proofs in = the worst case. Again, these are important tradeoffs to be discussed. Backing up for the moment, I think our first step is to establish = whether there=E2=80=99s a critical-mass of interest within CFRG to adopt = collective signing in some form as a working group item. We offer our = Internet-Draft as a starting point, but only a starting point, for such = an effort if approved, and are happy to evolve it as needed as WG = consensus hopefully emerges eventually around the above and other = important design issues and tradeoffs that will need to be discussed. = I=E2=80=99m already happy to see that there seems to be significant = interest, at least, based on the responses so far. Thanks Bryan >=20 > Cheers, > Oleg. >=20 >> On 2 Jul 2017, at 00:58, Philipp Jovanovic = wrote: >>=20 >> Hi CFRG, >>=20 >> Here=E2=80=99s a first version of an Internet-Draft on =E2=80=9CCollect= ive Edwards-Curve Digital Signature Algorithms=E2=80=9D based on Ed25519 = and Ed448: https://datatracker.ietf.org/doc/draft-ford-cfrg-cosi/ >>=20 >> We plan to give a short presentation on that topic at the next CFRG = meeting in Prague. >>=20 >> Any feedback is more than welcome. Thanks! >>=20 >> All the best, >> Philipp >> _______________________________________________ >> Cfrg mailing list >> Cfrg@irtf.org >> https://www.irtf.org/mailman/listinfo/cfrg >=20 > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > https://www.irtf.org/mailman/listinfo/cfrg --Apple-Mail=_18FCA772-5B90-4BA4-B589-9B20D2AD1544 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi Oleg, 

Thanks so much for your extremely constructive feedback. =  Responding to your points inline...

On Jul 2, 2017, at 10:47 PM, Oleg Andreev = <oleganza@gmail.com> wrote:

First of all: nice to see a simpler approach = than a full SSSS-based threshold signing scheme!

After a quick glance at the spec, I have two security = concerns:

1. It seems unsafe to add public = keys directly (A =3D Sum[A_i]) without multiplying them by their hashes = (A =3D Sum[Hash(A_i)*A_i]). Without that measure, it is possible to have = A_j as a linear combination of other public keys. See this discussion = for details: https://bitcointalk.org/index.php?topic=3D1377298.0

Definitely, we=E2=80=99d like to consider = incorporating delinearization schemes like this if/when the WG adopts = collective signing in some form as a working group item.  We=E2=80=99= ve added an Issue on the GitHub repo holding the internet-draft = specifically for this (https://github.com/dedis/doc/issues/1).

I seem to remember that this topic was already = brought up on this list months (years?) ago in the Ed25519/Ed448 = discussion leading up to RFC 8032, but delinearization mechanisms = weren=E2=80=99t adopted at that point - perhaps in part simply because = collective/aggregate signing wasn=E2=80=99t the focus of that work item. =  I don=E2=80=99t remember all the details though - if anyone else = has a clearer memory of exactly when that discussion occurred and can = find pointers to the relevant parts of the CFRG mailing list archive, = that would be great.

2. The signature does not = commit to membership bitmask Z. Maybe it could be argued that signature = is not malleable (especially with an improvement mentioned above), but = to stay on safe side I think committing to the exact set of signers is a = good idea.

Indeed, we=E2=80=99ve considered this question, = and included it as a specific =E2=80=9Cpoint for discussion=E2=80=9D in = section 9.2 of our initial Internet-Draft.  We also added an Issue = to the draft=E2=80=99s GitHub repo to expand this list of discussion = points and move it to an earlier, more prominent location in the draft = (see https://github.com/dedis/doc/issues/2).

The clear potential benefit of including the = bitmask in the hash is to strengthen the non-malleability of the = collective signature.  Suppose, for example, I=E2=80=99m a member = of a collective signing group and participated in creating a particular = collective signature S, for which my bit in the bit mask is 1. =  With the current (simple) formulation, I could take this signature = S, and remove my =E2=80=9Cshare" of it (which I can do because I know = both my private key and my share of the private Schnorr commit) to = produce a new =E2=80=9Creduced=E2=80=9D signature S=E2=80=99 without my = share and with my bit in the bit mask set to 0.  The resulting = modified signature S=E2=80=99 will be equally valid, just with one fewer = cosigners represented (i.e., me).

=46r= om one perspective, this =E2=80=9Cattack=E2=80=9D arguably shouldn=E2=80=99= t be a problem in most cases because the new signature still correctly = attests that all the (remaining) signers indeed signed the message, and = if I try to disclaim ever having signed it at all, anyone who knows the = original full signature S can just exhibit that as proof.  Any = signature almost by definition can=E2=80=99t be taken as a claim that = someone else *didn=E2=80=99t* sign a message - because they could have = signed the same message in a completely separate, unrelated signing = process.  Both the original signature S and the reduced signature = S=E2=80=99 will need to be checked by any verifier against some policy = anyway (e.g., a t-of-n threshold or a more complex policy), so my = reduction S=E2=80=99 will at best make it less likely to satisfy = whatever verification policy might be applied to it.

Nevertheless, there have certainly been instances = in which unexpected or poorly-understood signature malleability = properties have created security problems in practical systems using = malleable signing schemes, so from a purist perspective of =E2=80=9Cany = malleability is probably bad and should be eliminated=E2=80=9D, it might = be best to have the hash cover the bit mask purely out of an abundance = of caution.

However, there=E2=80=99s = another potential practical cost to enforcing this non-malleability: I = believe it conflicts with any provisions we might want to make = collective signing protocols =E2=80=9Crestart-proof=E2=80=9D and prevent = DoS attacks.  This is another issue to be discussed - for details = see https://github.com/dedis/doc/issues/2 and section = IV.D of our CoSi paper (http://dedis.cs.yale.edu/dissent/papers/witness-abs).
=

In brief, any Schnorr collective signing = protocol fundamentally must have two phases, =E2=80=9Ccommit/challenge=E2=80= =9D and =E2=80=9Cresponse=E2=80=9D.  If the commits and challenge = depend on the exact bit mask of participating cosigners, then if any of = those cosigners appeared to be online during the commit phase but then = go offline (perhaps maliciously, deliberately at the =E2=80=9Cworst = possible moment=E2=80=9D) between the commit/challenge and response = phases, then the only way for the protocol to complete is to restart = from scratch without the =E2=80=9Cfailed=E2=80=9D cosigner.  If = there are F colluding malicious cosigners in the group, then they can go = offline one-by-one in this way, forcing up to F successive restarts, = before the honest members of the cosigning group can successfully create = a valid collective signature. This is of course a limited and = potentially tolerable DoS attack, =E2=80=9Conly=E2=80=9D O(N) in the = group size, but still a consideration.

We have considered collective signing protocol = variations that would eliminate this DoS vulnerability, by enabling the = leader to continue the collective-signing process without restarting, = even if only a subset of the cosigners present in the commit phase = remain participants in the response phase.  Again, see section IV.D = of our CoSi paper for details (http://dedis.cs.yale.edu/dissent/papers/witness-abs). =  Of course such provisions add complexity to the protocol, and = we=E2=80=99re not at all certain whether they=E2=80=99re worth the = trouble, or if it=E2=80=99s better just to require restarts and tolerate = the (limited) DoS vulnerability that restarting on cosigner failure = creates.  So this is one of the particular =E2=80=9Cbalance=E2=80=9D = issues I=E2=80=99d like to see discussed further in this = group.

Additionally, I'd suggest an = improvement to the API. Since the scheme is not a SSSS scheme, verifier = needs to reconstruct the exact key from the individual keys (4.3.5 = Signature Verification). Current spec states that verifier should know = the set of these member-keys upfront. It could be more practical to = provide them as a part of the signature and commit into the aggregate = public key, so the setup process looks as simple as non-aggregate one, = or one using SSSS: just sharing a single aggregate public key.

This is how it could be done:

1. Organize all member keys in a merkle tree and compute it's = root hash `h`.
2. Compute intermediate aggregate key as `A = =3D Sum[Hash(A_i)*A_i]`.
3. Compute aggregate public key = with commitment to the merkle tree: `P =3D Hash(A || h)*A`.
4. Signature will include:
=    1) necessary member keys according to bitmask Z.
   2) merkle proof (necessary intermediate = hashes needed to reconstruct the root hash).
=    3) intermediate key A.
5. Verifier would = reconstruct root hash h', compute `Hash(h' || A)*A` and verify it = matches the P. Then it will reconstruct actual verification key `A' =3D = A-T` and proceed with Schnorr protocol.

The = member keys part of the signature could be optional, so the keys could = be cached in case many signature from the same key are continuously = verified.

Yes, I think something along these lines is a good = alternative to consider - in fact we suggested more-or-less exactly this = approach in Section IV.B of our CoSi paper (http://dedis.cs.yale.edu/dissent/papers/witness-abs). =  

The upside of this variation = is that verifiers need to know only the hash of the root of the Merkle = =E2=80=9Ckey tree=E2=80=9D in order to verify collective signatures. =  The downsides are (a) more complex signing and verification = protocols needing Merkle trees and the like, (b) collective signatures = themselves are no longer constant-size for a given cosigning group size, = and (c) collective signatures may have much larger worst-case size due = to the need to include one or more Merkle proofs for missing or present = public keys - up to N/2 Merkle proofs in the worst case.  Again, = these are important tradeoffs to be discussed.

Backing up for the moment, I think our first step = is to establish whether there=E2=80=99s a critical-mass of interest = within CFRG to adopt collective signing in some form as a working group = item.  We offer our Internet-Draft as a starting point, but only a = starting point, for such an effort if approved, and are happy to evolve = it as needed as WG consensus hopefully emerges eventually around the = above and other important design issues and tradeoffs that will need to = be discussed.  I=E2=80=99m already happy to see that there seems to = be significant interest, at least, based on the responses so = far.

Thanks
Bryan


Cheers,
Oleg.

On 2 Jul 2017, at 00:58, = Philipp Jovanovic <philipp@jovanovic.io> wrote:

Hi CFRG,

Here=E2=80=99s a first = version of an Internet-Draft on =E2=80=9CCollective Edwards-Curve = Digital Signature Algorithms=E2=80=9D based on Ed25519 and Ed448: https://datatracker.ietf.org/doc/draft-ford-cfrg-cosi/

We plan to give a short presentation on that = topic at the next CFRG meeting in Prague.

Any= feedback is more than welcome. Thanks!

All = the best,
Philipp
_______________________________________________
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

= --Apple-Mail=_18FCA772-5B90-4BA4-B589-9B20D2AD1544-- --Apple-Mail=_9B18970A-44D2-4314-BBB3-E8F2C5E69443 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIcBAEBCAAGBQJZXNrkAAoJEGt1rlrP7+d/4fQP/0qS8EJ76R25UTZIx09v1ds7 +s2Z81H+pHIHEKxSWaAuIZ/KUAL7cRcp11ek08A+CEWeinwkCxlA5f4Xk3SJjJpp 361TIKjBPblSMAvOD9DOSDDRSszGgUIBqJJriUaeRrf0VETHZG3UD47QHRHAcwuy aU0lJEZKXCihuubBOCUK14Y2Es9cO9tf3biYVwCZ1C2hR7yheu4roHxBU06a+E8o VL644z/N0M69gl5IQs02PBF4i6mldKLnkmJxscbFCmvSat5pg7c+jDRrAnRPmL30 BU7ar2LBpOQJ4y1rfZ8Cff0fNOBjDjFfOLXGTLabvI5/h/oMeWgKATZjNBCGXY4z NNpmxasyxQr6PmKrTQZKKHxGuVFTFka26jupFhIhqulrWLD3R+elxoEvVkxrk+4W MYGmZeG1GihoLDcN/SKgJenem+qKBqjiOkLmZWrlcpCSOxNZuv13t4gZZ4Ynlm4d iUBROlX5w6KNs3VToWkDZyEWMPVb8a7soQB5LlrRa6Aovk81d0mzwI4GT9wVINUI L/ggKu0LIzstUhwHVn4+08mlUQ7GHGFO8NTPeDTUSMHxGWNA7uMgU0OO/pC/rRea BMenZr3a/glL9lJTjGt6QjK3u95rNYaiU4+5gn/SSVV2BZJP+tZOeKyco/BSTq22 NWJfr2BJi1xmvLbOJ4/k =lFNj -----END PGP SIGNATURE----- --Apple-Mail=_9B18970A-44D2-4314-BBB3-E8F2C5E69443-- From nobody Wed Jul 5 06:11:54 2017 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 BBB45131CF4 for ; Wed, 5 Jul 2017 06:11:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 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_BLOCKED=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 8RKBwTBpRecD for ; Wed, 5 Jul 2017 06:11:50 -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 74CDE131CB0 for ; Wed, 5 Jul 2017 06:11:49 -0700 (PDT) Received: by mail-wm0-x22e.google.com with SMTP id 62so222356035wmw.1 for ; Wed, 05 Jul 2017 06:11:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=GHNZ95akZo7drPIYCl5zaY+mVkexX42Xl8N+xGmLNQA=; b=X2rCZjOXqc3Jwi0eUpMwngbNYDy6t+uNf0FWCDcXaAQSBlk87i1tWO6lvf5eKpiMnJ A2ZAlrZCh0oVvKN7HRYn5xXpN/FmxTxFnM+rb/NpXx4TwNA9i2c2B0HpPEbIO0oNzZVJ ZXjggHnWOGeMOPjoqgLrnJq4TxVh1siGItY8KnhFPobznOFqUWNYViCsyw/D4Hf5F0PK vF7EeFwy58znSG1W5au3qUpDnfqqEBsgCtnVKIUOQ6Ar4AXBYBkMgBZJpsIHwdf1zrzV wfVsj8NcF/52DK9QPbRWE3k5fxxCo6KuwNGs/s64xjXSDxuTqL2/1GPd3bFa7biTAKlc OZgw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=GHNZ95akZo7drPIYCl5zaY+mVkexX42Xl8N+xGmLNQA=; b=s0ZYyVaMGUwv+MMb0n9rGt/HuNcTyUjIFpPyufc4k++kiw1+FN7ejm9usDuPTcp+yU BZjHXHI6uEa4aMVCDRIQ1bwbaxfr9WwMa/Bmv/drR5tpD4qb7wv2tRVoXMbkidw2zbi1 iKHF8S3GWyMxNWYIw5WKhwz50GyWMmlMTq+WT8zGPG2nlKL8uDkgSSr8RrDrgsoDaxe6 nBL0uEXa+OXCMunIuhfiBErCFwO5vflNwoKMNxD2EQvdyZjfD+Rap/jz3jJEL4QhsOcx 5Dw6b50Q2kYzP0ctXF/WX7Bm7xTQLZClZJZl89h5CVNt2Pkfp/JxemcGi53tz1H/FBZc uGOA== X-Gm-Message-State: AKS2vOykEIWrX9hQ0J6/cEXPoB9P7K9tcu/AWmm1sapp21kxiooSjeQm 7YugUTqsDbzHaI9eJIw= X-Received: by 10.28.238.219 with SMTP id j88mr19891818wmi.33.1499260307905; Wed, 05 Jul 2017 06:11:47 -0700 (PDT) Received: from [192.168.1.28] (83-103-13-156.ip.fastwebnet.it. [83.103.13.156]) by smtp.gmail.com with ESMTPSA id h10sm11431707wme.30.2017.07.05.06.11.41 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 05 Jul 2017 06:11:46 -0700 (PDT) From: Bryan Ford Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_C4E4CACE-761E-4B3F-B41D-B27E8D7044A1"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Wed, 5 Jul 2017 15:11:36 +0200 In-Reply-To: <11cc5d3f-ecf9-2fd0-825c-c8b441bd2813@tugraz.at> Cc: Philipp Jovanovic , cfrg@irtf.org To: Daniel Slamanig References: <8AE29DD0-26FE-4AB6-A4A9-2BB9169BAB13@jovanovic.io> <11cc5d3f-ecf9-2fd0-825c-c8b441bd2813@tugraz.at> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Cfrg] Internet-Draft: Collective Edwards-Curve Digital Signature Algorithm X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jul 2017 13:11:53 -0000 --Apple-Mail=_C4E4CACE-761E-4B3F-B41D-B27E8D7044A1 Content-Type: multipart/alternative; boundary="Apple-Mail=_B5FF9FDC-9ED8-4DFA-971D-BAEB3D9B51E0" --Apple-Mail=_B5FF9FDC-9ED8-4DFA-971D-BAEB3D9B51E0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Daniel, thanks for your thoughts on the commitment-to-the-bitmask = issue. Your proposal of using a chameleon hash, to allow the leader to = =E2=80=9Cadjust=E2=80=9D the bit mask after the commit c has been = established, is an interesting idea. However, if I understand it = correctly, if the leader holds the trapdoor key for the chameleon hash, = wouldn=E2=80=99t that still make the final collective signature = malleable for the leader (or for anyone the leader=E2=80=99s trapdoor = key might leak to)? The CoSi protocol as currently defined is intended = to ensure that the leader has no special privilege or trust with respect = to other cosigners: i.e., the leader is merely an ordinary participant, = but is simply the one who for whatever reason decides to initiate the = cosigning operation. Giving the leader special powers - e.g., making = the signature malleable to the leader but not to others - would break = this principle and need to be extremely carefully considered I think. To follow up on my last message to Oleg, again I suggest reading section = IV of our CoSi paper from IEEE S&P last year = (http://dedis.cs.yale.edu/dissent/papers/witness-abs = ), as it discusses = several related issues, especially the potential desire to allow the = leader to complete a collective signing procedure even with only a = subset of =E2=80=9Ccommitted=E2=80=9D participants remaining present in = the =E2=80=9Cresponse=E2=80=9D phase. In particular, the leader can = form all the individual Schnorr commits into a Merkle tree, and make the = real commit c be the root of that Merkle tree. In this way, the leader = is committing not so much to a particular collective Schnorr commit but = rather to *all possible* Schnorr commits that can be composed from any = subset of the individual Schnorr commits within that Merkle tree. This = way, if some of the participants whose commits are present in that = Merkle tree remain available during the response phase but others drop = out, the leader can still use the commit c and form a correct and = verifiable collective signature against the particular subset of Schnorr = commits from nodes that remained available throughout the process, = without restarting. I guess this approach does, in a slightly different way, make the = resulting collective signatures slightly malleable to the leader: from a = given set of commit-time and response-time information, the leader could = put together distinct collective signatures representing different = subsets of response-time participants. Some form of = =E2=80=9Cleader-malleability=E2=80=9D of this kind seems unavoidably = essential to enabling the leader to complete a collective signing round = in the presence of partial failures without restarting. Perhaps the = same limited leader-malleability is more-or-less the same property your = suggestion of using chameleon hashes has, although I haven=E2=80=99t had = a chance to compare them deeply yet. But at any rate, the higher-level tradeoff here to consider is whether = it=E2=80=99s better to (a) enforce strict non-malleability of collective = signatures (by anyone, leader included), at the cost of O(N)-round DoS = attack vulnerability during signing due to the need to restart partially = failed rounds, or (b) provide some limited form of limited = leader-malleability in order to support restart-free operation and avoid = DoS attacks during signing, at the cost of a more complex protocol (and = perhaps slightly more =E2=80=9Cspecial=E2=80=9D trust in the leader than = we might like). Again, further thoughts on this and other topics are most welcome. Thanks Bryan > On Jul 3, 2017, at 7:34 PM, Daniel Slamanig = wrote: >=20 > Hi Philipp, >=20 > looks interesting! >=20 > After looking at the protocol I also have some security concerns = (related to what has been raised by Oleg in a previous mail). >=20 > Not committing to Z as well as the actual sum of signers public keys = A' in the computation of the hash c for the signature seems to be = problematic. >=20 > It seems to me that committing Z in the signature in plain as well as = A' does not work given the later application of the signing procedure = (where till the end of the protocol it is not clear who actually = participates in the signing but c must be known at the beginning). >=20 > Committing to neither of both however seems problematic as it does not = fix the set of actual signers. >=20 > This could be circumvented by allowing an honest leader to adapt the = commitment to the final Z (and A') after it knows the signers without = modifying the initially computed c using a chameleon hash (trapdoor = commitment). I use P as a generator below, omit the brackets [a]P = notation for scalar multiplication and write it from the perspective of = the leader, i.e., the signer that initiates the protocol. >=20 > The leader could choose chameleon hash parameters sk_ch=3Dy for random = y and pk_ch=3D(P,Y=3DyP) and add pk_ch and chameleon hash = CH(Z'):=3Dh(Z')P+u'Y for randomly chosen u' to the computation of c, = i.e., set c=3DH(R||A||pk_ch||CH(Z')||S), where h() is a collision = resistant hash function (this is just the standard way of constructing a = chameleon hash from DL for arbitrary message spaces as propsed in [1]). = If Z' is not yet known one simply sets Z' to some fixed string at the = beginning, e.g., Z':=3D0. At the end of the protocol, when the leader = knows the exact signers, it can update Z' to the final value Z and use = sk_ch to compute a collision in the chameleon hash, i.e., such that = CH(Z)=3DCH(Z') by solving h(Z')+u'y =3D h(Z)+uy for u. He then adds u = and Z as well as pk_ch to the signature, i.e., sets it as = (R,s,u,Z,pk_ch) and discards sk_ch and u'. If Z is known beforehand, one = simply computes the chameleon hash once and does not need to compute a = collision. Clearly, the use of a chameleon hash allows to simply adapt = to the actual set of signers representing Z without modifying c (with = the knowledge of sk_ch - but it does not work without the knowledge of = sk_ch). This would resolve the issue with the unknown Z at the time of = signing. >=20 > Also, A is committed in the signature, but not the concrete A'=3D\sum = A_i of keys used for computing the signature (I guess also due to the = reason that one does not know the correct set of signers when computing = the hash c). That can be problematic in a rogue key scenario in the = current protocol, i.e., when not all signers need to prove knowledge of = the secret key when they register their public keys but their public = keys could be functions of other public keys (guess this could be a = problem here). For instance, a malicious A^* could just take some key = from A, say A_j, and compute and publish A^*=3Da^*A_j. And then given a = collective signature (R,s,Z) where A_j participated, the signer can = update s to s^* =3D s+a^*c as well as Z^* to exclude A_j and include A^* = (as Z is not committed in the signature generation) and the signature = (R,s^*,Z^*) will be a valid signature that certifies that A^* = participated in signing - although he didn't. >=20 > If Z is committed as proposed above and it is checked during the = verification, then this should no longer work. One could also adapt the = hash c=3DH(R||pk_ch||CH(Z'||A)||S) to include a chameleon hash to = CH(Z||A'), where A' is the real set of signers that participated in the = signature generation and is adapted before finalizing the signature when = known as above. >=20 > I hope that what I proposed is not just complete nonsense :) Also it = produces quite a bit of an overhead. There may also be easier ways to = avoid the issues. >=20 > Some editorial issues: the message to be signed is sometimes called a = satement S and later then message msg. S could be confusing as part of = the signature is s and your semantic is that scalars are lowercase and = points are uppercase. Also in 4.2 "Signature Generation" steps 2 and 3 = are confusing as I guess that in the protocol all the signer compute = their own [r_i]B values and R=3D\sum R_i instead of R=3D[r]B which would = mean that they would send their r_i's (hope they will not do so). >=20 > Also I find it somewhat confusing that the bitmask Z identifies the = non-signers with a bit set to 1. Why not identifying the signers with a = bit set to 1? >=20 > Cheers, > Daniel >=20 >=20 > [1] Hugo Krawczyk, Tal Rabin: Chameleon Signatures. NDSS 2000 >=20 > On 01.07.2017 23:58, Philipp Jovanovic wrote: >> Hi CFRG, >> Here=E2=80=99s a first version of an Internet-Draft on =E2=80=9CCollect= ive Edwards-Curve Digital Signature Algorithms=E2=80=9D based on Ed25519 = and Ed448: https://datatracker.ietf.org/doc/draft-ford-cfrg-cosi/ >> We plan to give a short presentation on that topic at the next CFRG = meeting in Prague. >> Any feedback is more than welcome. Thanks! >> All the best, >> Philipp >> _______________________________________________ >> Cfrg mailing list >> Cfrg@irtf.org >> https://www.irtf.org/mailman/listinfo/cfrg >=20 >=20 > -- > Dr. Daniel Slamanig > Institute for Applied Information Processing and Communications > Graz University of Technology > Inffeldgasse 16a, 8010 Graz, Austria. > Phone: +43 316 873 5509 > http://www.iaik.tugraz.at >=20 > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > https://www.irtf.org/mailman/listinfo/cfrg --Apple-Mail=_B5FF9FDC-9ED8-4DFA-971D-BAEB3D9B51E0 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi Daniel, thanks for your thoughts on the = commitment-to-the-bitmask issue.

Your proposal of using a chameleon hash, to allow the leader = to =E2=80=9Cadjust=E2=80=9D the bit mask after the commit c has been = established, is an interesting idea. However, if I understand it = correctly, if the leader holds the trapdoor key for the chameleon hash, = wouldn=E2=80=99t that still make the final collective signature = malleable for the leader (or for anyone the leader=E2=80=99s trapdoor = key might leak to)?  The CoSi protocol as currently defined is = intended to ensure that the leader has no special privilege or trust = with respect to other cosigners: i.e., the leader is merely an ordinary = participant, but is simply the one who for whatever reason decides to = initiate the cosigning operation.  Giving the leader special powers = - e.g., making the signature malleable to the leader but not to others - = would break this principle and need to be extremely carefully considered = I think.

To = follow up on my last message to Oleg, again I suggest reading section IV = of our CoSi paper from IEEE S&P last year (http://dedis.cs.yale.edu/dissent/papers/witness-abs), as = it discusses several related issues, especially the potential desire to = allow the leader to complete a collective signing procedure even with = only a subset of =E2=80=9Ccommitted=E2=80=9D participants remaining = present in the =E2=80=9Cresponse=E2=80=9D phase.  In particular, = the leader can form all the individual Schnorr commits into a Merkle = tree, and make the real commit c be the root of that Merkle tree. =  In this way, the leader is committing not so much to a particular = collective Schnorr commit but rather to *all possible* Schnorr commits = that can be composed from any subset of the individual Schnorr commits = within that Merkle tree.  This way, if some of the participants = whose commits are present in that Merkle tree remain available during = the response phase but others drop out, the leader can still use the = commit c and form a correct and verifiable collective signature against = the particular subset of Schnorr commits from nodes that remained = available throughout the process, without restarting.

I guess this approach = does, in a slightly different way, make the resulting collective = signatures slightly malleable to the leader: from a given set of = commit-time and response-time information, the leader could put together = distinct collective signatures representing different subsets of = response-time participants.  Some form of =E2=80=9Cleader-malleabilit= y=E2=80=9D of this kind seems unavoidably essential to enabling the = leader to complete a collective signing round in the presence of partial = failures without restarting.  Perhaps the same limited = leader-malleability is more-or-less the same property your suggestion of = using chameleon hashes has, although I haven=E2=80=99t had a chance to = compare them deeply yet.  

But at any rate, the higher-level = tradeoff here to consider is whether it=E2=80=99s better to (a) enforce = strict non-malleability of collective signatures (by anyone, leader = included), at the cost of O(N)-round DoS attack vulnerability during = signing due to the need to restart partially failed rounds, or (b) = provide some limited form of limited leader-malleability in order to = support restart-free operation and avoid DoS attacks during signing, at = the cost of a more complex protocol (and perhaps slightly more = =E2=80=9Cspecial=E2=80=9D trust in the leader than we might = like).

Again, = further thoughts on this and other topics are most welcome.

Thanks
Bryan

On Jul 3, 2017, at 7:34 PM, = Daniel Slamanig <daniel.slamanig@tugraz.at> wrote:

Hi = Philipp,

looks interesting!
After looking at the protocol I also have some security = concerns (related to what has been raised by Oleg in a previous = mail).

Not committing to Z as well as the = actual sum of signers public keys A' in the computation of the hash c = for the signature seems to be problematic.

It= seems to me that committing Z in the signature in plain as well as A' = does not work given the later application of the signing procedure = (where till the end of the protocol it is not clear who actually = participates in the signing but c must be known at the beginning).

Committing to neither of both however seems = problematic as it does not fix the set of actual signers.

This could be circumvented by allowing an = honest leader to adapt the commitment to the final Z (and A') after it = knows the signers without modifying the initially computed c using a = chameleon hash (trapdoor commitment). I use P as a generator below, omit = the brackets [a]P notation for scalar multiplication and write it from = the perspective of the leader, i.e., the signer that initiates the = protocol.

The leader could choose chameleon = hash parameters sk_ch=3Dy for random y and pk_ch=3D(P,Y=3DyP) and add = pk_ch and chameleon hash CH(Z'):=3Dh(Z')P+u'Y for randomly chosen u' to = the computation of c, i.e., set c=3DH(R||A||pk_ch||CH(Z')||S), where h() = is a collision resistant hash function (this is just the standard way of = constructing a chameleon hash from DL for arbitrary message spaces as = propsed in [1]). If Z' is not yet known one simply sets Z' to some fixed = string at the beginning, e.g., Z':=3D0. At the end of the protocol, when = the leader knows the exact signers, it can update Z' to the final value = Z and use sk_ch to compute a collision in the chameleon hash, i.e., such = that CH(Z)=3DCH(Z') by solving h(Z')+u'y =3D h(Z)+uy for u. He then adds = u and Z as well as pk_ch to the signature, i.e., sets it as = (R,s,u,Z,pk_ch) and discards sk_ch and u'. If Z is known beforehand, one = simply computes the chameleon hash once and does not need to compute a = collision. Clearly, the use of a chameleon hash allows to simply adapt = to the actual set of signers representing Z without modifying c (with = the knowledge of sk_ch - but it does not work without the knowledge of = sk_ch). This would resolve the issue with the unknown Z at the time of = signing.

Also, A is committed in the = signature, but not the concrete A'=3D\sum A_i of keys used for computing = the signature (I guess also due to the reason that one does not know the = correct set of signers when computing the hash c). That can be = problematic in a rogue key scenario in the current protocol, i.e., when = not all signers need to prove knowledge of the secret key when they = register their public keys but their public keys could be functions of = other public keys (guess this could be a problem here). For instance, a = malicious A^* could just take some key from A, say A_j, and compute and = publish A^*=3Da^*A_j. And then given a collective signature (R,s,Z) = where A_j participated, the signer can update s to s^* =3D s+a^*c as = well as Z^* to exclude A_j and include A^* (as Z is not committed in the = signature generation) and the signature (R,s^*,Z^*) will be a valid = signature that certifies that A^* participated in signing - although he = didn't.

If Z is committed as proposed above = and it is checked during the verification, then this should no longer = work. One could also adapt the hash c=3DH(R||pk_ch||CH(Z'||A)||S) to = include a chameleon hash to CH(Z||A'), where A' is the real set of = signers that participated in the signature generation and is adapted = before finalizing the signature when known as above.

I hope that what I proposed is not just complete nonsense :) = Also it produces quite a bit of an overhead. There may also be easier = ways to avoid the issues.

Some editorial = issues: the message to be signed is sometimes called a satement S and = later then message msg. S could be confusing as part of the signature is = s and your semantic is that scalars are lowercase and points are = uppercase. Also in 4.2 "Signature Generation" steps 2 and 3 are = confusing as I guess that in the protocol all the signer compute their = own [r_i]B values and R=3D\sum R_i instead of R=3D[r]B which would mean = that they would send their r_i's (hope they will not do so).

Also I find it somewhat confusing that the = bitmask Z identifies the non-signers with a bit set to 1. Why not = identifying the signers with a bit set to 1?

Cheers,
Daniel


[1] Hugo Krawczyk, Tal Rabin: Chameleon Signatures. NDSS = 2000

On 01.07.2017 23:58, Philipp Jovanovic = wrote:
Hi CFRG,
Here=E2=80=99s a first version of an Internet-Draft on = =E2=80=9CCollective Edwards-Curve Digital Signature Algorithms=E2=80=9D = based on Ed25519 and Ed448: https://datatracker.ietf.org/doc/draft-ford-cfrg-cosi/
We plan to give a short presentation on that topic at the = next CFRG meeting in Prague.
Any feedback is more than = welcome. Thanks!
All the best,
Philipp
_______________________________________________
Cfrg mailing list
Cfrg@irtf.org
https://www.irtf.org/mailman/listinfo/cfrg


--
Dr.= Daniel Slamanig
Institute for Applied Information = Processing and Communications
Graz University of = Technology
Inffeldgasse 16a, 8010 Graz, Austria.
Phone: +43 316 873 5509
http://www.iaik.tugraz.at

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

= --Apple-Mail=_B5FF9FDC-9ED8-4DFA-971D-BAEB3D9B51E0-- --Apple-Mail=_C4E4CACE-761E-4B3F-B41D-B27E8D7044A1 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIcBAEBCAAGBQJZXOWIAAoJEGt1rlrP7+d/CZQP/1ObPV46yKJ6OrKLQJDP4YSz 3OsqTbDO5CP9m2n1vfTaI4yAxex3+5pH2nnufKSqLDBge8QCHzpnRsFEe2tMxpeS A2EHAU7seJdd/5uVJJecEbMOhY6TpsQHj3bp6Y4ucmG0JPnjgYvmaqRb/jLRjnLT K9c02TiyT07lU532V8xgmGaJ17uHpgp65Wpo/PvJ2VYKnAgPVh7iXDqGeOivpalh t7KoveoK4hBDp+aYK6mv/VvrpfybN2TTZ0ISaLgsuN1ygRdb6HAJAVNNqO2d2PK4 l9xrMdfhYnMwDVVq9XfBi0HGOQmUyZV93VOn1JWdGVbblTphJPBGg9g17VoRrIZ4 0S7DAMlHMQwYkYDfz1OHBBMTcUCJXlwprM/3mMcSwJ3wZ5fLIWFOTtb3J2jCkaQx mUSXO549cCEmknHa/OkkirnSEYZOMQ4NUt+JuNmfOwokhohqrMApdt/ie2k60He1 GH878+Zw6Ej2FTviSlwbphYCDSY4AOFMGMISEuipJeRuDuzFRzwuAKLSdUsHiJ74 adnRnbVy4SMde6upantGSiYqn81H/NFyll/JfW1n77i6+2bpe3pVwE9Ft+hlOkc9 5HnXqkyZDx/m0FURmygV2ljqL3+jr5m4nA3uPeG7XnauwnrJtbfhhuKKXl1wx5Cp W/+btip7GnVUyIp4mM1X =pPJq -----END PGP SIGNATURE----- --Apple-Mail=_C4E4CACE-761E-4B3F-B41D-B27E8D7044A1-- From nobody Wed Jul 5 06:27:08 2017 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 90F53132A19 for ; Wed, 5 Jul 2017 06:27:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=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 X1arLZakUaiv for ; Wed, 5 Jul 2017 06:27:03 -0700 (PDT) Received: from mail-lf0-x229.google.com (mail-lf0-x229.google.com [IPv6:2a00:1450:4010:c07::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 3B2E6132A13 for ; Wed, 5 Jul 2017 06:27:03 -0700 (PDT) Received: by mail-lf0-x229.google.com with SMTP id t72so24793950lff.1 for ; Wed, 05 Jul 2017 06:27:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=UKfnMuwHUZ/RgEvUOOGlINc1+jwLRDMAn5UQdl/D17s=; b=RQrqZDZipeNNA421oDvOPmrkuimuILR8SqbMcxEt+Wrp45xev9oiv0TbsC8AHJ2MUR Ys6zVKdJS7jCikBG6dyzp4RBl0RtTw3MJhGx/mYqfsw4A+LDJYAt3KjNfJ9cfZ31ssmx iSiy0LT0+DTw47mnbF8vK+XQ8ZU/2wRJ9V6iLUo5yqsFrr+a7YZePYxRpEuPzGR0ioXG kmffynVavkmAn2rdfJmoN5p5hO6zfzZ9ajThz/tVWRmLgWKPkGuOKxbbP4XJTk+WZzON 9RFp9RXEJ3tNm/lthZpXBKwMIbd+oGKLze/NuB45Ny61TQOCpA4sBCvzrR2ddSdva+2g 3iIg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=UKfnMuwHUZ/RgEvUOOGlINc1+jwLRDMAn5UQdl/D17s=; b=GVq+boCzeQlVy/cnIdFMOIia2waEuchfUa8m5fVceoXDi5VMHMWnK5QUcMKJN7DM/k Q6juWLdjG8u1l32B0MtZf9adQNoo1uchGC8lR6wKaVW7asStCC9vlMD0abfYhojCx7oL oWVgBAT9JHzikewCAtNMr48yhiZ45OPRtP1tw2GKMvMrzUpOhZTRrW1DX+whCg7lVGCZ bU3oBZJf0SYv0QO65dgKkOIPEhtYVNLRq6IVMGEDeYiJGWWlwXvSYbEUXIdNPQSjKWW9 JhU6HhjZCxR6CDwWFN1I4UA3c1fEU6363cq+AJWdQWcnNyqwCwU2ajh1fMoZeEXjkb0G eAQA== X-Gm-Message-State: AKS2vOzyv7Fjfn6081YP8uRg5n6FDcikuzstv4c/ecA3blIfkhuxIGgE Qi7HA3JLhQlhOppP/z4MP6Cc0w7YWA== X-Received: by 10.46.71.72 with SMTP id u69mr13290752lja.16.1499261221388; Wed, 05 Jul 2017 06:27:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.22.211 with HTTP; Wed, 5 Jul 2017 06:27:00 -0700 (PDT) In-Reply-To: References: <8AE29DD0-26FE-4AB6-A4A9-2BB9169BAB13@jovanovic.io> <11cc5d3f-ecf9-2fd0-825c-c8b441bd2813@tugraz.at> From: Thomas Garcia Date: Wed, 5 Jul 2017 14:27:00 +0100 Message-ID: To: Bryan Ford Cc: Daniel Slamanig , cfrg@irtf.org Content-Type: multipart/alternative; boundary="001a11411b8486ca1c055391f431" Archived-At: Subject: Re: [Cfrg] Internet-Draft: Collective Edwards-Curve Digital Signature Algorithm X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jul 2017 13:27:07 -0000 --001a11411b8486ca1c055391f431 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello, I have a number of comments regarding the draft. 1. In the described protocol the leader, after receiving commitments from the participants and calculating the challenge c, sends that challenge to the participants. The participants then do not verify that c was indeed calculated using the message that they intended to sign, allowing the leader to procure signatures for arbitrary messages. A stage of verification of c should be added to the protocol. 2. EdDSA is designed to withstand collision attacks against the hash function used in the signature. On the other hand, the protocol suggested is susceptible to such attacks. A hostile leader and participant, together, could wait for all other participants to select their commitments. They could then choose a commitment such that SHA512(R||A||msg)=3DSHA512(R'||A||msg'), providing them with a signature of msg'. This would of course have to be done in real-time, and given the strength of SHA512 is in no way practical. This kind of attack would be difficult to avoid without substantial modifications to the scheme, but this does not seem to be a significant threat. Thomas G. On Wed, Jul 5, 2017 at 2:11 PM, Bryan Ford wrote: > Hi Daniel, thanks for your thoughts on the commitment-to-the-bitmask issu= e. > > Your proposal of using a chameleon hash, to allow the leader to =E2=80=9C= adjust=E2=80=9D > the bit mask after the commit c has been established, is an interesting > idea. However, if I understand it correctly, if the leader holds the > trapdoor key for the chameleon hash, wouldn=E2=80=99t that still make the= final > collective signature malleable for the leader (or for anyone the leader= =E2=80=99s > trapdoor key might leak to)? The CoSi protocol as currently defined is > intended to ensure that the leader has no special privilege or trust with > respect to other cosigners: i.e., the leader is merely an ordinary > participant, but is simply the one who for whatever reason decides to > initiate the cosigning operation. Giving the leader special powers - e.g= ., > making the signature malleable to the leader but not to others - would > break this principle and need to be extremely carefully considered I thin= k. > > To follow up on my last message to Oleg, again I suggest reading section > IV of our CoSi paper from IEEE S&P last year (http://dedis.cs.yale.edu/ > dissent/papers/witness-abs), as it discusses several related issues, > especially the potential desire to allow the leader to complete a > collective signing procedure even with only a subset of =E2=80=9Ccommitte= d=E2=80=9D > participants remaining present in the =E2=80=9Cresponse=E2=80=9D phase. = In particular, the > leader can form all the individual Schnorr commits into a Merkle tree, an= d > make the real commit c be the root of that Merkle tree. In this way, the > leader is committing not so much to a particular collective Schnorr commi= t > but rather to *all possible* Schnorr commits that can be composed from an= y > subset of the individual Schnorr commits within that Merkle tree. This > way, if some of the participants whose commits are present in that Merkle > tree remain available during the response phase but others drop out, the > leader can still use the commit c and form a correct and verifiable > collective signature against the particular subset of Schnorr commits fro= m > nodes that remained available throughout the process, without restarting. > > I guess this approach does, in a slightly different way, make the > resulting collective signatures slightly malleable to the leader: from a > given set of commit-time and response-time information, the leader could > put together distinct collective signatures representing different subset= s > of response-time participants. Some form of =E2=80=9Cleader-malleability= =E2=80=9D of this > kind seems unavoidably essential to enabling the leader to complete a > collective signing round in the presence of partial failures without > restarting. Perhaps the same limited leader-malleability is more-or-less > the same property your suggestion of using chameleon hashes has, although= I > haven=E2=80=99t had a chance to compare them deeply yet. > > But at any rate, the higher-level tradeoff here to consider is whether > it=E2=80=99s better to (a) enforce strict non-malleability of collective = signatures > (by anyone, leader included), at the cost of O(N)-round DoS attack > vulnerability during signing due to the need to restart partially failed > rounds, or (b) provide some limited form of limited leader-malleability i= n > order to support restart-free operation and avoid DoS attacks during > signing, at the cost of a more complex protocol (and perhaps slightly mor= e > =E2=80=9Cspecial=E2=80=9D trust in the leader than we might like). > > Again, further thoughts on this and other topics are most welcome. > > Thanks > Bryan > > On Jul 3, 2017, at 7:34 PM, Daniel Slamanig > wrote: > > Hi Philipp, > > looks interesting! > > After looking at the protocol I also have some security concerns (related > to what has been raised by Oleg in a previous mail). > > Not committing to Z as well as the actual sum of signers public keys A' i= n > the computation of the hash c for the signature seems to be problematic. > > It seems to me that committing Z in the signature in plain as well as A' > does not work given the later application of the signing procedure (where > till the end of the protocol it is not clear who actually participates in > the signing but c must be known at the beginning). > > Committing to neither of both however seems problematic as it does not fi= x > the set of actual signers. > > This could be circumvented by allowing an honest leader to adapt the > commitment to the final Z (and A') after it knows the signers without > modifying the initially computed c using a chameleon hash (trapdoor > commitment). I use P as a generator below, omit the brackets [a]P notatio= n > for scalar multiplication and write it from the perspective of the leader= , > i.e., the signer that initiates the protocol. > > The leader could choose chameleon hash parameters sk_ch=3Dy for random y = and > pk_ch=3D(P,Y=3DyP) and add pk_ch and chameleon hash CH(Z'):=3Dh(Z')P+u'Y = for > randomly chosen u' to the computation of c, i.e., set > c=3DH(R||A||pk_ch||CH(Z')||S), where h() is a collision resistant hash > function (this is just the standard way of constructing a chameleon hash > from DL for arbitrary message spaces as propsed in [1]). If Z' is not yet > known one simply sets Z' to some fixed string at the beginning, e.g., > Z':=3D0. At the end of the protocol, when the leader knows the exact sign= ers, > it can update Z' to the final value Z and use sk_ch to compute a collisio= n > in the chameleon hash, i.e., such that CH(Z)=3DCH(Z') by solving h(Z')+u'= y =3D > h(Z)+uy for u. He then adds u and Z as well as pk_ch to the signature, > i.e., sets it as (R,s,u,Z,pk_ch) and discards sk_ch and u'. If Z is known > beforehand, one simply computes the chameleon hash once and does not need > to compute a collision. Clearly, the use of a chameleon hash allows to > simply adapt to the actual set of signers representing Z without modifyin= g > c (with the knowledge of sk_ch - but it does not work without the knowled= ge > of sk_ch). This would resolve the issue with the unknown Z at the time of > signing. > > Also, A is committed in the signature, but not the concrete A'=3D\sum A_i= of > keys used for computing the signature (I guess also due to the reason tha= t > one does not know the correct set of signers when computing the hash c). > That can be problematic in a rogue key scenario in the current protocol, > i.e., when not all signers need to prove knowledge of the secret key when > they register their public keys but their public keys could be functions = of > other public keys (guess this could be a problem here). For instance, a > malicious A^* could just take some key from A, say A_j, and compute and > publish A^*=3Da^*A_j. And then given a collective signature (R,s,Z) where= A_j > participated, the signer can update s to s^* =3D s+a^*c as well as Z^* to > exclude A_j and include A^* (as Z is not committed in the signature > generation) and the signature (R,s^*,Z^*) will be a valid signature that > certifies that A^* participated in signing - although he didn't. > > If Z is committed as proposed above and it is checked during the > verification, then this should no longer work. One could also adapt the > hash c=3DH(R||pk_ch||CH(Z'||A)||S) to include a chameleon hash to CH(Z||A= '), > where A' is the real set of signers that participated in the signature > generation and is adapted before finalizing the signature when known as > above. > > I hope that what I proposed is not just complete nonsense :) Also it > produces quite a bit of an overhead. There may also be easier ways to avo= id > the issues. > > Some editorial issues: the message to be signed is sometimes called a > satement S and later then message msg. S could be confusing as part of th= e > signature is s and your semantic is that scalars are lowercase and points > are uppercase. Also in 4.2 "Signature Generation" steps 2 and 3 are > confusing as I guess that in the protocol all the signer compute their ow= n > [r_i]B values and R=3D\sum R_i instead of R=3D[r]B which would mean that = they > would send their r_i's (hope they will not do so). > > Also I find it somewhat confusing that the bitmask Z identifies the > non-signers with a bit set to 1. Why not identifying the signers with a b= it > set to 1? > > Cheers, > Daniel > > > [1] Hugo Krawczyk, Tal Rabin: Chameleon Signatures. NDSS 2000 > > On 01.07.2017 23:58, Philipp Jovanovic wrote: > > Hi CFRG, > Here=E2=80=99s a first version of an Internet-Draft on =E2=80=9CCollectiv= e Edwards-Curve > Digital Signature Algorithms=E2=80=9D based on Ed25519 and Ed448: > https://datatracker.ietf.org/doc/draft-ford-cfrg-cosi/ > We plan to give a short presentation on that topic at the next CFRG > meeting in Prague. > Any feedback is more than welcome. Thanks! > All the best, > Philipp > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > https://www.irtf.org/mailman/listinfo/cfrg > > > > -- > Dr. Daniel Slamanig > Institute for Applied Information Processing and Communications > Graz University of Technology > Inffeldgasse 16a, 8010 Graz, Austria. > Phone: +43 316 873 5509 <+43%20316%208735509> > http://www.iaik.tugraz.at > > _______________________________________________ > 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 > > --001a11411b8486ca1c055391f431 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello,
I have a number of comments regarding the draft= .
1. In the described protocol the leader, after receiving commit= ments from the participants and calculating the challenge c, sends that cha= llenge to the participants. The participants then do not verify that c was = indeed calculated using the message that they intended to sign, allowing th= e leader to procure signatures for arbitrary messages. A stage of verificat= ion of c should be added to the protocol.
2. EdDSA is designed to= withstand collision attacks against the hash function used in the signatur= e. On the other hand, the protocol suggested is susceptible to such attacks= . A hostile leader and participant, together, could wait for all other part= icipants to select their commitments. They could then choose a commitment s= uch that SHA512(R||A||msg)=3DSHA512(R'||A||msg'), providing them wi= th a signature of msg'. This would of course have to be done in real-ti= me, and given the strength of SHA512 is in no way practical. This kind of a= ttack would be difficult to avoid without substantial modifications to the = scheme, but this does not seem to be a significant threat.

Thomas G.

On Wed, Jul 5, 2017 at 2:11 PM, Bryan Ford &= lt;brynosaurus@g= mail.com> wrote:
Hi Daniel, thanks for your thoughts on the comm= itment-to-the-bitmask issue.

Your proposal of using a ch= ameleon hash, to allow the leader to =E2=80=9Cadjust=E2=80=9D the bit mask = after the commit c has been established, is an interesting idea. However, i= f I understand it correctly, if the leader holds the trapdoor key for the c= hameleon hash, wouldn=E2=80=99t that still make the final collective signat= ure malleable for the leader (or for anyone the leader=E2=80=99s trapdoor k= ey might leak to)?=C2=A0 The CoSi protocol as currently defined is intended= to ensure that the leader has no special privilege or trust with respect t= o other cosigners: i.e., the leader is merely an ordinary participant, but = is simply the one who for whatever reason decides to initiate the cosigning= operation.=C2=A0 Giving the leader special powers - e.g., making the signa= ture malleable to the leader but not to others - would break this principle= and need to be extremely carefully considered I think.

To follow up on my last message to Oleg, again I suggest reading sect= ion IV of our CoSi paper from IEEE S&P last year (http://dedis.c= s.yale.edu/dissent/papers/witness-abs), as it discusses several re= lated issues, especially the potential desire to allow the leader to comple= te a collective signing procedure even with only a subset of =E2=80=9Ccommi= tted=E2=80=9D participants remaining present in the =E2=80=9Cresponse=E2=80= =9D phase.=C2=A0 In particular, the leader can form all the individual Schn= orr commits into a Merkle tree, and make the real commit c be the root of t= hat Merkle tree.=C2=A0 In this way, the leader is committing not so much to= a particular collective Schnorr commit but rather to *all possible* Schnor= r commits that can be composed from any subset of the individual Schnorr co= mmits within that Merkle tree.=C2=A0 This way, if some of the participants = whose commits are present in that Merkle tree remain available during the r= esponse phase but others drop out, the leader can still use the commit c an= d form a correct and verifiable collective signature against the particular= subset of Schnorr commits from nodes that remained available throughout th= e process, without restarting.

I guess this approa= ch does, in a slightly different way, make the resulting collective signatu= res slightly malleable to the leader: from a given set of commit-time and r= esponse-time information, the leader could put together distinct collective= signatures representing different subsets of response-time participants.= =C2=A0 Some form of =E2=80=9Cleader-malleability=E2=80=9D of this kind seem= s unavoidably essential to enabling the leader to complete a collective sig= ning round in the presence of partial failures without restarting.=C2=A0 Pe= rhaps the same limited leader-malleability is more-or-less the same propert= y your suggestion of using chameleon hashes has, although I haven=E2=80=99t= had a chance to compare them deeply yet. =C2=A0

B= ut at any rate, the higher-level tradeoff here to consider is whether it=E2= =80=99s better to (a) enforce strict non-malleability of collective signatu= res (by anyone, leader included), at the cost of O(N)-round DoS attack vuln= erability during signing due to the need to restart partially failed rounds= , or (b) provide some limited form of limited leader-malleability in order = to support restart-free operation and avoid DoS attacks during signing, at = the cost of a more complex protocol (and perhaps slightly more =E2=80=9Cspe= cial=E2=80=9D trust in the leader than we might like).

=
Again, further thoughts on this and other topics are most welcome.

Thanks
Bryan

On Jul 3, 2017, at 7:34 PM, Daniel Slamanig <daniel.slamanig@tug= raz.at> wrote:

Hi Philipp,

looks interesting!

After l= ooking at the protocol I also have some security concerns (related to what = has been raised by Oleg in a previous mail).

Not committing to Z as = well as the actual sum of signers public keys A' in the computation of = the hash c for the signature seems to be problematic.

It seems to me= that committing Z in the signature in plain as well as A' does not wor= k given the later application of the signing procedure (where till the end = of the protocol it is not clear who actually participates in the signing bu= t c must be known at the beginning).

Committing to neither of both h= owever seems problematic as it does not fix the set of actual signers.
<= br>This could be circumvented by allowing an honest leader to adapt the com= mitment to the final Z (and A') after it knows the signers without modi= fying the initially computed c using a chameleon hash (trapdoor commitment)= . I use P as a generator below, omit the brackets [a]P notation for scalar = multiplication and write it from the perspective of the leader, i.e., the s= igner that initiates the protocol.

The leader could choose chameleon= hash parameters sk_ch=3Dy for random y and pk_ch=3D(P,Y=3DyP) and add pk_c= h and chameleon hash CH(Z'):=3Dh(Z')P+u'Y for randomly chosen u= ' to the computation of c, i.e., set c=3DH(R||A||pk_ch||CH(Z')||S),= where h() is a collision resistant hash function (this is just the standar= d way of constructing a chameleon hash from DL for arbitrary message spaces= as propsed in [1]). If Z' is not yet known one simply sets Z' to s= ome fixed string at the beginning, e.g., Z':=3D0. At the end of the pro= tocol, when the leader knows the exact signers, it can update Z' to the= final value Z and use sk_ch to compute a collision in the chameleon hash, = i.e., such that CH(Z)=3DCH(Z') by solving h(Z')+u'y =3D h(Z)+uy= for u. He then adds u and Z as well as pk_ch to the signature, i.e., sets = it as (R,s,u,Z,pk_ch) and discards sk_ch and u'. If Z is known beforeha= nd, one simply computes the chameleon hash once and does not need to comput= e a collision. Clearly, the use of a chameleon hash allows to simply adapt = to the actual set of signers representing Z without modifying c (with the k= nowledge of sk_ch - but it does not work without the knowledge of sk_ch). T= his would resolve the issue with the unknown Z at the time of signing.
<= br>Also, A is committed in the signature, but not the concrete A'=3D\su= m A_i of keys used for computing the signature (I guess also due to the rea= son that one does not know the correct set of signers when computing the ha= sh c). That can be problematic in a rogue key scenario in the current proto= col, i.e., when not all signers need to prove knowledge of the secret key w= hen they register their public keys but their public keys could be function= s of other public keys (guess this could be a problem here). For instance, = a malicious A^* could just take some key from A, say A_j, and compute and p= ublish A^*=3Da^*A_j. And then given a collective signature (R,s,Z) where A_= j participated, the signer can update s to s^* =3D s+a^*c as well as Z^* to= exclude A_j and include A^* (as Z is not committed in the signature genera= tion) and the signature (R,s^*,Z^*) will be a valid signature that certifie= s that A^* participated in signing - although he didn't.

If Z is= committed as proposed above and it is checked during the verification, the= n this should no longer work. One could also adapt the hash c=3DH(R||pk_ch|= |CH(Z'||A)||S) to include a chameleon hash to CH(Z||A'), where A= 9; is the real set of signers that participated in the signature generation= and is adapted before finalizing the signature when known as above.
I hope that what I proposed is not just complete nonsense :) Also it produ= ces quite a bit of an overhead. There may also be easier ways to avoid the = issues.

Some editorial issues: the message to be signed is sometimes= called a satement S and later then message msg. S could be confusing as pa= rt of the signature is s and your semantic is that scalars are lowercase an= d points are uppercase. Also in 4.2 "Signature Generation" steps = 2 and 3 are confusing as I guess that in the protocol all the signer comput= e their own [r_i]B values and R=3D\sum R_i instead of R=3D[r]B which would = mean that they would send their r_i's (hope they will not do so).
Also I find it somewhat confusing that the bitmask Z identifies the non-s= igners with a bit set to 1. Why not identifying the signers with a bit set = to 1?

Cheers,
Daniel


[1] Hugo Krawczyk, Tal Rabin: Cha= meleon Signatures. NDSS 2000

On 01.07.2017 23:58, P= hilipp Jovanovic wrote:
Hi CFRG,
Here=E2=80= =99s a first version of an Internet-Draft on =E2=80=9CCollective Edwards-Cu= rve Digital Signature Algorithms=E2=80=9D based on Ed25519 and Ed448: https://datatracker.ietf.org/doc/draft-ford-cfrg-cosi/
We = plan to give a short presentation on that topic at the next CFRG meeting in= Prague.
Any feedback is more than welcome. Thanks!
All the best,
= Philipp
_______________________________________________
Cfrg mai= ling list
Cfrg@irtf.o= rg
https://www.irtf.org/mailman/listinfo/cfrg


--
Dr. Da= niel Slamanig
Institute for Applied Information Processing and Communica= tions
Graz University of Technology
Inffeldgasse 16a, 8010 Graz, Aust= ria.
Phone: +43 316 873 5509
http://www.iaik.tugraz.at

_______________________________________________
Cfr= g mailing list
Cfrg@i= rtf.org
https://www.irtf.org/mailman/listinfo/cfrg
=


________________________= _______________________
Cfrg mailing list
Cfrg@irtf.org
https://www.irtf.org/mailman/listinfo/cfrg


--001a11411b8486ca1c055391f431-- From nobody Wed Jul 5 09:29:40 2017 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 A22FF131D71 for ; Wed, 5 Jul 2017 09:29:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 lf5tjaHn0m-U for ; Wed, 5 Jul 2017 09:29:35 -0700 (PDT) Received: from mail-wr0-x235.google.com (mail-wr0-x235.google.com [IPv6:2a00:1450:400c:c0c::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 DB28E131D4E for ; Wed, 5 Jul 2017 09:29:34 -0700 (PDT) Received: by mail-wr0-x235.google.com with SMTP id k67so265319095wrc.2 for ; Wed, 05 Jul 2017 09:29:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=0nF05oLs9wB2XszEY29JO2CHdwTe/2lz56sZecOQ0Uc=; b=U9/piQ9M11GLE8bJhll7AhSpRQOZOQwK0gLp526EthlOGAoEApftJ2YHvbwgy6ZKe+ Ww5SeCiRLqu3mf55ut44JckE/2iywlbE3rPBw6qp0F76oCJpYxddBS7sRBOCe4yd+K/Q YoKOtFdkkv+63AfjTFBJHW4Qz+gP6U4+4xal6ri3he/5N8rwN7TMEKjXnQhmCtzBsMCg SGftIUGpDIOT/H0gdVqprS6GLhzHo3qhUqBtKhPHPkTJJqLZ0nRcbZB5bwbzA8U5FBNq a6aW0Xbi7wRPO0uef4VWPfInzN3ymPJhj0BbncEUlVIkkchyLu/q63RIyyWKf0t0WoTq ShLg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=0nF05oLs9wB2XszEY29JO2CHdwTe/2lz56sZecOQ0Uc=; b=UV7RCYfb4dOzYl6u//97RGahBpz8gVgha//AwYkNKrcvOmm/Sgm2ofDK3armEwqZiM +jWHKfqnHUq+BdJRI/Pr4K0HccRuD6tWbfK1u09Wpk19i/cJvZ9VnAKgv9oOho0PoMym yb3o6A5PZbvF+GVpM54NmFjdnrFe+R7mzhlZ1rR+zd9anlfgXuvVIHZzypvRbWR/CESX UEeEiq6JzUywqRAmgHvS/t81NQfmqJ/PzaQYPurAuxWsZsYK9b3ZYQoCZkEqYQvfphu0 dafkdIbcd3N9Bdo4CUtOij3VdZ3TMDHAqba64k7v9kxIsf+AZ2T4U4OhDd3oWq8c5hpC uSNQ== X-Gm-Message-State: AKS2vOxNMv8dGs+KoSjwgxXwfOoMFT8fWMVvGN4vtRwORVPG8aDRL+Hz ecAHaDnZTjEb/g== X-Received: by 10.223.145.227 with SMTP id 90mr39896772wri.171.1499272173395; Wed, 05 Jul 2017 09:29:33 -0700 (PDT) Received: from [192.168.1.28] (83-103-13-156.ip.fastwebnet.it. [83.103.13.156]) by smtp.gmail.com with ESMTPSA id 79sm12600055wrc.34.2017.07.05.09.29.25 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 05 Jul 2017 09:29:26 -0700 (PDT) From: Bryan Ford Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_821CAADD-B3B5-40A3-BF93-B12AD20EDA74"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Wed, 5 Jul 2017 18:29:23 +0200 In-Reply-To: Cc: Daniel Slamanig , cfrg@irtf.org To: Thomas Garcia References: <8AE29DD0-26FE-4AB6-A4A9-2BB9169BAB13@jovanovic.io> <11cc5d3f-ecf9-2fd0-825c-c8b441bd2813@tugraz.at> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Cfrg] Internet-Draft: Collective Edwards-Curve Digital Signature Algorithm X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jul 2017 16:29:39 -0000 --Apple-Mail=_821CAADD-B3B5-40A3-BF93-B12AD20EDA74 Content-Type: multipart/alternative; boundary="Apple-Mail=_B73CB522-DE56-4B30-967E-A4ECA65EE493" --Apple-Mail=_B73CB522-DE56-4B30-967E-A4ECA65EE493 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Thomas, > On Jul 5, 2017, at 3:27 PM, Thomas Garcia = wrote: >=20 > Hello, > I have a number of comments regarding the draft. > 1. In the described protocol the leader, after receiving commitments = from the participants and calculating the challenge c, sends that = challenge to the participants. The participants then do not verify that = c was indeed calculated using the message that they intended to sign, = allowing the leader to procure signatures for arbitrary messages. A = stage of verification of c should be added to the protocol. Oops, looks like that was an unfortunate omission that snuck into the = first draft somehow. Indeed, the cosigners definitely must not simply = trust the leader to compute c correctly. What section 5.1.3 should say = is that the leader sends out the aggregate commitment R, which all = participants use to compute c =3D SHA512(R || A || M) independently = based on that R, ensuring that the responses they produced are only good = for a particular message M they=E2=80=99ve seen and approved. (And the = hash might of course be further extended to cover additional = information, such as the bit mask, depending on the outcome of other = orthogonal discussions raised by others.) We=E2=80=99ll make sure that = fix gets into the next version of the spec - thanks for pointing out the = bug. > 2. EdDSA is designed to withstand collision attacks against the hash = function used in the signature. On the other hand, the protocol = suggested is susceptible to such attacks. A hostile leader and = participant, together, could wait for all other participants to select = their commitments. They could then choose a commitment such that = SHA512(R||A||msg)=3DSHA512(R'||A||msg'), providing them with a signature = of msg'. This would of course have to be done in real-time, and given = the strength of SHA512 is in no way practical. This kind of attack would = be difficult to avoid without substantial modifications to the scheme, = but this does not seem to be a significant threat. Nice observation, thanks. Agreed, it=E2=80=99s not clear that there=E2=80= =99s a straightforward way to protect against such attacks in the event = the hash function has collision weaknesses - but hopefully SHA512 will = be strong enough for long enough that this shouldn=E2=80=99t be an issue = in practice. Cheers Bryan > Thomas G. >=20 > On Wed, Jul 5, 2017 at 2:11 PM, Bryan Ford > wrote: > Hi Daniel, thanks for your thoughts on the commitment-to-the-bitmask = issue. >=20 > Your proposal of using a chameleon hash, to allow the leader to = =E2=80=9Cadjust=E2=80=9D the bit mask after the commit c has been = established, is an interesting idea. However, if I understand it = correctly, if the leader holds the trapdoor key for the chameleon hash, = wouldn=E2=80=99t that still make the final collective signature = malleable for the leader (or for anyone the leader=E2=80=99s trapdoor = key might leak to)? The CoSi protocol as currently defined is intended = to ensure that the leader has no special privilege or trust with respect = to other cosigners: i.e., the leader is merely an ordinary participant, = but is simply the one who for whatever reason decides to initiate the = cosigning operation. Giving the leader special powers - e.g., making = the signature malleable to the leader but not to others - would break = this principle and need to be extremely carefully considered I think. >=20 > To follow up on my last message to Oleg, again I suggest reading = section IV of our CoSi paper from IEEE S&P last year = (http://dedis.cs.yale.edu/dissent/papers/witness-abs = ), as it discusses = several related issues, especially the potential desire to allow the = leader to complete a collective signing procedure even with only a = subset of =E2=80=9Ccommitted=E2=80=9D participants remaining present in = the =E2=80=9Cresponse=E2=80=9D phase. In particular, the leader can = form all the individual Schnorr commits into a Merkle tree, and make the = real commit c be the root of that Merkle tree. In this way, the leader = is committing not so much to a particular collective Schnorr commit but = rather to *all possible* Schnorr commits that can be composed from any = subset of the individual Schnorr commits within that Merkle tree. This = way, if some of the participants whose commits are present in that = Merkle tree remain available during the response phase but others drop = out, the leader can still use the commit c and form a correct and = verifiable collective signature against the particular subset of Schnorr = commits from nodes that remained available throughout the process, = without restarting. >=20 > I guess this approach does, in a slightly different way, make the = resulting collective signatures slightly malleable to the leader: from a = given set of commit-time and response-time information, the leader could = put together distinct collective signatures representing different = subsets of response-time participants. Some form of = =E2=80=9Cleader-malleability=E2=80=9D of this kind seems unavoidably = essential to enabling the leader to complete a collective signing round = in the presence of partial failures without restarting. Perhaps the = same limited leader-malleability is more-or-less the same property your = suggestion of using chameleon hashes has, although I haven=E2=80=99t had = a chance to compare them deeply yet. >=20 > But at any rate, the higher-level tradeoff here to consider is whether = it=E2=80=99s better to (a) enforce strict non-malleability of collective = signatures (by anyone, leader included), at the cost of O(N)-round DoS = attack vulnerability during signing due to the need to restart partially = failed rounds, or (b) provide some limited form of limited = leader-malleability in order to support restart-free operation and avoid = DoS attacks during signing, at the cost of a more complex protocol (and = perhaps slightly more =E2=80=9Cspecial=E2=80=9D trust in the leader than = we might like). >=20 > Again, further thoughts on this and other topics are most welcome. >=20 > Thanks > Bryan >=20 >> On Jul 3, 2017, at 7:34 PM, Daniel Slamanig = > wrote: >>=20 >> Hi Philipp, >>=20 >> looks interesting! >>=20 >> After looking at the protocol I also have some security concerns = (related to what has been raised by Oleg in a previous mail). >>=20 >> Not committing to Z as well as the actual sum of signers public keys = A' in the computation of the hash c for the signature seems to be = problematic. >>=20 >> It seems to me that committing Z in the signature in plain as well as = A' does not work given the later application of the signing procedure = (where till the end of the protocol it is not clear who actually = participates in the signing but c must be known at the beginning). >>=20 >> Committing to neither of both however seems problematic as it does = not fix the set of actual signers. >>=20 >> This could be circumvented by allowing an honest leader to adapt the = commitment to the final Z (and A') after it knows the signers without = modifying the initially computed c using a chameleon hash (trapdoor = commitment). I use P as a generator below, omit the brackets [a]P = notation for scalar multiplication and write it from the perspective of = the leader, i.e., the signer that initiates the protocol. >>=20 >> The leader could choose chameleon hash parameters sk_ch=3Dy for = random y and pk_ch=3D(P,Y=3DyP) and add pk_ch and chameleon hash = CH(Z'):=3Dh(Z')P+u'Y for randomly chosen u' to the computation of c, = i.e., set c=3DH(R||A||pk_ch||CH(Z')||S), where h() is a collision = resistant hash function (this is just the standard way of constructing a = chameleon hash from DL for arbitrary message spaces as propsed in [1]). = If Z' is not yet known one simply sets Z' to some fixed string at the = beginning, e.g., Z':=3D0. At the end of the protocol, when the leader = knows the exact signers, it can update Z' to the final value Z and use = sk_ch to compute a collision in the chameleon hash, i.e., such that = CH(Z)=3DCH(Z') by solving h(Z')+u'y =3D h(Z)+uy for u. He then adds u = and Z as well as pk_ch to the signature, i.e., sets it as = (R,s,u,Z,pk_ch) and discards sk_ch and u'. If Z is known beforehand, one = simply computes the chameleon hash once and does not need to compute a = collision. Clearly, the use of a chameleon hash allows to simply adapt = to the actual set of signers representing Z without modifying c (with = the knowledge of sk_ch - but it does not work without the knowledge of = sk_ch). This would resolve the issue with the unknown Z at the time of = signing. >>=20 >> Also, A is committed in the signature, but not the concrete A'=3D\sum = A_i of keys used for computing the signature (I guess also due to the = reason that one does not know the correct set of signers when computing = the hash c). That can be problematic in a rogue key scenario in the = current protocol, i.e., when not all signers need to prove knowledge of = the secret key when they register their public keys but their public = keys could be functions of other public keys (guess this could be a = problem here). For instance, a malicious A^* could just take some key = from A, say A_j, and compute and publish A^*=3Da^*A_j. And then given a = collective signature (R,s,Z) where A_j participated, the signer can = update s to s^* =3D s+a^*c as well as Z^* to exclude A_j and include A^* = (as Z is not committed in the signature generation) and the signature = (R,s^*,Z^*) will be a valid signature that certifies that A^* = participated in signing - although he didn't. >>=20 >> If Z is committed as proposed above and it is checked during the = verification, then this should no longer work. One could also adapt the = hash c=3DH(R||pk_ch||CH(Z'||A)||S) to include a chameleon hash to = CH(Z||A'), where A' is the real set of signers that participated in the = signature generation and is adapted before finalizing the signature when = known as above. >>=20 >> I hope that what I proposed is not just complete nonsense :) Also it = produces quite a bit of an overhead. There may also be easier ways to = avoid the issues. >>=20 >> Some editorial issues: the message to be signed is sometimes called a = satement S and later then message msg. S could be confusing as part of = the signature is s and your semantic is that scalars are lowercase and = points are uppercase. Also in 4.2 "Signature Generation" steps 2 and 3 = are confusing as I guess that in the protocol all the signer compute = their own [r_i]B values and R=3D\sum R_i instead of R=3D[r]B which would = mean that they would send their r_i's (hope they will not do so). >>=20 >> Also I find it somewhat confusing that the bitmask Z identifies the = non-signers with a bit set to 1. Why not identifying the signers with a = bit set to 1? >>=20 >> Cheers, >> Daniel >>=20 >>=20 >> [1] Hugo Krawczyk, Tal Rabin: Chameleon Signatures. NDSS 2000 >>=20 >> On 01.07.2017 23:58, Philipp Jovanovic wrote: >>> Hi CFRG, >>> Here=E2=80=99s a first version of an Internet-Draft on =E2=80=9CCollec= tive Edwards-Curve Digital Signature Algorithms=E2=80=9D based on = Ed25519 and Ed448: = https://datatracker.ietf.org/doc/draft-ford-cfrg-cosi/ = >>> We plan to give a short presentation on that topic at the next CFRG = meeting in Prague. >>> Any feedback is more than welcome. Thanks! >>> All the best, >>> Philipp >>> _______________________________________________ >>> Cfrg mailing list >>> Cfrg@irtf.org >>> https://www.irtf.org/mailman/listinfo/cfrg = >>=20 >>=20 >> -- >> Dr. Daniel Slamanig >> Institute for Applied Information Processing and Communications >> Graz University of Technology >> Inffeldgasse 16a, 8010 Graz, Austria. >> Phone: +43 316 873 5509 >> http://www.iaik.tugraz.at >>=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 = >=20 >=20 --Apple-Mail=_B73CB522-DE56-4B30-967E-A4ECA65EE493 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi Thomas,

On Jul 5, 2017, at 3:27 PM, = Thomas Garcia <tgarcia.3141@gmail.com> wrote:

Hello,
I have a number of comments regarding = the draft.
1. In the described protocol the leader, = after receiving commitments from the participants and calculating the = challenge c, sends that challenge to the participants. The participants = then do not verify that c was indeed calculated using the message that = they intended to sign, allowing the leader to procure signatures for = arbitrary messages. A stage of verification of c should be added to the = protocol.

Oops, looks like that was an unfortunate omission = that snuck into the first draft somehow.  Indeed, the cosigners = definitely must not simply trust the leader to compute c correctly. =  What section 5.1.3 should say is that the leader sends out the = aggregate commitment R, which all participants use to compute c =3D = SHA512(R || A || M) independently based on that R, ensuring that the = responses they produced are only good for a particular message M = they=E2=80=99ve seen and approved.  (And the hash might of course = be further extended to cover additional information, such as the bit = mask, depending on the outcome of other orthogonal discussions raised by = others.)  We=E2=80=99ll make sure that fix gets into the next = version of the spec - thanks for pointing out the bug.

2. EdDSA is designed to withstand = collision attacks against the hash function used in the signature. On = the other hand, the protocol suggested is susceptible to such attacks. A = hostile leader and participant, together, could wait for all other = participants to select their commitments. They could then choose a = commitment such that SHA512(R||A||msg)=3DSHA512(R'||A||msg'), providing = them with a signature of msg'. This would of course have to be done in = real-time, and given the strength of SHA512 is in no way practical. This = kind of attack would be difficult to avoid without substantial = modifications to the scheme, but this does not seem to be a significant = threat.

Nice = observation, thanks.  Agreed, it=E2=80=99s not clear that there=E2=80= =99s a straightforward way to protect against such attacks in the event = the hash function has collision weaknesses - but hopefully SHA512 will = be strong enough for long enough that this shouldn=E2=80=99t be an issue = in practice.

Cheers
Bryan

Thomas G.

On Wed, = Jul 5, 2017 at 2:11 PM, Bryan Ford <brynosaurus@gmail.com> wrote:
Hi Daniel, thanks for your = thoughts on the commitment-to-the-bitmask issue.

Your proposal of using a chameleon = hash, to allow the leader to =E2=80=9Cadjust=E2=80=9D the bit mask after = the commit c has been established, is an interesting idea. However, if I = understand it correctly, if the leader holds the trapdoor key for the = chameleon hash, wouldn=E2=80=99t that still make the final collective = signature malleable for the leader (or for anyone the leader=E2=80=99s = trapdoor key might leak to)?  The CoSi protocol as currently = defined is intended to ensure that the leader has no special privilege = or trust with respect to other cosigners: i.e., the leader is merely an = ordinary participant, but is simply the one who for whatever reason = decides to initiate the cosigning operation.  Giving the leader = special powers - e.g., making the signature malleable to the leader but = not to others - would break this principle and need to be extremely = carefully considered I think.

To follow up on my last message to = Oleg, again I suggest reading section IV of our CoSi paper from IEEE = S&P last year (http://dedis.cs.yale.edu/dissent/papers/witness-abs), as it discusses several = related issues, especially the potential desire to allow the leader to = complete a collective signing procedure even with only a subset of = =E2=80=9Ccommitted=E2=80=9D participants remaining present in the = =E2=80=9Cresponse=E2=80=9D phase.  In particular, the leader can = form all the individual Schnorr commits into a Merkle tree, and make the = real commit c be the root of that Merkle tree.  In this way, the = leader is committing not so much to a particular collective Schnorr = commit but rather to *all possible* Schnorr commits that can be composed = from any subset of the individual Schnorr commits within that Merkle = tree.  This way, if some of the participants whose commits are = present in that Merkle tree remain available during the response phase = but others drop out, the leader can still use the commit c and form a = correct and verifiable collective signature against the particular = subset of Schnorr commits from nodes that remained available throughout = the process, without restarting.

I guess this approach does, in a = slightly different way, make the resulting collective signatures = slightly malleable to the leader: from a given set of commit-time and = response-time information, the leader could put together distinct = collective signatures representing different subsets of response-time = participants.  Some form of =E2=80=9Cleader-malleability=E2=80=9D = of this kind seems unavoidably essential to enabling the leader to = complete a collective signing round in the presence of partial failures = without restarting.  Perhaps the same limited leader-malleability = is more-or-less the same property your suggestion of using chameleon = hashes has, although I haven=E2=80=99t had a chance to compare them = deeply yet.  

But at any rate, the higher-level tradeoff here to consider = is whether it=E2=80=99s better to (a) enforce strict non-malleability of = collective signatures (by anyone, leader included), at the cost of = O(N)-round DoS attack vulnerability during signing due to the need to = restart partially failed rounds, or (b) provide some limited form of = limited leader-malleability in order to support restart-free operation = and avoid DoS attacks during signing, at the cost of a more complex = protocol (and perhaps slightly more =E2=80=9Cspecial=E2=80=9D trust in = the leader than we might like).

Again, further thoughts on this and = other topics are most welcome.

Thanks
Bryan

On Jul = 3, 2017, at 7:34 PM, Daniel Slamanig <daniel.slamanig@tugraz.at> wrote:

Hi Philipp,

looks = interesting!

After looking at the protocol = I also have some security concerns (related to what has been raised by = Oleg in a previous mail).

Not committing to = Z as well as the actual sum of signers public keys A' in the computation = of the hash c for the signature seems to be problematic.
It seems to me that committing Z in the signature in plain = as well as A' does not work given the later application of the signing = procedure (where till the end of the protocol it is not clear who = actually participates in the signing but c must be known at the = beginning).

Committing to neither of both = however seems problematic as it does not fix the set of actual = signers.

This could be circumvented by = allowing an honest leader to adapt the commitment to the final Z (and = A') after it knows the signers without modifying the initially computed = c using a chameleon hash (trapdoor commitment). I use P as a generator = below, omit the brackets [a]P notation for scalar multiplication and = write it from the perspective of the leader, i.e., the signer that = initiates the protocol.

The leader could = choose chameleon hash parameters sk_ch=3Dy for random y and = pk_ch=3D(P,Y=3DyP) and add pk_ch and chameleon hash CH(Z'):=3Dh(Z')P+u'Y = for randomly chosen u' to the computation of c, i.e., set = c=3DH(R||A||pk_ch||CH(Z')||S), where h() is a collision resistant hash = function (this is just the standard way of constructing a chameleon hash = from DL for arbitrary message spaces as propsed in [1]). If Z' is not = yet known one simply sets Z' to some fixed string at the beginning, = e.g., Z':=3D0. At the end of the protocol, when the leader knows the = exact signers, it can update Z' to the final value Z and use sk_ch to = compute a collision in the chameleon hash, i.e., such that CH(Z)=3DCH(Z') = by solving h(Z')+u'y =3D h(Z)+uy for u. He then adds u and Z as well as = pk_ch to the signature, i.e., sets it as (R,s,u,Z,pk_ch) and discards = sk_ch and u'. If Z is known beforehand, one simply computes the = chameleon hash once and does not need to compute a collision. Clearly, = the use of a chameleon hash allows to simply adapt to the actual set of = signers representing Z without modifying c (with the knowledge of sk_ch = - but it does not work without the knowledge of sk_ch). This would = resolve the issue with the unknown Z at the time of signing.

Also, A is committed in the signature, but not = the concrete A'=3D\sum A_i of keys used for computing the signature (I = guess also due to the reason that one does not know the correct set of = signers when computing the hash c). That can be problematic in a rogue = key scenario in the current protocol, i.e., when not all signers need to = prove knowledge of the secret key when they register their public keys = but their public keys could be functions of other public keys (guess = this could be a problem here). For instance, a malicious A^* could just = take some key from A, say A_j, and compute and publish A^*=3Da^*A_j. And = then given a collective signature (R,s,Z) where A_j participated, the = signer can update s to s^* =3D s+a^*c as well as Z^* to exclude A_j and = include A^* (as Z is not committed in the signature generation) and the = signature (R,s^*,Z^*) will be a valid signature that certifies that A^* = participated in signing - although he didn't.

If Z is committed as proposed above and it is checked during = the verification, then this should no longer work. One could also adapt = the hash c=3DH(R||pk_ch||CH(Z'||A)||S) to include a chameleon hash to = CH(Z||A'), where A' is the real set of signers that participated in the = signature generation and is adapted before finalizing the signature when = known as above.

I hope that what I proposed = is not just complete nonsense :) Also it produces quite a bit of an = overhead. There may also be easier ways to avoid the issues.

Some editorial issues: the message to be = signed is sometimes called a satement S and later then message msg. S = could be confusing as part of the signature is s and your semantic is = that scalars are lowercase and points are uppercase. Also in 4.2 = "Signature Generation" steps 2 and 3 are confusing as I guess that in = the protocol all the signer compute their own [r_i]B values and R=3D\sum = R_i instead of R=3D[r]B which would mean that they would send their = r_i's (hope they will not do so).

Also I = find it somewhat confusing that the bitmask Z identifies the non-signers = with a bit set to 1. Why not identifying the signers with a bit set to = 1?

Cheers,
Daniel


[1] Hugo Krawczyk, Tal Rabin: = Chameleon Signatures. NDSS 2000

On 01.07.2017 23:58, Philipp Jovanovic wrote:
Hi CFRG,
Here=E2=80=99s a first version of an Internet-Draft on = =E2=80=9CCollective Edwards-Curve Digital Signature Algorithms=E2=80=9D = based on Ed25519 and Ed448: https://datatracker.ietf.org/doc/draft-ford-cfrg-cosi/
We plan to give a = short presentation on that topic at the next CFRG meeting in Prague.
Any feedback is more than welcome. Thanks!
All = the best,
Philipp
_______________________________________________
Cfrg mailing list
Cfrg@irtf.org
https://www.irtf.org/mailman/listinfo/cfrg

--
Dr. Daniel Slamanig
Institute = for Applied Information Processing and Communications
Graz = University of Technology
Inffeldgasse 16a, 8010 Graz, = Austria.
Phone: +43 316 873 = 5509
http://www.iaik.tugraz.at
_______________________________________________
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



= --Apple-Mail=_B73CB522-DE56-4B30-967E-A4ECA65EE493-- --Apple-Mail=_821CAADD-B3B5-40A3-BF93-B12AD20EDA74 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIcBAEBCAAGBQJZXRPkAAoJEGt1rlrP7+d/LJgQAIKccHkpUYtcbN+3IlP40uBC DZt2+l9DzHcp1VOfaN7d7OL+aLTRkEhOdIWj/12RBuLbd1s8FRCp8IjSm96eYnPz mA9EDd0maLxdBOnXco6QROwOEC14rgDk18bCD2BsbXZt1m1FTby5cSHPpHNqyihP r8SZcVL5CL6D1vr1SZx15Hh8UjEaSy+PT0CriXBYXuohwVx8Bj7hp2IqMcgDtQeu b8WWuW7Y+lCcb77VguB1YRndK936pQ76Xm4/nWjirViYoa22w8fRlBvIbf1kq799 qGzwRYHARCeGihMCJ7PbNl3cdkLnUISx2kbJIQ8f8N2qRT846LoWqr6EOPrDd1gU zdbrKKX+jJEoHsufEtzGQaGw8A8kewhQYNBEjNQ8/QT6sTkKU7r7ukJM2OvDY6g6 hBnQG259fGVlczQ4Ys7M/0w3l53B+pZ5OTJ6GDxWjqiPTU+lPsCWw68G1lp/31k1 n2HN3sgoMkMHUN/IiRD/HqIYcf9LVcnvZUTx0O/DhYKCWMUsAgwPWu99PlCLHYtx vFFU++wmMcQe4xxVXOAbn3nGY4hBsxRMRgSDBk0+IJhjbUqDa5SftCr7dIXfjYiE vXopD8skA8m9qzcEseWMh6ha0B9jlG2Kz1b8v51BvQaT8RyOCJHGbqwHh8djeoZ4 r1GcdV7sx7zhZ/eGJOr6 =wuak -----END PGP SIGNATURE----- --Apple-Mail=_821CAADD-B3B5-40A3-BF93-B12AD20EDA74-- From nobody Wed Jul 5 11:23:28 2017 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 2C599131B5F for ; Wed, 5 Jul 2017 11:23:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.521 X-Spam-Level: X-Spam-Status: No, score=-14.521 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.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 n66kxT_EgtCF for ; Wed, 5 Jul 2017 11:23:25 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 73C1B13184B for ; Wed, 5 Jul 2017 11:23:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8091; q=dns/txt; s=iport; t=1499279005; x=1500488605; h=from:to:cc:subject:date:message-id:mime-version; bh=/UzDhYRte9UvBZ0LSi8t3eiiRyL7yxuoH4UOdZ7Jhw4=; b=NwvlAHbdtaVDoF2e8CIo+Pe0Dx77oNgDZKOfezbmhSl2uMoZDM3EPsiz hkXIsDPfP/FcN/OFqrFxRq7s1iJG35ynhtAktqQCETwW9qkF8msm8tEOO UwQ80gQB8CVzqdybDSnc7KdSK1rv9EtkunQAycysKqzi9ZqNRGgMKCWMR g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0A4AgCDLV1Z/4ENJK1dGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBgm9qY4EQB7A9hSyCESyFcIMeQRYBAgEBAQEBAQFrHQuFHS9MEgGBACY?= =?us-ascii?q?BBA4NiUNkELBoiz8BAQEBAQEBAQEBAQEBAQEBAQEBAQEdgyeDTIFhgySBJIk6B?= =?us-ascii?q?Zcph10CgWOFYow1gmuPPHCUQgEPFwUsP0t1FYVbHYFmdgGHdYENAQEB?= X-IronPort-AV: E=Sophos;i="5.40,312,1496102400"; d="scan'208,217";a="448868576" Received: from alln-core-9.cisco.com ([173.36.13.129]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 05 Jul 2017 18:23:24 +0000 Received: from XCH-RTP-001.cisco.com (xch-rtp-001.cisco.com [64.101.220.141]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id v65INO98002509 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Wed, 5 Jul 2017 18:23:24 GMT Received: from xch-rtp-006.cisco.com (64.101.220.146) by XCH-RTP-001.cisco.com (64.101.220.141) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 5 Jul 2017 14:23:23 -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.1210.000; Wed, 5 Jul 2017 14:23:23 -0400 From: "Scott Fluhrer (sfluhrer)" To: "cfrg@irtf.org" CC: "David McGrew (mcgrew)" Thread-Topic: Request for a slot to discuss the LMS hash based signatures at Prague Thread-Index: AdL1u8jStyGum1IMQimgMKynsUjIXg== Date: Wed, 5 Jul 2017 18:23:23 +0000 Message-ID: <05a9099ce483405ea988bc6053ceff66@XCH-RTP-006.cisco.com> 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.55] Content-Type: multipart/alternative; boundary="_000_05a9099ce483405ea988bc6053ceff66XCHRTP006ciscocom_" MIME-Version: 1.0 Archived-At: Subject: [Cfrg] Request for a slot to discuss the LMS hash based signatures at Prague X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jul 2017 18:23:27 -0000 --_000_05a9099ce483405ea988bc6053ceff66XCHRTP006ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I would ask to request a slot to discuss the LMS hash based signatures a= t the CRFG in-person meeting at Prague. I will not be there in person, how= ever David McGrew will be (and I'll be attending virtually). We have: - The latest version of the LMS draft: https://datatracker.ietf.or= g/doc/draft-mcgrew-hash-sigs/ - A proof of security (in the Random Oracle model, where the hash = compression function is considered the random Oracle): http://eprint.iacr.o= rg/2017/553.pdf - A comparison of this proposal with the XMSS proposal under consi= deration by the CRFG: http://eprint.iacr.org/2017/349.pdf - A practical implementation of this draft: https://github.com/cis= co/hash-sigs Thank you! --_000_05a9099ce483405ea988bc6053ceff66XCHRTP006ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

   I would ask to request a slot to discus= s the LMS hash based signatures at the CRFG in-person meeting at Prague.&nb= sp; I will not be there in person, however David McGrew will be (and I̵= 7;ll be attending virtually).

 

   We have:

 

-     &= nbsp;    The latest version of the LMS draft: https://datatracker.ietf.org/doc/draft-mcgrew-hash-sigs/

-     &= nbsp;    A proof of security (in the Random Oracle model, wh= ere the hash compression function is considered the random Oracle): http://eprint.iacr.org/2017= /553.pdf

-     &= nbsp;    A comparison of this proposal with the XMSS proposa= l under consideration by the CRFG: http://eprint.iacr.org/2017= /349.pdf

-     &= nbsp;    A practical implementation of this draft: https://github.com/cisco/hash-sigs

 

Thank you!

--_000_05a9099ce483405ea988bc6053ceff66XCHRTP006ciscocom_-- From nobody Wed Jul 5 11:38:27 2017 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 F136E131D9E for ; Wed, 5 Jul 2017 11:38:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.398 X-Spam-Level: X-Spam-Status: No, score=-2.398 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, URIBL_BLOCKED=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 2Vl1YwqBHwPr for ; Wed, 5 Jul 2017 11:38:24 -0700 (PDT) Received: from mail-lf0-x235.google.com (mail-lf0-x235.google.com [IPv6:2a00:1450:4010:c07::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 03D2C131DB2 for ; Wed, 5 Jul 2017 11:38:21 -0700 (PDT) Received: by mail-lf0-x235.google.com with SMTP id z78so98191480lff.0 for ; Wed, 05 Jul 2017 11:38:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:from:date:message-id:subject:to; bh=IEtX10uknXUUmHfb547Us78T5keHcPRrmU85yAoBAPo=; b=Qdi3trVC0QAfhfrUMJyXRWm0Z3lzcPQbcB/vujK8gZgAzekTjgDEpiaBjQcge7Bt/d JMxC8kPdPgp1TsoAPLYMtvlefhTFCDh7W5B7IlBpOGwznd9MLZqdyEBPhiGLm0ERLiVY pRM4AvzkyW2lZpPY64oVSi6Epl0K2Hhm1ep1yfT7L6uHy/dqpUPpUuz2r7uH0iRF1OAK 0P589pULNEoLgqPkILj0GHeyV7n5SXvL95wjwP17k+x0EV4cmtyoVLRT0+DPJv1n0fDc 33RkcpVKfTipOSVgy6DaL6w7hn3f5W4w/elaMUf0NLbJlp+kA49r3XXbd7KCCK+ylEZk 8ehA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:from:date:message-id:subject :to; bh=IEtX10uknXUUmHfb547Us78T5keHcPRrmU85yAoBAPo=; b=CwNLkh5F4rfx9pwS4bYadS2B5tlLU2JssYFtOdjmVRSj/rItHsadk9xcO9wMkuZzHi tU2ABYy6liO0K+NFvYV1b/TB+FgdmG7dHIuegbd3SaZSaG+dGycEbfqj7ODtUsjpeBNO VbJbHiUzNX/GGr1C61WR5b5WtRiDjUYtsS02v1C5ha9pFEkMldo3KoYWRX6NgmfVQ9EG AB8VA3AhdUEw1AiCBNS3Pp3J5A+3NhB3Hx6n3xWjP8DlJmyWAQZN6Ej3n6Z6N72Yj8ed 0UAsYkC8R3T4GUgq5MJT3NB4ueQNw6Zz1TT/dXNg/6UI+H5xeM+jTcX1vocD8tLGQmOL PTRw== X-Gm-Message-State: AKS2vOwR61p0sNhnqj19wpXadK2GYqF5vCbKd8vs8HN7H/vSRJL44I8B EnjKz4TGgp7nKjiBLPDHsxAOVpBwsCaf X-Received: by 10.46.82.199 with SMTP id n68mr12158438lje.99.1499279898840; Wed, 05 Jul 2017 11:38:18 -0700 (PDT) MIME-Version: 1.0 Sender: hallam@gmail.com Received: by 10.25.181.214 with HTTP; Wed, 5 Jul 2017 11:38:18 -0700 (PDT) From: Phillip Hallam-Baker Date: Wed, 5 Jul 2017 14:38:18 -0400 X-Google-Sender-Auth: e4LArwlx7mQ3iyeQbSf5L1fBfzY Message-ID: To: "cfrg@irtf.org" Content-Type: multipart/alternative; boundary="001a113be372ca138d0553964dff" Archived-At: Subject: [Cfrg] Side channel attack and Edwards curves... X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jul 2017 18:38:26 -0000 --001a113be372ca138d0553964dff Content-Type: text/plain; charset="UTF-8" http://thehackernews.com/2017/07/gnupg-libgcrypt-rsa-encryption.html?m=1 Just another side channel attack and not something that bothers me writing reference code. But have we maybe put our eggs in the Montgomery ladder basket when maybe we should have gone for 'randomly split the private key into two parts, perform two separate multiplications with each part and add the result'. We can play the blinding game in Edwards or Montgomery but it is easier in Edwards. Anyone got code for adding points in compressed Montgomery? Thoughts? --001a113be372ca138d0553964dff Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Just anothe= r side channel attack and not something that bothers me writing reference c= ode. But have we maybe put our eggs in the Montgomery ladder basket when ma= ybe we should have gone for 'randomly split the private key into two pa= rts, perform two separate multiplications with each part and add the result= '.

We can play the blinding game in Edwards or Montgomery but it is easie= r in Edwards.

Anyone got code for adding points in compressed Montgomery?


<= /div>

Th= oughts?


--001a113be372ca138d0553964dff-- From nobody Wed Jul 5 14:03:18 2017 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 3F2391200E5 for ; Wed, 5 Jul 2017 14:03:17 -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, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 pPN8GxjnMQz3 for ; Wed, 5 Jul 2017 14:03:15 -0700 (PDT) Received: from jupiter.mumble.net (jupiter.mumble.net [74.50.56.165]) (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 14616131A20 for ; Wed, 5 Jul 2017 14:03:14 -0700 (PDT) Received: by jupiter.mumble.net (Postfix, from userid 1014) id E58C860AA2; Wed, 5 Jul 2017 21:03:58 +0000 (UTC) From: Taylor R Campbell To: Phillip Hallam-Baker CC: cfrg@irtf.org In-reply-to: (phill@hallambaker.com) Date: Wed, 5 Jul 2017 21:03:20 +0000 Sender: Taylor R Campbell MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <20170705210358.E58C860AA2@jupiter.mumble.net> Archived-At: Subject: Re: [Cfrg] Side channel attack and Edwards curves... X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jul 2017 21:03:17 -0000 > Date: Wed, 5 Jul 2017 14:38:18 -0400 > From: Phillip Hallam-Baker >=20 > http://thehackernews.com/2017/07/gnupg-libgcrypt-rsa-encryption.html?m=3D1 >=20 > Just another side channel attack and not something that bothers me writing > reference code. But have we maybe put our eggs in the Montgomery ladder > basket when maybe we should have gone for 'randomly split the private key > into two parts, perform two separate multiplications with each part and a= dd > the result'. >=20 > We can play the blinding game in Edwards or Montgomery but it is easier in > Edwards. You can always convert from Montgomery x to Edwards (x, y) and back without losing anything and costing only one field element inversion; see XEdDSA for something similar. But there is no reason to flail around with blinding when you can just use constant-time code for both Edwards and Montgomery arithmetic. You can even do RSA in constant time, but it's hard if you naively start with a generic bignum library that automatically normalizes away high-order zeros for in-memory representations of secret integers. Unfortunately, both OpenSSL and libgcrypt did just that, and generally made basic mistakes for writing constant-time code in C. Not even anything interesting, like code that just happens to be `optimized' by a fancy compiler into variable-time -- they just have unnecessary explicit branches and array indices that are dependent on secrets. I wrote some details on and recommendations for libgcrypt a while back: https://lists.gnupg.org/pipermail/gcrypt-devel/2015-November/003618.html The easy bugs I observed in twisted Edwards scalarmult were fixed immediately; the harder bugs about generic bignum arithmetic were not fixed when I last checked. From nobody Wed Jul 5 14:56:23 2017 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 EE5C6120725 for ; Wed, 5 Jul 2017 14:56:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.398 X-Spam-Level: X-Spam-Status: No, score=-2.398 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, URIBL_BLOCKED=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 ZI_qLUBD-hrJ for ; Wed, 5 Jul 2017 14:56:20 -0700 (PDT) Received: from mail-lf0-x235.google.com (mail-lf0-x235.google.com [IPv6:2a00:1450:4010:c07::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 E2EEB1270AC for ; Wed, 5 Jul 2017 14:56:18 -0700 (PDT) Received: by mail-lf0-x235.google.com with SMTP id z78so1161668lff.0 for ; Wed, 05 Jul 2017 14:56:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=ugm3hWT1A3N52i9W+IfoPrbUq9EOkktuRlWCKlzOEmM=; b=I2haJyIFteU+R7Fv6iFynmsQMlA1blPYdqQwYwCNI4FfaTGQMtXAAS12ex2SPQ/69h dPrtDp6AH6mN68PXyDaSKlgB11DYe81FXW53mtLxghvXyTEk8XRRPEHjqm9i+8wTAeGB Xk4pw8Ies0/Lb6vWOgd0Jcbh6zneCo5scS+MckhQoPE7bCMfnmlZ93NaPx0aaxbFZ9gG y7owAlwhe8fW4Op7VC2M6cEqFLW+/0tBjgDWAl5/uuyTWbIkIKTF3j0XWqT9T3bPNnaB aDq+XXBO3JsmBKfDT4MFE5FUgxhnMi2fpybnO+ATYsQd9Aabsw6vLSqBtX75VqAHCmWl LU6w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=ugm3hWT1A3N52i9W+IfoPrbUq9EOkktuRlWCKlzOEmM=; b=pB/E6cpbCDCzSbSA5cUIQzARJxk5LbMMISWsUCU6ByjdX8Iw5m2sej33Sjcc/sRx06 ugRFi3vHMrou1+tli7oL2CSh4hWyV816uOWSGv6YueB1UytxStnLUhcEgoZ2nINKcAys WN72tK68reac+V6W0SaNQ25BjvCpnKZpt72KLDGzdtbjNcaHjd2qT1WlS/mthkCi+nVD S1ehR5SaRDFlpX1nd4140vECMYEbBmHytwkKAF3DZONy+2vH+gPoRgFJ7lCLDxhekhfo xN5yDXE8YRjVViZdSnvDoae4bMkkGM4MfmylLYVgImaGLnhjkc2ZUSO9fSyD15jxHGjr SUjw== X-Gm-Message-State: AIVw110Ya7BO7Z9T4WCc0JfjRwC9fKWUlQSQjrGk9q57JuRTUbPBltPS A7xF+FiodNsmS53FkfPwNC+CCPxmXw== X-Received: by 10.25.159.11 with SMTP id i11mr4744705lfe.178.1499291777138; Wed, 05 Jul 2017 14:56:17 -0700 (PDT) MIME-Version: 1.0 Sender: hallam@gmail.com Received: by 10.25.181.214 with HTTP; Wed, 5 Jul 2017 14:56:16 -0700 (PDT) In-Reply-To: <20170705210358.E58C860AA2@jupiter.mumble.net> References: <20170705210358.E58C860AA2@jupiter.mumble.net> From: Phillip Hallam-Baker Date: Wed, 5 Jul 2017 17:56:16 -0400 X-Google-Sender-Auth: 7Lq_igjoWCpITbCYV83AsiJp9GE Message-ID: To: Taylor R Campbell Cc: "cfrg@irtf.org" Content-Type: multipart/alternative; boundary="001a114109eaca867f055399117d" Archived-At: Subject: Re: [Cfrg] Side channel attack and Edwards curves... X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jul 2017 21:56:23 -0000 --001a114109eaca867f055399117d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Jul 5, 2017 at 5:03 PM, Taylor R Campbell wrote: > > Date: Wed, 5 Jul 2017 14:38:18 -0400 > > From: Phillip Hallam-Baker > > > > http://thehackernews.com/2017/07/gnupg-libgcrypt-rsa-encryption.html?m= =3D1 > > > > Just another side channel attack and not something that bothers me > writing > > reference code. But have we maybe put our eggs in the Montgomery ladder > > basket when maybe we should have gone for 'randomly split the private k= ey > > into two parts, perform two separate multiplications with each part and > add > > the result'. > > > > We can play the blinding game in Edwards or Montgomery but it is easier > in > > Edwards. > > You can always convert from Montgomery x to Edwards (x, y) and back > without losing anything and costing only one field element inversion; > see XEdDSA > for something similar. > > But there is no reason to flail around with blinding when you can just > use constant-time code for both Edwards and Montgomery arithmetic. > '=E2=80=8BJust use =E2=80=8Bfinely ground unicorn powder'. I don't think the constant time code survives modern optimizers or hardware accelerations nearly as robustly as you imagine. I would much rather go with an approach that does not depend on the vagaries of implementation. =E2=80=8BThe main reason not to do this was the Kocher patents on blinding.= But those are expiring soon.=E2=80=8B --001a114109eaca867f055399117d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Wed, Ju= l 5, 2017 at 5:03 PM, Taylor R Campbell <campbell+cfrg@mumble.net> wrote:
> Date: Wed, 5 Ju= l 2017 14:38:18 -0400
> From: Phillip Hallam-Baker <phill@hallambaker.com>
>
> http://thehackernews.= com/2017/07/gnupg-libgcrypt-rsa-encryption.html?m=3D1
>
> Just another side channel attack and not something that bothers me wri= ting
> reference code. But have we maybe put our eggs in the Montgomery ladde= r
> basket when maybe we should have gone for 'randomly split the priv= ate key
> into two parts, perform two separate multiplications with each part an= d add
> the result'.
>
> We can play the blinding game in Edwards or Montgomery but it is easie= r in
> Edwards.

You can always convert from Montgomery x to Edwards (x, y) and back<= br> without losing anything and costing only one field element inversion;
see XEdDSA <https://whispersystems.org/docs/specifications/xeddsa/>
for something similar.

But there is no reason to flail around with blinding when you can just
use constant-time code for both Edwards and Montgomery arithmetic.

'=E2=80=8BJust use =E2=80=8Bfinely ground unicorn powder'.<= /div>

I don't think the con= stant time code survives modern optimizers or hardware accelerations nearly= as robustly as you imagine. I would much rather go with an approach that d= oes not depend on the vagaries of implementation.

=E2=80=8BThe main reason = not to do this was the Kocher patents on blinding. But those are expiring s= oon.=E2=80=8B
--001a114109eaca867f055399117d-- From nobody Wed Jul 5 15:01:39 2017 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 2B29313169F for ; Wed, 5 Jul 2017 15:01:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 5yhm1hon3gQj for ; Wed, 5 Jul 2017 15:01:36 -0700 (PDT) Received: from mail-yb0-x229.google.com (mail-yb0-x229.google.com [IPv6:2607:f8b0:4002: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 EC03C131545 for ; Wed, 5 Jul 2017 15:01:32 -0700 (PDT) Received: by mail-yb0-x229.google.com with SMTP id s15so673769ybe.2 for ; Wed, 05 Jul 2017 15:01:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=/9bAixlAYrcDr8r67axy27lN4BtF0kCq40N4ryEAdQY=; b=Kj+YE90/0fanRARwua7T5HDQkssmUr/BInqj5Q8ueesJQbvSTqieJIWh2gIjCh8sTL FeYLF3aYsBaIOuxqLajsGMpLvzxM7Ahg1sWgVWl8ZCM8uxZO89ksnRlDVyD9K+sjfHRA 2bQOytleBYemxTqy4fYjo+HIV/pu0KS0ehAmzzdLuqlZ+Nt2UAeNL42sFTU007oaH8i7 caAOF1AInFCVJ5dFLUN+AWptJArYXG41Lm4Iz0WWq/GS0hlxUapKNC55f29z16JZCw4W H6eKGI3TrO/S4v6XrD4oVEhNyMZnTkocj/zT/HIf2tc2NdTyBJxLW3QQ+3XflFXsyhE3 zw5Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=/9bAixlAYrcDr8r67axy27lN4BtF0kCq40N4ryEAdQY=; b=FepL6n0Y/z3YwTfmOl2x9TXH2Dcf27fRpfNz9pTkMRgqyObZ3m+q78ej2RJVF9aF1s 6N6kpQVHZM7aSkToooEfwj+VF3FBJ/7OklSEhDCdJil+9w7ZXuKLjd8wzWy4js/+1voo wJVRhDopccwQjuS9FzKGVqB8ILojReQ2ako6rzjbC6gQYuLBw9fizUgy8XYY2qv9mWbI QuaoG1UskPu+2JIpOnflsmrGb4j55w1AWYFgXJC2cvbw+REt7sDw/G+Jwaqwjc2cq01m /k/m64ViMerVImYgFJnLozqqYgtxoFMx2N+hTN9a4XaK9iZLepJQYEl9M0aWJY+0vwcA S0LA== X-Gm-Message-State: AIVw110r4sBe0zjKpayitlstIeRc/+pDRe4s/ogS3Wm+9p5beULAi8zM 3nPEqyUGOk2zAElsa4YsbPsjb2k+yg== X-Received: by 10.37.203.139 with SMTP id b133mr224971ybg.209.1499292091718; Wed, 05 Jul 2017 15:01:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.228.134 with HTTP; Wed, 5 Jul 2017 15:01:11 -0700 (PDT) In-Reply-To: References: From: Tony Arcieri Date: Wed, 5 Jul 2017 15:01:11 -0700 Message-ID: To: Phillip Hallam-Baker Cc: "cfrg@irtf.org" Content-Type: multipart/alternative; boundary="001a114faf108abb6a0553992417" Archived-At: Subject: Re: [Cfrg] Side channel attack and Edwards curves... X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jul 2017 22:01:38 -0000 --001a114faf108abb6a0553992417 Content-Type: text/plain; charset="UTF-8" On Wed, Jul 5, 2017 at 11:38 AM, Phillip Hallam-Baker wrote: > Just another side channel attack and not something that bothers me writing > reference code. But have we maybe put our eggs in the Montgomery ladder > basket when maybe we should have gone for 'randomly split the private key > into two parts, perform two separate multiplications with each part and add > the result'. > I'm not sure why you're talking about Montgomery vs Edwards here. This is a Flush+Reload attack similar to: - "Just A Little Bit": https://eprint.iacr.org/2014/161.pdf - "Just A Little Bit More": https://eprint.iacr.org/2014/434.pdf - Cachebleed: https://eprint.iacr.org/2016/224.pdf If there was a conclusion I drew from these attacks, it's the need to include random values, as the security proofs say we should do. I will note that BoringSSL was not vulnerable to Cachebleed because they continued to use random blinding in addition to Intel's allegedly "constant time" RSA code. Though many are quick to dismiss it, random blinding seems to provide defenses against a multitude of attacks, not just cache timing but DPA as well. -- Tony Arcieri --001a114faf108abb6a0553992417 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On W= ed, Jul 5, 2017 at 11:38 AM, Phillip Hallam-Baker <phill@hallambaker.c= om> wrote:
Just another side channel attack and not something= that bothers me writing reference code. But have we maybe put our eggs in = the Montgomery ladder basket when maybe we should have gone for 'random= ly split the private key into two parts, perform two separate multiplicatio= ns with each part and add the result'.
I'm not sure why you're talking about Montgomery vs Edw= ards here. This is a Flush+Reload attack similar to:

- "Just A Little Bit":=C2=A0https://eprint.iacr.org/2014/161.pdf
- "J= ust A Little Bit More":=C2=A0https://eprint.iacr.org/2014/434.pdf

If there was a conclusion I drew= from these attacks, it's the need to include random values, as the sec= urity proofs say we should do.

I will note that Bo= ringSSL was not vulnerable to Cachebleed because they continued to use rand= om blinding in addition to Intel's allegedly "constant time" = RSA code. Though many are quick to dismiss it, random blinding seems to pro= vide defenses against a multitude of attacks, not just cache timing but DPA= as well.
=C2=A0
--
Tony Arcieri
--001a114faf108abb6a0553992417-- From nobody Wed Jul 5 16:16:31 2017 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 5187A12EA95 for ; Wed, 5 Jul 2017 16:16:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.398 X-Spam-Level: X-Spam-Status: No, score=-2.398 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, URIBL_BLOCKED=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 M6bSHDP24JLP for ; Wed, 5 Jul 2017 16:16:27 -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 EACDA129482 for ; Wed, 5 Jul 2017 16:16:26 -0700 (PDT) Received: by mail-lf0-x231.google.com with SMTP id t72so1897671lff.1 for ; Wed, 05 Jul 2017 16:16:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=Qu6YhYtzmZUfwMeH0usRnfhb17q9DlJrPMt8IRv8bKE=; b=b1kl18wST3kUholQejM+hv3s+Qu04xKmHLH99t91jB5LC1F2Vy2CtA2zqmxnqmQgZI IePexXxBbiC9HI5je0vi02SFbmzEQvWXAzjGAuLKN1OU/ZARyNRqanc2peSlH9vo+kXj i8+Cy7MfVIqcAmM57IxEZahJxphrTqiM2tHPngJleNcIZDkFl7o3ZZTCWWqMc6lYjQnT fCOGw3MIJjDvbe7nToWpDSqWuBNfogoBpPY4DlaowTmfhXU21RJ2DcTR4CG8q5qPpAWP bcuAZnuwe2Cmq5eavLIT/C4g4RS7E1XQNeyLvEdbyLYRJxzFb0fLX1JiJDLYrzP1tfgW z7Lg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=Qu6YhYtzmZUfwMeH0usRnfhb17q9DlJrPMt8IRv8bKE=; b=K09sL4kVzI7fu/hh6eCSiTQnBrD0skLmraMZX2L7SXj96j3khKaTMKMIdqbfzbW437 1nI+7msom0hWziQssy8wAiyZNrp1aqYUL4XhZPyKxRI9K+ehSTErNEKnFn01ArI+WIfj IbsgeXkp0J9ReQ/dyo+BdfOxqGZKwn/PnpUgF0LZj+tA+Wkv5hoQvLR06SnyilQWcxgI 1dEJJigWd62VRAIlNeHsNi04OcGCRFldG1Gmuowp3SQMZcifbpHefZBgjZzP+HbxfqKw QbSc/KzmG0od71OwW9RDpSmeX1AmxkriMScwvM//mgQMGlkpkj4IKzddo7EDXnal9VoK KY6Q== X-Gm-Message-State: AKS2vOxJ2fH4FG91pyhDWRIDx5gzBeOZ3TGfV3+OsseDjP5pUdwYNlaJ cPx3cyuzoE4OvTk/dF6aNK1RT0BGAg== X-Received: by 10.46.77.84 with SMTP id a81mr14490174ljb.73.1499296585116; Wed, 05 Jul 2017 16:16:25 -0700 (PDT) MIME-Version: 1.0 Sender: hallam@gmail.com Received: by 10.25.181.214 with HTTP; Wed, 5 Jul 2017 16:16:24 -0700 (PDT) In-Reply-To: References: From: Phillip Hallam-Baker Date: Wed, 5 Jul 2017 19:16:24 -0400 X-Google-Sender-Auth: _Y3NthpjCFcHaXIDh5iR3qjibJg Message-ID: To: Tony Arcieri Cc: "cfrg@irtf.org" Content-Type: multipart/alternative; boundary="94eb2c1aac365e728705539a3061" Archived-At: Subject: Re: [Cfrg] Side channel attack and Edwards curves... X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jul 2017 23:16:29 -0000 --94eb2c1aac365e728705539a3061 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Jul 5, 2017 at 6:01 PM, Tony Arcieri wrote: > On Wed, Jul 5, 2017 at 11:38 AM, Phillip Hallam-Baker < > phill@hallambaker.com> wrote: > >> Just another side channel attack and not something that bothers me >> writing reference code. But have we maybe put our eggs in the Montgomery >> ladder basket when maybe we should have gone for 'randomly split the >> private key into two parts, perform two separate multiplications with ea= ch >> part and add the result'. >> > > I'm not sure why you're talking about Montgomery vs Edwards here. This is > a Flush+Reload attack similar to: > =E2=80=8BYou can blind in either. But if you are going to blind then a lot = of the advantages of Montgomery start to collapse. because you have to do that add stage. > - "Just A Little Bit": https://eprint.iacr.org/2014/161.pdf > - "Just A Little Bit More": https://eprint.iacr.org/2014/434.pdf > - Cachebleed: https://eprint.iacr.org/2016/224.pdf > > If there was a conclusion I drew from these attacks, it's the need to > include random values, as the security proofs say we should do. > > I will note that BoringSSL was not vulnerable to Cachebleed because they > continued to use random blinding in addition to Intel's allegedly "consta= nt > time" RSA code. Though many are quick to dismiss it, random blinding seem= s > to provide defenses against a multitude of attacks, not just cache timing > but DPA as well. > > -- > Tony Arcieri > --94eb2c1aac365e728705539a3061 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Wed, Ju= l 5, 2017 at 6:01 PM, Tony Arcieri <bascule@gmail.com> wrote= :
On Wed, Jul 5, 2017 at 11:= 38 AM, Phillip Hallam-Baker <phill@hallambaker.com> wrot= e:
Just another side channel attack and not something that bothers me writi= ng reference code. But have we maybe put our eggs in the Montgomery ladder = basket when maybe we should have gone for 'randomly split the private k= ey into two parts, perform two separate multiplications with each part and = add the result'.

I&#= 39;m not sure why you're talking about Montgomery vs Edwards here. This= is a Flush+Reload attack similar to:
<= div>
= =E2=80=8BYou can blind in either. But if you are going to blind then a lot = of the advantages of Montgomery start to collapse. because you have to do t= hat add stage.
=
=C2=A0
- "Ju= st A Little Bit":=C2=A0https://eprint.iacr.org/2014/161.pdf
- "Just A Little Bit More":=C2=A0https://eprint.iacr.org/2014/434.p= df
- Cachebleed:=C2=A0https://eprint.iacr.org/2016/224.pdf

If there was a conclusion I drew from these attacks= , it's the need to include random values, as the security proofs say we= should do.

I will note that BoringSSL was not vul= nerable to Cachebleed because they continued to use random blinding in addi= tion to Intel's allegedly "constant time" RSA code. Though ma= ny are quick to dismiss it, random blinding seems to provide defenses again= st a multitude of attacks, not just cache timing but DPA as well.
=C2=A0
<= /div>--
Tony Arcieri

--94eb2c1aac365e728705539a3061-- From nobody Wed Jul 5 16:29:24 2017 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 A289212EE46 for ; Wed, 5 Jul 2017 16:29:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 tkKqgXnyrfDV for ; Wed, 5 Jul 2017 16:29:22 -0700 (PDT) Received: from mail-yb0-x231.google.com (mail-yb0-x231.google.com [IPv6:2607:f8b0:4002:c09::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 2888C12ECBB for ; Wed, 5 Jul 2017 16:29:22 -0700 (PDT) Received: by mail-yb0-x231.google.com with SMTP id f194so1129295yba.3 for ; Wed, 05 Jul 2017 16:29:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=IosnFZFmVwvsTrV1gY14keO4BhGcARh82JryrfXHcZA=; b=kcPJevIvWBC6bm0Kp7AxlzfReBcRTlJ3ILCKn8OVymeVzXcL8eZSZepOut5xMKgPYJ 3qjMV4zQlLE5/FaKXk7nnVkNxI01uwlMOQScXbmn7STN2s8oEAqjl0WJRqOF8aJvLXc4 dkZMy5XX9qHqn9WXMcXOXRKK5bYmBeOElsZ8nTQ4zj/z8Yav8TR5ZPRgEheuzCEFp3+i aEBShwqT9LZVzeX5mjws4iFoRrAwj2TUsgo2jmjh/fqAbj4FrDXQJvz07QL00ZRkdVj+ EDgu2SEflnI6QqK0np0Jd6OzqrYPzDYFWm1ZVL4M9bQE9NHwnXOV21jkuUcC7W41RpDU n8zg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=IosnFZFmVwvsTrV1gY14keO4BhGcARh82JryrfXHcZA=; b=OMKeJALY7wvdRxYDKeG7YchuTS2rwh1ZiP9/dI2do03z20GoZ+9VwjBIhVg7oCXau4 vQx4dLXkNhyaL1GJTGAVUvMIypBmra5pL0p1PUDEg0zzuP2O7xbEN1WT0u/AKKKtcEY9 kVtF6ul9+kM7wW5yP0KzspUm2NfiMQBf9vkSYCI4vn6Ks55wa/nmvK2gw2/fsknuJB25 Bf8aw889jrITTiR2JvVOr/nsZVdAtfJFhISAVBcdCeVgB/pu7u/AJN2G58/H0ZI60FOf wCKXJuz1Oct2UNmUMS/A3Who82M7swfSZhVeckS/SNUKLewqbkkzcDqdyAlLacnohqSS VuiA== X-Gm-Message-State: AIVw111WVedWl87nOg9OJdSeTs3YTuRwXQUUUjXOfwjWFwzirqJdvMCJ xxxeIme5Rs/0RFOfombOrk9Btj4Ag83c X-Received: by 10.37.221.196 with SMTP id u187mr444439ybg.173.1499297361397; Wed, 05 Jul 2017 16:29:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.228.134 with HTTP; Wed, 5 Jul 2017 16:29:00 -0700 (PDT) In-Reply-To: References: From: Tony Arcieri Date: Wed, 5 Jul 2017 16:29:00 -0700 Message-ID: To: Phillip Hallam-Baker Cc: "cfrg@irtf.org" Content-Type: multipart/alternative; boundary="001a114bc35aa3949105539a5e5d" Archived-At: Subject: Re: [Cfrg] Side channel attack and Edwards curves... X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jul 2017 23:29:23 -0000 --001a114bc35aa3949105539a5e5d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Jul 5, 2017 at 4:16 PM, Phillip Hallam-Baker wrote: > =E2=80=8BYou can blind in either. But if you are going to blind then a lo= t of the > advantages of Montgomery start to collapse. because you have to do that a= dd > stage. > Ephemeral Montgomery keys, of the sort used by TLS ECDHE, are another example of a use case which (if proper deployment procedures are followed) shouldn't be vulnerable to this sort of attack. I would agree that for long-term static keys, for this and other reasons perhaps Edwards would be preferable. --=20 Tony Arcieri --001a114bc35aa3949105539a5e5d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On W= ed, Jul 5, 2017 at 4:16 PM, Phillip Hallam-Baker <phill@hallambaker.co= m> wrote:
=
=E2=80=8BYou can blind in either. But if you= are going to blind then a lot of the advantages of Montgomery start to col= lapse. because you have to do that add stage.
=
Ephemeral Montgomery keys, of the sort used by TLS ECDHE, ar= e another example of a use case which (if proper deployment procedures are = followed) shouldn't be vulnerable to this sort of attack.
I would agree that for long-term static keys, for this and othe= r reasons perhaps Edwards would be preferable.

--=
Tony= Arcieri
--001a114bc35aa3949105539a5e5d-- From nobody Wed Jul 5 17:07:25 2017 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 3EE2312F5DB for ; Wed, 5 Jul 2017 17:07:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 csrifOQDDkfK for ; Wed, 5 Jul 2017 17:07:22 -0700 (PDT) Received: from mail-yb0-x231.google.com (mail-yb0-x231.google.com [IPv6:2607:f8b0:4002:c09::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 673C2127286 for ; Wed, 5 Jul 2017 17:07:22 -0700 (PDT) Received: by mail-yb0-x231.google.com with SMTP id e201so1327720ybb.1 for ; Wed, 05 Jul 2017 17:07:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=iO1JVqhavsssPBrtNx5VmyvdFcYp9Qmu2q5wi9VQj8A=; b=D3YB1PgxflcUI5o/xAK9k6Z1LDVfwfYv+0EGFYGknV8khKNXCFxY3QFPsqh1RY9N8J YMXQwWPpe4+zJOYDOXOb+LQCAzziMQ8XqZgNxNBeK07mJOf5FJhTXPzC48y9j66sDzAt QnEBFpU1D1jndMCnNxDS5HuuWkFKNullGxVxa6MabtvFO44bvRwg/XbhBnq+EEcslkUs tJZTX/PHUNJk3cDx+9sBXAct/8L0RbiPmbPwWIAIp8RKhkkX9e+oIrRKzFLjNKhoniP6 /zWhzoz/ESA+4+cCWglVUJPplbdemMrN9GY+gAFYEgKkPs5T87zIh5Jgo5tocz4rFzZH ePvQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=iO1JVqhavsssPBrtNx5VmyvdFcYp9Qmu2q5wi9VQj8A=; b=MZm0t0Qq/0nTsyQQt5Ck75yfKOkFjYyeu4Wxys/WP3FODXixhgtVmUmtFpLQGpCj7X UryNnP55CMWEOdShvw7K7kw74yS+jwk68x2pnWqr2nJEoqSXSOlvUrJ9bk4/9N6bAUjA 3Jbih5MG/VQDbu/oKmoP0zP/hwpMgsKJu4i7TYEyMeElZSWwzoXpana8y3YRcYSmB8sA bbLFuarS8HyL/5hgFMVPa29mwXtGetjSBM88pREpVV2NZusuk3ekFv0wVir6t1mNd2c3 t71Lo8lw12wpezDIFJDyS6B3lYVC+O/D3/sjJMyZwldUL+4zG7wLsLfpUZqoV7890qOx HxeQ== X-Gm-Message-State: AIVw112Ka+Mvb+cDol58SKJNMFw3h69N8GH8mE5U8HXEBFLpxtbFZh7t L1yRqJHYA5gdAnmBzOrr8OTeonsZIg== X-Received: by 10.37.221.196 with SMTP id u187mr529608ybg.173.1499299641595; Wed, 05 Jul 2017 17:07:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.228.134 with HTTP; Wed, 5 Jul 2017 17:07:01 -0700 (PDT) In-Reply-To: References: From: Tony Arcieri Date: Wed, 5 Jul 2017 17:07:01 -0700 Message-ID: To: Phillip Hallam-Baker Cc: "cfrg@irtf.org" Content-Type: multipart/alternative; boundary="001a114bc35a8cd73f05539ae63a" Archived-At: Subject: Re: [Cfrg] Side channel attack and Edwards curves... X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jul 2017 00:07:24 -0000 --001a114bc35a8cd73f05539ae63a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Jul 5, 2017 at 4:16 PM, Phillip Hallam-Baker wrote: > =E2=80=8BYou can blind in either. But if you are going to blind then a lo= t of the > advantages of Montgomery start to collapse. because you have to do that a= dd > stage. > What if you blinded kP with r using: r*([k r^-1]*P) which only requires inversions? --=20 Tony Arcieri --001a114bc35a8cd73f05539ae63a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On W= ed, Jul 5, 2017 at 4:16 PM, Phillip Hallam-Baker <phill@hallambaker.co= m> wrote:
=E2=80=8BYou can blind in= either. But if you are going to blind then a lot of the advantages of Mont= gomery start to collapse. because you have to do that add stage.

What if you blinded kP with r using:

=C2=A0 =C2=A0 r*([k r^-1]*P)=C2=A0
which only requires inversions?

--
Tony Arcieri
--001a114bc35a8cd73f05539ae63a-- From nobody Wed Jul 5 17:36:14 2017 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 32065129562 for ; Wed, 5 Jul 2017 17:36:13 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 GrObEqlMvmsP for ; Wed, 5 Jul 2017 17:36:11 -0700 (PDT) Received: from mail-wr0-x232.google.com (mail-wr0-x232.google.com [IPv6:2a00:1450:400c:c0c::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 D52901292F5 for ; Wed, 5 Jul 2017 17:36:10 -0700 (PDT) Received: by mail-wr0-x232.google.com with SMTP id c11so6502621wrc.3 for ; Wed, 05 Jul 2017 17:36:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-transfer-encoding; bh=1hM1JInjqew/mNCHXoeMcvvMdSTLtL3q51sGxIzYyQU=; b=GroWgnCC30qLwC+mfVQlgwywhT8wL7nzXy0f+Cc4YiVtlwKqtvBn5InufHLStqkl0x qGBa1+BH2N6kAgR4+TJ0Z9lXGeJb8j6nnIdG2Pkr1smgi5K++IAv55Z2u5/RN+tFw3Hk LJTJO/1CGlPMiAMyJInNY09HIpLXsKC6F41+0NuNUxd4JfKQWGpfWpD+7r/nO2D0BdjG xpXn5n+TPSeVPhUP8+5zjSp+QbEs/TQdRtSh73mzLy0EakaRWB8ecciqqBVwAsaHeQlW +oEKZoubWPOSeJbYbxP3e9keG6c7Xb0PtKxawN3MhZenurTKPmbpwvv3cBqyBbUW0wIC EB8Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:content-transfer-encoding; bh=1hM1JInjqew/mNCHXoeMcvvMdSTLtL3q51sGxIzYyQU=; b=Kd/RIbdA5bAc4ZeDkPFf59+/8OT7ma1wn9HVUFLCRf8tgCQ6qiuhsbtlbSXAy8vU3Z 75bjZohSXpcLa2CxYECFCyGDPdPJx9nDOyQj1xQIQkOhGnCqSkpLAhEd1mwaK2g+HVcn AYOELY8Y47utaxLMXh/VfWgtg3yi17YYb6ER6reydYTVndGtlsemGDcaJ6qGn3AYqAN7 OuxyPmzocM3tsUCXCpJ814z/4klUBWcXDu9HQDrhCMWNf1d5kuVVDngnljgWy9UQJZOs wwp9E0ob4H0Kb1hvHdaBUFWPAzwDPJjSos5N3GkZleI2bLwPbBv4ftb3uLPxYrsHbMu3 at0w== X-Gm-Message-State: AKS2vOyxMNEK2X8gKNI9yZGpxNQTi59BTVtAFDROd+7oI5J1K05/8dSi 3ZynlA5J3oY/ueBgo2JaVKhXTxaXVf4nDqI= X-Received: by 10.80.164.241 with SMTP id x46mr24041531edb.114.1499301369330; Wed, 05 Jul 2017 17:36:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.80.151.199 with HTTP; Wed, 5 Jul 2017 17:35:29 -0700 (PDT) In-Reply-To: References: From: Samuel Neves Date: Thu, 6 Jul 2017 01:35:29 +0100 Message-ID: To: "cfrg@irtf.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Cfrg] Side channel attack and Edwards curves... X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jul 2017 00:36:13 -0000 Coron's countermeasures [1, =C2=A75]---the first and third one, in particular---work well with Montgomery coordinates. [1] http://www.jscoron.fr/publications/dpaecc.pdf On Thu, Jul 6, 2017 at 1:07 AM, Tony Arcieri wrote: > On Wed, Jul 5, 2017 at 4:16 PM, Phillip Hallam-Baker > wrote: >> >> You can blind in either. But if you are going to blind then a lot of the >> advantages of Montgomery start to collapse. because you have to do that = add >> stage. > > > What if you blinded kP with r using: > > r*([k r^-1]*P) > > which only requires inversions? > > -- > Tony Arcieri > > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > https://www.irtf.org/mailman/listinfo/cfrg > From nobody Thu Jul 6 01:34:50 2017 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 D008812EB69 for ; Thu, 6 Jul 2017 01:34:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.302 X-Spam-Level: X-Spam-Status: No, score=-4.302 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.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=tugraz.at 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 5waHpx5huRXa for ; Thu, 6 Jul 2017 01:34:45 -0700 (PDT) Received: from mailrelay.tugraz.at (mailrelay.tugraz.at [129.27.2.202]) (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 95CE9126B6D for ; Thu, 6 Jul 2017 01:34:44 -0700 (PDT) Received: from [10.27.152.210] (nat-hiding.iaik.tugraz.at [129.27.152.126]) (authenticated bits=0) by mailrelay2.tugraz.at (8.14.9/8.14.9) with ESMTP id v668YboV010680 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 6 Jul 2017 10:34:38 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tugraz.at; s=mailrelay; t=1499330081; bh=Rn5nCYH4P21Vqc7j3lNlvracpkMuib+YvK6nmy4/r40=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=UrXWu2sWGgPxCwoqai/RhJTHsYYQR2N6iKURjAshOvSPTn1WyStIAt07gceg021PN 8cpHlfQrWDQXs2BgtcPfiDxIs81uADdbBMtMXPmFZJdQsjE1k1N3ffU9KIfghw6Ksh 9YlBLSxbfwaf1n+yWy6+QpmUyxhOSfCMfw4Ecx8E= To: Bryan Ford Cc: Philipp Jovanovic , cfrg@irtf.org References: <8AE29DD0-26FE-4AB6-A4A9-2BB9169BAB13@jovanovic.io> <11cc5d3f-ecf9-2fd0-825c-c8b441bd2813@tugraz.at> From: Daniel Slamanig Message-ID: <1e0faffa-370c-bf81-4973-55bfd36de510@tugraz.at> Date: Thu, 6 Jul 2017 10:34:36 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-TUG-Backscatter-control: lAa1Aa+Pa1hp/miybLoRww X-Spam-Scanner: SpamAssassin 3.003001 X-Spam-Score-relay: -1.7 X-Scanned-By: MIMEDefang 2.74 Archived-At: Subject: Re: [Cfrg] Internet-Draft: Collective Edwards-Curve Digital Signature Algorithm X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jul 2017 08:34:49 -0000 Hi Bryan, thank you very much for your detailed comments. I have to admit that I was not aware of the S&P paper before reading the draft and so I somewhat missed the big picture and simply "analyzed" the collective signing as described in the draft without specific context. You are correct in that with a chameleon hash (CH) the leader needs to be somehow trusted (it however does not seem to me that the leader has more power than producing invalid signatures by messing up with the CH - which would work in any case - but I guess one needs to evaluate that in a bit more details). Moreover, in such a CH approach the leader must be involved in the final step of the signature generation. It seems to me that this is not the case in your approach as everyone could complete the multi-signature. Clearly, the CH approach is much more susceptible to DoS attacks. Another observation regarding committing to the bitmask Z. If you do not commit to the bitmask Z, then users could cooperate in setting up their public keys, lets say A_i and A_j cooperate. Then one of them could take part in the signing, but in the end one could use the attack with the rogue keys outlined in my initial mail so that A_j can claim that he took part in the signing process although A_i actually took part. As far as I see not even using a delinearization scheme would help here. Nevertheless, it seems to me that this is not a valid attack vector when I look at the paper (but as you do not formally specify a security model for your approach in the paper this is hard to tell). Note that such an attack would even work if users have to register the public keys and prove that they know the secret key corresponding to the public key, e.g., via a (NI)ZK proof of the secret key - which I have seen is mentioned in the paper, but not discussed in the draft. Summing up, without commiting to Z in the signature, you would trivially not be able to achieve strong EUF-CMA security of the multi-signature due to the malleability, but as far as I see standard EUF-CMA should still hold (which seems sufficient for your application). Thanks and cheers, Daniel On 05.07.2017 15:11, Bryan Ford wrote: > Hi Daniel, thanks for your thoughts on the commitment-to-the-bitmask issue. > > Your proposal of using a chameleon hash, to allow the leader to “adjust” > the bit mask after the commit c has been established, is an interesting > idea. However, if I understand it correctly, if the leader holds the > trapdoor key for the chameleon hash, wouldn’t that still make the final > collective signature malleable for the leader (or for anyone the > leader’s trapdoor key might leak to)? The CoSi protocol as currently > defined is intended to ensure that the leader has no special privilege > or trust with respect to other cosigners: i.e., the leader is merely an > ordinary participant, but is simply the one who for whatever reason > decides to initiate the cosigning operation. Giving the leader special > powers - e.g., making the signature malleable to the leader but not to > others - would break this principle and need to be extremely carefully > considered I think. > > To follow up on my last message to Oleg, again I suggest reading section > IV of our CoSi paper from IEEE S&P last year > (http://dedis.cs.yale.edu/dissent/papers/witness-abs), as it discusses > several related issues, especially the potential desire to allow the > leader to complete a collective signing procedure even with only a > subset of “committed” participants remaining present in the “response” > phase. In particular, the leader can form all the individual Schnorr > commits into a Merkle tree, and make the real commit c be the root of > that Merkle tree. In this way, the leader is committing not so much to > a particular collective Schnorr commit but rather to *all possible* > Schnorr commits that can be composed from any subset of the individual > Schnorr commits within that Merkle tree. This way, if some of the > participants whose commits are present in that Merkle tree remain > available during the response phase but others drop out, the leader can > still use the commit c and form a correct and verifiable collective > signature against the particular subset of Schnorr commits from nodes > that remained available throughout the process, without restarting. > > I guess this approach does, in a slightly different way, make the > resulting collective signatures slightly malleable to the leader: from a > given set of commit-time and response-time information, the leader could > put together distinct collective signatures representing different > subsets of response-time participants. Some form of > “leader-malleability” of this kind seems unavoidably essential to > enabling the leader to complete a collective signing round in the > presence of partial failures without restarting. Perhaps the same > limited leader-malleability is more-or-less the same property your > suggestion of using chameleon hashes has, although I haven’t had a > chance to compare them deeply yet. > > But at any rate, the higher-level tradeoff here to consider is whether > it’s better to (a) enforce strict non-malleability of collective > signatures (by anyone, leader included), at the cost of O(N)-round DoS > attack vulnerability during signing due to the need to restart partially > failed rounds, or (b) provide some limited form of limited > leader-malleability in order to support restart-free operation and avoid > DoS attacks during signing, at the cost of a more complex protocol (and > perhaps slightly more “special” trust in the leader than we might like). > > Again, further thoughts on this and other topics are most welcome. > > Thanks > Bryan > >> On Jul 3, 2017, at 7:34 PM, Daniel Slamanig > > wrote: >> >> Hi Philipp, >> >> looks interesting! >> >> After looking at the protocol I also have some security concerns >> (related to what has been raised by Oleg in a previous mail). >> >> Not committing to Z as well as the actual sum of signers public keys >> A' in the computation of the hash c for the signature seems to be >> problematic. >> >> It seems to me that committing Z in the signature in plain as well as >> A' does not work given the later application of the signing procedure >> (where till the end of the protocol it is not clear who actually >> participates in the signing but c must be known at the beginning). >> >> Committing to neither of both however seems problematic as it does not >> fix the set of actual signers. >> >> This could be circumvented by allowing an honest leader to adapt the >> commitment to the final Z (and A') after it knows the signers without >> modifying the initially computed c using a chameleon hash (trapdoor >> commitment). I use P as a generator below, omit the brackets [a]P >> notation for scalar multiplication and write it from the perspective >> of the leader, i.e., the signer that initiates the protocol. >> >> The leader could choose chameleon hash parameters sk_ch=y for random y >> and pk_ch=(P,Y=yP) and add pk_ch and chameleon hash CH(Z'):=h(Z')P+u'Y >> for randomly chosen u' to the computation of c, i.e., set >> c=H(R||A||pk_ch||CH(Z')||S), where h() is a collision resistant hash >> function (this is just the standard way of constructing a chameleon >> hash from DL for arbitrary message spaces as propsed in [1]). If Z' is >> not yet known one simply sets Z' to some fixed string at the >> beginning, e.g., Z':=0. At the end of the protocol, when the leader >> knows the exact signers, it can update Z' to the final value Z and use >> sk_ch to compute a collision in the chameleon hash, i.e., such that >> CH(Z)=CH(Z') by solving h(Z')+u'y = h(Z)+uy for u. He then adds u and >> Z as well as pk_ch to the signature, i.e., sets it as (R,s,u,Z,pk_ch) >> and discards sk_ch and u'. If Z is known beforehand, one simply >> computes the chameleon hash once and does not need to compute a >> collision. Clearly, the use of a chameleon hash allows to simply adapt >> to the actual set of signers representing Z without modifying c (with >> the knowledge of sk_ch - but it does not work without the knowledge of >> sk_ch). This would resolve the issue with the unknown Z at the time of >> signing. >> >> Also, A is committed in the signature, but not the concrete A'=\sum >> A_i of keys used for computing the signature (I guess also due to the >> reason that one does not know the correct set of signers when >> computing the hash c). That can be problematic in a rogue key scenario >> in the current protocol, i.e., when not all signers need to prove >> knowledge of the secret key when they register their public keys but >> their public keys could be functions of other public keys (guess this >> could be a problem here). For instance, a malicious A^* could just >> take some key from A, say A_j, and compute and publish A^*=a^*A_j. And >> then given a collective signature (R,s,Z) where A_j participated, the >> signer can update s to s^* = s+a^*c as well as Z^* to exclude A_j and >> include A^* (as Z is not committed in the signature generation) and >> the signature (R,s^*,Z^*) will be a valid signature that certifies >> that A^* participated in signing - although he didn't. >> >> If Z is committed as proposed above and it is checked during the >> verification, then this should no longer work. One could also adapt >> the hash c=H(R||pk_ch||CH(Z'||A)||S) to include a chameleon hash to >> CH(Z||A'), where A' is the real set of signers that participated in >> the signature generation and is adapted before finalizing the >> signature when known as above. >> >> I hope that what I proposed is not just complete nonsense :) Also it >> produces quite a bit of an overhead. There may also be easier ways to >> avoid the issues. >> >> Some editorial issues: the message to be signed is sometimes called a >> satement S and later then message msg. S could be confusing as part of >> the signature is s and your semantic is that scalars are lowercase and >> points are uppercase. Also in 4.2 "Signature Generation" steps 2 and 3 >> are confusing as I guess that in the protocol all the signer compute >> their own [r_i]B values and R=\sum R_i instead of R=[r]B which would >> mean that they would send their r_i's (hope they will not do so). >> >> Also I find it somewhat confusing that the bitmask Z identifies the >> non-signers with a bit set to 1. Why not identifying the signers with >> a bit set to 1? >> >> Cheers, >> Daniel >> >> >> [1] Hugo Krawczyk, Tal Rabin: Chameleon Signatures. NDSS 2000 >> >> On 01.07.2017 23:58, Philipp Jovanovic wrote: >>> Hi CFRG, >>> Here’s a first version of an Internet-Draft on “Collective >>> Edwards-Curve Digital Signature Algorithms” based on Ed25519 and >>> Ed448: https://datatracker.ietf.org/doc/draft-ford-cfrg-cosi/ >>> We plan to give a short presentation on that topic at the next CFRG >>> meeting in Prague. >>> Any feedback is more than welcome. Thanks! >>> All the best, >>> Philipp >>> _______________________________________________ >>> Cfrg mailing list >>> Cfrg@irtf.org >>> https://www.irtf.org/mailman/listinfo/cfrg >> >> >> -- >> Dr. Daniel Slamanig >> Institute for Applied Information Processing and Communications >> Graz University of Technology >> Inffeldgasse 16a, 8010 Graz, Austria. >> Phone: +43 316 873 5509 >> http://www.iaik.tugraz.at >> >> _______________________________________________ >> Cfrg mailing list >> Cfrg@irtf.org >> https://www.irtf.org/mailman/listinfo/cfrg > -- Dr. Daniel Slamanig Institute for Applied Information Processing and Communications Graz University of Technology Inffeldgasse 16a, 8010 Graz, Austria. Phone: +43 316 873 5509 http://www.iaik.tugraz.at From nobody Fri Jul 7 00:17:49 2017 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 ADFA4131A4F for ; Fri, 7 Jul 2017 00:17:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 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, URIBL_BLOCKED=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 fzlaV2w7alab for ; Fri, 7 Jul 2017 00:17:46 -0700 (PDT) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01on0066.outbound.protection.outlook.com [104.47.0.66]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C4B84131A45 for ; Fri, 7 Jul 2017 00:17:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rhul.onmicrosoft.com; s=selector1-rhul-ac-uk; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=5/Qetdcn8TRY3GToTdKx7dY9VPZIKX+Juo6LNyP/nkc=; b=wWJ8R9CoFBc6zC02qfvqvsWe2gD3vayQILBv8cRNlw629Xf5FgJiT6yswa96Z1oQ//XuzG3hiflXH47LLjium0psaKfH/2LZ1qktDlp9q6Uiv7+Ich+punv1xK838YuRrVpuJCR67wv/0WBWRtoSqvFrDzu8TijHi0/JebkBS1Q= Received: from AM4PR0301MB1906.eurprd03.prod.outlook.com (10.168.2.156) by AM4PR0301MB1906.eurprd03.prod.outlook.com (10.168.2.156) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1220.11; Fri, 7 Jul 2017 07:17:43 +0000 Received: from AM4PR0301MB1906.eurprd03.prod.outlook.com ([fe80::482:61a:3f1b:be7a]) by AM4PR0301MB1906.eurprd03.prod.outlook.com ([fe80::482:61a:3f1b:be7a%14]) with mapi id 15.01.1220.018; Fri, 7 Jul 2017 07:17:42 +0000 From: "Paterson, Kenny" To: "Scott Fluhrer (sfluhrer)" , "cfrg@irtf.org" CC: "David McGrew (mcgrew)" Thread-Topic: [Cfrg] Request for a slot to discuss the LMS hash based signatures at Prague Thread-Index: AQHS9vEfY3kvF7g0tEaqUCtswSOC1Q== Date: Fri, 7 Jul 2017 07:17:42 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.1.161129 authentication-results: cisco.com; dkim=none (message not signed) header.d=none;cisco.com; dmarc=none action=none header.from=rhul.ac.uk; x-originating-ip: [134.219.227.30] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM4PR0301MB1906; 7:7vGVxP6iVwstGXSesEl1u/E7nMqzXbrhdCOW6gcyCKTggO4HXkGCJQ30yZzlCcCWbawKxHw3dDaVsxfSZ2QCdQkR4FY79ilxQOYYEuwGP/5EVQjNllY6fqP9icPdsfyU9aonbHVBV27O2ubdZY6Rpk2i4D33nfrs2LPHMkn6r44JgixFpa8DsfLF+tsiNs4b4gCAkca+Czldk41WPEEigVUkM4facqDtuAs/4Jl1t1BZx5B8rxeNE+ejelEeY/4jlv9jOtnFmSd/+/kwA3WpSddsav2LW3MNrvAislbLpgATg3Id2b6CDI1t2JnJ40Agn4YKe53/p84fLjn9hA1HEBqQ4jCDxCbsXQCnnv4lUk+fGoxfbgJynKT2iTszVjCF0Ni2DRt/wPpfuXc+goOrza5AMru+nB9Q3yb5WpkgboK17TRAlSAVUVD3cVWmadVmloaQ4E9iprmUw8LvVFq8AnDlk0c9B4hpQo/2KhwHUGFapDiaKMd7uUHPtVOLA/AAUUa7eQLiPXZfydSfMcI3M7Tq00yk98Nd3M5+4kOTKcBwu1ktW+ksS9v+yfRyw2jEwDgNbfdB9DryktaShY8Y+6aVtJr7BXVaLPQ+Hlg7WU0AL+Hr9WLzaofb1zZjIJnmyzyWNTHYhPgbvK3viW5ww3lpCHzNSscG6yjf9kKId8pvm0uNgUx9/R+6QtBW1zWR8QnO4CIbNuL4KhzdDK30RtRTv4wx1ByYTQQHUN6OMQl5LZvLjvNql6RlELYAdykzo49wQv8uZE8+4wvjOrZGsUg+hInxO6bhSADomkxO5Qw= x-forefront-antispam-report: SFV:SKI; SCL:-1SFV:NSPM; SFS:(10009020)(6009001)(39840400002)(39410400002)(39400400002)(39850400002)(39450400003)(24454002)(74482002)(6506006)(2906002)(6246003)(50986999)(54356999)(6512007)(305945005)(99286003)(7736002)(53936002)(38730400002)(42882006)(36756003)(66066001)(8676002)(8936002)(6306002)(6116002)(2900100001)(2501003)(3280700002)(189998001)(229853002)(478600001)(25786009)(6436002)(3660700001)(72206003)(3846002)(53546010)(102836003)(14454004)(81166006)(83506001)(6486002)(86362001)(4001350100001)(5660300001)(5250100002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM4PR0301MB1906; H:AM4PR0301MB1906.eurprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; x-ms-office365-filtering-correlation-id: 7204c42a-c2ac-4036-2ff4-08d4c508421c x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:AM4PR0301MB1906; x-ms-traffictypediagnostic: AM4PR0301MB1906: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(120809045254105)(166708455590820)(236129657087228)(192374486261705)(48057245064654)(95692535739014)(209349559609743); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(5005006)(2017060910059)(8121501046)(10201501046)(100000703101)(100105400095)(93006095)(93001095)(3002001)(6041248)(20161123562025)(20161123555025)(201703131423075)(201702281528075)(201702281529075)(201703061421075)(201703061406153)(20161123564025)(20161123558100)(20161123560025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:AM4PR0301MB1906; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:AM4PR0301MB1906; x-forefront-prvs: 0361212EA8 spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <50F9CF0F67210D4083ECBA37C553167F@eurprd03.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: rhul.ac.uk X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Jul 2017 07:17:42.5167 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2efd699a-1922-4e69-b601-108008d28a2e X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR0301MB1906 Archived-At: Subject: Re: [Cfrg] Request for a slot to discuss the LMS hash based signatures at Prague X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jul 2017 07:17:49 -0000 SGkgU2NvdHQsDQoNCk5vdGVkLCBhbmQgd2Ugd2lsbCB0cnkgdG8gZmluZCB0aW1lIGZvciB5b3Ug YXMgd2UgcHJlcGFyZSB0aGUgYWdlbmRhIChidXQNCnBsZWFzZSBkbyBub3RlIHRoYXQgeW91ciBy ZXF1ZXN0IGNhbWUgYWZ0ZXIgdGhlIGRlYWRsaW5lIGZvciByZXF1ZXN0cykuDQoNCkJlc3Qgd2lz aGVzLA0KDQpLZW5ueSANCg0KT24gMDUvMDcvMjAxNyAxOToyMywgIkNmcmcgb24gYmVoYWxmIG9m IFNjb3R0IEZsdWhyZXIgKHNmbHVocmVyKSINCjxjZnJnLWJvdW5jZXNAaXJ0Zi5vcmcgb24gYmVo YWxmIG9mIHNmbHVocmVyQGNpc2NvLmNvbT4gd3JvdGU6DQoNCj5IaSwNCj4gDQo+ICAgSSB3b3Vs ZCBhc2sgdG8gcmVxdWVzdCBhIHNsb3QgdG8gZGlzY3VzcyB0aGUgTE1TIGhhc2ggYmFzZWQgc2ln bmF0dXJlcw0KPmF0IHRoZSBDUkZHIGluLXBlcnNvbiBtZWV0aW5nIGF0IFByYWd1ZS4gIEkgd2ls bCBub3QgYmUgdGhlcmUgaW4gcGVyc29uLA0KPmhvd2V2ZXIgRGF2aWQgTWNHcmV3IHdpbGwgYmUg KGFuZCBJ4oCZbGwgYmUgYXR0ZW5kaW5nIHZpcnR1YWxseSkuDQo+IA0KPiAgIFdlIGhhdmU6DQo+ IA0KPi0gICAgICAgICANCj5UaGUgbGF0ZXN0IHZlcnNpb24gb2YgdGhlIExNUyBkcmFmdDoNCj5o dHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1tY2dyZXctaGFzaC1zaWdzLw0K PjxodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1tY2dyZXctaGFzaC1zaWdz Lz4NCj4tICAgICAgICAgDQo+QSBwcm9vZiBvZiBzZWN1cml0eSAoaW4gdGhlIFJhbmRvbSBPcmFj bGUgbW9kZWwsIHdoZXJlIHRoZSBoYXNoDQo+Y29tcHJlc3Npb24gZnVuY3Rpb24gaXMgY29uc2lk ZXJlZCB0aGUgcmFuZG9tIE9yYWNsZSk6DQo+aHR0cDovL2VwcmludC5pYWNyLm9yZy8yMDE3LzU1 My5wZGYNCj4tICAgICAgICAgDQo+QSBjb21wYXJpc29uIG9mIHRoaXMgcHJvcG9zYWwgd2l0aCB0 aGUgWE1TUyBwcm9wb3NhbCB1bmRlciBjb25zaWRlcmF0aW9uDQo+YnkgdGhlIENSRkc6DQo+aHR0 cDovL2VwcmludC5pYWNyLm9yZy8yMDE3LzM0OS5wZGYNCj4tICAgICAgICAgDQo+QSBwcmFjdGlj YWwgaW1wbGVtZW50YXRpb24gb2YgdGhpcyBkcmFmdDoNCj5odHRwczovL2dpdGh1Yi5jb20vY2lz Y28vaGFzaC1zaWdzIDxodHRwczovL2dpdGh1Yi5jb20vY2lzY28vaGFzaC1zaWdzPg0KPiANCj5U aGFuayB5b3UhDQo+DQoNCg== From nobody Sun Jul 9 09:43:31 2017 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 ABF32129B8B for ; Sun, 9 Jul 2017 09:43:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 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_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, URIBL_BLOCKED=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 SvG_0u0ef6RB for ; Sun, 9 Jul 2017 09:43:27 -0700 (PDT) Received: from EUR03-AM5-obe.outbound.protection.outlook.com (mail-eopbgr30061.outbound.protection.outlook.com [40.107.3.61]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 44D24129B19 for ; Sun, 9 Jul 2017 09:43:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rhul.onmicrosoft.com; s=selector1-rhul-ac-uk; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=uTTEF4GuQe1ezurxCb6RXFV5gDFedH3exw76DeytYtw=; b=Q/WjrGsryY1XRM2qWhQae1yalaH7u1PKpwhSImT/s5uVQQdeIGUaXWpXxJbliBAoIQThhiOUtBEIRmKwa43UwdJ01A5J6izZbW5UqUwxDm59BY9UpLEzAxFY7EiRxJdgdvmNrUEzGVa+SL5QDasNhwkEAWETiNNq+LylKqKD9Eg= Received: from AM4PR0301MB1906.eurprd03.prod.outlook.com (10.168.2.156) by AM4PR0301MB1907.eurprd03.prod.outlook.com (10.168.3.7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1240.13; Sun, 9 Jul 2017 16:43:24 +0000 Received: from AM4PR0301MB1906.eurprd03.prod.outlook.com ([fe80::482:61a:3f1b:be7a]) by AM4PR0301MB1906.eurprd03.prod.outlook.com ([fe80::482:61a:3f1b:be7a%14]) with mapi id 15.01.1240.013; Sun, 9 Jul 2017 16:43:22 +0000 From: "Paterson, Kenny" To: "cfrg@irtf.org" Thread-Topic: Preliminary agenda for CFRG meeting at IETF99 Thread-Index: AQHS+NJ6ey1CJFJrdUOmRvOoeL1R6Q== Date: Sun, 9 Jul 2017 16:43:22 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.1.161129 authentication-results: irtf.org; dkim=none (message not signed) header.d=none;irtf.org; dmarc=none action=none header.from=rhul.ac.uk; x-originating-ip: [78.146.77.209] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM4PR0301MB1907; 7:Pfod3XdOiIssnaz6K+gFTzzGsgJaKTaXF4wKlC/oEP+W3e+MkggxAhnFTtlSzZgUcH8twKwyD34VPpjo4osQBaQysQbeCRXBlztxn1pv3KV2j/h10j5UT/4H/RKasLOVLOqZdOY5Gt/P83lyJfR/++qSMCXPGNgyo2o/6iNgUsU8KLEttLJLct+9/VzSYNBtNKzeYUPHJ0VOxVw8SUrklVLIganoCl5lQxQ6OCce2JZCmisaLffVMNNP4IRQ7S1TJtOWf1JDyi/lvH7r7dOq1MQ4a17XP4GY+JSDjssI5SH/+SShFMuyUlri6kQz/vo+cpW0684oaGP1KqTDHNeIYpTnrdXZgKjwoX/nmPH9YEHrr3DzlPE6ToaSADUSo/LuwdJEQJmkKWkAhgmDGdDddy4iku6KFBYHT1SbetZZXBhzcEBRLsA135oWUJZZbBUR+tjyRpt0bCWoegfRdr6UYLpxJIWcP5170aCLh4y3Ky/5aaetJqus1O9eEwVd7ICEcjxzbYS6z4gi/12j9NDCBQfs/q1hm5mkFSJHjU7TKzzz9HO3wrXfZ1TE7ICa+Ko53+90SfxHLQ3hYJ1k+XkR0RvXthODXKmw6qAo4yhxr+G/mAmRPuz02GzhFozwCIsfnonjvL6SrTNV45pW4UOCCi6/RNROOT1qhZIGlRbNozHx+BcOqjkJGDHSQD2gWf0Z8ldnwzyweTk5ZBegDVyvSAgnPjBTTcnn7+hFzsTsavhKE1oxERs8qB7Juj4z2f0SsriE5XWfw8aE8wchRfDm6k7Cpkg70NyCX6CPtc1AadI= x-forefront-antispam-report: SFV:SKI; SCL:-1SFV:NSPM; SFS:(10009020)(6009001)(39840400002)(39410400002)(39400400002)(39450400003)(6916009)(6436002)(3846002)(2501003)(2351001)(42882006)(478600001)(6116002)(102836003)(110136004)(38730400002)(72206003)(6306002)(6512007)(6486002)(6506006)(5250100002)(53936002)(966005)(413944005)(5640700003)(99286003)(36756003)(5660300001)(4001350100001)(3660700001)(54356999)(50986999)(83506001)(305945005)(3280700002)(74482002)(2900100001)(66066001)(14454004)(189998001)(7736002)(86362001)(1730700003)(8936002)(81166006)(25786009)(2906002)(8676002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM4PR0301MB1907; H:AM4PR0301MB1906.eurprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; x-ms-office365-filtering-correlation-id: b9a50fe7-b3cd-446e-194d-08d4c6e99cfc x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:AM4PR0301MB1907; x-ms-traffictypediagnostic: AM4PR0301MB1907: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(120809045254105)(166708455590820)(236129657087228)(48057245064654)(92977632026198)(167848164394848); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(5005006)(8121501046)(2017060910075)(3002001)(10201501046)(100000703101)(100105400095)(93006095)(93001095)(6041248)(20161123558100)(20161123564025)(20161123555025)(201703131423075)(201702281528075)(201702281529075)(201703061421075)(201703061406153)(20161123562025)(20161123560025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:AM4PR0301MB1907; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:AM4PR0301MB1907; x-forefront-prvs: 03630A6A4A spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM 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: 09 Jul 2017 16:43:22.8435 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2efd699a-1922-4e69-b601-108008d28a2e X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR0301MB1907 Archived-At: Subject: [Cfrg] Preliminary agenda for CFRG meeting at IETF99 X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Jul 2017 16:43:30 -0000 RGVhciBDRlJHLA0KDQpCZWxvdyBpcyBhIHByZWxpbWluYXJ5IGFnZW5kYSBmb3IgdGhlIGZvcnRo Y29taW5nIENGUkcgbWVldGluZyBhdCBJRVRGOTkNCmluIFByYWd1ZSBpbiBhIGNvdXBsZSBvZiB3 ZWVrcy4NCg0KQ29tbWVudHMvY29ycmVjdGlvbnMgYXJlIHdlbGNvbWUuIE5vdGUgdGhhdCBhbG1v c3QgZXZlcnlvbmUncyB0aW1lIHdhcw0Kc3F1ZWV6ZWQgYmVjYXVzZSBvZiBoaWdoIGRlbWFuZCBm b3Igc3BlYWtpbmcgc2xvdHMuDQoNCklmIHlvdSBhcmUgYSBzcGVha2VyIChvciBzb21lb25lIGlz IHNwZWFraW5nIG9uIHlvdXIgYmVoYWxmKSwgcGxlYXNlIGdldA0Kc2xpZGVzIHRvIG1lIGJ5IGVu ZCBvZiB0aGUgZGF5IHRoaXMgY29taW5nIFRodXJzZGF5LiBUaGlzIGlzIGEgaGFyZA0KZGVhZGxp bmUuDQoNCkJlc3QgcmVnYXJkcywNCg0KS2VubnkgKGZvciB0aGUgY2hhaXJzKQ0KDQotLS0NCg0K Q0ZSRyBBZ2VuZGENCklFVEYgOTkgUHJhZ3VlLCBDemVjaCBSZXB1YmxpYw0KSnVseSAxOCwgMjAx NyAgMTU6NTAgLSAxNzo1MCAgQ29uZ3Jlc3MgSGFsbCBJLA0KDQpDaGFpcnM6ICBBbGV4ZXkgTWVs bmlrb3YgYW5kIEtlbm55IFBhdGVyc29uDQoNCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcv ZG9jL2FnZW5kYS05OS1jZnJnLw0KDQoNCioqKiBQUkVMSU1JTkFSWSAqKioNCg0KMTU6NTAgQ0ZS RyBzdGF0dXMgdXBkYXRlIGZyb20gQ0ZSRyBjaGFpcnMNCiAgICAgICg1IG1pbnM7IEtlbm55IFBh dGVyc29uKQ0KDQoxNTo1NSBSZS1rZXlpbmcgTWVjaGFuaXNtcyBmb3IgU3ltbWV0cmljIEtleXMN CiAgICAgICgxMCArIDEwOyBTdGFuaXNsYXYgVi4gU215c2hseWFldikNCiAgICAgIGh0dHBzOi8v ZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlydGYtY2ZyZy1yZS1rZXlpbmcvKQ0KDQox NjoxNSBWZXJpZmlhYmxlIFJhbmRvbSBGdW5jdGlvbnMNCiAgICAgICgxMCArIDEwOyBTaGFyb24g R29sZGJlcmcpDQogICAgICBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtZ29sZGJl LXZyZi0wMQ0KDQoxNjozNSBDb2xsZWN0aXZlIEVkd2FyZHMtQ3VydmUgRGlnaXRhbCBTaWduYXR1 cmUgQWxnb3JpdGhtDQogICAgICAoMTAgKyAxMDsgQnJ5YW4gRm9yZCkNCiAgICAgIGh0dHBzOi8v ZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWZvcmQtY2ZyZy1jb3NpLw0KDQoxNjo1NSBU aGUgVHJhbnNpdGlvbiBmcm9tIENsYXNzaWNhbCB0byBQb3N0LVF1YW50dW0gQ3J5cHRvZ3JhcGh5 DQogICAgICAoNSArIDU7IEtlbm55IFBhdGVyc29uIGZvciBQYXVsIEhvZmZtYW4pDQogICAgICBo dHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaG9mZm1hbi1jMnBxLTAxDQoNCjE3OjA1 IEhhc2gtQmFzZWQgU2lnbmF0dXJlcw0KICAgICAgKDEwICsgNTsgRGF2aWQgTWNHcmV3KQ0KaHR0 cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtbWNncmV3LWhhc2gtc2lncy8NCiAg ICAgIFNlZSBhbHNvOg0KaHR0cDovL2VwcmludC5pYWNyLm9yZy8yMDE3LzM0OS5wZGY7ICBodHRw Oi8vZXByaW50LmlhY3Iub3JnLzIwMTcvMzQ5LnBkZjsNCmh0dHBzOi8vZ2l0aHViLmNvbS9jaXNj by9oYXNoLXNpZ3MNCg0KMTc6MjAgS2FuZ2Fyb29Ud2VsdmUNCiAgICAgICgxMCArIDU7IFF1eW5o IERhbmcgZm9yIEJlbm8idCBWaWd1aWVyKQ0KICAgICAgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9o dG1sL2RyYWZ0LXZpZ3VpZXIta2FuZ2Fyb290d2VsdmUtMDANCg0KMTc6MzUgVHdvIGN1cnZlIHBy b3Bvc2Fscw0KICAgICAgKDEwICsgNTsgQW5kcmV3IEFsbGVuIGZvciBEYW4gQnJvd24pDQoNCjE3 OjUwIENsb3NlIG9mIENGUkcgbWVldGluZw0KDQo= From nobody Tue Jul 11 03:29:14 2017 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 E3AE2127180 for ; Tue, 11 Jul 2017 03:29:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 p4C7kz7BKTJe for ; Tue, 11 Jul 2017 03:29:09 -0700 (PDT) Received: from mail-wr0-x22b.google.com (mail-wr0-x22b.google.com [IPv6:2a00:1450:400c:c0c::22b]) (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 37931126BF3 for ; Tue, 11 Jul 2017 03:29:09 -0700 (PDT) Received: by mail-wr0-x22b.google.com with SMTP id r103so177163248wrb.0 for ; Tue, 11 Jul 2017 03:29:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=hLuXhCzKolEQJ9MHcVVkQgaMYT7HDH+7lhH2CnDPDXw=; b=Q52+X0MO2fICPPkLAm4Ykty2kjFHZEqMoJnQw4yaHtDO3NbKLORwtAnYbXxHEsWIHU 9GfS/xhs+//ESWJENX5+dCYnN44FUmuJx2hEeNxXm4kvp7hNQgs9TiI1JOL5C7cjuAcj pkwVPLs19t4QLBZhrpxOeUcHNFEqqVjzwgeUjxPCzYU5KIrF/fQT+wQRCni0abABeaPR +n5su7O6HIAVRVcDqaaoiSjx92FKJbgg8rYu69YhTbvyu1zoU5LCMNzcPEQZjAkekvew wUNSUWwCjoS3t8960tX2t7Hu4QESNSdZiK1t58uEZpan18lZM2PLSVbk//4v4R36ljmT /Z2A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=hLuXhCzKolEQJ9MHcVVkQgaMYT7HDH+7lhH2CnDPDXw=; b=KGcNotF9XjZq7SI6xciwDtLGJgOzAv3KkROPXCHgRFbCqV26Us3f4nDdsI62DlVrgG w8ARAQ/ryGh8THFUNWu+42hUssUT2AHD6J84y4GILXk9E+Gb++oiWct7rcHYpzXva9MW /MoOPLyvAuQz8GHnXWZXJDU4Ird8ZCbzp51BjxNx4+LcktPCXWxm1oXO8Y0KFHDBNCGN 7xIo9mmLG2s/wzT+RAtauBeHsyJnoiuR3eOyGCEedXNKnl5sJlHkSITf0dlQ8KDyJ8I7 4vgPuPhxw8qQNV/G9j11ZDy2k3AUnGUhAk/6ovHFhKkX7lOR+DrUPG3tY2SiPTDG/cQ+ MzIw== X-Gm-Message-State: AIVw111TIxwq0XXUAS7sY2mX9Ypc5EUuNTU71qYlrCBVt/mCMv62/CaC CAHkILvwcZB9mXpw24g= X-Received: by 10.80.183.98 with SMTP id g89mr2002621ede.105.1499768947538; Tue, 11 Jul 2017 03:29:07 -0700 (PDT) Received: from [172.20.10.2] (78.227.197.178.dynamic.wless.zhbmb00p-cgnat.res.cust.swisscom.ch. [178.197.227.78]) by smtp.gmail.com with ESMTPSA id h18sm777749eda.46.2017.07.11.03.29.04 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 11 Jul 2017 03:29:04 -0700 (PDT) From: Bryan Ford Message-Id: <870B4583-2FF4-4B5F-A19C-5D39FA81559B@gmail.com> Content-Type: multipart/signed; boundary="Apple-Mail=_4D1010BB-2068-406E-BB75-7089D31ED14A"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Tue, 11 Jul 2017 12:29:02 +0200 In-Reply-To: <1e0faffa-370c-bf81-4973-55bfd36de510@tugraz.at> Cc: Philipp Jovanovic , cfrg@irtf.org To: Daniel Slamanig References: <8AE29DD0-26FE-4AB6-A4A9-2BB9169BAB13@jovanovic.io> <11cc5d3f-ecf9-2fd0-825c-c8b441bd2813@tugraz.at> <1e0faffa-370c-bf81-4973-55bfd36de510@tugraz.at> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Cfrg] Internet-Draft: Collective Edwards-Curve Digital Signature Algorithm X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jul 2017 10:29:13 -0000 --Apple-Mail=_4D1010BB-2068-406E-BB75-7089D31ED14A Content-Type: multipart/alternative; boundary="Apple-Mail=_7B1AD11C-2390-4290-A1A2-EAFEAE3244C8" --Apple-Mail=_7B1AD11C-2390-4290-A1A2-EAFEAE3244C8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Daniel, sorry about the slow followup=E2=80=A6 > On Jul 6, 2017, at 10:34 AM, Daniel Slamanig = wrote: > Another observation regarding committing to the bitmask Z. If you do = not commit to the bitmask Z, then users could cooperate in setting up = their public keys, lets say A_i and A_j cooperate. Then one of them = could take part in the signing, but in the end one could use the attack = with the rogue keys outlined in my initial mail so that A_j can claim = that he took part in the signing process although A_i actually took = part. As far as I see not even using a delinearization scheme would help = here. Nevertheless, it seems to me that this is not a valid attack = vector when I look at the paper (but as you do not formally specify a = security model for your approach in the paper this is hard to tell). Correct - when two users A_i and A_j collude in such fashion, we just = count both of them as =E2=80=9Cmalicious=E2=80=9D in our threat model. = In practice, if two nodes want to collude in this way, there are easier = attacks that have nothing to do with collective signing but would work = equally well with the =E2=80=9Cbase-case=E2=80=9D approach of collecting = a bunch of individual signatures. For example, A_i simply uses A_j=E2=80=99= s private key (which A_j shares with A_i because they=E2=80=99re = colluding) to pretend to be A_j and sign on A_j=E2=80=99s behalf, = individually or collectively. Or vice versa. > Note that such an attack would even work if users have to register the = public keys and prove that they know the secret key corresponding to the = public key, e.g., via a (NI)ZK proof of the secret key - which I have = seen is mentioned in the paper, but not discussed in the draft. Summing = up, without commiting to Z in the signature, you would trivially not be = able to achieve strong EUF-CMA security of the multi-signature due to = the malleability, but as far as I see standard EUF-CMA should still hold = (which seems sufficient for your application). Agreed. The critical question is then whether to prioritize strict = non-malleability, or to allow just enough malleability to allow for = stronger protection against DoS attacks. The tradeoff is subtle and the = ideal balance is not clear to me at least. Cheers Bryan > Thanks and cheers, > Daniel >=20 > On 05.07.2017 15:11, Bryan Ford wrote: >> Hi Daniel, thanks for your thoughts on the commitment-to-the-bitmask = issue. >> Your proposal of using a chameleon hash, to allow the leader to = =E2=80=9Cadjust=E2=80=9D the bit mask after the commit c has been = established, is an interesting idea. However, if I understand it = correctly, if the leader holds the trapdoor key for the chameleon hash, = wouldn=E2=80=99t that still make the final collective signature = malleable for the leader (or for anyone the leader=E2=80=99s trapdoor = key might leak to)? The CoSi protocol as currently defined is intended = to ensure that the leader has no special privilege or trust with respect = to other cosigners: i.e., the leader is merely an ordinary participant, = but is simply the one who for whatever reason decides to initiate the = cosigning operation. Giving the leader special powers - e.g., making = the signature malleable to the leader but not to others - would break = this principle and need to be extremely carefully considered I think. >> To follow up on my last message to Oleg, again I suggest reading = section IV of our CoSi paper from IEEE S&P last year = (http://dedis.cs.yale.edu/dissent/papers/witness-abs), as it discusses = several related issues, especially the potential desire to allow the = leader to complete a collective signing procedure even with only a = subset of =E2=80=9Ccommitted=E2=80=9D participants remaining present in = the =E2=80=9Cresponse=E2=80=9D phase. In particular, the leader can = form all the individual Schnorr commits into a Merkle tree, and make the = real commit c be the root of that Merkle tree. In this way, the leader = is committing not so much to a particular collective Schnorr commit but = rather to *all possible* Schnorr commits that can be composed from any = subset of the individual Schnorr commits within that Merkle tree. This = way, if some of the participants whose commits are present in that = Merkle tree remain available during the response phase but others drop = out, the leader can still use the commit c and form a correct and = verifiable collective signature against the particular subset of Schnorr = commits from nodes that remained available throughout the process, = without restarting. >> I guess this approach does, in a slightly different way, make the = resulting collective signatures slightly malleable to the leader: from a = given set of commit-time and response-time information, the leader could = put together distinct collective signatures representing different = subsets of response-time participants. Some form of = =E2=80=9Cleader-malleability=E2=80=9D of this kind seems unavoidably = essential to enabling the leader to complete a collective signing round = in the presence of partial failures without restarting. Perhaps the = same limited leader-malleability is more-or-less the same property your = suggestion of using chameleon hashes has, although I haven=E2=80=99t had = a chance to compare them deeply yet. >> But at any rate, the higher-level tradeoff here to consider is = whether it=E2=80=99s better to (a) enforce strict non-malleability of = collective signatures (by anyone, leader included), at the cost of = O(N)-round DoS attack vulnerability during signing due to the need to = restart partially failed rounds, or (b) provide some limited form of = limited leader-malleability in order to support restart-free operation = and avoid DoS attacks during signing, at the cost of a more complex = protocol (and perhaps slightly more =E2=80=9Cspecial=E2=80=9D trust in = the leader than we might like). >> Again, further thoughts on this and other topics are most welcome. >> Thanks >> Bryan >>> On Jul 3, 2017, at 7:34 PM, Daniel Slamanig = = >> = wrote: >>>=20 >>> Hi Philipp, >>>=20 >>> looks interesting! >>>=20 >>> After looking at the protocol I also have some security concerns = (related to what has been raised by Oleg in a previous mail). >>>=20 >>> Not committing to Z as well as the actual sum of signers public keys = A' in the computation of the hash c for the signature seems to be = problematic. >>>=20 >>> It seems to me that committing Z in the signature in plain as well = as A' does not work given the later application of the signing procedure = (where till the end of the protocol it is not clear who actually = participates in the signing but c must be known at the beginning). >>>=20 >>> Committing to neither of both however seems problematic as it does = not fix the set of actual signers. >>>=20 >>> This could be circumvented by allowing an honest leader to adapt the = commitment to the final Z (and A') after it knows the signers without = modifying the initially computed c using a chameleon hash (trapdoor = commitment). I use P as a generator below, omit the brackets [a]P = notation for scalar multiplication and write it from the perspective of = the leader, i.e., the signer that initiates the protocol. >>>=20 >>> The leader could choose chameleon hash parameters sk_ch=3Dy for = random y and pk_ch=3D(P,Y=3DyP) and add pk_ch and chameleon hash = CH(Z'):=3Dh(Z')P+u'Y for randomly chosen u' to the computation of c, = i.e., set c=3DH(R||A||pk_ch||CH(Z')||S), where h() is a collision = resistant hash function (this is just the standard way of constructing a = chameleon hash from DL for arbitrary message spaces as propsed in [1]). = If Z' is not yet known one simply sets Z' to some fixed string at the = beginning, e.g., Z':=3D0. At the end of the protocol, when the leader = knows the exact signers, it can update Z' to the final value Z and use = sk_ch to compute a collision in the chameleon hash, i.e., such that = CH(Z)=3DCH(Z') by solving h(Z')+u'y =3D h(Z)+uy for u. He then adds u = and Z as well as pk_ch to the signature, i.e., sets it as = (R,s,u,Z,pk_ch) and discards sk_ch and u'. If Z is known beforehand, one = simply computes the chameleon hash once and does not need to compute a = collision. Clearly, the use of a chameleon hash allows to simply adapt = to the actual set of signers representing Z without modifying c (with = the knowledge of sk_ch - but it does not work without the knowledge of = sk_ch). This would resolve the issue with the unknown Z at the time of = signing. >>>=20 >>> Also, A is committed in the signature, but not the concrete A'=3D\sum = A_i of keys used for computing the signature (I guess also due to the = reason that one does not know the correct set of signers when computing = the hash c). That can be problematic in a rogue key scenario in the = current protocol, i.e., when not all signers need to prove knowledge of = the secret key when they register their public keys but their public = keys could be functions of other public keys (guess this could be a = problem here). For instance, a malicious A^* could just take some key = from A, say A_j, and compute and publish A^*=3Da^*A_j. And then given a = collective signature (R,s,Z) where A_j participated, the signer can = update s to s^* =3D s+a^*c as well as Z^* to exclude A_j and include A^* = (as Z is not committed in the signature generation) and the signature = (R,s^*,Z^*) will be a valid signature that certifies that A^* = participated in signing - although he didn't. >>>=20 >>> If Z is committed as proposed above and it is checked during the = verification, then this should no longer work. One could also adapt the = hash c=3DH(R||pk_ch||CH(Z'||A)||S) to include a chameleon hash to = CH(Z||A'), where A' is the real set of signers that participated in the = signature generation and is adapted before finalizing the signature when = known as above. >>>=20 >>> I hope that what I proposed is not just complete nonsense :) Also it = produces quite a bit of an overhead. There may also be easier ways to = avoid the issues. >>>=20 >>> Some editorial issues: the message to be signed is sometimes called = a satement S and later then message msg. S could be confusing as part of = the signature is s and your semantic is that scalars are lowercase and = points are uppercase. Also in 4.2 "Signature Generation" steps 2 and 3 = are confusing as I guess that in the protocol all the signer compute = their own [r_i]B values and R=3D\sum R_i instead of R=3D[r]B which would = mean that they would send their r_i's (hope they will not do so). >>>=20 >>> Also I find it somewhat confusing that the bitmask Z identifies the = non-signers with a bit set to 1. Why not identifying the signers with a = bit set to 1? >>>=20 >>> Cheers, >>> Daniel >>>=20 >>>=20 >>> [1] Hugo Krawczyk, Tal Rabin: Chameleon Signatures. NDSS 2000 >>>=20 >>> On 01.07.2017 23:58, Philipp Jovanovic wrote: >>>> Hi CFRG, >>>> Here=E2=80=99s a first version of an Internet-Draft on = =E2=80=9CCollective Edwards-Curve Digital Signature Algorithms=E2=80=9D = based on Ed25519 and Ed448: = https://datatracker.ietf.org/doc/draft-ford-cfrg-cosi/ = >>>> We plan to give a short presentation on that topic at the next CFRG = meeting in Prague. >>>> Any feedback is more than welcome. Thanks! >>>> All the best, >>>> Philipp >>>> _______________________________________________ >>>> Cfrg mailing list >>>> Cfrg@irtf.org > >>>> https://www.irtf.org/mailman/listinfo/cfrg = >>>=20 >>>=20 >>> -- >>> Dr. Daniel Slamanig >>> Institute for Applied Information Processing and Communications >>> Graz University of Technology >>> Inffeldgasse 16a, 8010 Graz, Austria. >>> Phone: +43 316 873 5509 >>> http://www.iaik.tugraz.at >>>=20 >>> _______________________________________________ >>> Cfrg mailing list >>> Cfrg@irtf.org >>> https://www.irtf.org/mailman/listinfo/cfrg = >=20 >=20 > -- > Dr. Daniel Slamanig > Institute for Applied Information Processing and Communications > Graz University of Technology > Inffeldgasse 16a, 8010 Graz, Austria. > Phone: +43 316 873 5509 > http://www.iaik.tugraz.at --Apple-Mail=_7B1AD11C-2390-4290-A1A2-EAFEAE3244C8 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi Daniel, sorry about the slow followup=E2=80=A6

On Jul 6, 2017, at 10:34 AM, = Daniel Slamanig <daniel.slamanig@tugraz.at> wrote:
Another observation regarding committing to the = bitmask Z. If you do not commit to the bitmask Z, then users could = cooperate in setting up their public keys, lets say A_i and A_j = cooperate. Then one of them could take part in the signing, but in the = end one could use the attack with the rogue keys outlined in my initial = mail so that A_j can claim that he took part in the signing process = although A_i actually took part. As far as I see not even using a = delinearization scheme would help here. Nevertheless, it seems to me = that this is not a valid attack vector when I look at the paper (but as = you do not formally specify a security model for your approach in the = paper this is hard to tell).

Correct - when two users A_i and A_j collude in = such fashion, we just count both of them as =E2=80=9Cmalicious=E2=80=9D = in our threat model.  In practice, if two nodes want to collude in = this way, there are easier attacks that have nothing to do with = collective signing but would work equally well with the =E2=80=9Cbase-case= =E2=80=9D approach of collecting a bunch of individual signatures. =  For example, A_i simply uses A_j=E2=80=99s private key (which A_j = shares with A_i because they=E2=80=99re colluding) to pretend to be A_j = and sign on A_j=E2=80=99s behalf, individually or collectively.  Or = vice versa.

Note that such an attack would even work if = users have to register the public keys and prove that they know the = secret key corresponding to the public key, e.g., via a (NI)ZK proof of = the secret key - which I have seen is mentioned in the paper, but not = discussed in the draft. Summing up, without commiting to Z in the = signature, you would trivially not be able to achieve strong EUF-CMA = security of the multi-signature due to the malleability, but as far as I = see standard EUF-CMA should still hold (which seems sufficient for your = application).

Agreed.  The critical question is then = whether to prioritize strict non-malleability, or to allow just enough = malleability to allow for stronger protection against DoS attacks. =  The tradeoff is subtle and the ideal balance is not clear to me at = least.

Cheers
Bryan
Thanks and cheers,
Daniel

On 05.07.2017 15:11, Bryan Ford wrote:
Hi Daniel, thanks for your = thoughts on the commitment-to-the-bitmask issue.
Your = proposal of using a chameleon hash, to allow the leader to =E2=80=9Cadjust= =E2=80=9D the bit mask after the commit c has been established, is an = interesting idea. However, if I understand it correctly, if the leader = holds the trapdoor key for the chameleon hash, wouldn=E2=80=99t that = still make the final collective signature malleable for the leader (or = for anyone the leader=E2=80=99s trapdoor key might leak to)?  The = CoSi protocol as currently defined is intended to ensure that the leader = has no special privilege or trust with respect to other cosigners: i.e., = the leader is merely an ordinary participant, but is simply the one who = for whatever reason decides to initiate the cosigning operation. =  Giving the leader special powers - e.g., making the signature = malleable to the leader but not to others - would break this principle = and need to be extremely carefully considered I think.
To = follow up on my last message to Oleg, again I suggest reading section IV = of our CoSi paper from IEEE S&P last year (http://dedis.cs.yale.edu/dissent/papers/witness-abs), as = it discusses several related issues, especially the potential desire to = allow the leader to complete a collective signing procedure even with = only a subset of =E2=80=9Ccommitted=E2=80=9D participants remaining = present in the =E2=80=9Cresponse=E2=80=9D phase.  In particular, = the leader can form all the individual Schnorr commits into a Merkle = tree, and make the real commit c be the root of that Merkle tree. =  In this way, the leader is committing not so much to a particular = collective Schnorr commit but rather to *all possible* Schnorr commits = that can be composed from any subset of the individual Schnorr commits = within that Merkle tree.  This way, if some of the participants = whose commits are present in that Merkle tree remain available during = the response phase but others drop out, the leader can still use the = commit c and form a correct and verifiable collective signature against = the particular subset of Schnorr commits from nodes that remained = available throughout the process, without restarting.
I = guess this approach does, in a slightly different way, make the = resulting collective signatures slightly malleable to the leader: from a = given set of commit-time and response-time information, the leader could = put together distinct collective signatures representing different = subsets of response-time participants.  Some form of = =E2=80=9Cleader-malleability=E2=80=9D of this kind seems unavoidably = essential to enabling the leader to complete a collective signing round = in the presence of partial failures without restarting.  Perhaps = the same limited leader-malleability is more-or-less the same property = your suggestion of using chameleon hashes has, although I haven=E2=80=99t = had a chance to compare them deeply yet.
But at any rate, = the higher-level tradeoff here to consider is whether it=E2=80=99s = better to (a) enforce strict non-malleability of collective signatures = (by anyone, leader included), at the cost of O(N)-round DoS attack = vulnerability during signing due to the need to restart partially failed = rounds, or (b) provide some limited form of limited leader-malleability = in order to support restart-free operation and avoid DoS attacks during = signing, at the cost of a more complex protocol (and perhaps slightly = more =E2=80=9Cspecial=E2=80=9D trust in the leader than we might = like).
Again, further thoughts on this and other topics = are most welcome.
Thanks
Bryan
On Jul 3, 2017, at 7:34 = PM, Daniel Slamanig <daniel.slamanig@tugraz.at <mailto:daniel.slamanig@tugraz.at>> wrote:

Hi Philipp,

looks = interesting!

After looking at the protocol = I also have some security concerns (related to what has been raised by = Oleg in a previous mail).

Not committing to = Z as well as the actual sum of signers public keys A' in the computation = of the hash c for the signature seems to be problematic.
It seems to me that committing Z in the signature in plain = as well as A' does not work given the later application of the signing = procedure (where till the end of the protocol it is not clear who = actually participates in the signing but c must be known at the = beginning).

Committing to neither of both = however seems problematic as it does not fix the set of actual = signers.

This could be circumvented by = allowing an honest leader to adapt the commitment to the final Z (and = A') after it knows the signers without modifying the initially computed = c using a chameleon hash (trapdoor commitment). I use P as a generator = below, omit the brackets [a]P notation for scalar multiplication and = write it from the perspective of the leader, i.e., the signer that = initiates the protocol.

The leader could = choose chameleon hash parameters sk_ch=3Dy for random y and = pk_ch=3D(P,Y=3DyP) and add pk_ch and chameleon hash CH(Z'):=3Dh(Z')P+u'Y = for randomly chosen u' to the computation of c, i.e., set = c=3DH(R||A||pk_ch||CH(Z')||S), where h() is a collision resistant hash = function (this is just the standard way of constructing a chameleon hash = from DL for arbitrary message spaces as propsed in [1]). If Z' is not = yet known one simply sets Z' to some fixed string at the beginning, = e.g., Z':=3D0. At the end of the protocol, when the leader knows the = exact signers, it can update Z' to the final value Z and use sk_ch to = compute a collision in the chameleon hash, i.e., such that CH(Z)=3DCH(Z') = by solving h(Z')+u'y =3D h(Z)+uy for u. He then adds u and Z as well as = pk_ch to the signature, i.e., sets it as (R,s,u,Z,pk_ch) and discards = sk_ch and u'. If Z is known beforehand, one simply computes the = chameleon hash once and does not need to compute a collision. Clearly, = the use of a chameleon hash allows to simply adapt to the actual set of = signers representing Z without modifying c (with the knowledge of sk_ch = - but it does not work without the knowledge of sk_ch). This would = resolve the issue with the unknown Z at the time of signing.

Also, A is committed in the signature, but not = the concrete A'=3D\sum A_i of keys used for computing the signature (I = guess also due to the reason that one does not know the correct set of = signers when computing the hash c). That can be problematic in a rogue = key scenario in the current protocol, i.e., when not all signers need to = prove knowledge of the secret key when they register their public keys = but their public keys could be functions of other public keys (guess = this could be a problem here). For instance, a malicious A^* could just = take some key from A, say A_j, and compute and publish A^*=3Da^*A_j. And = then given a collective signature (R,s,Z) where A_j participated, the = signer can update s to s^* =3D s+a^*c as well as Z^* to exclude A_j and = include A^* (as Z is not committed in the signature generation) and the = signature (R,s^*,Z^*) will be a valid signature that certifies that A^* = participated in signing - although he didn't.

If Z is committed as proposed above and it is checked during = the verification, then this should no longer work. One could also adapt = the hash c=3DH(R||pk_ch||CH(Z'||A)||S) to include a chameleon hash to = CH(Z||A'), where A' is the real set of signers that participated in the = signature generation and is adapted before finalizing the signature when = known as above.

I hope that what I proposed = is not just complete nonsense :) Also it produces quite a bit of an = overhead. There may also be easier ways to avoid the issues.

Some editorial issues: the message to be = signed is sometimes called a satement S and later then message msg. S = could be confusing as part of the signature is s and your semantic is = that scalars are lowercase and points are uppercase. Also in 4.2 = "Signature Generation" steps 2 and 3 are confusing as I guess that in = the protocol all the signer compute their own [r_i]B values and R=3D\sum = R_i instead of R=3D[r]B which would mean that they would send their = r_i's (hope they will not do so).

Also I = find it somewhat confusing that the bitmask Z identifies the non-signers = with a bit set to 1. Why not identifying the signers with a bit set to = 1?

Cheers,
Daniel


[1] Hugo Krawczyk, Tal Rabin: = Chameleon Signatures. NDSS 2000

On = 01.07.2017 23:58, Philipp Jovanovic wrote:
Hi CFRG,
Here=E2=80=99s a first = version of an Internet-Draft on =E2=80=9CCollective Edwards-Curve = Digital Signature Algorithms=E2=80=9D based on Ed25519 and Ed448: https://datatracker.ietf.org/doc/draft-ford-cfrg-cosi/
We plan to give a short presentation on that topic at the = next CFRG meeting in Prague.
Any feedback is more than = welcome. Thanks!
All the best,
Philipp
_______________________________________________
Cfrg mailing list
Cfrg@irtf.org <mailto:Cfrg@irtf.org>
https://www.irtf.org/mailman/listinfo/cfrg


--
Dr.= Daniel Slamanig
Institute for Applied Information = Processing and Communications
Graz University of = Technology
Inffeldgasse 16a, 8010 Graz, Austria.
Phone: +43 316 873 5509
http://www.iaik.tugraz.at

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


--
Dr. Daniel Slamanig
Institute for Applied Information Processing and = Communications
Graz University of Technology
Inffeldgasse 16a, 8010 Graz, Austria.
Phone: +43 316 873 5509
http://www.iaik.tugraz.at

= --Apple-Mail=_7B1AD11C-2390-4290-A1A2-EAFEAE3244C8-- --Apple-Mail=_4D1010BB-2068-406E-BB75-7089D31ED14A Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIcBAEBCAAGBQJZZKhvAAoJEGt1rlrP7+d/+5gP/j6xDPHBK8VqCxXjySRuztaU AxfJasra7evcOSjhsv2dr/bmZrbfiXjXAsLmAp4su8KcBGSk3Bn0/nkxE3pX7HTY Q1X/+XjnKj79NP5VeUfkdoDCLkjMwCA8jaDZgejIRxOj+LOOZyD5MKbPIwVIqVWJ QvIfCTKkEbtd+gUPoZGkRlS0N2c0Y7zwwGbZMEkd4agtXkh8AgXiLdJ1yM9HcBQ9 a8sug9mm0rl2tmU6xGDpLTEq0jQb/UVubhioinmKjoA2cuCok1658RvIzCBPMrRV bss3SYhjjDew38nd1sZtUgI33PfSdMCnhrLJLNH5Q5CQFuijtB5qiHHFwKzLusRY 241nzjTJSKB0EddNqlXA2DqnaJHfE2y5LR5Z53s350DQzFksU6v3mmKM9L9Et1l9 0alcKwo80Dn1toAaCv+PSO1muIS4AGJDNBiHgynFlIwVVHReFrp0LehKiB0Ivxv2 AfGsZ9W1r+tteUIiCnWAXg7j+Q8fXK8YM7/7nWAP0CsBOGMdEixXxrlRtFzVCZmI ZV30JGVGxjPPx5au/l3H8vd1SmHNlOX7TASb1eom6Hox8sd7qVNiG48M4e64E+Pw YTRtvP2O6rEgTSnXXo2vJJ0DT93ub3T6v3pl0OKZVx0FkCMLUCINg2F0qynteXUI 2V/xgIxDQoRqBhx2JyDG =Cczo -----END PGP SIGNATURE----- --Apple-Mail=_4D1010BB-2068-406E-BB75-7089D31ED14A-- From nobody Tue Jul 11 03:51:01 2017 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 AB102128BC8 for ; Tue, 11 Jul 2017 03:51:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 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.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 HOR_xgEQ9Gxc for ; Tue, 11 Jul 2017 03:50:59 -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 10186129B5E for ; Tue, 11 Jul 2017 03:50:59 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id CD182BF4C for ; Tue, 11 Jul 2017 11:50:57 +0100 (IST) 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 af_Iz1TLoJpQ for ; Tue, 11 Jul 2017 11:50:57 +0100 (IST) Received: from [134.226.36.93] (bilbo.dsg.cs.tcd.ie [134.226.36.93]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 868E2BF48 for ; Tue, 11 Jul 2017 11:50:57 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1499770257; bh=Md4CMHfybURHwRuV7cB3GktH7+YP0VsIByu4MQq4LM0=; h=Subject:To:References:From:Date:In-Reply-To:From; b=mFUm+Kt7GmclwQY92zoKd0v781ANGbf72J7u90RJOSi8B3OIgyLCikKjmAb+XY9Xg SYPVVyphgGOc3CTUjs30Vyr9IqtbaWIRrMa0c3KMLM4krFJqSrsmQ3FNP0Hq6IH/Aw Q26YanoJd5vpT3RA08NUbUXW3kS5tZ2i0kvjInX0= To: "cfrg@irtf.org" References: <1777c26d-4e8c-453d-422e-b1f238105bd5@cs.tcd.ie> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: Date: Tue, 11 Jul 2017 11:50:54 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <1777c26d-4e8c-453d-422e-b1f238105bd5@cs.tcd.ie> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="lF5AvI0QuElgu80roAiUwL3mGeNGa9xBI" Archived-At: Subject: Re: [Cfrg] [TLS] wiretapping draft - collecting rebuttal arguments X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jul 2017 10:51:01 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --lF5AvI0QuElgu80roAiUwL3mGeNGa9xBI Content-Type: multipart/mixed; boundary="QodADKSwsqT21Uh5cXe63DqE6KNvbAQu3"; protected-headers="v1" From: Stephen Farrell To: "cfrg@irtf.org" Message-ID: Subject: Re: [TLS] wiretapping draft - collecting rebuttal arguments References: <1777c26d-4e8c-453d-422e-b1f238105bd5@cs.tcd.ie> In-Reply-To: <1777c26d-4e8c-453d-422e-b1f238105bd5@cs.tcd.ie> --QodADKSwsqT21Uh5cXe63DqE6KNvbAQu3 Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: quoted-printable FYI. Contributions from folks here would be welcome if you're interested, Cheers, S. PS: This relates to ongoing discussion on the TLS list. On 11/07/17 11:48, Stephen Farrell wrote: >=20 > Hiya, >=20 > I've asked the chairs for a slot in Prague to allow > for rebutting the claims made by the proponents of > the most recent wiretapping draft we're (sadly, still) > discussing. [1] >=20 > So far the chairs seem un-keen, but I'm gonna keep > asking as I think having a rebuttal for this kind > of bad idea is needed. (And again, I'd prefer the > chairs ditch the entire idea of discussing this at > all.) >=20 > In any case, and perhaps with a view to longer-term > documenting the arguments against the various "let's > break TLS" proposals we continually see, I've started > to collect some of those arguments in a github repo [2]. >=20 > I would welcome contributions to [2] however folks > would like to provide 'em (but ideally via PRs) so > we can provide a nice crowd-sourced rebuttal in > Prague, either as a presentation or via a lively > mic-line if need be. >=20 > Cheers, > S. >=20 > PS: I've just started on this, but will go through > the list archive to extract others' arguments and > add acks. Not sure if that'll get done before we > end up in Prague but please do let me know if I've > used an argument you made so I can ack that later. >=20 > [1] https://tools.ietf.org/html/draft-green-tls-static-dh-in-tls13-01 > [2] https://github.com/sftcd/tinfoil >=20 >=20 >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >=20 --QodADKSwsqT21Uh5cXe63DqE6KNvbAQu3-- --lF5AvI0QuElgu80roAiUwL3mGeNGa9xBI Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJZZK2QAAoJEC88hzaAX42igpkIAIBAMOTTa9in20d6Ac2Rcpoo 0iyxQlrRoPHfRByawW6qowtPKbJ5WqdcIIYNXkUAtzspnFP3n+CFhKExPMq+TIA9 JoWqhYwFGpW6ZAfVTXDQkY3Qwb+PXeEMjAYd/Sli9v/Og5M3z90iuvM4m9Iot9Dd thGyzleZJcE6fBtTt8ofqugQR1TdtBdQxS87bgGVMiDbGrSY7XZ/Mz1lKj+MfY0c mXwBCvc9tBaY/UBHXRD50cu0TtH+s7gbwJ4XGAmJdEXEfljvV34hE70LnkLR2VkR MxS5h6h043e9OIHF1CXqdl0IYzEOftqK6rl8OIMe8/Ub+HX8cZg5RDhA2v8Q/Dw= =OxwR -----END PGP SIGNATURE----- --lF5AvI0QuElgu80roAiUwL3mGeNGa9xBI-- From nobody Tue Jul 11 19:18:26 2017 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 329F7120725 for ; Tue, 11 Jul 2017 19:18: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, 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 WUcKjK1lP58u for ; Tue, 11 Jul 2017 19:18:22 -0700 (PDT) Received: from nm18-vm4.access.bullet.mail.bf1.yahoo.com (nm18-vm4.access.bullet.mail.bf1.yahoo.com [216.109.115.83]) (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 8622A120454 for ; Tue, 11 Jul 2017 19:18:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sbcglobal.net; s=s2048; t=1499825901; bh=uCNFmpF+zqp7IBMHyo0dsKud7Tq6Tnu/SpOdK4GQz9Q=; h=Subject:To:References:From:Date:In-Reply-To:From:Subject; b=n1bHJ3MlOrDRVyLfDxt9zMTWOXWQ2OF8vVHoZ0JIi852PZL/GA2p9v5buobFQiN5hyS5fDWoqE7RxDVfY0gbiCpN1zi8NnKtYymIGifVxKKORGK5QzefXIApnSOh6BEe4q1ngJW7I1+sMK4gX3dnc0lAc2/FmRNR+d+KdQUh/mFlpvCCYhOJvkD75LO4T7tXNcLswnoTkB2oa8+TCoq2Sq12pD1f0QZp7+sTyMarQjN5hN6Vjeur44ucXv7IW6rRFxZbPdT/RJK551xETArImkJAY0icLE3AZIODsicl6i/2gOoAbPpB/8WADWI7yEJd43RD4EX4x/y0UhnnuGguUg== Received: from [66.196.81.157] by nm18.access.bullet.mail.bf1.yahoo.com with NNFMP; 12 Jul 2017 02:18:21 -0000 Received: from [10.218.253.202] by tm3.access.bullet.mail.bf1.yahoo.com with NNFMP; 12 Jul 2017 02:18:21 -0000 Received: from [127.0.0.1] by smtp119.sbc.mail.ne1.yahoo.com with NNFMP; 12 Jul 2017 02:18:21 -0000 X-Yahoo-Newman-Id: 468197.53913.bm@smtp119.sbc.mail.ne1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: MMgQT64VM1l2niu8M5pa0OI8aqBfkvkyPOu.KTBHfzfw51w ZbMFu8izQsyPkPBxrw.DWKIChzkKAsi0R6PAZ.mFoVptrhF4x80V0XmtKkcW Qwj1hRtvt.aEGMBDblyTTFlHl5B1lcFoQtRL4XvLcJHVyPgIIZGnWPBh46V2 wHAcnOdd_Q9vU5hIwIeNbJHXXGJLIv57lhCIMZ5bveQjF.WJ0uoc8tkrgZSs TkKELQh1dO5SglNVbpreOX51L.9eB_TO42YMl_MyeYbPLlEcDIpza5TT7AG7 zadLl435Dgvn33PV6dYqVQRB0w5ad4tiLH.cCaYrYyzZ.P05giJTwJ6JuHpu OWao2ZjSD._yq1Cv1qQN9Ms2xOvUyYofmTV7rRAHNZPh3I7No2Y2HV77.zM9 wOFklCwXQ.RAPeRAEY9NBN01xlxb4fOvIwwzkCzr_eykJMs78a.F7Mp2_4Kp KwyUnUZOIlTFVoGH.Sz2qna14f05fZ5dZAPX2ge_Dmro_z2GiIAs_PgpWwJA NUwhC84FD7yfLIkmC2MGTKxy72W8KWAp8ihFtQFSbLQ-- X-Yahoo-SMTP: nOrmCa6swBAE50FabWnlVFUpgFVJ9Gbi__8U5mpvhtQq7tTV1g-- To: Samuel Neves , "cfrg@irtf.org" References: From: David Jacobson Message-ID: <838cb765-1ecb-5dbd-f308-bbd415e6321c@sbcglobal.net> Date: Tue, 11 Jul 2017 19:18:18 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Cfrg] Side channel attack and Edwards curves... X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jul 2017 02:18:24 -0000 On 7/5/17 5:35 PM, Samuel Neves wrote: > Coron's countermeasures [1, §5]---the first and third one, in > particular---work well with Montgomery coordinates. > > [1] http://www.jscoron.fr/publications/dpaecc.pdf > > On Thu, Jul 6, 2017 at 1:07 AM, Tony Arcieri wrote: >> On Wed, Jul 5, 2017 at 4:16 PM, Phillip Hallam-Baker >> wrote: >>> You can blind in either. But if you are going to blind then a lot of the >>> advantages of Montgomery start to collapse. because you have to do that add >>> stage. >> >> What if you blinded kP with r using: >> >> r*([k r^-1]*P) >> >> which only requires inversions? >> >> -- >> Tony Arcieri >> >> _______________________________________________ >> 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 I think you miscounted the cost. You need an extra inversion and an extra point multiplication. And even then the security is dubious. The original motivation apparently was that you are worried that computing kP will leak k. Well, the proposal first leaks k r^-1, then it leaks r. The attacker can just multiply the two leaked quantities and she has k. --David Jacobson From nobody Wed Jul 12 02:42:43 2017 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 A51FC126B72 for ; Wed, 12 Jul 2017 02:42:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 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, SPF_PASS=-0.001] autolearn=no 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 Xif7y51Empus for ; Wed, 12 Jul 2017 02:42:40 -0700 (PDT) Received: from mail-it0-x229.google.com (mail-it0-x229.google.com [IPv6:2607:f8b0:4001:c0b::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 25C8B124E15 for ; Wed, 12 Jul 2017 02:42:40 -0700 (PDT) Received: by mail-it0-x229.google.com with SMTP id m68so8865199ith.1 for ; Wed, 12 Jul 2017 02:42:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:from:date:message-id:subject:to:cc; bh=EecCD57uzATR8fbxVB3wRbgrJmvC0VQ3feIcK+bcRmc=; b=f+Mjh6pxAg5UTboy1hTCq/39NpzTDDdD1DxzHEP+mA4wxfrZaSNG/f0AeSTXUF8ren eewtF1hvu5q2+vLP/dVJvGIHWQHt7pIHUcF9jhGk/rpxiG7KCMojWaSV8g9wYpQaerRu btrshci645e2SrnYelWOUbOVxEo6l6ee8QP7QuElkXrdIr5GemoA3Kgor1mRMk/CB1oh OCbiL5G2l2pH2ULU8vG/KeNMXC4zjW+pEA+/s8nv88bvhjrWAWSLVs1WYKFzEkrvh0qa bX5nmJWPd5iyjzOBWZMF2D80Z+ZvX0U3XBoYIgjFQgC86RL46tV/RrJlql74k4YlFON4 s9Kg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:from:date:message-id:subject :to:cc; bh=EecCD57uzATR8fbxVB3wRbgrJmvC0VQ3feIcK+bcRmc=; b=UaBNGPmtiDcOk+ZjX26tLIsGasW0o55ZJOPXIzVk2LuHgCgrYl/p0qWuG9wH8uSIp3 DKnlZPLo9l3WKkBwOkjUCQPuEKqSORtvM9Wsk8u1641cwdIOd23wdN/YijHnSGdrW+aa QUq+mjr6pWbxuF0jk3SooKL2n0B9d+2EIcEzzuHgbkr2az+h2u7gFuafEITYP4SlLHjT IB+/n4OwF/SxgkJCYzQ4sHsV4S9DRytBZwI1COAesiQ2e1w1FC40cdWwuT6TOUnSmjzw +nPCQZ6fmj1rnX5qgoJmJvZeYeWKqSE526kg3IbYZK9suI51WOzHzDFd1Sgu9jF1xdz0 iBbw== X-Gm-Message-State: AIVw111a/b4EIrnaxltMIlffgHuv+mft6tDHAmPL88SxSfxrB82HwWJt eQXuDo9sRISg1dSzVCMqThGvdh6eNHak X-Received: by 10.36.82.77 with SMTP id d74mr20485250itb.119.1499852559342; Wed, 12 Jul 2017 02:42:39 -0700 (PDT) MIME-Version: 1.0 Sender: sharon.goldbe@gmail.com Received: by 10.107.164.205 with HTTP; Wed, 12 Jul 2017 02:41:58 -0700 (PDT) From: Sharon Goldberg Date: Wed, 12 Jul 2017 12:41:58 +0300 X-Google-Sender-Auth: mob62gXFptJbpNMYMuBkGPE4oT4 Message-ID: To: cfrg@irtf.org Cc: Leonid Reyzin , jan@ns1.com, Dimitrios Papadopoulos Content-Type: multipart/alternative; boundary="001a11448d8203e33205541ba3d9" Archived-At: Subject: [Cfrg] draft-goldbe-vrf: Verifiable Random Functions X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jul 2017 09:42:42 -0000 --001a11448d8203e33205541ba3d9 Content-Type: text/plain; charset="UTF-8" Dear CFRG, I'm presenting at next week's meeting on Verifiable Random Functions. A VRF is the public-key version of keyed cryptographic hash. Only the holder of the VRF secret key can compute the hash, but anyone with the public key can verify it. VRFs can be used to prevent dictionary attacks on hash-based data structures, and have applications to key transparency (CONIKS), DNSSEC (NSEC5), and cryptocurrencies (Algorand). In advance of the meeting, please see: 1) Our substantially updated -01 draft: https://datatracker.ietf.org/doc/draft-goldbe-vrf/ 2) Our project page, with links to various VRF implementations: https://www.cs.bu.edu/~goldbe/projects/vrf Comments welcome. Thanks, Sharon -- Sharon Goldberg Computer Science, Boston University http://www.cs.bu.edu/~goldbe --001a11448d8203e33205541ba3d9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear CFRG,

I'm presenting at next week's me= eting on Verifiable Random Functions. A VRF is the public-key version of ke= yed cryptographic hash. Only the holder of the VRF secret key can compute t= he hash, but anyone with the public key can verify it.=C2=A0 VRFs can be us= ed to prevent dictionary attacks on hash-based data structures, and have ap= plications to key transparency (CONIKS), DNSSEC (NSEC5), and cryptocurrenci= es (Algorand).

In advance of the meeting, please see:

1) Our = substantially updated -01 draft:
https://datatracker.ietf.org/doc/draft-goldbe-vrf/

2) Our project page, with links to variou= s VRF implementations:
https://www.cs.bu.edu/~goldbe/projects/vrf=

Comments welcome.=C2=A0 Thanks,

Sharon

--
Sharon G= oldberg
Computer Science, Boston University
http://www.cs.bu.edu/~goldbe
--001a11448d8203e33205541ba3d9-- From nobody Wed Jul 12 05:43:54 2017 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 4582812783A for ; Wed, 12 Jul 2017 05:43:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.523 X-Spam-Level: X-Spam-Status: No, score=-14.523 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_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, 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 gdJbZrjx-tnj for ; Wed, 12 Jul 2017 05:43:51 -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 728CF12EC30 for ; Wed, 12 Jul 2017 05:43:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3672; q=dns/txt; s=iport; t=1499863431; x=1501073031; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=OKWikAKOVRWnrrYP9HRhoPftYpVHnppvJtZuM/Rbe+s=; b=i3SF8jl2pJ9sWdNDa5mV2+bJesBB6/OUjwB9uGM6tImAYP2QN06njYu/ xHBaUx5KXoLqI09tqrANnUFz/sbPr7u3HwxlZ2SJ2rl9LcCcFqbhTlVuH vdQhXllert1nR7XRY0wunCHFGyJ2IHd13kxQM9w7TiCXz1zofNd4AVPln s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AQAgA+GWZZ/4sNJK1dGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBg1pkgRQHn3KILo1VghEhC4VKAhqDM0AXAQIBAQEBAQEBayiFGAEBAQE?= =?us-ascii?q?BAgEBIRE6BhEEAgEIDgMEAQEBAgIjAwICAh8GCxQBCAgCBAESCBOJfAMVEKxvg?= =?us-ascii?q?iaHLw2DZAEBAQEBAQEBAQEBAQEBAQEBAQEBAR2BC4IZBIELgkKFBYJXKYIBgny?= =?us-ascii?q?CYQWebTsCjx+EZZIujAaJSgEhATWBCnUVSYcWdgGHS4ENAQEB?= X-IronPort-AV: E=Sophos;i="5.40,349,1496102400"; d="scan'208";a="272070722" Received: from alln-core-6.cisco.com ([173.36.13.139]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 12 Jul 2017 12:43:31 +0000 Received: from XCH-RTP-008.cisco.com (xch-rtp-008.cisco.com [64.101.220.148]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id v6CChVPB018865 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 12 Jul 2017 12:43:31 GMT Received: from xch-rtp-006.cisco.com (64.101.220.146) by XCH-RTP-008.cisco.com (64.101.220.148) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 12 Jul 2017 08:43:30 -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.1210.000; Wed, 12 Jul 2017 08:43:30 -0400 From: "Scott Fluhrer (sfluhrer)" To: David Jacobson , Samuel Neves , "cfrg@irtf.org" Thread-Topic: [Cfrg] Side channel attack and Edwards curves... Thread-Index: AQHS9b3vZ+aOkxg3wUKP5VNbVUjcgaJGC/6AgAAVBACAAA4lgIAAB/SAgAmKtwCAAGlfIA== Date: Wed, 12 Jul 2017 12:43:30 +0000 Message-ID: <63bd361b2bc543b4a84de3678cea196a@XCH-RTP-006.cisco.com> References: <838cb765-1ecb-5dbd-f308-bbd415e6321c@sbcglobal.net> In-Reply-To: <838cb765-1ecb-5dbd-f308-bbd415e6321c@sbcglobal.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: [10.150.34.172] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Cfrg] Side channel attack and Edwards curves... X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jul 2017 12:43:53 -0000 DQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IENmcmcgW21haWx0bzpjZnJn LWJvdW5jZXNAaXJ0Zi5vcmddIE9uIEJlaGFsZiBPZiBEYXZpZCBKYWNvYnNvbg0KPiBTZW50OiBU dWVzZGF5LCBKdWx5IDExLCAyMDE3IDEwOjE4IFBNDQo+IFRvOiBTYW11ZWwgTmV2ZXM7IGNmcmdA aXJ0Zi5vcmcNCj4gU3ViamVjdDogUmU6IFtDZnJnXSBTaWRlIGNoYW5uZWwgYXR0YWNrIGFuZCBF ZHdhcmRzIGN1cnZlcy4uLg0KPiANCj4gT24gNy81LzE3IDU6MzUgUE0sIFNhbXVlbCBOZXZlcyB3 cm90ZToNCj4gPiBDb3JvbidzIGNvdW50ZXJtZWFzdXJlcyBbMSwgwqc1XS0tLXRoZSBmaXJzdCBh bmQgdGhpcmQgb25lLCBpbg0KPiA+IHBhcnRpY3VsYXItLS13b3JrIHdlbGwgd2l0aCBNb250Z29t ZXJ5IGNvb3JkaW5hdGVzLg0KPiA+DQo+ID4gWzFdIGh0dHA6Ly93d3cuanNjb3Jvbi5mci9wdWJs aWNhdGlvbnMvZHBhZWNjLnBkZg0KPiA+DQo+ID4gT24gVGh1LCBKdWwgNiwgMjAxNyBhdCAxOjA3 IEFNLCBUb255IEFyY2llcmkgPGJhc2N1bGVAZ21haWwuY29tPiB3cm90ZToNCj4gPj4gT24gV2Vk LCBKdWwgNSwgMjAxNyBhdCA0OjE2IFBNLCBQaGlsbGlwIEhhbGxhbS1CYWtlcg0KPiA+PiA8cGhp bGxAaGFsbGFtYmFrZXIuY29tPg0KPiA+PiB3cm90ZToNCj4gPj4+IFlvdSBjYW4gYmxpbmQgaW4g ZWl0aGVyLiBCdXQgaWYgeW91IGFyZSBnb2luZyB0byBibGluZCB0aGVuIGEgbG90IG9mDQo+ID4+ PiB0aGUgYWR2YW50YWdlcyBvZiBNb250Z29tZXJ5IHN0YXJ0IHRvIGNvbGxhcHNlLiBiZWNhdXNl IHlvdSBoYXZlIHRvDQo+ID4+PiBkbyB0aGF0IGFkZCBzdGFnZS4NCj4gPj4NCj4gPj4gV2hhdCBp ZiB5b3UgYmxpbmRlZCBrUCB3aXRoIHIgdXNpbmc6DQo+ID4+DQo+ID4+ICAgICAgciooW2sgcl4t MV0qUCkNCj4gPj4NCj4gPj4gd2hpY2ggb25seSByZXF1aXJlcyBpbnZlcnNpb25zPw0KPiA+Pg0K PiA+PiAtLQ0KPiA+PiBUb255IEFyY2llcmkNCj4gPj4NCj4gPj4gX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPj4gQ2ZyZyBtYWlsaW5nIGxpc3QNCj4g Pj4gQ2ZyZ0BpcnRmLm9yZw0KPiA+PiBodHRwczovL3d3dy5pcnRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL2NmcmcNCj4gPj4NCj4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KPiA+IENmcmcgbWFpbGluZyBsaXN0DQo+ID4gQ2ZyZ0BpcnRmLm9yZw0KPiA+ IGh0dHBzOi8vd3d3LmlydGYub3JnL21haWxtYW4vbGlzdGluZm8vY2ZyZw0KPiANCj4gSSB0aGlu ayB5b3UgbWlzY291bnRlZCB0aGUgY29zdC4gICBZb3UgbmVlZCBhbiBleHRyYSBpbnZlcnNpb24g YW5kIGFuDQo+IGV4dHJhIHBvaW50IG11bHRpcGxpY2F0aW9uLg0KPiANCj4gQW5kIGV2ZW4gdGhl biB0aGUgc2VjdXJpdHkgaXMgZHViaW91cy4gIFRoZSBvcmlnaW5hbCBtb3RpdmF0aW9uIGFwcGFy ZW50bHkNCj4gd2FzIHRoYXQgeW91IGFyZSB3b3JyaWVkIHRoYXQgY29tcHV0aW5nIGtQIHdpbGwg bGVhayBrLg0KPiBXZWxsLCB0aGUgcHJvcG9zYWwgZmlyc3QgbGVha3MgayByXi0xLCB0aGVuIGl0 IGxlYWtzIHIuICBUaGUgYXR0YWNrZXIgY2FuIGp1c3QNCj4gbXVsdGlwbHkgdGhlIHR3byBsZWFr ZWQgcXVhbnRpdGllcyBhbmQgc2hlIGhhcyBrLg0KDQpJIHdvdWxkIGRpc2FncmVlIHdpdGggdGhp cyBzZWN1cml0eSBhc3Nlc3NtZW50OyBzaWRlIGNoYW5uZWwgYXR0YWNrcyBnZW5lcmFsbHkgZG9u J3QgbGVhayB0aGUgZW50aXJlIHZhbHVlIGluIG9uZSBydW47IHRoZXkgbGVhayBwcm9iYWJpbGlz dGljIGluZm9ybWF0aW9uIGFib3V0IHRoZSBzZWNyZXQgKGFuZCB0aGUgYXR0YWNrZXIgd2lsbCB0 eXBpY2FsbHkgdXNlIG11bHRpcGxlIHJ1bnMgdXNpbmcgdGhlIHNhbWUgc2VjcmV0IHRvIHJlY292 ZXIgc3VmZmljaWVudCBpbmZvcm1hdGlvbiB0byBhY3R1YWxseSBkbyB0aGUgcmVjb3ZlcnkpLiAg SW4gdGhpcyBjYXNlLCAncicgaXMgc2VsZWN0ZWQgcmFuZG9tbHkgZWFjaCB0aW1lLCBhbmQgaGVu Y2UgYW55IHNwZWNpZmljIG11bHRpcGxpZXIgdGhhdCB3aWxsIGJlIHVzZWQgd2lsbCBiZSB1bmNv cnJlbGF0ZWQgd2l0aCB0aGUgc2VjcmV0IGFuZCBhbnkgb3RoZXIgbXVsdGlwbGllciAoZXhjZXB0 IHRoYXQgdGhlIG11bHRpcGxpY2F0aW9uIG9mIHR3byBhZGphY2VudCBvbmVzIHdpbGwgcmVzdWx0 IGluIHRoZSBhY3R1YWwgc2VjcmV0OyBwYXJ0aWFsIGxlYWthZ2Ugb2YgYml0cyBvZiB0aGUgbXVs dGlwbGllciBpc24ndCBwYXJ0aWN1bGFybHkgdXNlZnVsIHRvIHJlY292ZXIgdGhlIG1vZHVsYXIg cHJvZHVjdCkuICBIZW5jZSwgdGhpcyBhY3R1YWxseSBkb2VzIHByb3ZpZGUgc29tZSBsZXZlbCBv ZiBwcm90ZWN0aW9uLCBhc3N1bWluZyB0aGF0IHRoZSBhdHRhY2tlciBjYW5ub3Qgb2J0YWluIHN1 ZmZpY2llbnQgaW5mb3JtYXRpb24gZnJvbSBhIHNpbmdsZSBydW4gKGFuZCBpZiB5b3Ugc3RhcnQg YXNzdW1pbmcgdGhhdCwgeW91J2QgbmVlZCB0byBzdGFydCBsb29raW5nIGludG8gd2hpdGUtYm94 IGNyeXB0byBzb2x1dGlvbnMpLg0KDQpJcyB0aGlzIGVub3VnaCBwcm90ZWN0aW9uIHRvIGJlIHdv cnRoIHRoZSBjb3N0PyAgVGhhdCdzIGEgcXVlc3Rpb24gSSB3b24ndCBnZXQgaW50by4uLg0KDQoN Cg== From nobody Fri Jul 14 08:52:39 2017 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 74C51128961; Fri, 14 Jul 2017 08:52:37 -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 cQ869B8as8zO; Fri, 14 Jul 2017 08:52:34 -0700 (PDT) Received: from mail-yw0-x22a.google.com (mail-yw0-x22a.google.com [IPv6:2607:f8b0:4002: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 9A620127ABE; Fri, 14 Jul 2017 08:52:34 -0700 (PDT) Received: by mail-yw0-x22a.google.com with SMTP id l21so27046747ywb.1; Fri, 14 Jul 2017 08:52:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=8LzfEQVPNlqay360NtaKavT5FsjKv0lneeREZiXNiBM=; b=GyekS0RvZf9//RSPDTQQ5iTf0+TtaWvI+LHruwX8R6ggnHvhPo1QvlXWBX/rP+eVbM 26RPMn+Djkzhjc9mSWVby7ve5OK00/TBvFEapd2hOf79Xi0L0u02+GtRTd0gkXG/1xlS ckACHi34U5W/Wos2H921X0uEa14wgkTk23j/hNFkY+ASg0Pn+2Ff6WpthFRVNfQc4FkD R/FBfAbonNt3OztGzc9AUeq3S20ouPQWtidQtU/JeqL0GiQkBNRyNJL98q2InFvArlze yScRkZYVbkYs2Yzc0NWW1nnzO5BHtq69yYlrigTJkMTcOYpuYBbYFYTqZGRGBomifSSs OI1g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=8LzfEQVPNlqay360NtaKavT5FsjKv0lneeREZiXNiBM=; b=oMnnpS+yz8VfTaDbdlo+6NcxqaOwZZBCboMl/4EfZBgCyWuvdmKQezJmTvYsLKLM+7 pO/bLg6npJdUYR1WhGFgtdfCXllnaCJPs9HNZfPbicFSZ158/1gO8uW+3OtBnyIycE6j ZzlETBdCNsscDrMJ1ANZHDSkW+v15KLmRPMSUPJTMvUZcJDvgljuj6CE75xRDMiq35T0 AWhN2/JMdibyfVveflN1FisgfQqE1FvD+YKnnKqYBtf0+OyQWT5XAqhjFtuOoJFFJnt0 zPTP60wTbScdrdajiM/XOlT9WEHXhETQ9TWNM9mnN2VDfP0N9XCNmFuKiucaPqcizP13 N8gw== X-Gm-Message-State: AIVw110NO0zTx3Qm+iQWYctdwWgHemBx6NHpn0iLqh5MGgzBY3LG6bLS DF5HwwYP3PaN2/ea2DyFxbgeGzYrNw== X-Received: by 10.129.200.7 with SMTP id n7mr7064427ywi.115.1500047553718; Fri, 14 Jul 2017 08:52:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.83.17.138 with HTTP; Fri, 14 Jul 2017 08:52:18 -0700 (PDT) In-Reply-To: References: <149061159741.30566.11599293166376872082@ietfa.amsl.com> From: Dmitry Khovratovich Date: Fri, 14 Jul 2017 17:52:18 +0200 Message-ID: To: "Paterson, Kenny" Cc: "draft-irtf-cfrg-argon2@ietf.org" , "cfrg@ietf.org" Content-Type: multipart/alternative; boundary="089e0821eb4095f16f0554490900" Archived-At: Subject: Re: [Cfrg] I-D Action: draft-irtf-cfrg-argon2-02.txt X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jul 2017 15:52:37 -0000 --089e0821eb4095f16f0554490900 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Dear Russ, Stanislav, Jeremiah, thank you a lot for the efforts! The reviews make the document much better. We are now working on integrating the comments into the draft, hopefully finished next week. We'll publish a document where every comment is accompanied with a note. Best regards, Dmitry, Alex On Tue, Jul 4, 2017 at 4:06 PM, Paterson, Kenny wrote: > Dear Argon2 authors, > > > You will have seen the two recent CFRG review panel reviews for > draft-irtf-cfrg-argon2-02.txt: > > https://www.ietf.org/mail-archive/web/cfrg/current/msg09199.html > > https://www.ietf.org/mail-archive/web/cfrg/current/msg09195.html > > > - thanks to Russ Housley and Stanislav Smyshlyaev for preparing these. > > Please would you take these reviews into account when preparing the next > version of your draft? It would helpful if you would post a response > explaining how you have addressed the comments when you are ready. > > (Note also that there was a cutoff for new drafts this Monday past becaus= e > of the upcoming IETF meeting.) > > Regards > > Kenny (for the chairs) > > > On 15/06/2017 15:16, "Paterson, Kenny" wrote: > > >Dear CFRG, > > > >Dmitry Khovratovich kindly presented the latest draft for Argon2 at the > >interim CFRG meeting in Paris. For those of you who could not attend, hi= s > >slides can be found here: > > > >https://www.ietf.org/proceedings/interim-2017-cfrg- > 01/slides/slides-interi > >m > >-2017-cfrg-01-sessa-argon2-00.pdf > > > > > >My sense from the constructive discussion that took place after Dmitry's > >talk in Paris was that there are now no remaining serious objections to > >the recommended parameters in the latest version of the draft: > > > >https://datatracker.ietf.org/doc/draft-irtf-cfrg-argon2/ > > > > > >If there are further substantive technical comments from the CFRG > >membership, the chairs would be grateful if they could be brought to the > >list in the next few days. > > > >Assuming we have indeed reached consensus, then we will be in a position > >to move to last call for this ID. > > > >Thanks, > > > >Kenny (for the chairs) > > > > > >On 27/03/2017 11:51, "Cfrg on behalf of Dmitry Khovratovich" > > wrote: > > > >>Some comments on a new draft:VariantsArgon2 fills M bytes of memory in = T > >>iterations over > >> it, with M and T being the parameters supplied to Argon2 and determini= ng > >>its performance. Speed on a typical server is linear in the MT product. > >> > >>The Argon2 family has three variants: I, D, and > >> ID, which differ in the way of reusing memory that has been filled. Th= e > >>I variant makes queries with predictable addresses, whereas D determine= s > >>the addresses on the fly depending on the current state (and thus the > >>password). The ID variant follows I for the > >> first half of the memory used and D for the rest and while overwriting= . > >>Side-channelsThe side-channel attacks, which are of still rising > >> concern in the security community, are applicable to the D variant as > >>the memory addresses and thus information about the password or other > >>secret inputs can be determined from the timing leaks. The I variant is > >>completely invulnerable to this attack, and > >> the ID variant provides only a constant factor improvement for the > >>attacker. > >>Hardware and tradeoffsThe M and T parameters determine the cost of > >>bruteforcing > >> passwords on custom hardware, which is proportional to M2T > >> if we follow the traditional time-area product metric. The time-memory > >>tradeoff analysis [2] shows that the bruteforce cost for the I variant > >>can be changed to M2T/Q(M,T) > >> for some quality function Q. For instance, Q(230,1)=3D5, > >> Q(230,4)=3D2.5. > >> > >>The D variant is invulnerable to the approach [2], > >> and the savings factor in the ID variant is upper bounded by factor 2 > >>for all parameters. > >>Defender tradeoff and ultimate > >> recommendationsIn public and private conversations with security > >> architects in the industry we learned that the bottleneck in a system > >>employing the password-hashing function is the function latency rather > >>than memory costs. We then assume that a rational defender would like t= o > >>maximize the bruteforce costs for the attacker > >> equipped with a list of hashes, salts, and timing information, for fix= ed > >>computing time on the > >> defender=E2=80=99s machine. In this assumption the defender keeps the= MT > >>product constant and maximizes the losses M/Q(M,T). > >> The authors of [2] provides us with attack cost estimates for constant > >>MT =3D 228,230,232 > >> (measured in iteration-bytes) > >> > >>We ultimately recommend the ID variant with T=3D1 and maximum M as a > >>default setting for all environments, which is secure > >> against side-channel attacks and prohibit adversarial advantage on > >>dedicated bruteforce hardware. > >> > >> > >>References[1] > >>=E2=80=9CEfficiently Computing Data-Independent > >> Memory-Hard Functions=E2=80=9D > >>[2] > >>=E2=80=9CTowards Practical Attacks on > >> Argon2i and Balloon Hashing=E2=80=9D > >> > >> > >> > >> > >> > >>On Mon, Mar 27, 2017 at 12:46 PM, wrote: > >> > >> > >>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 : The memory-hard Argon2 password hash and > >>proof-of-work function > >> Authors : Alex Biryukov > >> Daniel Dinu > >> Dmitry Khovratovich > >> Simon Josefsson > >> Filename : draft-irtf-cfrg-argon2-02.txt > >> Pages : 26 > >> Date : 2017-03-27 > >> > >>Abstract: > >> This document describes the Argon2 memory-hard function for password > >> hashing and proof-of-work applications. We provide an implementer > >> oriented description together with sample code and test vectors. Th= e > >> purpose is to simplify adoption of Argon2 for Internet protocols. > >> > >> > >>The IETF datatracker status page for this draft is: > >>https://datatracker.ietf.org/doc/draft-irtf-cfrg-argon2/ > >> > >>There are also htmlized versions available at: > >>https://tools.ietf.org/html/draft-irtf-cfrg-argon2-02 > >>https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-argon2-02 > >> > >>A diff from the previous version is available at: > >>https://www.ietf.org/rfcdiff?url2=3Ddraft-irtf-cfrg-argon2-02 > >> > >> > >>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/ > >> > >>_______________________________________________ > >>Cfrg mailing list > >>Cfrg@irtf.org > >>https://www.irtf.org/mailman/listinfo/cfrg > >> > >> > >> > >> > >> > >> > >> > >>-- > >>Best regards, > >>Dmitry Khovratovich > >> > >> > > > > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > https://www.irtf.org/mailman/listinfo/cfrg > --=20 Best regards, Dmitry Khovratovich --089e0821eb4095f16f0554490900 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear Russ, Stanislav, Jeremiah,

thank y= ou a lot for the efforts! The reviews make the document much better. We are= now working on integrating the comments into the draft, hopefully finished= next week.

We'll publish a document where eve= ry comment is accompanied with a note.=C2=A0

Best = regards,
Dmitry, Alex

<= div class=3D"gmail_quote">On Tue, Jul 4, 2017 at 4:06 PM, Paterson, Kenny <= span dir=3D"ltr"><Kenny.Paterson@rhul.ac.uk> wrote:
Dear Argon2 authors,


You will have seen the two recent CFRG review panel reviews for
draft-irtf-cfrg-argon2-02.txt:

https://www.ietf.org/mail-archi= ve/web/cfrg/current/msg09199.html

https://www.ietf.org/mail-archi= ve/web/cfrg/current/msg09195.html


- thanks to Russ Housley and Stanislav Smyshlyaev for preparing these.

Please would you take these reviews into account when preparing the next version of your draft? It would helpful if you would post a response
explaining how you have addressed the comments when you are ready.

(Note also that there was a cutoff for new drafts this Monday past because<= br> of the upcoming IETF meeting.)

Regards

Kenny (for the chairs)


On 15/06/2017 15:16, "Paterson, Kenny" <Kenny.Paterson@rhul.ac.uk> wrote:

>Dear CFRG,
>
>Dmitry Khovratovich kindly presented the latest draft for Argon2 at the=
>interim CFRG meeting in Paris. For those of you who could not attend, h= is
>slides can be found here:
>
>https://www.ietf.org/<= wbr>proceedings/interim-2017-cfrg-01/slides/slides-interi
>m
>-2017-cfrg-01-sessa-argon2-00.pdf
>
>
>My sense from the constructive discussion that took place after Dmitry&= #39;s
>talk in Paris was that there are now no remaining serious objections to=
>the recommended parameters in the latest version of the draft:
>
>https://datatracker.ietf.org/doc/dr= aft-irtf-cfrg-argon2/
>
>
>If there are further substantive technical comments from the CFRG
>membership, the chairs would be grateful if they could be brought to th= e
>list in the next few days.
>
>Assuming we have indeed reached consensus, then we will be in a positio= n
>to move to last call for this ID.
>
>Thanks,
>
>Kenny (for the chairs)
>
>
>On 27/03/2017 11:51, "Cfrg on behalf of Dmitry Khovratovich"<= br> ><cfrg-bounces@irtf.org = on behalf of khovratovich@gmail.c= om> wrote:
>
>>Some comments on a new draft:VariantsArgon2 fills M bytes of memory= in T
>>iterations over
>> it, with M and T being the parameters supplied to Argon2 and deter= mining
>>its performance. Speed on a typical server is linear in the MT prod= uct.
>>
>>The Argon2 family has three variants: I, D, and
>> ID, which differ in the way of reusing memory that has been filled= . The
>>I variant makes queries with predictable addresses, whereas D deter= mines
>>the addresses on the fly depending on the current state (and thus t= he
>>password). The ID variant follows I for the
>> first half of the memory used and D for the rest and while overwri= ting.
>>Side-channelsThe side-channel attacks, which are of still rising >> concern in the security community, are applicable to the D variant= as
>>the memory addresses and thus information about the password or oth= er
>>secret inputs can be determined from the timing leaks. The I varian= t is
>>completely invulnerable to this attack, and
>> the ID variant provides only a constant factor improvement for the=
>>attacker.
>>Hardware and tradeoffsThe M and T parameters determine the cost of<= br> >>bruteforcing
>> passwords on custom hardware, which is proportional to M2T
>> if we follow the traditional time-area product metric. The time-me= mory
>>tradeoff analysis [2] shows that the bruteforce cost for the I vari= ant
>>can be changed to M2T/Q(M,T)
>> for some quality function Q. For instance, Q(230,1)=3D5,
>> Q(230,4)=3D2.5.
>>
>>The D variant is invulnerable to the approach [2],
>> and the savings factor in the ID variant is upper bounded by facto= r 2
>>for all parameters.
>>Defender tradeoff and ultimate
>> recommendationsIn public and private conversations with security >> architects in the industry we learned that the bottleneck in a sys= tem
>>employing the password-hashing function is the function latency rat= her
>>than memory costs. We then assume that a rational defender would li= ke to
>>maximize the bruteforce costs for the attacker
>> equipped with a list of hashes, salts, and timing information, for= fixed
>>computing time on the
>> defender=E2=80=99s machine.=C2=A0 In this assumption the defender = keeps the MT
>>product constant and maximizes the losses M/Q(M,T).
>> The authors of [2] provides us with attack cost estimates for cons= tant
>>MT =3D 228,230,232
>> (measured in iteration-bytes)
>>
>>We ultimately recommend the ID variant with T=3D1 and maximum M as = a
>>default setting for all environments, which is secure
>> against side-channel attacks and prohibit adversarial advantage on=
>>dedicated bruteforce hardware.
>>
>>
>>References[1]
>>=E2=80=9CEfficiently Computing Data-Independent
>> Memory-Hard Functions=E2=80=9D <http://eprint.iacr.or= g/2016/115.pdf>
>>[2]
>>=E2=80=9CTowards Practical Attacks on
>> Argon2i and Balloon Hashing=E2=80=9D=C2=A0 <http://ep= rint.iacr.org/2016/759.pdf>
>>
>>
>>
>>
>>
>>On Mon, Mar 27, 2017 at 12:46 PM, <internet-drafts@ietf.org> wrote:
>>
>>
>>A New Internet-Draft is available from the on-line Internet-Drafts<= br> >>directories.
>>This draft is a work item of the Crypto Forum of the IETF.
>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0: The memory-hard Argon2 password hash and
>>proof-of-work function
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0: Alex Biryukov
>>=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 Daniel Dinu
>>=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 Dmitry Khovratovich
>>=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 Simon Josefsson
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : d= raft-irtf-cfrg-argon2-02.txt
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0: 26
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 : 2017-03-27
>>
>>Abstract:
>>=C2=A0 =C2=A0This document describes the Argon2 memory-hard functio= n for password
>>=C2=A0 =C2=A0hashing and proof-of-work applications.=C2=A0 We provi= de an implementer
>>=C2=A0 =C2=A0oriented description together with sample code and tes= t vectors.=C2=A0 The
>>=C2=A0 =C2=A0purpose is to simplify adoption of Argon2 for Internet= protocols.
>>
>>
>>The IETF datatracker status page for this draft is:
>>https://datatracker.ietf.org/do= c/draft-irtf-cfrg-argon2/
>>
>>There are also htmlized versions available at:
>>https://tools.ietf.org/html/draft-= irtf-cfrg-argon2-02
>>https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-argon2-02
>>
>>A diff from the previous version is available at:
>>https://www.ietf.org/rfcdi= ff?url2=3Ddraft-irtf-cfrg-argon2-02
>>
>>
>>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 <http://tools.ietf.org>.
>>
>>Internet-Drafts are also available by anonymous FTP at:
>>ftp://ftp.ietf.org/internet-drafts/
>>
>>_______________________________________________
>>Cfrg mailing list
>>Cfrg@irtf.org
>>https://www.irtf.org/mailman/listinfo/cfrg
>>
>>
>>
>>
>>
>>
>>
>>--
>>Best regards,
>>Dmitry Khovratovich
>>
>>
>

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



--
=
Best= regards,
Dmitry Khovratovich
--089e0821eb4095f16f0554490900-- From nobody Fri Jul 14 12:29:18 2017 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 5FF4013171B for ; Fri, 14 Jul 2017 12:29:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, 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 v73_VuGDZO_g for ; Fri, 14 Jul 2017 12:29:14 -0700 (PDT) Received: from delta.cs.cinvestav.mx (delta.cs.cinvestav.mx [148.247.102.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B1FA12EAB0 for ; Fri, 14 Jul 2017 12:29:13 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by delta.cs.cinvestav.mx (Postfix) with ESMTP id B654B5C1462; Fri, 14 Jul 2017 14:28:57 -0500 (CDT) X-Virus-Scanned: amavisd-new at cs.cinvestav.mx Received: from delta.cs.cinvestav.mx ([127.0.0.1]) by localhost (delta.cs.cinvestav.mx [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QX-SPrFBaQ-X; Fri, 14 Jul 2017 14:28:56 -0500 (CDT) Received: by delta.cs.cinvestav.mx (Postfix, from userid 1507) id 38E385C1557; Fri, 14 Jul 2017 14:28:56 -0500 (CDT) Received: from localhost (localhost [127.0.0.1]) by delta.cs.cinvestav.mx (Postfix) with ESMTP id 299945C1462; Fri, 14 Jul 2017 14:28:56 -0500 (CDT) Date: Fri, 14 Jul 2017 14:28:56 -0500 (CDT) From: Francisco Rodriguez- Henriquez To: "cfrg@irtf.org" cc: Thomaz Oliveira , =?ISO-8859-15?Q?Julio_C=E9sar_Lopez?= , huseyin.hisil@yasar.edu.tr, Armando Faz In-Reply-To: Message-ID: References: User-Agent: Alpine 2.02 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-141290138-2002586352-1500058027=:16576" Content-ID: Archived-At: Subject: Re: [Cfrg] How to (pre-)compute a ladder [full C implementation] X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jul 2017 19:29:16 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---141290138-2002586352-1500058027=:16576 Content-Type: TEXT/PLAIN; CHARSET=ISO-8859-15; format=flowed Content-Transfer-Encoding: 8BIT Content-ID: Dear CFRG community, We would like to share with you a full C implementation of the ladder procedure described in the IACR pre-print 2017/264: "How to (pre-)compute a ladder" The C code can be downloaded from, https://github.com/armfazh/rfc7748_precomputed We are reporting the following benchmarked timings for 64-bit Intel architectures (table entries are given in clock cycles), X25519 Haswell Skylake proposed Keygen rtl ladder 90,895 72,571 Shared secret 138,962 107,942 S.Secret/Keygen speedup 1.529 1.487 overall D-H speedup 1.209 1.196 X448 Haswell Skylake Proposed Keygen rtl Ladder 401,902 322,040 Shared Secret 670,747 528,470 S.Secret/Keygen speedup 1.668 1.641 overall D-H speedup 1.251 1.243 Notes: + The Key generation reported above was computed using the proposed right-to-left ladder + The Shared secret was computed using the procedure described in the RFC 7748 memo + The D-H speedup is obtained as the ratio, 2*shared secret / (shared secret + key generation); + In the sense explained in our pre-print, our procedure fully complies with the RFC 7748 memo. With best regards, Thomaz Oliveira, Julio Lpez, Hseyin Hisil, Armando Faz-Hernndez and Francisco Rodrguez-Henrquez On Thu, 11 May 2017, Francisco Rodriguez- Henriquez wrote: > Dear CFRG community, > > We would like to draw your attention to an improved version of our IACR > pre-print 2017/264 now entitled: > > "How to (pre-)compute a ladder" > > In this revised version, we present an improved differential addition formula > that uses pre-computation to match the computational cost of the classical > Montgomery differential addition. > > Accordingly, our estimates suggest that a full implementation of our > pre-computable ladder proposal should outperform state-of-the-art software > implementations of the X25519 and X448 functions by a 40% speedup when > working in the fixed-point scenario. > > We would be delighted to receive feedback (including sightings of typos) from > the CFRG community. > > With best regards, > > Thomaz Oliveira, Julio Lpez, Hseyin Hisil and Francisco Rodrguez-Henrquez ---141290138-2002586352-1500058027=:16576-- From nobody Fri Jul 14 12:34:08 2017 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 04FE7129ADD for ; Fri, 14 Jul 2017 12:34:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, 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 j87REikMw7Ux for ; Fri, 14 Jul 2017 12:34:05 -0700 (PDT) Received: from delta.cs.cinvestav.mx (delta.cs.cinvestav.mx [148.247.102.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5BA4B126BFD for ; Fri, 14 Jul 2017 12:34:05 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by delta.cs.cinvestav.mx (Postfix) with ESMTP id 4ACDC5C1557; Fri, 14 Jul 2017 14:33:50 -0500 (CDT) X-Virus-Scanned: amavisd-new at cs.cinvestav.mx Received: from delta.cs.cinvestav.mx ([127.0.0.1]) by localhost (delta.cs.cinvestav.mx [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kf9MbDqbNpJb; Fri, 14 Jul 2017 14:33:48 -0500 (CDT) Received: by delta.cs.cinvestav.mx (Postfix, from userid 1507) id BD0735C1577; Fri, 14 Jul 2017 14:33:48 -0500 (CDT) Received: from localhost (localhost [127.0.0.1]) by delta.cs.cinvestav.mx (Postfix) with ESMTP id 93F8C5C1557; Fri, 14 Jul 2017 14:33:48 -0500 (CDT) Date: Fri, 14 Jul 2017 14:33:48 -0500 (CDT) From: Francisco Rodriguez- Henriquez To: Peter Dettman cc: "cfrg@irtf.org" , =?ISO-8859-15?Q?Julio_C=E9sar_Lopez?= , Thomaz Oliveira , huseyin.hisil@yasar.edu.tr, Armando Faz In-Reply-To: <02899a12-8cf7-c318-32ea-9491ec2a22c2@bouncycastle.org> Message-ID: References: <02899a12-8cf7-c318-32ea-9491ec2a22c2@bouncycastle.org> User-Agent: Alpine 2.02 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Archived-At: Subject: Re: [Cfrg] How to (pre-)compute a ladder [revised version] X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jul 2017 19:34:07 -0000 Hi Peter, Please see my reply below. Cheers, Francisco [on behalf of the authors] On Fri, 16 Jun 2017, Peter Dettman wrote: > Hi Francisco, > > I've updated my (java) implementations of X25519 and X448 in line with > your revised paper. My rough benchmark results for a complete ECDH are > -17.7% and -19.5% time required for X25519 and X448 respectively. Great! This is roughly in the same ballpark of what we are getting in our C implementation, which is available at, https://github.com/armfazh/rfc7748_precomputed [please check my previous email to this list] > These are perhaps slightly more modest than the paper's estimates. Your > paper already anticipates that (uncounted) field add/sub are significant > in practice. Right! This effect appears to be more significant in the case of X25519 than in the case of X448. > Part of the difference however is that my implementation of Algorithm 3 > handles the final 'q' bits using simple doublings, and removes redundant > cswaps - just as Algorithm 5 does. Of course Alg. 3 is just as presented > in RFC 7748, but it might be a fairer comparison to first apply to Alg. > 3 those of your optimizations that are applicable. > > Also, my (32-bit) X448 implementation (Alg. 5) required a carry > propagation for 'A' (line 10), due to tight bounds on limbs when > squaring D, E. I did the same for (32-bit) X25519 although I haven't yet > proved it necessary. OK! If you have time please compare against the C implementation mentioned above. > An idea: for fixed-base X25519, why not precompute one doubling? i.e. > just calculate (k/2) * 2P, needing only 2 final doublings (you even > already have S of order 4). I am not sure whether this extends to > precomputing (q-1) doublings. > > Another thought that occurred to me is that someone might get the idea > to use your fixed-base ladder with some other point. Couldn't this go > awry if that point were already "P + S" or similar? If so, a caution > somewhere in the paper on preconditions for the fixed point might be > advised. > > Regards, > Pete Dettman Thanks for both suggestions. We will carefully analyze both of them. Cheers, Francisco From nobody Fri Jul 14 12:54:46 2017 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 A639E131937 for ; Fri, 14 Jul 2017 12:54:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, 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 iTnZ2tX1umT2 for ; Fri, 14 Jul 2017 12:54:43 -0700 (PDT) Received: from delta.cs.cinvestav.mx (delta.cs.cinvestav.mx [148.247.102.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1EE3413193F for ; Fri, 14 Jul 2017 12:54:43 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by delta.cs.cinvestav.mx (Postfix) with ESMTP id 144735C13CA; Fri, 14 Jul 2017 14:54:28 -0500 (CDT) X-Virus-Scanned: amavisd-new at cs.cinvestav.mx Received: from delta.cs.cinvestav.mx ([127.0.0.1]) by localhost (delta.cs.cinvestav.mx [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ARCYpgCEAkqt; Fri, 14 Jul 2017 14:54:26 -0500 (CDT) Received: by delta.cs.cinvestav.mx (Postfix, from userid 1507) id 997265C1526; Fri, 14 Jul 2017 14:54:26 -0500 (CDT) Received: from localhost (localhost [127.0.0.1]) by delta.cs.cinvestav.mx (Postfix) with ESMTP id 869F75C13CA; Fri, 14 Jul 2017 14:54:26 -0500 (CDT) Date: Fri, 14 Jul 2017 14:54:26 -0500 (CDT) From: Francisco Rodriguez- Henriquez To: Mike Hamburg cc: "cfrg@irtf.org" , =?ISO-8859-15?Q?Julio_C=E9sar_Lopez?= , Thomaz Oliveira , huseyin.hisil@yasar.edu.tr, Armando Faz In-Reply-To: Message-ID: References: <02899a12-8cf7-c318-32ea-9491ec2a22c2@bouncycastle.org> User-Agent: Alpine 2.02 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Archived-At: Subject: Re: [Cfrg] How to (pre-)compute a ladder [revised version] X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jul 2017 19:54:45 -0000 On May 12, 2017, at 2:15 PM, Mike Hamburg wrote: > Hello Francisco et al, > This is a clever and useful piece of work. It's a good intermediate > between just using the standard Montgomery ladder for everything, and > going to a full Edwards implementation with combs or something. It > especially seems useful where power analysis resistance is required, > because other precomputation methods usually aren't suitable. The RTL > Montgomery ladder (or Joye double-add ladder) is already known to be > useful in this situation, at least with some modification to prevent > coordinates from staying the same between iterations. Since you're > speeding up the RTL Montgomery ladder, your optimization can slot right > in to some implementations. Hi Mike, Thanks for your comments and sorry for this really slow reply :) I agree with you about the fact that the RTL Montgomery ladder by Joye was already known for performing this feature. > You should probably compare to existing Edwards precomputation methods > in your paper, since they are the likely alternative to your technique. > In particular, I noticed that you compared against the EBACS version of > Ed448-Goldilocks. With a fixed base point, your method uses 41% less > time for the Montgomery ladder with a 25kiB table. However, the EBACS > version of Ed448-Goldilocks doesn't use the Montgomery ladder for > fixed-base scalarmul. Instead it uses a combs algorithm, which uses a > 15kiB table and takes about 70% less time than the Montgomery ladder; > see https://bench.cr.yp.to/results-dh.html. Libdecaf likewise uses > precomputed combs for fixed-base scalarmul. But your new technique is > certainly simpler. I agree with you, there are faster methods to perform pre-computation, which offer [some] protection against side-channel attacks. In our work, we were specifically targeting the RFC 7748 Memo, and hence we only meant to compare against ladder procedures for computing the scalar multiplication. I believe that the tradeoffs between the simplicity/elegance/beauty of the ladders Vs. the efficiency of regular recoding + other methods of pre-computation, was already debated in this list :) Cheers, Francisco > Cheers, > -- Mike From nobody Sun Jul 16 19:09:25 2017 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 CEAA5129A97 for ; Sun, 16 Jul 2017 19:09:23 -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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=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 f2wIrzMibPYj for ; Sun, 16 Jul 2017 19:09:21 -0700 (PDT) Received: from mail-it0-x236.google.com (mail-it0-x236.google.com [IPv6:2607:f8b0:4001:c0b::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 AE7F9126C0F for ; Sun, 16 Jul 2017 19:09:21 -0700 (PDT) Received: by mail-it0-x236.google.com with SMTP id l132so6847386ita.1 for ; Sun, 16 Jul 2017 19:09:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:from:date:message-id:subject:to; bh=d02pySssvugb9fqgIE9nOTK6B5eXiUrJdr72L6hhABQ=; b=ueKWhbBZi8N5WunqaBwoy1RBUJizTCaQanqGmeK+FbjldXQVWaVNwHg49C2tL/x71V Ll5VRkRndIJ+XfNi4LGIaGb4hQOkh7ICBCh7HU3JwMymHRe3trtRRoC9Ob16xGkcRPBa wLArOt+Bhf6QUklzphWxXtzXwe1jhU1u9nGPOjQGaf3umH6mLQQxgsrsw+fYHypmQCTI elWeiEcWXWQ+AdfvgxVGxHV+kIOp+JGNd9q+fWyoIYv0GummgSoZasdlg8s2nXQ6CCy9 M0J6Z7YCzC8JWa4RHO9f5txuyAA4kCOq3D/mMn+pnBF63asZrcDl18ZgkkX7ujggnTh8 16MQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:from:date:message-id:subject :to; bh=d02pySssvugb9fqgIE9nOTK6B5eXiUrJdr72L6hhABQ=; b=bH+mc6uGbBJXyAGgq2CEIdehzwzcL0Ylsx2imhNuaEElhQi8ui29udYbznItJUk4yn uh+qhkGuPMEf1BJQaw7r3Ib0wyaa8xFqTGMSxhZa5RT5FkkFWHvm1QAeSNkT0mtot0xN kAVuCf6XKZBm65I9hT8H8H/uFehozEgdneycsn/VZl+8LqgO3cOZnKg+e+Dlx3gOS7CG BqUFQk2Eu7t7CeNPl63jWiZMv5jaJCpuwIakjBcOJbCwps+kAdlvK4Q0ybNdXaZwxXH2 wAPzlR4Z8sFUu9OT5ZxTtSbzJE4Q7j1CjsocolkuZNPHSKbe9fyjsuB3J+TPsJxiIsb8 ioKQ== X-Gm-Message-State: AIVw112MUxCg+1r/OK+M8XrrJPjYw4AOmYPlz19wInB13mGaT9Gq5A+H kqMQFegE4EPrHSC9NK4Dih9x1Vhe/zKo7us= X-Received: by 10.36.55.145 with SMTP id r139mr3794391itr.117.1500257360602; Sun, 16 Jul 2017 19:09:20 -0700 (PDT) MIME-Version: 1.0 Sender: alangley@gmail.com Received: by 10.79.38.216 with HTTP; Sun, 16 Jul 2017 19:09:20 -0700 (PDT) From: Adam Langley Date: Sun, 16 Jul 2017 19:09:20 -0700 X-Google-Sender-Auth: APp13jiHlf4Tvvw9_IPDABIwWwU Message-ID: To: cfrg@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [Cfrg] Updated bounds in AES-GCM-SIV paper X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jul 2017 02:09:24 -0000 Dear CFRG, We would like to thank Yannick Seurin and Tetsu Iwata for alerting us to the fact that we had erroneously assumed that one of the terms in the security bounds of AES-GCM-SIV was negligible when, for indistinguishability, it was not. Thus, while the security proof was correct, the example concrete bounds were over optimistic, most notably for very large messages. This was most evident in Fig 4. We have updated the paper[1] to correct this mistake and we draw the group's attention to the revised figure four (now called Table 1). For typical uses, thankfully, the difference is not material but for we wish to highlight that one cannot encrypt many messages of many-gigabytes using AES-GCM-SIV, in contrast to what the figures previously suggested. However, even in such a case of very long messages, the overall number of blocks encrypted safely is still significantly higher than previous schemes. [1] https://eprint.iacr.org/2017/168 Cheers AGL -- Adam Langley agl@imperialviolet.org https://www.imperialviolet.org From nobody Tue Jul 18 11:29:10 2017 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 ABEA1128CFF for ; Tue, 18 Jul 2017 11:29: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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-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 wiNbfm0V25tp for ; Tue, 18 Jul 2017 11:29:05 -0700 (PDT) Received: from smtp-p02.blackberry.com (smtp-p02.blackberry.com [208.65.78.89]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C8A6131BAD for ; Tue, 18 Jul 2017 11:29:05 -0700 (PDT) Received: from xct103cnc.rim.net ([10.65.161.203]) by mhs214cnc.rim.net with ESMTP/TLS/DHE-RSA-AES256-SHA; 18 Jul 2017 14:29:03 -0400 Received: from XCT112CNC.rim.net (10.65.161.212) by XCT103CNC.rim.net (10.65.161.203) with Microsoft SMTP Server (TLS) id 14.3.319.2; Tue, 18 Jul 2017 14:29:02 -0400 Received: from XMB116CNC.rim.net ([fe80::45d:f4fe:6277:5d1b]) by XCT112CNC.rim.net ([::1]) with mapi id 14.03.0319.002; Tue, 18 Jul 2017 14:29:02 -0400 From: Dan Brown To: Sharon Goldberg , "cfrg@irtf.org" CC: "jan@ns1.com" , Dimitrios Papadopoulos , Leonid Reyzin Thread-Topic: [Cfrg] draft-goldbe-vrf: Verifiable Random Functions Thread-Index: AQHS+vM6+DG9anuMcU+xW6RwdHg7uaJZ5Flg Date: Tue, 18 Jul 2017 18:29:02 +0000 Message-ID: <810C31990B57ED40B2062BA10D43FBF501B63B22@XMB116CNC.rim.net> References: In-Reply-To: Accept-Language: en-US, en-CA Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.160.251] Content-Type: multipart/alternative; boundary="_000_810C31990B57ED40B2062BA10D43FBF501B63B22XMB116CNCrimnet_" MIME-Version: 1.0 Archived-At: Subject: Re: [Cfrg] draft-goldbe-vrf: Verifiable Random Functions X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jul 2017 18:29:09 -0000 --_000_810C31990B57ED40B2062BA10D43FBF501B63B22XMB116CNCrimnet_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgU2hhcm9uIGFuZCBDRlJHLA0KDQpPbiBWUkZzLCBteSB1bmNlcnRhaW4gY29tbWVudHMgdG8g Y29uc2lkZXIgYXQgeW91ciBsZWlzdXJlOg0KDQpJcyBpdCBmYWlyIHRvIHNheSBWUkZzIGFyZSBy ZWxhdGl2ZWx5IG5ldz8gIElmIHNvLCB0aGVuIG1heWJlIGEgbGl0dGxlIG1vcmUgY2F1dGlvbiBp cyBuZWVkZWQgYWJvdXQgdGhlaXIgdXNlLiAgSXQgc2VlbXMgYSB0YWQgaGFzdHkgdGhhdCBpdCBp cyBiZWluZyB1c2VkIGFscmVhZHkuDQoNClRvIG1lLCBpdCBzZWVtcyB0aGF0IFZSRnMgYXJlIGJh c2ljYWxseSBzaWduYXR1cmVzLCB3aXRoIGFuIGV4dHJhIGZlYXR1cmUuICBNeSBjb25jZXJuIGlz IHRoYXQgdGhpcyBleHRyYSBmZWF0dXJlIG1pZ2h0IGdldCBvdmVydXNlZCwgYmVmb3JlIGl0IGlz IHRob3JvdWdobHkgcmV2aWV3ZWQuDQoNCkl0IGlzIHVuc3VycHJpc2luZyB0byBtZSB0aGF0IHJh bmRvbSBvcmFjbGUgbW9kZWwgcHJvb2YgY2FuIHByb3ZlIHRoZSBvdXRwdXQgb2YgYSBoYXNoIHRv IGJlIHJhbmRvbS4gIE15IGludHVpdGl2ZSBjb25jZXJuIGlzIHRoYXQgYXQgbGVhc3QgaW5mb3Jt YWxseSwgdGhpcyBpcyBraW5kIG9mIGNpcmN1bGFyLiAgSGFzaGVzIG9mdGVuIGhhdmUgc29tZSBu b24tcmFuZG9tLWlzaCBwcm9wZXJ0aWVzIHRoYXQgbWlnaHQgYWZmZWN0IHRoZSBleHRyYSBzZWN1 cml0eSAob3ZlciBzaWduYXR1cmVzKSB0aGF0IFZSRnMgYXJlIGFpbWluZyBmb3IuICBJIGd1ZXNz IEkgd291bGQgbXVjaCBwcmVmZXIgYSBwcm9vZiBzYXlpbmcgaWYgdGhlIGhhc2ggaGFzICh3ZWxs LXN0dWRpZWQpIHByb3BlcnRpZXMgWFlaLCB0aGVuIHlvdXIgY29uc3RydWN0aW9uIGFyZSBWUkZz LiAgKE1heWJlIHlvdSBoYXZlIHRoaXMgYWxyZWFkeT8gIElmIHNvLCB0aGVuIHRlbGwgbWUgc28u KQ0KDQpTaW5jZSwgVlJGcyByZXF1aXJlIHNlbmRpbmcgdGhlIOKAnHByb29mc+KAnSBvbiB0aGUg d2lyZSwgSSBmaW5kIGl0IGhhcmQgdG8gc2VlIGhvdyBpdCBjb3VsZCBiZSB1c2VkIHRvIHByZXZl bnQgZGljdGlvbmFyeSBhdHRhY2tzLiAgSSBhc3N1bWUgdGhhdCB5b3UgYXJlIHNheWluZyB0aGUg cHJvb2ZzIG11c3QgYmUgZW5jcnlwdGVkIHdoZW4gb25lIG5lZWRzIHRvIGF2b2lkIGRpY3Rpb25h cnkgbW9kZWxzPyAgSSBzdXBwb3NlIGFsbCB0aGUgZGV0YWlscyBhcmUgdGhlcmUgaW4gSS1EIGFu ZCBwYXBlcnMsIGJ1dCBmb3Igbm93LCBJIGFtIGNvbmZ1c2VkIGFib3V0IHRoZSB0aHJlYXQgbW9k ZWwgKHdoaWNoIHBhcnRpZXMgaGF2ZSBrZXlzLCBldGMuLCBpZiB0aGV5IHJlcXVpcmUgYSBzZWN1 cmUgY2hhbm5lbCBhbmQgbXV0dWFsIHRydXN0LCB3aHkganVzdCB1c2UgcGxhaW4gb2xkIGhhc2gs 4oCmKS4gVG8gcmVzaXN0IGRpY3Rpb25hcnkgYXR0YWNrcywgd2VyZSBhbHJlYWR5IGhhdmUgUEFL RXMgYW5kIFBCSGFzaGluZy4gIE5vdyB0aGlzPw0KDQpGaW5hbGx5LCBvbiBhIGJpa2VzaGVkLWNv bG9yaW5nIG5vdGUsIEkgb2JqZWN0IHRvIHRoZSBuYW1lIOKAnHZlcmlmaWFibGUgcmFuZG9tIGZ1 bmN0aW9u4oCdLCBvbiBzZXZlcmFsIGdyb3VuZHMuDQoNCg0KICAxLiAgSXQgaXMgbm90IGEgZnVu Y3Rpb24uICBJdCBpcyBhdCBsZWFzdCBmb3VyIGZ1bmN0aW9ucywga2V5Z2VuLCBzaWduLCB2ZXJp ZnksIGFuZCBoYXNoaWZ5Lg0KICAyLiAgSWYgeW91IG1ha2UgaXQgaW50byBhIGtleWVkIGZ1bmN0 aW9uIEZfc2sobSksIGFzIGluIHByb29mdG9oYXNoKHNpZ25fc2sobSkpLCBpdCBpcyBub3QgdmVy aWZpYWJsZS4NCiAgMy4gIFZlcmlmaWNhdGlvbiByZXF1aXJlcyB0aGUgaW50ZXJtZWRpYXRlIHBy b29mLCB3aGljaCBpcyBjZXJ0YWlubHkgbm90IGV2ZW4gcHNldWRvcmFuZG9tIChpdCBpcyBlYXN5 IHRvIGRpc3Rpbmd1aXNoIHZhbGlkIHNpZ25hdHVyZXMgZnJvbSByYW5kb20pLg0KICA0LiAgSXQg aXMgcHNldWRvcmFuZG9tLCBub3QgcmFuZG9tLiAgKFRoZSBrZXlzIGFyZSByYW5kb20sIGJ1dCBt YW55IGNyeXB0byBoYXMga2V5cywgd2l0aG91dCBoYXZpbmcg4oCccmFuZG9t4oCdIGluIGl0cyBu YW1lOiBlbmNyeXB0aW9uLCBNQUMsIHNpZ25hdHVyZXMsIGtleSBleGNoYW5nZSwg4oCmLCB0aGV5 IGFsc28gZG9u4oCZdCB2ZXJpZmlhYmxlIG9yIHJhbmRvbSBpbiB0aGVpciBuYW1lcyBlaXRoZXIu KQ0KICA1LiAgVGhlIHNpbWlsYXIgcGhyYXNlIOKAnHZlcmlmaWFibHkgcmFuZG9t4oCdLCBhbGJl aXQgYXMgYSBtaXNub21lciwgaGFzIHBhc3QgcHJlY2VkZW50cywgc2VlIE5JU1QgUC0yNTYgYW5k IEJyYWlucG9vbCwgZXRjLiAgV2hlbiBJIHNlZSBWUkYsIEkgdGhpbmsgYSBmdW5jdGlvbiwgdGhh dCBhaW1zIHRvIFZSIGluIHRoYXQgc2Vuc2UsIGFuZCBncmVhdCwgbm93IHdlIGNhbiBpbXByb3Zl IG9uIEJyYWlucG9vbCwgZXRjLg0KICA2LiAg4oCcUmFuZG9tIGZ1bmN0aW9u4oCdIHNob3VsZCBi ZSByZXNlcnZlZCBmb3IgdGhlIGlkZWFsIHJhbmRvbSBtYXBwaW5nIGNvbmNlcHQsIGZvciBleGFt cGxlLCBhcyBzdHVkaWVkIGJ5IEZsYWpvbGV0LU9kbHl6a28gKG9rIHRoZXkgb25seSBzdHVkaWVk IHRoZSBjYXNlIG9mIGVxdWFsIHNpemUgZG9tYWluIGFuZCByYW5nZSkuICBUaGUgcmFuZG9tIG9y YWNsZSBtb2RlbCwgaXMgdGhlIGlkZWEgb2YgYXBwcm94aW1hdGluZyB0aGlzIGlkZWFsLCBldGMu ICBBbiBhY3R1YWwgYXBwcm94aW1hdGlvbiBzaG91bGQgbm90IGJlIG5hbWUgYXMgdGhlIGlkZWFs IChzb3JyeSwgSeKAmW0ga2luZCBvZiByZXBlYXRpbmcgbXkgcG9pbnQgNCkuDQoNClBsZWFzZSBm b3JnaXZlIHRoZSBmYWN0IHRoYXQgbXkgY29tbWVudHMgYWJvdmUgYXJlIG5vdCB2ZXJ5IGNvbnN0 cnVjdGl2ZSAob3IgaWYgdGhlIHRvbmUgaXMgd3JvbmcpLiAgVGhpcyBpcyBhIG5ldyB0b3BpYyBm b3IgbWUsIHNvIEkgYW0gcmVsdWN0YW50IHRvbyBtYW55IHN1Z2dlc3Rpb25zLiAgTm9uZXRoZWxl c3MsIEkgc3VnZ2VzdCAoMCkgd2FpdGluZyBhIGxpdHRsZSwgKDEpIGEgbm9uLXJhbmRvbS1vcmFj bGUgc2VjdXJpdHkgcHJvb2YgKGlmIHlvdSBkb27igJl0IGhhdmUgaXQgeWV0KSwgKDIpIHJlLW5h bWluZyB0aGUgc2NoZW1lIHRvIHNvbWV0aGluZyBsaWtlIHJlLWhhc2hhYmxlIChvciBkaWdlc3Rp YmxlKSBzaWduYXR1cmVzIChhbmQgcmUtbmFtZSB0aGUgdmFyaW91cyBwYXJ0cywgaS5lLiBwcm9v ZiAtPiBzaWduYXR1cmUsIGV0Yy4pLg0KDQpCZXN0IHJlZ2FyZHMsDQoNCkRhbg0KDQoNCkZyb206 IENmcmcgW21haWx0bzpjZnJnLWJvdW5jZXNAaXJ0Zi5vcmddIE9uIEJlaGFsZiBPZiBTaGFyb24g R29sZGJlcmcNClNlbnQ6IFdlZG5lc2RheSwgSnVseSAxMiwgMjAxNyA1OjQyIEFNDQpUbzogY2Zy Z0BpcnRmLm9yZw0KQ2M6IGphbkBuczEuY29tOyBEaW1pdHJpb3MgUGFwYWRvcG91bG9zIDxkaXBh cGFkb0B1bWQuZWR1PjsgTGVvbmlkIFJleXppbiA8cmV5emluQGNzLmJ1LmVkdT4NClN1YmplY3Q6 IFtDZnJnXSBkcmFmdC1nb2xkYmUtdnJmOiBWZXJpZmlhYmxlIFJhbmRvbSBGdW5jdGlvbnMNCg0K RGVhciBDRlJHLA0KDQpJJ20gcHJlc2VudGluZyBhdCBuZXh0IHdlZWsncyBtZWV0aW5nIG9uIFZl cmlmaWFibGUgUmFuZG9tIEZ1bmN0aW9ucy4gQSBWUkYgaXMgdGhlIHB1YmxpYy1rZXkgdmVyc2lv biBvZiBrZXllZCBjcnlwdG9ncmFwaGljIGhhc2guIE9ubHkgdGhlIGhvbGRlciBvZiB0aGUgVlJG IHNlY3JldCBrZXkgY2FuIGNvbXB1dGUgdGhlIGhhc2gsIGJ1dCBhbnlvbmUgd2l0aCB0aGUgcHVi bGljIGtleSBjYW4gdmVyaWZ5IGl0LiAgVlJGcyBjYW4gYmUgdXNlZCB0byBwcmV2ZW50IGRpY3Rp b25hcnkgYXR0YWNrcyBvbiBoYXNoLWJhc2VkIGRhdGEgc3RydWN0dXJlcywgYW5kIGhhdmUgYXBw bGljYXRpb25zIHRvIGtleSB0cmFuc3BhcmVuY3kgKENPTklLUyksIEROU1NFQyAoTlNFQzUpLCBh bmQgY3J5cHRvY3VycmVuY2llcyAoQWxnb3JhbmQpLg0KDQpJbiBhZHZhbmNlIG9mIHRoZSBtZWV0 aW5nLCBwbGVhc2Ugc2VlOg0KDQoxKSBPdXIgc3Vic3RhbnRpYWxseSB1cGRhdGVkIC0wMSBkcmFm dDoNCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWdvbGRiZS12cmYvDQoN CjIpIE91ciBwcm9qZWN0IHBhZ2UsIHdpdGggbGlua3MgdG8gdmFyaW91cyBWUkYgaW1wbGVtZW50 YXRpb25zOg0KaHR0cHM6Ly93d3cuY3MuYnUuZWR1L35nb2xkYmUvcHJvamVjdHMvdnJmDQoNCkNv bW1lbnRzIHdlbGNvbWUuICBUaGFua3MsDQoNClNoYXJvbg0KDQotLQ0KU2hhcm9uIEdvbGRiZXJn DQpDb21wdXRlciBTY2llbmNlLCBCb3N0b24gVW5pdmVyc2l0eQ0KaHR0cDovL3d3dy5jcy5idS5l ZHUvfmdvbGRiZQ0K --_000_810C31990B57ED40B2062BA10D43FBF501B63B22XMB116CNCrimnet_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLk1zb0xpc3RQYXJhZ3JhcGgs IGxpLk1zb0xpc3RQYXJhZ3JhcGgsIGRpdi5Nc29MaXN0UGFyYWdyYXBoDQoJe21zby1zdHlsZS1w cmlvcml0eTozNDsNCgltYXJnaW4tdG9wOjBpbjsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1hcmdp bi1ib3R0b206MGluOw0KCW1hcmdpbi1sZWZ0Oi41aW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0 Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsc2Vy aWY7fQ0KcC5tc29ub3JtYWwwLCBsaS5tc29ub3JtYWwwLCBkaXYubXNvbm9ybWFsMA0KCXttc28t c3R5bGUtbmFtZTptc29ub3JtYWw7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2lu LXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDow aW47DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixz ZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBs eTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0 O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQt c2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KQHBhZ2Ug V29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAx LjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi8q IExpc3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0LWlkOjY4MzU1NzY0OTsN Cgltc28tbGlzdC10eXBlOmh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6MzgyOTI0NTc4 IDY3Njk4NzAzIDY3Njk4NzEzIDY3Njk4NzE1IDY3Njk4NzAzIDY3Njk4NzEzIDY3Njk4NzE1IDY3 Njk4NzAzIDY3Njk4NzEzIDY3Njk4NzE1O30NCkBsaXN0IGwwOmxldmVsMQ0KCXttc28tbGV2ZWwt dGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LS4yNWluO30NCkBsaXN0IGwwOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDphbHBoYS1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwwOmxldmVs Mw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpyb21hbi1sb3dlcjsNCgltc28tbGV2ZWwtdGFi LXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOnJpZ2h0Ow0KCXRleHQtaW5k ZW50Oi05LjBwdDt9DQpAbGlzdCBsMDpsZXZlbDQNCgl7bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9 DQpAbGlzdCBsMDpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7 DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps ZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMDpsZXZlbDYNCgl7bXNvLWxldmVs LW51bWJlci1mb3JtYXQ6cm9tYW4tbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpyaWdodDsNCgl0ZXh0LWluZGVudDotOS4wcHQ7fQ0K QGxpc3QgbDA6bGV2ZWw3DQoJe21zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDA6bGV2 ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmFscGhhLWxvd2VyOw0KCW1zby1sZXZlbC10 YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotLjI1aW47fQ0KQGxpc3QgbDA6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0 OnJvbWFuLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246cmlnaHQ7DQoJdGV4dC1pbmRlbnQ6LTkuMHB0O30NCm9sDQoJe21hcmdpbi1i b3R0b206MGluO30NCnVsDQoJe21hcmdpbi1ib3R0b206MGluO30NCi0tPjwvc3R5bGU+PCEtLVtp ZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4 PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8 bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0i MSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5 IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9Ildv cmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkhpIFNo YXJvbiBhbmQgQ0ZSRyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+T24gVlJGcywgbXkgdW5jZXJ0YWluIGNvbW1l bnRzIHRvIGNvbnNpZGVyIGF0IHlvdXIgbGVpc3VyZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+SXMgaXQgZmFp ciB0byBzYXkgVlJGcyBhcmUgcmVsYXRpdmVseSBuZXc/Jm5ic3A7IElmIHNvLCB0aGVuIG1heWJl IGEgbGl0dGxlIG1vcmUgY2F1dGlvbiBpcyBuZWVkZWQgYWJvdXQgdGhlaXIgdXNlLiZuYnNwOyBJ dCBzZWVtcyBhIHRhZCBoYXN0eSB0aGF0IGl0IGlzIGJlaW5nIHVzZWQgYWxyZWFkeS48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZiI+VG8gbWUsIGl0IHNlZW1zIHRoYXQgVlJGcyBhcmUgYmFzaWNhbGx5IHNpZ25hdHVy ZXMsIHdpdGggYW4gZXh0cmEgZmVhdHVyZS4mbmJzcDsgTXkgY29uY2VybiBpcyB0aGF0IHRoaXMg ZXh0cmEgZmVhdHVyZSBtaWdodCBnZXQgb3ZlcnVzZWQsIGJlZm9yZSBpdCBpcyB0aG9yb3VnaGx5 IHJldmlld2VkLiZuYnNwOw0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkl0IGlzIHVuc3VycHJpc2luZyB0byBt ZSB0aGF0IHJhbmRvbSBvcmFjbGUgbW9kZWwgcHJvb2YgY2FuIHByb3ZlIHRoZSBvdXRwdXQgb2Yg YSBoYXNoIHRvIGJlIHJhbmRvbS4mbmJzcDsgTXkgaW50dWl0aXZlIGNvbmNlcm4gaXMgdGhhdCBh dCBsZWFzdCBpbmZvcm1hbGx5LCB0aGlzIGlzIGtpbmQgb2YgY2lyY3VsYXIuJm5ic3A7DQogSGFz aGVzIG9mdGVuIGhhdmUgc29tZSBub24tcmFuZG9tLWlzaCBwcm9wZXJ0aWVzIHRoYXQgbWlnaHQg YWZmZWN0IHRoZSBleHRyYSBzZWN1cml0eSAob3ZlciBzaWduYXR1cmVzKSB0aGF0IFZSRnMgYXJl IGFpbWluZyBmb3IuJm5ic3A7IEkgZ3Vlc3MgSSB3b3VsZCBtdWNoIHByZWZlciBhIHByb29mIHNh eWluZyBpZiB0aGUgaGFzaCBoYXMgKHdlbGwtc3R1ZGllZCkgcHJvcGVydGllcyBYWVosIHRoZW4g eW91ciBjb25zdHJ1Y3Rpb24gYXJlIFZSRnMuJm5ic3A7IChNYXliZQ0KIHlvdSBoYXZlIHRoaXMg YWxyZWFkeT8mbmJzcDsgSWYgc28sIHRoZW4gdGVsbCBtZSBzby4pPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPlNp bmNlLCBWUkZzIHJlcXVpcmUgc2VuZGluZyB0aGUg4oCccHJvb2Zz4oCdIG9uIHRoZSB3aXJlLCBJ IGZpbmQgaXQgaGFyZCB0byBzZWUgaG93IGl0IGNvdWxkIGJlIHVzZWQgdG8gcHJldmVudCBkaWN0 aW9uYXJ5IGF0dGFja3MuJm5ic3A7IEkgYXNzdW1lIHRoYXQgeW91IGFyZSBzYXlpbmcgdGhlIHBy b29mcyBtdXN0DQogYmUgZW5jcnlwdGVkIHdoZW4gb25lIG5lZWRzIHRvIGF2b2lkIGRpY3Rpb25h cnkgbW9kZWxzPyZuYnNwOyBJIHN1cHBvc2UgYWxsIHRoZSBkZXRhaWxzIGFyZSB0aGVyZSBpbiBJ LUQgYW5kIHBhcGVycywgYnV0IGZvciBub3csIEkgYW0gY29uZnVzZWQgYWJvdXQgdGhlIHRocmVh dCBtb2RlbCAod2hpY2ggcGFydGllcyBoYXZlIGtleXMsIGV0Yy4sIGlmIHRoZXkgcmVxdWlyZSBh IHNlY3VyZSBjaGFubmVsIGFuZCBtdXR1YWwgdHJ1c3QsIHdoeSBqdXN0IHVzZQ0KIHBsYWluIG9s ZCBoYXNoLOKApikuIFRvIHJlc2lzdCBkaWN0aW9uYXJ5IGF0dGFja3MsIHdlcmUgYWxyZWFkeSBo YXZlIFBBS0VzIGFuZCBQQkhhc2hpbmcuJm5ic3A7IE5vdyB0aGlzPzxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5G aW5hbGx5LCBvbiBhIGJpa2VzaGVkLWNvbG9yaW5nIG5vdGUsIEkgb2JqZWN0IHRvIHRoZSBuYW1l IOKAnHZlcmlmaWFibGUgcmFuZG9tIGZ1bmN0aW9u4oCdLCBvbiBzZXZlcmFsIGdyb3VuZHMuPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8b2wgc3R5bGU9Im1hcmdpbi10b3A6MGlu IiBzdGFydD0iMSIgdHlwZT0iMSI+DQo8bGkgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxl PSJtYXJnaW4tbGVmdDowaW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp ZiI+SXQgaXMgbm90IGEgZnVuY3Rpb24uJm5ic3A7IEl0IGlzIGF0IGxlYXN0IGZvdXIgZnVuY3Rp b25zLCBrZXlnZW4sIHNpZ24sIHZlcmlmeSwgYW5kIGhhc2hpZnkuPG86cD48L286cD48L3NwYW4+ PC9saT48bGkgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDowaW47 bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+SWYgeW91IG1ha2UgaXQg aW50byBhIGtleWVkIGZ1bmN0aW9uIEZfc2sobSksIGFzIGluIHByb29mdG9oYXNoKHNpZ25fc2so bSkpLCBpdCBpcyBub3QgdmVyaWZpYWJsZS4mbmJzcDsNCjxvOnA+PC9vOnA+PC9zcGFuPjwvbGk+ PGxpIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MGluO21zby1s aXN0OmwwIGxldmVsMSBsZm8xIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPlZlcmlmaWNhdGlvbiByZXF1aXJl cyB0aGUgaW50ZXJtZWRpYXRlIHByb29mLCB3aGljaCBpcyBjZXJ0YWlubHkgbm90IGV2ZW4gcHNl dWRvcmFuZG9tIChpdCBpcyBlYXN5IHRvIGRpc3Rpbmd1aXNoIHZhbGlkDQogc2lnbmF0dXJlcyBm cm9tIHJhbmRvbSkuPG86cD48L286cD48L3NwYW4+PC9saT48bGkgY2xhc3M9Ik1zb0xpc3RQYXJh Z3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDowaW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZiI+SXQgaXMgcHNldWRvcmFuZG9tLCBub3QgcmFuZG9tLiZuYnNwOyAoVGhl IGtleXMgYXJlIHJhbmRvbSwgYnV0IG1hbnkgY3J5cHRvIGhhcyBrZXlzLCB3aXRob3V0IGhhdmlu ZyDigJxyYW5kb23igJ0gaW4gaXRzIG5hbWU6DQogZW5jcnlwdGlvbiwgTUFDLCBzaWduYXR1cmVz LCBrZXkgZXhjaGFuZ2UsIOKApiwgdGhleSBhbHNvIGRvbuKAmXQgdmVyaWZpYWJsZSBvciByYW5k b20gaW4gdGhlaXIgbmFtZXMgZWl0aGVyLik8bzpwPjwvbzpwPjwvc3Bhbj48L2xpPjxsaSBjbGFz cz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjBpbjttc28tbGlzdDpsMCBs ZXZlbDEgbGZvMSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5UaGUgc2ltaWxhciBwaHJhc2Ug4oCcdmVyaWZp YWJseSByYW5kb23igJ0sIGFsYmVpdCBhcyBhIG1pc25vbWVyLCBoYXMgcGFzdCBwcmVjZWRlbnRz LCBzZWUgTklTVCBQLTI1NiBhbmQgQnJhaW5wb29sLCBldGMuJm5ic3A7DQogV2hlbiBJIHNlZSBW UkYsIEkgdGhpbmsgYSBmdW5jdGlvbiwgdGhhdCBhaW1zIHRvIFZSIGluIHRoYXQgc2Vuc2UsIGFu ZCBncmVhdCwgbm93IHdlIGNhbiBpbXByb3ZlIG9uIEJyYWlucG9vbCwgZXRjLjxvOnA+PC9vOnA+ PC9zcGFuPjwvbGk+PGxpIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxl ZnQ6MGluO21zby1saXN0OmwwIGxldmVsMSBsZm8xIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPuKAnFJhbmRv bSBmdW5jdGlvbuKAnSBzaG91bGQgYmUgcmVzZXJ2ZWQgZm9yIHRoZSBpZGVhbCByYW5kb20gbWFw cGluZyBjb25jZXB0LCBmb3IgZXhhbXBsZSwgYXMgc3R1ZGllZCBieSBGbGFqb2xldC1PZGx5emtv DQogKG9rIHRoZXkgb25seSBzdHVkaWVkIHRoZSBjYXNlIG9mIGVxdWFsIHNpemUgZG9tYWluIGFu ZCByYW5nZSkuJm5ic3A7IFRoZSByYW5kb20gb3JhY2xlIG1vZGVsLCBpcyB0aGUgaWRlYSBvZiBh cHByb3hpbWF0aW5nIHRoaXMgaWRlYWwsIGV0Yy4mbmJzcDsgQW4gYWN0dWFsIGFwcHJveGltYXRp b24gc2hvdWxkIG5vdCBiZSBuYW1lIGFzIHRoZSBpZGVhbCAoc29ycnksIEnigJltIGtpbmQgb2Yg cmVwZWF0aW5nIG15IHBvaW50IDQpLjxvOnA+PC9vOnA+PC9zcGFuPjwvbGk+PC9vbD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5QbGVhc2UgZm9yZ2l2 ZSB0aGUgZmFjdCB0aGF0IG15IGNvbW1lbnRzIGFib3ZlIGFyZSBub3QgdmVyeSBjb25zdHJ1Y3Rp dmUgKG9yIGlmIHRoZSB0b25lIGlzIHdyb25nKS4mbmJzcDsgVGhpcyBpcyBhIG5ldyB0b3BpYyBm b3IgbWUsIHNvIEkgYW0gcmVsdWN0YW50IHRvbyBtYW55IHN1Z2dlc3Rpb25zLiZuYnNwOyBOb25l dGhlbGVzcywNCiBJIHN1Z2dlc3QgKDApIHdhaXRpbmcgYSBsaXR0bGUsICgxKSBhIG5vbi1yYW5k b20tb3JhY2xlIHNlY3VyaXR5IHByb29mIChpZiB5b3UgZG9u4oCZdCBoYXZlIGl0IHlldCksICgy KSByZS1uYW1pbmcgdGhlIHNjaGVtZSB0byBzb21ldGhpbmcgbGlrZSByZS1oYXNoYWJsZSAob3Ig ZGlnZXN0aWJsZSkgc2lnbmF0dXJlcyAoYW5kIHJlLW5hbWUgdGhlIHZhcmlvdXMgcGFydHMsIGku ZS4gcHJvb2YgLSZndDsgc2lnbmF0dXJlLCBldGMuKS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+QmVzdCByZWdh cmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmIj5EYW48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9t Ojwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gQ2ZyZyBbbWFpbHRvOmNmcmctYm91bmNlc0Bp cnRmLm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+U2hhcm9uIEdvbGRiZXJnPGJyPg0KPGI+U2Vu dDo8L2I+IFdlZG5lc2RheSwgSnVseSAxMiwgMjAxNyA1OjQyIEFNPGJyPg0KPGI+VG86PC9iPiBj ZnJnQGlydGYub3JnPGJyPg0KPGI+Q2M6PC9iPiBqYW5AbnMxLmNvbTsgRGltaXRyaW9zIFBhcGFk b3BvdWxvcyAmbHQ7ZGlwYXBhZG9AdW1kLmVkdSZndDs7IExlb25pZCBSZXl6aW4gJmx0O3JleXpp bkBjcy5idS5lZHUmZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFtDZnJnXSBkcmFmdC1nb2xkYmUt dnJmOiBWZXJpZmlhYmxlIFJhbmRvbSBGdW5jdGlvbnM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5EZWFyIENGUkcsPGJyPg0KPGJyPg0KSSdtIHByZXNlbnRpbmcgYXQgbmV4 dCB3ZWVrJ3MgbWVldGluZyBvbiBWZXJpZmlhYmxlIFJhbmRvbSBGdW5jdGlvbnMuIEEgVlJGIGlz IHRoZSBwdWJsaWMta2V5IHZlcnNpb24gb2Yga2V5ZWQgY3J5cHRvZ3JhcGhpYyBoYXNoLiBPbmx5 IHRoZSBob2xkZXIgb2YgdGhlIFZSRiBzZWNyZXQga2V5IGNhbiBjb21wdXRlIHRoZSBoYXNoLCBi dXQgYW55b25lIHdpdGggdGhlIHB1YmxpYyBrZXkgY2FuIHZlcmlmeSBpdC4mbmJzcDsgVlJGcyBj YW4gYmUgdXNlZCB0bw0KIHByZXZlbnQgZGljdGlvbmFyeSBhdHRhY2tzIG9uIGhhc2gtYmFzZWQg ZGF0YSBzdHJ1Y3R1cmVzLCBhbmQgaGF2ZSBhcHBsaWNhdGlvbnMgdG8ga2V5IHRyYW5zcGFyZW5j eSAoQ09OSUtTKSwgRE5TU0VDIChOU0VDNSksIGFuZCBjcnlwdG9jdXJyZW5jaWVzIChBbGdvcmFu ZCkuPGJyPg0KPGJyPg0KSW4gYWR2YW5jZSBvZiB0aGUgbWVldGluZywgcGxlYXNlIHNlZTo8YnI+ DQo8YnI+DQoxKSBPdXIgc3Vic3RhbnRpYWxseSB1cGRhdGVkIC0wMSBkcmFmdDo8YnI+DQo8YSBo cmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1nb2xkYmUtdnJmLyIg dGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWdv bGRiZS12cmYvPC9hPjxicj4NCjxicj4NCjIpIE91ciBwcm9qZWN0IHBhZ2UsIHdpdGggbGlua3Mg dG8gdmFyaW91cyBWUkYgaW1wbGVtZW50YXRpb25zOjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3 LmNzLmJ1LmVkdS9+Z29sZGJlL3Byb2plY3RzL3ZyZiIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8v d3d3LmNzLmJ1LmVkdS9+Z29sZGJlL3Byb2plY3RzL3ZyZjwvYT48YnI+DQo8YnI+DQpDb21tZW50 cyB3ZWxjb21lLiZuYnNwOyBUaGFua3MsPGJyPg0KPGJyPg0KU2hhcm9uPGJyPg0KPGJyPg0KLS08 YnI+DQpTaGFyb24gR29sZGJlcmc8YnI+DQpDb21wdXRlciBTY2llbmNlLCBCb3N0b24gVW5pdmVy c2l0eTxicj4NCjxhIGhyZWY9Imh0dHA6Ly93d3cuY3MuYnUuZWR1L35nb2xkYmUiIHRhcmdldD0i X2JsYW5rIj5odHRwOi8vd3d3LmNzLmJ1LmVkdS9+Z29sZGJlPC9hPjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_810C31990B57ED40B2062BA10D43FBF501B63B22XMB116CNCrimnet_-- From nobody Tue Jul 18 11:37:33 2017 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 9034812F299 for ; Tue, 18 Jul 2017 11:37:32 -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 Sv0bLX6Ml5xX for ; Tue, 18 Jul 2017 11:37:31 -0700 (PDT) Received: from mail-yw0-x235.google.com (mail-yw0-x235.google.com [IPv6:2607:f8b0:4002: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 2D54B129B35 for ; Tue, 18 Jul 2017 11:37:31 -0700 (PDT) Received: by mail-yw0-x235.google.com with SMTP id y186so9761096ywc.1 for ; Tue, 18 Jul 2017 11:37:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=fIs9mRoCp8OXtZODjnmYDZSNZw3pca2UN+mVwQpCZGA=; b=a/T3qJvSYyoSNS5TSNvnGQBU/NJtknaSzHs6RDaoZ7tDDhKv9YQ5YzW+ph2bKxxkmq 0LKwDI9DMWa+a4O0N8cfGl4gDGfej43m9Si17BNc7A7b9DIOzD6/erm430XkL+i2P8B4 MAGbXyiNXWxrnMuVsbzK9iO/zuNIoUvkfGFnNHF+owWRF+A26nF+om33FRCHxHK+xdCd 4eNKxErnm/sLcWHT3Rb6fA0qg0akuGvf5tTdQro/GdAakuy8vknvmEmxN9vicO0M1Iqy ygLlay4CD54It9ShYMy2uGJt8axjgmuT/QZpPrN/N02/pHScRsQjMs/mH3dh8B2u9E+A UMuA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=fIs9mRoCp8OXtZODjnmYDZSNZw3pca2UN+mVwQpCZGA=; b=sEvOSIU4gWqhDIwPtOtDBV/rJ5EW9fp2ZvKNvjXFprnvy9C//8DpCDCLecsvn4hb2n Iw8E4ahpe0oQ1wwGGq415daK5qXYvpnmlqioHfJOsqa19+UhssFSwdR//OrJOk+xVAOv 2GIc5Y0UVKXUT8tROQRLv431PAfuvWe7m+NqvnPJKCoAoJgzirV7YPQmsNRny/JLnS3D SE5BGQz/kARyy9fwjvkIEbyHRs2PzVdjuqmUEpxKCdZiCND+8yqQ48JsQAwgh57DClem B9qqoowRHkYvRvQ5qgk/wGKYqL0a9uhXy1ju6WFfV6AJlxYGqxPiEXUoGJgvlRnfjdk8 XXwA== X-Gm-Message-State: AIVw113P35aJEJ8sxrAIAH4IG4Y37Zuibv0vrCsMfbRpjW3DEchDCEgX WT6l8CjxCGB+Urx4zLaucavILEJRjg== X-Received: by 10.129.53.205 with SMTP id c196mr2311279ywa.38.1500403050190; Tue, 18 Jul 2017 11:37:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.170.132 with HTTP; Tue, 18 Jul 2017 11:37:09 -0700 (PDT) In-Reply-To: References: From: Tony Arcieri Date: Tue, 18 Jul 2017 11:37:09 -0700 Message-ID: To: Sharon Goldberg Cc: "cfrg@irtf.org" , jan@ns1.com, Dimitrios Papadopoulos , Leonid Reyzin Content-Type: multipart/alternative; boundary="001a114224c6d3b48005549bce86" Archived-At: Subject: Re: [Cfrg] draft-goldbe-vrf: Verifiable Random Functions X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jul 2017 18:37:32 -0000 --001a114224c6d3b48005549bce86 Content-Type: text/plain; charset="UTF-8" Just a quick note on section 5.4.1, and perhaps a question to the chairs: Would it be worth it for the CFRG to specify standard schemes for hashing to elliptic curve points? This draft talks about both the "hash and pray" method (5.4.1.1) then also the Icart method as well as Elligator (5.4.1.2). This seems like a common enough problem it'd be nice to have off-the-shelf solutions for it, rather than every higher level protocol having to specify their own. -- Tony Arcieri --001a114224c6d3b48005549bce86 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Just a quick note on section 5.4.1, and perhaps a question= to the chairs:

Would it be worth it for the CFRG to specify = standard schemes for hashing to elliptic curve points? This draft talks abo= ut both the "hash and pray" method (5.4.1.1) then also the Icart = method as well as Elligator (5.4.1.2).

This seems like a= common enough problem it'd be nice to have off-the-shelf solutions for= it, rather than every higher level protocol having to specify their own.
--
Tony Arcieri
--001a114224c6d3b48005549bce86-- From nobody Tue Jul 18 11:51:23 2017 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 B3D8612EC11; Tue, 18 Jul 2017 11:51:21 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: cfrg@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.56.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150040388169.11304.11188669832144366187@ietfa.amsl.com> Date: Tue, 18 Jul 2017 11:51:21 -0700 Archived-At: Subject: [Cfrg] I-D Action: draft-irtf-cfrg-augpake-08.txt X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.22 List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jul 2017 18:51:22 -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 : Augmented Password-Authenticated Key Exchange (AugPAKE) Authors : SeongHan Shin Kazukuni Kobara Filename : draft-irtf-cfrg-augpake-08.txt Pages : 20 Date : 2017-07-18 Abstract: This document describes a secure and highly-efficient augmented password-authenticated key exchange (AugPAKE) protocol where a user remembers a low-entropy password and its verifier is registered in the intended server. In general, the user's password is chosen from a small set of dictionary, making the password susceptible to offline dictionary attacks. The AugPAKE protocol described here is secure against passive attacks, active attacks and offline dictionary attacks (on the obtained messages with passive/active attacks). Also, this protocol provides resistance to server compromise in the context that an attacker, who obtained the password verifier from the server, must at least perform offline dictionary attacks to gain any advantage in impersonating the user. The AugPAKE protocol is not only provably secure in the random oracle model but also the most efficient over the previous augmented PAKE protocols (SRP and AMP). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-irtf-cfrg-augpake/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-irtf-cfrg-augpake-08 https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-augpake-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-irtf-cfrg-augpake-08 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 Wed Jul 19 00:55:16 2017 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 AA4EE131C07 for ; Wed, 19 Jul 2017 00:55:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.7 X-Spam-Level: X-Spam-Status: No, score=-4.7 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_H2=-2.8, SPF_HELO_PASS=-0.001, URIBL_BLOCKED=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 HFi7jjedysTp for ; Wed, 19 Jul 2017 00:55:12 -0700 (PDT) Received: from EUR03-DB5-obe.outbound.protection.outlook.com (mail-eopbgr40081.outbound.protection.outlook.com [40.107.4.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F3F10131C08 for ; Wed, 19 Jul 2017 00:55:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rhul.onmicrosoft.com; s=selector1-rhul-ac-uk; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=nL8B6a2ZAvY7/D9HcncXGt0qXXcd2PY1oY5Dr9cceWE=; b=gt+z+B0C4bvoSB7g9+qeaA1k/d0KbvubHJrsiIO654CKeykNsSCiZYrCEX1rxjAqjwEuYFcd4c4Pm1Fx4E3uz1e0W13GxlQDrbFqTI6DVQbvEFDxdXro0xGa1oOumlpxBtWiY8vO5TQsz22SMzqDWi4TtL7o8YewEptAu1spDj4= Received: from AM4PR0301MB1906.eurprd03.prod.outlook.com (10.168.2.156) by AM4PR0301MB1905.eurprd03.prod.outlook.com (10.168.2.155) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1261.13; Wed, 19 Jul 2017 07:55:07 +0000 Received: from AM4PR0301MB1906.eurprd03.prod.outlook.com ([fe80::482:61a:3f1b:be7a]) by AM4PR0301MB1906.eurprd03.prod.outlook.com ([fe80::482:61a:3f1b:be7a%14]) with mapi id 15.01.1261.024; Wed, 19 Jul 2017 07:55:07 +0000 From: "Paterson, Kenny" To: Tony Arcieri , Sharon Goldberg CC: "jan@ns1.com" , "cfrg@irtf.org" , "Leonid Reyzin" , Dimitrios Papadopoulos Thread-Topic: [Cfrg] draft-goldbe-vrf: Verifiable Random Functions Thread-Index: AQHS+vNBkrUviGJWskGoaUVUdJgq0aJZ89OAgADv0YA= Date: Wed, 19 Jul 2017 07:55:07 +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.7.1.161129 authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=rhul.ac.uk; x-originating-ip: [31.133.132.244] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM4PR0301MB1905; 7:my5i/c/lr0v85WDRBUY9WKmx9CG6lDni+z1U3fSf9x3qGdAmPlQc1jdkvL0uP5W3m4oLAm/PU4DJcsx4Jk9RYStQowBmY0cC9y0iraRLJU/uP3+khZ7j0gipqAbQ8Fpa53pqniUrtI9ZldBwpXwDofyioReDQ4WT8Au27aUl7IjPQVwunvN8XC/ADh0w9ZPZKX2aDxq+rOg084VhC2XQlmUg/8TnH0AEN+8vMiW8FyDUHlHG3ZNh0XO2zcK7ZPOj0sXcprEXUe3sBlHEGZErCblBAgBTGNxNoiaHO8rdlHjHM9QiIqv+4YfqW+Rsev0FmNT4tIQVFQExLy9gSDhGCpwEzw14DMpDZHLvPphNGxkefCC2AC73PnMpuExKFVnNj3QvPFotYlwK7eJbwBi1vPX7mUIQ+k4qSHEzrHLeQBCumIQTJgyijR9X3kyADcKksyJl0EeR9h84xxuekicNOAmHguOAiJhyBZVB+xeU+S4+ox7OV1XjCW7EzjHwnl34VBulafZrmofgoSYqZu0lSIo1O3Lw0TextTkjSZpmabfRMBPBPYOFYY8c3IXP096XRzETp5hF3xJ0swzJCAUxlpz/a0DX4DO9jQzjTO+KdW4FNtW38C+0U9Hc9M7yX+htREBdNMyNXNOIWb8+1x1bbXWzFThrQMYwHGQtebH40dp0KNS3zd0TNeUYAjuR6Cx09lIAXkvGb5gfYFysPlLuaMEFH00VOekyw9cFU0UI9CLKuoT0QcLe5q4LZnsCi2QxvKZ5uUMHgiA9ZcANsT6joefJOvB7x7Zm73a7RVLW12o= x-forefront-antispam-report: SFV:SKI; SCL:-1SFV:NSPM; SFS:(10009020)(6009001)(39400400002)(39850400002)(39450400003)(39410400002)(39840400002)(24454002)(230783001)(72206003)(36756003)(74482002)(4326008)(25786009)(6246003)(5250100002)(83506001)(38730400002)(6512007)(99286003)(54906002)(53936002)(2171002)(39060400002)(86362001)(3846002)(102836003)(6116002)(8676002)(14454004)(478600001)(7736002)(305945005)(2950100002)(66066001)(2906002)(42882006)(189998001)(54356999)(81166006)(50986999)(76176999)(8936002)(6486002)(5660300001)(229853002)(6506006)(53546010)(6436002)(4001350100001)(3660700001)(3280700002)(2900100001); DIR:OUT; SFP:1101; SCL:1; SRVR:AM4PR0301MB1905; H:AM4PR0301MB1906.eurprd03.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; x-ms-office365-filtering-correlation-id: 3d06a190-b11a-4c9e-cddd-08d4ce7b78e7 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:AM4PR0301MB1905; x-ms-traffictypediagnostic: AM4PR0301MB1905: x-exchange-antispam-report-test: UriScan:(236129657087228); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(8121501046)(5005006)(2017060910075)(10201501046)(100000703101)(100105400095)(3002001)(93006095)(93001095)(6041248)(20161123555025)(201703131423075)(201702281529075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(20161123562025)(20161123564025)(20161123558100)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:AM4PR0301MB1905; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:AM4PR0301MB1905; x-forefront-prvs: 0373D94D15 spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <0783D249EF8D224A8152ED75FDD4CAD3@eurprd03.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: rhul.ac.uk X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Jul 2017 07:55:07.0214 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2efd699a-1922-4e69-b601-108008d28a2e X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR0301MB1905 Archived-At: Subject: Re: [Cfrg] draft-goldbe-vrf: Verifiable Random Functions X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jul 2017 07:55:15 -0000 SGkgVG9ueSwNCg0KSSB0aGluayB0aGlzIGlzIGFuIGV4Y2VsbGVudCBzdWdnZXN0aW9uLiBJdCdz IHNvbWV0aGluZyBJIGhpdCBpbiBteSBvd24NCnJlc2VhcmNoIHJlY2VudGx5IHRvby4NCg0KU286 IGFueSB2b2x1bnRlZXJzIHRvIHN0YXJ0IGEgZHJhZnQgb24gdGhpcz8NCg0KQ2hlZXJzDQoNCktl bm55DQoNCk9uIDE4LzA3LzIwMTcgMTk6MzcsICJDZnJnIG9uIGJlaGFsZiBvZiBUb255IEFyY2ll cmkiDQo8Y2ZyZy1ib3VuY2VzQGlydGYub3JnIG9uIGJlaGFsZiBvZiBiYXNjdWxlQGdtYWlsLmNv bT4gd3JvdGU6DQoNCj5KdXN0IGEgcXVpY2sgbm90ZSBvbiBzZWN0aW9uIDUuNC4xLCBhbmQgcGVy aGFwcyBhIHF1ZXN0aW9uIHRvIHRoZSBjaGFpcnM6DQo+DQo+DQo+V291bGQgaXQgYmUgd29ydGgg aXQgZm9yIHRoZSBDRlJHIHRvIHNwZWNpZnkgc3RhbmRhcmQgc2NoZW1lcyBmb3IgaGFzaGluZw0K PnRvIGVsbGlwdGljIGN1cnZlIHBvaW50cz8gVGhpcyBkcmFmdCB0YWxrcyBhYm91dCBib3RoIHRo ZSAiaGFzaCBhbmQgcHJheSINCj5tZXRob2QgKDUuNC4xLjEpIHRoZW4gYWxzbyB0aGUgSWNhcnQg bWV0aG9kIGFzIHdlbGwgYXMgRWxsaWdhdG9yDQo+KDUuNC4xLjIpLg0KPg0KPg0KPlRoaXMgc2Vl bXMgbGlrZSBhIGNvbW1vbiBlbm91Z2ggcHJvYmxlbSBpdCdkIGJlIG5pY2UgdG8gaGF2ZQ0KPm9m Zi10aGUtc2hlbGYgc29sdXRpb25zIGZvciBpdCwgcmF0aGVyIHRoYW4gZXZlcnkgaGlnaGVyIGxl dmVsIHByb3RvY29sDQo+aGF2aW5nIHRvIHNwZWNpZnkgdGhlaXIgb3duLg0KPg0KPi0tDQo+VG9u eSBBcmNpZXJpDQo+DQoNCg== From nobody Wed Jul 19 01:34:55 2017 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 3755C131C3B for ; Wed, 19 Jul 2017 01:34:52 -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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 zS9ohKXeuXRs for ; Wed, 19 Jul 2017 01:34:50 -0700 (PDT) Received: from nat-hk.nvidia.com (nat-hk.nvidia.com [203.18.50.4]) (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 4B73F131C35 for ; Wed, 19 Jul 2017 01:34:50 -0700 (PDT) Received: from hkpgpgate102.nvidia.com (Not Verified[10.18.92.9]) by nat-hk.nvidia.com id ; Wed, 19 Jul 2017 16:18:52 +0800 Received: from HKMAIL102.nvidia.com ([10.18.16.11]) by hkpgpgate102.nvidia.com (PGP Universal service); Wed, 19 Jul 2017 01:34:47 -0700 X-PGP-Universal: processed; by hkpgpgate102.nvidia.com on Wed, 19 Jul 2017 01:34:47 -0700 Received: from HKMAIL103.nvidia.com (10.18.16.12) by HKMAIL102.nvidia.com (10.18.16.11) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Wed, 19 Jul 2017 08:34:46 +0000 Received: from HKMAIL103.nvidia.com ([fe80::f5ae:f43f:ff37:8c85]) by HKMAIL103.nvidia.com ([fe80::f5ae:f43f:ff37:8c85%19]) with mapi id 15.00.1263.000; Wed, 19 Jul 2017 08:34:46 +0000 From: Jerry Zhu To: "cfrg@irtf.org" Thread-Topic: RFC 8032: Question on Side-Channel Leaks Thread-Index: AdMAahSpyutm7k8jSgmJRdRK3qusBg== Date: Wed, 19 Jul 2017 08:34:46 +0000 Message-ID: <6fa65bd5e4ce454ba871ddec56a87d9c@HKMAIL103.nvidia.com> Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.19.219.23] MIME-Version: 1.0 Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_6fa65bd5e4ce454ba871ddec56a87d9cHKMAIL103nvidiacom_" Archived-At: Subject: [Cfrg] RFC 8032: Question on Side-Channel Leaks X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jul 2017 08:34:52 -0000 --_000_6fa65bd5e4ce454ba871ddec56a87d9cHKMAIL103nvidiacom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear RFC experts, I am an engineer in Nvidia. When reading below statement in https://tools= .ietf.org/html/rfc8032#section-8.1 "To make an implementation side-channel silent in this way, the modulo p = arithmetic must not use any data-dependent branches, e.g., related to car= ry propagation." Does the 'modulo p' refer to a generic prime number, or the prime number = defining GF(p) e.g. 2^255-19 for Ed25519? I am asking this because some modulo arithmetic in Ed25519 Sign is again= st L, not p. "5. Compute S =3D (r + k * s) mod L. For efficiency, again reduce k mod= ulo L first." I think this computation shall also be side channel silent to keep confid= entiality of k. Could you please clarify? Thanks -Jerry Zhu (Ext. 41218) -------------------------------------------------------------------------= ---------- This email message is for the sole use of the intended recipient(s) and m= ay contain confidential information. Any unauthorized review, use, disclosure or di= stribution is prohibited. If you are not the intended recipient, please contact the= =20sender by reply email and destroy all copies of the original message. -------------------------------------------------------------------------= ---------- --_000_6fa65bd5e4ce454ba871ddec56a87d9cHKMAIL103nvidiacom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =

Dear RFC experts,

 

I am an engineer in Nvidia. When reading below sta= tement in https://tools.ietf.org/html/rfc8032#section-8.1

“To make an implementation side-ch=
annel silent in this way, the modulo p arithmetic must not use any data-dependent br=
anches, e.g., related to carry propagation.”

 


Does the ‘modulo p’ refer to a generic=
=20prime number, or the prime number defining GF(p) e.g. 2^255-19 for Ed2=
5519?


I am asking this because some modulo arithmetic in=
=20 Ed25519 Sign is against  L, not p.


 


“5.  Compute S =3D (r + k=
=20* s) mod L.  For efficiency, again reduce k modulo L first.”=
;


I think this computation shall also be side channe=
l silent to keep confidentiality of k.


 


Could you please clarify?


 


 


Tha=
nks


=
-Jerry Zhu (Ext. 41218)


 
This email message is for the sole use of the intended recipient(s) = and may=20 contain confidential information.  Any unauthorized review, use, dis= closure=20 or distribution is prohibited.  If you are not the intended recipien= t,=20 please contact the sender by reply email and destroy all copies of the or= iginal=20 message.
--_000_6fa65bd5e4ce454ba871ddec56a87d9cHKMAIL103nvidiacom_-- From nobody Wed Jul 19 03:02:41 2017 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 4810C131C78 for ; Wed, 19 Jul 2017 03:02:36 -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, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=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 yxlaTUDKLbpJ for ; Wed, 19 Jul 2017 03:02:31 -0700 (PDT) Received: from welho-filter3.welho.com (welho-filter3.welho.com [83.102.41.25]) by ietfa.amsl.com (Postfix) with ESMTP id C93A112F24E for ; Wed, 19 Jul 2017 03:02:30 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter3.welho.com (Postfix) with ESMTP id 79EEF223D1; Wed, 19 Jul 2017 13:02:28 +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-filter3.welho.com [::ffff:83.102.41.25]) (amavisd-new, port 10024) with ESMTP id dRm-me5nixsy; Wed, 19 Jul 2017 13:02:27 +0300 (EEST) Received: from LK-Perkele-VII (87-92-19-27.bb.dnainternet.fi [87.92.19.27]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp1.welho.com (Postfix) with ESMTPSA id 8794A286; Wed, 19 Jul 2017 13:02:25 +0300 (EEST) Date: Wed, 19 Jul 2017 13:02:25 +0300 From: Ilari Liusvaara To: Jerry Zhu Cc: "cfrg@irtf.org" Message-ID: <20170719100225.wwaazm7f3mxz3aca@LK-Perkele-VII> References: <6fa65bd5e4ce454ba871ddec56a87d9c@HKMAIL103.nvidia.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <6fa65bd5e4ce454ba871ddec56a87d9c@HKMAIL103.nvidia.com> User-Agent: NeoMutt/20170609 (1.8.3) Sender: ilariliusvaara@welho.com Archived-At: Subject: Re: [Cfrg] RFC 8032: Question on Side-Channel Leaks X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jul 2017 10:02:36 -0000 On Wed, Jul 19, 2017 at 08:34:46AM +0000, Jerry Zhu wrote: > Dear RFC experts, > > I am an engineer in Nvidia. When reading below statement in https://tools.ietf.org/html/rfc8032#section-8.1 > > "To make an implementation side-channel silent in this way, the modulo p arithmetic must not use any data-dependent branches, e.g., related to carry propagation." > > Does the 'modulo p' refer to a generic prime number, or the prime number defining GF(p) e.g. 2^255-19 for Ed25519? > I am asking this because some modulo arithmetic in Ed25519 Sign is against L, not p. > > "5. Compute S = (r + k * s) mod L. For efficiency, again reduce k modulo L first." > I think this computation shall also be side channel silent to keep confidentiality of k. > > Could you please clarify? > Looks like the section concentrates on elliptic curves and forgets the scalar (mod L) computations. However, there are much less computations modulo L than mod p. So even relatively dumb implemenantion does not affect speed very much. k is AFAIK not secret. The way I coded the mod L calculations was: - The multiplication and addition are ordinary integer operations, done on constant number of words for being constant-time. - There are specialized routines for partially reducing from "double width" (e.g., 512 bits for 25519) to "single width" (e.g., 255 bits). - Then there is specialized full reduction routine (e.g., from 256 bits to ~252 bits). The ladder the code uses to reduce numbers uses the following: Let L = 2^252 + k. Let r1 = h1 * 2^252 + l1 Then r1 = l1 - k * h1 = x1*L + l1 - k * h1 (mod L). Choose x1 to be big enough so that the expression is always positive. Let r2 = h2 * 2^256 + l2 Then r2 = l2 - 16k * h2 = x2*L + l2 - 16k * h2 (mod L). Choose x2 to be big enough so that the expression is always positive. Let L = 2^446 - k. Let r3 = h3 * 2^446 + l3 Then r3 = l3 + k * h3 (mod L). Let r4 = h4 * 2^448 + l4 Then r4 = l4 + 4k * h4 (mod L). These formulas rather rapidly can reduce the numbers, eliminating half of the bits in about three rounds, with the last round having single-word multiplication. For full reductions, one needs one round followed by conditional substraction (which takes some care to do in constant time). -Ilari From nobody Wed Jul 19 23:28:31 2017 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 6F88B129B34 for ; Wed, 19 Jul 2017 23:28:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 WeviSIB3we22 for ; Wed, 19 Jul 2017 23:28:20 -0700 (PDT) Received: from nat-hk.nvidia.com (nat-hk.nvidia.com [203.18.50.4]) (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 6E6891289B0 for ; Wed, 19 Jul 2017 23:28:20 -0700 (PDT) Received: from hkpgpgate102.nvidia.com (Not Verified[10.18.92.9]) by nat-hk.nvidia.com id ; Thu, 20 Jul 2017 14:28:15 +0800 Received: from HKMAIL104.nvidia.com ([10.18.16.13]) by hkpgpgate102.nvidia.com (PGP Universal service); Wed, 19 Jul 2017 23:28:18 -0700 X-PGP-Universal: processed; by hkpgpgate102.nvidia.com on Wed, 19 Jul 2017 23:28:18 -0700 Received: from HKMAIL103.nvidia.com (10.18.16.12) by HKMAIL104.nvidia.com (10.18.16.13) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Thu, 20 Jul 2017 06:28:16 +0000 Received: from HKMAIL103.nvidia.com ([fe80::f5ae:f43f:ff37:8c85]) by HKMAIL103.nvidia.com ([fe80::f5ae:f43f:ff37:8c85%19]) with mapi id 15.00.1263.000; Thu, 20 Jul 2017 06:28:16 +0000 From: Jerry Zhu To: "ilariliusvaara@welho.com" CC: "cfrg@irtf.org" Thread-Topic: [Cfrg] RFC 8032: Question on Side-Channel Leaks Thread-Index: AdMAahSpyutm7k8jSgmJRdRK3qusBgADApWAACrHtzA= Date: Thu, 20 Jul 2017 06:28:16 +0000 Message-ID: References: <6fa65bd5e4ce454ba871ddec56a87d9c@HKMAIL103.nvidia.com> <20170719100225.wwaazm7f3mxz3aca@LK-Perkele-VII> In-Reply-To: <20170719100225.wwaazm7f3mxz3aca@LK-Perkele-VII> Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.18.19.222] MIME-Version: 1.0 Content-Language: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Archived-At: Subject: Re: [Cfrg] RFC 8032: Question on Side-Channel Leaks X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 06:28:24 -0000 SGkgSWxhcmksDQoNCkFwcHJlY2lhdGUgeW91ciByZXNwb25zZSBhbmQgc2FtcGxlIGltcGxlbWVu dGF0aW9uLiANCklzbid0IHRoZXJlIHJlcHVkaWF0aW9uIHJpc2sgaWYgayBpcyBsZWFrZWQgdG8g YWR2ZXJzYXJ5Pw0KDQpUaGFua3MNCi1KZXJyeSBaaHUgKEV4dC4gNDEyMTgpDQoNCi0tLS0tT3Jp Z2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBpbGFyaWxpdXN2YWFyYUB3ZWxoby5jb20gW21haWx0 bzppbGFyaWxpdXN2YWFyYUB3ZWxoby5jb21dIA0KU2VudDogV2VkbmVzZGF5LCBKdWx5IDE5LCAy MDE3IDY6MDIgUE0NClRvOiBKZXJyeSBaaHUgPGplemh1QG52aWRpYS5jb20+DQpDYzogY2ZyZ0Bp cnRmLm9yZw0KU3ViamVjdDogUmU6IFtDZnJnXSBSRkMgODAzMjogUXVlc3Rpb24gb24gU2lkZS1D aGFubmVsIExlYWtzDQoNCk9uIFdlZCwgSnVsIDE5LCAyMDE3IGF0IDA4OjM0OjQ2QU0gKzAwMDAs IEplcnJ5IFpodSB3cm90ZToNCj4gRGVhciBSRkMgZXhwZXJ0cywNCj4gDQo+IEkgYW0gYW4gZW5n aW5lZXIgaW4gTnZpZGlhLiBXaGVuIHJlYWRpbmcgYmVsb3cgc3RhdGVtZW50IGluIA0KPiBodHRw czovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjODAzMiNzZWN0aW9uLTguMQ0KPiANCj4gIlRvIG1h a2UgYW4gaW1wbGVtZW50YXRpb24gc2lkZS1jaGFubmVsIHNpbGVudCBpbiB0aGlzIHdheSwgdGhl IG1vZHVsbyBwIGFyaXRobWV0aWMgbXVzdCBub3QgdXNlIGFueSBkYXRhLWRlcGVuZGVudCBicmFu Y2hlcywgZS5nLiwgcmVsYXRlZCB0byBjYXJyeSBwcm9wYWdhdGlvbi4iDQo+IA0KPiBEb2VzIHRo ZSAnbW9kdWxvIHAnIHJlZmVyIHRvIGEgZ2VuZXJpYyBwcmltZSBudW1iZXIsIG9yIHRoZSBwcmlt ZSBudW1iZXIgZGVmaW5pbmcgR0YocCkgZS5nLiAyXjI1NS0xOSBmb3IgRWQyNTUxOT8NCj4gSSBh bSBhc2tpbmcgdGhpcyBiZWNhdXNlIHNvbWUgbW9kdWxvIGFyaXRobWV0aWMgaW4gIEVkMjU1MTkg U2lnbiBpcyBhZ2FpbnN0ICBMLCBub3QgcC4NCg0KPiANCj4gIjUuICBDb21wdXRlIFMgPSAociAr IGsgKiBzKSBtb2QgTC4gIEZvciBlZmZpY2llbmN5LCBhZ2FpbiByZWR1Y2UgayBtb2R1bG8gTCBm aXJzdC4iDQo+IEkgdGhpbmsgdGhpcyBjb21wdXRhdGlvbiBzaGFsbCBhbHNvIGJlIHNpZGUgY2hh bm5lbCBzaWxlbnQgdG8ga2VlcCBjb25maWRlbnRpYWxpdHkgb2Ygay4NCj4gDQo+IENvdWxkIHlv dSBwbGVhc2UgY2xhcmlmeT8NCj4gDQoNCkxvb2tzIGxpa2UgdGhlIHNlY3Rpb24gY29uY2VudHJh dGVzIG9uIGVsbGlwdGljIGN1cnZlcyBhbmQgZm9yZ2V0cyB0aGUgc2NhbGFyIChtb2QgTCkgY29t cHV0YXRpb25zLg0KDQpIb3dldmVyLCB0aGVyZSBhcmUgbXVjaCBsZXNzIGNvbXB1dGF0aW9ucyBt b2R1bG8gTCB0aGFuIG1vZCBwLiBTbyBldmVuIHJlbGF0aXZlbHkgZHVtYiBpbXBsZW1lbmFudGlv biBkb2VzIG5vdCBhZmZlY3Qgc3BlZWQgdmVyeSBtdWNoLg0KDQprIGlzIEFGQUlLIG5vdCBzZWNy ZXQuDQoNCg0KDQpUaGUgd2F5IEkgY29kZWQgdGhlIG1vZCBMIGNhbGN1bGF0aW9ucyB3YXM6DQoN Ci0gVGhlIG11bHRpcGxpY2F0aW9uIGFuZCBhZGRpdGlvbiBhcmUgb3JkaW5hcnkgaW50ZWdlciBv cGVyYXRpb25zLCBkb25lDQogIG9uIGNvbnN0YW50IG51bWJlciBvZiB3b3JkcyBmb3IgYmVpbmcg Y29uc3RhbnQtdGltZS4NCi0gVGhlcmUgYXJlIHNwZWNpYWxpemVkIHJvdXRpbmVzIGZvciBwYXJ0 aWFsbHkgcmVkdWNpbmcgZnJvbSAiZG91YmxlDQogIHdpZHRoIiAoZS5nLiwgNTEyIGJpdHMgZm9y IDI1NTE5KSB0byAic2luZ2xlIHdpZHRoIiAoZS5nLiwgMjU1IGJpdHMpLg0KLSBUaGVuIHRoZXJl IGlzIHNwZWNpYWxpemVkIGZ1bGwgcmVkdWN0aW9uIHJvdXRpbmUgKGUuZy4sIGZyb20gMjU2IGJp dHMNCiAgdG8gfjI1MiBiaXRzKS4NCg0KVGhlIGxhZGRlciB0aGUgY29kZSB1c2VzIHRvIHJlZHVj ZSBudW1iZXJzIHVzZXMgdGhlIGZvbGxvd2luZzoNCg0KTGV0IEwgPSAyXjI1MiArIGsuDQoNCkxl dCByMSA9IGgxICogMl4yNTIgKyBsMQ0KDQpUaGVuIHIxID0gbDEgLSBrICogaDEgPSB4MSpMICsg bDEgLSBrICogaDEgKG1vZCBMKS4NCg0KQ2hvb3NlIHgxIHRvIGJlIGJpZyBlbm91Z2ggc28gdGhh dCB0aGUgZXhwcmVzc2lvbiBpcyBhbHdheXMgcG9zaXRpdmUuDQoNCkxldCByMiA9IGgyICogMl4y NTYgKyBsMg0KDQpUaGVuIHIyID0gbDIgLSAxNmsgKiBoMiA9IHgyKkwgKyBsMiAtIDE2ayAqIGgy IChtb2QgTCkuDQoNCkNob29zZSB4MiB0byBiZSBiaWcgZW5vdWdoIHNvIHRoYXQgdGhlIGV4cHJl c3Npb24gaXMgYWx3YXlzIHBvc2l0aXZlLg0KDQoNCg0KTGV0IEwgPSAyXjQ0NiAtIGsuDQoNCkxl dCByMyA9IGgzICogMl40NDYgKyBsMw0KDQpUaGVuIHIzID0gbDMgKyBrICogaDMgKG1vZCBMKS4N Cg0KTGV0IHI0ID0gaDQgKiAyXjQ0OCArIGw0DQoNClRoZW4gcjQgPSBsNCArIDRrICogaDQgKG1v ZCBMKS4NCg0KDQpUaGVzZSBmb3JtdWxhcyByYXRoZXIgcmFwaWRseSBjYW4gcmVkdWNlIHRoZSBu dW1iZXJzLCBlbGltaW5hdGluZyBoYWxmIG9mIHRoZSBiaXRzIGluIGFib3V0IHRocmVlIHJvdW5k cywgd2l0aCB0aGUgbGFzdCByb3VuZCBoYXZpbmcgc2luZ2xlLXdvcmQgbXVsdGlwbGljYXRpb24u DQoNCkZvciBmdWxsIHJlZHVjdGlvbnMsIG9uZSBuZWVkcyBvbmUgcm91bmQgZm9sbG93ZWQgYnkg Y29uZGl0aW9uYWwgc3Vic3RyYWN0aW9uICh3aGljaCB0YWtlcyBzb21lIGNhcmUgdG8gZG8gaW4g Y29uc3RhbnQgdGltZSkuDQoNCg0KDQotSWxhcmkNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0NClRoaXMgZW1haWwgbWVzc2FnZSBpcyBmb3IgdGhlIHNvbGUgdXNlIG9mIHRoZSBpbnRlbmRl ZCByZWNpcGllbnQocykgYW5kIG1heSBjb250YWluDQpjb25maWRlbnRpYWwgaW5mb3JtYXRpb24u ICBBbnkgdW5hdXRob3JpemVkIHJldmlldywgdXNlLCBkaXNjbG9zdXJlIG9yIGRpc3RyaWJ1dGlv bg0KaXMgcHJvaGliaXRlZC4gIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQs IHBsZWFzZSBjb250YWN0IHRoZSBzZW5kZXIgYnkNCnJlcGx5IGVtYWlsIGFuZCBkZXN0cm95IGFs bCBjb3BpZXMgb2YgdGhlIG9yaWdpbmFsIG1lc3NhZ2UuDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLQ0K From nobody Thu Jul 20 01:08:05 2017 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 25D12126B72 for ; Thu, 20 Jul 2017 01:08:05 -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, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-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 tSuA9sez4FhY for ; Thu, 20 Jul 2017 01:08:03 -0700 (PDT) Received: from welho-filter1.welho.com (welho-filter1.welho.com [83.102.41.23]) by ietfa.amsl.com (Postfix) with ESMTP id 23840126557 for ; Thu, 20 Jul 2017 01:08:03 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter1.welho.com (Postfix) with ESMTP id 57FE06586C; Thu, 20 Jul 2017 11:08:01 +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 IYS2Q51SsDxJ; Thu, 20 Jul 2017 11:08:01 +0300 (EEST) Received: from LK-Perkele-VII (87-92-19-27.bb.dnainternet.fi [87.92.19.27]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp3.welho.com (Postfix) with ESMTPSA id 1341A2313; Thu, 20 Jul 2017 11:07:59 +0300 (EEST) Date: Thu, 20 Jul 2017 11:07:58 +0300 From: Ilari Liusvaara To: Jerry Zhu Cc: "cfrg@irtf.org" Message-ID: <20170720080758.hp6mps4q5u2m54e7@LK-Perkele-VII> References: <6fa65bd5e4ce454ba871ddec56a87d9c@HKMAIL103.nvidia.com> <20170719100225.wwaazm7f3mxz3aca@LK-Perkele-VII> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20170609 (1.8.3) Sender: ilariliusvaara@welho.com Archived-At: Subject: Re: [Cfrg] RFC 8032: Question on Side-Channel Leaks X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 08:08:05 -0000 On Thu, Jul 20, 2017 at 06:28:16AM +0000, Jerry Zhu wrote: > Hi Ilari, > > Appreciate your response and sample implementation. > Isn't there repudiation risk if k is leaked to adversary? k is computable from context[1], message, signature and the public key. And in fact, k is reconstructed in signature verification. [1] Contexts turn out to be pretty much useless except for generating time-wasting discussion... -Ilari From nobody Thu Jul 20 01:34:18 2017 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 0C208131B09 for ; Thu, 20 Jul 2017 01:34:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 Yt2zS_bEzmSf for ; Thu, 20 Jul 2017 01:34:15 -0700 (PDT) Received: from nat-hk.nvidia.com (nat-hk.nvidia.com [203.18.50.4]) (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 7FA4213157A for ; Thu, 20 Jul 2017 01:34:15 -0700 (PDT) Received: from hkpgpgate101.nvidia.com (Not Verified[10.18.92.9]) by nat-hk.nvidia.com id ; Thu, 20 Jul 2017 16:34:10 +0800 Received: from HKMAIL101.nvidia.com ([10.18.16.10]) by hkpgpgate101.nvidia.com (PGP Universal service); Thu, 20 Jul 2017 01:34:13 -0700 X-PGP-Universal: processed; by hkpgpgate101.nvidia.com on Thu, 20 Jul 2017 01:34:13 -0700 Received: from HKMAIL103.nvidia.com (10.18.16.12) by HKMAIL101.nvidia.com (10.18.16.10) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Thu, 20 Jul 2017 08:34:11 +0000 Received: from HKMAIL103.nvidia.com ([fe80::f5ae:f43f:ff37:8c85]) by HKMAIL103.nvidia.com ([fe80::f5ae:f43f:ff37:8c85%19]) with mapi id 15.00.1263.000; Thu, 20 Jul 2017 08:34:11 +0000 From: Jerry Zhu To: "ilariliusvaara@welho.com" CC: "cfrg@irtf.org" Thread-Topic: [Cfrg] RFC 8032: Question on Side-Channel Leaks Thread-Index: AdMAahSpyutm7k8jSgmJRdRK3qusBgADApWAACrHtzAAA4OgAAAA9BDg Date: Thu, 20 Jul 2017 08:34:11 +0000 Message-ID: References: <6fa65bd5e4ce454ba871ddec56a87d9c@HKMAIL103.nvidia.com> <20170719100225.wwaazm7f3mxz3aca@LK-Perkele-VII> <20170720080758.hp6mps4q5u2m54e7@LK-Perkele-VII> In-Reply-To: <20170720080758.hp6mps4q5u2m54e7@LK-Perkele-VII> Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.18.19.222] MIME-Version: 1.0 Content-Language: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Archived-At: Subject: Re: [Cfrg] RFC 8032: Question on Side-Channel Leaks X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 08:34:17 -0000 TGVhcm5lZCBuZXcga25vd2xlZGdlLiBUaGFuayB5b3UuIA0KDQpUaGFua3MNCi1KZXJyeSBaaHUg KEV4dC4gNDEyMTgpDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBpbGFyaWxp dXN2YWFyYUB3ZWxoby5jb20gW21haWx0bzppbGFyaWxpdXN2YWFyYUB3ZWxoby5jb21dIA0KU2Vu dDogVGh1cnNkYXksIEp1bHkgMjAsIDIwMTcgNDowOCBQTQ0KVG86IEplcnJ5IFpodSA8amV6aHVA bnZpZGlhLmNvbT4NCkNjOiBjZnJnQGlydGYub3JnDQpTdWJqZWN0OiBSZTogW0NmcmddIFJGQyA4 MDMyOiBRdWVzdGlvbiBvbiBTaWRlLUNoYW5uZWwgTGVha3MNCg0KT24gVGh1LCBKdWwgMjAsIDIw MTcgYXQgMDY6Mjg6MTZBTSArMDAwMCwgSmVycnkgWmh1IHdyb3RlOg0KPiBIaSBJbGFyaSwNCj4g DQo+IEFwcHJlY2lhdGUgeW91ciByZXNwb25zZSBhbmQgc2FtcGxlIGltcGxlbWVudGF0aW9uLiAN Cj4gSXNuJ3QgdGhlcmUgcmVwdWRpYXRpb24gcmlzayBpZiBrIGlzIGxlYWtlZCB0byBhZHZlcnNh cnk/DQoNCmsgaXMgY29tcHV0YWJsZSBmcm9tIGNvbnRleHRbMV0sIG1lc3NhZ2UsIHNpZ25hdHVy ZSBhbmQgdGhlIHB1YmxpYyBrZXkuIEFuZCBpbiBmYWN0LCBrIGlzIHJlY29uc3RydWN0ZWQgaW4g c2lnbmF0dXJlIHZlcmlmaWNhdGlvbi4NCg0KDQpbMV0gQ29udGV4dHMgdHVybiBvdXQgdG8gYmUg cHJldHR5IG11Y2ggdXNlbGVzcyBleGNlcHQgZm9yIGdlbmVyYXRpbmcgdGltZS13YXN0aW5nIGRp c2N1c3Npb24uLi4NCg0KDQotSWxhcmkNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClRo aXMgZW1haWwgbWVzc2FnZSBpcyBmb3IgdGhlIHNvbGUgdXNlIG9mIHRoZSBpbnRlbmRlZCByZWNp cGllbnQocykgYW5kIG1heSBjb250YWluDQpjb25maWRlbnRpYWwgaW5mb3JtYXRpb24uICBBbnkg dW5hdXRob3JpemVkIHJldmlldywgdXNlLCBkaXNjbG9zdXJlIG9yIGRpc3RyaWJ1dGlvbg0KaXMg cHJvaGliaXRlZC4gIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHBsZWFz ZSBjb250YWN0IHRoZSBzZW5kZXIgYnkNCnJlcGx5IGVtYWlsIGFuZCBkZXN0cm95IGFsbCBjb3Bp ZXMgb2YgdGhlIG9yaWdpbmFsIG1lc3NhZ2UuDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0K From nobody Thu Jul 20 03:20:15 2017 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 0799B131BFA for ; Thu, 20 Jul 2017 03:20:08 -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_H3=-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 XYoWXCUVtNwW for ; Thu, 20 Jul 2017 03:20:05 -0700 (PDT) Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-eopbgr10057.outbound.protection.outlook.com [40.107.1.57]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 16AD6131C03 for ; Thu, 20 Jul 2017 03:20:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rhul.onmicrosoft.com; s=selector1-rhul-ac-uk; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=SFuwu/H/XaZ/Kkoowjhbtof1vUvJ0xbmcaiwhb3xlMA=; b=Ne3k1J6BkJQcDWK9hu6QUxFHOhesbPexPCETU+kwTIlEbgKi1e4P0Ruj4LA94cokkDR/4JbctXONNQQeWdpoh5CvdkgNPaosctwJW76jHccbobeEh6wzLEryeUfw99VafnR5qSDBG1E6j3A6M50Nxn6M7RD1Ond/qpHMjL9RW40= Received: from AM4PR0301MB1906.eurprd03.prod.outlook.com (10.168.2.156) by AM4PR0301MB1907.eurprd03.prod.outlook.com (10.168.3.7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1261.13; Thu, 20 Jul 2017 10:20:01 +0000 Received: from AM4PR0301MB1906.eurprd03.prod.outlook.com ([fe80::482:61a:3f1b:be7a]) by AM4PR0301MB1906.eurprd03.prod.outlook.com ([fe80::482:61a:3f1b:be7a%14]) with mapi id 15.01.1261.024; Thu, 20 Jul 2017 10:20:01 +0000 From: "Paterson, Kenny" To: saag CC: "cfrg@irtf.org" Thread-Topic: CFRG report from IETF99 Thread-Index: AQHTAUG/nrwJR++nlEmj0kW0KhMR2g== Date: Thu, 20 Jul 2017 10:20:01 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.1.161129 authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=rhul.ac.uk; x-originating-ip: [31.133.147.39] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM4PR0301MB1907; 7:2ocQfHZ10UrIl13sEZXPPGgHPN856fT47U+qUzMQBQNKq2RNlzWKQN+zRiI539u5LzC9rx7Y16EK7I3AEdgKGwmigXQ0wgDXMa1H7/Aa0oJG9wsRh4Y5pvkRozbwyXA7Li4FVeVTCpSAq3REIrlmPem0uYeZehcsU/m7j7Sh0RmzGPNVOzXhlADM2fD2A49LGQV/eF977vW+8Iou/11q8+UwLYH6Pcf57+AxtQ/ViSMv+2lgfYm+kY5gpDi9uu5GSDBqGcqFaj4Jg2ViczF2eX+7KaxdfEseLTB6GDp2zhSikEAFBq1Wy37+Eb9cg5pYdMiHGIuLkLdvd1zVuIL4Sz3eAkemqD1rJXKNBbGZjxlfqZJ5Iz//WS9JRflTkioAq97xKqn+aEAm7UgUO4sNtlbEfiGAcH+CiWp8eN3Y83S61nWg1kTnGgCL8LK91fIUfGzirWolSVM4izgfnIagrmEEfStvD61+sAHz/FsKVNDZB27sO979NbhxyYwQLbACDq7xcnswa8ijqoFdxs3phCVGW0Z69tBJcf9ioqQ2DV7aXnfKdIeO+MCpzpZ6owNSfuf8ICCnQVV31vEcmVV6rGZc/r4bNXCpA4yCOSTMhOLQP0gWZ8vzCzC3X3njv9l5goVPuoLgFLsdcx1fRcxsqvVqV5rMKS/twaFmW7VlMRwu9CPuL0DJmc847Q/IGjko+aRzh3SPODvPTIYdGbUtIgYPtj6PhMBHlXR2Lu8ECnaviK2zXZNPYfJ7rCxh+xuecd7G5pamjq2ljDuXQdxO53smQhKKtl0shywAutzrxVo= x-forefront-antispam-report: SFV:SKI; SCL:-1SFV:NSPM; SFS:(10009020)(979002)(6009001)(39450400003)(39840400002)(39850400002)(39400400002)(39410400002)(6436002)(7736002)(305945005)(25786009)(4001350100001)(14454004)(110136004)(38730400002)(6512007)(99286003)(8936002)(8676002)(81166006)(102836003)(6116002)(4326008)(36756003)(74482002)(3280700002)(5660300001)(2900100001)(2906002)(3660700001)(114624004)(83506001)(478600001)(6506006)(86362001)(6916009)(50986999)(3846002)(189998001)(6486002)(54356999)(53936002)(5250100002)(66066001)(72206003)(42882006)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1101; SCL:1; SRVR:AM4PR0301MB1907; H:AM4PR0301MB1906.eurprd03.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; x-ms-office365-filtering-correlation-id: 3d7b4287-e68f-4c56-8cfa-08d4cf58e1e3 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:AM4PR0301MB1907; x-ms-traffictypediagnostic: AM4PR0301MB1907: x-exchange-antispam-report-test: UriScan:(278178393323532)(133145235818549)(236129657087228)(148574349560750)(167848164394848); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(5005006)(8121501046)(2017060910075)(93006095)(93001095)(100000703101)(100105400095)(3002001)(10201501046)(6041248)(201703131423075)(201702281529075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123562025)(20161123560025)(20161123564025)(20161123555025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:AM4PR0301MB1907; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:AM4PR0301MB1907; x-forefront-prvs: 0374433C81 spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <7D356937BBD20C4EAFDAE108E38FCAD6@eurprd03.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: rhul.ac.uk X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Jul 2017 10:20:01.9159 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2efd699a-1922-4e69-b601-108008d28a2e X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR0301MB1907 Archived-At: Subject: [Cfrg] CFRG report from IETF99 X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 10:20:08 -0000 Q0ZSRyBtZXQgb24gVHVlc2RheSBhZnRlcm5vb24uDQoNCkNoYWlycyBnYXZlIGFuIHVwZGF0ZS4g U2luY2Ugb3VyIGxhc3QgbWVldGluZyBpbiBTZW91bCwgd2UgaGF2ZSB0d28gbmV3DQpSRkNzIGZy b20gdGhlIGdyb3VwOg0KKiBSRkMgODAzMjogRWR3YXJkcy1jdXJ2ZSBEaWdpdGFsIFNpZ25hdHVy ZSBBbGdvcml0aG0gKEVkRFNBKQ0KKiBSRkMgODEyNTogUmVxdWlyZW1lbnRzIG9uIFBBS0Ugc2No ZW1lcw0KDQpUd28gZG9jdW1lbnRzIGFyZSBpbiBJUlNHIHJldmlldw0KKiBkcmFmdC1pcnRmLWNm cmcteG1zcy1oYXNoLWJhc2VkLXNpZ25hdHVyZXMtMDkgKHVwZGF0ZWQpOiBYTVNTOiBFeHRlbmRl ZA0KSGFzaC1CYXNlZCBTaWduYXR1cmVzDQoqIGRyYWZ0LW5pci1jZnJnLXJmYzc1MzliaXMtMDEg KHVwZGF0ZWQpOiBDaGFDaGEyMCBhbmQgUG9seTEzMDUgZm9yIElFVEYNClByb3RvY29scw0KDQpU aGUgd29yayBvbiBBcmdvbjIgYW5kIEFFUy1HQ00tU0lWIGlzIHByb2dyZXNzaW5nIHNtb290aGx5 IGFuZCB3ZSBzaG91bGQNCm1vdmUgdG8gbGFzdCBjYWxsIHNvb24uDQoNClRoZSBDRlJHIHJldmll dyBwYW5lbCBpcyB3b3JraW5nIHdlbGwsIHByb2R1Y2luZyB0aW1lbHkgYW5kIGRldGFpbGVkDQpy ZXZpZXdzIHRvIGhlbHAgaW1wcm92ZSBDRlJHIGRyYWZ0cy4NCg0KV2UgaGFkIGEgdmFyaWV0eSBv ZiBwcmVzZW50YXRpb25zIG9mIG5ldyBhbmQgb24tZ29pbmcgd29yayBvZiBpbnRlcmVzdCB0bw0K dGhlIGdyb3VwLiANCg0KKiBUaGUgd29yayBvbiAiUmUta2V5aW5nIE1lY2hhbmlzbXMgZm9yIFN5 bW1ldHJpYyBLZXlzIg0KKGRyYWZ0LWlydGYtY2ZyZy1yZS1rZXlpbmcpIGlzIHByb2dyZXNzaW5n IHdlbGw7IFN0YW5pc2xhdiBTbXlzaGx5YWV2DQpwcm92aWRlZCBhbiB1cGRhdGUgb24gcHJvZ3Jl c3MgYW5kIHBsYW5zLg0KDQoqIFNoYXJvbiBHb2xkYmVyZyBwcmVzZW50ZWQgb24gVlJGcyAoZHJh ZnQtZ29sZGJlLXZyZi0wMSkuIFRoZXJlIHdhcw0Kc3Ryb25nIHN1cHBvcnQgaW4gdGhlIHJvb20g Zm9yIGFkb3B0aW9uIG9mIHRoZSBkb2N1bWVudCBhcyBhIENGUkcgZHJhZnQuDQpDaGFpcnMgd2ls bCB0YWtlIHRoaXMgdG8gdGhlIGxpc3QuDQoNCiogRGF2aWQgTWNHcmV3IHByZXNlbnRlZCBvbiAi SGFzaC1CYXNlZCBTaWduYXR1cmVzIg0KKGRyYTEtbWNncmV3LWhhc2gtc2lncy0wNyksIG5vdGlu ZyB0aGF0IGlzIGFscmVhZHkgYSBDRlJHIGRyYWZ0IGFuZA0KcmVxdWVzdGluZyB0aGF0IGl0IGdv IHRvIGxhc3QgY2FsbC4gQ2hhaXJzIHdpbGwgZG8gc28gYW5kIGluIHBhcmFsbGVsDQpjb21taXNz aW9uIHJldmlld3MgYnkgdGhlIENGUkcgcmV2aWV3IHBhbmVsIGFuZC9vciBvdGhlcnMuDQoNCkFk ZGl0aW9uYWwgcHJlc2VudGF0aW9ucyBpbmNsdWRlZDoNCg0KKiBCcnlhbiBGb3JkOiAiQ29sbGVj dGl2ZSBFZHdhcmRzLUN1cnZlIERpZ2l0YWwgU2lnbmF0dXJlIEFsZ29yaXRobSINCihkcmFmdC1m b3JkLWNmcmctY29zaS0wMCksDQoqIEtlbm55IFBhdGVyc29uIGZvciBQYXVsIEhvZmZtYW4sICJU aGUgVHJhbnNpdGlvbiBmcm9tIENsYXNzaWNhbCB0bw0KUG9zdC1RdWFudHVtIENyeXB0b2dyYXBo eSIgKGRyYWZ0LWhvZmZtYW4tYzJwcSkNCiogUXV5bmggRGFuZyBmb3IgQmVub2l0IFZpZ3VpZXIs ICJLYW5nYXJvb1R3ZWx2ZSINCihkcmFmdC12aWd1aWVyLWthbmdhcm9vdHdlbHZlLTAwKQ0KKiBE YW4gQnJvd24sICJFQ0MgbW9kIDheOTErNSIgYW5kICJEaWZmaWUtSGVsbG1hbiBtb2QgNjMwKDQy NyErMSkrMSINCg0KDQoNCg0K From nobody Thu Jul 20 14:19:01 2017 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 67A82126DC2 for ; Thu, 20 Jul 2017 14:19:00 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: X-Test-IDTracker: no X-IETF-IDTracker: 6.57.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150058554042.22410.15964670819190795015.idtracker@ietfa.amsl.com> Date: Thu, 20 Jul 2017 14:19:00 -0700 From: IETF Secretariat Archived-At: Subject: [Cfrg] Milestones changed for cfrg RG X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.22 List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 21:19:00 -0000 Changed milestone "Submit "Hash-Based Signatures" to IRSG", set state to active from review, accepting new milestone. URL: https://datatracker.ietf.org/rg/cfrg/about/ From nobody Fri Jul 21 03:18:06 2017 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 6FAA0129B3A for ; Fri, 21 Jul 2017 03:18:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 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.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 d9IJ88eV0kjE for ; Fri, 21 Jul 2017 03:18:04 -0700 (PDT) Received: from waldorf.isode.com (waldorf.isode.com [62.232.206.188]) by ietfa.amsl.com (Postfix) with ESMTP id 1DD03127ABE for ; Fri, 21 Jul 2017 03:18:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1500632283; d=isode.com; s=june2016; i=@isode.com; bh=TV/OO4/R4Ns5iyJ2nuUNmHeIVTwdT/PwBB53jf6aLwY=; 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=AJd650ZKCFNowRm5MFytzvluquUJkOrjPu3FW22R7lQh0efwPhYwyu5ruBvGJSZ/r1B7jJ lHHGCh5RGZWYOliISfYxCiY8tFBB17Tm+pa8+Z/xi33PmBxat21KBX5YZY1ybXT5oXXxZG mYqfyYRdPItg4hnnRHsB6JMX3Xek5k0=; Received: from [31.133.129.198] (dhcp-81c6.meeting.ietf.org [31.133.129.198]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Fri, 21 Jul 2017 11:18:03 +0100 To: "cfrg@irtf.org" From: Alexey Melnikov Message-ID: <5971D4DD.9030005@isode.com> Date: Fri, 21 Jul 2017 11:18:05 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-transfer-encoding: quoted-printable Archived-At: Subject: [Cfrg] Adoption call for "Verifiable Random Functions": draft-goldbe-vrf-01 X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jul 2017 10:18:05 -0000 Dear CFRG, Based on interest in the face-to-face CFRG meeting in Prague, chairs are starting adoption call for "Verifiable Random Functions" . Unless chairs hear some objections to taking this document as a CFRG deliverable, the default is to work on this document in CFRG. The adoption call will last for 3 weeks (finishing on August 11th). Thank you, Kenny and Alexey From nobody Fri Jul 21 04:15:03 2017 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 7923612EE45 for ; Fri, 21 Jul 2017 04:15:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 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.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 sJjkG0v4vkjp for ; Fri, 21 Jul 2017 04:15:00 -0700 (PDT) Received: from waldorf.isode.com (waldorf.isode.com [62.232.206.188]) by ietfa.amsl.com (Postfix) with ESMTP id 05154129B7F for ; Fri, 21 Jul 2017 04:15:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1500635699; d=isode.com; s=june2016; i=@isode.com; bh=Dcgz/WEhrfr3cYUA8UTEOIFY46HxruYkiRzI2V0Sv7I=; 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=BOQX+BvrFt5LQ0R2EnMG4wTvpsZZh4sekBgfx6wyz/HgT6ao54lFx7ujUCoEG7qA7lNyVe JHsQO+wUC9wXkhgx4AxYvmNpJoS+h9LZBV2OIN0awnob+AJhTXSpWPIjkOIzOgyQYiRB+M EWN3Ezo1OPiJIxhT+GzD66vedIReEVg=; Received: from [31.133.129.198] (dhcp-81c6.meeting.ietf.org [31.133.129.198]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Fri, 21 Jul 2017 12:14:59 +0100 From: Alexey Melnikov To: "cfrg@irtf.org" Message-ID: <5971E235.9060703@isode.com> Date: Fri, 21 Jul 2017 12:15:01 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: [Cfrg] RGLC on "Hash-Based Signatures": draft-mcgrew-hash-sigs-07 X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jul 2017 11:15:01 -0000 Dear CFRG participants, This message is starting 4 weeks CFRG Last Call on "Hash-Based Signatures" . The LC is going to finish on August 18th. Please send your comments in a reply to this message or directly to chairs (cfrg-chairs@ietf.org). Statement of support (or not) for this draft being submitted to IRSG for review and publication are also welcomed. Thank you, Kenny and Alexey From nobody Fri Jul 21 04:26:02 2017 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 5AC2D131483 for ; Fri, 21 Jul 2017 04:26:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=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 gsjppkzhS23c for ; Fri, 21 Jul 2017 04:25:59 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 880F7129B7F for ; Fri, 21 Jul 2017 04:25:59 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id F35B43004FE for ; Fri, 21 Jul 2017 07:25:58 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id QB7YfetS05ZQ for ; Fri, 21 Jul 2017 07:25:57 -0400 (EDT) Received: from [5.5.33.183] (vpn.snozzages.com [204.42.252.17]) by mail.smeinc.net (Postfix) with ESMTPSA id 66817300429; Fri, 21 Jul 2017 07:25:57 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Russ Housley In-Reply-To: <5971E235.9060703@isode.com> Date: Fri, 21 Jul 2017 07:25:55 -0400 Cc: IRTF CFRG Content-Transfer-Encoding: quoted-printable Message-Id: <8EE92C2B-F484-42D4-B799-993C024DA559@vigilsec.com> References: <5971E235.9060703@isode.com> To: Alexey Melnikov X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Cfrg] RGLC on "Hash-Based Signatures": draft-mcgrew-hash-sigs-07 X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jul 2017 11:26:01 -0000 I have read the document, and I have an individual draft that depends on = it. I think it is ready. Russ > On Jul 21, 2017, at 7:15 AM, Alexey Melnikov = wrote: >=20 > Dear CFRG participants, >=20 > This message is starting 4 weeks CFRG Last Call on "Hash-Based > Signatures" = . > The LC is going to finish on August 18th. >=20 > Please send your comments in a reply to this message or directly to > chairs (cfrg-chairs@ietf.org). Statement of support (or not) for this > draft being submitted to IRSG for review and publication are also = welcomed. >=20 > Thank you, > Kenny and Alexey From nobody Fri Jul 21 05:01:28 2017 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 1B4F6131BB0 for ; Fri, 21 Jul 2017 05:01:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=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 pFJBpKQs-aLD for ; Fri, 21 Jul 2017 05:01:20 -0700 (PDT) Received: from mail-it0-x22f.google.com (mail-it0-x22f.google.com [IPv6:2607:f8b0:4001:c0b::22f]) (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 4210B131A87 for ; Fri, 21 Jul 2017 05:01:20 -0700 (PDT) Received: by mail-it0-x22f.google.com with SMTP id h199so6349040ith.0 for ; Fri, 21 Jul 2017 05:01:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=wyjmdf8Y/Qp7+LZy95p1hSu+naNUecsxStSjOQUDWOQ=; b=azGtoZr2ws5wMeGqOXZ8E7KljrU5nUkMYNoRE8crON1N6UbGhay1RTozZ7P74d8AwN ZaWyLpRX6eEnLDLTBAHQjfpmB36tggAkWmYoAAATTlSaDbEF6shvwETs67KJD/Bdrtba f7v7sptMTYItn+EVMt4zgGjltQAUk8bg8Xd04GMRxxVtGyyeK+6VbwZY/9LSu0Ni0t8O dlxQYSXr+uNjOaNY7vUcvAYQixAa+XBIXJNg20a7PqjNPvuZEpKFVXILGG4NHEpHQRQy fORq7UMRJ9cCPOwayDbyFK45sJ7vwfcx2YgaW+dMsWqBszP8PsEMhX5yZGJlWQjOAL5R CpLA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=wyjmdf8Y/Qp7+LZy95p1hSu+naNUecsxStSjOQUDWOQ=; b=M21SN6NWihQ8FPEC2t0/lXrykMOKZ3tWB9J5AI7YPKPkyqYP+UQIMZEKo3LS/lozaJ 4iqiv9641O39ZkMmaswEk/+0Hcb/+3V47vu5Yw9feLWWe4wtqQrbfitlMv/48f7SNh31 Tordv3GUigDf9qTpP6K1ocC/aDv0vQ7D2QAIl4jnU1wHLYSV3x5uR+sXit52t8UDjUZt xLzztSAAUsGUTZ3viEp/IoF+Md4ODNws4ztz12Un/M1iTj+YcejUuUD7vj+SZ3dm7U2c G7OkWgNSNE/LIbbdGaXaCSV5xkEGWxaNJyckhmrlE8Pwm+xgbenY4GFes8wMK4/RHVOh cKNg== X-Gm-Message-State: AIVw111YCgMOdc9Xmguo6XWYEFU606LToq+tG6ah8pfLlP4A5kN3GYgY 3P2gpIJOQ1Mz76LQFtuvLA3lGRwcgZjg X-Received: by 10.36.4.139 with SMTP id 133mr6925607itb.142.1500638479037; Fri, 21 Jul 2017 05:01:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.189.194 with HTTP; Fri, 21 Jul 2017 05:01:18 -0700 (PDT) From: Philip Lafrance Date: Fri, 21 Jul 2017 08:01:18 -0400 Message-ID: To: cfrg@irtf.org Content-Type: multipart/alternative; boundary="001a113fe1e27abc4a0554d29f23" Archived-At: Subject: [Cfrg] Comments on draft-hoffman-c2pq-01 X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jul 2017 12:01:27 -0000 --001a113fe1e27abc4a0554d29f23 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello all, So I can't express enough how much I support this document. I gave it a cursory read and prepared some remarks (see below). Since I was up at 3am today (IPSECME meeting was at 5:50 am my time) I kind of want to go home and sleep. So, I'll give a more detailed review sometime next week (hopefully with some input from my quantum crypto colleagues). Comments: Section 1.3 -The definition given for =E2=80=9Cpost-quantum cryptography=E2= =80=9D is pretty limited and kind of inaccurate. The definition as given would suggest that ECC is post-quantum as it does not rely on factoring large numbers or determine the discrete log of a large composite number. Maybe something like: "The term "post-quantum cryptography" refers to the invention and study of cryptographic techniques (including encryption, signature and key exchange algorithms) that are implementable on a classical computer and are based on problems that are believed to be difficult for a quantum computer to solve. In particular, this includes algorithms based on lattices, isogenies, hash-functions, multivariate polynomial systems, and coding theory. It excludes systems whose security relies on factoring numbers, or the difficulty of determining the discrete log of one group element with respect to another." Section 1.6 -The good folks at the Institute for Quantum Computing have a good textbook which would be a nice reference (here is a link http://hep.fcfm.buap.mx/cursos/2014/MCI/An_Intro_to_Quantum.pdf) Section 2.1 -This section seems to only be concerned with using quantum algorithms to recover secret key. Why not also mention for example using Grover to find collisions to forge signatures? -We should maybe consider replacing =E2=80=9Clarge-scale=E2=80= =9D quantum computer with =E2=80=9Cuniversal=E2=80=9D quantum computer. -Maybe some discussion about the differences between quantum annealing and a universal quantum computer. This would be useful because, for example D-Wave is a quantum annealer, not a universal quantum computer, but the difference is lost on most people. Understanding the difference is important if we=E2=80=99re talking about when to transition. That's all for now. All the best folks! Safe travels home from Prague! -Philip Lafrance --001a113fe1e27abc4a0554d29f23 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello all,

So I can't express enoug= h how much I support this document.

I gave it a cu= rsory read and prepared some remarks (see below).

= Since I was up at 3am today (IPSECME meeting was at 5:50 am my time) I kind= of want to go home and sleep. So, I'll give a more detailed review som= etime next week (hopefully with some input from my quantum crypto colleague= s).

Comments:

Section 1.3

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 -The definition given for =E2=80=9Cpost-quantum cryptography=E2=80=9D is pretty = limited and kind of inaccurate. The definition as given would suggest that ECC is post-quantum = as it does not rely on factoring large numbers or determine the discrete log o= f a large composite number.=C2=A0


<= /span>

Maybe something like:


=C2=A0"The term "post-quantum crypt= ography" refers to the invention and study of cryptographic techniques (including encryptio= n, signature and key exchange algorithms) that are implementable on a classica= l computer and are based on problems that are believed to be difficult for a quantum computer to solve. In particular, this includes algorithms based on lattices, isogenies, hash-functions, multivariate polynomial systems, and coding theory. It excludes systems whose security relies on factoring numbe= rs, or the difficulty of determining the discrete log of one group element with respect to another."

=C2=A0

Section 1.6

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 -The good folks at the Institute for Quantum Computing have a good textbook which wou= ld be a nice reference (here is a link http://hep.fcfm.buap.mx/cursos/2014/MC= I/An_Intro_to_Quantum.pdf)

=C2=A0

Section 2.1

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 -This section seems to only be concerned with using quantum algorithms to recover secret key. Why not also mention for example using Grover to find collision= s to forge signatures?

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 -We should maybe consider replacing =E2=80=9Clarge-scale=E2=80=9D quantum computer wit= h =E2=80=9Cuniversal=E2=80=9D quantum computer.

=C2=A0

-Maybe some discussion about the differences = between quantum annealing and a universal quantum computer. This would be useful because, f= or example D-Wave is a quantum annealer, not a universal quantum computer, but= the difference is lost on most people. Understanding the difference is importan= t if we=E2=80=99re talking about when to transition.


That= 's all for now.


=

All the best folks! Safe travels home from Pr= ague!


-Philip Lafrance

--001a113fe1e27abc4a0554d29f23-- From nobody Fri Jul 21 09:27:09 2017 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 5533C131B29 for ; Fri, 21 Jul 2017 09:27:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=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 MpbJDsrBqGyc for ; Fri, 21 Jul 2017 09:27:05 -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 A3EFF131891 for ; Fri, 21 Jul 2017 09:27:05 -0700 (PDT) Received: from [10.47.60.62] ([62.168.35.66]) (authenticated bits=0) by mail.proper.com (8.15.2/8.14.9) with ESMTPSA id v6LGQ8Vf051406 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 21 Jul 2017 09:26:11 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: mail.proper.com: Host [62.168.35.66] claimed to be [10.47.60.62] From: "Paul Hoffman" To: "Philip Lafrance" Cc: cfrg@irtf.org Date: Fri, 21 Jul 2017 18:26:56 +0200 Message-ID: <001D22D7-2A0C-4DA1-A980-89C78C95A17A@vpnc.org> In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Mailer: MailMate (1.9.6r5347) Archived-At: Subject: Re: [Cfrg] Comments on draft-hoffman-c2pq-01 X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jul 2017 16:27:07 -0000 On 21 Jul 2017, at 14:01, Philip Lafrance wrote: > So I can't express enough how much I support this document. Thanks! > Comments: > > Section 1.3 > > -The definition given for “post-quantum cryptography” > is pretty > limited and kind of inaccurate. The definition as given would suggest > that > ECC is post-quantum as it does not rely on factoring large numbers or > determine the discrete log of a large composite number. > > > Maybe something like: > > > "The term "post-quantum cryptography" refers to the invention and > study of > cryptographic techniques (including encryption, signature and key > exchange > algorithms) that are implementable on a classical computer and are > based on > problems that are believed to be difficult for a quantum computer to > solve. > In particular, this includes algorithms based on lattices, isogenies, > hash-functions, multivariate polynomial systems, and coding theory. It > excludes systems whose security relies on factoring numbers, or the > difficulty of determining the discrete log of one group element with > respect to another." Yes, great. > Section 1.6 > > -The good folks at the Institute for Quantum Computing > have a > good textbook which would be a nice reference (here is a link > http://hep.fcfm.buap.mx/cursos/2014/MCI/An_Intro_to_Quantum.pdf) That book is more limited (and, to my eye, harder to read) than the more popular Nielsen and Chuang. (Side-note: posting URLs to ripped copies of books is a bit tacky...) > Section 2.1 > > -This section seems to only be concerned with using > quantum > algorithms to recover secret key. Why not also mention for example > using > Grover to find collisions to forge signatures? Finding collisions in greater than 2^128 quantum steps doesn't seem like an interesting threat (assuming that you are using a hash like SHA256 or better). > -We should maybe consider replacing “large-scale” > quantum > computer with “universal” quantum computer. I definitely need to work on the terminology here. I'll send out separate messages after I have incorporated some other off-list suggestions in this area that I have received. > -Maybe some discussion about the differences between quantum annealing > and > a universal quantum computer. This would be useful because, for > example > D-Wave is a quantum annealer, not a universal quantum computer, but > the > difference is lost on most people. Understanding the difference is > important if we’re talking about when to transition. This sounds great. Suggestions of text are welcome! --Paul Hoffman From nobody Fri Jul 21 09:32:16 2017 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 B6082131B71 for ; Fri, 21 Jul 2017 09:32:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.4 X-Spam-Level: X-Spam-Status: No, score=-5.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 DKiWEN4s00w8 for ; Fri, 21 Jul 2017 09:32:11 -0700 (PDT) Received: from smtp-p01.blackberry.com (smtp-p01.blackberry.com [208.65.78.88]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B82E131B29 for ; Fri, 21 Jul 2017 09:32:11 -0700 (PDT) Received: from xct103cnc.rim.net ([10.65.161.203]) by mhs211cnc.rim.net with ESMTP/TLS/DHE-RSA-AES256-SHA; 21 Jul 2017 12:32:08 -0400 Received: from XCT116CNC.rim.net (10.65.161.216) by XCT103CNC.rim.net (10.65.161.203) with Microsoft SMTP Server (TLS) id 14.3.319.2; Fri, 21 Jul 2017 12:32:09 -0400 Received: from XMB116CNC.rim.net ([fe80::45d:f4fe:6277:5d1b]) by XCT116CNC.rim.net ([::1]) with mapi id 14.03.0319.002; Fri, 21 Jul 2017 12:32:09 -0400 From: Dan Brown To: Sharon Goldberg , "cfrg@irtf.org" CC: "jan@ns1.com" , Leonid Reyzin , "Dimitrios Papadopoulos" Thread-Topic: [Cfrg] draft-goldbe-vrf: Verifiable Random Functions Thread-Index: AQHS+vM6+DG9anuMcU+xW6RwdHg7uaJZ5FlggASji3c= Date: Fri, 21 Jul 2017 16:32:08 +0000 Message-ID: <20170721163204.8573013.1016.15939@blackberry.com> References: , <810C31990B57ED40B2062BA10D43FBF501B63B22@XMB116CNC.rim.net> In-Reply-To: <810C31990B57ED40B2062BA10D43FBF501B63B22@XMB116CNC.rim.net> Accept-Language: en-US, en-CA Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_201707211632048573013101615939blackberrycom_" MIME-Version: 1.0 Archived-At: Subject: Re: [Cfrg] draft-goldbe-vrf: Verifiable Random Functions X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jul 2017 16:32:15 -0000 --_000_201707211632048573013101615939blackberrycom_ Content-Type: text/plain; charset="windows-1256" Content-Transfer-Encoding: quoted-printable Answering myself below: VRFs have been around since 1999, so are not so new= . =FDStill don't like the name, and still have trouble seeing the value. From: Dan Brown Sent: Tuesday, July 18, 2017 2:29 PM To: Sharon Goldberg; cfrg@irtf.org Cc: jan@ns1.com; Leonid Reyzin; Dimitrios Papadopoulos Subject: Re: [Cfrg] draft-goldbe-vrf: Verifiable Random Functions Hi Sharon and CFRG, On VRFs, my uncertain comments to consider at your leisure: Is it fair to say VRFs are relatively new? If so, then maybe a little more= caution is needed about their use. It seems a tad hasty that it is being = used already. To me, it seems that VRFs are basically signatures, with an extra feature. = My concern is that this extra feature might get overused, before it is tho= roughly reviewed. It is unsurprising to me that random oracle model proof can prove the outpu= t of a hash to be random. My intuitive concern is that at least informally= , this is kind of circular. Hashes often have some non-random-ish properti= es that might affect the extra security (over signatures) that VRFs are aim= ing for. I guess I would much prefer a proof saying if the hash has (well-= studied) properties XYZ, then your construction are VRFs. (Maybe you have = this already? If so, then tell me so.) Since, VRFs require sending the =93proofs=94 on the wire, I find it hard to= see how it could be used to prevent dictionary attacks. I assume that you= are saying the proofs must be encrypted when one needs to avoid dictionary= models? I suppose all the details are there in I-D and papers, but for no= w, I am confused about the threat model (which parties have keys, etc., if = they require a secure channel and mutual trust, why just use plain old hash= ,=85). To resist dictionary attacks, were already have PAKEs and PBHashing.= Now this? Finally, on a bikeshed-coloring note, I object to the name =93verifiable ra= ndom function=94, on several grounds. 1. It is not a function. It is at least four functions, keygen, sign, v= erify, and hashify. 2. If you make it into a keyed function F_sk(m), as in prooftohash(sign_= sk(m)), it is not verifiable. 3. Verification requires the intermediate proof, which is certainly not = even pseudorandom (it is easy to distinguish valid signatures from random). 4. It is pseudorandom, not random. (The keys are random, but many crypt= o has keys, without having =93random=94 in its name: encryption, MAC, signa= tures, key exchange, =85, they also don=92t verifiable or random in their n= ames either.) 5. The similar phrase =93verifiably random=94, albeit as a misnomer, has= past precedents, see NIST P-256 and Brainpool, etc. When I see VRF, I thi= nk a function, that aims to VR in that sense, and great, now we can improve= on Brainpool, etc. 6. =93Random function=94 should be reserved for the ideal random mapping= concept, for example, as studied by Flajolet-Odlyzko (ok they only studied= the case of equal size domain and range). The random oracle model, is the= idea of approximating this ideal, etc. An actual approximation should not= be name as the ideal (sorry, I=92m kind of repeating my point 4). Please forgive the fact that my comments above are not very constructive (o= r if the tone is wrong). This is a new topic for me, so I am reluctant too= many suggestions. Nonetheless, I suggest (0) waiting a little, (1) a non-= random-oracle security proof (if you don=92t have it yet), (2) re-naming th= e scheme to something like re-hashable (or digestible) signatures (and re-n= ame the various parts, i.e. proof -> signature, etc.). Best regards, Dan From: Cfrg [mailto:cfrg-bounces@irtf.org] On Behalf Of Sharon Goldberg Sent: Wednesday, July 12, 2017 5:42 AM To: cfrg@irtf.org Cc: jan@ns1.com; Dimitrios Papadopoulos ; Leonid Reyzin <= reyzin@cs.bu.edu> Subject: [Cfrg] draft-goldbe-vrf: Verifiable Random Functions Dear CFRG, I'm presenting at next week's meeting on Verifiable Random Functions. A VRF= is the public-key version of keyed cryptographic hash. Only the holder of = the VRF secret key can compute the hash, but anyone with the public key can= verify it. VRFs can be used to prevent dictionary attacks on hash-based d= ata structures, and have applications to key transparency (CONIKS), DNSSEC = (NSEC5), and cryptocurrencies (Algorand). In advance of the meeting, please see: 1) Our substantially updated -01 draft: https://datatracker.ietf.org/doc/draft-goldbe-vrf/ 2) Our project page, with links to various VRF implementations: https://www.cs.bu.edu/~goldbe/projects/vrf Comments welcome. Thanks, Sharon -- Sharon Goldberg Computer Science, Boston University http://www.cs.bu.edu/~goldbe --_000_201707211632048573013101615939blackberrycom_ Content-Type: text/html; charset="windows-1256" Content-Transfer-Encoding: quoted-printable

From: Dan Brown
Sent: Tuesday, July 18, 2017 2:29 PM
To: Sharon Goldberg; cfrg@irtf.org
Cc: jan@ns1.com; Leonid Reyzin; Dimitrios Papadopoulos
Subject: Re: [Cfrg] draft-goldbe-vrf: Verifiable Random Functio= ns

Hi Sharon and CFRG,

 

On VRFs, my uncertain comments to consider at your= leisure:

 

Is it fair to say VRFs are relatively new?  I= f so, then maybe a little more caution is needed about their use.  It = seems a tad hasty that it is being used already.

 

To me, it seems that VRFs are basically signatures= , with an extra feature.  My concern is that this extra feature might = get overused, before it is thoroughly reviewed. 

 

It is unsurprising to me that random oracle model = proof can prove the output of a hash to be random.  My intuitive conce= rn is that at least informally, this is kind of circular.  Hashes often have some non-random-ish properties that might affect the ext= ra security (over signatures) that VRFs are aiming for.  I guess I wou= ld much prefer a proof saying if the hash has (well-studied) properties XYZ= , then your construction are VRFs.  (Maybe you have this already?  If so, then tell me so.)

 

Since, VRFs require sending the =93proofs=94 on th= e wire, I find it hard to see how it could be used to prevent dictionary at= tacks.  I assume that you are saying the proofs must be encrypted when one needs to avoid dictionary models?  I suppose al= l the details are there in I-D and papers, but for now, I am confused about= the threat model (which parties have keys, etc., if they require a secure = channel and mutual trust, why just use plain old hash,=85). To resist dictionary attacks, were already have PAKEs= and PBHashing.  Now this?

 

Finally, on a bikeshed-coloring note, I object to = the name =93verifiable random function=94, on several grounds.

 

  1. It is not a func= tion.  It is at least four functions, keygen, sign, verify, and hashif= y.
  2. If= you make it into a keyed function F_sk(m), as in prooftohash(sign_sk(m)), = it is not verifiable. 
  3. Veri= fication requires the intermediate proof, which is certainly not even pseud= orandom (it is easy to distinguish valid signatures from random).
  4. It is pseudora= ndom, not random.  (The keys are random, but many crypto has keys, wit= hout having =93random=94 in its name: encryption, MAC, signatures, key exchange, =85, they also don=92t verifiable or random in their names e= ither.)
  5. The similar phrase =93verifiably random=94, albeit as a misnomer, has pa= st precedents, see NIST P-256 and Brainpool, etc.  When I see VRF, I t= hink a function, that aims to VR in that sense, and great, now we can improve o= n Brainpool, etc.
  6. =93Random function=94 should be reserved for the ideal random = mapping concept, for example, as studied by Flajolet-Odlyzko (ok they only = studied the case of equal size domain and range).  The random oracle model, i= s the idea of approximating this ideal, etc.  An actual approximation = should not be name as the ideal (sorry, I=92m kind of repeating my point 4)= .

 

Please forgive the fact that my comments above are= not very constructive (or if the tone is wrong).  This is a new topic= for me, so I am reluctant too many suggestions.  Nonetheless, I suggest (0) waiting a little, (1) a non-random-oracle security proof (if= you don=92t have it yet), (2) re-naming the scheme to something like re-ha= shable (or digestible) signatures (and re-name the various parts, i.e. proo= f -> signature, etc.).

 

Best regards,

 

Dan

 

 

From: Cfrg [mailto:cfrg-bounces@ir= tf.org] On Behalf Of Sharon Goldberg
Sent: Wednesday, July 12, 2017 5:42 AM
To: cfrg@irtf.org
Cc: jan@ns1.com; Dimitrios Papadopoulos <dipapado@umd.edu>; Le= onid Reyzin <reyzin@cs.bu.edu>
Subject: [Cfrg] draft-goldbe-vrf: Verifiable Random Functions=

 

Dear CFRG,

I'm presenting at next week's meeting on Verifiable Random Functions. A VRF= is the public-key version of keyed cryptographic hash. Only the holder of = the VRF secret key can compute the hash, but anyone with the public key can= verify it.  VRFs can be used to prevent dictionary attacks on hash-based data structures, and have applica= tions to key transparency (CONIKS), DNSSEC (NSEC5), and cryptocurrencies (A= lgorand).

In advance of the meeting, please see:

1) Our substantially updated -01 draft:
https://datatracker.ietf.org/doc/draft-goldbe-vrf/

2) Our project page, with links to various VRF implementations:
ht= tps://www.cs.bu.edu/~goldbe/projects/vrf

Comments welcome.  Thanks,

Sharon

--
Sharon Goldberg
Computer Science, Boston University
http://www.cs.bu= .edu/~goldbe

--_000_201707211632048573013101615939blackberrycom_-- From nobody Fri Jul 21 19:37:39 2017 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 8446A1270A3 for ; Fri, 21 Jul 2017 19:37:37 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 i1J4YakoAB7r for ; Fri, 21 Jul 2017 19:37:34 -0700 (PDT) Received: from mail-pg0-x236.google.com (mail-pg0-x236.google.com [IPv6:2607:f8b0:400e:c05::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 BD5AA126BF3 for ; Fri, 21 Jul 2017 19:37:34 -0700 (PDT) Received: by mail-pg0-x236.google.com with SMTP id k14so35446115pgr.0 for ; Fri, 21 Jul 2017 19:37:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=QRrNbnMg2WA4qPmCsK0eW2zbNf+wbFAep7Rg666aVck=; b=DZHkBcz6PSbsiZVab8N22loSp/Em4Ym9L0/VEmuFhT3HnTZLnewWpM1pM/WyxK+cLT cXygwCRTwCblqmzuoXp6FRPg9ZMSGockvTfoBaWgql3xq2gVBbE+ZGc+eMTC0JeXBfRp NAhX0a9OCeJDa+Qlr6neh6XO08fRt5re97OJFZoXgpK91iC4qxdfNcnss4eCbvOMeSoB d5UPYw2UN3Fd8zOuSiZ3lpfneAwgnqbdGn3VjrRMn4ynQXKVXQ+CvfzW+VhcPVK1dItD Cnzifx7jaGqTbDAPCb3NG23rAedlyepqsoPlhu+3QiMksn3FVe3k0LILvuQnL/P0eolh lRTg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=QRrNbnMg2WA4qPmCsK0eW2zbNf+wbFAep7Rg666aVck=; b=hAWPboya4FtQwCUanPnv4LKD5X0Dd29+rHPrfE47VJX0Gu4E3CX2RqXugEWrB7hE/Q ae7709Zt1XPo2Wj+MTawstRExNh6O7LtaIErempTqmrJ1NhDHp4/1yC9yiZ6zvuHNjho x7Kf7oOKdz0hD6uSvJ+WBb2wBkNHRZ6/V3YqviVTvCZHwAYMVtQZoGBJq7N46IAsHl1H yka4bVIaQo5x/sXKt6s3iDCuvnb8F+KPJAaYUsKFue335DElaBg2Htnwi8xvjpZ48I+k Di64mxy+9NsKw9+Wz6Oxc9Fr+z6NGXNxjGiaACVBtpNPOxqI7JjZ25IkFyh320sC7IQO C9Aw== X-Gm-Message-State: AIVw112kUKyT8ql3+yAZtwHrTWlRKTRZYeYy4cPiZU5TWGdYZtJMeI9c UmevaZrII1g59LqBAwtA47rFjH6Prw== X-Received: by 10.98.38.68 with SMTP id m65mr9280308pfm.47.1500691054342; Fri, 21 Jul 2017 19:37:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.187.77 with HTTP; Fri, 21 Jul 2017 19:37:33 -0700 (PDT) In-Reply-To: <20170721163204.8573013.1016.15939@blackberry.com> References: <810C31990B57ED40B2062BA10D43FBF501B63B22@XMB116CNC.rim.net> <20170721163204.8573013.1016.15939@blackberry.com> From: Watson Ladd Date: Fri, 21 Jul 2017 19:37:33 -0700 Message-ID: To: Dan Brown Cc: Sharon Goldberg , "cfrg@irtf.org" , "jan@ns1.com" , Dimitrios Papadopoulos , Leonid Reyzin Content-Type: multipart/alternative; boundary="94eb2c0ca0003643b00554deddb2" Archived-At: Subject: Re: [Cfrg] draft-goldbe-vrf: Verifiable Random Functions X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Jul 2017 02:37:37 -0000 --94eb2c0ca0003643b00554deddb2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Two applications: -NSEC5 uses VRFs to use online signing for zonewalking prevention and offline signing for authenticity. - Cloudflare uses OPRFs, a slightly different construction, to improve the experience of Tor users On Fri, Jul 21, 2017 at 9:32 AM, Dan Brown wrote= : > Answering myself below: VRFs have been around since 1999, so are not so > new. =E2=80=8EStill don't like the name, and still have trouble seeing t= he value. > > *From: *Dan Brown > *Sent: *Tuesday, July 18, 2017 2:29 PM > *To: *Sharon Goldberg; cfrg@irtf.org > *Cc: *jan@ns1.com; Leonid Reyzin; Dimitrios Papadopoulos > *Subject: *Re: [Cfrg] draft-goldbe-vrf: Verifiable Random Functions > > Hi Sharon and CFRG, > > > > On VRFs, my uncertain comments to consider at your leisure: > > > > Is it fair to say VRFs are relatively new? If so, then maybe a little > more caution is needed about their use. It seems a tad hasty that it is > being used already. > > > > To me, it seems that VRFs are basically signatures, with an extra > feature. My concern is that this extra feature might get overused, befor= e > it is thoroughly reviewed. > > > > It is unsurprising to me that random oracle model proof can prove the > output of a hash to be random. My intuitive concern is that at least > informally, this is kind of circular. Hashes often have some > non-random-ish properties that might affect the extra security (over > signatures) that VRFs are aiming for. I guess I would much prefer a proo= f > saying if the hash has (well-studied) properties XYZ, then your > construction are VRFs. (Maybe you have this already? If so, then tell m= e > so.) > > > > Since, VRFs require sending the =E2=80=9Cproofs=E2=80=9D on the wire, I f= ind it hard to > see how it could be used to prevent dictionary attacks. I assume that yo= u > are saying the proofs must be encrypted when one needs to avoid dictionar= y > models? I suppose all the details are there in I-D and papers, but for > now, I am confused about the threat model (which parties have keys, etc., > if they require a secure channel and mutual trust, why just use plain old > hash,=E2=80=A6). To resist dictionary attacks, were already have PAKEs an= d > PBHashing. Now this? > > > > Finally, on a bikeshed-coloring note, I object to the name =E2=80=9Cverif= iable > random function=E2=80=9D, on several grounds. > > > > 1. It is not a function. It is at least four functions, keygen, sign, > verify, and hashify. > 2. If you make it into a keyed function F_sk(m), as in > prooftohash(sign_sk(m)), it is not verifiable. > 3. Verification requires the intermediate proof, which is certainly > not even pseudorandom (it is easy to distinguish valid signatures from > random). > 4. It is pseudorandom, not random. (The keys are random, but many > crypto has keys, without having =E2=80=9Crandom=E2=80=9D in its name: = encryption, MAC, > signatures, key exchange, =E2=80=A6, they also don=E2=80=99t verifiabl= e or random in their > names either.) > 5. The similar phrase =E2=80=9Cverifiably random=E2=80=9D, albeit as a= misnomer, has > past precedents, see NIST P-256 and Brainpool, etc. When I see VRF, I > think a function, that aims to VR in that sense, and great, now we can > improve on Brainpool, etc. > 6. =E2=80=9CRandom function=E2=80=9D should be reserved for the ideal = random mapping > concept, for example, as studied by Flajolet-Odlyzko (ok they only stu= died > the case of equal size domain and range). The random oracle model, is= the > idea of approximating this ideal, etc. An actual approximation should= not > be name as the ideal (sorry, I=E2=80=99m kind of repeating my point 4)= . > > > > Please forgive the fact that my comments above are not very constructive > (or if the tone is wrong). This is a new topic for me, so I am reluctant > too many suggestions. Nonetheless, I suggest (0) waiting a little, (1) a > non-random-oracle security proof (if you don=E2=80=99t have it yet), (2) = re-naming > the scheme to something like re-hashable (or digestible) signatures (and > re-name the various parts, i.e. proof -> signature, etc.). > > > > Best regards, > > > > Dan > > > > > > *From:* Cfrg [mailto:cfrg-bounces@irtf.org] *On Behalf Of *Sharon Goldber= g > *Sent:* Wednesday, July 12, 2017 5:42 AM > *To:* cfrg@irtf.org > *Cc:* jan@ns1.com; Dimitrios Papadopoulos ; Leonid > Reyzin > *Subject:* [Cfrg] draft-goldbe-vrf: Verifiable Random Functions > > > > Dear CFRG, > > I'm presenting at next week's meeting on Verifiable Random Functions. A > VRF is the public-key version of keyed cryptographic hash. Only the holde= r > of the VRF secret key can compute the hash, but anyone with the public ke= y > can verify it. VRFs can be used to prevent dictionary attacks on > hash-based data structures, and have applications to key transparency > (CONIKS), DNSSEC (NSEC5), and cryptocurrencies (Algorand). > > In advance of the meeting, please see: > > 1) Our substantially updated -01 draft: > https://datatracker.ietf.org/doc/draft-goldbe-vrf/ > > 2) Our project page, with links to various VRF implementations: > https://www.cs.bu.edu/~goldbe/projects/vrf > > Comments welcome. Thanks, > > Sharon > > -- > Sharon Goldberg > Computer Science, Boston University > http://www.cs.bu.edu/~goldbe > > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > https://www.irtf.org/mailman/listinfo/cfrg > > --=20 "Man is born free, but everywhere he is in chains". --Rousseau. --94eb2c0ca0003643b00554deddb2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Two applications:
-NSEC5 uses VRFs to use online= signing for zonewalking prevention and offline signing for authenticity.- Cloudflare uses OPRFs, a slightly different construction, to improve t= he experience of Tor users



On Fri, Jul 21, 2017 at = 9:32 AM, Dan Brown <danibrown@blackberry.com> wrote:<= br>
Answering myself below: VRFs have been around since 1999, so are not so new= . =C2=A0=E2=80=8EStill don't like the name, and still have trouble seei= ng the value.

From: Dan Brown
Sent: Tuesday, July 18, 2017 2:29 PM
To: Sharon Goldberg; cfrg@irtf.org
Cc: jan@ns1.co= m; Leonid Reyzin; Dimitrios Papadopoulos
Subject: Re: [Cfrg] draft-goldbe-vrf: Verifiable Random Functio= ns

Hi Sharon and CFRG,

=C2=A0

On VRFs, my uncertain comments to consider at your = leisure:

=C2=A0

Is it fair to say VRFs are relatively new?=C2=A0 If= so, then maybe a little more caution is needed about their use.=C2=A0 It s= eems a tad hasty that it is being used already.

=C2=A0

To me, it seems that VRFs are basically signatures,= with an extra feature.=C2=A0 My concern is that this extra feature might g= et overused, before it is thoroughly reviewed.=C2=A0

=C2=A0

It is unsurprising to me that random oracle model p= roof can prove the output of a hash to be random.=C2=A0 My intuitive concer= n is that at least informally, this is kind of circular.=C2=A0 Hashes often have some non-random-ish properties that might affect the ext= ra security (over signatures) that VRFs are aiming for.=C2=A0 I guess I wou= ld much prefer a proof saying if the hash has (well-studied) properties XYZ= , then your construction are VRFs.=C2=A0 (Maybe you have this already?=C2=A0 If so, then tell me so.)

=C2=A0

Since, VRFs require sending the =E2=80=9Cproofs=E2= =80=9D on the wire, I find it hard to see how it could be used to prevent d= ictionary attacks.=C2=A0 I assume that you are saying the proofs must be encrypted when one needs to avoid dictionary models?=C2=A0 I suppose al= l the details are there in I-D and papers, but for now, I am confused about= the threat model (which parties have keys, etc., if they require a secure = channel and mutual trust, why just use plain old hash,=E2=80=A6). To resist dictionary attacks, were already have= PAKEs and PBHashing.=C2=A0 Now this?

=C2=A0

Finally, on a bikeshed-coloring note, I object to t= he name =E2=80=9Cverifiable random function=E2=80=9D, on several grounds.

=C2=A0

  1. It is not a function.=C2=A0 It is at least four functions, keygen, sign= , verify, and hashify.
  2. If you make it into a keyed function = F_sk(m), as in prooftohash(sign_sk(m)), it is not verifiable.=C2=A0
  3. Verification requires the intermediate proof, which is cert= ainly not even pseudorandom (it is easy to distinguish valid signatures fro= m random).
  4. It is pseudorandom, not random.=C2=A0 (The keys a= re random, but many crypto has keys, without having =E2=80=9Crandom=E2=80= =9D in its name: encryption, MAC, signatures, key exchange, =E2=80=A6, they also don=E2=80=99t verifiable or random in t= heir names either.)
  5. The similar phrase =E2=80=9Cverifiably r= andom=E2=80=9D, albeit as a misnomer, has past precedents, see NIST P-256 a= nd Brainpool, etc.=C2=A0 When I see VRF, I think a function, that aims to VR in that sense, and great, now we can improve o= n Brainpool, etc.
  6. =E2=80=9CRandom function=E2=80=9D should b= e reserved for the ideal random mapping concept, for example, as studied by= Flajolet-Odlyzko (ok they only studied the case of equal size domain and range).=C2=A0 The random oracle model, i= s the idea of approximating this ideal, etc.=C2=A0 An actual approximation = should not be name as the ideal (sorry, I=E2=80=99m kind of repeating my po= int 4).

=C2=A0

Please forgive the fact that my comments above are = not very constructive (or if the tone is wrong).=C2=A0 This is a new topic = for me, so I am reluctant too many suggestions.=C2=A0 Nonetheless, I suggest (0) waiting a little, (1) a non-random-oracle security proof (if= you don=E2=80=99t have it yet), (2) re-naming the scheme to something like= re-hashable (or digestible) signatures (and re-name the various parts, i.e= . proof -> signature, etc.).

=C2=A0

Best regards,

=C2=A0

Dan

=C2=A0

=C2=A0

From: Cfrg [mailto:cfrg-bounces@irtf.org] On Behalf Of Sharon Goldberg
Sent: Wednesday, July 12, 2017 5:42 AM
To: cfrg@irtf.org=
Cc: jan@ns1.com= ; Dimitrios Papadopoulos <dipapado@umd.edu>; Leonid Reyzin <reyzin@cs.bu.edu>
Subject: [Cfrg] draft-goldbe-vrf: Verifiable Random Functions=

=C2=A0

Dear CFRG,

I'm presenting at next week's meeting on Verifiable Random Function= s. A VRF is the public-key version of keyed cryptographic hash. Only the ho= lder of the VRF secret key can compute the hash, but anyone with the public= key can verify it.=C2=A0 VRFs can be used to prevent dictionary attacks on hash-based data structures, and have applica= tions to key transparency (CONIKS), DNSSEC (NSEC5), and cryptocurrencies (A= lgorand).

In advance of the meeting, please see:

1) Our substantially updated -01 draft:
https://datatracker.ietf.org/doc/draft-goldbe-vrf/

2) Our project page, with links to various VRF implementations:
ht= tps://www.cs.bu.edu/~goldbe/projects/vrf

Comments welcome.=C2=A0 Thanks,

Sharon

--
Sharon Goldberg
Computer Science, Boston University
http://www.cs.bu= .edu/~goldbe


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




--
"Man is born= free, but everywhere he is in chains".
--Rousseau.
--94eb2c0ca0003643b00554deddb2-- From nobody Sat Jul 22 09:08:47 2017 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 97DE3126CD8 for ; Sat, 22 Jul 2017 09:08:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.689 X-Spam-Level: X-Spam-Status: No, score=-2.689 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, T_FILL_THIS_FORM_SHORT=0.01] 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 8xZpf0oN0Rhi for ; Sat, 22 Jul 2017 09:08:45 -0700 (PDT) Received: from mail-yw0-x231.google.com (mail-yw0-x231.google.com [IPv6:2607:f8b0:4002:c05::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 4FD59120725 for ; Sat, 22 Jul 2017 09:08:45 -0700 (PDT) Received: by mail-yw0-x231.google.com with SMTP id v128so7445096ywb.1 for ; Sat, 22 Jul 2017 09:08:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=7Ksn7Ujf3gvETzc+xUApNC3fyAL6E7sMfYUlWLUS1EA=; b=DLfXUiblCXgl2OE6q7hV4vv4rZOruRd7KtMXNMFlt16/gWih+Ef+QJ0tQt+s5CSFFl k5/2MP/OYQ00lzGdNdaQIHDzQUd5ow6fNKOYc2GIen+eg2b1gf7Sz2Xp3QCfULB+uQCV SY1GWIitFq6J1VayO9xCzRdj95vJko7B9N14mI/HxD8nY58QSe4kbQbOj7VIEYCbbcpZ ooNZGyuxx3Yh4v06aKDoNNm4iThHWyqzWbp3Box3Qnn3Y3Hrd1UegQ+a/RLLD+/1ckWi Y6VLkEqduabBmO9KGMT3FDuZDFAbIELujJv7i/4IBGCPSojFoUlbvhk1YeoMY0i/K7uj AuEQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=7Ksn7Ujf3gvETzc+xUApNC3fyAL6E7sMfYUlWLUS1EA=; b=gwQjUlfnCeyeZRhSX3dzA/DPIerwqmndUYOXZtys9C47wsP5xtqIzWZa89Qfk8VvJS TvbXiNS/YdNG0IHOX9uOE7q+Ww8HINdQ2gU/k9+c6P6IXZG3pVsZTkygPvNnUnC6b6Cz F6pqEq4SrMlntC3KmJpUHXa51tyoxeRWqZ029YfSeezfz1dGI/r9T03lc5wqEU0GNLlM Vulm8jlwspeJSf4o/3nrnF1NqbfownNPjBa2hfRrnKBI6dHlJPdZurLRoW7iwpCyNYbd 1VzV5kGLQNUe7KoE5v1xMpft/yXY+W49HndEHfl75eS7w1pghqQZ9U5tX4ArER897E2Y Qyfg== X-Gm-Message-State: AIVw110KTmGA6NP0XXyfX6vhiRTEbG1sTq7RHNXT35hkKw0NU4zYX6ny D5lIMnyk2Ok6z5Tpslc6uyq1af/exw== X-Received: by 10.13.229.132 with SMTP id o126mr10695402ywe.186.1500739724414; Sat, 22 Jul 2017 09:08:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.170.132 with HTTP; Sat, 22 Jul 2017 09:08:23 -0700 (PDT) In-Reply-To: <20170721163204.8573013.1016.15939@blackberry.com> References: <810C31990B57ED40B2062BA10D43FBF501B63B22@XMB116CNC.rim.net> <20170721163204.8573013.1016.15939@blackberry.com> From: Tony Arcieri Date: Sat, 22 Jul 2017 09:08:23 -0700 Message-ID: To: Dan Brown Cc: Sharon Goldberg , "cfrg@irtf.org" , "jan@ns1.com" , Dimitrios Papadopoulos , Leonid Reyzin Content-Type: multipart/alternative; boundary="94eb2c07f9f02cadf50554ea321a" Archived-At: Subject: Re: [Cfrg] draft-goldbe-vrf: Verifiable Random Functions X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Jul 2017 16:08:46 -0000 --94eb2c07f9f02cadf50554ea321a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Jul 21, 2017 at 9:32 AM, Dan Brown wrote= : > Answering myself below: VRFs have been around since 1999, so are not so > new. =E2=80=8EStill don't like the name, and still have trouble seeing t= he value. > VRFs provide deterministic precommitments you can reveal at a later time. This is useful if you want to maintain a 1:1 mapping of low entropy inputs (e.g. names, email addresses, phone numbers) to some random values you can commit to in advance, e.g. through a timestamping service/transparency log. Using a VRF means you can make these random outputs effectively public without them being subject to a preimage attack (so long as the VRF private key is not leaked). This way a key transparency server can prove a given user's keys were included in a transparency log without enabling spammers to obtain all of the names in the directory. --=20 Tony Arcieri --94eb2c07f9f02cadf50554ea321a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On F= ri, Jul 21, 2017 at 9:32 AM, Dan Brown <danibrown@blackberry.com> wrote:
Answering myself below: VRFs have been around since 1999, so are not so new= . =C2=A0=E2=80=8EStill don't like the name, and still have trouble seei= ng the value.

VRFs provide dete= rministic precommitments you can reveal at a later time. This is useful if = you want to maintain a 1:1 mapping of low entropy inputs (e.g. names, email= addresses, phone numbers) to some random values you can commit to in advan= ce, e.g. through a timestamping service/transparency log.

Using a VRF means you can make these random outputs effectively pub= lic without them being subject to a preimage attack (so long as the VRF pri= vate key is not leaked). This way a key transparency server can prove a giv= en user's keys were included in a transparency log without enabling spa= mmers to obtain all of the names in the directory.

--
= Tony Arcieri
--94eb2c07f9f02cadf50554ea321a-- From nobody Sat Jul 22 19:26:02 2017 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 57351131A4C for ; Sat, 22 Jul 2017 19:26:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.188 X-Spam-Level: X-Spam-Status: No, score=-4.188 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, T_FILL_THIS_FORM_SHORT=0.01, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=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 llV5wYgfi0Ox for ; Sat, 22 Jul 2017 19:25:58 -0700 (PDT) Received: from llmx2.ll.mit.edu (LLMX2.LL.MIT.EDU [129.55.12.48]) by ietfa.amsl.com (Postfix) with ESMTP id 718ED127B73 for ; Sat, 22 Jul 2017 19:25:58 -0700 (PDT) Received: from LLE2K10-HUB01.mitll.ad.local (LLE2K10-HUB01.mitll.ad.local) by llmx2.ll.mit.edu (unknown) with ESMTP id v6N2Pt7m005041; Sat, 22 Jul 2017 22:25:55 -0400 From: "Blumenthal, Uri - 0553 - MITLL" To: Tony Arcieri , "cfrg@irtf.org" Thread-Topic: [Cfrg] draft-goldbe-vrf: Verifiable Random Functions Thread-Index: AQHS+vNP80F0E1pfY0yQXqh5796h7KJaNJwAgASWVQCAAYuygIAArIiA Date: Sun, 23 Jul 2017 02:25:54 +0000 Message-ID: References: <810C31990B57ED40B2062BA10D43FBF501B63B22@XMB116CNC.rim.net> <20170721163204.8573013.1016.15939@blackberry.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Content-Type: multipart/signed; boundary="Apple-Mail-A25145B9-9C9B-4A83-986C-FAF07A1A5B34"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-22_19:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default 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-1706020000 definitions=main-1707230037 Archived-At: Subject: Re: [Cfrg] draft-goldbe-vrf: Verifiable Random Functions X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Jul 2017 02:26:00 -0000 --Apple-Mail-A25145B9-9C9B-4A83-986C-FAF07A1A5B34 Content-Type: multipart/alternative; boundary=Apple-Mail-076A17C2-D9F3-4AF2-A400-4213207B7FF3 Content-Transfer-Encoding: 7bit --Apple-Mail-076A17C2-D9F3-4AF2-A400-4213207B7FF3 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 QW5kIEkgd291bGQgKnJlYWxseSogbG92ZSBpdCBpZiB3ZSBjb3VsZCBoYXZlIHNvbWV0aGluZyBs aWtlIEVsbGlnYXRvciBmb3IgbW9yZSBjdXJ2ZXMsIHN1Y2ggYXMgdGhlIE5JU1QtZGVmaW5lZC4u Lg0KDQpSZWdhcmRzLA0KVXJpDQoNClNlbnQgZnJvbSBteSBpUGhvbmUNCg0KPiBPbiBKdWwgMjIs IDIwMTcsIGF0IDEyOjA5LCBUb255IEFyY2llcmkgPGJhc2N1bGVAZ21haWwuY29tPiB3cm90ZToN Cj4gDQo+PiBPbiBGcmksIEp1bCAyMSwgMjAxNyBhdCA5OjMyIEFNLCBEYW4gQnJvd24gPGRhbmli cm93bkBibGFja2JlcnJ5LmNvbT4gd3JvdGU6DQo+PiBBbnN3ZXJpbmcgbXlzZWxmIGJlbG93OiBW UkZzIGhhdmUgYmVlbiBhcm91bmQgc2luY2UgMTk5OSwgc28gYXJlIG5vdCBzbyBuZXcuICDigI5T dGlsbCBkb24ndCBsaWtlIHRoZSBuYW1lLCBhbmQgc3RpbGwgaGF2ZSB0cm91YmxlIHNlZWluZyB0 aGUgdmFsdWUuDQo+IA0KPiBWUkZzIHByb3ZpZGUgZGV0ZXJtaW5pc3RpYyBwcmVjb21taXRtZW50 cyB5b3UgY2FuIHJldmVhbCBhdCBhIGxhdGVyIHRpbWUuIFRoaXMgaXMgdXNlZnVsIGlmIHlvdSB3 YW50IHRvIG1haW50YWluIGEgMToxIG1hcHBpbmcgb2YgbG93IGVudHJvcHkgaW5wdXRzIChlLmcu IG5hbWVzLCBlbWFpbCBhZGRyZXNzZXMsIHBob25lIG51bWJlcnMpIHRvIHNvbWUgcmFuZG9tIHZh bHVlcyB5b3UgY2FuIGNvbW1pdCB0byBpbiBhZHZhbmNlLCBlLmcuIHRocm91Z2ggYSB0aW1lc3Rh bXBpbmcgc2VydmljZS90cmFuc3BhcmVuY3kgbG9nLg0KPiANCj4gVXNpbmcgYSBWUkYgbWVhbnMg eW91IGNhbiBtYWtlIHRoZXNlIHJhbmRvbSBvdXRwdXRzIGVmZmVjdGl2ZWx5IHB1YmxpYyB3aXRo b3V0IHRoZW0gYmVpbmcgc3ViamVjdCB0byBhIHByZWltYWdlIGF0dGFjayAoc28gbG9uZyBhcyB0 aGUgVlJGIHByaXZhdGUga2V5IGlzIG5vdCBsZWFrZWQpLiBUaGlzIHdheSBhIGtleSB0cmFuc3Bh cmVuY3kgc2VydmVyIGNhbiBwcm92ZSBhIGdpdmVuIHVzZXIncyBrZXlzIHdlcmUgaW5jbHVkZWQg aW4gYSB0cmFuc3BhcmVuY3kgbG9nIHdpdGhvdXQgZW5hYmxpbmcgc3BhbW1lcnMgdG8gb2J0YWlu IGFsbCBvZiB0aGUgbmFtZXMgaW4gdGhlIGRpcmVjdG9yeS4NCj4gDQo+IC0tIA0KPiBUb255IEFy Y2llcmkNCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N Cj4gQ2ZyZyBtYWlsaW5nIGxpc3QNCj4gQ2ZyZ0BpcnRmLm9yZw0KPiBodHRwczovL3d3dy5pcnRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL2NmcmcNCg== --Apple-Mail-076A17C2-D9F3-4AF2-A400-4213207B7FF3 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 PGh0bWw+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj0iY29udGVudC10eXBlIiBjb250ZW50PSJ0ZXh0 L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPjwvaGVhZD48Ym9keSBkaXI9ImF1dG8iPjxkaXY+QW5kIEkg d291bGQgKnJlYWxseSogbG92ZSBpdCBpZiB3ZSBjb3VsZCBoYXZlIHNvbWV0aGluZyBsaWtlIEVs bGlnYXRvciBmb3IgbW9yZSBjdXJ2ZXMsIHN1Y2ggYXMgdGhlIE5JU1QtZGVmaW5lZC4uLjxicj48 YnI+UmVnYXJkcyw8ZGl2PlVyaTwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+U2VudCBmcm9tIG15 IGlQaG9uZTwvZGl2PjwvZGl2PjxkaXY+PGJyPk9uIEp1bCAyMiwgMjAxNywgYXQgMTI6MDksIFRv bnkgQXJjaWVyaSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmJhc2N1bGVAZ21haWwuY29tIj5iYXNjdWxl QGdtYWlsLmNvbTwvYT4mZ3Q7IHdyb3RlOjxicj48YnI+PC9kaXY+PGJsb2NrcXVvdGUgdHlwZT0i Y2l0ZSI+PGRpdj48bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9InRleHQv aHRtbDsgY2hhcnNldD11dGYtOCI+PGRpdiBkaXI9Imx0ciI+PGRpdiBjbGFzcz0iZ21haWxfZXh0 cmEiPjxkaXYgY2xhc3M9ImdtYWlsX3F1b3RlIj5PbiBGcmksIEp1bCAyMSwgMjAxNyBhdCA5OjMy IEFNLCBEYW4gQnJvd24gPHNwYW4gZGlyPSJsdHIiPiZsdDs8YSBocmVmPSJtYWlsdG86ZGFuaWJy b3duQGJsYWNrYmVycnkuY29tIiB0YXJnZXQ9Il9ibGFuayI+ZGFuaWJyb3duQGJsYWNrYmVycnku Y29tPC9hPiZndDs8L3NwYW4+IHdyb3RlOjxicj48YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVv dGUiIHN0eWxlPSJtYXJnaW46MCAwIDAgLjhleDtib3JkZXItbGVmdDoxcHggI2NjYyBzb2xpZDtw YWRkaW5nLWxlZnQ6MWV4Ij4NCg0KDQoNCg0KPGRpdiBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIg dmxpbms9InB1cnBsZSI+DQo8ZGl2IHN0eWxlPSJ3aWR0aDoxMDAlO2ZvbnQtc2l6ZTppbml0aWFs O2ZvbnQtZmFtaWx5OkNhbGlicmksJ1NsYXRlIFBybycsc2Fucy1zZXJpZixzYW5zLXNlcmlmO2Nv bG9yOnJnYigzMSw3MywxMjUpO3RleHQtYWxpZ246aW5pdGlhbDtiYWNrZ3JvdW5kLWNvbG9yOnJn YigyNTUsMjU1LDI1NSkiPg0KQW5zd2VyaW5nIG15c2VsZiBiZWxvdzogVlJGcyBoYXZlIGJlZW4g YXJvdW5kIHNpbmNlIDE5OTksIHNvIGFyZSBub3Qgc28gbmV3LiAmbmJzcDvigI5TdGlsbCBkb24n dCBsaWtlIHRoZSBuYW1lLCBhbmQgc3RpbGwgaGF2ZSB0cm91YmxlIHNlZWluZyB0aGUgdmFsdWUu PC9kaXY+PC9kaXY+PC9ibG9ja3F1b3RlPjxkaXY+PGJyPjwvZGl2PjxkaXY+VlJGcyBwcm92aWRl IGRldGVybWluaXN0aWMgcHJlY29tbWl0bWVudHMgeW91IGNhbiByZXZlYWwgYXQgYSBsYXRlciB0 aW1lLiBUaGlzIGlzIHVzZWZ1bCBpZiB5b3Ugd2FudCB0byBtYWludGFpbiBhIDE6MSBtYXBwaW5n IG9mIGxvdyBlbnRyb3B5IGlucHV0cyAoZS5nLiBuYW1lcywgZW1haWwgYWRkcmVzc2VzLCBwaG9u ZSBudW1iZXJzKSB0byBzb21lIHJhbmRvbSB2YWx1ZXMgeW91IGNhbiBjb21taXQgdG8gaW4gYWR2 YW5jZSwgZS5nLiB0aHJvdWdoIGEgdGltZXN0YW1waW5nIHNlcnZpY2UvdHJhbnNwYXJlbmN5IGxv Zy48L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2PlVzaW5nIGEgVlJGIG1lYW5zIHlvdSBjYW4gbWFr ZSB0aGVzZSByYW5kb20gb3V0cHV0cyBlZmZlY3RpdmVseSBwdWJsaWMgd2l0aG91dCB0aGVtIGJl aW5nIHN1YmplY3QgdG8gYSBwcmVpbWFnZSBhdHRhY2sgKHNvIGxvbmcgYXMgdGhlIFZSRiBwcml2 YXRlIGtleSBpcyBub3QgbGVha2VkKS4gVGhpcyB3YXkgYSBrZXkgdHJhbnNwYXJlbmN5IHNlcnZl ciBjYW4gcHJvdmUgYSBnaXZlbiB1c2VyJ3Mga2V5cyB3ZXJlIGluY2x1ZGVkIGluIGEgdHJhbnNw YXJlbmN5IGxvZyB3aXRob3V0IGVuYWJsaW5nIHNwYW1tZXJzIHRvIG9idGFpbiBhbGwgb2YgdGhl IG5hbWVzIGluIHRoZSBkaXJlY3RvcnkuPC9kaXY+PGRpdj48YnI+PC9kaXY+PC9kaXY+LS0gPGJy PjxkaXYgY2xhc3M9ImdtYWlsX3NpZ25hdHVyZSIgZGF0YS1zbWFydG1haWw9ImdtYWlsX3NpZ25h dHVyZSI+VG9ueSBBcmNpZXJpPGJyPjwvZGl2Pg0KPC9kaXY+PC9kaXY+DQo8L2Rpdj48L2Jsb2Nr cXVvdGU+PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PGRpdj48c3Bhbj5fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzwvc3Bhbj48YnI+PHNwYW4+Q2ZyZyBtYWls aW5nIGxpc3Q8L3NwYW4+PGJyPjxzcGFuPjxhIGhyZWY9Im1haWx0bzpDZnJnQGlydGYub3JnIj5D ZnJnQGlydGYub3JnPC9hPjwvc3Bhbj48YnI+PHNwYW4+PGEgaHJlZj0iaHR0cHM6Ly93d3cuaXJ0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jZnJnIj5odHRwczovL3d3dy5pcnRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL2Nmcmc8L2E+PC9zcGFuPjxicj48L2Rpdj48L2Jsb2NrcXVvdGU+PC9ib2R5Pjwv aHRtbD4= --Apple-Mail-076A17C2-D9F3-4AF2-A400-4213207B7FF3-- --Apple-Mail-A25145B9-9C9B-4A83-986C-FAF07A1A5B34 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINeDCCA4Mw ggJroAMCAQICAQEwDQYJKoZIhvcNAQEFBQAwVDELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBM aW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsTA1BLSTEWMBQGA1UEAxMNTUlUTEwgUm9vdCBDQTAe Fw0wODA5MjMxMjAwMDBaFw0yOTEyMzEyMzU5NTlaMFQxCzAJBgNVBAYTAlVTMR8wHQYDVQQKExZN SVQgTGluY29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxFjAUBgNVBAMTDU1JVExMIFJvb3Qg Q0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDFTikXWLImsvmtir9cEAqD3eQJMBMb sHDQ0YWkQnUDdeyvpQgir3/VUkE6ALAOqtWwArWVHDL+WSsfM+ShuIyvXDONDbxJH/2yDmQByasy oFhtzfTaq3AIYpnF012ECHadQ4I7XQAylSwI12mKQ9j26RPyWwD56iszhDWtz8vQnoAdGm05Tsi4 MF1mP6101vuC/4YqSevrCP2baxUZrChobsACqGxa9BQz+riH8fkWliXCdUASHYDOGqIb1vCXq4kk jMn/y5RaV02RXDPUjl9H+8JrGItchbihTJ0G5EpMb56QSjEca4PvfLHkm2xJyJLwdAvagQzy2/5U AL5qVuqDAgMBAAGjYDBeMA8GA1UdEwEB/wQFMAMBAf8wHQYDVR0OBBYEFGeqes/0Cqa5crWKoNKd 8hDDQ+0pMB8GA1UdIwQYMBaAFGeqes/0Cqa5crWKoNKd8hDDQ+0pMAsGA1UdDwQEAwIBhjANBgkq hkiG9w0BAQUFAAOCAQEAPhttBWDQeHjYSlhfj8k+Q1Lc5QARZH9iDNlRjVAaL2tBnil9yNTX9Nqg 1Pxjth/RE75702Ib34EOFAf+RCJk5Cj2u/01RvzEO0oJgJp3vMRC1Wxixa68rZcvD8mLWbZ4G+g4 HhFL/ksBZ83Cztb4Na3ZrLN5MLKstKvHtlWAGPM06bRM8iRt+ml3CDG6jsVkvy2z4zbj3YCXzt3d Vqx69RLWmmtEES6kKGY9O3WGO1qORA6lPgFADM/WVURitbOW/47+Vs/2K6MqlhZx9ipDcUZ/ftgK +4N656zjGb6eqbKto2w14jwaHdcMjCp/MecuHLhjzRXKo38mPx1/dIr0ADCCBLwwggOkoAMCAQIC ASkwDQYJKoZIhvcNAQEFBQAwVDELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExh Ym9yYXRvcnkxDDAKBgNVBAsTA1BLSTEWMBQGA1UEAxMNTUlUTEwgUm9vdCBDQTAeFw0xMzEyMTcw MDAwMDBaFw0yMDEyMzEyMzU5NTlaMFExCzAJBgNVBAYTAlVTMR8wHQYDVQQKExZNSVQgTGluY29s biBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxEzARBgNVBAMTCk1JVExMIENBLTMwggEiMA0GCSqG SIb3DQEBAQUAA4IBDwAwggEKAoIBAQDaMFJ1bXy25bW03EbqHwHSSpyQVlAAC2gcKS9SlQRfqMW8 F3yZAjncbIthG4CjgdYml7v+LMVc59IkOzpQzmi+8I59eDZsmANiUEL0kNwsEUifSemk671G+mNZ KLG0LnpyvAnlSzlA923G0p16TksleXagrDfDyWKFSLF49vFZp3WbtkwopqC+b3NPJs/oW6YpHF5g mNKkHb5wBiOgYYRtJUfLHy7MebrECgEwfFrxvL7IPPwnOTqw/2KKWA/eJdIagICaHIHO+VBDlA01 Y/4Saj2PP+6QqFhUH9XB3G2iq48CqfiJ8MAhoz121vTlzLWBcAVI/dn+JSTHIFllQ5F/AgMBAAGj ggGaMIIBljASBgNVHRMBAf8ECDAGAQH/AgEAMB0GA1UdDgQWBBTXYGYOe0mNdUwN/c9G3sjHEofK vzAfBgNVHSMEGDAWgBRnqnrP9AqmuXK1iqDSnfIQw0PtKTAOBgNVHQ8BAf8EBAMCAYYwZgYIKwYB BQUHAQEEWjBYMC0GCCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8/TExSQ0Ew JwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLmxsLm1pdC5lZHUvb2NzcDAzBgNVHR8ELDAqMCigJqAk hiJodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0Y3JsP0xMUkNBMIGSBgNVHSAEgYowgYcwDQYLKoZI hvcSAgEDAQYwDQYLKoZIhvcSAgEDAQgwDQYLKoZIhvcSAgEDAQcwDQYLKoZIhvcSAgEDAQkwDQYL KoZIhvcSAgEDAQowDQYLKoZIhvcSAgEDAQswDQYLKoZIhvcSAgEDAQ4wDQYLKoZIhvcSAgEDAQ8w DQYLKoZIhvcSAgEDARAwDQYJKoZIhvcNAQEFBQADggEBACx/0cGfvapTtROCTFquMBzuLKeFwMSB bB7Ngq139IsZJDQOG3MhX8tMLGpQuM534f4dOowlcHz6cefOHKpDjdGycZk4VPlF/M+H3h1v9kne qXbjgPCUkjvJcEDYORlwQSA5YL1sdysSXNTo2eKBqFJbmh1UmuGYf9eFABwxLvsTkfrbLLErVY8+ BwGKkZWe7XFIdtOId7sOp9ZDa1UwtR/bddiEi5r3iQmxB3iNKHvU1UPR7sXiycCipAwj3wzMNh4s 6SOXMpGzvuv9oyw8ArHqcxo69EvsLLQ+OnnWLaoWRsaZfyh+eHaR6uNNO9En+DbavUxXxFHU+S2M yw06w98wggUtMIIEFaADAgECAgoadMQgAAAAAK0DMA0GCSqGSIb3DQEBCwUAMFExCzAJBgNVBAYT AlVTMR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxEzARBgNV BAMTCk1JVExMIENBLTMwHhcNMTcwMzAxMTgyNTA2WhcNMjAxMjMxMjM1OTU5WjBsMQswCQYDVQQG EwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEPMA0GA1UECxMGUGVvcGxlMSsw KQYDVQQDEyJCbHVtZW50aGFsLlVyaS41MDAxMDU4NCAoTW9iaWxpdHkpMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAg+8bBB+jySfGyqx/fL9a596qTeq9fGfYXI2yJEZqLzJazzV1u6oL ToMnJQ6phCIkQGplPsM+9PpzIcw5nN8GahHPU6FXXT3BSr6/bny4hftGu05y/n/DWWlPkos6PhSN AB8WG3L+6a3mHcp9yYumPkdtM20+08oiU9S6OhFr6BoFFoeFjKEcFhvvovm9GcRzQ3g1cXHore5p 6umBCLGxZi0cGhBI/7ZyJmJUUo50bAPKdpURqYSsgU7p6GxCgpIcZBUlTxCSliPO/0TqiBMZ857M F4OcehpG7LuxufD0p+g02uX7Z0aIfYnGHlkm3Y7NgvF6lW2WxCPklqKakb2fuwIDAQABo4IB6jCC AeYwHQYDVR0OBBYEFPbiFDP71vJBmRLhxtKU/CWESr+tMA4GA1UdDwEB/wQEAwIGwDAfBgNVHSME GDAWgBTXYGYOe0mNdUwN/c9G3sjHEofKvzAzBgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLmxs Lm1pdC5lZHUvZ2V0Y3JsL0xMQ0EzMGYGCCsGAQUFBwEBBFowWDAtBggrBgEFBQcwAoYhaHR0cDov L2NybC5sbC5taXQuZWR1L2dldHRvL0xMQ0EzMCcGCCsGAQUFBzABhhtodHRwOi8vb2NzcC5sbC5t aXQuZWR1L29jc3AwPQYJKwYBBAGCNxUHBDAwLgYmKwYBBAGCNxUIg4PlHYfsp2aGrYcVg+rwRYW2 oR8dhYHgQIbXxk0CAWQCAQkwLAYDVR0lAQH/BCIwIAYIKwYBBQUHAwQGCisGAQQBgjcKAwwGCCsG AQUFBwMCMBgGA1UdIAQRMA8wDQYLKoZIhvcSAgEDAQgwQQYDVR0RBDowOIEOdXJpQGxsLm1pdC5l ZHWgJgYKKwYBBAGCNxQCA6AYDBZVUjIwOTgwQG1pdGxsLmFkLmxvY2FsMC0GCSsGAQQBgjcUAgQg Hh4ATABMAE0AbwBiAGkAbABlAFMAaQBnAEEAdQB0AGgwDQYJKoZIhvcNAQELBQADggEBADbiZo1D kfqhBA4LYklB+i49k6dh7L+nDEg3WdeZ/CRZAon9G3hPsUWd5YIsufRpoYUVJABcVos87kXZmkF1 RjH8vLNFOEV8ZVcNxbWC5DiA6dTswIEhXMSHFuyp3tERvu2z6+f9FC4jvZttYyLyirBJC4KwP/AO Lm42Gn4lLeNrY4Ex8nq2Ah3xjB+QqvpxD2k1aaoR0fWaDxv2ZrdaFR43x2MTkiee+wR1diZ7GA7G /HyJg9MUukKq23qm6Ys0VJQcJsKU1Q2/TLL99FRRa18ourBvFwJzcllLhTcqnvbawWt6cYEvGIJ9 Dszxz7LQECXI0KrPpM7x32SulMJjt1YxggLJMIICxQIBATBfMFExCzAJBgNVBAYTAlVTMR8wHQYD VQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxEzARBgNVBAMTCk1JVExM IENBLTMCChp0xCAAAAAArQMwCQYFKw4DAhoFAKCCAT8wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEH ATAcBgkqhkiG9w0BCQUxDxcNMTcwNzIzMDIyNTUzWjAjBgkqhkiG9w0BCQQxFgQULMvtbKNQvoEs RfmDVLbS1Bk3dI4wbgYJKwYBBAGCNxAEMWEwXzBRMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlU IExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBDQS0zAgoa dMQgAAAAAK0DMHAGCyqGSIb3DQEJEAILMWGgXzBRMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlU IExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBDQS0zAgoa dMQgAAAAAK0DMA0GCSqGSIb3DQEBAQUABIIBAFOrQ3CxkMos9JoPPR6HVL0d7TOPa71Y0Rv9Zf/R 8Up+Genc8YiFI6HkhIrMPe1iVjwQ2KAWPpcjENNdm2hB+Mh7WHDEFWCVPr67yqoPO2LL9BIw9Hlt bb4bdQqdBv7q7T4YkNB8SerIK1CIYF3BWOfMBFvl/AitSkP6Fnn5vJ9DWV/A85Ph+EwzpGb6rPd+ KiQ1wbaOQbdZsPiTqphAU9Kb0kP5xMpEMf9ZC6N2anNTyEqoOk5zLuaPBIRAkOMv68/0oHvK+sUH TaiXXYX07/QVXyyRWxIyoQdsdpnu5SoLC8o5sli6LQ/JzCo+dHo+YbZO3B+65onv6VQhZUJVOY4A AAAAAAA= --Apple-Mail-A25145B9-9C9B-4A83-986C-FAF07A1A5B34-- From nobody Sat Jul 22 22:11:25 2017 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 20E52127B73 for ; Sat, 22 Jul 2017 22:11:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 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_BLOCKED=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 zuxxYiHAQr1S for ; Sat, 22 Jul 2017 22:11:21 -0700 (PDT) Received: from mail-it0-x234.google.com (mail-it0-x234.google.com [IPv6:2607:f8b0:4001:c0b::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 6822E1201F2 for ; Sat, 22 Jul 2017 22:11:21 -0700 (PDT) Received: by mail-it0-x234.google.com with SMTP id v205so6783371itf.1 for ; Sat, 22 Jul 2017 22:11:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=rduRgvu4H1BNBRfLEkk7f2Jz2cc0Q0PApjzVm4jfQiw=; b=jEOltisDFAarvGjAkF3/vQ9MgLuiEHsCs+Ip5O78EruEVG5bjosWb5+3zZUR0QFfHM JHZot05+HurHc+RpydA0k4xACKJVyW+FVI4oU8+U2SQ6dfyJ7GkOcu9EINoVmJHyaQT6 FcHdZhXp0FVi8XSmiNdDgE6ojrYocIH7Nar5Bce6xubPTDRRKS4cAppx619CiXI9kgjQ cXsNEy0FtQRP/z83zwXsx9nz5xkruMSoxMr3rxsFAJ4o3NggEiVnjdA559zpObkkrXNj LRs6CzKaRTLg1pcqUytss+ZrYfx4orJ7yBymcmIjB/smIZ8I7Gkm02TiPz/bxPtferJL c+2g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=rduRgvu4H1BNBRfLEkk7f2Jz2cc0Q0PApjzVm4jfQiw=; b=DrrXIZE8LYy4Jv+7pyk7orzE4+lA0j3CcJHHnZFJY5+XLWImXknsE+8jnozeU4aMZ+ sk6sYk5mfuHrCUIaRV0VR3K8DowAyYDfetqJF817rSOJxCQMSjRQUAdkVuafgucgpIgw 4EDskV1deiDPAoD2PEBzRfre5aDAGS7WIwKu13T3TgppJTZrh5t578y5kKlvzPdW+ZrP sTQb59m8BMFOoT2VOFUQdjfi6zBwltSAsnigEGBiwoe92Al6eiVRKXJ9ZmYSNRQrkBQl ztLkFfQqIoKaHqrpFVzCYmwTS1PGLaQ8sxMGym7SsIU94joTc70/YCaXdxQ9TIsiYdL3 B8EA== X-Gm-Message-State: AIVw113jAKdeTAZSpm1bEi+b9MljNoHXHeT8g30qpHCPRREzpQV2Q/eT Yolg/5x0Sa0J+X6rQP3oxCPQs+jfigBn X-Received: by 10.36.103.65 with SMTP id u62mr3572624itc.27.1500786680626; Sat, 22 Jul 2017 22:11:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.39.83 with HTTP; Sat, 22 Jul 2017 22:10:40 -0700 (PDT) In-Reply-To: <20170721163204.8573013.1016.15939@blackberry.com> References: <810C31990B57ED40B2062BA10D43FBF501B63B22@XMB116CNC.rim.net> <20170721163204.8573013.1016.15939@blackberry.com> From: Sharon Goldberg Date: Sun, 23 Jul 2017 08:10:40 +0300 Message-ID: To: Dan Brown Cc: "cfrg@irtf.org" , "jan@ns1.com" , Leonid Reyzin , Dimitrios Papadopoulos Content-Type: multipart/alternative; boundary="001a114ac81cfb80fa0554f520d4" Archived-At: Subject: Re: [Cfrg] draft-goldbe-vrf: Verifiable Random Functions X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Jul 2017 05:11:24 -0000 --001a114ac81cfb80fa0554f520d4 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Dan, Thank you for your comments. Indeed, VRFs have been around since 1999. They are really "verifiable PRFs" but the name is by now standard in the crypto literature, and changing it will cause more confusion than keeping it. In terms of the VRF's security properties, there are three: uniqueness, collision resistance, and pseudorandomness. These are defined in our draft = ( https://tools.ietf.org/html/draft-goldbe-vrf-01#section-3). How VRFs prevent dictionary attacks: a public hash is subject to a dictionary attack because, given the output, an adversary can evaluate the hash on different inputs and see what hits the outputs. In a VRF, the adversary can't evaluate the hash on different inputs. You say it's not surprising that "random oracle model proof can prove the output of a hash to be random". But actually, the output of a hash is NOT random if the input and the hash function are known. This is because the output of a hash is deterministic (every input maps to a unique output). That's exactly what enables dictionary attacks. This is in contrast to a VRF, where the output is (pseudo)random even given knowledge of the input. Only once the VRF proof is given, does the VRF output stop looking random. Note that random oracles are not essential for VRFs, and non-random-oracles constructions exist (but are less efficient than what we propose to standardize). As far as use cases, here are a few: In the NSEC5 use case for DNSSEC, you have sensitive data (domain names) and you sign consecutive pairs of hashes of domain names in order to be able to prove absence of a name. If you just use standard hashing, whenever signed hash values are disclosed, your sensitive data is subject to dictionary attacks. VRFs solve that problem, and sensitive names don't have to be disclosed at all. More details are in https://eprint.iacr.org/201 7/099.pdf In CONIKS (also Google Key Transparency, Signal secure messaging, Yahoo! Coname) you also have some sensitive data (user names) that are put into a Merkle-like authenticated data structure. If you just use standard hashing, whenever hash values are disclosed, sensitive data is subject to dictionary attacks. If you use VRFs, sensitive data again can be disclosed only on an as-needed basis. More details are in https://eprint.iacr.org/2014/1004.pdf= . In a cryptocurrency use case, you wish perform a coin flip that is deterministic and provably correct, but cannot be done by just anyone. More details are in https://people.csail.mit.ed u/nickolai/papers/gilad-algorand-eprint.pdf and possibly other cryptocurrency papers. Bryan Ford mentioned an additional usecase at the mic on Tuesday: distributed password protection protocols Many of these use case are already putting VRFs into production use (esp. the CONIKS one). You can see a list of the various implementations we have found in the "implementation status" section of our draft. One of the reasons we think this spec is so important is that we found flaws in several of the implementations that can be used to trivially break uniqueness. (See eg: https://github.com/google/keytransparency/issues/567) Thanks, Sharon On Fri, Jul 21, 2017 at 7:32 PM, Dan Brown wrote= : > Answering myself below: VRFs have been around since 1999, so are not so > new. =E2=80=8EStill don't like the name, and still have trouble seeing t= he value. > > *From: *Dan Brown > *Sent: *Tuesday, July 18, 2017 2:29 PM > *To: *Sharon Goldberg; cfrg@irtf.org > *Cc: *jan@ns1.com; Leonid Reyzin; Dimitrios Papadopoulos > *Subject: *Re: [Cfrg] draft-goldbe-vrf: Verifiable Random Functions > > Hi Sharon and CFRG, > > > > On VRFs, my uncertain comments to consider at your leisure: > > > > Is it fair to say VRFs are relatively new? If so, then maybe a little > more caution is needed about their use. It seems a tad hasty that it is > being used already. > > > > To me, it seems that VRFs are basically signatures, with an extra > feature. My concern is that this extra feature might get overused, befor= e > it is thoroughly reviewed. > > > > It is unsurprising to me that random oracle model proof can prove the > output of a hash to be random. My intuitive concern is that at least > informally, this is kind of circular. Hashes often have some > non-random-ish properties that might affect the extra security (over > signatures) that VRFs are aiming for. I guess I would much prefer a proo= f > saying if the hash has (well-studied) properties XYZ, then your > construction are VRFs. (Maybe you have this already? If so, then tell m= e > so.) > > > > Since, VRFs require sending the =E2=80=9Cproofs=E2=80=9D on the wire, I f= ind it hard to > see how it could be used to prevent dictionary attacks. I assume that yo= u > are saying the proofs must be encrypted when one needs to avoid dictionar= y > models? I suppose all the details are there in I-D and papers, but for > now, I am confused about the threat model (which parties have keys, etc., > if they require a secure channel and mutual trust, why just use plain old > hash,=E2=80=A6). To resist dictionary attacks, were already have PAKEs an= d > PBHashing. Now this? > > > > Finally, on a bikeshed-coloring note, I object to the name =E2=80=9Cverif= iable > random function=E2=80=9D, on several grounds. > > > > 1. It is not a function. It is at least four functions, keygen, sign, > verify, and hashify. > 2. If you make it into a keyed function F_sk(m), as in > prooftohash(sign_sk(m)), it is not verifiable. > 3. Verification requires the intermediate proof, which is certainly > not even pseudorandom (it is easy to distinguish valid signatures from > random). > 4. It is pseudorandom, not random. (The keys are random, but many > crypto has keys, without having =E2=80=9Crandom=E2=80=9D in its name: = encryption, MAC, > signatures, key exchange, =E2=80=A6, they also don=E2=80=99t verifiabl= e or random in their > names either.) > 5. The similar phrase =E2=80=9Cverifiably random=E2=80=9D, albeit as a= misnomer, has > past precedents, see NIST P-256 and Brainpool, etc. When I see VRF, I > think a function, that aims to VR in that sense, and great, now we can > improve on Brainpool, etc. > 6. =E2=80=9CRandom function=E2=80=9D should be reserved for the ideal = random mapping > concept, for example, as studied by Flajolet-Odlyzko (ok they only stu= died > the case of equal size domain and range). The random oracle model, is= the > idea of approximating this ideal, etc. An actual approximation should= not > be name as the ideal (sorry, I=E2=80=99m kind of repeating my point 4)= . > > > > Please forgive the fact that my comments above are not very constructive > (or if the tone is wrong). This is a new topic for me, so I am reluctant > too many suggestions. Nonetheless, I suggest (0) waiting a little, (1) a > non-random-oracle security proof (if you don=E2=80=99t have it yet), (2) = re-naming > the scheme to something like re-hashable (or digestible) signatures (and > re-name the various parts, i.e. proof -> signature, etc.). > > > > Best regards, > > > > Dan > > > > > > *From:* Cfrg [mailto:cfrg-bounces@irtf.org] *On Behalf Of *Sharon Goldber= g > *Sent:* Wednesday, July 12, 2017 5:42 AM > *To:* cfrg@irtf.org > *Cc:* jan@ns1.com; Dimitrios Papadopoulos ; Leonid > Reyzin > *Subject:* [Cfrg] draft-goldbe-vrf: Verifiable Random Functions > > > > Dear CFRG, > > I'm presenting at next week's meeting on Verifiable Random Functions. A > VRF is the public-key version of keyed cryptographic hash. Only the holde= r > of the VRF secret key can compute the hash, but anyone with the public ke= y > can verify it. VRFs can be used to prevent dictionary attacks on > hash-based data structures, and have applications to key transparency > (CONIKS), DNSSEC (NSEC5), and cryptocurrencies (Algorand). > > In advance of the meeting, please see: > > 1) Our substantially updated -01 draft: > https://datatracker.ietf.org/doc/draft-goldbe-vrf/ > > 2) Our project page, with links to various VRF implementations: > https://www.cs.bu.edu/~goldbe/projects/vrf > > Comments welcome. Thanks, > > Sharon > > -- > Sharon Goldberg > Computer Science, Boston University > http://www.cs.bu.edu/~goldbe > --=20 --- Sharon Goldberg Computer Science, Boston University http://www.cs.bu.edu/~goldbe --001a114ac81cfb80fa0554f520d4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Dan,

Thank you for = your comments. Indeed, VRFs have been around since 1999. They are really &q= uot;verifiable PRFs" but the name is by now standard in the crypto lit= erature, and changing it will cause more confusion than keeping it.


=
How VRFs prevent dictionary attacks: a publ= ic hash is subject to a dictionary attack because, given the output, an adv= ersary can evaluate the hash on different inputs and see what hits the outp= uts. In a VRF, the adversary can't evaluate the hash on different input= s.=C2=A0

You say it's not surprising that "random oracle model= proof can prove the output of a hash to be random". But actually, the= output of a hash is NOT random if the input and the hash function are know= n. This is because the output of a hash is deterministic (every input maps = to a unique output). That's exactly what enables dictionary attacks. Th= is is in contrast to a VRF, where the output is (pseudo)random even given k= nowledge of the input. Only once the VRF proof is given, does the VRF outpu= t stop looking random. Note that random oracles are not essential for VRFs,= and non-random-oracles constructions exist (but are less efficient than wh= at we propose to standardize).

As far as use cases, here are a few:=C2= =A0

In the NSEC5 use case for DNSSEC, you have sensitive data (domain n= ames) and you sign consecutive pairs of hashes of domain names in order to = be able to prove absence of a name. If you just use standard hashing, whene= ver signed hash values are disclosed, your sensitive data is subject to dic= tionary attacks. VRFs solve that problem, and sensitive names don't hav= e to be disclosed at all. More details are in=C2=A0https://eprint.iacr.org/201= 7/099.pdf

In CONIKS (also Google Key Transparency, Signal secure me= ssaging, Yahoo! Coname) you also have some sensitive data (user names) that= are put into a Merkle-like authenticated data structure. If you just use s= tandard hashing, whenever hash values are disclosed, sensitive data is subj= ect to dictionary attacks. If you use VRFs, sensitive data again can be dis= closed only on an as-needed basis. More details are in =C2=A0https://eprint.iacr.o= rg/2014/1004.pdf.

<= div style=3D"font-size:12.8px">In a cryptocurrency use case, you wish perfo= rm a coin flip that is deterministic and provably correct, but cannot be do= ne by just anyone.=C2=A0 More details are in=C2=A0https://people.csail.mit.edu/nickolai/papers/gilad-algorand-epri= nt.pdf=C2=A0and possibly other cryptocurrency papers.

Bryan Ford = mentioned an additional usecase at the mic on Tuesday: distributed password= protection protocols

Many of these use case are already putting VRFs i= nto production use (esp. the CONIKS one).=C2=A0 You can see a list of the v= arious implementations we have found in the "implementation status&quo= t; section of our draft.=C2=A0 One of the reasons we think this spec is so = important is that we found flaws in several of the implementations that can= be used to trivially break uniqueness. =C2=A0(See eg:=C2=A0https:/= /github.com/google/keytransparency/issues/567)

Thanks,
S= haron=C2=A0

= On Fri, Jul 21, 2017 at 7:32 PM, Dan Brown <danibrown@blackberry.co= m> wrote:
Answering myself below: VRFs have been around since 1999, so are not so new= . =C2=A0=E2=80=8EStill don't like the name, and still have trouble seei= ng the value.

From: Dan Brown
Sent: Tuesday, July 18, 2017 2:29 PM
To: Sharon Goldberg; cfrg@irtf.org
Cc: jan@ns1.co= m; Leonid Reyzin; Dimitrios Papadopoulos
Subject: Re: [Cfrg] draft-goldbe-vrf: Verifiable Random Functio= ns

Hi Sharon and CFRG,

=C2=A0

On VRFs, my uncertain comments to consider at your leisure:

=C2=A0

Is it fair to say VRFs are relatively new?=C2=A0 If so, then mayb= e a little more caution is needed about their use.=C2=A0 It seems a tad has= ty that it is being used already.

=C2=A0

To me, it seems that VRFs are basically signatures, with an extra= feature.=C2=A0 My concern is that this extra feature might get overused, b= efore it is thoroughly reviewed.=C2=A0

=C2=A0

It is unsurprising to me that random oracle model proof can prove= the output of a hash to be random.=C2=A0 My intuitive concern is that at l= east informally, this is kind of circular.=C2=A0 Hashes often have some non-random-ish properties that might affect the ext= ra security (over signatures) that VRFs are aiming for.=C2=A0 I guess I wou= ld much prefer a proof saying if the hash has (well-studied) properties XYZ= , then your construction are VRFs.=C2=A0 (Maybe you have this already?=C2=A0 If so, then tell me so.)

=C2=A0

Since, VRFs require sending the =E2=80=9Cproofs=E2=80=9D on the w= ire, I find it hard to see how it could be used to prevent dictionary attac= ks.=C2=A0 I assume that you are saying the proofs must be encrypted when one needs to avoid dictionary models?=C2=A0 I suppose al= l the details are there in I-D and papers, but for now, I am confused about= the threat model (which parties have keys, etc., if they require a secure = channel and mutual trust, why just use plain old hash,=E2=80=A6). To resist dictionary attacks, were already have= PAKEs and PBHashing.=C2=A0 Now this?

=C2=A0

Finally, on a bikeshed-coloring note, I object to the name =E2=80= =9Cverifiable random function=E2=80=9D, on several grounds.

=C2=A0

  1. It is not a function.=C2=A0 It is at least four functions,= keygen, sign, verify, and hashify.
  2. If you make= it into a keyed function F_sk(m), as in prooftohash(sign_sk(m)), it is not= verifiable.=C2=A0
  3. Verification requires the intermediate proof, = which is certainly not even pseudorandom (it is easy to distinguish valid s= ignatures from random).
  4. It is pseudorandom, not= random.=C2=A0 (The keys are random, but many crypto has keys, without havi= ng =E2=80=9Crandom=E2=80=9D in its name: encryption, MAC, signatures, key exchange, =E2=80=A6, they also don=E2=80=99t verifiable or random in t= heir names either.)
  5. The similar phrase =E2=80= =9Cverifiably random=E2=80=9D, albeit as a misnomer, has past precedents, s= ee NIST P-256 and Brainpool, etc.=C2=A0 When I see VRF, I think a function, that aims to VR in that sense, and great, now we can improve o= n Brainpool, etc.
  6. =E2=80=9CRandom function=E2= =80=9D should be reserved for the ideal random mapping concept, for example= , as studied by Flajolet-Odlyzko (ok they only studied the case of equal size domain and range).=C2=A0 The random oracle model, i= s the idea of approximating this ideal, etc.=C2=A0 An actual approximation = should not be name as the ideal (sorry, I=E2=80=99m kind of repeating my po= int 4).

=C2=A0

Please forgive the fact that my comments above are not very const= ructive (or if the tone is wrong).=C2=A0 This is a new topic for me, so I a= m reluctant too many suggestions.=C2=A0 Nonetheless, I suggest (0) waiting a little, (1) a non-random-oracle security proof (if= you don=E2=80=99t have it yet), (2) re-naming the scheme to something like= re-hashable (or digestible) signatures (and re-name the various parts, i.e= . proof -> signature, etc.).

=C2=A0

Best regards,

=C2=A0

Dan

=C2=A0

=C2=A0

From: Cfrg [mailto:cfrg-bounces@irtf.org] On Behalf Of Sharon Goldberg
Sent: Wednesday, July 12, 2017 5:42 AM
To: cfrg@irtf.org=
Cc: jan@ns1.com= ; Dimitrios Papadopoulos <dipapado@umd.edu>; Leonid Reyzin <reyzin@cs.bu.edu>
Subject: [Cfrg] draft-goldbe-vrf: Verifiable Random Functions=

=C2=A0

Dear CFRG,

I'm presenting at next week's meeting on Verifiable Random Function= s. A VRF is the public-key version of keyed cryptographic hash. Only the ho= lder of the VRF secret key can compute the hash, but anyone with the public= key can verify it.=C2=A0 VRFs can be used to prevent dictionary attacks on hash-based data structures, and have applica= tions to key transparency (CONIKS), DNSSEC (NSEC5), and cryptocurrencies (A= lgorand).

In advance of the meeting, please see:

1) Our substantially updated -01 draft:
https://datatracker.ietf.org/doc/draft-goldbe-vrf/

2) Our project page, with links to various VRF implementations:
ht= tps://www.cs.bu.edu/~goldbe/projects/vrf

Comments welcome.=C2=A0 Thanks,

Sharon

--
Sharon Goldberg
Computer Science, Boston University
http://www.cs.bu= .edu/~goldbe




--
---
Sharon Goldberg
Compute= r Science, Boston University
http://www.cs.bu.edu/~goldbe
--001a114ac81cfb80fa0554f520d4-- From nobody Mon Jul 24 07:40:02 2017 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 B9F93131D33; Mon, 24 Jul 2017 07:40:00 -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=unavailable 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 FIQmhEUEg2sK; Mon, 24 Jul 2017 07:39:58 -0700 (PDT) Received: from mail-wm0-x22f.google.com (mail-wm0-x22f.google.com [IPv6:2a00:1450:400c:c09::22f]) (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 89870131D2F; Mon, 24 Jul 2017 07:39:57 -0700 (PDT) Received: by mail-wm0-x22f.google.com with SMTP id l81so19862035wmg.1; Mon, 24 Jul 2017 07:39:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=u+ytpkHk9XsNWoM4OjOkreWEj35F9nOKZqM9ZbfQdCM=; b=WNSPtmUl9Hl+InM5jVw57dG4O+oy7dVTKJ3yanNQJPKhd4taPxFu+jq1WtZmeEvOyv YLdLlKDcFkpF9phylGtyXJBLvcsSPrJOQadHc9cY6P+zjiwr1yk0rS2GAajnMSxM/+Tn PGJgB0ygv1wGOhQGeh1pKrcefHZBGCWO5S2PdnBOWknfpz3j1vZOsivw1Q3or8pQoLvX 5Yy+KS5Y44WcWGU+5aE5HRkokTFtt+lzdEPP3/4snZgVB7bbS9PTpNjEKfEHbjNG6RlK yyvBwk0i9MaVdo2/xL7RFfvnMFnEez6ttON/gAQ8wI/V19/mIsdxLsp4if4lFdlz0rTA uGrw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=u+ytpkHk9XsNWoM4OjOkreWEj35F9nOKZqM9ZbfQdCM=; b=UNDkJ8OWc7ZXfkU9IzkTqiJ+zV4vWfOGj1Zwy4hjQFQoVUY3+n0KTufEj70xLuy8BX sMHLN/437Y9x/EuPs2hoiOF4SXFMVSs88iKrirM2kYBjLpOgAjePozzw3hCEUIcDJjeu X6i762E5qDt6cFBDiUjQ/oiFjECp9uJU0lyhD6HniBLNaKE8bXJdlu+dOkidiCWboP3X vdwFXBPt9Ew/jAStFyCG+IShAhQzNpvxJRtapukL6DeAlK761YLp9XB9I/DL2pbelJe8 qA4skDi99JVvYt3BwexAodk9DZrtDAlhnxhz3yxA0MUylGNtF6LwWN/KfjEvdtay+d/r j06g== X-Gm-Message-State: AIVw110F/RUN1FSLXO8gGHvk4Z6jWfFDyQplXaoYatbPkOE3y+bYXK3N PDWah6bYsDnuIccTAFdD5QK+P151lA== X-Received: by 10.80.215.7 with SMTP id t7mr15622561edi.19.1500907195956; Mon, 24 Jul 2017 07:39:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.80.138.69 with HTTP; Mon, 24 Jul 2017 07:39:55 -0700 (PDT) In-Reply-To: <4699f3d2-40ce-9c40-d29a-d24ecb3b6cab@huelsing.net> References: <9a878527-5ab9-5429-7c5d-4f7e4ca4e8db@isode.com> <08944dc3-9086-ed47-cc1b-54248b3dac70@cs.tcd.ie> <9e6b6146-e376-86cb-70be-0127a3e72d16@cs.tcd.ie> <6f90e485-01f4-5ad8-49ef-e51c52e01a46@cs.tcd.ie> <5e328e85-a8a1-67f1-3853-418309b04a17@huelsing.net> <27cc7000-7fd5-27dd-b8b5-9b9518a9f3ad@huelsing.net> <1785b9ed-fb53-889a-9d34-311c7ea5c762@cs.tcd.ie> <4699f3d2-40ce-9c40-d29a-d24ecb3b6cab@huelsing.net> From: Allison Mankin Date: Mon, 24 Jul 2017 16:39:55 +0200 Message-ID: To: "A. Huelsing" Cc: Stephen Farrell , "Paterson, Kenny" , Alexey Melnikov , "irsg@irtf.org" , "cfrg@irtf.org" , "draft-irtf-cfrg-xmss-hash-based-signatures@ietf.org" Content-Type: multipart/alternative; boundary="f403045dbe944186ed0555113061" Archived-At: Subject: Re: [Cfrg] [irsg] IRSG review of draft-irtf-cfrg-xmss-hash-based-signatures-08 X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jul 2017 14:40:01 -0000 --f403045dbe944186ed0555113061 Content-Type: text/plain; charset="UTF-8" Thanks for making the changes. Stephen, let me know if you are ready to give this a thumbs-up, and I'll start an IRSG poll. Allison On 24 July 2017 at 16:30, A. Huelsing wrote: > Dear Stephen, > > we tried to make the required changes. Please have a look if you are fine > with the changes (especially regarding section 5 and the reference > implementation). > > You find our answers to your review below and the new draft version > attached. > > Thanks again for your time, > > Andreas, Aziz, Denis, Joost & Stefan > > > ################# Answers #################### > possible errors: > ---------------- > > - 3.1.2: Algorithm 2: "if ( (i + s) > w - 1 )..." seems to be > missing parenthesis around the "(w-1)" to me. Without those > brackets I could interpret that test to always result in false. > > #Done > > - 4.1.9: should the call to setIdx in alg 12 be after treeSig? > as-is you seem to have incremented the index too soon so > that when alg 11 does getIdx it'd presumably get the > incremented index and cause verification failure. I think > the same is true of alg 16 as well, in section 4.2.4. > > #Done > > significant comments, but likely fixable: > ----------------------------------------- > > - section 5: there are waaaay too many options defined here. > As-is, this will damage potential deployment of xmss. I > would strongly suggest deleting all of the options except the > minimum, that being one (and only one) set of parameters for > XMSS and one for XMSS^MT. If others are needed later, those > can be defined later. (Note that the damage done here includes > the hours of developer time that would be wasted debating > which of these choices to implement/use. Consider the case of > pre-hash variants of eddsa for an ongoing example.) > > #### > # We significantly changed section 5, please check if this > # satisfies your remarks > #### > > - section 5 (or an appendix) should contain some test vectors > (including intermediate values). Without those, implementers > have a much harder time of getting their code right. > > # Added section on reference implementation > > > nits, near-nits and other ignorable things: > ------------------------------------------- > > - abstract: I'd suggest s/can withstand attacks/ can withstand > so-far known attacks/ > > # Done > > - 1.1: You say if used >1 time "no cryptographic security > guarantees remain." It might be clearer to give some > examples of consequences, e.g. that the attacker can forge new > signatures or whatever. > > # Done > > - 1.1: I think you might mention that XMSS and other OTS ideas > require some new crypto APIs. I'm not aware if anyone has > developed proposals for such, but would be interested if > someone has. > > # Done > > - 2.3, 2nd last para: you might want to say what happens with > e.g. B<<2 where B=0xf0. I assume the result is 0xc0 but > someone might think it's 0x3c0 or even 0xc3. > > # Done: Removed the left shift as it is never used for single bytes > > - 2.5: having the "type word" as octet 15 of a 32 byte address > seems odd. Is there a reason why? (Just wondering.) > > # Yes: We got the space and think that it simlifies implementation if > one always has to manipulate whole words (and can treat the address as > uint32_t[8]) > > - 2.6: It seems odd to given an example where the input and > output of base_w() are the same. A different example may be > more useful. (More examples generally would be great.) > > # Done > > - 3.1.3: maybe note that "/" means nothing? Which I assume it > does? Better might be to just say that. > > # Done > > - 3.1.5: "a maximum value of len_1 * (w - 1) * 2^8" is missing > units > > # Done: value -> Integer value > > - 3.1.5: "the variable" - which one? > > # Done: Added explanation > > - 3.1.5: "For the parameter sets given in Section 5 a 32-bit > unsigned integer is sufficient." Sufficient for what? > > # Done: Added " to hold the checksum" > > - 3.1.5: The ascii art at the end of p16 doesn't help much. > > # while the art does not contain new information, we think it's > a handy reminder. Would prefer to keep it like this. > > - 3.1.7: The "MUST match" statement doesn't seem enforceable > nor testable so I'm not sure it's a good idea to include. > OTOH, I do get the idea of using 2119 terms for emphasis. > > # Ok, so what should we do? I agree that key handling cannot be > verified. Still, it seems necessary to emphasize this. > If it is just about the use of the 2119 term, > how about: > "but it is crucial for security that the cryptographic strength > matches that of the used WOTS+ parameters."? > > - 3.1.7: I think it might be useful to point out any specific > problems associated with using a low entropy human memorable > secret (password) for the value S. No matter what you say, > people will do that, so better if you can say you told them > specifically about downsides of doing that. > > # We adressed this in a new sentence at the end of the > # paragraph. > > - 4.1.12: I'm not sure if the MAY there is correct or not. If > it means "you MAY use a different algorithm to get the same > output as alg 12" then that'd be fine. If something else is > meant I'm not sure what you're saying, and it'd probably be > better to not even mention it. > # That is exactly what it means. There are far more efficient > # algorithms to compute that output (but also far more complex) > > - section 5 should also spell out the signature and > public key sizes in bytes and ideally, if you keep multiple > options, (but please don't:-) describe relative or measured > timings. > > # Done > > --f403045dbe944186ed0555113061 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks for making the changes.=C2=A0 Stephen, let me kn= ow if you are ready to give this a thumbs-up, and I'll start an IRSG po= ll.

Allison

<= div class=3D"gmail_quote">On 24 July 2017 at 16:30, A. Huelsing <ietf@hu= elsing.net> wrote:
Dear Ste= phen,

we tried to make the required changes. Please have a look if you are fine with the changes (especially regarding section 5 and the reference
implementation).

You find our answers to your review below and the new draft version attache= d.

Thanks again for your time,

Andreas, Aziz, Denis, Joost & Stefan


################# Answers ####################
possible errors:
----------------

- 3.1.2: Algorithm 2: "if ( (i + s) > w - 1 )..." seems to be<= br> missing parenthesis around the "(w-1)" to me.=C2=A0 Without those=
brackets I could interpret that test to always result in false.

#Done

- 4.1.9: should the call to setIdx in alg 12 be after treeSig?
=C2=A0 as-is you seem to have incremented the index too soon so
that when alg 11 does getIdx it'd presumably get the
incremented index and cause verification failure. I think
the same is true of alg 16 as well, in section 4.2.4.

#Done

significant comments, but likely fixable:
-----------------------------------------

- section 5: there are waaaay too many options defined here.
=C2=A0 As-is, this will damage potential deployment of xmss. I
would strongly suggest deleting all of the options except the
minimum, that being one (and only one) set of parameters for
XMSS and one for XMSS^MT. If others are needed later, those
can be defined later. (Note that the damage done here includes
the hours of developer time that would be wasted debating
which of these choices to implement/use. Consider the case of
pre-hash variants of eddsa for an ongoing example.)

####
#=C2=A0 =C2=A0We significantly changed section 5, please check if this
#=C2=A0 =C2=A0satisfies your remarks
####

- section 5 (or an appendix) should contain some test vectors
=C2=A0 (including intermediate values). Without those, implementers
have a much harder time of getting their code right.

# Added section on reference implementation


nits, near-nits and other ignorable things:
-------------------------------------------

- abstract: I'd suggest s/can withstand attacks/ can withstand
=C2=A0 so-far known attacks/

# Done

- 1.1: You say if used >1 time "no cryptographic security
=C2=A0 guarantees remain." It might be clearer to give some
examples of consequences, e.g. that the attacker can forge new
signatures or whatever.

# Done

- 1.1: I think you might mention that XMSS and other OTS ideas
=C2=A0 require some new crypto APIs. I'm not aware if anyone has
developed proposals for such, but would be interested if
someone has.

# Done

- 2.3, 2nd last para: you might want to say what happens with
=C2=A0 e.g.=C2=A0 B<<2 where B=3D0xf0. I assume the result is 0xc0 bu= t
someone might think it's 0x3c0 or even 0xc3.

# Done: Removed the left shift as it is never used for single bytes<= br>
- 2.5: having the "type word" as octet 15 of a 32 byte address =C2=A0 seems odd. Is there a reason why? (Just wondering.)

# Yes: We got the space and think that it simlifies implementation i= f
one always has to manipulate whole words (and can treat the address as
uint32_t[8])

- 2.6: It seems odd to given an example where the input and
=C2=A0 output of base_w() are the same. A different example may be
more useful. (More examples generally would be great.)

# Done

- 3.1.3: maybe note that "/" means nothing? Which I assume it
=C2=A0 does? Better might be to just say that.

# Done

- 3.1.5: "a maximum value of len_1 * (w - 1) * 2^8" is missing =C2=A0 units

# Done: value -> Integer value

- 3.1.5: "the variable" - which one?

# Done: Added explanation

- 3.1.5: "For the parameter sets given in Section 5 a 32-bit
=C2=A0 unsigned integer is sufficient." Sufficient for what?

# Done: Added " to hold the checksum"

- 3.1.5: The ascii art at the end of p16 doesn't help much.

# while the art does not contain new information, we think it's<= br> a handy reminder. Would prefer to keep it like this.

- 3.1.7: The "MUST match" statement doesn't seem enforceable<= br> =C2=A0 nor testable so I'm not sure it's a good idea to include. OTOH, I do get the idea of using 2119 terms for emphasis.

# Ok, so what should we do? I agree that key handling cannot be
verified. Still, it seems necessary to emphasize this.
If it is just about the use of the 2119 term,
how about:
"but it is crucial for security that the cryptographic strength
matches that of the used WOTS+ parameters."?

- 3.1.7: I think it might be useful to point out any specific
=C2=A0 problems associated with using a low entropy human memorable
secret (password) for the value S. No matter what you say,
people will do that, so better if you can say you told them
specifically about downsides of doing that.

# We adressed this in a new sentence at the end of the
# paragraph.

- 4.1.12: I'm not sure if the MAY there is correct or not.=C2=A0 If
=C2=A0 it means "you MAY use a different algorithm to get the same
output as alg 12" then that'd be fine. If something else is
meant I'm not sure what you're saying, and it'd probably be
better to not even mention it.
# That is exactly what it means. There are far more efficient
# algorithms to compute that output (but also far more complex)

- section 5 should also spell out the signature and
public key sizes in bytes and ideally, if you keep multiple
options, (but please don't:-) describe relative or measured
timings.

# Done


--f403045dbe944186ed0555113061-- From nobody Mon Jul 24 07:44:00 2017 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 086B9131D70; Mon, 24 Jul 2017 07:43:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.302 X-Spam-Level: X-Spam-Status: No, score=-4.302 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.001, 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 EP-2XQSRrrWk; Mon, 24 Jul 2017 07:43:55 -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 94C32131D6F; Mon, 24 Jul 2017 07:43:55 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id CFF06BE50; Mon, 24 Jul 2017 15:43:53 +0100 (IST) 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 KerVh1aHaFrG; Mon, 24 Jul 2017 15:43:53 +0100 (IST) Received: from [134.226.36.93] (bilbo.dsg.cs.tcd.ie [134.226.36.93]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 8FCF3BE4D; Mon, 24 Jul 2017 15:43:53 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1500907433; bh=2S9ypQrn2gggphyOnbhoL92EDLT7WOFZT3HuSd5RxeI=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=H3BqAYKuBFGwGM4YkQVifu1hiEzQSUiF3w+Zwj8TOhVIBKhaDBD7f3oGmthmF/M2R uUVpR9PCIRI5xFjZ1jonjNoHxV40HmfTmtCVu+NQvHxnfzCK9nL3wHSrTWFGfzppgf F7GomCDKN8qf/BsSgEWrmu9ySlZK+ZdQ7G+RVSYI= To: "A. Huelsing" , "Paterson, Kenny" , Alexey Melnikov , "irsg@irtf.org" , "cfrg@irtf.org" Cc: "draft-irtf-cfrg-xmss-hash-based-signatures@ietf.org" References: <9a878527-5ab9-5429-7c5d-4f7e4ca4e8db@isode.com> <08944dc3-9086-ed47-cc1b-54248b3dac70@cs.tcd.ie> <9e6b6146-e376-86cb-70be-0127a3e72d16@cs.tcd.ie> <6f90e485-01f4-5ad8-49ef-e51c52e01a46@cs.tcd.ie> <5e328e85-a8a1-67f1-3853-418309b04a17@huelsing.net> <27cc7000-7fd5-27dd-b8b5-9b9518a9f3ad@huelsing.net> <1785b9ed-fb53-889a-9d34-311c7ea5c762@cs.tcd.ie> <4699f3d2-40ce-9c40-d29a-d24ecb3b6cab@huelsing.net> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <92dbf402-be6b-cf6d-40da-983f6faa5e8c@cs.tcd.ie> Date: Mon, 24 Jul 2017 15:43:52 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <4699f3d2-40ce-9c40-d29a-d24ecb3b6cab@huelsing.net> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="Q2k6mEjaTdQ1bhwHJ55DK04ULXQssufU0" Archived-At: Subject: Re: [Cfrg] [irsg] IRSG review of draft-irtf-cfrg-xmss-hash-based-signatures-08 X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jul 2017 14:43:58 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --Q2k6mEjaTdQ1bhwHJ55DK04ULXQssufU0 Content-Type: multipart/mixed; boundary="NG0dhUdbis0s2UJlkVDOP5f7x1olDQ8Gp"; protected-headers="v1" From: Stephen Farrell To: "A. Huelsing" , "Paterson, Kenny" , Alexey Melnikov , "irsg@irtf.org" , "cfrg@irtf.org" Cc: "draft-irtf-cfrg-xmss-hash-based-signatures@ietf.org" Message-ID: <92dbf402-be6b-cf6d-40da-983f6faa5e8c@cs.tcd.ie> Subject: Re: [irsg] IRSG review of draft-irtf-cfrg-xmss-hash-based-signatures-08 References: <9a878527-5ab9-5429-7c5d-4f7e4ca4e8db@isode.com> <08944dc3-9086-ed47-cc1b-54248b3dac70@cs.tcd.ie> <9e6b6146-e376-86cb-70be-0127a3e72d16@cs.tcd.ie> <6f90e485-01f4-5ad8-49ef-e51c52e01a46@cs.tcd.ie> <5e328e85-a8a1-67f1-3853-418309b04a17@huelsing.net> <27cc7000-7fd5-27dd-b8b5-9b9518a9f3ad@huelsing.net> <1785b9ed-fb53-889a-9d34-311c7ea5c762@cs.tcd.ie> <4699f3d2-40ce-9c40-d29a-d24ecb3b6cab@huelsing.net> In-Reply-To: <4699f3d2-40ce-9c40-d29a-d24ecb3b6cab@huelsing.net> --NG0dhUdbis0s2UJlkVDOP5f7x1olDQ8Gp Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: quoted-printable Hi Andreas, I took a look at the diff vs. -09 and all the changes that I reckon were needed are covered nicely. I also think that the set of changes as a whole are good improvements, thanks. So fwiw, I think this is ready for publication. Cheers, S. PS: I'd still prefer fewer options, but we talked about that already:-) That oughtn't delay publication I reckon. On 24/07/17 15:30, A. Huelsing wrote: > Dear Stephen, >=20 > we tried to make the required changes. Please have a look if you are fi= ne > with the changes (especially regarding section 5 and the reference > implementation). >=20 > You find our answers to your review below and the new draft version att= ached. >=20 > Thanks again for your time, >=20 > Andreas, Aziz, Denis, Joost & Stefan >=20 >=20 > ################# Answers #################### > possible errors: > ---------------- >=20 > - 3.1.2: Algorithm 2: "if ( (i + s) > w - 1 )..." seems to be > missing parenthesis around the "(w-1)" to me. Without those > brackets I could interpret that test to always result in false. >=20 > #Done >=20 > - 4.1.9: should the call to setIdx in alg 12 be after treeSig? > as-is you seem to have incremented the index too soon so > that when alg 11 does getIdx it'd presumably get the > incremented index and cause verification failure. I think > the same is true of alg 16 as well, in section 4.2.4. >=20 > #Done >=20 > significant comments, but likely fixable: > ----------------------------------------- >=20 > - section 5: there are waaaay too many options defined here. > As-is, this will damage potential deployment of xmss. I > would strongly suggest deleting all of the options except the > minimum, that being one (and only one) set of parameters for > XMSS and one for XMSS^MT. If others are needed later, those > can be defined later. (Note that the damage done here includes > the hours of developer time that would be wasted debating > which of these choices to implement/use. Consider the case of > pre-hash variants of eddsa for an ongoing example.) >=20 > #### > # We significantly changed section 5, please check if this > # satisfies your remarks > #### >=20 > - section 5 (or an appendix) should contain some test vectors > (including intermediate values). Without those, implementers > have a much harder time of getting their code right. >=20 > # Added section on reference implementation >=20 >=20 > nits, near-nits and other ignorable things: > ------------------------------------------- >=20 > - abstract: I'd suggest s/can withstand attacks/ can withstand > so-far known attacks/ > =20 > # Done >=20 > - 1.1: You say if used >1 time "no cryptographic security > guarantees remain." It might be clearer to give some > examples of consequences, e.g. that the attacker can forge new > signatures or whatever. >=20 > # Done >=20 > - 1.1: I think you might mention that XMSS and other OTS ideas > require some new crypto APIs. I'm not aware if anyone has > developed proposals for such, but would be interested if > someone has. >=20 > # Done >=20 > - 2.3, 2nd last para: you might want to say what happens with > e.g. B<<2 where B=3D0xf0. I assume the result is 0xc0 but > someone might think it's 0x3c0 or even 0xc3. >=20 > # Done: Removed the left shift as it is never used for single bytes >=20 > - 2.5: having the "type word" as octet 15 of a 32 byte address > seems odd. Is there a reason why? (Just wondering.) >=20 > # Yes: We got the space and think that it simlifies implementation if > one always has to manipulate whole words (and can treat the address as > uint32_t[8]) > =20 > - 2.6: It seems odd to given an example where the input and > output of base_w() are the same. A different example may be > more useful. (More examples generally would be great.) >=20 > # Done >=20 > - 3.1.3: maybe note that "/" means nothing? Which I assume it > does? Better might be to just say that. > =20 > # Done >=20 > - 3.1.5: "a maximum value of len_1 * (w - 1) * 2^8" is missing > units > =20 > # Done: value -> Integer value >=20 > - 3.1.5: "the variable" - which one? >=20 > # Done: Added explanation >=20 > - 3.1.5: "For the parameter sets given in Section 5 a 32-bit > unsigned integer is sufficient." Sufficient for what? >=20 > # Done: Added " to hold the checksum" > =20 > - 3.1.5: The ascii art at the end of p16 doesn't help much. >=20 > # while the art does not contain new information, we think it's > a handy reminder. Would prefer to keep it like this. >=20 > - 3.1.7: The "MUST match" statement doesn't seem enforceable > nor testable so I'm not sure it's a good idea to include. > OTOH, I do get the idea of using 2119 terms for emphasis. >=20 > # Ok, so what should we do? I agree that key handling cannot be > verified. Still, it seems necessary to emphasize this. > If it is just about the use of the 2119 term, > how about: > "but it is crucial for security that the cryptographic strength > matches that of the used WOTS+ parameters."? >=20 > - 3.1.7: I think it might be useful to point out any specific > problems associated with using a low entropy human memorable > secret (password) for the value S. No matter what you say, > people will do that, so better if you can say you told them > specifically about downsides of doing that. >=20 > # We adressed this in a new sentence at the end of the > # paragraph. >=20 > - 4.1.12: I'm not sure if the MAY there is correct or not. If > it means "you MAY use a different algorithm to get the same > output as alg 12" then that'd be fine. If something else is > meant I'm not sure what you're saying, and it'd probably be > better to not even mention it. > # That is exactly what it means. There are far more efficient > # algorithms to compute that output (but also far more complex) >=20 > - section 5 should also spell out the signature and > public key sizes in bytes and ideally, if you keep multiple > options, (but please don't:-) describe relative or measured > timings. >=20 > # Done >=20 --NG0dhUdbis0s2UJlkVDOP5f7x1olDQ8Gp-- --Q2k6mEjaTdQ1bhwHJ55DK04ULXQssufU0 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJZdgeoAAoJEC88hzaAX42ixBsIALt/4Sz1Ar32uows9Bb7Jtgv 5f8cUblsccRYAjnJiV9qZ7bDzjeQ6J41qiz+Lrmx5Qywj/1jhyg7afPonD3N1AUl UG6EVG9py5Wv34bD5ASPh/MkZdqWafds9cZu67vQSHjsMyLUu+hsM5EtjECcqjON CwVymfxqfrw7++mdeSrW9ENd260owqkQuubXToZEnwcSiWt1B/nOHHTYS7gQy+kR h/3S8+cGg7PM7txZEly1Rl9n3hT7ly7zYSVj1Oiv0i2ZCJdueWJO58LtHy0u0ztD mtiCbZJ6EJ3NIvQ1Lg0+SDrKfB74voh3/ewFgKEOVFCOm3gb4TNRCdmZvnyXLxU= =qYNS -----END PGP SIGNATURE----- --Q2k6mEjaTdQ1bhwHJ55DK04ULXQssufU0-- From nobody Mon Jul 24 07:45:56 2017 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 EEAFD131DA6; Mon, 24 Jul 2017 07:45:53 -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 kK_TWAwrJ1-0; Mon, 24 Jul 2017 07:45:53 -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 2D4C0131D2C; Mon, 24 Jul 2017 07:45:53 -0700 (PDT) Received: from [10.32.60.46] (142-254-101-176.dsl.dynamic.fusionbroadband.com [142.254.101.176]) (authenticated bits=0) by mail.proper.com (8.15.2/8.14.9) with ESMTPSA id v6OEj0fE063532 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 24 Jul 2017 07:45:01 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: mail.proper.com: Host 142-254-101-176.dsl.dynamic.fusionbroadband.com [142.254.101.176] claimed to be [10.32.60.46] From: "Paul Hoffman" To: "Allison Mankin" Cc: "cfrg@irtf.org" , "irsg@irtf.org" Date: Mon, 24 Jul 2017 07:45:48 -0700 Message-ID: <69AF34C2-C594-44D2-93E8-EAA9175F1291@vpnc.org> In-Reply-To: References: <9a878527-5ab9-5429-7c5d-4f7e4ca4e8db@isode.com> <08944dc3-9086-ed47-cc1b-54248b3dac70@cs.tcd.ie> <9e6b6146-e376-86cb-70be-0127a3e72d16@cs.tcd.ie> <6f90e485-01f4-5ad8-49ef-e51c52e01a46@cs.tcd.ie> <5e328e85-a8a1-67f1-3853-418309b04a17@huelsing.net> <27cc7000-7fd5-27dd-b8b5-9b9518a9f3ad@huelsing.net> <1785b9ed-fb53-889a-9d34-311c7ea5c762@cs.tcd.ie> <4699f3d2-40ce-9c40-d29a-d24ecb3b6cab@huelsing.net> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.6r5347) Archived-At: Subject: Re: [Cfrg] [irsg] IRSG review of draft-irtf-cfrg-xmss-hash-based-signatures-08 X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jul 2017 14:45:54 -0000 On 24 Jul 2017, at 7:39, Allison Mankin wrote: > Thanks for making the changes. Stephen, let me know if you are ready > to > give this a thumbs-up, and I'll start an IRSG poll. Do the IRSG polls normally happen at the same time as the WG Last calls? The RGLC on this document just started a few days ago. --Paul Hoffman From nobody Mon Jul 24 07:52:11 2017 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 13176131DAA; Mon, 24 Jul 2017 07:52:09 -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 z6NOhXGj-Veb; Mon, 24 Jul 2017 07:52:08 -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 574D1131DA2; Mon, 24 Jul 2017 07:52:08 -0700 (PDT) Received: from [10.32.60.46] (142-254-101-176.dsl.dynamic.fusionbroadband.com [142.254.101.176]) (authenticated bits=0) by mail.proper.com (8.15.2/8.14.9) with ESMTPSA id v6OEpEQP064282 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 24 Jul 2017 07:51:16 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: mail.proper.com: Host 142-254-101-176.dsl.dynamic.fusionbroadband.com [142.254.101.176] claimed to be [10.32.60.46] From: "Paul Hoffman" To: "Allison Mankin" Cc: "cfrg@irtf.org" , "irsg@irtf.org" Date: Mon, 24 Jul 2017 07:52:03 -0700 Message-ID: <4ABB7C1F-C43A-485B-85E6-06603D3C1064@vpnc.org> In-Reply-To: <69AF34C2-C594-44D2-93E8-EAA9175F1291@vpnc.org> References: <9a878527-5ab9-5429-7c5d-4f7e4ca4e8db@isode.com> <08944dc3-9086-ed47-cc1b-54248b3dac70@cs.tcd.ie> <9e6b6146-e376-86cb-70be-0127a3e72d16@cs.tcd.ie> <6f90e485-01f4-5ad8-49ef-e51c52e01a46@cs.tcd.ie> <5e328e85-a8a1-67f1-3853-418309b04a17@huelsing.net> <27cc7000-7fd5-27dd-b8b5-9b9518a9f3ad@huelsing.net> <1785b9ed-fb53-889a-9d34-311c7ea5c762@cs.tcd.ie> <4699f3d2-40ce-9c40-d29a-d24ecb3b6cab@huelsing.net> <69AF34C2-C594-44D2-93E8-EAA9175F1291@vpnc.org> MIME-Version: 1.0 X-Mailer: MailMate (1.9.6r5347) Archived-At: Subject: Re: [Cfrg] [irsg] IRSG review of draft-irtf-cfrg-xmss-hash-based-signatures-08 X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jul 2017 14:52:09 -0000 Er, n'r mind. I got two similarly-named drafts mixed up. --Paul Hoffman From nobody Mon Jul 24 08:02:42 2017 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 CC9BE131DAA; Mon, 24 Jul 2017 08:02:40 -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 19dhzTMTUbWs; Mon, 24 Jul 2017 08:02:39 -0700 (PDT) Received: from mail-wm0-x22f.google.com (mail-wm0-x22f.google.com [IPv6:2a00:1450:400c:c09::22f]) (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 0A998127058; Mon, 24 Jul 2017 08:02:39 -0700 (PDT) Received: by mail-wm0-x22f.google.com with SMTP id c184so34171454wmd.0; Mon, 24 Jul 2017 08:02:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=fD6O6KRdEgVbWdtvYmAOeVNdlBqiN4sx4kArez1weYE=; b=hOm2+w3ZI9in2xma/+j9NbdUg1yywopVDfp6VHBgmxpzjgV+XNSEhC6Ri31xLX9uVn Xe/YizyZIbEQLRnjnLejSxIkHW8iVcIPUoQTYXJ+Z5+UjQYxdaDkad82Eu10M0YjUK6L 3bMz5yU7BtmdaRj/Qb+3ymHLrKmxzbymkodFlMiufSTKwr38B9t+TRoiqlAvnUTx35sQ Mw0aW4KScoM1ZnyLM2YNHAxhySZ1MYyM5ExyJSaHJXclgcobc/OWhtwYYxsRVDeJSalF lrtmqExHGVjT+eR0p/LRkRumGHs2f8RMAl6nbmjm2YZ1BOl/3lLcsgNWWkHb15mgytRm +P5A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=fD6O6KRdEgVbWdtvYmAOeVNdlBqiN4sx4kArez1weYE=; b=VxoqRY9olWdo7UoMj1EUplayiIf5CkufAxtgpq12BQeUALMwGtbL5nYzsqYeQQVjGn 0Kw2jLLalma52hxBUpVYu7o+kNApXnyd6ekSCGPKKjlH3ggRQQjzzAE6hXBzDU55y138 pWkPJ9QkD6HihEBODubzlgJ3pZkVpfTYK1UUM8wTuBjtuK0Fj7NeRTDzO9WBjX7nvDkI ApbmE/37UTnHoekymwy2aEuG7l/iQ5KEWqMBW793beUBP0qh2zF7NLf8eBPAYikV858i 2yghjYx2HLhzAiqET8/0NhapRy8Q1+llarOfHO1uEW2f9PfnyzA0k4mfGOFmqutZcz4w cZaA== X-Gm-Message-State: AIVw112PIGTR7+K/cOLfzAypstoDBEaSHBs8RF58fGYJz8Ep6uX/zPVs 1dZNE9cAWSkLiocuiqmSsd8K+YPfYQ== X-Received: by 10.80.142.165 with SMTP id w34mr14798549edw.34.1500908557426; Mon, 24 Jul 2017 08:02:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.80.138.69 with HTTP; Mon, 24 Jul 2017 08:02:36 -0700 (PDT) In-Reply-To: <4ABB7C1F-C43A-485B-85E6-06603D3C1064@vpnc.org> References: <9a878527-5ab9-5429-7c5d-4f7e4ca4e8db@isode.com> <08944dc3-9086-ed47-cc1b-54248b3dac70@cs.tcd.ie> <9e6b6146-e376-86cb-70be-0127a3e72d16@cs.tcd.ie> <6f90e485-01f4-5ad8-49ef-e51c52e01a46@cs.tcd.ie> <5e328e85-a8a1-67f1-3853-418309b04a17@huelsing.net> <27cc7000-7fd5-27dd-b8b5-9b9518a9f3ad@huelsing.net> <1785b9ed-fb53-889a-9d34-311c7ea5c762@cs.tcd.ie> <4699f3d2-40ce-9c40-d29a-d24ecb3b6cab@huelsing.net> <69AF34C2-C594-44D2-93E8-EAA9175F1291@vpnc.org> <4ABB7C1F-C43A-485B-85E6-06603D3C1064@vpnc.org> From: Allison Mankin Date: Mon, 24 Jul 2017 17:02:36 +0200 Message-ID: To: Paul Hoffman Cc: "cfrg@irtf.org" , "irsg@irtf.org" Content-Type: multipart/alternative; boundary="f403045c529467e7e405551181a0" Archived-At: Subject: Re: [Cfrg] [irsg] IRSG review of draft-irtf-cfrg-xmss-hash-based-signatures-08 X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jul 2017 15:02:41 -0000 --f403045c529467e7e405551181a0 Content-Type: text/plain; charset="UTF-8" Happens to the best of us :-) On 24 July 2017 at 16:52, Paul Hoffman wrote: > Er, n'r mind. I got two similarly-named drafts mixed up. > > --Paul Hoffman > --f403045c529467e7e405551181a0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Happens to the best of us :-)

On 24 July 2017 at 16:52, P= aul Hoffman <paul.hoffman@vpnc.org> wrote:
Er, n'r mind. I got two similarly-named drafts mix= ed up.

--Paul Hoffman

--f403045c529467e7e405551181a0-- From nobody Mon Jul 24 08:14:41 2017 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 B4705131E0F; Mon, 24 Jul 2017 08:14:33 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: cfrg@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.57.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150090927369.32037.9841595916887034298@ietfa.amsl.com> Date: Mon, 24 Jul 2017 08:14:33 -0700 Archived-At: Subject: [Cfrg] I-D Action: draft-irtf-cfrg-xmss-hash-based-signatures-10.txt X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.22 List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jul 2017 15:14:34 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Crypto Forum RG of the IRTF. Title : XMSS: Extended Hash-Based Signatures Authors : Andreas Huelsing Denis Butin Stefan-Lukas Gazdag Joost Rijneveld Aziz Mohaisen Filename : draft-irtf-cfrg-xmss-hash-based-signatures-10.txt Pages : 72 Date : 2017-07-24 Abstract: This note describes the eXtended Merkle Signature Scheme (XMSS), a hash-based digital signature system. It follows existing descriptions in scientific literature. The note specifies the WOTS+ one-time signature scheme, a single-tree (XMSS) and a multi-tree variant (XMSS^MT) of XMSS. Both variants use WOTS+ as a main building block. XMSS provides cryptographic digital signatures without relying on the conjectured hardness of mathematical problems. Instead, it is proven that it only relies on the properties of cryptographic hash functions. XMSS provides strong security guarantees and is even secure when the collision resistance of the underlying hash function is broken. It is suitable for compact implementations, relatively simple to implement, and naturally resists side-channel attacks. Unlike most other signature systems, hash-based signatures can withstand so far known attacks using quantum computers. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-irtf-cfrg-xmss-hash-based-signatures/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-irtf-cfrg-xmss-hash-based-signatures-10 https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-xmss-hash-based-signatures-10 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-irtf-cfrg-xmss-hash-based-signatures-10 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 Mon Jul 24 09:40:53 2017 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 0FC3A131EA0 for ; Mon, 24 Jul 2017 09:40:52 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: X-Test-IDTracker: no X-IETF-IDTracker: 6.57.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150091445206.31897.1194666585163923378.idtracker@ietfa.amsl.com> Date: Mon, 24 Jul 2017 09:40:52 -0700 From: IETF Secretariat Archived-At: Subject: [Cfrg] Milestones changed for cfrg RG X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.22 List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jul 2017 16:40:52 -0000 Changed milestone "Send "ChaCha20 and Poly1305 for IETF Protocols" to IRSG", set state to active from review, accepting new milestone. Changed milestone "Submit "AES-GCM-SIV: Nonce Misuse-Resistant Authenticated Encryption" to IRSG", set state to active from review, accepting new milestone. URL: https://datatracker.ietf.org/rg/cfrg/about/ From nobody Mon Jul 24 15:55:27 2017 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 408DE127867 for ; Mon, 24 Jul 2017 15:55:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.701 X-Spam-Level: X-Spam-Status: No, score=-4.701 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_H2=-2.8, 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 4ksqc0f4IuTw for ; Mon, 24 Jul 2017 15:55:23 -0700 (PDT) Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-eopbgr10046.outbound.protection.outlook.com [40.107.1.46]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE098124C27 for ; Mon, 24 Jul 2017 15:55:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rhul.onmicrosoft.com; s=selector1-rhul-ac-uk; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=SCFd1AiQbwWvwQnyUK40e9XSnFMZtgrAE96KYdTFo2c=; b=03v4ayGdUpz2+r9qym3NGcmfUB2DP62PFjm47WXMoWTptA47g+ZGrAEhunuhCk6Z3qNhhtP3fd+v+/Opzv2XrFJ4p7XNkI+adcjHS8/qFlqxLJU9zqo6wTOnqaNtssdIxrMce13AhpK1AneMPz5Kuc89bCaFlhMTYvtRUbGcmK8= Received: from AM4PR0301MB1906.eurprd03.prod.outlook.com (10.168.2.156) by AM4PR0301MB1908.eurprd03.prod.outlook.com (10.168.3.8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1282.10; Mon, 24 Jul 2017 22:55:20 +0000 Received: from AM4PR0301MB1906.eurprd03.prod.outlook.com ([fe80::e475:7abc:5c25:5e28]) by AM4PR0301MB1906.eurprd03.prod.outlook.com ([fe80::e475:7abc:5c25:5e28%14]) with mapi id 15.01.1282.017; Mon, 24 Jul 2017 22:55:19 +0000 From: "Paterson, Kenny" To: "cfrg@irtf.org" Thread-Topic: Minutes from CFRG meeting at IETF99 Thread-Index: AQHTBM/sGSW+9pGM2Eu8xlKe/bsDVA== Date: Mon, 24 Jul 2017 22:55:19 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.1.161129 authentication-results: spf=none (sender IP is ) smtp.mailfrom=Kenny.Paterson@rhul.ac.uk; x-originating-ip: [78.146.77.209] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM4PR0301MB1908; 7:fMnrIspajt/YqxVezmI3PB4N3sJ/MM/OHD/XIs0ophPH7sqecymszJ4t+24f191b+G3KPlke6MIY1xvAGnTFod10uRET+RbjQj0W1YFnehNXpYA8hosYbwmtEvqO5WZ5Qrb/ZGoIsHTiOhtMiB58bZwN944SPwLnQt3d60MH3wdRbxO27E2wQYlsMvdLhiny0KOmW6qztNt6WzgEYFt8fcto6/KkhjrSFjE0pjS2Oyzn3Hb6pUt4yN5sUSvNVaC6H+cLudiFVWs80SZ5wDkeZG3sQhGpfC8sEH3seMrnnV0j4/ntTvV50LqaWh6Vfquy6JJr8dhDtHaGjSxmVeFrQ3eRRRl/2dcoDcd48X6EdftkvQ1veWy22vFFjr4wWdrbjcVeejVBdrnhvD0OHGfFRHkHLzUpNugzr04gwBfKBdiFlohmWBq1BuFziH3x4QkhlZssSV1gnnRisjcFLkSdOOYEcn/HXzmYiRuI8i32FkDxHBnVs7Snk4QrwK7483NG8giEhtY0t5vmgq4eOg/GzApX6ijSs+dJPE6ujPyNA6xvdydYgf1zEV0CzvfRS1tcWgymnFpqyGr49xga2z4f8/Y6SnVaRwg7sU2imIxToNI+2GuT5CuqG1Mt5klocE+SzfATQcPpXl9lqi0LpXIMcH2767oCFvX7p8CkE/ido6wlCGdCmiZ6kH/DfTeVEgJ5IOVqqpAhFglKvTrjn5C0Z8riNUhDJu+DCwmXr4D1aM5QUlpRELrVUg0JZxjxp3kam6hC8koaLnZGhRymkJhZJ5rsKLbtk3XvU5MY7DxT+JM= x-forefront-antispam-report: SFV:SKI; SCL:-1; SFV:NSPM; SFS:(10009020)(6009001)(39840400002)(39450400003)(39850400002)(39410400002)(39400400002)(199003)(189002)(14454004)(4326008)(101416001)(72206003)(966005)(7736002)(86362001)(68736007)(413944005)(4001350100001)(6116002)(6506006)(102836003)(6512007)(105586002)(305945005)(3846002)(229853002)(6486002)(6306002)(99286003)(5640700003)(106356001)(6436002)(3280700002)(6916009)(42882006)(2351001)(2900100001)(3660700001)(6246003)(53936002)(2906002)(8936002)(66066001)(8676002)(81166006)(1730700003)(81156014)(74482002)(97736004)(2501003)(5250100002)(189998001)(36756003)(68196006)(478600001)(54356999)(5660300001)(110136004)(50986999)(83506001)(38730400002)(25786009); DIR:OUT; SFP:1101; SCL:1; SRVR:AM4PR0301MB1908; H:AM4PR0301MB1906.eurprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; x-ms-office365-filtering-correlation-id: 47827518-297a-448b-3194-08d4d2e70f12 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:AM4PR0301MB1908; x-ms-traffictypediagnostic: AM4PR0301MB1908: x-exchange-antispam-report-test: UriScan:(120809045254105)(209352067349851)(254730959083279)(91638250987450); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(8121501046)(5005006)(93006095)(93001095)(100000703101)(100105400095)(3002001)(10201501046)(6041248)(20161123564025)(20161123555025)(201703131423075)(201702281529075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(20161123562025)(20161123558100)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:AM4PR0301MB1908; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:AM4PR0301MB1908; x-forefront-prvs: 0378F1E47A received-spf: None (protection.outlook.com: rhul.ac.uk does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM 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: 24 Jul 2017 22:55:19.6319 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2efd699a-1922-4e69-b601-108008d28a2e X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR0301MB1908 Archived-At: Subject: Re: [Cfrg] Minutes from CFRG meeting at IETF99 X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jul 2017 22:55:25 -0000 RGVhciBDRlJHIHBhcnRpY2lwYW50cywNCg0KTWludXRlcyBmcm9tIHRoZSBDRlJHIG1lZXRpbmcg YXQgSUVURjk5IGluIFByYWd1ZSBsYXN0IHdlZWsgYXJlIG5vdw0KYXZhaWxhYmxlIG9ubGluZSBh dDoNCg0KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvbWludXRlcy05OS1jZnJnLw0K DQoNClRoYW5rcyB0byBTdGVwaGVuIEZhcnJlbGwgZm9yIHRha2luZyBub3RlcyBvZiB0aGUgc2Vz c2lvbiwgb24gd2hpY2ggdGhlc2UNCm1pbnV0ZXMgYXJlIGJhc2VkLiANCg0KUGxlYXNlIHNlbmQg YW55IGNvcnJlY3Rpb25zIHRvIHRoZSBjaGFpcnMuDQoNClRoZXJlJ3MgYWxzbyBhIHlvdXR1YmUg dmlkZW8gb2YgdGhlIHNlc3Npb246DQoNCmh0dHBzOi8vd3d3LnlvdXR1YmUuY29tL3dhdGNoP3Y9 VTFlUUlFRzZZTFUNCg0KQmVzdCB3aXNoZXMsDQoNCkFsZXhleSBhbmQgS2VubnkNCg0K From nobody Wed Jul 26 04:32:17 2017 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 2A907131FFC for ; Wed, 26 Jul 2017 04:32:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, 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 MfXrXFY7S9Vz for ; Wed, 26 Jul 2017 04:32:11 -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 5D842131FF7 for ; Wed, 26 Jul 2017 04:32:11 -0700 (PDT) Received: by mail-lf0-x232.google.com with SMTP id t128so37112107lff.2 for ; Wed, 26 Jul 2017 04:32:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=21q23PDTgBieJNQb+1QskSPHF4nLdTNaN716qy9iYws=; b=iBqLsbTTM+O1XFpSdIALheMumakxS7k8Lk9pIdZIFl9j/l+ngvykDPnG6Oy05iP5of gmt3hg/nNd4Omjs8UEFozHmlJOBDOpBPzHTGDNml2o/nhXXndLN3HN180LHqxx/lpIyY xiKxKabw4m147RFtiw7LSAH/oCauy3RwN9hZOwwaVuuubvuly/mPpBhcu8QFV35Wc/Qx AazUVZ746bC0jURl9GjT/WmSyxX1K/57a5aovVeZkokNb60Kw6XAkgubrKl7nheBZXH1 DSorjLAHaV6Zy0WYpIEVPaDqAO0TpHFnLUo4Z5DszKM1TVAdBxPObi+75l/5kNe/G1ff Sdig== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=21q23PDTgBieJNQb+1QskSPHF4nLdTNaN716qy9iYws=; b=W2TA7XcyVDXv3KbBUHoTkQ62UcHAeAh2JycofS2i31dY307513svhHFuqqpMFljiRK 9CNY8l6vWmSU3BN36X13hMWxA5u71LlrBepj7WoekYNa4n7ZKhkv88/gMOTzte8OO/bV NJ39yw0OG+M0uHLVaS8FeQl5YTUQ2qqeTCt1ke02PpDRS0IqE1MAh1dGUW3lJ6ZFY8Oj osoSselat+bh9LU15kyyMtH3yiy/QbWddBzUBcTNCz5CaiBM0izvNqDMQkv6+HIAD7nT s8XD0oX3/CMwx8kRFq2LHn+96zjYHV1R50woLrEbatgqnD4+0x6+XVa10h18fXJF95LJ JTgQ== X-Gm-Message-State: AIVw113DXGsLROKq6bFceCbq7JIqgavoV46gLUScqHPsWNvm+2Dgi1AI jgSFyc/wG4Yxsgt9dw4eKitCjTuiCA== X-Received: by 10.46.69.87 with SMTP id s84mr311183lja.129.1501068729470; Wed, 26 Jul 2017 04:32:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.37.83 with HTTP; Wed, 26 Jul 2017 04:32:08 -0700 (PDT) In-Reply-To: References: <810C31990B57ED40B2062BA10D43FBF501B63B22@XMB116CNC.rim.net> <20170721163204.8573013.1016.15939@blackberry.com> From: Thomas Garcia Date: Wed, 26 Jul 2017 12:32:08 +0100 Message-ID: To: Sharon Goldberg Cc: Dan Brown , "jan@ns1.com" , "cfrg@irtf.org" , Dimitrios Papadopoulos , Leonid Reyzin Content-Type: multipart/alternative; boundary="001a114b0cda675212055536cc3a" Archived-At: Subject: Re: [Cfrg] draft-goldbe-vrf: Verifiable Random Functions X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jul 2017 11:32:15 -0000 --001a114b0cda675212055536cc3a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello, A couple of questions: 1. It seems that one of the properties that you are interested that the VRF will have is determinism. On the other hand, the EC-VRF value is dependent on the choice of some random number k. How are these two facts compatible? Am I missing something? 2. The value c calculated in EC-VRF is only 128 bits long for Ed25519. In normal usage of Ed25519 the signature uses the full length of the hash output. Doesn't this expose the signature to collision attacks? Thomas G. On Sun, Jul 23, 2017 at 6:10 AM, Sharon Goldberg wrote: > Hi Dan, > > Thank you for your comments. Indeed, VRFs have been around since 1999. > They are really "verifiable PRFs" but the name is by now standard in the > crypto literature, and changing it will cause more confusion than keeping > it. > > In terms of the VRF's security properties, there are three: uniqueness, > collision resistance, and pseudorandomness. These are defined in our draf= t ( > https://tools.ietf.org/html/draft-goldbe-vrf-01#section-3). > > How VRFs prevent dictionary attacks: a public hash is subject to a > dictionary attack because, given the output, an adversary can evaluate th= e > hash on different inputs and see what hits the outputs. In a VRF, the > adversary can't evaluate the hash on different inputs. > > You say it's not surprising that "random oracle model proof can prove the > output of a hash to be random". But actually, the output of a hash is NOT > random if the input and the hash function are known. This is because the > output of a hash is deterministic (every input maps to a unique output). > That's exactly what enables dictionary attacks. This is in contrast to a > VRF, where the output is (pseudo)random even given knowledge of the input= . > Only once the VRF proof is given, does the VRF output stop looking random= . > Note that random oracles are not essential for VRFs, and non-random-oracl= es > constructions exist (but are less efficient than what we propose to > standardize). > > As far as use cases, here are a few: > > In the NSEC5 use case for DNSSEC, you have sensitive data (domain names) > and you sign consecutive pairs of hashes of domain names in order to be > able to prove absence of a name. If you just use standard hashing, whenev= er > signed hash values are disclosed, your sensitive data is subject to > dictionary attacks. VRFs solve that problem, and sensitive names don't ha= ve > to be disclosed at all. More details are in https://eprint.iacr.org/201 > 7/099.pdf > > In CONIKS (also Google Key Transparency, Signal secure messaging, Yahoo! > Coname) you also have some sensitive data (user names) that are put into = a > Merkle-like authenticated data structure. If you just use standard hashin= g, > whenever hash values are disclosed, sensitive data is subject to dictiona= ry > attacks. If you use VRFs, sensitive data again can be disclosed only on a= n > as-needed basis. More details are in https://eprint.iacr.org/2014/ > 1004.pdf. > > In a cryptocurrency use case, you wish perform a coin flip that is > deterministic and provably correct, but cannot be done by just anyone. > More details are in https://people.csail.mit.ed > u/nickolai/papers/gilad-algorand-eprint.pdf and possibly other > cryptocurrency papers. > > Bryan Ford mentioned an additional usecase at the mic on Tuesday: > distributed password protection protocols > > Many of these use case are already putting VRFs into production use (esp. > the CONIKS one). You can see a list of the various implementations we ha= ve > found in the "implementation status" section of our draft. One of the > reasons we think this spec is so important is that we found flaws in > several of the implementations that can be used to trivially break > uniqueness. (See eg: https://github.com/google/keytransparency/issues/56= 7 > ) > > Thanks, > Sharon > > On Fri, Jul 21, 2017 at 7:32 PM, Dan Brown > wrote: > >> Answering myself below: VRFs have been around since 1999, so are not so >> new. =E2=80=8EStill don't like the name, and still have trouble seeing = the value. >> >> *From: *Dan Brown >> *Sent: *Tuesday, July 18, 2017 2:29 PM >> *To: *Sharon Goldberg; cfrg@irtf.org >> *Cc: *jan@ns1.com; Leonid Reyzin; Dimitrios Papadopoulos >> *Subject: *Re: [Cfrg] draft-goldbe-vrf: Verifiable Random Functions >> >> Hi Sharon and CFRG, >> >> >> >> On VRFs, my uncertain comments to consider at your leisure: >> >> >> >> Is it fair to say VRFs are relatively new? If so, then maybe a little >> more caution is needed about their use. It seems a tad hasty that it is >> being used already. >> >> >> >> To me, it seems that VRFs are basically signatures, with an extra >> feature. My concern is that this extra feature might get overused, befo= re >> it is thoroughly reviewed. >> >> >> >> It is unsurprising to me that random oracle model proof can prove the >> output of a hash to be random. My intuitive concern is that at least >> informally, this is kind of circular. Hashes often have some >> non-random-ish properties that might affect the extra security (over >> signatures) that VRFs are aiming for. I guess I would much prefer a pro= of >> saying if the hash has (well-studied) properties XYZ, then your >> construction are VRFs. (Maybe you have this already? If so, then tell = me >> so.) >> >> >> >> Since, VRFs require sending the =E2=80=9Cproofs=E2=80=9D on the wire, I = find it hard to >> see how it could be used to prevent dictionary attacks. I assume that y= ou >> are saying the proofs must be encrypted when one needs to avoid dictiona= ry >> models? I suppose all the details are there in I-D and papers, but for >> now, I am confused about the threat model (which parties have keys, etc.= , >> if they require a secure channel and mutual trust, why just use plain ol= d >> hash,=E2=80=A6). To resist dictionary attacks, were already have PAKEs a= nd >> PBHashing. Now this? >> >> >> >> Finally, on a bikeshed-coloring note, I object to the name =E2=80=9Cveri= fiable >> random function=E2=80=9D, on several grounds. >> >> >> >> 1. It is not a function. It is at least four functions, keygen, >> sign, verify, and hashify. >> 2. If you make it into a keyed function F_sk(m), as in >> prooftohash(sign_sk(m)), it is not verifiable. >> 3. Verification requires the intermediate proof, which is certainly >> not even pseudorandom (it is easy to distinguish valid signatures fro= m >> random). >> 4. It is pseudorandom, not random. (The keys are random, but many >> crypto has keys, without having =E2=80=9Crandom=E2=80=9D in its name:= encryption, MAC, >> signatures, key exchange, =E2=80=A6, they also don=E2=80=99t verifiab= le or random in their >> names either.) >> 5. The similar phrase =E2=80=9Cverifiably random=E2=80=9D, albeit as = a misnomer, has >> past precedents, see NIST P-256 and Brainpool, etc. When I see VRF, = I >> think a function, that aims to VR in that sense, and great, now we ca= n >> improve on Brainpool, etc. >> 6. =E2=80=9CRandom function=E2=80=9D should be reserved for the ideal= random mapping >> concept, for example, as studied by Flajolet-Odlyzko (ok they only st= udied >> the case of equal size domain and range). The random oracle model, i= s the >> idea of approximating this ideal, etc. An actual approximation shoul= d not >> be name as the ideal (sorry, I=E2=80=99m kind of repeating my point 4= ). >> >> >> >> Please forgive the fact that my comments above are not very constructive >> (or if the tone is wrong). This is a new topic for me, so I am reluctan= t >> too many suggestions. Nonetheless, I suggest (0) waiting a little, (1) = a >> non-random-oracle security proof (if you don=E2=80=99t have it yet), (2)= re-naming >> the scheme to something like re-hashable (or digestible) signatures (and >> re-name the various parts, i.e. proof -> signature, etc.). >> >> >> >> Best regards, >> >> >> >> Dan >> >> >> >> >> >> *From:* Cfrg [mailto:cfrg-bounces@irtf.org] *On Behalf Of *Sharon >> Goldberg >> *Sent:* Wednesday, July 12, 2017 5:42 AM >> *To:* cfrg@irtf.org >> *Cc:* jan@ns1.com; Dimitrios Papadopoulos ; Leonid >> Reyzin >> *Subject:* [Cfrg] draft-goldbe-vrf: Verifiable Random Functions >> >> >> >> Dear CFRG, >> >> I'm presenting at next week's meeting on Verifiable Random Functions. A >> VRF is the public-key version of keyed cryptographic hash. Only the hold= er >> of the VRF secret key can compute the hash, but anyone with the public k= ey >> can verify it. VRFs can be used to prevent dictionary attacks on >> hash-based data structures, and have applications to key transparency >> (CONIKS), DNSSEC (NSEC5), and cryptocurrencies (Algorand). >> >> In advance of the meeting, please see: >> >> 1) Our substantially updated -01 draft: >> https://datatracker.ietf.org/doc/draft-goldbe-vrf/ >> >> 2) Our project page, with links to various VRF implementations: >> https://www.cs.bu.edu/~goldbe/projects/vrf >> >> Comments welcome. Thanks, >> >> Sharon >> >> -- >> Sharon Goldberg >> Computer Science, Boston University >> http://www.cs.bu.edu/~goldbe >> > > > > -- > --- > Sharon Goldberg > Computer Science, Boston University > http://www.cs.bu.edu/~goldbe > > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > https://www.irtf.org/mailman/listinfo/cfrg > > --001a114b0cda675212055536cc3a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello,
A couple of questions:
1. It seems th= at one of the properties that you are interested that the VRF will have is = determinism. On the other hand, the EC-VRF value is dependent on the choice= of some random number k. How are these two facts compatible? Am I missing = something?
2. The value c calculated in EC-VRF is only 128 bits l= ong for Ed25519. In normal usage of Ed25519 the signature uses the full len= gth of the hash output. Doesn't this expose the signature to collision = attacks?

Thomas G.

On Sun, Jul 23, 2017 at 6:10 AM, Shar= on Goldberg <sharon.goldbe@gmail.com> wrote:
H= i Dan,

Thank you for your comments. Indeed, VRFs have been around since= 1999. They are really "verifiable PRFs" but the name is by now s= tandard in the crypto literature, and changing it will cause more confusion= than keeping it.

In terms of the VRF's security properties, there = are three: =C2=A0uniqueness, collision resistance, and pseudorandomness. Th= ese are defined in our draft (https://tools.ietf.org/html/draft-goldbe-vrf-01#section-3<= span style=3D"font-size:12.8px">).=C2=A0

How VRFs prevent d= ictionary attacks: a public hash is subject to a dictionary attack because,= given the output, an adversary can evaluate the hash on different inputs a= nd see what hits the outputs. In a VRF, the adversary can't evaluate th= e hash on different inputs.=C2=A0

=
You say it's not surprising that = "random oracle model proof can prove the output of a hash to be random= ". But actually, the output of a hash is NOT random if the input and t= he hash function are known. This is because the output of a hash is determi= nistic (every input maps to a unique output). That's exactly what enabl= es dictionary attacks. This is in contrast to a VRF, where the output is (p= seudo)random even given knowledge of the input. Only once the VRF proof is = given, does the VRF output stop looking random. Note that random oracles ar= e not essential for VRFs, and non-random-oracles constructions exist (but a= re less efficient than what we propose to standardize).

As far as use c= ases, here are a few:=C2=A0

=
In the NSEC5 use case for DNSSEC, you have = sensitive data (domain names) and you sign consecutive pairs of hashes of d= omain names in order to be able to prove absence of a name. If you just use= standard hashing, whenever signed hash values are disclosed, your sensitiv= e data is subject to dictionary attacks. VRFs solve that problem, and sensi= tive names don't have to be disclosed at all. More details are in=C2=A0= https://= eprint.iacr.org/2017/099.pdf
=
In CONIKS (also Google Key Transp= arency, Signal secure messaging, Yahoo! Coname) you also have some sensitiv= e data (user names) that are put into a Merkle-like authenticated data stru= cture. If you just use standard hashing, whenever hash values are disclosed= , sensitive data is subject to dictionary attacks. If you use VRFs, sensiti= ve data again can be disclosed only on an as-needed basis. More details are= in =C2=A0https://eprint.iacr.org/2014/1004.pdf.

In a cryptocurrency = use case, you wish perform a coin flip that is deterministic and provably c= orrect, but cannot be done by just anyone.=C2=A0 More details are in=C2=A0<= a href=3D"https://people.csail.mit.edu/nickolai/papers/gilad-algorand-eprin= t.pdf" target=3D"_blank">https://people.csail.mit.edu/nickolai/papers/= gilad-algorand-eprint.pdf=C2=A0and possibly other cryptocurrency p= apers.

Bryan Ford mentioned an additional usecase at the mic on Tuesday= : distributed password protection protocols

Many of these use case are = already putting VRFs into production use (esp. the CONIKS one).=C2=A0 You c= an see a list of the various implementations we have found in the "imp= lementation status" section of our draft.=C2=A0 One of the reasons we = think this spec is so important is that we found flaws in several of the im= plementations that can be used to trivially break uniqueness. =C2=A0(See eg= :=C2=A0https://github.com/google/keytransparency/issues/567)


On Fri, Jul 21, 2017 at 7:32 = PM, Dan Brown <danibrown@blackberry.com> wrote:
Answering myself below: VRFs have been around since 1999, so are not so new= . =C2=A0=E2=80=8EStill don't like the name, and still have trouble seei= ng the value.

From: Dan Brown
Sent: Tuesday, July 18, 2017 2:29 PM
To: Sharon Goldberg; cfrg@irtf.org
Cc: jan@ns1.co= m; Leonid Reyzin; Dimitrios Papadopoulos
Subject: Re: [Cfrg] draft-goldbe-vrf: Verifiable Random Functio= ns

Hi Sharon and CFRG,

=C2=A0

On VRFs, my uncertain comments to consider at your leisure:

=C2=A0

Is it fair to say VRFs are relatively new?=C2=A0 If so, then mayb= e a little more caution is needed about their use.=C2=A0 It seems a tad has= ty that it is being used already.

=C2=A0

To me, it seems that VRFs are basically signatures, with an extra= feature.=C2=A0 My concern is that this extra feature might get overused, b= efore it is thoroughly reviewed.=C2=A0

=C2=A0

It is unsurprising to me that random oracle model proof can prove= the output of a hash to be random.=C2=A0 My intuitive concern is that at l= east informally, this is kind of circular.=C2=A0 Hashes often have some non-random-ish properties that might affect the ext= ra security (over signatures) that VRFs are aiming for.=C2=A0 I guess I wou= ld much prefer a proof saying if the hash has (well-studied) properties XYZ= , then your construction are VRFs.=C2=A0 (Maybe you have this already?=C2=A0 If so, then tell me so.)

=C2=A0

Since, VRFs require sending the =E2=80=9Cproofs=E2=80=9D on the w= ire, I find it hard to see how it could be used to prevent dictionary attac= ks.=C2=A0 I assume that you are saying the proofs must be encrypted when one needs to avoid dictionary models?=C2=A0 I suppose al= l the details are there in I-D and papers, but for now, I am confused about= the threat model (which parties have keys, etc., if they require a secure = channel and mutual trust, why just use plain old hash,=E2=80=A6). To resist dictionary attacks, were already have= PAKEs and PBHashing.=C2=A0 Now this?

=C2=A0

Finally, on a bikeshed-coloring note, I object to the name =E2=80= =9Cverifiable random function=E2=80=9D, on several grounds.

=C2=A0

  1. It is not a function.=C2=A0 It is at= least four functions, keygen, sign, verify, and hashify.
  2. If you make it into a keyed function F_sk(= m), as in prooftohash(sign_sk(m)), it is not verifiable.=C2=A0
  3. Verification requires th= e intermediate proof, which is certainly not even pseudorandom (it is easy = to distinguish valid signatures from random).
  4. It is pseudorandom, not random.=C2=A0 (The keys are ra= ndom, but many crypto has keys, without having =E2=80=9Crandom=E2=80=9D in = its name: encryption, MAC, signatures, key exchange, =E2=80=A6, they also don=E2=80=99t verifiable or random in t= heir names either.)
  5. The s= imilar phrase =E2=80=9Cverifiably random=E2=80=9D, albeit as a misnomer, ha= s past precedents, see NIST P-256 and Brainpool, etc.=C2=A0 When I see VRF,= I think a function, that aims to VR in that sense, and great, now we can improve o= n Brainpool, etc.
  6. =E2=80= =9CRandom function=E2=80=9D should be reserved for the ideal random mapping= concept, for example, as studied by Flajolet-Odlyzko (ok they only studied the case of equal size domain and range).=C2=A0 The random oracle model, i= s the idea of approximating this ideal, etc.=C2=A0 An actual approximation = should not be name as the ideal (sorry, I=E2=80=99m kind of repeating my po= int 4).

=C2=A0

Please forgive the fact that my comments above are not very const= ructive (or if the tone is wrong).=C2=A0 This is a new topic for me, so I a= m reluctant too many suggestions.=C2=A0 Nonetheless, I suggest (0) waiting a little, (1) a non-random-oracle security proof (if= you don=E2=80=99t have it yet), (2) re-naming the scheme to something like= re-hashable (or digestible) signatures (and re-name the various parts, i.e= . proof -> signature, etc.).

=C2=A0

Best regards,

=C2=A0

Dan

=C2=A0

=C2=A0

From: Cfrg [mailto:cfrg-bounces@irtf.org] On Behalf Of Sharon Goldberg
Sent: Wednesday, July 12, 2017 5:42 AM
To: cfrg@irtf.org=
Cc: jan@ns1.com= ; Dimitrios Papadopoulos <dipapado@umd.edu>; Leonid Reyzin <reyzin@cs.bu.edu>
Subject: [Cfrg] draft-goldbe-vrf: Verifiable Random Functions=

=C2=A0

Dear CFRG,

I'm presenting at next week's meeting on Verifiable Random Function= s. A VRF is the public-key version of keyed cryptographic hash. Only the ho= lder of the VRF secret key can compute the hash, but anyone with the public= key can verify it.=C2=A0 VRFs can be used to prevent dictionary attacks on hash-based data structures, and have applica= tions to key transparency (CONIKS), DNSSEC (NSEC5), and cryptocurrencies (A= lgorand).

In advance of the meeting, please see:

1) Our substantially updated -01 draft:
https://datatracker.ietf.org/doc/draft-goldbe-vrf/

2) Our project page, with links to various VRF implementations:
ht= tps://www.cs.bu.edu/~goldbe/projects/vrf

Comments welcome.=C2=A0 Thanks,

Sharon

--
Sharon Goldberg
Computer Science, Boston University
http://www.cs.bu= .edu/~goldbe




--
=
-= --
Sharon Goldberg
Computer Science, Boston Universi= ty
http://www= .cs.bu.edu/~goldbe

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


--001a114b0cda675212055536cc3a-- From nobody Wed Jul 26 04:42:58 2017 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 F10CE131FFB for ; Wed, 26 Jul 2017 04:42:56 -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 VYshFKKrnkPa for ; Wed, 26 Jul 2017 04:42:53 -0700 (PDT) Received: from mail-io0-x235.google.com (mail-io0-x235.google.com [IPv6:2607:f8b0:4001: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 454BC132006 for ; Wed, 26 Jul 2017 04:42:53 -0700 (PDT) Received: by mail-io0-x235.google.com with SMTP id m88so57929194iod.2 for ; Wed, 26 Jul 2017 04:42:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=wKuos3xs8sP15YWadbD1gSVAX6cwcMDB6a99GeWlMfA=; b=J5hXqGNTSjDzkUY7ZwCUByAHZKHhqvkXeBSWN2fN3jEUe/NnuPzH6AWrQFhWNQCBRn XfRcx+vBG6lsRtEWXHxTJtbMFoor3giiOZc2ScTuGDbwlGUumg/uSk1KRjI2Ljhkw4bt TdLW4MsI90E2QAF1E/hJ85dcXQpUhLxYnCdTMafI9fX1yaCAHZBoaPbIaDROhRiRbk1I WdS+q2U1kZEhEz2b+tO/QhQTTXIxlnVBPkFcOibY1wZgHK4RPdeNxbOeQQPOac8BQ6U2 bd+9Dt1/JDiBh7OnM9ME7finzH8liWdNfk6i3Mp12gq/16YK/t0HZOIiC+H/CltPOrph HqeA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=wKuos3xs8sP15YWadbD1gSVAX6cwcMDB6a99GeWlMfA=; b=tJ3g6+ubPznAtWI0gPZ6FTwPMWAKbGYL+twXIFSXVTdQvvCnXvKg4qfWEv2WXrdo8V /ML3xpegsW8bvmW3uwfwbKdS2Tz+mD68RgdzmWndVy7lm9oBQ2nCgOjNLZEp/RTAPwQO 8ILiqKny9Sa+JenMNYfultq/P4HnL8GS7drhJFHhFvFdvENGeA3BHHS6hSAWDZHgzmv2 SBqZ+DzLDiMAjDFGduzo+Z7A0BQQXNBNMRaQkoHNUnW1BjO1gyAh0aJJKXQrqk4mfB9M 0Zhcv7gtGSmQl/5KrPXtYvhloQA7qzAtdhqK7k5wBdu9QZ9yAe8kEaHrXDCwTfp6RBAz 3/bQ== X-Gm-Message-State: AIVw110krVIq23jBGmGCORlCHXv83plkmEaLIhR3c+Yi067anJ7DFFv+ 4ARNN0T5gp2T/LPB3yrMQBIVbCOhZA== X-Received: by 10.107.131.81 with SMTP id f78mr622260iod.141.1501069372517; Wed, 26 Jul 2017 04:42:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.39.83 with HTTP; Wed, 26 Jul 2017 04:42:11 -0700 (PDT) In-Reply-To: References: <810C31990B57ED40B2062BA10D43FBF501B63B22@XMB116CNC.rim.net> <20170721163204.8573013.1016.15939@blackberry.com> From: Sharon Goldberg Date: Wed, 26 Jul 2017 14:42:11 +0300 Message-ID: To: Thomas Garcia Cc: Dan Brown , "jan@ns1.com" , "cfrg@irtf.org" , Dimitrios Papadopoulos , Leonid Reyzin Content-Type: multipart/alternative; boundary="001a113ecb70bb7422055536f20c" Archived-At: Subject: Re: [Cfrg] draft-goldbe-vrf: Verifiable Random Functions X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jul 2017 11:42:57 -0000 --001a113ecb70bb7422055536f20c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Thomas, 1. It seems that one of the properties that you are interested that the VRF > will have is determinism. On the other hand, the EC-VRF value is dependen= t > on the choice of some random number k. How are these two facts compatible= ? > Am I missing something? > We require determinism from the VRF hash output, which is obtained from the VRF proof via the "proof2hash" function. The EC-VRF proof has 3 values: gamma, c, s Values c and s depends on the choice of random number k But value gamma does not depend on k. We get determinism because the VRF hash output (derived using "proof2hash") depends only on gamma, but not on c and s. Slide 28 from my CFRG presentations gives a pictorial explanation of this: http://www.cs.bu.edu/~goldbe/papers/VRF_ietf99_print.pdf 2. The value c calculated in EC-VRF is only 128 bits long for Ed25519. In > normal usage of Ed25519 the signature uses the full length of the hash > output. Doesn't this expose the signature to collision attacks? > > No. We worked this out in our proofs of security. Section B.2.1 of this paper explains why this works. https://eprint.iacr.org/2017/099.pdf Thanks, Sharon > Thank you for your comments. Indeed, VRFs have been around since 1999. >> They are really "verifiable PRFs" but the name is by now standard in the >> crypto literature, and changing it will cause more confusion than keepin= g >> it. >> >> In terms of the VRF's security properties, there are three: uniqueness, >> collision resistance, and pseudorandomness. These are defined in our dra= ft ( >> https://tools.ietf.org/html/draft-goldbe-vrf-01#section-3). >> >> How VRFs prevent dictionary attacks: a public hash is subject to a >> dictionary attack because, given the output, an adversary can evaluate t= he >> hash on different inputs and see what hits the outputs. In a VRF, the >> adversary can't evaluate the hash on different inputs. >> >> You say it's not surprising that "random oracle model proof can prove th= e >> output of a hash to be random". But actually, the output of a hash is NO= T >> random if the input and the hash function are known. This is because the >> output of a hash is deterministic (every input maps to a unique output). >> That's exactly what enables dictionary attacks. This is in contrast to a >> VRF, where the output is (pseudo)random even given knowledge of the inpu= t. >> Only once the VRF proof is given, does the VRF output stop looking rando= m. >> Note that random oracles are not essential for VRFs, and non-random-orac= les >> constructions exist (but are less efficient than what we propose to >> standardize). >> >> As far as use cases, here are a few: >> >> In the NSEC5 use case for DNSSEC, you have sensitive data (domain names) >> and you sign consecutive pairs of hashes of domain names in order to be >> able to prove absence of a name. If you just use standard hashing, whene= ver >> signed hash values are disclosed, your sensitive data is subject to >> dictionary attacks. VRFs solve that problem, and sensitive names don't h= ave >> to be disclosed at all. More details are in https://eprint.iacr.org/201 >> 7/099.pdf >> >> In CONIKS (also Google Key Transparency, Signal secure messaging, Yahoo! >> Coname) you also have some sensitive data (user names) that are put into= a >> Merkle-like authenticated data structure. If you just use standard hashi= ng, >> whenever hash values are disclosed, sensitive data is subject to diction= ary >> attacks. If you use VRFs, sensitive data again can be disclosed only on = an >> as-needed basis. More details are in https://eprint.iacr.org/2014/ >> 1004.pdf. >> >> In a cryptocurrency use case, you wish perform a coin flip that is >> deterministic and provably correct, but cannot be done by just anyone. >> More details are in https://people.csail.mit.ed >> u/nickolai/papers/gilad-algorand-eprint.pdf and possibly other >> cryptocurrency papers. >> >> Bryan Ford mentioned an additional usecase at the mic on Tuesday: >> distributed password protection protocols >> >> Many of these use case are already putting VRFs into production use (esp= . >> the CONIKS one). You can see a list of the various implementations we h= ave >> found in the "implementation status" section of our draft. One of the >> reasons we think this spec is so important is that we found flaws in >> several of the implementations that can be used to trivially break >> uniqueness. (See eg: https://github.com/google/ >> keytransparency/issues/567) >> >> Thanks, >> Sharon >> >> On Fri, Jul 21, 2017 at 7:32 PM, Dan Brown >> wrote: >> >>> Answering myself below: VRFs have been around since 1999, so are not so >>> new. =E2=80=8EStill don't like the name, and still have trouble seeing= the value. >>> >>> *From: *Dan Brown >>> *Sent: *Tuesday, July 18, 2017 2:29 PM >>> *To: *Sharon Goldberg; cfrg@irtf.org >>> *Cc: *jan@ns1.com; Leonid Reyzin; Dimitrios Papadopoulos >>> *Subject: *Re: [Cfrg] draft-goldbe-vrf: Verifiable Random Functions >>> >>> Hi Sharon and CFRG, >>> >>> >>> >>> On VRFs, my uncertain comments to consider at your leisure: >>> >>> >>> >>> Is it fair to say VRFs are relatively new? If so, then maybe a little >>> more caution is needed about their use. It seems a tad hasty that it i= s >>> being used already. >>> >>> >>> >>> To me, it seems that VRFs are basically signatures, with an extra >>> feature. My concern is that this extra feature might get overused, bef= ore >>> it is thoroughly reviewed. >>> >>> >>> >>> It is unsurprising to me that random oracle model proof can prove the >>> output of a hash to be random. My intuitive concern is that at least >>> informally, this is kind of circular. Hashes often have some >>> non-random-ish properties that might affect the extra security (over >>> signatures) that VRFs are aiming for. I guess I would much prefer a pr= oof >>> saying if the hash has (well-studied) properties XYZ, then your >>> construction are VRFs. (Maybe you have this already? If so, then tell= me >>> so.) >>> >>> >>> >>> Since, VRFs require sending the =E2=80=9Cproofs=E2=80=9D on the wire, I= find it hard to >>> see how it could be used to prevent dictionary attacks. I assume that = you >>> are saying the proofs must be encrypted when one needs to avoid diction= ary >>> models? I suppose all the details are there in I-D and papers, but for >>> now, I am confused about the threat model (which parties have keys, etc= ., >>> if they require a secure channel and mutual trust, why just use plain o= ld >>> hash,=E2=80=A6). To resist dictionary attacks, were already have PAKEs = and >>> PBHashing. Now this? >>> >>> >>> >>> Finally, on a bikeshed-coloring note, I object to the name =E2=80=9Cver= ifiable >>> random function=E2=80=9D, on several grounds. >>> >>> >>> >>> 1. It is not a function. It is at least four functions, keygen, >>> sign, verify, and hashify. >>> 2. If you make it into a keyed function F_sk(m), as in >>> prooftohash(sign_sk(m)), it is not verifiable. >>> 3. Verification requires the intermediate proof, which is certainly >>> not even pseudorandom (it is easy to distinguish valid signatures fr= om >>> random). >>> 4. It is pseudorandom, not random. (The keys are random, but many >>> crypto has keys, without having =E2=80=9Crandom=E2=80=9D in its name= : encryption, MAC, >>> signatures, key exchange, =E2=80=A6, they also don=E2=80=99t verifia= ble or random in their >>> names either.) >>> 5. The similar phrase =E2=80=9Cverifiably random=E2=80=9D, albeit as= a misnomer, has >>> past precedents, see NIST P-256 and Brainpool, etc. When I see VRF,= I >>> think a function, that aims to VR in that sense, and great, now we c= an >>> improve on Brainpool, etc. >>> 6. =E2=80=9CRandom function=E2=80=9D should be reserved for the idea= l random mapping >>> concept, for example, as studied by Flajolet-Odlyzko (ok they only s= tudied >>> the case of equal size domain and range). The random oracle model, = is the >>> idea of approximating this ideal, etc. An actual approximation shou= ld not >>> be name as the ideal (sorry, I=E2=80=99m kind of repeating my point = 4). >>> >>> >>> >>> Please forgive the fact that my comments above are not very constructiv= e >>> (or if the tone is wrong). This is a new topic for me, so I am relucta= nt >>> too many suggestions. Nonetheless, I suggest (0) waiting a little, (1)= a >>> non-random-oracle security proof (if you don=E2=80=99t have it yet), (2= ) re-naming >>> the scheme to something like re-hashable (or digestible) signatures (an= d >>> re-name the various parts, i.e. proof -> signature, etc.). >>> >>> >>> >>> Best regards, >>> >>> >>> >>> Dan >>> >>> >>> >>> >>> >>> *From:* Cfrg [mailto:cfrg-bounces@irtf.org] *On Behalf Of *Sharon >>> Goldberg >>> *Sent:* Wednesday, July 12, 2017 5:42 AM >>> *To:* cfrg@irtf.org >>> *Cc:* jan@ns1.com; Dimitrios Papadopoulos ; Leonid >>> Reyzin >>> *Subject:* [Cfrg] draft-goldbe-vrf: Verifiable Random Functions >>> >>> >>> >>> Dear CFRG, >>> >>> I'm presenting at next week's meeting on Verifiable Random Functions. A >>> VRF is the public-key version of keyed cryptographic hash. Only the hol= der >>> of the VRF secret key can compute the hash, but anyone with the public = key >>> can verify it. VRFs can be used to prevent dictionary attacks on >>> hash-based data structures, and have applications to key transparency >>> (CONIKS), DNSSEC (NSEC5), and cryptocurrencies (Algorand). >>> >>> In advance of the meeting, please see: >>> >>> 1) Our substantially updated -01 draft: >>> https://datatracker.ietf.org/doc/draft-goldbe-vrf/ >>> >>> 2) Our project page, with links to various VRF implementations: >>> https://www.cs.bu.edu/~goldbe/projects/vrf >>> >>> Comments welcome. Thanks, >>> >>> Sharon >>> >>> -- >>> Sharon Goldberg >>> Computer Science, Boston University >>> http://www.cs.bu.edu/~goldbe >>> >> >> >> >> -- >> --- >> Sharon Goldberg >> Computer Science, Boston University >> http://www.cs.bu.edu/~goldbe >> >> _______________________________________________ >> Cfrg mailing list >> Cfrg@irtf.org >> https://www.irtf.org/mailman/listinfo/cfrg >> >> > --=20 --- Sharon Goldberg Computer Science, Boston University http://www.cs.bu.edu/~goldbe --001a113ecb70bb7422055536f20c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Thomas,

1. It seems that one of the properties that you are inter= ested that the VRF will have is determinism. On the other hand, the EC-VRF = value is dependent on the choice of some random number k. How are these two= facts compatible? Am I missing something?
We require determinism from the VRF hash output, which is obtai= ned from the VRF proof via the "proof2hash" function.
<= br>
The EC-VRF proof has 3 values: gamma, c, s
Values c= and s depends on the choice of random number k
But value gamma d= oes not depend on k.

We get determinism because th= e VRF hash output (derived using "proof2hash") depends only on ga= mma, but not on c and s.
=C2=A0
Slide 28 from my CFRG p= resentations gives a pictorial explanation of this:

2. The value= c calculated in EC-VRF is only 128 bits long for Ed25519. In normal usage = of Ed25519 the signature uses the full length of the hash output. Doesn'= ;t this expose the signature to collision attacks?

No. We worked this out in our proofs of security.=C2=A0= Section B.2.1 of this paper explains why this works.

<= div>https://eprint.iacr.or= g/2017/099.pdf

Thanks,
Sharon

=C2=A0
Thank you for your comments. Indeed, VRFs have been around since 1999= . They are really "verifiable PRFs" but the name is by now standa= rd in the crypto literature, and changing it will cause more confusion than= keeping it.

In terms of the VRF's security properties, there are t= hree: =C2=A0uniqueness, collision resistance, and pseudorandomness. These a= re defined in our draft (http= s://tools.ietf.org/html/draft-goldbe-vrf-01#section-3).=C2=A0

How VRFs prevent dictio= nary attacks: a public hash is subject to a dictionary attack because, give= n the output, an adversary can evaluate the hash on different inputs and se= e what hits the outputs. In a VRF, the adversary can't evaluate the has= h on different inputs.=C2=A0

You say it's not surprising that "= ;random oracle model proof can prove the output of a hash to be random"= ;. But actually, the output of a hash is NOT random if the input and the ha= sh function are known. This is because the output of a hash is deterministi= c (every input maps to a unique output). That's exactly what enables di= ctionary attacks. This is in contrast to a VRF, where the output is (pseudo= )random even given knowledge of the input. Only once the VRF proof is given= , does the VRF output stop looking random. Note that random oracles are not= essential for VRFs, and non-random-oracles constructions exist (but are le= ss efficient than what we propose to standardize).

As far as use cases,= here are a few:=C2=A0

In the NSEC5 use case for DNSSEC, you have sensi= tive data (domain names) and you sign consecutive pairs of hashes of domain= names in order to be able to prove absence of a name. If you just use stan= dard hashing, whenever signed hash values are disclosed, your sensitive dat= a is subject to dictionary attacks. VRFs solve that problem, and sensitive = names don't have to be disclosed at all. More details are in=C2=A0https://eprin= t.iacr.org/2017/099.pdf

<= /div>
In CONIKS (also Google Key Transparenc= y, Signal secure messaging, Yahoo! Coname) you also have some sensitive dat= a (user names) that are put into a Merkle-like authenticated data structure= . If you just use standard hashing, whenever hash values are disclosed, sen= sitive data is subject to dictionary attacks. If you use VRFs, sensitive da= ta again can be disclosed only on an as-needed basis. More details are in = =C2=A0h= ttps://eprint.iacr.org/2014/1004.pdf.

In a cryptocurrency use = case, you wish perform a coin flip that is deterministic and provably corre= ct, but cannot be done by just anyone.=C2=A0 More details are in=C2=A0https://people.csail.mit.edu/nickolai/papers/gila= d-algorand-eprint.pdf=C2=A0and possibly other cryptocurrency paper= s.

Bryan Ford mentioned an additional usecase at the mic on Tuesday: di= stributed password protection protocols

Many of these use case are alre= ady putting VRFs into production use (esp. the CONIKS one).=C2=A0 You can s= ee a list of the various implementations we have found in the "impleme= ntation status" section of our draft.=C2=A0 One of the reasons we thin= k this spec is so important is that we found flaws in several of the implem= entations that can be used to trivially break uniqueness. =C2=A0(See eg:=C2= =A0https://github.com/google/keytransparency/issues/567)<= /div>

Thanks,
Sharon=C2=A0

On Fri= , Jul 21, 2017 at 7:32 PM, Dan Brown <danibrown@blackberry.com&= gt; wrote:
Answering myself below: VRFs have been around since 1999, so are not so new= . =C2=A0=E2=80=8EStill don't like the name, and still have trouble seei= ng the value.

From: Dan Brown
Sent: Tuesday, July 18, 2017 2:29 PM
To: Sharon Goldberg; cfrg@irtf.org
Cc: jan@ns1.co= m; Leonid Reyzin; Dimitrios Papadopoulos
Subject: Re: [Cfrg] draft-goldbe-vrf: Verifiable Random Functio= ns

Hi Sharon and CFRG,

=C2=A0

On VRFs, my uncertain comments to consider at your leisure:

=C2=A0

Is it fair to say VRFs are relatively new?=C2=A0 If so, then mayb= e a little more caution is needed about their use.=C2=A0 It seems a tad has= ty that it is being used already.

=C2=A0

To me, it seems that VRFs are basically signatures, with an extra= feature.=C2=A0 My concern is that this extra feature might get overused, b= efore it is thoroughly reviewed.=C2=A0

=C2=A0

It is unsurprising to me that random oracle model proof can prove= the output of a hash to be random.=C2=A0 My intuitive concern is that at l= east informally, this is kind of circular.=C2=A0 Hashes often have some non-random-ish properties that might affect the ext= ra security (over signatures) that VRFs are aiming for.=C2=A0 I guess I wou= ld much prefer a proof saying if the hash has (well-studied) properties XYZ= , then your construction are VRFs.=C2=A0 (Maybe you have this already?=C2=A0 If so, then tell me so.)

=C2=A0

Since, VRFs require sending the =E2=80=9Cproofs=E2=80=9D on the w= ire, I find it hard to see how it could be used to prevent dictionary attac= ks.=C2=A0 I assume that you are saying the proofs must be encrypted when one needs to avoid dictionary models?=C2=A0 I suppose al= l the details are there in I-D and papers, but for now, I am confused about= the threat model (which parties have keys, etc., if they require a secure = channel and mutual trust, why just use plain old hash,=E2=80=A6). To resist dictionary attacks, were already have= PAKEs and PBHashing.=C2=A0 Now this?

=C2=A0

Finally, on a bikeshed-coloring note, I object to the name =E2=80= =9Cverifiable random function=E2=80=9D, on several grounds.

=C2=A0

  1. It is not= a function.=C2=A0 It is at least four functions, keygen, sign, verify, and= hashify.
  2. If you make it into a keyed function F_sk(m), as in prooftohash= (sign_sk(m)), it is not verifiable.=C2=A0
  3. Verification requires the intermediate proof, which is certainly not eve= n pseudorandom (it is easy to distinguish valid signatures from random).
  4. = It is pseudorandom, not random.=C2=A0 (The keys are random, but many crypto= has keys, without having =E2=80=9Crandom=E2=80=9D in its name: encryption,= MAC, signatures, key exchange, =E2=80=A6, they also don=E2=80=99t verifiable or random in t= heir names either.)
  5. The similar phrase =E2=80=9Cverifiably random=E2=80= =9D, albeit as a misnomer, has past precedents, see NIST P-256 and Brainpoo= l, etc.=C2=A0 When I see VRF, I think a function, that aims to VR in that sense, and great, now we can improve o= n Brainpool, etc.
  6. =E2=80=9CRandom function=E2=80=9D should be reserved fo= r the ideal random mapping concept, for example, as studied by Flajolet-Odl= yzko (ok they only studied the case of equal size domain and range).=C2=A0 The random oracle model, i= s the idea of approximating this ideal, etc.=C2=A0 An actual approximation = should not be name as the ideal (sorry, I=E2=80=99m kind of repeating my po= int 4).

=C2=A0

Please forgive the fact that my comments above are not very const= ructive (or if the tone is wrong).=C2=A0 This is a new topic for me, so I a= m reluctant too many suggestions.=C2=A0 Nonetheless, I suggest (0) waiting a little, (1) a non-random-oracle security proof (if= you don=E2=80=99t have it yet), (2) re-naming the scheme to something like= re-hashable (or digestible) signatures (and re-name the various parts, i.e= . proof -> signature, etc.).

=C2=A0

Best regards,

=C2=A0

Dan

=C2=A0

=C2=A0

From: Cfrg [mailto:cfrg-bounces@irtf.org] On Behalf Of Sharon Goldberg
Sent: Wednesday, July 12, 2017 5:42 AM
To: cfrg@irtf.org=
Cc: jan@ns1.com= ; Dimitrios Papadopoulos <dipapado@umd.edu>; Leonid Reyzin <reyzin@cs.bu.edu>
Subject: [Cfrg] draft-goldbe-vrf: Verifiable Random Functions=

=C2=A0

Dear CFRG,

I'm presenting at next week's meeting on Verifiable Random Function= s. A VRF is the public-key version of keyed cryptographic hash. Only the ho= lder of the VRF secret key can compute the hash, but anyone with the public= key can verify it.=C2=A0 VRFs can be used to prevent dictionary attacks on hash-based data structures, and have applica= tions to key transparency (CONIKS), DNSSEC (NSEC5), and cryptocurrencies (A= lgorand).

In advance of the meeting, please see:

1) Our substantially updated -01 draft:
https://datatracker.ietf.org/doc/draft-goldbe-vrf/

2) Our project page, with links to various VRF implementations:
ht= tps://www.cs.bu.edu/~goldbe/projects/vrf

Comments welcome.=C2=A0 Thanks,

Sharon

--
Sharon Goldberg
Computer Science, Boston University
http://www.cs.bu= .edu/~goldbe




--
=
---
Sharon Goldberg
Computer Science,= Boston University
http://www.cs.bu.edu/~goldbe

_______________________________= ________________
Cfrg mailing list
Cfrg@irtf.org
https://www.irtf.org/mailman/listinfo/cfrg





--
---
Sharon Goldberg
Computer Science, Boston Uni= versity
http:= //www.cs.bu.edu/~goldbe
--001a113ecb70bb7422055536f20c-- From nobody Wed Jul 26 05:04:59 2017 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 41D9A126E3A for ; Wed, 26 Jul 2017 05:04:58 -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 kg43EQi0JaY0 for ; Wed, 26 Jul 2017 05:04:55 -0700 (PDT) Received: from mail-yw0-x22e.google.com (mail-yw0-x22e.google.com [IPv6:2607:f8b0:4002: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 66DEA131C7A for ; Wed, 26 Jul 2017 05:04:55 -0700 (PDT) Received: by mail-yw0-x22e.google.com with SMTP id u207so24569585ywc.3 for ; Wed, 26 Jul 2017 05:04:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=zf7R6IRnXtKPJXQ2AFrSLpjOZuAIOCcdcoN3Qu8L1qk=; b=SRMqGmBiCfqNefbX4O/nNcIIUJEHqdQRQfEJ3t3DiVvjHdLgykUN6Drm4PMW/NfD3m cHJEzvosZo/tYhbMmkKg8jb7QT/NSmfLIZZIdz5dXNd6xqhyT3KwGeCR9V75/7m4D1bu I2XNhm0WNeG7MXTT9afnwm5J3bLJiYRIHSvjbH5y66Js9ge6Wngh9m3idZnLqkYSOLOF bnoLQ9g7wl3YtwZZuuYpjMRCYPSrQ1/cdeXntOQQ1WhLGcBci/ctoucIee/54IIPqv1e f7GBbqgTKn0MznfUUpOjnE8wVXNdZU8CjsQdXFmPuv4cIZYIMBmaI9mUBFsrkoq+ho16 1HqA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=zf7R6IRnXtKPJXQ2AFrSLpjOZuAIOCcdcoN3Qu8L1qk=; b=a7lPP0sF4OPT1q8Oe4jhi7w9pcAaubd4HEDzqvIChC9Us4MFfqj3F3Glde4za2QS4C zmLhV9wBsAygOIFL7k9MaGqAAcXsnWCdX0PWSVb8+WsUPd8aVQmc7/CuDlpTRVqoBQBj M5OUpx/4t+6U2DpQrcOdJTTMsPBMt19tkD4sTUV22/FEwWlkLWDYqgaJA35gzMxARQZ1 HuNoJticyqIwed0Ih3AIY3NtjTZVWAlX5ordDdsryxRpLuAVTsc5mFUwaeuTFbeb0ofi ph6RWUJO8YIg68OnD18DompkQb0iDdVSxdGNGTnQqKQGql+7/Vxuh7XtPjRstrx3Qc1T 7yxQ== X-Gm-Message-State: AIVw111oVadedvDBe8qV7Er7TxE50xp65t3A1xb/NJPVP27AVj4t0zu1 KFTNiNNZXs1BGmy5JxHiFrowo9EmyTGhx+s= X-Received: by 10.37.206.9 with SMTP id x9mr563933ybe.79.1501070694224; Wed, 26 Jul 2017 05:04:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.91.7 with HTTP; Wed, 26 Jul 2017 05:04:23 -0700 (PDT) In-Reply-To: References: From: Yannick Seurin Date: Wed, 26 Jul 2017 14:04:23 +0200 Message-ID: To: cfrg@ietf.org Cc: Tetsu Iwata Content-Type: multipart/alternative; boundary="94eb2c190112831eac0555374180" Archived-At: Subject: Re: [Cfrg] Updated bounds in AES-GCM-SIV paper X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jul 2017 12:04:58 -0000 --94eb2c190112831eac0555374180 Content-Type: text/plain; charset="UTF-8" Dear CFRG, Our paper "Reconsidering the Security Bound of AES-GCM-SIV", which prompted Adam's email, is now available on ePrint: https://eprint.iacr.org/2017/708 The main contribution of this paper is an independent security analysis for AES-GCM-SIV motivated by some problems that we discovered in the security proofs presented in [1] and [2]. We also propose a different key-derivation function with similar efficiency but better security than the one currently specified. As explained by Adam, we noticed that the security claims made in [2] were overly optimistic because the PRP-PRF indistinguishability term had been neglected, whereas it was actually the dominating term of the security bound. As a consequence, the security guarantees provided by AES-GCM-SIV must be lowered compared with what was originally announced in [2], especially for long messages. We stress that our paper is based on version 20160310:063701 of [1] and version 20170223:140759 of [2]. Both [1] and [2] were updated after we sent our paper to AES-GCM-SIV's designers on July 7. We believe that the CFRG specification (especially Section 9) should be updated as well to reflect the new security analysis. Recommended usage limitations for an AEAD scheme (such as the maximal number of messages that can be encrypted with the same key) should be based on the maximal message length allowed by its specification (currently, 2^{32} 128-bit blocks). More fine-grained recommendations (such as "if the maximal message length in an application is 2^m and the maximal number of nonce repetitions is R, then the maximal number of messages that can be encrypted with the same key can be pushed to XXX") are likely to create confusion and incur implementations errors. For AES-GCM-SIV with randomly generated nonces (which has been put forward by the designers as the preferred way of generating nonces when no state can be saved by encrypting devices), this means that no more than 2^{30} messages should be encrypted with the same key, which contrasts with the recommended limit of 2^{50} given (without context) in Section 9 of the CFRG specification and in the abstract of [2]. Cheers, Tetsu and Yannick. [1] https://eprint.iacr.org/2015/102 [2] https://eprint.iacr.org/2017/168 2017-07-17 4:09 GMT+02:00 Adam Langley : > Dear CFRG, > > We would like to thank Yannick Seurin and Tetsu Iwata for alerting us > to the fact that we had erroneously assumed that one of the terms in > the security bounds of AES-GCM-SIV was negligible when, for > indistinguishability, it was not. Thus, while the security proof was > correct, the example concrete bounds were over optimistic, most > notably for very large messages. This was most evident in Fig 4. > > We have updated the paper[1] to correct this mistake and we draw the > group's attention to the revised figure four (now called Table 1). For > typical uses, thankfully, the difference is not material but for we > wish to highlight that one cannot encrypt many messages of > many-gigabytes using AES-GCM-SIV, in contrast to what the figures > previously suggested. However, even in such a case of very long > messages, the overall number of blocks encrypted safely is still > significantly higher than previous schemes. > > [1] https://eprint.iacr.org/2017/168 > > > Cheers > > AGL > > -- > Adam Langley agl@imperialviolet.org https://www.imperialviolet.org > > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > https://www.irtf.org/mailman/listinfo/cfrg > --94eb2c190112831eac0555374180 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear CFRG,

Our paper "R= econsidering the Security Bound of AES-GCM-SIV", which prompted Adam&#= 39;s email, is now available on ePrint:

The main contribution of this paper is an ind= ependent security analysis for AES-GCM-SIV motivated by some problems that = we discovered in the security proofs presented in [1] and [2]. We also prop= ose a different key-derivation function with similar efficiency but better = security than the one currently specified.=C2=A0

A= s explained by Adam, we noticed that the security claims made in [2] were o= verly optimistic because the PRP-PRF indistinguishability term had been neg= lected, whereas it was actually the dominating term of the security bound. = As a consequence, the security guarantees provided by AES-GCM-SIV must be l= owered compared with what was originally announced in [2], especially for l= ong messages.

We stress that our paper is based on= version 20160310:063701 of [1] and version 20170223:140759 of [2]. Both [1= ] and [2] were updated after we sent our paper to AES-GCM-SIV's designe= rs on July 7.

We believe that the CFRG specificati= on (especially Section 9) should be updated as well to reflect the new secu= rity analysis. Recommended usage limitations for an AEAD scheme (such as th= e maximal number of messages that can be encrypted with the same key) shoul= d be based on the maximal message length allowed by its specification (curr= ently, 2^{32} 128-bit blocks). More fine-grained recommendations (such as &= quot;if the maximal message length in an application is 2^m and the maximal= number of nonce repetitions is R, then the maximal number of messages that= can be encrypted with the same key can be pushed to XXX") are likely = to create confusion and incur implementations errors. For AES-GCM-SIV with = randomly generated nonces (which has been put forward by the designers as t= he preferred way of generating nonces when no state can be saved by encrypt= ing devices), this means that no more than 2^{30} messages should be encryp= ted with the same key, which contrasts with the recommended limit of 2^{50}= given (without context) in Section 9 of the CFRG specification and in the = abstract of [2].

Cheers,
Tetsu and Yanni= ck.


2017-07-17 4:09 GMT+02:00 Adam Langley <agl@imper= ialviolet.org>:
Dear CFRG,

We would like to thank Yannick Seurin and Tetsu Iwata for alerting us
to the fact that we had erroneously assumed that one of the terms in
the security bounds of AES-GCM-SIV was negligible when, for
indistinguishability, it was not. Thus, while the security proof was
correct, the example concrete bounds were over optimistic, most
notably for very large messages. This was most evident in Fig 4.

We have updated the paper[1] to correct this mistake and we draw the
group's attention to the revised figure four (now called Table 1). For<= br> typical uses, thankfully, the difference is not material but for we
wish to highlight that one cannot encrypt many messages of
many-gigabytes using AES-GCM-SIV, in contrast to what the figures
previously suggested. However, even in such a case of very long
messages, the overall number of blocks encrypted safely is still
significantly higher than previous schemes.

[1] https://eprint.iacr.org/2017/168


Cheers

AGL

--
Adam Langley ag= l@imperialviolet.org https://www.imperialviolet.org

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

--94eb2c190112831eac0555374180-- From nobody Wed Jul 26 08:07:47 2017 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 80CF5131D69; Mon, 24 Jul 2017 07:30:27 -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, 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 6NHrfZZ3aG-X; Mon, 24 Jul 2017 07:30:18 -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 200F3131D3D; Mon, 24 Jul 2017 07:30:17 -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 1dZeNB-0000Bv-Lb; Mon, 24 Jul 2017 16:30:13 +0200 Received: from [131.155.70.110] by sslproxy03.your-server.de with esmtpsa (TLSv1.2:DHE-RSA-AES256-SHA:256) (Exim 4.84_2) (envelope-from ) id 1dZeNB-0004sE-4D; Mon, 24 Jul 2017 16:30:13 +0200 To: Stephen Farrell , "Paterson, Kenny" , Alexey Melnikov , "irsg@irtf.org" , "cfrg@irtf.org" Cc: "draft-irtf-cfrg-xmss-hash-based-signatures@ietf.org" References: <9a878527-5ab9-5429-7c5d-4f7e4ca4e8db@isode.com> <08944dc3-9086-ed47-cc1b-54248b3dac70@cs.tcd.ie> <9e6b6146-e376-86cb-70be-0127a3e72d16@cs.tcd.ie> <6f90e485-01f4-5ad8-49ef-e51c52e01a46@cs.tcd.ie> <5e328e85-a8a1-67f1-3853-418309b04a17@huelsing.net> <27cc7000-7fd5-27dd-b8b5-9b9518a9f3ad@huelsing.net> <1785b9ed-fb53-889a-9d34-311c7ea5c762@cs.tcd.ie> From: "A. Huelsing" Message-ID: <4699f3d2-40ce-9c40-d29a-d24ecb3b6cab@huelsing.net> Date: Mon, 24 Jul 2017 16:30:10 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <1785b9ed-fb53-889a-9d34-311c7ea5c762@cs.tcd.ie> Content-Type: multipart/mixed; boundary="------------EDA0ADC751965DA00E77AF10" Content-Language: en-GB X-Authenticated-Sender: ietf@huelsing.net X-Virus-Scanned: Clear (ClamAV 0.99.2/23592/Mon Jul 24 10:18:33 2017) Archived-At: X-Mailman-Approved-At: Wed, 26 Jul 2017 08:07:38 -0700 Subject: Re: [Cfrg] [irsg] IRSG review of draft-irtf-cfrg-xmss-hash-based-signatures-08 X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jul 2017 14:30:28 -0000 This is a multi-part message in MIME format. --------------EDA0ADC751965DA00E77AF10 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Dear Stephen, we tried to make the required changes. Please have a look if you are fine with the changes (especially regarding section 5 and the reference implementation). You find our answers to your review below and the new draft version attached. Thanks again for your time, Andreas, Aziz, Denis, Joost & Stefan ################# Answers #################### possible errors: ---------------- - 3.1.2: Algorithm 2: "if ( (i + s) > w - 1 )..." seems to be missing parenthesis around the "(w-1)" to me. Without those brackets I could interpret that test to always result in false. #Done - 4.1.9: should the call to setIdx in alg 12 be after treeSig? as-is you seem to have incremented the index too soon so that when alg 11 does getIdx it'd presumably get the incremented index and cause verification failure. I think the same is true of alg 16 as well, in section 4.2.4. #Done significant comments, but likely fixable: ----------------------------------------- - section 5: there are waaaay too many options defined here. As-is, this will damage potential deployment of xmss. I would strongly suggest deleting all of the options except the minimum, that being one (and only one) set of parameters for XMSS and one for XMSS^MT. If others are needed later, those can be defined later. (Note that the damage done here includes the hours of developer time that would be wasted debating which of these choices to implement/use. Consider the case of pre-hash variants of eddsa for an ongoing example.) #### # We significantly changed section 5, please check if this # satisfies your remarks #### - section 5 (or an appendix) should contain some test vectors (including intermediate values). Without those, implementers have a much harder time of getting their code right. # Added section on reference implementation nits, near-nits and other ignorable things: ------------------------------------------- - abstract: I'd suggest s/can withstand attacks/ can withstand so-far known attacks/ # Done - 1.1: You say if used >1 time "no cryptographic security guarantees remain." It might be clearer to give some examples of consequences, e.g. that the attacker can forge new signatures or whatever. # Done - 1.1: I think you might mention that XMSS and other OTS ideas require some new crypto APIs. I'm not aware if anyone has developed proposals for such, but would be interested if someone has. # Done - 2.3, 2nd last para: you might want to say what happens with e.g. B<<2 where B=0xf0. I assume the result is 0xc0 but someone might think it's 0x3c0 or even 0xc3. # Done: Removed the left shift as it is never used for single bytes - 2.5: having the "type word" as octet 15 of a 32 byte address seems odd. Is there a reason why? (Just wondering.) # Yes: We got the space and think that it simlifies implementation if one always has to manipulate whole words (and can treat the address as uint32_t[8]) - 2.6: It seems odd to given an example where the input and output of base_w() are the same. A different example may be more useful. (More examples generally would be great.) # Done - 3.1.3: maybe note that "/" means nothing? Which I assume it does? Better might be to just say that. # Done - 3.1.5: "a maximum value of len_1 * (w - 1) * 2^8" is missing units # Done: value -> Integer value - 3.1.5: "the variable" - which one? # Done: Added explanation - 3.1.5: "For the parameter sets given in Section 5 a 32-bit unsigned integer is sufficient." Sufficient for what? # Done: Added " to hold the checksum" - 3.1.5: The ascii art at the end of p16 doesn't help much. # while the art does not contain new information, we think it's a handy reminder. Would prefer to keep it like this. - 3.1.7: The "MUST match" statement doesn't seem enforceable nor testable so I'm not sure it's a good idea to include. OTOH, I do get the idea of using 2119 terms for emphasis. # Ok, so what should we do? I agree that key handling cannot be verified. Still, it seems necessary to emphasize this. If it is just about the use of the 2119 term, how about: "but it is crucial for security that the cryptographic strength matches that of the used WOTS+ parameters."? - 3.1.7: I think it might be useful to point out any specific problems associated with using a low entropy human memorable secret (password) for the value S. No matter what you say, people will do that, so better if you can say you told them specifically about downsides of doing that. # We adressed this in a new sentence at the end of the # paragraph. - 4.1.12: I'm not sure if the MAY there is correct or not. If it means "you MAY use a different algorithm to get the same output as alg 12" then that'd be fine. If something else is meant I'm not sure what you're saying, and it'd probably be better to not even mention it. # That is exactly what it means. There are far more efficient # algorithms to compute that output (but also far more complex) - section 5 should also spell out the signature and public key sizes in bytes and ideally, if you keep multiple options, (but please don't:-) describe relative or measured timings. # Done --------------EDA0ADC751965DA00E77AF10 Content-Type: text/plain; charset=UTF-8; name="draft-irtf-cfrg-xmss-hash-based-signatures-10.txt" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="draft-irtf-cfrg-xmss-hash-based-signatures-10.txt" CgoKCkNyeXB0byBGb3J1bSBSZXNlYXJjaCBHcm91cCAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICBBLiBIdWVsc2luZwpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBUVSBFaW5kaG92ZW4KSW50ZW5kZWQgc3Rh dHVzOiBJbmZvcm1hdGlvbmFsICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEQu IEJ1dGluCkV4cGlyZXM6IEphbnVhcnkgMjUsIDIwMTggICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIFRVIERhcm1zdGFkdAogICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBTLiBHYXpkYWcKICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBn ZW51YSBHbWJICiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIEouIFJpam5ldmVsZAogICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBSYWRib3VkIFVuaXZlcnNpdHkKICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IEEuIE1vaGFpc2VuCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIFNVTlkgQnVmZmFsbwogICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEp1bHkgMjQsIDIwMTcKCgog ICAgICAgICAgICAgICAgICBYTVNTOiBFeHRlbmRlZCBIYXNoLUJhc2VkIFNpZ25hdHVyZXMK ICAgICAgICAgICAgIGRyYWZ0LWlydGYtY2ZyZy14bXNzLWhhc2gtYmFzZWQtc2lnbmF0dXJl cy0xMAoKQWJzdHJhY3QKCiAgIFRoaXMgbm90ZSBkZXNjcmliZXMgdGhlIGVYdGVuZGVkIE1l cmtsZSBTaWduYXR1cmUgU2NoZW1lIChYTVNTKSwgYQogICBoYXNoLWJhc2VkIGRpZ2l0YWwg c2lnbmF0dXJlIHN5c3RlbS4gIEl0IGZvbGxvd3MgZXhpc3RpbmcKICAgZGVzY3JpcHRpb25z IGluIHNjaWVudGlmaWMgbGl0ZXJhdHVyZS4gIFRoZSBub3RlIHNwZWNpZmllcyB0aGUgV09U UysKICAgb25lLXRpbWUgc2lnbmF0dXJlIHNjaGVtZSwgYSBzaW5nbGUtdHJlZSAoWE1TUykg YW5kIGEgbXVsdGktdHJlZQogICB2YXJpYW50IChYTVNTXk1UKSBvZiBYTVNTLiAgQm90aCB2 YXJpYW50cyB1c2UgV09UUysgYXMgYSBtYWluCiAgIGJ1aWxkaW5nIGJsb2NrLiAgWE1TUyBw cm92aWRlcyBjcnlwdG9ncmFwaGljIGRpZ2l0YWwgc2lnbmF0dXJlcwogICB3aXRob3V0IHJl bHlpbmcgb24gdGhlIGNvbmplY3R1cmVkIGhhcmRuZXNzIG9mIG1hdGhlbWF0aWNhbCBwcm9i bGVtcy4KICAgSW5zdGVhZCwgaXQgaXMgcHJvdmVuIHRoYXQgaXQgb25seSByZWxpZXMgb24g dGhlIHByb3BlcnRpZXMgb2YKICAgY3J5cHRvZ3JhcGhpYyBoYXNoIGZ1bmN0aW9ucy4gIFhN U1MgcHJvdmlkZXMgc3Ryb25nIHNlY3VyaXR5CiAgIGd1YXJhbnRlZXMgYW5kIGlzIGV2ZW4g c2VjdXJlIHdoZW4gdGhlIGNvbGxpc2lvbiByZXNpc3RhbmNlIG9mIHRoZQogICB1bmRlcmx5 aW5nIGhhc2ggZnVuY3Rpb24gaXMgYnJva2VuLiAgSXQgaXMgc3VpdGFibGUgZm9yIGNvbXBh Y3QKICAgaW1wbGVtZW50YXRpb25zLCByZWxhdGl2ZWx5IHNpbXBsZSB0byBpbXBsZW1lbnQs IGFuZCBuYXR1cmFsbHkKICAgcmVzaXN0cyBzaWRlLWNoYW5uZWwgYXR0YWNrcy4gIFVubGlr ZSBtb3N0IG90aGVyIHNpZ25hdHVyZSBzeXN0ZW1zLAogICBoYXNoLWJhc2VkIHNpZ25hdHVy ZXMgY2FuIHdpdGhzdGFuZCBzbyBmYXIga25vd24gYXR0YWNrcyB1c2luZwogICBxdWFudHVt IGNvbXB1dGVycy4KClN0YXR1cyBvZiBUaGlzIE1lbW8KCiAgIFRoaXMgSW50ZXJuZXQtRHJh ZnQgaXMgc3VibWl0dGVkIGluIGZ1bGwgY29uZm9ybWFuY2Ugd2l0aCB0aGUKICAgcHJvdmlz aW9ucyBvZiBCQ1AgNzggYW5kIEJDUCA3OS4KCiAgIEludGVybmV0LURyYWZ0cyBhcmUgd29y a2luZyBkb2N1bWVudHMgb2YgdGhlIEludGVybmV0IEVuZ2luZWVyaW5nCiAgIFRhc2sgRm9y Y2UgKElFVEYpLiAgTm90ZSB0aGF0IG90aGVyIGdyb3VwcyBtYXkgYWxzbyBkaXN0cmlidXRl CiAgIHdvcmtpbmcgZG9jdW1lbnRzIGFzIEludGVybmV0LURyYWZ0cy4gIFRoZSBsaXN0IG9m IGN1cnJlbnQgSW50ZXJuZXQtCiAgIERyYWZ0cyBpcyBhdCBodHRwOi8vZGF0YXRyYWNrZXIu aWV0Zi5vcmcvZHJhZnRzL2N1cnJlbnQvLgoKICAgSW50ZXJuZXQtRHJhZnRzIGFyZSBkcmFm dCBkb2N1bWVudHMgdmFsaWQgZm9yIGEgbWF4aW11bSBvZiBzaXggbW9udGhzCiAgIGFuZCBt YXkgYmUgdXBkYXRlZCwgcmVwbGFjZWQsIG9yIG9ic29sZXRlZCBieSBvdGhlciBkb2N1bWVu dHMgYXQgYW55CiAgIHRpbWUuICBJdCBpcyBpbmFwcHJvcHJpYXRlIHRvIHVzZSBJbnRlcm5l dC1EcmFmdHMgYXMgcmVmZXJlbmNlCiAgIG1hdGVyaWFsIG9yIHRvIGNpdGUgdGhlbSBvdGhl ciB0aGFuIGFzICJ3b3JrIGluIHByb2dyZXNzLiIKCgoKSHVlbHNpbmcsIGV0IGFsLiAgICAg ICAgRXhwaXJlcyBKYW51YXJ5IDI1LCAyMDE4ICAgICAgICAgICAgICAgIFtQYWdlIDFdCgwK SW50ZXJuZXQtRHJhZnQgICAgWE1TUzogRXh0ZW5kZWQgSGFzaC1CYXNlZCBTaWduYXR1cmVz ICAgICAgICAgSnVseSAyMDE3CgoKICAgVGhpcyBJbnRlcm5ldC1EcmFmdCB3aWxsIGV4cGly ZSBvbiBKYW51YXJ5IDI1LCAyMDE4LgoKQ29weXJpZ2h0IE5vdGljZQoKICAgQ29weXJpZ2h0 IChjKSAyMDE3IElFVEYgVHJ1c3QgYW5kIHRoZSBwZXJzb25zIGlkZW50aWZpZWQgYXMgdGhl CiAgIGRvY3VtZW50IGF1dGhvcnMuICBBbGwgcmlnaHRzIHJlc2VydmVkLgoKICAgVGhpcyBk b2N1bWVudCBpcyBzdWJqZWN0IHRvIEJDUCA3OCBhbmQgdGhlIElFVEYgVHJ1c3QncyBMZWdh bAogICBQcm92aXNpb25zIFJlbGF0aW5nIHRvIElFVEYgRG9jdW1lbnRzCiAgIChodHRwOi8v dHJ1c3RlZS5pZXRmLm9yZy9saWNlbnNlLWluZm8pIGluIGVmZmVjdCBvbiB0aGUgZGF0ZSBv ZgogICBwdWJsaWNhdGlvbiBvZiB0aGlzIGRvY3VtZW50LiAgUGxlYXNlIHJldmlldyB0aGVz ZSBkb2N1bWVudHMKICAgY2FyZWZ1bGx5LCBhcyB0aGV5IGRlc2NyaWJlIHlvdXIgcmlnaHRz IGFuZCByZXN0cmljdGlvbnMgd2l0aCByZXNwZWN0CiAgIHRvIHRoaXMgZG9jdW1lbnQuICBD b2RlIENvbXBvbmVudHMgZXh0cmFjdGVkIGZyb20gdGhpcyBkb2N1bWVudCBtdXN0CiAgIGlu Y2x1ZGUgU2ltcGxpZmllZCBCU0QgTGljZW5zZSB0ZXh0IGFzIGRlc2NyaWJlZCBpbiBTZWN0 aW9uIDQuZSBvZgogICB0aGUgVHJ1c3QgTGVnYWwgUHJvdmlzaW9ucyBhbmQgYXJlIHByb3Zp ZGVkIHdpdGhvdXQgd2FycmFudHkgYXMKICAgZGVzY3JpYmVkIGluIHRoZSBTaW1wbGlmaWVk IEJTRCBMaWNlbnNlLgoKVGFibGUgb2YgQ29udGVudHMKCiAgIDEuICBJbnRyb2R1Y3Rpb24g IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAgMwog ICAgIDEuMS4gIENGUkcgTm90ZSBvbiBQb3N0LVF1YW50dW0gQ3J5cHRvZ3JhcGh5ICAuIC4g LiAuIC4gLiAuIC4gLiAgIDUKICAgICAxLjIuICBDb252ZW50aW9ucyBVc2VkIEluIFRoaXMg RG9jdW1lbnQgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICA2CiAgIDIuICBOb3RhdGlvbiAg LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAg NgogICAgIDIuMS4gIERhdGEgVHlwZXMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAgIDYKICAgICAyLjIuICBGdW5jdGlvbnMgLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICA2CiAgICAgMi4zLiAgT3Bl cmF0b3JzIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu ICAgNgogICAgIDIuNC4gIEludGVnZXIgdG8gQnl0ZSBDb252ZXJzaW9uICAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAgIDcKICAgICAyLjUuICBIYXNoIEZ1bmN0aW9uIEFkZHJl c3MgU2NoZW1lICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICA3CiAgICAgMi42LiAg U3RyaW5ncyBvZiBCYXNlIHcgTnVtYmVycyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuICAxMAogICAgIDIuNy4gIE1lbWJlciBGdW5jdGlvbnMgIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgMTIKICAgMy4gIFByaW1pdGl2ZXMgIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDEyCiAgICAgMy4x LiAgV09UUysgT25lLVRpbWUgU2lnbmF0dXJlcyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuICAxMgogICAgICAgMy4xLjEuICBXT1RTKyBQYXJhbWV0ZXJzICAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgMTMKICAgICAgICAgMy4xLjEuMS4gIFdPVFMr IEZ1bmN0aW9ucyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDEzCiAgICAg ICAzLjEuMi4gIFdPVFMrIENoYWluaW5nIEZ1bmN0aW9uIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuICAxNAogICAgICAgMy4xLjMuICBXT1RTKyBQcml2YXRlIEtleSAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgMTQKICAgICAgIDMuMS40LiAgV09UUysg UHVibGljIEtleSAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDE1CiAg ICAgICAzLjEuNS4gIFdPVFMrIFNpZ25hdHVyZSBHZW5lcmF0aW9uICAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuICAxNgogICAgICAgMy4xLjYuICBXT1RTKyBTaWduYXR1cmUgVmVyaWZp Y2F0aW9uICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgMTgKICAgICAgIDMuMS43LiAgUHNl dWRvcmFuZG9tIEtleSBHZW5lcmF0aW9uIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDE5 CiAgIDQuICBTY2hlbWVzIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuICAxOQogICAgIDQuMS4gIFhNU1M6IGVYdGVuZGVkIE1lcmtsZSBT aWduYXR1cmUgU2NoZW1lICAuIC4gLiAuIC4gLiAuIC4gLiAgMTkKICAgICAgIDQuMS4xLiAg WE1TUyBQYXJhbWV0ZXJzIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g IDIwCiAgICAgICA0LjEuMi4gIFhNU1MgSGFzaCBGdW5jdGlvbnMgLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuICAyMQogICAgICAgNC4xLjMuICBYTVNTIFByaXZhdGUgS2V5 ICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgMjEKICAgICAgIDQuMS40 LiAgUmFuZG9taXplZCBUcmVlIEhhc2hpbmcgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gIDIxCiAgICAgICA0LjEuNS4gIEwtVHJlZXMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuICAyMgogICAgICAgNC4xLjYuICBUcmVlSGFzaCAgLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgMjMKCgoKSHVlbHNp bmcsIGV0IGFsLiAgICAgICAgRXhwaXJlcyBKYW51YXJ5IDI1LCAyMDE4ICAgICAgICAgICAg ICAgIFtQYWdlIDJdCgwKSW50ZXJuZXQtRHJhZnQgICAgWE1TUzogRXh0ZW5kZWQgSGFzaC1C YXNlZCBTaWduYXR1cmVzICAgICAgICAgSnVseSAyMDE3CgoKICAgICAgIDQuMS43LiAgWE1T UyBLZXkgR2VuZXJhdGlvbiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDI0 CiAgICAgICA0LjEuOC4gIFhNU1MgU2lnbmF0dXJlICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuICAyNgogICAgICAgNC4xLjkuICBYTVNTIFNpZ25hdHVyZSBHZW5l cmF0aW9uIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgMjcKICAgICAgIDQuMS4xMC4g WE1TUyBTaWduYXR1cmUgVmVyaWZpY2F0aW9uIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g IDI5CiAgICAgICA0LjEuMTEuIFBzZXVkb3JhbmRvbSBLZXkgR2VuZXJhdGlvbiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuICAzMQogICAgICAgNC4xLjEyLiBGcmVlIEluZGV4IEhhbmRs aW5nIGFuZCBQYXJ0aWFsIFByaXZhdGUgS2V5cyAgLiAuIC4gLiAgMzIKICAgICA0LjIuICBY TVNTXk1UOiBNdWx0aS1UcmVlIFhNU1MgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gIDMyCiAgICAgICA0LjIuMS4gIFhNU1NeTVQgUGFyYW1ldGVycyAgLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuICAzMgogICAgICAgNC4yLjIuICBYTVNTXk1UIEtleSBn ZW5lcmF0aW9uICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgMzIKICAgICAgIDQu Mi4zLiAgWE1TU15NVCBTaWduYXR1cmUgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gIDM1CiAgICAgICA0LjIuNC4gIFhNU1NeTVQgU2lnbmF0dXJlIEdlbmVyYXRpb24g IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAzNgogICAgICAgNC4yLjUuICBYTVNTXk1UIFNp Z25hdHVyZSBWZXJpZmljYXRpb24gIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgMzgKICAgICAg IDQuMi42LiAgUHNldWRvcmFuZG9tIEtleSBHZW5lcmF0aW9uIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gIDM5CiAgICAgICA0LjIuNy4gIEZyZWUgSW5kZXggSGFuZGxpbmcgYW5kIFBh cnRpYWwgUHJpdmF0ZSBLZXlzICAuIC4gLiAuICA0MAogICA1LiAgUGFyYW1ldGVyIFNldHMg IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgNDAKICAg ICA1LjEuICBJbXBsZW1lbnRpbmcgdGhlIGZ1bmN0aW9ucyAgLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gIDQwCiAgICAgNS4yLiAgV09UUysgUGFyYW1ldGVycyAgLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICA0MgogICAgIDUuMy4gIFhNU1MgUGFy YW1ldGVycyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgNDIK ICAgICAgIDUuMy4xLiAgUGFyYW1ldGVyIGd1aWRlIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gIDQzCiAgICAgNS40LiAgWE1TU15NVCBQYXJhbWV0ZXJzICAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICA0NAogICAgIDUuNS4gIFBhcmFt ZXRlciBndWlkZSAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAg NDYKICAgNi4gIFJhdGlvbmFsZSAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gIDQ4CiAgIDcuICBSZWZlcmVuY2UgQ29kZSAgLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICA0OQogICA4LiAgSUFOQSBD b25zaWRlcmF0aW9ucyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAgNDkKICAgOS4gIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gIDUzCiAgICAgOS4xLiAgU2VjdXJpdHkgUHJvb2ZzIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICA1MwogICAgIDkuMi4g IE1pbmltYWwgU2VjdXJpdHkgQXNzdW1wdGlvbnMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAgNTUKICAgICA5LjMuICBQb3N0LVF1YW50dW0gU2VjdXJpdHkgLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDU1CiAgIDEwLiBBY2tub3dsZWRnZW1lbnRzICAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICA1NgogICAxMS4g UmVmZXJlbmNlcyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAgNTYKICAgICAxMS4xLiAgTm9ybWF0aXZlIFJlZmVyZW5jZXMgLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDU2CiAgICAgMTEuMi4gIEluZm9ybWF0aXZl IFJlZmVyZW5jZXMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICA1NgogICBB cHBlbmRpeCBBLiAgV09UUysgWERSIEZvcm1hdHMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAgNTgKICAgQXBwZW5kaXggQi4gIFhNU1MgWERSIEZvcm1hdHMgLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDU5CiAgIEFwcGVuZGl4IEMuICBYTVNT Xk1UIFhEUiBGb3JtYXRzICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICA2NAog ICBBdXRob3JzJyBBZGRyZXNzZXMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAgNzEKCjEuICBJbnRyb2R1Y3Rpb24KCiAgIEEgKGNyeXB0b2dyYXBo aWMpIGRpZ2l0YWwgc2lnbmF0dXJlIHNjaGVtZSBwcm92aWRlcyBhc3ltbWV0cmljCiAgIG1l c3NhZ2UgYXV0aGVudGljYXRpb24uICBUaGUga2V5IGdlbmVyYXRpb24gYWxnb3JpdGhtIHBy b2R1Y2VzIGEga2V5CiAgIHBhaXIgY29uc2lzdGluZyBvZiBhIHByaXZhdGUgYW5kIGEgcHVi bGljIGtleS4gIEEgbWVzc2FnZSBpcyBzaWduZWQKICAgdXNpbmcgYSBwcml2YXRlIGtleSB0 byBwcm9kdWNlIGEgc2lnbmF0dXJlLiAgQSBtZXNzYWdlL3NpZ25hdHVyZSBwYWlyCiAgIGNh biBiZSB2ZXJpZmllZCB1c2luZyBhIHB1YmxpYyBrZXkuICBBIE9uZS1UaW1lIFNpZ25hdHVy ZSAoT1RTKQogICBzY2hlbWUgYWxsb3dzIHVzaW5nIGEga2V5IHBhaXIgdG8gc2lnbiBleGFj dGx5IG9uZSBtZXNzYWdlIHNlY3VyZWx5LgogICBBIE1hbnktVGltZSBTaWduYXR1cmUgKE1U Uykgc3lzdGVtIGNhbiBiZSB1c2VkIHRvIHNpZ24gbXVsdGlwbGUKICAgbWVzc2FnZXMuCgoK CgpIdWVsc2luZywgZXQgYWwuICAgICAgICBFeHBpcmVzIEphbnVhcnkgMjUsIDIwMTggICAg ICAgICAgICAgICAgW1BhZ2UgM10KDApJbnRlcm5ldC1EcmFmdCAgICBYTVNTOiBFeHRlbmRl ZCBIYXNoLUJhc2VkIFNpZ25hdHVyZXMgICAgICAgICBKdWx5IDIwMTcKCgogICBPVFMgc2No ZW1lcywgYW5kIE1UUyBzY2hlbWVzIGNvbXBvc2VkIGZyb20gdGhlbSwgd2VyZSBwcm9wb3Nl ZCBieQogICBNZXJrbGUgaW4gMTk3OSBbTWVya2xlNzldLiAgVGhleSB3ZXJlIHdlbGwtc3R1 ZGllZCBpbiB0aGUgMTk5MHMgYW5kCiAgIGhhdmUgcmVnYWluZWQgaW50ZXJlc3QgZnJvbSB0 aGUgbWlkIDIwMDBzIG9ud2FyZHMgYmVjYXVzZSBvZiB0aGVpcgogICByZXNpc3RhbmNlIGFn YWluc3QgcXVhbnR1bS1jb21wdXRlci1haWRlZCBhdHRhY2tzLiAgVGhlc2Uga2luZHMgb2YK ICAgc2lnbmF0dXJlIHNjaGVtZXMgYXJlIGNhbGxlZCBoYXNoLWJhc2VkIHNpZ25hdHVyZSBz Y2hlbWVzIGFzIHRoZXkgYXJlCiAgIGJ1aWx0IG91dCBvZiBhIGNyeXB0b2dyYXBoaWMgaGFz aCBmdW5jdGlvbi4gIEhhc2gtYmFzZWQgc2lnbmF0dXJlCiAgIHNjaGVtZXMgZ2VuZXJhbGx5 IGZlYXR1cmUgc21hbGwgcHJpdmF0ZSBhbmQgcHVibGljIGtleXMgYXMgd2VsbCBhcwogICBm YXN0IHNpZ25hdHVyZSBnZW5lcmF0aW9uIGFuZCB2ZXJpZmljYXRpb24gYnV0IGxhcmdlIHNp Z25hdHVyZXMgYW5kCiAgIHJlbGF0aXZlbHkgc2xvdyBrZXkgZ2VuZXJhdGlvbi4gIEluIGFk ZGl0aW9uLCB0aGV5IGFyZSBzdWl0YWJsZSBmb3IKICAgY29tcGFjdCBpbXBsZW1lbnRhdGlv bnMgdGhhdCBiZW5lZml0IHZhcmlvdXMgYXBwbGljYXRpb25zIGFuZCBhcmUKICAgbmF0dXJh bGx5IHJlc2lzdGFudCB0byBtb3N0IGtpbmRzIG9mIHNpZGUtY2hhbm5lbCBhdHRhY2tzLgoK ICAgU29tZSBwcm9ncmVzcyBoYXMgYWxyZWFkeSBiZWVuIG1hZGUgdG93YXJkIGludHJvZHVj aW5nIGFuZAogICBzdGFuZGFyZGl6aW5nIGhhc2gtYmFzZWQgc2lnbmF0dXJlcy4gIE1jR3Jl dywgQ3VyY2lvLCBhbmQgRmx1aHJlcgogICBoYXZlIHB1Ymxpc2hlZCBhbiBJbnRlcm5ldC1E cmFmdCBbTUNGMTddIHNwZWNpZnlpbmcgdGhlIExhbXBvcnQtCiAgIERpZmZpZS1XaW50ZXJu aXR6LU1lcmtsZSAoTERXTSkgc2NoZW1lLCBhbHNvIHRha2luZyBpbnRvIGFjY291bnQKICAg c3Vic2VxdWVudCBhZGFwdGF0aW9ucyBieSBMZWlnaHRvbiBhbmQgTWljYWxpLiAgSW5kZXBl bmRlbnRseSwKICAgQnVjaG1hbm4sIERhaG1lbiBhbmQgSHVlbHNpbmcgaGF2ZSBwcm9wb3Nl ZCBYTVNTIFtCREgxMV0sIHRoZQogICBlWHRlbmRlZCBNZXJrbGUgU2lnbmF0dXJlIFNjaGVt ZSwgb2ZmZXJpbmcgYmV0dGVyIGVmZmljaWVuY3kgYW5kIGEKICAgbW9kZXJuIHNlY3VyaXR5 IHByb29mLiAgVmVyeSByZWNlbnRseSwgdGhlIHN0YXRlbGVzcyBoYXNoLWJhc2VkCiAgIHNp Z25hdHVyZSBzY2hlbWUgU1BISU5DUyB3YXMgaW50cm9kdWNlZCBbQkhIMTVdLCB3aXRoIHRo ZSBpbnRlbnQgb2YKICAgYmVpbmcgZWFzaWVyIHRvIGRlcGxveSBpbiBjdXJyZW50IGFwcGxp Y2F0aW9ucy4gIEEgcmVhc29uYWJsZSBuZXh0CiAgIHN0ZXAgdG93YXJkIGludHJvZHVjaW5n IGhhc2gtYmFzZWQgc2lnbmF0dXJlcyBpcyB0byBjb21wbGV0ZSB0aGUKICAgc3BlY2lmaWNh dGlvbnMgb2YgdGhlIGJhc2ljIGFsZ29yaXRobXMgLSBMRFdNLCBYTVNTLCBTUEhJTkNTIGFu ZC9vcgogICB2YXJpYW50cyBbS2FsaXNraTE1XS4KCiAgIFRoZSBlWHRlbmRlZCBNZXJrbGUg U2lnbmF0dXJlIFNjaGVtZSAoWE1TUykgW0JESDExXSBpcyB0aGUgbGF0ZXN0CiAgIHN0YXRl ZnVsIGhhc2gtYmFzZWQgc2lnbmF0dXJlIHNjaGVtZS4gIEl0IGhhcyB0aGUgc21hbGxlc3Qg c2lnbmF0dXJlcwogICBvdXQgb2Ygc3VjaCBzY2hlbWVzIGFuZCBjb21lcyB3aXRoIGEgbXVs dGktdHJlZSB2YXJpYW50IHRoYXQgc29sdmVzCiAgIHRoZSBwcm9ibGVtIG9mIHNsb3cga2V5 IGdlbmVyYXRpb24uICBNb3Jlb3ZlciwgaXQgY2FuIGJlIHNob3duIHRoYXQKICAgWE1TUyBp cyBzZWN1cmUsIG1ha2luZyBvbmx5IG1pbGQgYXNzdW1wdGlvbnMgb24gdGhlIHVuZGVybHlp bmcgaGFzaAogICBmdW5jdGlvbi4gIEVzcGVjaWFsbHksIGl0IGlzIG5vdCByZXF1aXJlZCB0 aGF0IHRoZSBjcnlwdG9ncmFwaGljIGhhc2gKICAgZnVuY3Rpb24gaXMgY29sbGlzaW9uLXJl c2lzdGFudCBmb3IgdGhlIHNlY3VyaXR5IG9mIFhNU1MuCiAgIEltcHJvdmVtZW50cyB1cG9u IFhNU1MsIGFzIGRlc2NyaWJlZCBpbiBbSFJTMTZdLCBhcmUgcGFydCBvZiB0aGlzCiAgIG5v dGUuCgogICBUaGlzIGRvY3VtZW50IGRlc2NyaWJlcyBhIHNpbmdsZS10cmVlIGFuZCBhIG11 bHRpLXRyZWUgdmFyaWFudCBvZgogICBYTVNTLiAgSXQgYWxzbyBkZXNjcmliZXMgV09UUyss IGEgdmFyaWFudCBvZiB0aGUgV2ludGVybml0eiBPVFMKICAgc2NoZW1lIGludHJvZHVjZWQg aW4gW0h1ZWxzaW5nMTNdIHRoYXQgaXMgdXNlZCBieSBYTVNTLiAgVGhlIHNjaGVtZXMKICAg YXJlIGRlc2NyaWJlZCB3aXRoIGVub3VnaCBzcGVjaWZpY2l0eSB0byBlbnN1cmUgaW50ZXJv cGVyYWJpbGl0eQogICBiZXR3ZWVuIGltcGxlbWVudGF0aW9ucy4KCiAgIFRoaXMgZG9jdW1l bnQgaXMgc3RydWN0dXJlZCBhcyBmb2xsb3dzLiAgTm90YXRpb24gaXMgaW50cm9kdWNlZCBp bgogICBTZWN0aW9uIDIuICBTZWN0aW9uIDMgZGVzY3JpYmVzIHRoZSBXT1RTKyBzaWduYXR1 cmUgc3lzdGVtLiAgTVRTCiAgIHNjaGVtZXMgYXJlIGRlZmluZWQgaW4gU2VjdGlvbiA0OiB0 aGUgZVh0ZW5kZWQgTWVya2xlIFNpZ25hdHVyZQogICBTY2hlbWUgKFhNU1MpIGluIFNlY3Rp b24gNC4xLCBhbmQgaXRzIE11bHRpLVRyZWUgdmFyaWFudCAoWE1TU15NVCkgaW4KICAgU2Vj dGlvbiA0LjIuICBQYXJhbWV0ZXIgc2V0cyBhcmUgZGVzY3JpYmVkIGluIFNlY3Rpb24gNS4g IFNlY3Rpb24gNgogICBkZXNjcmliZXMgdGhlIHJhdGlvbmFsZSBiZWhpbmQgY2hvaWNlcyBp biB0aGlzIG5vdGUuICBUaGUgSUFOQQoKCgpIdWVsc2luZywgZXQgYWwuICAgICAgICBFeHBp cmVzIEphbnVhcnkgMjUsIDIwMTggICAgICAgICAgICAgICAgW1BhZ2UgNF0KDApJbnRlcm5l dC1EcmFmdCAgICBYTVNTOiBFeHRlbmRlZCBIYXNoLUJhc2VkIFNpZ25hdHVyZXMgICAgICAg ICBKdWx5IDIwMTcKCgogICByZWdpc3RyeSBmb3IgdGhlc2Ugc2lnbmF0dXJlIHN5c3RlbXMg aXMgZGVzY3JpYmVkIGluIFNlY3Rpb24gOC4KICAgRmluYWxseSwgc2VjdXJpdHkgY29uc2lk ZXJhdGlvbnMgYXJlIHByZXNlbnRlZCBpbiBTZWN0aW9uIDkuCgoxLjEuICBDRlJHIE5vdGUg b24gUG9zdC1RdWFudHVtIENyeXB0b2dyYXBoeQoKICAgQWxsIHBvc3QtcXVhbnR1bSBhbGdv cml0aG1zIGRvY3VtZW50ZWQgYnkgQ0ZSRyBhcmUgdG9kYXkgY29uc2lkZXJlZAogICByZWFk eSBmb3IgZXhwZXJpbWVudGF0aW9uIGFuZCBmdXJ0aGVyIGVuZ2luZWVyaW5nIGRldmVsb3Bt ZW50IChlLmcuCiAgIHRvIGVzdGFibGlzaCB0aGUgaW1wYWN0IG9mIHBlcmZvcm1hbmNlIGFu ZCBzaXplcyBvbiBJRVRGIHByb3RvY29scykuCiAgIEhvd2V2ZXIsIGF0IHRoZSB0aW1lIG9m IHdyaXRpbmcsIHdlIGRvIG5vdCBoYXZlIHNpZ25pZmljYW50CiAgIGRlcGxveW1lbnQgZXhw ZXJpZW5jZSB3aXRoIHN1Y2ggYWxnb3JpdGhtcy4KCiAgIE1hbnkgb2YgdGhlc2UgYWxnb3Jp dGhtcyBjb21lIHdpdGggc3BlY2lmaWMgcmVzdHJpY3Rpb25zLCBlLmcuCiAgIGNoYW5nZSBv ZiBjbGFzc2ljYWwgaW50ZXJmYWNlIG9yIGxlc3MgY3J5cHRhbmFseXNpcyBvZiBwcm9wb3Nl ZAogICBwYXJhbWV0ZXJzIHRoYW4gZXN0YWJsaXNoZWQgc2NoZW1lcy4gIENGUkcgaGFzIGNv bnNlbnN1cyB0aGF0IGFsbAogICBkb2N1bWVudHMgZGVzY3JpYmluZyBwb3N0LXF1YW50dW0g dGVjaG5vbG9naWVzIGluY2x1ZGUgdGhlIGFib3ZlCiAgIHBhcmFncmFwaCBhbmQgYSBjbGVh ciBhZGRpdGlvbmFsIHdhcm5pbmcgYWJvdXQgYW55IHNwZWNpZmljCiAgIHJlc3RyaWN0aW9u cywgZXNwZWNpYWxseSBhcyB0aG9zZSBtaWdodCBhZmZlY3QgdXNlIG9yIGRlcGxveW1lbnQg b2YKICAgdGhlIHNwZWNpZmljIHNjaGVtZS4gIFRoYXQgZ3VpZGFuY2UgbWF5IGJlIGNoYW5n ZWQgb3ZlciB0aW1lIHZpYQogICBkb2N1bWVudCB1cGRhdGVzLgoKICAgQWRkaXRpb25hbGx5 LCBmb3IgWE1TUzoKCiAgIENGUkcgY29uc2Vuc3VzIGlzIHRoYXQgd2UgYXJlIGNvbmZpZGVu dCBpbiB0aGUgY3J5cHRvZ3JhcGhpYyBzZWN1cml0eQogICBvZiB0aGUgc2lnbmF0dXJlIHNj aGVtZXMgZGVzY3JpYmVkIGluIHRoaXMgZG9jdW1lbnQgYWdhaW5zdCBxdWFudHVtCiAgIGNv bXB1dGVycywgZ2l2ZW4gdGhlIGN1cnJlbnQgc3RhdGUgb2YgdGhlIHJlc2VhcmNoIGNvbW11 bml0eSdzCiAgIGtub3dsZWRnZSBhYm91dCBxdWFudHVtIGFsZ29yaXRobXMuICBJbmRlZWQs IHdlIGFyZSBjb25maWRlbnQgdGhhdAogICB0aGUgc2VjdXJpdHkgb2YgYSBzaWduaWZpY2Fu dCBwYXJ0IG9mIHRoZSBJbnRlcm5ldCBjb3VsZCBiZSBtYWRlCiAgIGRlcGVuZGVudCBvbiB0 aGUgc2lnbmF0dXJlIHNjaGVtZXMgZGVmaW5lZCBpbiB0aGlzIGRvY3VtZW50LCBpZgogICBk ZXZlbG9wZXJzIHRha2UgY2FyZSBvZiB0aGUgZm9sbG93aW5nLgoKICAgSW4gY29udHJhc3Qg dG8gdHJhZGl0aW9uYWwgc2lnbmF0dXJlIHNjaGVtZXMsIHRoZSBzaWduYXR1cmUgc2NoZW1l cwogICBkZXNjcmliZWQgaW4gdGhpcyBkb2N1bWVudCBhcmUgc3RhdGVmdWwsIG1lYW5pbmcg dGhlIHNlY3JldCBrZXkKICAgY2hhbmdlcyBvdmVyIHRpbWUuICBJZiBhIHNlY3JldCBrZXkg c3RhdGUgaXMgdXNlZCB0d2ljZSwgbm8KICAgY3J5cHRvZ3JhcGhpYyBzZWN1cml0eSBndWFy YW50ZWVzIHJlbWFpbi4gIEluIGNvbnNlcXVlbmNlLCBpdCBiZWNvbWVzCiAgIGZlYXNpYmxl IHRvIGZvcmdlIGEgc2lnbmF0dXJlIG9uIGEgbmV3IG1lc3NhZ2UuICBUaGlzIGlzIGEgbmV3 CiAgIHByb3BlcnR5IHRoYXQgbW9zdCBkZXZlbG9wZXJzIHdpbGwgbm90IGJlIGZhbWlsaWFy IHdpdGggYW5kIHJlcXVpcmVzCiAgIGNhcmVmdWwgaGFuZGxpbmcgb2Ygc2VjcmV0IGtleXMu ICBEZXZlbG9wZXJzIHNob3VsZCBub3QgdXNlIHRoZQogICBzY2hlbWVzIGRlc2NyaWJlZCBo ZXJlIGV4Y2VwdCBpbiBzeXN0ZW1zIHRoYXQgcHJldmVudCB0aGUgcmV1c2Ugb2YKICAgc2Vj cmV0IGtleSBzdGF0ZXMuCgogICBOb3RlIHRoYXQgdGhlIGZhY3QgdGhhdCB0aGUgc2NoZW1l cyBkZXNjcmliZWQgaW4gdGhpcyBkb2N1bWVudCBhcmUKICAgc3RhdGVmdWwgYWxzbyBpbXBs aWVzIHRoYXQgY2xhc3NpY2FsIEFQSXMgZm9yIGRpZ2l0YWwgc2lnbmF0dXJlCiAgIGNhbm5v dCBiZSB1c2VkIHdpdGhvdXQgbW9kaWZpY2F0aW9uLiAgVGhlIEFQSSBNVVNUIGJlIGFibGUg dG8gaGFuZGxlCiAgIGEgc2VjcmV0IGtleSBzdGF0ZS4gIFRoaXMgZXNwZWNpYWxseSBtZWFu cyB0aGF0IHRoZSBBUEkgSEFTIFRPIGFsbG93CiAgIHRvIHJldHVybiBhbiB1cGRhdGVkIHNl Y3JldCBrZXkgc3RhdGUuCgoKCgoKCkh1ZWxzaW5nLCBldCBhbC4gICAgICAgIEV4cGlyZXMg SmFudWFyeSAyNSwgMjAxOCAgICAgICAgICAgICAgICBbUGFnZSA1XQoMCkludGVybmV0LURy YWZ0ICAgIFhNU1M6IEV4dGVuZGVkIEhhc2gtQmFzZWQgU2lnbmF0dXJlcyAgICAgICAgIEp1 bHkgMjAxNwoKCjEuMi4gIENvbnZlbnRpb25zIFVzZWQgSW4gVGhpcyBEb2N1bWVudAoKICAg VGhlIGtleSB3b3JkcyAiTVVTVCIsICJNVVNUIE5PVCIsICJSRVFVSVJFRCIsICJTSEFMTCIs ICJTSEFMTCBOT1QiLAogICAiU0hPVUxEIiwgIlNIT1VMRCBOT1QiLCAiUkVDT01NRU5ERUQi LCAiTUFZIiwgYW5kICJPUFRJT05BTCIgaW4gdGhpcwogICBkb2N1bWVudCBhcmUgdG8gYmUg aW50ZXJwcmV0ZWQgYXMgZGVzY3JpYmVkIGluIFtSRkMyMTE5XS4KCjIuICBOb3RhdGlvbgoK Mi4xLiAgRGF0YSBUeXBlcwoKICAgQnl0ZXMgYW5kIGJ5dGUgc3RyaW5ncyBhcmUgdGhlIGZ1 bmRhbWVudGFsIGRhdGEgdHlwZXMuICBBIGJ5dGUgaXMgYQogICBzZXF1ZW5jZSBvZiBlaWdo dCBiaXRzLiAgQSBzaW5nbGUgYnl0ZSBpcyBkZW5vdGVkIGFzIGEgcGFpciBvZgogICBoZXhh ZGVjaW1hbCBkaWdpdHMgd2l0aCBhIGxlYWRpbmcgIjB4Ii4gIEEgYnl0ZSBzdHJpbmcgaXMg YW4gb3JkZXJlZAogICBzZXF1ZW5jZSBvZiB6ZXJvIG9yIG1vcmUgYnl0ZXMgYW5kIGlzIGRl bm90ZWQgYXMgYW4gb3JkZXJlZCBzZXF1ZW5jZQogICBvZiBoZXhhZGVjaW1hbCBjaGFyYWN0 ZXJzIHdpdGggYSBsZWFkaW5nICIweCIuICBGb3IgZXhhbXBsZSwgMHhlNTM0ZjAKICAgaXMg YSBieXRlIHN0cmluZyBvZiBsZW5ndGggMy4gIEFuIGFycmF5IG9mIGJ5dGUgc3RyaW5ncyBp cyBhbgogICBvcmRlcmVkLCBpbmRleGVkIHNldCBzdGFydGluZyB3aXRoIGluZGV4IDAgaW4g d2hpY2ggYWxsIGJ5dGUgc3RyaW5ncwogICBoYXZlIGlkZW50aWNhbCBsZW5ndGguICBXZSBh c3N1bWUgYmlnLWVuZGlhbiByZXByZXNlbnRhdGlvbiBmb3IgYW55CiAgIGRhdGEgdHlwZXMg b3Igc3RydWN0dXJlcy4KCjIuMi4gIEZ1bmN0aW9ucwoKICAgSWYgeCBpcyBhIG5vbi1uZWdh dGl2ZSByZWFsIG51bWJlciwgdGhlbiB3ZSBkZWZpbmUgdGhlIGZvbGxvd2luZwogICBmdW5j dGlvbnM6CgogICAgICBjZWlsKHgpIDogcmV0dXJucyB0aGUgc21hbGxlc3QgaW50ZWdlciBn cmVhdGVyIHRoYW4gb3IgZXF1YWwgdG8geC4KCiAgICAgIGZsb29yKHgpIDogcmV0dXJucyB0 aGUgbGFyZ2VzdCBpbnRlZ2VyIGxlc3MgdGhhbiBvciBlcXVhbCB0byB4LgoKICAgICAgbGco eCkgOiByZXR1cm5zIHRoZSBsb2dhcml0aG0gdG8gYmFzZSAyIG9mIHguCgoyLjMuICBPcGVy YXRvcnMKCiAgIFdoZW4gYSBhbmQgYiBhcmUgaW50ZWdlcnMsIG1hdGhlbWF0aWNhbCBvcGVy YXRvcnMgYXJlIGRlZmluZWQgYXMKICAgZm9sbG93czoKCiAgICAgIF4gOiBhIF4gYiBkZW5v dGVzIHRoZSByZXN1bHQgb2YgYSByYWlzZWQgdG8gdGhlIHBvd2VyIG9mIGIuCgogICAgICAq IDogYSAqIGIgZGVub3RlcyB0aGUgcHJvZHVjdCBvZiBhIGFuZCBiLiAgVGhpcyBvcGVyYXRv ciBpcwogICAgICBzb21ldGltZXMgb21pdHRlZCBpbiB0aGUgYWJzZW5jZSBvZiBhbWJpZ3Vp dHksIGFzIGluIHVzdWFsCiAgICAgIG1hdGhlbWF0aWNhbCBub3RhdGlvbi4KCiAgICAgIC8g OiBhIC8gYiBkZW5vdGVzIHRoZSBxdW90aWVudCBvZiBhIGJ5IG5vbi16ZXJvIGIuCgogICAg ICAlIDogYSAlIGIgZGVub3RlcyB0aGUgbm9uLW5lZ2F0aXZlIHJlbWFpbmRlciBvZiB0aGUg aW50ZWdlcgogICAgICBkaXZpc2lvbiBvZiBhIGJ5IGIuCgogICAgICArIDogYSArIGIgZGVu b3RlcyB0aGUgc3VtIG9mIGEgYW5kIGIuCgoKCkh1ZWxzaW5nLCBldCBhbC4gICAgICAgIEV4 cGlyZXMgSmFudWFyeSAyNSwgMjAxOCAgICAgICAgICAgICAgICBbUGFnZSA2XQoMCkludGVy bmV0LURyYWZ0ICAgIFhNU1M6IEV4dGVuZGVkIEhhc2gtQmFzZWQgU2lnbmF0dXJlcyAgICAg ICAgIEp1bHkgMjAxNwoKCiAgICAgIC0gOiBhIC0gYiBkZW5vdGVzIHRoZSBkaWZmZXJlbmNl IG9mIGEgYW5kIGIuCgogICAgICArKyA6IGErKyBkZW5vdGVzIGluY3JlbWVudGluZyBhIGJ5 IDEsIGkuZS4sIGEgPSBhICsgMS4KCiAgICAgIDw8IDogYSA8PCBiIGRlbm90ZXMgYSBsb2dp Y2FsIGxlZnQgc2hpZnQgd2l0aCBiIGJlaW5nIG5vbi0KICAgICAgbmVnYXRpdmUsIGkuZS4s IGEgKiAyXmIuCgogICAgICA+PiA6IGEgPj4gYiBkZW5vdGVzIGEgbG9naWNhbCByaWdodCBz aGlmdCB3aXRoIGIgYmVpbmcgbm9uLQogICAgICBuZWdhdGl2ZSwgaS5lLiBmbG9vcihhIC8g Ml5iKS4KCiAgIFRoZSBzdGFuZGFyZCBvcmRlciBvZiBvcGVyYXRpb25zIGlzIHVzZWQgd2hl biBldmFsdWF0aW5nIGFyaXRobWV0aWMKICAgZXhwcmVzc2lvbnMuCgogICBBcnJheXMgYXJl IHVzZWQgaW4gdGhlIGNvbW1vbiB3YXksIHdoZXJlIHRoZSBpXnRoIGVsZW1lbnQgb2YgYW4g YXJyYXkKICAgQSBpcyBkZW5vdGVkIEFbaV0uICBCeXRlIHN0cmluZ3MgYXJlIHRyZWF0ZWQg YXMgYXJyYXlzIG9mIGJ5dGVzIHdoZXJlCiAgIG5lY2Vzc2FyeTogSWYgWCBpcyBhIGJ5dGUg c3RyaW5nLCB0aGVuIFhbaV0gZGVub3RlcyBpdHMgaV50aCBieXRlLAogICB3aGVyZSBYWzBd IGlzIHRoZSBsZWZ0bW9zdCBieXRlLgoKICAgSWYgQSBhbmQgQiBhcmUgYnl0ZSBzdHJpbmdz IG9mIGVxdWFsIGxlbmd0aCwgdGhlbjoKCiAgICAgIEEgQU5EIEIgZGVub3RlcyB0aGUgYml0 d2lzZSBsb2dpY2FsIGNvbmp1bmN0aW9uIG9wZXJhdGlvbi4KCiAgICAgIEEgWE9SIEIgZGVu b3RlcyB0aGUgYml0d2lzZSBsb2dpY2FsIGV4Y2x1c2l2ZSBkaXNqdW5jdGlvbgogICAgICBv cGVyYXRpb24uCgogICBXaGVuIEIgaXMgYSBieXRlIGFuZCBpIGlzIGFuIGludGVnZXIsIHRo ZW4gQiA+PiBpIGRlbm90ZXMgdGhlIGxvZ2ljYWwKICAgcmlnaHQtc2hpZnQgb3BlcmF0aW9u LgoKICAgSWYgWCBpcyBhbiB4LWJ5dGUgc3RyaW5nIGFuZCBZIGEgeS1ieXRlIHN0cmluZywg dGhlbiBYIHx8IFkgZGVub3RlcwogICB0aGUgY29uY2F0ZW5hdGlvbiBvZiBYIGFuZCBZLCB3 aXRoIFggfHwgWSA9IFhbMF0gLi4uIFhbeC0xXSBZWzBdIC4uLgogICBZW3ktMV0uCgoyLjQu ICBJbnRlZ2VyIHRvIEJ5dGUgQ29udmVyc2lvbgoKICAgSWYgeCBhbmQgeSBhcmUgbm9uLW5l Z2F0aXZlIGludGVnZXJzLCB3ZSBkZWZpbmUgWiA9IHRvQnl0ZSh4LCB5KSB0bwogICBiZSB0 aGUgeS1ieXRlIHN0cmluZyBjb250YWluaW5nIHRoZSBiaW5hcnkgcmVwcmVzZW50YXRpb24g b2YgeCBpbgogICBiaWctZW5kaWFuIGJ5dGUtb3JkZXIuCgoyLjUuICBIYXNoIEZ1bmN0aW9u IEFkZHJlc3MgU2NoZW1lCgogICBUaGUgc2NoZW1lcyBkZXNjcmliZWQgaW4gdGhpcyBkb2N1 bWVudCByYW5kb21pemUgZWFjaCBoYXNoIGZ1bmN0aW9uCiAgIGNhbGwuICBUaGlzIG1lYW5z IHRoYXQgYXNpZGUgZnJvbSB0aGUgaW5pdGlhbCBtZXNzYWdlIGRpZ2VzdCwgZm9yCiAgIGVh Y2ggaGFzaCBmdW5jdGlvbiBjYWxsIGEgZGlmZmVyZW50IGtleSBhbmQgZGlmZmVyZW50IGJp dG1hc2sgaXMKICAgdXNlZC4gIFRoZXNlIHZhbHVlcyBhcmUgcHNldWRvcmFuZG9tbHkgZ2Vu ZXJhdGVkIHVzaW5nIGEgcHNldWRvcmFuZG9tCiAgIGZ1bmN0aW9uIHRoYXQgdGFrZXMgYSBr ZXkgU0VFRCBhbmQgYSAzMi1ieXRlIGFkZHJlc3MgQURSUyBhcyBpbnB1dAogICBhbmQgb3V0 cHV0cyBhbiBuLWJ5dGUgdmFsdWUsIHdoZXJlIG4gaXMgdGhlIHNlY3VyaXR5IHBhcmFtZXRl ci4gIEhlcmUKICAgd2UgZXhwbGFpbiB0aGUgc3RydWN0dXJlIG9mIGFkZHJlc3MgQURSUyBh bmQgcHJvcG9zZSBzZXR0ZXIgbWV0aG9kcwoKCgoKSHVlbHNpbmcsIGV0IGFsLiAgICAgICAg RXhwaXJlcyBKYW51YXJ5IDI1LCAyMDE4ICAgICAgICAgICAgICAgIFtQYWdlIDddCgwKSW50 ZXJuZXQtRHJhZnQgICAgWE1TUzogRXh0ZW5kZWQgSGFzaC1CYXNlZCBTaWduYXR1cmVzICAg ICAgICAgSnVseSAyMDE3CgoKICAgdG8gbWFuaXB1bGF0ZSB0aGUgYWRkcmVzcy4gIFdlIGV4 cGxhaW4gdGhlIGdlbmVyYXRpb24gb2YgdGhlCiAgIGFkZHJlc3NlcyBpbiB0aGUgZm9sbG93 aW5nIHNlY3Rpb25zIHdoZXJlIHRoZXkgYXJlIHVzZWQuCgogICBUaGUgc2NoZW1lcyBpbiB0 aGUgbmV4dCB0d28gc2VjdGlvbnMgdXNlIHR3byBraW5kcyBvZiBoYXNoIGZ1bmN0aW9ucwog ICBwYXJhbWV0ZXJpemVkIGJ5IHNlY3VyaXR5IHBhcmFtZXRlciBuLiAgRm9yIHRoZSBoYXNo IHRyZWUKICAgY29uc3RydWN0aW9ucywgYSBoYXNoIGZ1bmN0aW9uIHRoYXQgbWFwcyBhbiBu LWJ5dGUga2V5IGFuZCAybi1ieXRlCiAgIGlucHV0cyB0byBuLWJ5dGUgb3V0cHV0cyBpcyB1 c2VkLiAgVG8gcmFuZG9taXplIHRoaXMgZnVuY3Rpb24sIDNuCiAgIGJ5dGVzIGFyZSBuZWVk ZWQgLSBuIGJ5dGVzIGZvciB0aGUga2V5IGFuZCAybiBieXRlcyBmb3IgYSBiaXRtYXNrLgog ICBGb3IgdGhlIE9UUyBzY2hlbWUgY29uc3RydWN0aW9ucywgYSBoYXNoIGZ1bmN0aW9uIHRo YXQgbWFwcyBuLWJ5dGUKICAga2V5cyBhbmQgbi1ieXRlIGlucHV0cyB0byBuLWJ5dGUgb3V0 cHV0cyBpcyB1c2VkLiAgVG8gcmFuZG9taXplIHRoaXMKICAgZnVuY3Rpb24sIDJuIGJ5dGVz IGFyZSBuZWVkZWQgLSBuIGJ5dGVzIGZvciB0aGUga2V5IGFuZCBuIGJ5dGVzIGZvciBhCiAg IGJpdG1hc2suICBDb25zZXF1ZW50bHksIHRocmVlIGFkZHJlc3NlcyBhcmUgbmVlZGVkIGZv ciB0aGUgZmlyc3QKICAgZnVuY3Rpb24gYW5kIHR3byBhZGRyZXNzZXMgZm9yIHRoZSBzZWNv bmQgb25lLgoKICAgVGhlcmUgYXJlIHRocmVlIGRpZmZlcmVudCB0eXBlcyBvZiBhZGRyZXNz ZXMgZm9yIHRoZSBkaWZmZXJlbnQgdXNlCiAgIGNhc2VzLiAgT25lIHR5cGUgaXMgdXNlZCBm b3IgdGhlIGhhc2hlcyBpbiBPVFMgc2NoZW1lcywgb25lIGlzIHVzZWQKICAgZm9yIGhhc2hl cyB3aXRoaW4gdGhlIG1haW4gTWVya2xlIHRyZWUgY29uc3RydWN0aW9uLCBhbmQgb25lIGlz IHVzZWQKICAgZm9yIGhhc2hlcyBpbiB0aGUgTC10cmVlcy4gIFRoZSBsYXR0ZXIgaXMgdXNl ZCB0byBjb21wcmVzcyBvbmUtdGltZQogICBwdWJsaWMga2V5cy4gIEFsbCB0aGVzZSB0eXBl cyBzaGFyZSBhcyBtdWNoIGZvcm1hdCBhcyBwb3NzaWJsZS4gIEluCiAgIHRoZSBmb2xsb3dp bmcgd2UgZGVzY3JpYmUgdGhlc2UgdHlwZXMgaW4gZGV0YWlsLgoKICAgVGhlIHN0cnVjdHVy ZSBvZiBhbiBhZGRyZXNzIGNvbXBsaWVzIHdpdGggd29yZCBib3JkZXJzLCB3aXRoIGEgd29y ZAogICBiZWluZyAzMiBiaXRzIGxvbmcgaW4gdGhpcyBjb250ZXh0LiAgT25seSB0aGUgdHJl ZSBhZGRyZXNzIGlzIHRvbwogICBsb25nIHRvIGZpdCBhIHNpbmdsZSB3b3JkIGJ1dCBtYXRj aGVzIGEgZG91YmxlIHdvcmQuICBBbiBhZGRyZXNzIGlzCiAgIHN0cnVjdHVyZWQgYXMgZm9s bG93cy4gIEl0IGFsd2F5cyBzdGFydHMgd2l0aCBhIGxheWVyIGFkZHJlc3Mgb2Ygb25lCiAg IHdvcmQgaW4gdGhlIG1vc3Qgc2lnbmlmaWNhbnQgYml0cywgZm9sbG93ZWQgYnkgYSB0cmVl IGFkZHJlc3Mgb2YgdHdvCiAgIHdvcmRzLiAgQm90aCBhZGRyZXNzZXMgYXJlIG5lZWRlZCBm b3IgdGhlIG11bHRpLXRyZWUgdmFyaWFudCAoc2VlCiAgIFNlY3Rpb24gNC4yKSBhbmQgZGVz Y3JpYmUgdGhlIHBvc2l0aW9uIG9mIGEgdHJlZSB3aXRoaW4gYSBtdWx0aS10cmVlLgogICBU aGV5IGFyZSB0aGVyZWZvcmUgc2V0IHRvIHplcm8gaW4gY2FzZSBvZiBzaW5nbGUtdHJlZSBh cHBsaWNhdGlvbnMuCiAgIEZvciBtdWx0aS10cmVlIGhhc2gtYmFzZWQgc2lnbmF0dXJlcyB0 aGUgbGF5ZXIgYWRkcmVzcyBkZXNjcmliZXMgdGhlCiAgIGhlaWdodCBvZiBhIHRyZWUgd2l0 aGluIHRoZSBtdWx0aS10cmVlIHN0YXJ0aW5nIGZyb20gaGVpZ2h0IHplcm8gZm9yCiAgIHRy ZWVzIGF0IHRoZSBib3R0b20gbGF5ZXIuICBUaGUgdHJlZSBhZGRyZXNzIGRlc2NyaWJlcyB0 aGUgcG9zaXRpb24KICAgb2YgYSB0cmVlIHdpdGhpbiBhIGxheWVyIG9mIGEgbXVsdGktdHJl ZSBzdGFydGluZyB3aXRoIGluZGV4IHplcm8gZm9yCiAgIHRoZSBsZWZ0bW9zdCB0cmVlLiAg VGhlIG5leHQgd29yZCBkZWZpbmVzIHRoZSB0eXBlIG9mIHRoZSBhZGRyZXNzLgogICBJdCBp cyBzZXQgdG8gMCBmb3IgYW4gT1RTIGFkZHJlc3MsIHRvIDEgZm9yIGFuIEwtdHJlZSBhZGRy ZXNzLCBhbmQgdG8KICAgMiBmb3IgYSBoYXNoIHRyZWUgYWRkcmVzcy4gIFdoZW5ldmVyIHRo ZSB0eXBlIHdvcmQgb2YgYW4gYWRkcmVzcyBpcwogICBjaGFuZ2VkLCBhbGwgZm9sbG93aW5n IHdvcmRzIHNob3VsZCBiZSBpbml0aWFsaXplZCB3aXRoIDAgdG8gcHJldmVudAogICBub24t emVybyB2YWx1ZXMgaW4gdW51c2VkIHBhZGRpbmcgd29yZHMuCgogICBXZSBmaXJzdCBkZXNj cmliZSB0aGUgT1RTIGFkZHJlc3MgY2FzZS4gIEluIHRoaXMgY2FzZSwgdGhlIHR5cGUgd29y ZAogICBpcyBmb2xsb3dlZCBieSBhbiBPVFMgYWRkcmVzcyB3b3JkIHRoYXQgZW5jb2RlcyB0 aGUgaW5kZXggb2YgdGhlIE9UUwogICBrZXkgcGFpciB3aXRoaW4gdGhlIHRyZWUuICBUaGUg bmV4dCB3b3JkIGVuY29kZXMgdGhlIGNoYWluIGFkZHJlc3MKICAgZm9sbG93ZWQgYnkgYSB3 b3JkIHRoYXQgZW5jb2RlcyB0aGUgYWRkcmVzcyBvZiB0aGUgaGFzaCBmdW5jdGlvbiBjYWxs CiAgIHdpdGhpbiB0aGUgY2hhaW4uICBUaGUgbGFzdCB3b3JkLCBjYWxsZWQga2V5QW5kTWFz aywgaXMgdXNlZCB0bwogICBnZW5lcmF0ZSB0d28gZGlmZmVyZW50IGFkZHJlc3NlcyBmb3Ig b25lIGhhc2ggZnVuY3Rpb24gY2FsbC4gIFRoZQogICB3b3JkIGlzIHNldCB0byB6ZXJvIHRv IGdlbmVyYXRlIHRoZSBrZXkuICBUbyBnZW5lcmF0ZSB0aGUgbi1ieXRlCiAgIGJpdG1hc2ss IHRoZSB3b3JkIGlzIHNldCB0byBvbmUuCgoKCgpIdWVsc2luZywgZXQgYWwuICAgICAgICBF eHBpcmVzIEphbnVhcnkgMjUsIDIwMTggICAgICAgICAgICAgICAgW1BhZ2UgOF0KDApJbnRl cm5ldC1EcmFmdCAgICBYTVNTOiBFeHRlbmRlZCBIYXNoLUJhc2VkIFNpZ25hdHVyZXMgICAg ICAgICBKdWx5IDIwMTcKCgogICAgICAgICAgICAgICAgICAgICAgIEFuIE9UUyBoYXNoIGFk ZHJlc3MKICAgICAgICAgICAgICAgICAgICAgKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsK ICAgICAgICAgICAgICAgICAgICAgfCBsYXllciBhZGRyZXNzICAoMzIgYml0KXwKICAgICAg ICAgICAgICAgICAgICAgKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsKICAgICAgICAgICAg ICAgICAgICAgfCB0cmVlIGFkZHJlc3MgICAoNjQgYml0KXwKICAgICAgICAgICAgICAgICAg ICAgKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsKICAgICAgICAgICAgICAgICAgICAgfCB0 eXBlID0gMCAgICAgICAoMzIgYml0KXwKICAgICAgICAgICAgICAgICAgICAgKy0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLSsKICAgICAgICAgICAgICAgICAgICAgfCBPVFMgYWRkcmVzcyAg ICAoMzIgYml0KXwKICAgICAgICAgICAgICAgICAgICAgKy0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLSsKICAgICAgICAgICAgICAgICAgICAgfCBjaGFpbiBhZGRyZXNzICAoMzIgYml0KXwK ICAgICAgICAgICAgICAgICAgICAgKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsKICAgICAg ICAgICAgICAgICAgICAgfCBoYXNoIGFkZHJlc3MgICAoMzIgYml0KXwKICAgICAgICAgICAg ICAgICAgICAgKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsKICAgICAgICAgICAgICAgICAg ICAgfCBrZXlBbmRNYXNrICAgICAoMzIgYml0KXwKICAgICAgICAgICAgICAgICAgICAgKy0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsKCiAgIFdlIG5vdyBkaXNjdXNzIHRoZSBMLXRyZWUg Y2FzZSwgd2hpY2ggbWVhbnMgdGhhdCB0aGUgdHlwZSB3b3JkIGlzIHNldAogICB0byBvbmUu ICBJbiB0aGF0IGNhc2UgdGhlIHR5cGUgd29yZCBpcyBmb2xsb3dlZCBieSBhbiBMLXRyZWUg YWRkcmVzcwogICB3b3JkIHRoYXQgZW5jb2RlcyB0aGUgaW5kZXggb2YgdGhlIGxlYWYgY29t cHV0ZWQgd2l0aCB0aGlzIEwtdHJlZS4KICAgVGhlIG5leHQgd29yZCBlbmNvZGVzIHRoZSBo ZWlnaHQgb2YgdGhlIG5vZGUgYmVpbmcgaW5wdXQgZm9yIHRoZSBuZXh0CiAgIGNvbXB1dGF0 aW9uIGluc2lkZSB0aGUgTC10cmVlLiAgVGhlIGZvbGxvd2luZyB3b3JkIGVuY29kZXMgdGhl IGluZGV4CiAgIG9mIHRoZSBub2RlIGF0IHRoYXQgaGVpZ2h0LCBpbnNpZGUgdGhlIEwtdHJl ZS4gIFRoaXMgdGltZSwgdGhlIGxhc3QKICAgd29yZCwga2V5QW5kTWFzaywgaXMgdXNlZCB0 byBnZW5lcmF0ZSB0aHJlZSBkaWZmZXJlbnQgYWRkcmVzc2VzIGZvcgogICBvbmUgZnVuY3Rp b24gY2FsbC4gIFRoZSB3b3JkIGlzIHNldCB0byB6ZXJvIHRvIGdlbmVyYXRlIHRoZSBrZXku ICBUbwogICBnZW5lcmF0ZSB0aGUgbW9zdCBzaWduaWZpY2FudCBuIGJ5dGVzIG9mIHRoZSAy bi1ieXRlIGJpdG1hc2ssIHRoZQogICB3b3JkIGlzIHNldCB0byBvbmUuICBUaGUgbGVhc3Qg c2lnbmlmaWNhbnQgYnl0ZXMgYXJlIGdlbmVyYXRlZCB1c2luZwogICB0aGUgYWRkcmVzcyB3 aXRoIHRoZSB3b3JkIHNldCB0byB0d28uCgogICAgICAgICAgICAgICAgICAgICAgICAgIEFu IEwtdHJlZSBhZGRyZXNzCiAgICAgICAgICAgICAgICAgICAgICstLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0rCiAgICAgICAgICAgICAgICAgICAgIHwgbGF5ZXIgYWRkcmVzcyAgKDMyIGJp dCl8CiAgICAgICAgICAgICAgICAgICAgICstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rCiAg ICAgICAgICAgICAgICAgICAgIHwgdHJlZSBhZGRyZXNzICAgKDY0IGJpdCl8CiAgICAgICAg ICAgICAgICAgICAgICstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rCiAgICAgICAgICAgICAg ICAgICAgIHwgdHlwZSA9IDEgICAgICAgKDMyIGJpdCl8CiAgICAgICAgICAgICAgICAgICAg ICstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rCiAgICAgICAgICAgICAgICAgICAgIHwgTC10 cmVlIGFkZHJlc3MgKDMyIGJpdCl8CiAgICAgICAgICAgICAgICAgICAgICstLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0rCiAgICAgICAgICAgICAgICAgICAgIHwgdHJlZSBoZWlnaHQgICAg KDMyIGJpdCl8CiAgICAgICAgICAgICAgICAgICAgICstLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0rCiAgICAgICAgICAgICAgICAgICAgIHwgdHJlZSBpbmRleCAgICAgKDMyIGJpdCl8CiAg ICAgICAgICAgICAgICAgICAgICstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rCiAgICAgICAg ICAgICAgICAgICAgIHwga2V5QW5kTWFzayAgICAgKDMyIGJpdCl8CiAgICAgICAgICAgICAg ICAgICAgICstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rCgogICBXZSBub3cgZGVzY3JpYmUg dGhlIHJlbWFpbmluZyB0eXBlIGZvciB0aGUgbWFpbiB0cmVlIGhhc2ggYWRkcmVzc2VzLgog ICBJbiB0aGlzIGNhc2UgdGhlIHR5cGUgd29yZCBpcyBzZXQgdG8gdHdvLCBmb2xsb3dlZCBi eSBhIHplcm8gcGFkZGluZwoKCgpIdWVsc2luZywgZXQgYWwuICAgICAgICBFeHBpcmVzIEph bnVhcnkgMjUsIDIwMTggICAgICAgICAgICAgICAgW1BhZ2UgOV0KDApJbnRlcm5ldC1EcmFm dCAgICBYTVNTOiBFeHRlbmRlZCBIYXNoLUJhc2VkIFNpZ25hdHVyZXMgICAgICAgICBKdWx5 IDIwMTcKCgogICBvZiBvbmUgd29yZC4gIFRoZSBuZXh0IHdvcmQgZW5jb2RlcyB0aGUgaGVp Z2h0IG9mIHRoZSB0cmVlIG5vZGUgYmVpbmcKICAgaW5wdXQgZm9yIHRoZSBuZXh0IGNvbXB1 dGF0aW9uLCBmb2xsb3dlZCBieSBhIHdvcmQgdGhhdCBlbmNvZGVzIHRoZQogICBpbmRleCBv ZiB0aGlzIG5vZGUgYXQgdGhhdCBoZWlnaHQuICBBcyBmb3IgdGhlIEwtdHJlZSBhZGRyZXNz ZXMsIHRoZQogICBsYXN0IHdvcmQsIGtleUFuZE1hc2ssIGlzIHVzZWQgdG8gZ2VuZXJhdGUg dGhyZWUgZGlmZmVyZW50IGFkZHJlc3NlcwogICBmb3Igb25lIGZ1bmN0aW9uIGNhbGwuICBU aGUgd29yZCBpcyBzZXQgdG8gemVybyB0byBnZW5lcmF0ZSB0aGUga2V5LgogICBUbyBnZW5l cmF0ZSB0aGUgbW9zdCBzaWduaWZpY2FudCBuIGJ5dGVzIG9mIHRoZSAybi1ieXRlIGJpdG1h c2ssIHRoZQogICB3b3JkIGlzIHNldCB0byBvbmUuICBUaGUgbGVhc3Qgc2lnbmlmaWNhbnQg Ynl0ZXMgYXJlIGdlbmVyYXRlZCB1c2luZwogICB0aGUgYWRkcmVzcyB3aXRoIHRoZSB3b3Jk IHNldCB0byB0d28uCgogICAgICAgICAgICAgICAgICAgICAgIEEgaGFzaCB0cmVlIGFkZHJl c3MKICAgICAgICAgICAgICAgICAgICAgKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsKICAg ICAgICAgICAgICAgICAgICAgfCBsYXllciBhZGRyZXNzICAoMzIgYml0KXwKICAgICAgICAg ICAgICAgICAgICAgKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsKICAgICAgICAgICAgICAg ICAgICAgfCB0cmVlIGFkZHJlc3MgICAoNjQgYml0KXwKICAgICAgICAgICAgICAgICAgICAg Ky0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsKICAgICAgICAgICAgICAgICAgICAgfCB0eXBl ID0gMiAgICAgICAoMzIgYml0KXwKICAgICAgICAgICAgICAgICAgICAgKy0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLSsKICAgICAgICAgICAgICAgICAgICAgfCBQYWRkaW5nID0gMCAgICAo MzIgYml0KXwKICAgICAgICAgICAgICAgICAgICAgKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LSsKICAgICAgICAgICAgICAgICAgICAgfCB0cmVlIGhlaWdodCAgICAoMzIgYml0KXwKICAg ICAgICAgICAgICAgICAgICAgKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsKICAgICAgICAg ICAgICAgICAgICAgfCB0cmVlIGluZGV4ICAgICAoMzIgYml0KXwKICAgICAgICAgICAgICAg ICAgICAgKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsKICAgICAgICAgICAgICAgICAgICAg fCBrZXlBbmRNYXNrICAgICAoMzIgYml0KXwKICAgICAgICAgICAgICAgICAgICAgKy0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLSsKCiAgIEFsbCBmaWVsZHMgd2l0aGluIHRoZXNlIGFkZHJl c3NlcyBlbmNvZGUgdW5zaWduZWQgaW50ZWdlcnMuICBXaGVuCiAgIGRlc2NyaWJpbmcgdGhl IGdlbmVyYXRpb24gb2YgYWRkcmVzc2VzIHdlIHVzZSBzZXR0ZXIgbWV0aG9kcyB0aGF0CiAg IHRha2UgcG9zaXRpdmUgaW50ZWdlcnMgYW5kIHNldCB0aGUgYml0cyBvZiBhIGZpZWxkIHRv IHRoZSBiaW5hcnkKICAgcmVwcmVzZW50YXRpb24gb2YgdGhhdCBpbnRlZ2VyIG9mIHRoZSBs ZW5ndGggb2YgdGhlIGZpZWxkLiAgV2UKICAgZnVydGhlcm1vcmUgYXNzdW1lIHRoYXQgdGhl IHNldFR5cGUoKSBtZXRob2Qgc2V0cyB0aGUgZm91ciB3b3JkcwogICBmb2xsb3dpbmcgdGhl IHR5cGUgd29yZCB0byB6ZXJvLgoKMi42LiAgU3RyaW5ncyBvZiBCYXNlIHcgTnVtYmVycwoK ICAgQSBieXRlIHN0cmluZyBjYW4gYmUgY29uc2lkZXJlZCBhcyBhIHN0cmluZyBvZiBiYXNl IHcgbnVtYmVycywgaS5lLgogICBpbnRlZ2VycyBpbiB0aGUgc2V0IHswLCAuLi4gLCB3IC0g MX0uICBUaGUgY29ycmVzcG9uZGVuY2UgaXMgZGVmaW5lZAogICBieSB0aGUgZnVuY3Rpb24g YmFzZV93KFgsIHcsIG91dF9sZW4pIGFzIGZvbGxvd3MuICBJZiBYIGlzIGEgbGVuX1gtCiAg IGJ5dGUgc3RyaW5nLCBhbmQgdyBpcyBhIG1lbWJlciBvZiB0aGUgc2V0IHs0LCAxNn0sIHRo ZW4gYmFzZV93KFgsIHcsCiAgIG91dF9sZW4pIG91dHB1dHMgYW4gYXJyYXkgb2Ygb3V0X2xl biBpbnRlZ2VycyBiZXR3ZWVuIDAgYW5kIHcgLSAxLgogICBUaGUgbGVuZ3RoIG91dF9sZW4g aXMgUkVRVUlSRUQgdG8gYmUgbGVzcyB0aGFuIG9yIGVxdWFsIHRvIDggKiBsZW5fWAogICAv IGxnKHcpLgoKCgoKCgoKCgpIdWVsc2luZywgZXQgYWwuICAgICAgICBFeHBpcmVzIEphbnVh cnkgMjUsIDIwMTggICAgICAgICAgICAgICBbUGFnZSAxMF0KDApJbnRlcm5ldC1EcmFmdCAg ICBYTVNTOiBFeHRlbmRlZCBIYXNoLUJhc2VkIFNpZ25hdHVyZXMgICAgICAgICBKdWx5IDIw MTcKCgogICBBbGdvcml0aG0gMTogYmFzZV93CgogICAgIElucHV0OiBsZW5fWC1ieXRlIHN0 cmluZyBYLCBpbnQgdywgb3V0cHV0IGxlbmd0aCBvdXRfbGVuCiAgICAgT3V0cHV0OiBvdXRf bGVuIGludCBhcnJheSBiYXNldwoKICAgICAgIGludCBpbiA9IDA7CiAgICAgICBpbnQgb3V0 ID0gMDsKICAgICAgIHVuc2lnbmVkIGludCB0b3RhbCA9IDA7CiAgICAgICBpbnQgYml0cyA9 IDA7CiAgICAgICBpbnQgY29uc3VtZWQ7CgogICAgICAgZm9yICggY29uc3VtZWQgPSAwOyBj b25zdW1lZCA8IG91dF9sZW47IGNvbnN1bWVkKysgKSB7CiAgICAgICAgICAgaWYgKCBiaXRz ID09IDAgKSB7CiAgICAgICAgICAgICAgIHRvdGFsID0gWFtpbl07CiAgICAgICAgICAgICAg IGluKys7CiAgICAgICAgICAgICAgIGJpdHMgKz0gODsKICAgICAgICAgICB9CiAgICAgICAg ICAgYml0cyAtPSBsZyh3KTsKICAgICAgICAgICBiYXNld1tvdXRdID0gKHRvdGFsID4+IGJp dHMpIEFORCAodyAtIDEpOwogICAgICAgICAgIG91dCsrOwogICAgICAgfQogICAgICAgcmV0 dXJuIGJhc2V3OwoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCkh1ZWxzaW5nLCBldCBh bC4gICAgICAgIEV4cGlyZXMgSmFudWFyeSAyNSwgMjAxOCAgICAgICAgICAgICAgIFtQYWdl IDExXQoMCkludGVybmV0LURyYWZ0ICAgIFhNU1M6IEV4dGVuZGVkIEhhc2gtQmFzZWQgU2ln bmF0dXJlcyAgICAgICAgIEp1bHkgMjAxNwoKCiAgIEZvciBleGFtcGxlLCBpZiBYIGlzIHRo ZSAoYmlnLWVuZGlhbikgYnl0ZSBzdHJpbmcgMHgxMjM0LCB0aGVuCiAgIGJhc2VfdyhYLCAx NiwgNCkgcmV0dXJucyB0aGUgYXJyYXkgYSA9IHsxLCAyLCAzLCA0fS4KCiAgICAgICAgICAg ICAgICAgICAgICBYIChyZXByZXNlbnRlZCBhcyBiaXRzKQogICAgICAgICArLS0rLS0rLS0r LS0rLS0rLS0rLS0rLS0rLS0rLS0rLS0rLS0rLS0rLS0rLS0rLS0rCiAgICAgICAgIHwgMHwg MHwgMHwgMXwgMHwgMHwgMXwgMHwgMHwgMHwgMXwgMXwgMHwgMXwgMHwgMHwKICAgICAgICAg Ky0tKy0tKy0tKy0tKy0tKy0tKy0tKy0tKy0tKy0tKy0tKy0tKy0tKy0tKy0tKy0tKwogICAg ICAgICAgICAgICAgICAgIFhbMF0gICAgICAgICB8ICAgICAgICAgWFsxXQoKICAgICAgICAg ICAgICAgICBYIChyZXByZXNlbnRlZCBhcyBiYXNlIDE2IG51bWJlcnMpCiAgICAgICAgICst LS0tLS0tLS0tLSstLS0tLS0tLS0tLSstLS0tLS0tLS0tLSstLS0tLS0tLS0tLSsKICAgICAg ICAgfCAgICAgMSAgICAgfCAgICAgMiAgICAgfCAgICAgMyAgICAgfCAgICAgNCAgICAgfAog ICAgICAgICArLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0rLS0tLS0tLS0t LS0rCgogICAgICAgICAgICAgICAgICAgICAgICAgIGJhc2VfdyhYLCAxNiwgNCkKICAgICAg ICAgKy0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tKwog ICAgICAgICB8ICAgICAxICAgICB8ICAgICAyICAgICB8ICAgICAzICAgICB8ICAgICA0ICAg ICB8CiAgICAgICAgICstLS0tLS0tLS0tLSstLS0tLS0tLS0tLSstLS0tLS0tLS0tLSstLS0t LS0tLS0tLSsKICAgICAgICAgICAgIGFbMF0gICAgICAgIGFbMV0gICAgICAgIGFbMl0gICAg ICAgIGFbM10KCiAgICAgICAgICAgICAgICAgICAgICAgICAgYmFzZV93KFgsIDE2LCAzKQog ICAgICAgICArLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0rCiAgICAgICAg IHwgICAgIDEgICAgIHwgICAgIDIgICAgIHwgICAgIDMgICAgIHwKICAgICAgICAgKy0tLS0t LS0tLS0tKy0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tKwogICAgICAgICAgICAgYVswXSAgICAg ICAgYVsxXSAgICAgICAgYVsyXQoKICAgICAgICAgICAgICAgICAgICAgICAgICBiYXNlX3co WCwgMTYsIDIpCiAgICAgICAgICstLS0tLS0tLS0tLSstLS0tLS0tLS0tLSsKICAgICAgICAg fCAgICAgMSAgICAgfCAgICAgMiAgICAgfAogICAgICAgICArLS0tLS0tLS0tLS0rLS0tLS0t LS0tLS0rCiAgICAgICAgICAgICBhWzBdICAgICAgICBhWzFdCgoyLjcuICBNZW1iZXIgRnVu Y3Rpb25zCgogICBUbyBzaW1wbGlmeSBhbGdvcml0aG0gZGVzY3JpcHRpb25zLCB3ZSBhc3N1 bWUgdGhlIGV4aXN0ZW5jZSBvZiBtZW1iZXIKICAgZnVuY3Rpb25zLiAgSWYgYSBjb21wbGV4 IGRhdGEgc3RydWN0dXJlIGxpa2UgYSBwdWJsaWMga2V5IFBLIGNvbnRhaW5zCiAgIGEgdmFs dWUgWCB0aGVuIGdldFgoUEspIHJldHVybnMgdGhlIHZhbHVlIG9mIFggZm9yIHRoaXMgcHVi bGljIGtleS4KICAgQWNjb3JkaW5nbHksIHNldFgoUEssIFgsIFkpIHNldHMgdmFsdWUgWCBp biBQSyB0byB0aGUgdmFsdWUgaGVsZCBieQogICBZLiAgU2luY2UgY2FtZWxDYXNlIGlzIHVz ZWQgZm9yIG1lbWJlciBmdW5jdGlvbiBuYW1lcywgYSB2YWx1ZSB6IG1heQogICBiZSByZWZl cnJlZCB0byBhcyBaIGluIHRoZSBmdW5jdGlvbiBuYW1lLCBlLmcuICBnZXRaLgoKMy4gIFBy aW1pdGl2ZXMKCjMuMS4gIFdPVFMrIE9uZS1UaW1lIFNpZ25hdHVyZXMKCiAgIFRoaXMgc2Vj dGlvbiBkZXNjcmliZXMgdGhlIFdPVFMrIE9UUyBzeXN0ZW0sIGluIGEgdmVyc2lvbiBzaW1p bGFyIHRvCiAgIFtIdWVsc2luZzEzXS4gIFdPVFMrIGlzIGEgT1RTIHNjaGVtZTsgd2hpbGUg YSBwcml2YXRlIGtleSBjYW4gYmUgdXNlZAogICB0byBzaWduIGFueSBtZXNzYWdlLCBlYWNo IHByaXZhdGUga2V5IE1VU1QgYmUgdXNlZCBvbmx5IG9uY2UgdG8gc2lnbgoKCgpIdWVsc2lu ZywgZXQgYWwuICAgICAgICBFeHBpcmVzIEphbnVhcnkgMjUsIDIwMTggICAgICAgICAgICAg ICBbUGFnZSAxMl0KDApJbnRlcm5ldC1EcmFmdCAgICBYTVNTOiBFeHRlbmRlZCBIYXNoLUJh c2VkIFNpZ25hdHVyZXMgICAgICAgICBKdWx5IDIwMTcKCgogICBhIHNpbmdsZSBtZXNzYWdl LiAgSW4gcGFydGljdWxhciwgaWYgYSBwcml2YXRlIGtleSBpcyB1c2VkIHRvIHNpZ24KICAg dHdvIGRpZmZlcmVudCBtZXNzYWdlcywgdGhlIHNjaGVtZSBiZWNvbWVzIGluc2VjdXJlLgoK ICAgVGhlIHNlY3Rpb24gc3RhcnRzIHdpdGggYW4gZXhwbGFuYXRpb24gb2YgcGFyYW1ldGVy cy4gIEFmdGVyd2FyZHMsCiAgIHRoZSBzby1jYWxsZWQgY2hhaW5pbmcgZnVuY3Rpb24sIHdo aWNoIGZvcm1zIHRoZSBtYWluIGJ1aWxkaW5nIGJsb2NrCiAgIG9mIHRoZSBXT1RTKyBzY2hl bWUsIGlzIGV4cGxhaW5lZC4gIEEgZGVzY3JpcHRpb24gb2YgdGhlIGFsZ29yaXRobXMKICAg Zm9yIGtleSBnZW5lcmF0aW9uLCBzaWduaW5nIGFuZCB2ZXJpZmljYXRpb24gZm9sbG93cy4g IEZpbmFsbHksCiAgIHBzZXVkb3JhbmRvbSBrZXkgZ2VuZXJhdGlvbiBpcyBkaXNjdXNzZWQu CgozLjEuMS4gIFdPVFMrIFBhcmFtZXRlcnMKCiAgIFdPVFMrIHVzZXMgdGhlIHBhcmFtZXRl cnMgbiwgYW5kIHc7IHRoZXkgYWxsIHRha2UgcG9zaXRpdmUgaW50ZWdlcgogICB2YWx1ZXMu ICBUaGVzZSBwYXJhbWV0ZXJzIGFyZSBzdW1tYXJpemVkIGFzIGZvbGxvd3M6CgogICAgICBu IDogdGhlIG1lc3NhZ2UgbGVuZ3RoIGFzIHdlbGwgYXMgdGhlIGxlbmd0aCBvZiBhIHByaXZh dGUga2V5LAogICAgICBwdWJsaWMga2V5LCBvciBzaWduYXR1cmUgZWxlbWVudCBpbiBieXRl cy4KCiAgICAgIHcgOiB0aGUgV2ludGVybml0eiBwYXJhbWV0ZXI7IGl0IGlzIGEgbWVtYmVy IG9mIHRoZSBzZXQgezQsIDE2fS4KCiAgIFRoZSBwYXJhbWV0ZXJzIGFyZSB1c2VkIHRvIGNv bXB1dGUgdmFsdWVzIGxlbiwgbGVuXzEgYW5kIGxlbl8yOgoKICAgICAgbGVuIDogdGhlIG51 bWJlciBvZiBuLWJ5dGUgc3RyaW5nIGVsZW1lbnRzIGluIGEgV09UUysgcHJpdmF0ZSBrZXks CiAgICAgIHB1YmxpYyBrZXksIGFuZCBzaWduYXR1cmUuICBJdCBpcyBjb21wdXRlZCBhcyBs ZW4gPSBsZW5fMSArIGxlbl8yLAogICAgICB3aXRoIGxlbl8xID0gY2VpbCg4biAvIGxnKHcp KSBhbmQgbGVuXzIgPSBmbG9vcihsZyhsZW5fMSAqICh3IC0KICAgICAgMSkpIC8gbGcodykp ICsgMS4KCiAgIFRoZSB2YWx1ZSBvZiBuIGlzIGRldGVybWluZWQgYnkgdGhlIGNyeXB0b2dy YXBoaWMgaGFzaCBmdW5jdGlvbiB1c2VkCiAgIGZvciBXT1RTKy4gVGhlIGhhc2ggZnVuY3Rp b24gaXMgY2hvc2VuIHRvIGVuc3VyZSBhbiBhcHByb3ByaWF0ZSBsZXZlbAogICBvZiBzZWN1 cml0eS4gIFRoZSB2YWx1ZSBvZiBuIGlzIHRoZSBpbnB1dCBsZW5ndGggdGhhdCBjYW4gYmUK ICAgcHJvY2Vzc2VkIGJ5IHRoZSBzaWduaW5nIGFsZ29yaXRobS4gIEl0IGlzIG9mdGVuIHRo ZSBsZW5ndGggb2YgYQogICBtZXNzYWdlIGRpZ2VzdC4gIFRoZSBwYXJhbWV0ZXIgdyBjYW4g YmUgY2hvc2VuIGZyb20gdGhlIHNldCB7NCwgMTZ9LgogICBBIGxhcmdlciB2YWx1ZSBvZiB3 IHJlc3VsdHMgaW4gc2hvcnRlciBzaWduYXR1cmVzIGJ1dCBzbG93ZXIgb3ZlcmFsbAogICBz aWduaW5nIG9wZXJhdGlvbnM7IGl0IGhhcyBsaXR0bGUgZWZmZWN0IG9uIHNlY3VyaXR5LiAg Q2hvaWNlcyBvZiB3CiAgIGFyZSBsaW1pdGVkIHRvIHRoZSB2YWx1ZXMgNCBhbmQgMTYgc2lu Y2UgdGhlc2UgdmFsdWVzIHlpZWxkIG9wdGltYWwKICAgdHJhZGUtb2ZmcyBhbmQgZWFzeSBp bXBsZW1lbnRhdGlvbi4KCiAgIFdPVFMrIHBhcmFtZXRlcnMgYXJlIGltcGxpY2l0bHkgaW5j bHVkZWQgaW4gYWxnb3JpdGhtIGlucHV0cyBhcwogICBuZWVkZWQuCgozLjEuMS4xLiAgV09U UysgRnVuY3Rpb25zCgogICBUaGUgV09UUysgYWxnb3JpdGhtIHVzZXMgYSBrZXllZCBjcnlw dG9ncmFwaGljIGhhc2ggZnVuY3Rpb24gRi4gIEYKICAgYWNjZXB0cyBhbmQgcmV0dXJucyBi eXRlIHN0cmluZ3Mgb2YgbGVuZ3RoIG4gdXNpbmcga2V5cyBvZiBsZW5ndGggbi4KICAgTW9y ZSBkZXRhaWwgb24gc3BlY2lmaWMgaW5zdGFudGlhdGlvbnMgY2FuIGJlIGZvdW5kIGluIFNl Y3Rpb24gNS4KICAgU2VjdXJpdHkgcmVxdWlyZW1lbnRzIG9uIEYgYXJlIGRpc2N1c3NlZCBp biBTZWN0aW9uIDkuICBJbiBhZGRpdGlvbiwKICAgV09UUysgdXNlcyBhIHBzZXVkb3JhbmRv bSBmdW5jdGlvbiBQUkYuICBQUkYgdGFrZXMgYXMgaW5wdXQgYW4gbi1ieXRlCiAgIGtleSBh bmQgYSAzMi1ieXRlIGluZGV4IGFuZCBnZW5lcmF0ZXMgcHNldWRvcmFuZG9tIG91dHB1dHMg b2YgbGVuZ3RoCgoKCgpIdWVsc2luZywgZXQgYWwuICAgICAgICBFeHBpcmVzIEphbnVhcnkg MjUsIDIwMTggICAgICAgICAgICAgICBbUGFnZSAxM10KDApJbnRlcm5ldC1EcmFmdCAgICBY TVNTOiBFeHRlbmRlZCBIYXNoLUJhc2VkIFNpZ25hdHVyZXMgICAgICAgICBKdWx5IDIwMTcK CgogICBuLiAgTW9yZSBkZXRhaWwgb24gc3BlY2lmaWMgaW5zdGFudGlhdGlvbnMgY2FuIGJl IGZvdW5kIGluIFNlY3Rpb24gNS4KICAgU2VjdXJpdHkgcmVxdWlyZW1lbnRzIG9uIFBSRiBh cmUgZGlzY3Vzc2VkIGluIFNlY3Rpb24gOS4KCjMuMS4yLiAgV09UUysgQ2hhaW5pbmcgRnVu Y3Rpb24KCiAgIFRoZSBjaGFpbmluZyBmdW5jdGlvbiAoQWxnb3JpdGhtIDIpIGNvbXB1dGVz IGFuIGl0ZXJhdGlvbiBvZiBGIG9uIGFuCiAgIG4tYnl0ZSBpbnB1dCB1c2luZyBvdXRwdXRz IG9mIFBSRi4gIEl0IHRha2VzIGFuIE9UUyBoYXNoIGFkZHJlc3MgYXMKICAgaW5wdXQuICBU aGlzIGFkZHJlc3Mgd2lsbCBoYXZlIHRoZSBmaXJzdCBzaXggMzItYml0IHdvcmRzIHNldCB0 bwogICBlbmNvZGUgdGhlIGFkZHJlc3Mgb2YgdGhpcyBjaGFpbi4gIEluIGVhY2ggaXRlcmF0 aW9uLCBQUkYgaXMgdXNlZCB0bwogICBnZW5lcmF0ZSBhIGtleSBmb3IgRiBhbmQgYSBiaXRt YXNrIHRoYXQgaXMgWE9SZWQgdG8gdGhlIGludGVybWVkaWF0ZQogICByZXN1bHQgYmVmb3Jl IGl0IGlzIHByb2Nlc3NlZCBieSBGLiAgSW4gdGhlIGZvbGxvd2luZywgQURSUyBpcyBhCiAg IDMyLWJ5dGUgT1RTIGhhc2ggYWRkcmVzcyBhcyBzcGVjaWZpZWQgaW4gU2VjdGlvbiAyLjUg YW5kIFNFRUQgaXMgYW4KICAgbi1ieXRlIHN0cmluZy4gIFRvIGdlbmVyYXRlIHRoZSBrZXlz IGFuZCBiaXRtYXNrcywgUFJGIGlzIGNhbGxlZCB3aXRoCiAgIFNFRUQgYXMga2V5IGFuZCBB RFJTIGFzIGlucHV0LiAgVGhlIGNoYWluaW5nIGZ1bmN0aW9uIHRha2VzIGFzIGlucHV0CiAg IGFuIG4tYnl0ZSBzdHJpbmcgWCwgYSBzdGFydCBpbmRleCBpLCBhIG51bWJlciBvZiBzdGVw cyBzLCBhcyB3ZWxsIGFzCiAgIEFEUlMgYW5kIFNFRUQuICBUaGUgY2hhaW5pbmcgZnVuY3Rp b24gcmV0dXJucyBhcyBvdXRwdXQgdGhlIHZhbHVlCiAgIG9idGFpbmVkIGJ5IGl0ZXJhdGlu ZyBGIGZvciBzIHRpbWVzIG9uIGlucHV0IFgsIHVzaW5nIHRoZSBvdXRwdXRzIG9mCiAgIFBS Ri4KCiAgIEFsZ29yaXRobSAyOiBjaGFpbiAtIENoYWluaW5nIEZ1bmN0aW9uCgogICAgIElu cHV0OiBJbnB1dCBzdHJpbmcgWCwgc3RhcnQgaW5kZXggaSwgbnVtYmVyIG9mIHN0ZXBzIHMs CiAgICAgc2VlZCBTRUVELCBhZGRyZXNzIEFEUlMKICAgICBPdXRwdXQ6IHZhbHVlIG9mIEYg aXRlcmF0ZWQgcyB0aW1lcyBvbiBYCgogICAgIGlmICggcyA9PSAwICkgewogICAgICAgcmV0 dXJuIFg7CiAgICAgfQogICAgIGlmICggKGkgKyBzKSA+ICh3IC0gMSkgKSB7CiAgICAgICBy ZXR1cm4gTlVMTDsKICAgICB9CiAgICAgYnl0ZVtuXSB0bXAgPSBjaGFpbihYLCBpLCBzIC0g MSwgU0VFRCwgQURSUyk7CgogICAgIEFEUlMuc2V0SGFzaEFkZHJlc3MoaSArIHMgLSAxKTsK ICAgICBBRFJTLnNldEtleUFuZE1hc2soMCk7CiAgICAgS0VZID0gUFJGKFNFRUQsIEFEUlMp OwogICAgIEFEUlMuc2V0S2V5QW5kTWFzaygxKTsKICAgICBCTSA9IFBSRihTRUVELCBBRFJT KTsKCiAgICAgdG1wID0gRihLRVksIHRtcCBYT1IgQk0pOwogICAgIHJldHVybiB0bXA7Cgoz LjEuMy4gIFdPVFMrIFByaXZhdGUgS2V5CgogICBUaGUgcHJpdmF0ZSBrZXkgaW4gV09UUyss IGRlbm90ZWQgYnkgc2sgKHMgZm9yIHNlY3JldCksIGlzIGEgbGVuZ3RoCiAgIGxlbiBhcnJh eSBvZiBuLWJ5dGUgc3RyaW5ncy4gIFRoaXMgcHJpdmF0ZSBrZXkgTVVTVCBiZSBvbmx5IHVz ZWQgdG8KICAgc2lnbiBhdCBtb3N0IG9uZSBtZXNzYWdlLiAgRWFjaCBuLWJ5dGUgc3RyaW5n IE1VU1QgZWl0aGVyIGJlIHNlbGVjdGVkCiAgIHJhbmRvbWx5IGZyb20gdGhlIHVuaWZvcm0g ZGlzdHJpYnV0aW9uIG9yIHVzaW5nIGEgY3J5cHRvZ3JhcGhpY2FsbHkKCgoKSHVlbHNpbmcs IGV0IGFsLiAgICAgICAgRXhwaXJlcyBKYW51YXJ5IDI1LCAyMDE4ICAgICAgICAgICAgICAg W1BhZ2UgMTRdCgwKSW50ZXJuZXQtRHJhZnQgICAgWE1TUzogRXh0ZW5kZWQgSGFzaC1CYXNl ZCBTaWduYXR1cmVzICAgICAgICAgSnVseSAyMDE3CgoKICAgc2VjdXJlIHBzZXVkb3JhbmRv bSBwcm9jZWR1cmUuICBJbiB0aGUgbGF0dGVyIGNhc2UsIHRoZSBzZWN1cml0eSBvZgogICB0 aGUgdXNlZCBwcm9jZWR1cmUgTVVTVCBhdCBsZWFzdCBtYXRjaCB0aGF0IG9mIHRoZSBXT1RT KyBwYXJhbWV0ZXJzCiAgIHVzZWQuICBGb3IgYSBmdXJ0aGVyIGRpc2N1c3Npb24gb24gcHNl dWRvcmFuZG9tIGtleSBnZW5lcmF0aW9uLCBzZWUKICAgU2VjdGlvbiAzLjEuNy4gIFRoZSBm b2xsb3dpbmcgcHNldWRvY29kZSAoQWxnb3JpdGhtIDMpIGRlc2NyaWJlcyBhbgogICBhbGdv cml0aG0gZm9yIGdlbmVyYXRpbmcgc2suCgogICBBbGdvcml0aG0gMzogV09UU19nZW5TSyAt IEdlbmVyYXRpbmcgYSBXT1RTKyBQcml2YXRlIEtleQoKICAgICBJbnB1dDogTm8gaW5wdXQK ICAgICBPdXRwdXQ6IFdPVFMrIHByaXZhdGUga2V5IHNrCgogICAgIGZvciAoIGkgPSAwOyBp IDwgbGVuOyBpKysgKSB7CiAgICAgICBpbml0aWFsaXplIHNrW2ldIHdpdGggYSB1bmlmb3Jt bHkgcmFuZG9tIG4tYnl0ZSBzdHJpbmc7CiAgICAgfQogICAgIHJldHVybiBzazsKCjMuMS40 LiAgV09UUysgUHVibGljIEtleQoKICAgQSBXT1RTKyBrZXkgcGFpciBkZWZpbmVzIGEgdmly dHVhbCBzdHJ1Y3R1cmUgdGhhdCBjb25zaXN0cyBvZiBsZW4KICAgaGFzaCBjaGFpbnMgb2Yg bGVuZ3RoIHcuICBUaGUgbGVuIG4tYnl0ZSBzdHJpbmdzIGluIHRoZSBwcml2YXRlIGtleQog ICBlYWNoIGRlZmluZSB0aGUgc3RhcnQgbm9kZSBmb3Igb25lIGhhc2ggY2hhaW4uICBUaGUg cHVibGljIGtleQogICBjb25zaXN0cyBvZiB0aGUgZW5kIG5vZGVzIG9mIHRoZXNlIGhhc2gg Y2hhaW5zLiAgVGhlcmVmb3JlLCBsaWtlIHRoZQogICBwcml2YXRlIGtleSwgdGhlIHB1Ymxp YyBrZXkgaXMgYWxzbyBhIGxlbmd0aCBsZW4gYXJyYXkgb2Ygbi1ieXRlCiAgIHN0cmluZ3Mu ICBUbyBjb21wdXRlIHRoZSBoYXNoIGNoYWluLCB0aGUgY2hhaW5pbmcgZnVuY3Rpb24gKEFs Z29yaXRobQogICAyKSBpcyB1c2VkLiAgQW4gT1RTIGhhc2ggYWRkcmVzcyBBRFJTIGFuZCBh IHNlZWQgU0VFRCBoYXZlIHRvIGJlCiAgIHByb3ZpZGVkIGJ5IHRoZSBjYWxsaW5nIGFsZ29y aXRobS4gIFRoaXMgYWRkcmVzcyB3aWxsIGVuY29kZSB0aGUKICAgYWRkcmVzcyBvZiB0aGUg V09UUysga2V5IHBhaXIgd2l0aGluIGEgZ3JlYXRlciBzdHJ1Y3R1cmUuICBIZW5jZSwgYQog ICBXT1RTKyBhbGdvcml0aG0gTVVTVCBOT1QgbWFuaXB1bGF0ZSBhbnkgb3RoZXIgcGFydHMg b2YgQURSUyB0aGFuIHRoZQogICBsYXN0IHRocmVlIDMyLWJpdCB3b3Jkcy4gIFBsZWFzZSBu b3RlIHRoYXQgdGhlIFNFRUQgdXNlZCBoZXJlIGlzCiAgIHB1YmxpYyBpbmZvcm1hdGlvbiBh bHNvIGF2YWlsYWJsZSB0byBhIHZlcmlmaWVyLiAgVGhlIGZvbGxvd2luZwogICBwc2V1ZG9j b2RlIChBbGdvcml0aG0gNCkgZGVzY3JpYmVzIGFuIGFsZ29yaXRobSBmb3IgZ2VuZXJhdGlu ZyB0aGUKICAgcHVibGljIGtleSBwaywgd2hlcmUgc2sgaXMgdGhlIHByaXZhdGUga2V5LgoK ICAgQWxnb3JpdGhtIDQ6IFdPVFNfZ2VuUEsgLSBHZW5lcmF0aW5nIGEgV09UUysgUHVibGlj IEtleSBGcm9tIGEKICAgUHJpdmF0ZSBLZXkKCiAgICAgSW5wdXQ6IFdPVFMrIHByaXZhdGUg a2V5IHNrLCBhZGRyZXNzIEFEUlMsIHNlZWQgU0VFRAogICAgIE91dHB1dDogV09UUysgcHVi bGljIGtleSBwawoKICAgICBmb3IgKCBpID0gMDsgaSA8IGxlbjsgaSsrICkgewogICAgICAg QURSUy5zZXRDaGFpbkFkZHJlc3MoaSk7CiAgICAgICBwa1tpXSA9IGNoYWluKHNrW2ldLCAw LCB3IC0gMSwgU0VFRCwgQURSUyk7CiAgICAgfQogICAgIHJldHVybiBwazsKCgoKCgoKCkh1 ZWxzaW5nLCBldCBhbC4gICAgICAgIEV4cGlyZXMgSmFudWFyeSAyNSwgMjAxOCAgICAgICAg ICAgICAgIFtQYWdlIDE1XQoMCkludGVybmV0LURyYWZ0ICAgIFhNU1M6IEV4dGVuZGVkIEhh c2gtQmFzZWQgU2lnbmF0dXJlcyAgICAgICAgIEp1bHkgMjAxNwoKCjMuMS41LiAgV09UUysg U2lnbmF0dXJlIEdlbmVyYXRpb24KCiAgIEEgV09UUysgc2lnbmF0dXJlIGlzIGEgbGVuZ3Ro IGxlbiBhcnJheSBvZiBuLWJ5dGUgc3RyaW5ncy4gIFRoZSBXT1RTKwogICBzaWduYXR1cmUg aXMgZ2VuZXJhdGVkIGJ5IG1hcHBpbmcgYSBtZXNzYWdlIHRvIGxlbiBpbnRlZ2VycyBiZXR3 ZWVuIDAKICAgYW5kIHcgLSAxLiAgVG8gdGhpcyBlbmQsIHRoZSBtZXNzYWdlIGlzIHRyYW5z Zm9ybWVkIGludG8gbGVuXzEgYmFzZSB3CiAgIG51bWJlcnMgdXNpbmcgdGhlIGJhc2VfdyBm dW5jdGlvbiBkZWZpbmVkIGluIFNlY3Rpb24gMi42LiAgTmV4dCwgYQogICBjaGVja3N1bSBp cyBjb21wdXRlZCBhbmQgYXBwZW5kZWQgdG8gdGhlIHRyYW5zZm9ybWVkIG1lc3NhZ2UgYXMg bGVuXzIKICAgYmFzZSB3IG51bWJlcnMgdXNpbmcgdGhlIGJhc2VfdyBmdW5jdGlvbi4gIE5v dGUgdGhhdCB0aGUgY2hlY2tzdW0gbWF5CiAgIHJlYWNoIGEgbWF4aW11bSBpbnRlZ2VyIHZh bHVlIG9mIGxlbl8xICogKHcgLSAxKSAqIDJeOCBhbmQgdGhlcmVmb3JlCiAgIGRlcGVuZHMg b24gdGhlIHBhcmFtZXRlcnMgbiBhbmQgdy4gIEZvciB0aGUgcGFyYW1ldGVyIHNldHMgZ2l2 ZW4gaW4KICAgU2VjdGlvbiA1IGEgMzItYml0IHVuc2lnbmVkIGludGVnZXIgaXMgc3VmZmlj aWVudCB0byBob2xkIHRoZQogICBjaGVja3N1bS4gIElmIG90aGVyIHBhcmFtZXRlciBzZXR0 aW5ncyBhcmUgdXNlZCB0aGUgc2l6ZSBvZiB0aGUKICAgdmFyaWFibGUgaG9sZGluZyB0aGUg aW50ZWdlciB2YWx1ZSBvZiB0aGUgY2hlY2tzdW0gTVVTVCBiZQogICBzdWZmaWNpZW50bHkg bGFyZ2UuICBFYWNoIG9mIHRoZSBiYXNlIHcgaW50ZWdlcnMgaXMgdXNlZCB0byBzZWxlY3Qg YQogICBub2RlIGZyb20gYSBkaWZmZXJlbnQgaGFzaCBjaGFpbi4gIFRoZSBzaWduYXR1cmUg aXMgZm9ybWVkIGJ5CiAgIGNvbmNhdGVuYXRpbmcgdGhlIHNlbGVjdGVkIG5vZGVzLiAgQW4g T1RTIGhhc2ggYWRkcmVzcyBBRFJTIGFuZCBhCiAgIHNlZWQgU0VFRCBoYXZlIHRvIGJlIHBy b3ZpZGVkIGJ5IHRoZSBjYWxsaW5nIGFsZ29yaXRobS4gIFRoaXMgYWRkcmVzcwogICB3aWxs IGVuY29kZSB0aGUgYWRkcmVzcyBvZiB0aGUgV09UUysga2V5IHBhaXIgd2l0aGluIGEgZ3Jl YXRlcgogICBzdHJ1Y3R1cmUuICBIZW5jZSwgYSBXT1RTKyBhbGdvcml0aG0gTVVTVCBOT1Qg bWFuaXB1bGF0ZSBhbnkgb3RoZXIKICAgcGFydHMgb2YgQURSUyB0aGFuIHRoZSBsYXN0IHRo cmVlIDMyLWJpdCB3b3Jkcy4gIFBsZWFzZSBub3RlIHRoYXQgdGhlCiAgIFNFRUQgdXNlZCBo ZXJlIGlzIHB1YmxpYyBpbmZvcm1hdGlvbiBhbHNvIGF2YWlsYWJsZSB0byBhIHZlcmlmaWVy LgogICBUaGUgcHNldWRvY29kZSBmb3Igc2lnbmF0dXJlIGdlbmVyYXRpb24gaXMgc2hvd24g YmVsb3cgKEFsZ29yaXRobSA1KSwKICAgd2hlcmUgTSBpcyB0aGUgbWVzc2FnZSBhbmQgc2ln IGlzIHRoZSByZXN1bHRpbmcgc2lnbmF0dXJlLgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoK CgoKSHVlbHNpbmcsIGV0IGFsLiAgICAgICAgRXhwaXJlcyBKYW51YXJ5IDI1LCAyMDE4ICAg ICAgICAgICAgICAgW1BhZ2UgMTZdCgwKSW50ZXJuZXQtRHJhZnQgICAgWE1TUzogRXh0ZW5k ZWQgSGFzaC1CYXNlZCBTaWduYXR1cmVzICAgICAgICAgSnVseSAyMDE3CgoKICAgQWxnb3Jp dGhtIDU6IFdPVFNfc2lnbiAtIEdlbmVyYXRpbmcgYSBzaWduYXR1cmUgZnJvbSBhIHByaXZh dGUga2V5CiAgIGFuZCBhIG1lc3NhZ2UKCiAgICAgSW5wdXQ6IE1lc3NhZ2UgTSwgV09UUysg cHJpdmF0ZSBrZXkgc2ssIGFkZHJlc3MgQURSUywgc2VlZCBTRUVECiAgICAgT3V0cHV0OiBX T1RTKyBzaWduYXR1cmUgc2lnCgogICAgIGNzdW0gPSAwOwoKICAgICAvLyBDb252ZXJ0IG1l c3NhZ2UgdG8gYmFzZSB3CiAgICAgbXNnID0gYmFzZV93KE0sIHcsIGxlbl8xKTsKCiAgICAg Ly8gQ29tcHV0ZSBjaGVja3N1bQogICAgIGZvciAoIGkgPSAwOyBpIDwgbGVuXzE7IGkrKyAp IHsKICAgICAgICAgICBjc3VtID0gY3N1bSArIHcgLSAxIC0gbXNnW2ldOwogICAgIH0KCiAg ICAgLy8gQ29udmVydCBjc3VtIHRvIGJhc2UgdwogICAgIGNzdW0gPSBjc3VtIDw8ICggOCAt ICggKCBsZW5fMiAqIGxnKHcpICkgJSA4ICkpOwogICAgIGxlbl8yX2J5dGVzID0gY2VpbCgg KCBsZW5fMiAqIGxnKHcpICkgLyA4ICk7CiAgICAgbXNnID0gbXNnIHx8IGJhc2Vfdyh0b0J5 dGUoY3N1bSwgbGVuXzJfYnl0ZXMpLCB3LCBsZW5fMik7CiAgICAgZm9yICggaSA9IDA7IGkg PCBsZW47IGkrKyApIHsKICAgICAgICAgIEFEUlMuc2V0Q2hhaW5BZGRyZXNzKGkpOwogICAg ICAgICAgc2lnW2ldID0gY2hhaW4oc2tbaV0sIDAsIG1zZ1tpXSwgU0VFRCwgQURSUyk7CiAg ICAgfQogICAgIHJldHVybiBzaWc7CgogICBUaGUgZGF0YSBmb3JtYXQgZm9yIGEgc2lnbmF0 dXJlIGlzIGdpdmVuIGJlbG93LgoKICAgV09UUysgU2lnbmF0dXJlCgogICAgICAgICAgICAg Ky0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsKICAgICAgICAgICAgIHwgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8CiAgICAgICAgICAgICB8ICAgICAgICAg ICBzaWdfb3RzWzBdICAgICAgICAgICAgfCAgICBuIGJ5dGVzCiAgICAgICAgICAgICB8ICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfAogICAgICAgICAgICAgKy0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsKICAgICAgICAgICAgIHwgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICB8CiAgICAgICAgICAgICB+ICAgICAgICAgICAgICAuLi4u ICAgICAgICAgICAgICAgfgogICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIHwKICAgICAgICAgICAgICstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0rCiAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg fAogICAgICAgICAgICAgfCAgICAgICAgICBzaWdfb3RzW2xlbiAtIDFdICAgICAgIHwgICAg biBieXRlcwogICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IHwKICAgICAgICAgICAgICstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rCgoK CgoKCgoKSHVlbHNpbmcsIGV0IGFsLiAgICAgICAgRXhwaXJlcyBKYW51YXJ5IDI1LCAyMDE4 ICAgICAgICAgICAgICAgW1BhZ2UgMTddCgwKSW50ZXJuZXQtRHJhZnQgICAgWE1TUzogRXh0 ZW5kZWQgSGFzaC1CYXNlZCBTaWduYXR1cmVzICAgICAgICAgSnVseSAyMDE3CgoKMy4xLjYu ICBXT1RTKyBTaWduYXR1cmUgVmVyaWZpY2F0aW9uCgogICBJbiBvcmRlciB0byB2ZXJpZnkg YSBzaWduYXR1cmUgc2lnIG9uIGEgbWVzc2FnZSBNLCB0aGUgdmVyaWZpZXIKICAgY29tcHV0 ZXMgYSBXT1RTKyBwdWJsaWMga2V5IHZhbHVlIGZyb20gdGhlIHNpZ25hdHVyZS4gIFRoaXMg Y2FuIGJlCiAgIGRvbmUgYnkgImNvbXBsZXRpbmciIHRoZSBjaGFpbiBjb21wdXRhdGlvbnMg c3RhcnRpbmcgZnJvbSB0aGUKICAgc2lnbmF0dXJlIHZhbHVlcywgdXNpbmcgdGhlIGJhc2Ug dyB2YWx1ZXMgb2YgdGhlIG1lc3NhZ2UgaGFzaCBhbmQgaXRzCiAgIGNoZWNrc3VtLiAgVGhp cyBzdGVwLCBjYWxsZWQgV09UU19wa0Zyb21TaWcsIGlzIGRlc2NyaWJlZCBiZWxvdyBpbgog ICBBbGdvcml0aG0gNi4gIFRoZSByZXN1bHQgb2YgV09UU19wa0Zyb21TaWcgaXMgdGhlbiBj b21wYXJlZCB0byB0aGUKICAgZ2l2ZW4gcHVibGljIGtleS4gIElmIHRoZSB2YWx1ZXMgYXJl IGVxdWFsLCB0aGUgc2lnbmF0dXJlIGlzCiAgIGFjY2VwdGVkLiAgT3RoZXJ3aXNlLCB0aGUg c2lnbmF0dXJlIE1VU1QgYmUgcmVqZWN0ZWQuICBBbiBPVFMgaGFzaAogICBhZGRyZXNzIEFE UlMgYW5kIGEgc2VlZCBTRUVEIGhhdmUgdG8gYmUgcHJvdmlkZWQgYnkgdGhlIGNhbGxpbmcK ICAgYWxnb3JpdGhtLiAgVGhpcyBhZGRyZXNzIHdpbGwgZW5jb2RlIHRoZSBhZGRyZXNzIG9m IHRoZSBXT1RTKyBrZXkKICAgcGFpciB3aXRoaW4gYSBncmVhdGVyIHN0cnVjdHVyZS4gIEhl bmNlLCBhIFdPVFMrIGFsZ29yaXRobSBNVVNUIE5PVAogICBtYW5pcHVsYXRlIGFueSBvdGhl ciBwYXJ0cyBvZiBBRFJTIHRoYW4gdGhlIGxhc3QgdGhyZWUgMzItYml0IHdvcmRzLgogICBQ bGVhc2Ugbm90ZSB0aGF0IHRoZSBTRUVEIHVzZWQgaGVyZSBpcyBwdWJsaWMgaW5mb3JtYXRp b24gYWxzbwogICBhdmFpbGFibGUgdG8gYSB2ZXJpZmllci4KCiAgIEFsZ29yaXRobSA2OiBX T1RTX3BrRnJvbVNpZyAtIENvbXB1dGluZyBhIFdPVFMrIHB1YmxpYyBrZXkgZnJvbSBhCiAg IG1lc3NhZ2UgYW5kIGl0cyBzaWduYXR1cmUKCiAgICAgSW5wdXQ6IE1lc3NhZ2UgTSwgV09U Uysgc2lnbmF0dXJlIHNpZywgYWRkcmVzcyBBRFJTLCBzZWVkIFNFRUQKICAgICBPdXRwdXQ6 ICdUZW1wb3JhcnknIFdPVFMrIHB1YmxpYyBrZXkgdG1wX3BrCgogICAgIGNzdW0gPSAwOwoK ICAgICAvLyBDb252ZXJ0IG1lc3NhZ2UgdG8gYmFzZSB3CiAgICAgbXNnID0gYmFzZV93KE0s IHcsIGxlbl8xKTsKCiAgICAgLy8gQ29tcHV0ZSBjaGVja3N1bQogICAgIGZvciAoIGkgPSAw OyBpIDwgbGVuXzE7IGkrKyApIHsKICAgICAgICAgICBjc3VtID0gY3N1bSArIHcgLSAxIC0g bXNnW2ldOwogICAgIH0KCiAgICAgLy8gQ29udmVydCBjc3VtIHRvIGJhc2UgdwogICAgIGNz dW0gPSBjc3VtIDw8ICggOCAtICggKCBsZW5fMiAqIGxnKHcpICkgJSA4ICkpOwogICAgIGxl bl8yX2J5dGVzID0gY2VpbCggKCBsZW5fMiAqIGxnKHcpICkgLyA4ICk7CiAgICAgbXNnID0g bXNnIHx8IGJhc2Vfdyh0b0J5dGUoY3N1bSwgbGVuXzJfYnl0ZXMpLCB3LCBsZW5fMik7CiAg ICAgZm9yICggaSA9IDA7IGkgPCBsZW47IGkrKyApIHsKICAgICAgICAgIEFEUlMuc2V0Q2hh aW5BZGRyZXNzKGkpOwogICAgICAgICAgdG1wX3BrW2ldID0gY2hhaW4oc2lnW2ldLCBtc2db aV0sIHcgLSAxIC0gbXNnW2ldLCBTRUVELCBBRFJTKTsKICAgICB9CiAgICAgcmV0dXJuIHRt cF9wazsKCiAgIE5vdGU6IFhNU1MgdXNlcyBXT1RTX3BrRnJvbVNpZyB0byBjb21wdXRlIGEg cHVibGljIGtleSB2YWx1ZSBhbmQKICAgZGVsYXlzIHRoZSBjb21wYXJpc29uIHRvIGEgbGF0 ZXIgcG9pbnQuCgoKCgoKCkh1ZWxzaW5nLCBldCBhbC4gICAgICAgIEV4cGlyZXMgSmFudWFy eSAyNSwgMjAxOCAgICAgICAgICAgICAgIFtQYWdlIDE4XQoMCkludGVybmV0LURyYWZ0ICAg IFhNU1M6IEV4dGVuZGVkIEhhc2gtQmFzZWQgU2lnbmF0dXJlcyAgICAgICAgIEp1bHkgMjAx NwoKCjMuMS43LiAgUHNldWRvcmFuZG9tIEtleSBHZW5lcmF0aW9uCgogICBBbiBpbXBsZW1l bnRhdGlvbiBNQVkgdXNlIGEgY3J5cHRvZ3JhcGhpY2FsbHkgc2VjdXJlIHBzZXVkb3JhbmRv bQogICBtZXRob2QgdG8gZ2VuZXJhdGUgdGhlIHByaXZhdGUga2V5IGZyb20gYSBzaW5nbGUg bi1ieXRlIHZhbHVlLiAgRm9yCiAgIGV4YW1wbGUsIHRoZSBtZXRob2Qgc3VnZ2VzdGVkIGlu IFtCREgxMV0gYW5kIGV4cGxhaW5lZCBiZWxvdyBNQVkgYmUKICAgdXNlZC4gIE90aGVyIG1l dGhvZHMgTUFZIGJlIHVzZWQuICBUaGUgY2hvaWNlIG9mIGEgcHNldWRvcmFuZG9tCiAgIG1l dGhvZCBkb2VzIG5vdCBhZmZlY3QgaW50ZXJvcGVyYWJpbGl0eSwgYnV0IHRoZSBjcnlwdG9n cmFwaGljCiAgIHN0cmVuZ3RoIE1VU1QgbWF0Y2ggdGhhdCBvZiB0aGUgdXNlZCBXT1RTKyBw YXJhbWV0ZXJzLgoKICAgVGhlIGFkdmFudGFnZSBvZiBnZW5lcmF0aW5nIHRoZSBwcml2YXRl IGtleSBlbGVtZW50cyBmcm9tIGEgcmFuZG9tCiAgIG4tYnl0ZSBzdHJpbmcgaXMgdGhhdCBv bmx5IHRoaXMgbi1ieXRlIHN0cmluZyBuZWVkcyB0byBiZSBzdG9yZWQKICAgaW5zdGVhZCBv ZiB0aGUgZnVsbCBwcml2YXRlIGtleS4gIFRoZSBrZXkgY2FuIGJlIHJlZ2VuZXJhdGVkIHdo ZW4KICAgbmVlZGVkLiAgVGhlIHN1Z2dlc3RlZCBtZXRob2QgZnJvbSBbQkRIMTFdIGNhbiBi ZSBkZXNjcmliZWQgdXNpbmcKICAgUFJGLiAgRHVyaW5nIGtleSBnZW5lcmF0aW9uIGEgdW5p Zm9ybWx5IHJhbmRvbSBuLWJ5dGUgc3RyaW5nIFMgaXMKICAgc2FtcGxlZCBmcm9tIGEgc2Vj dXJlIHNvdXJjZSBvZiByYW5kb21uZXNzLiAgVGhpcyBzdHJpbmcgUyBpcyBzdG9yZWQKICAg YXMgcHJpdmF0ZSBrZXkuICBUaGUgcHJpdmF0ZSBrZXkgZWxlbWVudHMgYXJlIGNvbXB1dGVk IGFzIHNrW2ldID0KICAgUFJGKFMsIHRvQnl0ZShpLCAzMikpIHdoZW5ldmVyIG5lZWRlZC4g IFBsZWFzZSBub3RlIHRoYXQgdGhpcyBzZWVkIFMKICAgTVVTVCBiZSBkaWZmZXJlbnQgZnJv bSB0aGUgc2VlZCBTRUVEIHVzZWQgdG8gcmFuZG9taXplIHRoZSBoYXNoCiAgIGZ1bmN0aW9u IGNhbGxzLiAgQWxzbywgdGhpcyBzZWVkIFMgTVVTVCBiZSBrZXB0IHNlY3JldC4gIFRoZSBz ZWVkIFMKICAgTVVTVCBOT1QgYmUgYSBsb3cgZW50cm9weSwgaHVtYW4tbWVtb3JhYmxlIHZh bHVlIHNpbmNlIHByaXZhdGUga2V5CiAgIGVsZW1lbnRzIGFyZSBkZXJpdmVkIGZyb20gUyBk ZXRlcm1pbmlzdGljYWxseSBhbmQgdGhlaXIKICAgY29uZmlkZW50aWFsaXR5IGlzIHNlY3Vy aXR5LWNyaXRpY2FsLgoKNC4gIFNjaGVtZXMKCiAgIEluIHRoaXMgc2VjdGlvbiwgdGhlIGVY dGVuZGVkIE1lcmtsZSBTaWduYXR1cmUgU2NoZW1lIChYTVNTKSBpcwogICBkZXNjcmliZWQg dXNpbmcgV09UUysuICBYTVNTIGNvbWVzIGluIHR3byBmbGF2b3JzOiBGaXJzdCwgYSBzaW5n bGUtCiAgIHRyZWUgdmFyaWFudCAoWE1TUykgYW5kIHNlY29uZCBhIG11bHRpLXRyZWUgdmFy aWFudCAoWE1TU15NVCkuICBCb3RoCiAgIGFsbG93IGNvbWJpbmluZyBhIGxhcmdlIG51bWJl ciBvZiBXT1RTKyBrZXkgcGFpcnMgdW5kZXIgYSBzaW5nbGUKICAgc21hbGwgcHVibGljIGtl eS4gIFRoZSBtYWluIGluZ3JlZGllbnQgYWRkZWQgaXMgYSBiaW5hcnkgaGFzaCB0cmVlCiAg IGNvbnN0cnVjdGlvbi4gIFhNU1MgdXNlcyBhIHNpbmdsZSBoYXNoIHRyZWUgd2hpbGUgWE1T U15NVCB1c2VzIGEgdHJlZQogICBvZiBYTVNTIGtleSBwYWlycy4KCjQuMS4gIFhNU1M6IGVY dGVuZGVkIE1lcmtsZSBTaWduYXR1cmUgU2NoZW1lCgogICBYTVNTIGlzIGEgbWV0aG9kIGZv ciBzaWduaW5nIGEgcG90ZW50aWFsbHkgbGFyZ2UgYnV0IGZpeGVkIG51bWJlciBvZgogICBt ZXNzYWdlcy4gIEl0IGlzIGJhc2VkIG9uIHRoZSBNZXJrbGUgc2lnbmF0dXJlIHNjaGVtZS4g IFhNU1MgdXNlcwogICBmb3VyIGNyeXB0b2dyYXBoaWMgY29tcG9uZW50czogV09UUysgYXMg T1RTIG1ldGhvZCwgdHdvIGFkZGl0aW9uYWwKICAgY3J5cHRvZ3JhcGhpYyBoYXNoIGZ1bmN0 aW9ucyBIIGFuZCBIX21zZywgYW5kIGEgcHNldWRvcmFuZG9tIGZ1bmN0aW9uCiAgIFBSRi4g IE9uZSBvZiB0aGUgbWFpbiBhZHZhbnRhZ2VzIG9mIFhNU1Mgd2l0aCBXT1RTKyBpcyB0aGF0 IGl0IGRvZXMKICAgbm90IHJlbHkgb24gdGhlIGNvbGxpc2lvbiByZXNpc3RhbmNlIG9mIHRo ZSB1c2VkIGhhc2ggZnVuY3Rpb25zIGJ1dAogICBvbiB3ZWFrZXIgcHJvcGVydGllcy4gIEVh Y2ggWE1TUyBwdWJsaWMvcHJpdmF0ZSBrZXkgcGFpciBpcwogICBhc3NvY2lhdGVkIHdpdGgg YSBwZXJmZWN0IGJpbmFyeSB0cmVlLCBldmVyeSBub2RlIG9mIHdoaWNoIGNvbnRhaW5zCiAg IGFuIG4tYnl0ZSB2YWx1ZS4gIEVhY2ggdHJlZSBsZWFmIGNvbnRhaW5zIGEgc3BlY2lhbCB0 cmVlIGhhc2ggb2YgYQogICBXT1RTKyBwdWJsaWMga2V5IHZhbHVlLiAgRWFjaCBub24tbGVh ZiB0cmVlIG5vZGUgaXMgY29tcHV0ZWQgYnkgZmlyc3QKICAgY29uY2F0ZW5hdGluZyB0aGUg dmFsdWVzIG9mIGl0cyBjaGlsZCBub2RlcywgY29tcHV0aW5nIHRoZSBYT1Igd2l0aCBhCiAg IGJpdG1hc2ssIGFuZCBhcHBseWluZyB0aGUga2V5ZWQgaGFzaCBmdW5jdGlvbiBIIHRvIHRo ZSByZXN1bHQuICBUaGUKICAgYml0bWFza3MgYW5kIHRoZSBrZXlzIGZvciB0aGUgaGFzaCBm dW5jdGlvbiBIIGFyZSBnZW5lcmF0ZWQgZnJvbSBhCgoKCkh1ZWxzaW5nLCBldCBhbC4gICAg ICAgIEV4cGlyZXMgSmFudWFyeSAyNSwgMjAxOCAgICAgICAgICAgICAgIFtQYWdlIDE5XQoM CkludGVybmV0LURyYWZ0ICAgIFhNU1M6IEV4dGVuZGVkIEhhc2gtQmFzZWQgU2lnbmF0dXJl cyAgICAgICAgIEp1bHkgMjAxNwoKCiAgIChwdWJsaWMpIHNlZWQgdGhhdCBpcyBwYXJ0IG9m IHRoZSBwdWJsaWMga2V5IHVzaW5nIHRoZSBwc2V1ZG9yYW5kb20KICAgZnVuY3Rpb24gUFJG LiAgVGhlIHZhbHVlIGNvcnJlc3BvbmRpbmcgdG8gdGhlIHJvb3Qgb2YgdGhlIFhNU1MgdHJl ZQogICBmb3JtcyB0aGUgWE1TUyBwdWJsaWMga2V5IHRvZ2V0aGVyIHdpdGggdGhlIHNlZWQu CgogICBUbyBnZW5lcmF0ZSBhIGtleSBwYWlyIHRoYXQgY2FuIGJlIHVzZWQgdG8gc2lnbiAy XmggbWVzc2FnZXMsIGEgdHJlZQogICBvZiBoZWlnaHQgaCBpcyB1c2VkLiAgWE1TUyBpcyBh IHN0YXRlZnVsIHNpZ25hdHVyZSBzY2hlbWUsIG1lYW5pbmcKICAgdGhhdCB0aGUgcHJpdmF0 ZSBrZXkgY2hhbmdlcyB3aXRoIGV2ZXJ5IHNpZ25hdHVyZSBnZW5lcmF0aW9uLiAgVG8KICAg cHJldmVudCBvbmUtdGltZSBwcml2YXRlIGtleXMgZnJvbSBiZWluZyB1c2VkIHR3aWNlLCB0 aGUgV09UUysga2V5CiAgIHBhaXJzIGFyZSBudW1iZXJlZCBmcm9tIDAgdG8gKDJeaCkgLSAx IGFjY29yZGluZyB0byB0aGUgcmVsYXRlZCBsZWFmLAogICBzdGFydGluZyBmcm9tIGluZGV4 IDAgZm9yIHRoZSBsZWZ0bW9zdCBsZWFmLiAgVGhlIHByaXZhdGUga2V5CiAgIGNvbnRhaW5z IGFuIGluZGV4IHRoYXQgaXMgdXBkYXRlZCB3aXRoIGV2ZXJ5IHNpZ25hdHVyZSBnZW5lcmF0 aW9uLAogICBzdWNoIHRoYXQgaXQgY29udGFpbnMgdGhlIGluZGV4IG9mIHRoZSBuZXh0IHVu dXNlZCBXT1RTKyBrZXkgcGFpci4KCiAgIEEgc2lnbmF0dXJlIGNvbnNpc3RzIG9mIHRoZSBp bmRleCBvZiB0aGUgdXNlZCBXT1RTKyBrZXkgcGFpciwgdGhlCiAgIFdPVFMrIHNpZ25hdHVy ZSBvbiB0aGUgbWVzc2FnZSBhbmQgdGhlIHNvLWNhbGxlZCBhdXRoZW50aWNhdGlvbiBwYXRo LgogICBUaGUgbGF0dGVyIGlzIGEgdmVjdG9yIG9mIHRyZWUgbm9kZXMgdGhhdCBhbGxvdyBh IHZlcmlmaWVyIHRvIGNvbXB1dGUKICAgYSB2YWx1ZSBmb3IgdGhlIHJvb3Qgb2YgdGhlIHRy ZWUgc3RhcnRpbmcgZnJvbSBhIFdPVFMrIHNpZ25hdHVyZS4gIEEKICAgdmVyaWZpZXIgY29t cHV0ZXMgdGhlIHJvb3QgdmFsdWUgYW5kIGNvbXBhcmVzIGl0IHRvIHRoZSByZXNwZWN0aXZl CiAgIHZhbHVlIGluIHRoZSBYTVNTIHB1YmxpYyBrZXkuICBJZiB0aGV5IG1hdGNoLCB0aGUg c2lnbmF0dXJlIGlzCiAgIGRlY2xhcmVkIHZhbGlkLiAgVGhlIFhNU1MgcHJpdmF0ZSBrZXkg Y29uc2lzdHMgb2YgYWxsIFdPVFMrIHByaXZhdGUKICAga2V5cyBhbmQgdGhlIGN1cnJlbnQg aW5kZXguICBUbyByZWR1Y2Ugc3RvcmFnZSwgYSBwc2V1ZG9yYW5kb20ga2V5CiAgIGdlbmVy YXRpb24gcHJvY2VkdXJlLCBhcyBkZXNjcmliZWQgaW4gW0JESDExXSwgTUFZIGJlIHVzZWQu ICBUaGUKICAgc2VjdXJpdHkgb2YgdGhlIHVzZWQgbWV0aG9kIE1VU1QgYXQgbGVhc3QgbWF0 Y2ggdGhlIHNlY3VyaXR5IG9mIHRoZQogICBYTVNTIGluc3RhbmNlLgoKNC4xLjEuICBYTVNT IFBhcmFtZXRlcnMKCiAgIFhNU1MgaGFzIHRoZSBmb2xsb3dpbmcgcGFyYW1ldGVyczoKCiAg ICAgIGggOiB0aGUgaGVpZ2h0IChudW1iZXIgb2YgbGV2ZWxzIC0gMSkgb2YgdGhlIHRyZWUK CiAgICAgIG4gOiB0aGUgbGVuZ3RoIGluIGJ5dGVzIG9mIHRoZSBtZXNzYWdlIGRpZ2VzdCBh cyB3ZWxsIGFzIG9mIGVhY2gKICAgICAgbm9kZQoKICAgICAgdyA6IHRoZSBXaW50ZXJuaXR6 IHBhcmFtZXRlciBhcyBkZWZpbmVkIGZvciBXT1RTKyBpbiBTZWN0aW9uIDMuMQoKICAgVGhl cmUgYXJlIDJeaCBsZWF2ZXMgaW4gdGhlIHRyZWUuCgogICBGb3IgWE1TUyBhbmQgWE1TU15N VCwgcHJpdmF0ZSBhbmQgcHVibGljIGtleXMgYXJlIGRlbm90ZWQgYnkgU0sgKFMKICAgZm9y IHNlY3JldCkgYW5kIFBLLiAgRm9yIFdPVFMrLCBwcml2YXRlIGFuZCBwdWJsaWMga2V5cyBh cmUgZGVub3RlZAogICBieSBzayAocyBmb3Igc2VjcmV0KSBhbmQgcGssIHJlc3BlY3RpdmVs eS4gIFhNU1MgYW5kIFhNU1NeTVQKICAgc2lnbmF0dXJlcyBhcmUgZGVub3RlZCBieSBTaWcu ICBXT1RTKyBzaWduYXR1cmVzIGFyZSBkZW5vdGVkIGJ5IHNpZy4KCiAgIFhNU1MgYW5kIFhN U1NeTVQgcGFyYW1ldGVycyBhcmUgaW1wbGljaXRseSBpbmNsdWRlZCBpbiBhbGdvcml0aG0K ICAgaW5wdXRzIGFzIG5lZWRlZC4KCgoKCgoKSHVlbHNpbmcsIGV0IGFsLiAgICAgICAgRXhw aXJlcyBKYW51YXJ5IDI1LCAyMDE4ICAgICAgICAgICAgICAgW1BhZ2UgMjBdCgwKSW50ZXJu ZXQtRHJhZnQgICAgWE1TUzogRXh0ZW5kZWQgSGFzaC1CYXNlZCBTaWduYXR1cmVzICAgICAg ICAgSnVseSAyMDE3CgoKNC4xLjIuICBYTVNTIEhhc2ggRnVuY3Rpb25zCgogICBCZXNpZGVz IHRoZSBjcnlwdG9ncmFwaGljIGhhc2ggZnVuY3Rpb24gRiBhbmQgdGhlIHBzZXVkb3JhbmRv bQogICBmdW5jdGlvbiBQUkYgcmVxdWlyZWQgYnkgV09UUyssIFhNU1MgdXNlcyB0d28gbW9y ZSBmdW5jdGlvbnM6CgogICAgICBBIGNyeXB0b2dyYXBoaWMgaGFzaCBmdW5jdGlvbiBILiAg SCBhY2NlcHRzIG4tYnl0ZSBrZXlzIGFuZCBieXRlCiAgICAgIHN0cmluZ3Mgb2YgbGVuZ3Ro IDJuIGFuZCByZXR1cm5zIGFuIG4tYnl0ZSBzdHJpbmcuCgogICAgICBBIGNyeXB0b2dyYXBo aWMgaGFzaCBmdW5jdGlvbiBIX21zZy4gIEhfbXNnIGFjY2VwdHMgM24tYnl0ZSBrZXlzCiAg ICAgIGFuZCBieXRlIHN0cmluZ3Mgb2YgYXJiaXRyYXJ5IGxlbmd0aCBhbmQgcmV0dXJucyBh biBuLWJ5dGUgc3RyaW5nLgoKICAgTW9yZSBkZXRhaWwgb24gc3BlY2lmaWMgaW5zdGFudGlh dGlvbnMgY2FuIGJlIGZvdW5kIGluIFNlY3Rpb24gNS4KICAgU2VjdXJpdHkgcmVxdWlyZW1l bnRzIG9uIEggYW5kIEhfbXNnIGFyZSBkaXNjdXNzZWQgaW4gU2VjdGlvbiA5LgoKNC4xLjMu ICBYTVNTIFByaXZhdGUgS2V5CgogICBBbiBYTVNTIHByaXZhdGUga2V5IFNLIGNvbnRhaW5z IDJeaCBXT1RTKyBwcml2YXRlIGtleXMsIHRoZSBsZWFmCiAgIGluZGV4IGlkeCBvZiB0aGUg bmV4dCBXT1RTKyBwcml2YXRlIGtleSB0aGF0IGhhcyBub3QgeWV0IGJlZW4gdXNlZCwKICAg U0tfUFJGLCBhbiBuLWJ5dGUga2V5IHRvIGdlbmVyYXRlIHBzZXVkb3JhbmRvbSB2YWx1ZXMg Zm9yIHJhbmRvbWl6ZWQKICAgbWVzc2FnZSBoYXNoaW5nLCB0aGUgbi1ieXRlIHZhbHVlIHJv b3QsIHdoaWNoIGlzIHRoZSByb290IG5vZGUgb2YgdGhlCiAgIHRyZWUgYW5kIFNFRUQsIHRo ZSBuLWJ5dGUgcHVibGljIHNlZWQgdXNlZCB0byBwc2V1ZG9yYW5kb21seSBnZW5lcmF0ZQog ICBiaXRtYXNrcyBhbmQgaGFzaCBmdW5jdGlvbiBrZXlzLiAgQWx0aG91Z2ggcm9vdCBhbmQg U0VFRCBmb3JtYWxseQogICB3b3VsZCBiZSBjb25zaWRlcmVkIG9ubHkgcGFydCBvZiB0aGUg cHVibGljIGtleSwgdGhleSBhcmUgbmVlZGVkIGUuZy4KICAgZm9yIHNpZ25hdHVyZSBnZW5l cmF0aW9uIGFuZCBoZW5jZSBhcmUgYWxzbyByZXF1aXJlZCBmb3IgZnVuY3Rpb25zCiAgIHRo YXQgZG8gbm90IHRha2UgdGhlIHB1YmxpYyBrZXkgYXMgaW5wdXQuCgogICBUaGUgbGVhZiBp bmRleCBpZHggaXMgaW5pdGlhbGl6ZWQgdG8gemVybyB3aGVuIHRoZSBYTVNTIHByaXZhdGUg a2V5CiAgIGlzIGNyZWF0ZWQuICBUaGUga2V5IFNLX1BSRiBNVVNUIGJlIHNhbXBsZWQgZnJv bSBhIHNlY3VyZSBzb3VyY2Ugb2YKICAgcmFuZG9tbmVzcyB0aGF0IGZvbGxvd3MgdGhlIHVu aWZvcm0gZGlzdHJpYnV0aW9uLiAgVGhlIFdPVFMrIHByaXZhdGUKICAga2V5cyBNVVNUIGVp dGhlciBiZSBnZW5lcmF0ZWQgYXMgZGVzY3JpYmVkIGluIFNlY3Rpb24gMy4xIG9yLCB0bwog ICByZWR1Y2UgdGhlIHByaXZhdGUga2V5IHNpemUsIGEgY3J5cHRvZ3JhcGhpYyBwc2V1ZG9y YW5kb20gbWV0aG9kIE1VU1QKICAgYmUgdXNlZCBhcyBkaXNjdXNzZWQgaW4gU2VjdGlvbiA0 LjEuMTEuICBTRUVEIGlzIGdlbmVyYXRlZCBhcyBhCiAgIHVuaWZvcm1seSByYW5kb20gbi1i eXRlIHN0cmluZy4gIEFsdGhvdWdoIFNFRUQgaXMgcHVibGljLCBpdCBpcwogICBjcml0aWNh bCBmb3Igc2VjdXJpdHkgdGhhdCBpdCBpcyBnZW5lcmF0ZWQgdXNpbmcgYSBnb29kIGVudHJv cHkKICAgc291cmNlLiAgVGhlIHJvb3Qgbm9kZSBpcyBnZW5lcmF0ZWQgYXMgZGVzY3JpYmVk IGJlbG93IGluIHRoZSBzZWN0aW9uCiAgIG9uIGtleSBnZW5lcmF0aW9uIChTZWN0aW9uIDQu MS43KS4gIFRoYXQgc2VjdGlvbiBhbHNvIGNvbnRhaW5zIGFuCiAgIGV4YW1wbGUgYWxnb3Jp dGhtIGZvciBjb21iaW5lZCBwcml2YXRlIGFuZCBwdWJsaWMga2V5IGdlbmVyYXRpb24uCgog ICBGb3IgdGhlIGZvbGxvd2luZyBhbGdvcml0aG0gZGVzY3JpcHRpb25zLCB0aGUgZXhpc3Rl bmNlIG9mIGEgbWV0aG9kCiAgIGdldFdPVFNfU0soU0ssIGkpIGlzIGFzc3VtZWQuICBUaGlz IG1ldGhvZCB0YWtlcyBhcyBpbnB1dHMgYW4gWE1TUwogICBwcml2YXRlIGtleSBTSyBhbmQg YW4gaW50ZWdlciBpIGFuZCBvdXRwdXRzIHRoZSBpXnRoIFdPVFMrIHByaXZhdGUKICAga2V5 IG9mIFNLLgoKNC4xLjQuICBSYW5kb21pemVkIFRyZWUgSGFzaGluZwoKICAgVG8gaW1wcm92 ZSByZWFkYWJpbGl0eSB3ZSBpbnRyb2R1Y2UgYSBmdW5jdGlvbiBSQU5EX0hBU0goTEVGVCwg UklHSFQsCiAgIFNFRUQsIEFEUlMpIHRoYXQgZG9lcyB0aGUgcmFuZG9taXplZCBoYXNoaW5n IGluIHRoZSB0cmVlLiAgSXQgdGFrZXMKICAgYXMgaW5wdXQgdHdvIG4tYnl0ZSB2YWx1ZXMg TEVGVCBhbmQgUklHSFQgdGhhdCByZXByZXNlbnQgdGhlIGxlZnQgYW5kCgoKCkh1ZWxzaW5n LCBldCBhbC4gICAgICAgIEV4cGlyZXMgSmFudWFyeSAyNSwgMjAxOCAgICAgICAgICAgICAg IFtQYWdlIDIxXQoMCkludGVybmV0LURyYWZ0ICAgIFhNU1M6IEV4dGVuZGVkIEhhc2gtQmFz ZWQgU2lnbmF0dXJlcyAgICAgICAgIEp1bHkgMjAxNwoKCiAgIHRoZSByaWdodCBoYWxmIG9m IHRoZSBoYXNoIGZ1bmN0aW9uIGlucHV0LCB0aGUgc2VlZCBTRUVEIHVzZWQgYXMga2V5CiAg IGZvciBQUkYgYW5kIHRoZSBhZGRyZXNzIEFEUlMgb2YgdGhpcyBoYXNoIGZ1bmN0aW9uIGNh bGwuICBSQU5EX0hBU0gKICAgZmlyc3QgdXNlcyBQUkYgd2l0aCBTRUVEIGFuZCBBRFJTIHRv IGdlbmVyYXRlIGEga2V5IEtFWSBhbmQgbi1ieXRlCiAgIGJpdG1hc2tzIEJNXzAsIEJNXzEu ICBUaGVuIGl0IHJldHVybnMgdGhlIHJhbmRvbWl6ZWQgaGFzaCBIKEtFWSwKICAgKExFRlQg WE9SIEJNXzApIHx8IChSSUdIVCBYT1IgQk1fMSkpLgoKICAgQWxnb3JpdGhtIDc6IFJBTkRf SEFTSAoKICAgICBJbnB1dDogIG4tYnl0ZSB2YWx1ZSBMRUZULCBuLWJ5dGUgdmFsdWUgUklH SFQsIHNlZWQgU0VFRCwKICAgICAgICAgICAgIGFkZHJlc3MgQURSUwogICAgIE91dHB1dDog bi1ieXRlIHJhbmRvbWl6ZWQgaGFzaAoKICAgICBBRFJTLnNldEtleUFuZE1hc2soMCk7CiAg ICAgS0VZID0gUFJGKFNFRUQsIEFEUlMpOwogICAgIEFEUlMuc2V0S2V5QW5kTWFzaygxKTsK ICAgICBCTV8wID0gUFJGKFNFRUQsIEFEUlMpOwogICAgIEFEUlMuc2V0S2V5QW5kTWFzaygy KTsKICAgICBCTV8xID0gUFJGKFNFRUQsIEFEUlMpOwoKICAgICByZXR1cm4gSChLRVksIChM RUZUIFhPUiBCTV8wKSB8fCAoUklHSFQgWE9SIEJNXzEpKTsKCjQuMS41LiAgTC1UcmVlcwoK ICAgVG8gY29tcHV0ZSB0aGUgbGVhdmVzIG9mIHRoZSBiaW5hcnkgaGFzaCB0cmVlLCBhIHNv LWNhbGxlZCBMLXRyZWUgaXMKICAgdXNlZC4gIEFuIEwtdHJlZSBpcyBhbiB1bmJhbGFuY2Vk IGJpbmFyeSBoYXNoIHRyZWUsIGRpc3RpbmN0IGJ1dAogICBzaW1pbGFyIHRvIHRoZSBtYWlu IFhNU1MgYmluYXJ5IGhhc2ggdHJlZS4gIFRoZSBhbGdvcml0aG0gbHRyZWUKICAgKEFsZ29y aXRobSA4KSB0YWtlcyBhcyBpbnB1dCBhIFdPVFMrIHB1YmxpYyBrZXkgcGsgYW5kIGNvbXBy ZXNzZXMgaXQKICAgdG8gYSBzaW5nbGUgbi1ieXRlIHZhbHVlIHBrWzBdLiAgVG93YXJkcyB0 aGlzIGVuZCBpdCBhbHNvIHRha2VzIGFuCiAgIEwtdHJlZSBhZGRyZXNzIEFEUlMgYXMgaW5w dXQgdGhhdCBlbmNvZGVzIHRoZSBhZGRyZXNzIG9mIHRoZSBMLXRyZWUsCiAgIGFuZCB0aGUg c2VlZCBTRUVELgoKCgoKCgoKCgoKCgoKCgoKCgoKCgpIdWVsc2luZywgZXQgYWwuICAgICAg ICBFeHBpcmVzIEphbnVhcnkgMjUsIDIwMTggICAgICAgICAgICAgICBbUGFnZSAyMl0KDApJ bnRlcm5ldC1EcmFmdCAgICBYTVNTOiBFeHRlbmRlZCBIYXNoLUJhc2VkIFNpZ25hdHVyZXMg ICAgICAgICBKdWx5IDIwMTcKCgogICBBbGdvcml0aG0gODogbHRyZWUKCiAgICAgSW5wdXQ6 IFdPVFMrIHB1YmxpYyBrZXkgcGssIGFkZHJlc3MgQURSUywgc2VlZCBTRUVECiAgICAgT3V0 cHV0OiBuLWJ5dGUgY29tcHJlc3NlZCBwdWJsaWMga2V5IHZhbHVlIHBrWzBdCgogICAgIHVu c2lnbmVkIGludCBsZW4nID0gbGVuOwogICAgIEFEUlMuc2V0VHJlZUhlaWdodCgwKTsKICAg ICB3aGlsZSAoIGxlbicgPiAxICkgewogICAgICAgZm9yICggaSA9IDA7IGkgPCBmbG9vcihs ZW4nIC8gMik7IGkrKyApIHsKICAgICAgICAgQURSUy5zZXRUcmVlSW5kZXgoaSk7CiAgICAg ICAgIHBrW2ldID0gUkFORF9IQVNIKHBrWzJpXSwgcGtbMmkgKyAxXSwgU0VFRCwgQURSUyk7 CiAgICAgICB9CiAgICAgICBpZiAoIGxlbicgJSAyID09IDEgKSB7CiAgICAgICAgIHBrW2Zs b29yKGxlbicgLyAyKV0gPSBwa1tsZW4nIC0gMV07CiAgICAgICB9CiAgICAgICBsZW4nID0g Y2VpbChsZW4nIC8gMik7CiAgICAgICBBRFJTLnNldFRyZWVIZWlnaHQoQURSUy5nZXRUcmVl SGVpZ2h0KCkgKyAxKTsKICAgICB9CiAgICAgcmV0dXJuIHBrWzBdOwoKNC4xLjYuICBUcmVl SGFzaAoKICAgRm9yIHRoZSBjb21wdXRhdGlvbiBvZiB0aGUgaW50ZXJuYWwgbi1ieXRlIG5v ZGVzIG9mIGEgTWVya2xlIHRyZWUsCiAgIHRoZSBzdWJyb3V0aW5lIHRyZWVIYXNoIChBbGdv cml0aG0gOSkgYWNjZXB0cyBhbiBYTVNTIHByaXZhdGUga2V5IFNLCiAgIChpbmNsdWRpbmcg c2VlZCBTRUVEKSwgYW4gdW5zaWduZWQgaW50ZWdlciBzICh0aGUgc3RhcnQgaW5kZXgpLCBh bgogICB1bnNpZ25lZCBpbnRlZ2VyIHQgKHRoZSB0YXJnZXQgbm9kZSBoZWlnaHQpLCBhbmQg YW4gYWRkcmVzcyBBRFJTIHRoYXQKICAgZW5jb2RlcyB0aGUgYWRkcmVzcyBvZiB0aGUgY29u dGFpbmluZyB0cmVlLiAgRm9yIHRoZSBoZWlnaHQgb2YgYSBub2RlCiAgIHdpdGhpbiBhIHRy ZWUgY291bnRpbmcgc3RhcnRzIHdpdGggdGhlIGxlYXZlcyBhdCBoZWlnaHQgemVyby4gIFRo ZQogICB0cmVlSGFzaCBhbGdvcml0aG0gcmV0dXJucyB0aGUgcm9vdCBub2RlIG9mIGEgdHJl ZSBvZiBoZWlnaHQgdCB3aXRoCiAgIHRoZSBsZWZ0bW9zdCBsZWFmIGJlaW5nIHRoZSBoYXNo IG9mIHRoZSBXT1RTKyBwayB3aXRoIGluZGV4IHMuICBJdCBpcwogICBSRVFVSVJFRCB0aGF0 IHMgJSAyXnQgPSAwLCBpLmUuIHRoYXQgdGhlIGxlYWYgYXQgaW5kZXggcyBpcyBhCiAgIGxl ZnRtb3N0IGxlYWYgb2YgYSBzdWItdHJlZSBvZiBoZWlnaHQgdC4gIE90aGVyd2lzZSB0aGUg aGFzaC0KICAgYWRkcmVzc2luZyBzY2hlbWUgZmFpbHMuICBUaGUgdHJlZUhhc2ggYWxnb3Jp dGhtIGRlc2NyaWJlZCBoZXJlIHVzZXMKICAgYSBzdGFjayBob2xkaW5nIHVwIHRvICh0IC0g MSkgbm9kZXMsIHdpdGggdGhlIHVzdWFsIHN0YWNrIGZ1bmN0aW9ucwogICBwdXNoKCkgYW5k IHBvcCgpLiAgV2UgZnVydGhlcm1vcmUgYXNzdW1lIHRoYXQgdGhlIGhlaWdodCBvZiBhIG5v ZGUKICAgKGFuIHVuc2lnbmVkIGludGVnZXIpIGlzIHN0b3JlZCBhbG9uZ3NpZGUgYSBub2Rl J3MgdmFsdWUgKGFuIG4tYnl0ZQogICBzdHJpbmcpIG9uIHRoZSBzdGFjay4KCgoKCgoKCgoK CgoKCgpIdWVsc2luZywgZXQgYWwuICAgICAgICBFeHBpcmVzIEphbnVhcnkgMjUsIDIwMTgg ICAgICAgICAgICAgICBbUGFnZSAyM10KDApJbnRlcm5ldC1EcmFmdCAgICBYTVNTOiBFeHRl bmRlZCBIYXNoLUJhc2VkIFNpZ25hdHVyZXMgICAgICAgICBKdWx5IDIwMTcKCgogICBBbGdv cml0aG0gOTogdHJlZUhhc2gKCiAgICAgSW5wdXQ6IFhNU1MgcHJpdmF0ZSBrZXkgU0ssIHN0 YXJ0IGluZGV4IHMsIHRhcmdldCBub2RlIGhlaWdodCB0LAogICAgICAgICAgICBhZGRyZXNz IEFEUlMKICAgICBPdXRwdXQ6IG4tYnl0ZSByb290IG5vZGUgLSB0b3Agbm9kZSBvbiBTdGFj awoKICAgICBpZiggcyAlICgxIDw8IHQpICE9IDAgKSByZXR1cm4gLTE7CiAgICAgZm9yICgg aSA9IDA7IGkgPCAyXnQ7IGkrKyApIHsKICAgICAgIFNFRUQgPSBnZXRTRUVEKFNLKTsKICAg ICAgIEFEUlMuc2V0VHlwZSgwKTsgICAvLyBUeXBlID0gT1RTIGhhc2ggYWRkcmVzcwogICAg ICAgQURSUy5zZXRPVFNBZGRyZXNzKHMgKyBpKTsKICAgICAgIHBrID0gV09UU19nZW5QSyAo Z2V0V09UU19TSyhTSywgcyArIGkpLCBTRUVELCBBRFJTKTsKICAgICAgIEFEUlMuc2V0VHlw ZSgxKTsgICAvLyBUeXBlID0gTC10cmVlIGFkZHJlc3MKICAgICAgIEFEUlMuc2V0TFRyZWVB ZGRyZXNzKHMgKyBpKTsKICAgICAgIG5vZGUgPSBsdHJlZShwaywgU0VFRCwgQURSUyk7CiAg ICAgICBBRFJTLnNldFR5cGUoMik7ICAgLy8gVHlwZSA9IGhhc2ggdHJlZSBhZGRyZXNzCiAg ICAgICBBRFJTLnNldFRyZWVIZWlnaHQoMCk7CiAgICAgICBBRFJTLnNldFRyZWVJbmRleChp ICsgcyk7CiAgICAgICB3aGlsZSAoIFRvcCBub2RlIG9uIFN0YWNrIGhhcyBzYW1lIGhlaWdo dCB0JyBhcyBub2RlICkgewogICAgICAgICAgQURSUy5zZXRUcmVlSW5kZXgoKEFEUlMuZ2V0 VHJlZUluZGV4KCkgLSAxKSAvIDIpOwogICAgICAgICAgbm9kZSA9IFJBTkRfSEFTSChTdGFj ay5wb3AoKSwgbm9kZSwgU0VFRCwgQURSUyk7CiAgICAgICAgICBBRFJTLnNldFRyZWVIZWln aHQoQURSUy5nZXRUcmVlSGVpZ2h0KCkgKyAxKTsKICAgICAgIH0KICAgICAgIFN0YWNrLnB1 c2gobm9kZSk7CiAgICAgfQogICAgIHJldHVybiBTdGFjay5wb3AoKTsKCjQuMS43LiAgWE1T UyBLZXkgR2VuZXJhdGlvbgoKICAgVGhlIFhNU1Mga2V5IHBhaXIgaXMgY29tcHV0ZWQgYXMg ZGVzY3JpYmVkIGluIFhNU1Nfa2V5R2VuIChBbGdvcml0aG0KICAgMTApLiAgVGhlIFhNU1Mg cHVibGljIGtleSBQSyBjb25zaXN0cyBvZiB0aGUgcm9vdCBvZiB0aGUgYmluYXJ5IGhhc2gK ICAgdHJlZSBhbmQgdGhlIHNlZWQgU0VFRCwgYm90aCBhbHNvIHN0b3JlZCBpbiBTSy4gIFRo ZSByb290IGlzIGNvbXB1dGVkCiAgIHVzaW5nIHRyZWVIYXNoLiAgRm9yIFhNU1MsIHRoZXJl IGlzIG9ubHkgYSBzaW5nbGUgbWFpbiB0cmVlLiAgSGVuY2UsCiAgIHRoZSB1c2VkIGFkZHJl c3MgaXMgc2V0IHRvIHRoZSBhbGwtemVybyBzdHJpbmcgaW4gdGhlIGJlZ2lubmluZy4KICAg Tm90ZSB0aGF0IHdlIGRvIG5vdCBkZWZpbmUgYW55IHNwZWNpZmljIGZvcm1hdCBvciBoYW5k bGluZyBmb3IgdGhlCiAgIFhNU1MgcHJpdmF0ZSBrZXkgU0sgYnkgaW50cm9kdWNpbmcgdGhp cyBhbGdvcml0aG0uICBJdCByZWxhdGVzIHRvCiAgIHJlcXVpcmVtZW50cyBkZXNjcmliZWQg ZWFybGllciBhbmQgc2ltcGx5IHNob3dzIGEgYmFzaWMgYnV0IHZlcnkKICAgaW5lZmZpY2ll bnQgZXhhbXBsZSB0byBpbml0aWFsaXplIGEgcHJpdmF0ZSBrZXkuCgoKCgoKCgoKCgoKCgpI dWVsc2luZywgZXQgYWwuICAgICAgICBFeHBpcmVzIEphbnVhcnkgMjUsIDIwMTggICAgICAg ICAgICAgICBbUGFnZSAyNF0KDApJbnRlcm5ldC1EcmFmdCAgICBYTVNTOiBFeHRlbmRlZCBI YXNoLUJhc2VkIFNpZ25hdHVyZXMgICAgICAgICBKdWx5IDIwMTcKCgogICBBbGdvcml0aG0g MTA6IFhNU1Nfa2V5R2VuIC0gR2VuZXJhdGUgYW4gWE1TUyBrZXkgcGFpcgoKICAgICBJbnB1 dDogTm8gaW5wdXQKICAgICBPdXRwdXQ6IFhNU1MgcHJpdmF0ZSBrZXkgU0ssIFhNU1MgcHVi bGljIGtleSBQSwoKICAgICAvLyBFeGFtcGxlIGluaXRpYWxpemF0aW9uIGZvciBTSy1zcGVj aWZpYyBjb250ZW50cwogICAgIGlkeCA9IDA7CiAgICAgZm9yICggaSA9IDA7IGkgPCAyXmg7 IGkrKyApIHsKICAgICAgIHdvdHNfc2tbaV0gPSBXT1RTX2dlblNLKCk7CiAgICAgfQogICAg IGluaXRpYWxpemUgU0tfUFJGIHdpdGggYSB1bmlmb3JtbHkgcmFuZG9tIG4tYnl0ZSBzdHJp bmc7CiAgICAgc2V0U0tfUFJGKFNLLCBTS19QUkYpOwoKICAgICAvLyBJbml0aWFsaXphdGlv biBmb3IgY29tbW9uIGNvbnRlbnRzCiAgICAgaW5pdGlhbGl6ZSBTRUVEIHdpdGggYSB1bmlm b3JtbHkgcmFuZG9tIG4tYnl0ZSBzdHJpbmc7CiAgICAgc2V0U0VFRChTSywgU0VFRCk7CiAg ICAgc2V0V09UU19TSyhTSywgd290c19zaykpOwogICAgIEFEUlMgPSB0b0J5dGUoMCwgMzIp OwogICAgIHJvb3QgPSB0cmVlSGFzaChTSywgMCwgaCwgQURSUyk7CgogICAgIFNLID0gaWR4 IHx8IHdvdHNfc2sgfHwgU0tfUFJGIHx8IHJvb3QgfHwgU0VFRDsKICAgICBQSyA9IE9JRCB8 fCByb290IHx8IFNFRUQ7CiAgICAgcmV0dXJuIChTSyB8fCBQSyk7CgogICBUaGUgYWJvdmUg aXMganVzdCBhbiBleGFtcGxlIGFsZ29yaXRobS4gIEl0IGlzIHN0cm9uZ2x5IFJFQ09NTUVO REVECiAgIHRvIHVzZSBwc2V1ZG9yYW5kb20ga2V5IGdlbmVyYXRpb24gdG8gcmVkdWNlIHRo ZSBwcml2YXRlIGtleSBzaXplLgogICBQdWJsaWMgYW5kIHByaXZhdGUga2V5IGdlbmVyYXRp b24gTUFZIGJlIGludGVybGVhdmVkIHRvIHNhdmUgc3BhY2UuCiAgIEVzcGVjaWFsbHksIHdo ZW4gYSBwc2V1ZG9yYW5kb20gbWV0aG9kIGlzIHVzZWQgdG8gZ2VuZXJhdGUgdGhlCiAgIHBy aXZhdGUga2V5LCBnZW5lcmF0aW9uIE1BWSBiZSBkb25lIHdoZW4gdGhlIHJlc3BlY3RpdmUg V09UUysga2V5CiAgIHBhaXIgaXMgbmVlZGVkIGJ5IHRyZWVIYXNoLgoKICAgVGhlIGZvcm1h dCBvZiBhbiBYTVNTIHB1YmxpYyBrZXkgaXMgZ2l2ZW4gYmVsb3cuCgogICBYTVNTIFB1Ymxp YyBLZXkKCiAgICAgICAgICAgICstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0r CiAgICAgICAgICAgIHwgICAgICAgICAgYWxnb3JpdGhtIE9JRCAgICAgICAgICB8CiAgICAg ICAgICAgICstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rCiAgICAgICAgICAg IHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8CiAgICAgICAgICAgIHwgICAg ICAgICAgICByb290IG5vZGUgICAgICAgICAgICB8ICAgICBuIGJ5dGVzCiAgICAgICAgICAg IHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8CiAgICAgICAgICAgICstLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rCiAgICAgICAgICAgIHwgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICB8CiAgICAgICAgICAgIHwgICAgICAgICAgICAgIFNF RUQgICAgICAgICAgICAgICB8ICAgICBuIGJ5dGVzCiAgICAgICAgICAgIHwgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICB8CiAgICAgICAgICAgICstLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0rCgoKCgoKSHVlbHNpbmcsIGV0IGFsLiAgICAgICAgRXhwaXJl cyBKYW51YXJ5IDI1LCAyMDE4ICAgICAgICAgICAgICAgW1BhZ2UgMjVdCgwKSW50ZXJuZXQt RHJhZnQgICAgWE1TUzogRXh0ZW5kZWQgSGFzaC1CYXNlZCBTaWduYXR1cmVzICAgICAgICAg SnVseSAyMDE3CgoKNC4xLjguICBYTVNTIFNpZ25hdHVyZQoKICAgQW4gWE1TUyBzaWduYXR1 cmUgaXMgYSAoNCArIG4gKyAobGVuICsgaCkgKiBuKS1ieXRlIHN0cmluZyBjb25zaXN0aW5n CiAgIG9mCgogICAgICB0aGUgaW5kZXggaWR4X3NpZyBvZiB0aGUgdXNlZCBXT1RTKyBrZXkg cGFpciAoNCBieXRlcyksCgogICAgICBhIGJ5dGUgc3RyaW5nIHIgdXNlZCBmb3IgcmFuZG9t aXplZCBtZXNzYWdlIGhhc2hpbmcgKG4gYnl0ZXMpLAoKICAgICAgYSBXT1RTKyBzaWduYXR1 cmUgc2lnX290cyAobGVuICogbiBieXRlcyksCgogICAgICB0aGUgc28tY2FsbGVkIGF1dGhl bnRpY2F0aW9uIHBhdGggJ2F1dGgnIGZvciB0aGUgbGVhZiBhc3NvY2lhdGVkCiAgICAgIHdp dGggdGhlIHVzZWQgV09UUysga2V5IHBhaXIgKGggKiBuIGJ5dGVzKS4KCiAgIFRoZSBhdXRo ZW50aWNhdGlvbiBwYXRoIGlzIGFuIGFycmF5IG9mIGggbi1ieXRlIHN0cmluZ3MuICBJdCBj b250YWlucwogICB0aGUgc2libGluZ3Mgb2YgdGhlIG5vZGVzIG9uIHRoZSBwYXRoIGZyb20g dGhlIHVzZWQgbGVhZiB0byB0aGUgcm9vdC4KICAgSXQgZG9lcyBub3QgY29udGFpbiB0aGUg bm9kZXMgb24gdGhlIHBhdGggaXRzZWxmLiAgVGhlc2Ugbm9kZXMgYXJlCiAgIG5lZWRlZCBi eSBhIHZlcmlmaWVyIHRvIGNvbXB1dGUgYSByb290IG5vZGUgZm9yIHRoZSB0cmVlIGZyb20g dGhlCiAgIFdPVFMrIHB1YmxpYyBrZXkuICBBIG5vZGUgTm9kZSBpcyBhZGRyZXNzZWQgYnkg aXRzIHBvc2l0aW9uIGluIHRoZQogICB0cmVlLiAgTm9kZSh4LCB5KSBkZW5vdGVzIHRoZSB5 XnRoIG5vZGUgb24gbGV2ZWwgeCB3aXRoIHkgPSAwIGJlaW5nCiAgIHRoZSBsZWZ0bW9zdCBu b2RlIG9uIGEgbGV2ZWwuICBUaGUgbGVhdmVzIGFyZSBvbiBsZXZlbCAwLCB0aGUgcm9vdCBp cwogICBvbiBsZXZlbCBoLiAgQW4gYXV0aGVudGljYXRpb24gcGF0aCBjb250YWlucyBleGFj dGx5IG9uZSBub2RlIG9uCiAgIGV2ZXJ5IGxheWVyIDAgPD0geCA8PSAoaCAtIDEpLiAgRm9y IHRoZSBpXnRoIFdPVFMrIGtleSBwYWlyLCBjb3VudGluZwogICBmcm9tIHplcm8sIHRoZSBq XnRoIGF1dGhlbnRpY2F0aW9uIHBhdGggbm9kZSBpcwoKICAgICAgTm9kZShqLCBmbG9vcihp IC8gKDJeaikpIFhPUiAxKQoKICAgVGhlIGNvbXB1dGF0aW9uIG9mIHRoZSBhdXRoZW50aWNh dGlvbiBwYXRoIGlzIGRpc2N1c3NlZCBpbgogICBTZWN0aW9uIDQuMS45LgoKICAgVGhlIGRh dGEgZm9ybWF0IGZvciBhIHNpZ25hdHVyZSBpcyBnaXZlbiBiZWxvdy4KCgoKCgoKCgoKCgoK CgoKCgoKCgpIdWVsc2luZywgZXQgYWwuICAgICAgICBFeHBpcmVzIEphbnVhcnkgMjUsIDIw MTggICAgICAgICAgICAgICBbUGFnZSAyNl0KDApJbnRlcm5ldC1EcmFmdCAgICBYTVNTOiBF eHRlbmRlZCBIYXNoLUJhc2VkIFNpZ25hdHVyZXMgICAgICAgICBKdWx5IDIwMTcKCgogICBY TVNTIFNpZ25hdHVyZQoKICAgICAgICAgICAgICstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0rCiAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgfAogICAgICAgICAgICAgfCAgICAgICAgICBpbmRleCBpZHhfc2lnICAgICAgICAgIHwg ICAgNCBieXRlcwogICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIHwKICAgICAgICAgICAgICstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0r CiAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfAogICAg ICAgICAgICAgfCAgICAgICAgICByYW5kb21uZXNzIHIgICAgICAgICAgIHwgICAgbiBieXRl cwogICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwKICAg ICAgICAgICAgICstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rCiAgICAgICAg ICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfAogICAgICAgICAgICAg fCAgICAgV09UUysgc2lnbmF0dXJlIHNpZ19vdHMgICAgIHwgICAgbGVuICogbiBieXRlcwog ICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwKICAgICAg ICAgICAgICstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rCiAgICAgICAgICAg ICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfAogICAgICAgICAgICAgfCAg ICAgICAgICAgICBhdXRoWzBdICAgICAgICAgICAgIHwgICAgbiBieXRlcwogICAgICAgICAg ICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwKICAgICAgICAgICAgICst LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rCiAgICAgICAgICAgICB8ICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgfAogICAgICAgICAgICAgfiAgICAgICAgICAg ICAgLi4uLiAgICAgICAgICAgICAgIH4KICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICB8CiAgICAgICAgICAgICArLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tKwogICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIHwKICAgICAgICAgICAgIHwgICAgICAgICAgIGF1dGhbaCAtIDFdICAgICAgICAg ICB8ICAgIG4gYnl0ZXMKICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICB8CiAgICAgICAgICAgICArLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tKwoKNC4xLjkuICBYTVNTIFNpZ25hdHVyZSBHZW5lcmF0aW9uCgogICBUbyBjb21wdXRl IHRoZSBYTVNTIHNpZ25hdHVyZSBvZiBhIG1lc3NhZ2UgTSB3aXRoIGFuIFhNU1MgcHJpdmF0 ZQogICBrZXksIHRoZSBzaWduZXIgZmlyc3QgY29tcHV0ZXMgYSByYW5kb21pemVkIG1lc3Nh Z2UgZGlnZXN0IHVzaW5nIGEKICAgcmFuZG9tIHZhbHVlIHIsIGlkeF9zaWcsIHRoZSBpbmRl eCBvZiB0aGUgV09UUysga2V5IHBhaXIgdG8gYmUgdXNlZCwKICAgYW5kIHRoZSByb290IHZh bHVlIGZyb20gdGhlIHB1YmxpYyBrZXkgYXMga2V5LiAgVGhlbiBhIFdPVFMrCiAgIHNpZ25h dHVyZSBvZiB0aGUgbWVzc2FnZSBkaWdlc3QgaXMgY29tcHV0ZWQgdXNpbmcgdGhlIG5leHQg dW51c2VkCiAgIFdPVFMrIHByaXZhdGUga2V5LiAgTmV4dCwgdGhlIGF1dGhlbnRpY2F0aW9u IHBhdGggaXMgY29tcHV0ZWQuCiAgIEZpbmFsbHksIHRoZSBwcml2YXRlIGtleSBpcyB1cGRh dGVkLCBpLmUuICBpZHggaXMgaW5jcmVtZW50ZWQuICBBbgogICBpbXBsZW1lbnRhdGlvbiBN VVNUIE5PVCBvdXRwdXQgdGhlIHNpZ25hdHVyZSBiZWZvcmUgdGhlIHByaXZhdGUga2V5CiAg IGlzIHVwZGF0ZWQuCgogICBUaGUgbm9kZSB2YWx1ZXMgb2YgdGhlIGF1dGhlbnRpY2F0aW9u IHBhdGggTUFZIGJlIGNvbXB1dGVkIGluIGFueQogICB3YXkuICBUaGlzIGNvbXB1dGF0aW9u IGlzIGFzc3VtZWQgdG8gYmUgcGVyZm9ybWVkIGJ5IHRoZSBzdWJyb3V0aW5lCiAgIGJ1aWxk QXV0aCBmb3IgdGhlIGZ1bmN0aW9uIFhNU1Nfc2lnbiwgYXMgYmVsb3cuICBUaGUgZmFzdGVz dAogICBhbHRlcm5hdGl2ZSBpcyB0byBzdG9yZSBhbGwgdHJlZSBub2RlcyBhbmQgc2V0IHRo ZSBhcnJheSBpbiB0aGUKICAgc2lnbmF0dXJlIGJ5IGNvcHlpbmcgdGhlIHJlc3BlY3RpdmUg bm9kZXMuICBUaGUgbGVhc3Qgc3RvcmFnZS0KICAgaW50ZW5zaXZlIGFsdGVybmF0aXZlIGlz IHRvIHJlY29tcHV0ZSBhbGwgbm9kZXMgZm9yIGVhY2ggc2lnbmF0dXJlCiAgIG9ubGluZSB1 c2luZyB0aGUgdHJlZUhhc2ggYWxnb3JpdGhtIChBbGdvcml0aG0gOSkuICBUaGVyZSBleGlz dAogICBzZXZlcmFsIGFsZ29yaXRobXMgaW4gYmV0d2Vlbiwgd2l0aCBkaWZmZXJlbnQgdGlt ZS9zdG9yYWdlIHRyYWRlLQoKCgpIdWVsc2luZywgZXQgYWwuICAgICAgICBFeHBpcmVzIEph bnVhcnkgMjUsIDIwMTggICAgICAgICAgICAgICBbUGFnZSAyN10KDApJbnRlcm5ldC1EcmFm dCAgICBYTVNTOiBFeHRlbmRlZCBIYXNoLUJhc2VkIFNpZ25hdHVyZXMgICAgICAgICBKdWx5 IDIwMTcKCgogICBvZmZzLiAgRm9yIGFuIG92ZXJ2aWV3LCBzZWUgW0JEUzA5XS4gIEEgZnVy dGhlciBhcHByb2FjaCBjYW4gYmUgZm91bmQKICAgaW4gW0tNTjE0XS4gIE5vdGUgdGhhdCB0 aGUgZGV0YWlscyBvZiB0aGlzIHByb2NlZHVyZSBhcmUgbm90IHJlbGV2YW50CiAgIHRvIGlu dGVyb3BlcmFiaWxpdHk7IGl0IGlzIG5vdCBuZWNlc3NhcnkgdG8ga25vdyBhbnkgb2YgdGhl c2UgZGV0YWlscwogICBpbiBvcmRlciB0byBwZXJmb3JtIHRoZSBzaWduYXR1cmUgdmVyaWZp Y2F0aW9uIG9wZXJhdGlvbi4gIFRoZQogICBmb2xsb3dpbmcgdmVyc2lvbiBvZiBidWlsZEF1 dGggaXMgZ2l2ZW4gZm9yIGNvbXBsZXRlbmVzcy4gIEl0IGlzIGEKICAgc2ltcGxlIGV4YW1w bGUgZm9yIHVuZGVyc3RhbmRpbmcsIGJ1dCBleHRyZW1lbHkgaW5lZmZpY2llbnQuICBUaGUg dXNlCiAgIG9mIG9uZSBvZiB0aGUgYWx0ZXJuYXRpdmUgYWxnb3JpdGhtcyBpcyBzdHJvbmds eSBSRUNPTU1FTkRFRC4KCiAgIEdpdmVuIGFuIFhNU1MgcHJpdmF0ZSBrZXkgU0ssIGFsbCBu b2RlcyBpbiBhIHRyZWUgYXJlIGRldGVybWluZWQuCiAgIFRoZWlyIHZhbHVlIGlzIGRlZmlu ZWQgaW4gdGVybXMgb2YgdHJlZUhhc2ggKEFsZ29yaXRobSA5KS4gIEhlbmNlLAogICBvbmUg Y2FuIGNvbXB1dGUgdGhlIGF1dGhlbnRpY2F0aW9uIHBhdGggYXMgZm9sbG93czoKCiAgIChF eGFtcGxlKSBidWlsZEF1dGggLSBDb21wdXRlIHRoZSBhdXRoZW50aWNhdGlvbiBwYXRoIGZv ciB0aGUgaV50aAogICBXT1RTKyBrZXkgcGFpcgoKICAgICBJbnB1dDogWE1TUyBwcml2YXRl IGtleSBTSywgV09UUysga2V5IHBhaXIgaW5kZXggaSwgQURSUwogICAgIE91dHB1dDogQXV0 aGVudGljYXRpb24gcGF0aCBhdXRoCgogICAgIGZvciAoIGogPSAwOyBqIDwgaDsgaisrICkg ewogICAgICAgayA9IGZsb29yKGkgLyAoMl5qKSkgWE9SIDE7CiAgICAgICBhdXRoW2pdID0g dHJlZUhhc2goU0ssIGsgKiAyXmosIGosIEFEUlMpOwogICAgIH0KCiAgIFdlIHNwbGl0IHRo ZSBkZXNjcmlwdGlvbiBvZiB0aGUgc2lnbmF0dXJlIGdlbmVyYXRpb24gaW50byB0d28gbWFp bgogICBhbGdvcml0aG1zLiAgVGhlIGZpcnN0IG9uZSwgdHJlZVNpZyAoQWxnb3JpdGhtIDEx KSwgZ2VuZXJhdGVzIHRoZQogICBtYWluIHBhcnQgb2YgYW4gWE1TUyBzaWduYXR1cmUgYW5k IGlzIGFsc28gdXNlZCBieSB0aGUgbXVsdGktdHJlZQogICB2ZXJzaW9uIFhNU1NeTVQuICBY TVNTX3NpZ24gKEFsZ29yaXRobSAxMikgY2FsbHMgdHJlZVNpZyBidXQgaGFuZGxlcwogICBt ZXNzYWdlIGNvbXByZXNzaW9uIGJlZm9yZSBhbmQgdGhlIHByaXZhdGUga2V5IHVwZGF0ZSBh ZnRlcndhcmRzLgoKICAgVGhlIGFsZ29yaXRobSB0cmVlU2lnIChBbGdvcml0aG0gMTEpIGRl c2NyaWJlZCBiZWxvdyBjYWxjdWxhdGVzIHRoZQogICBXT1RTKyBzaWduYXR1cmUgb24gYW4g bi1ieXRlIG1lc3NhZ2UgYW5kIHRoZSBjb3JyZXNwb25kaW5nCiAgIGF1dGhlbnRpY2F0aW9u IHBhdGguICB0cmVlU2lnIHRha2VzIGFzIGlucHV0cyBhbiBuLWJ5dGUgbWVzc2FnZSBNJywK ICAgYW4gWE1TUyBwcml2YXRlIGtleSBTSywgYSBzaWduYXR1cmUgaW5kZXggaWR4X3NpZywg YW5kIGFuIGFkZHJlc3MKICAgQURSUy4gIEl0IHJldHVybnMgdGhlIGNvbmNhdGVuYXRpb24g b2YgdGhlIFdPVFMrIHNpZ25hdHVyZSBzaWdfb3RzCiAgIGFuZCBhdXRoZW50aWNhdGlvbiBw YXRoIGF1dGguCgoKCgoKCgoKCgoKCgoKCgpIdWVsc2luZywgZXQgYWwuICAgICAgICBFeHBp cmVzIEphbnVhcnkgMjUsIDIwMTggICAgICAgICAgICAgICBbUGFnZSAyOF0KDApJbnRlcm5l dC1EcmFmdCAgICBYTVNTOiBFeHRlbmRlZCBIYXNoLUJhc2VkIFNpZ25hdHVyZXMgICAgICAg ICBKdWx5IDIwMTcKCgogICBBbGdvcml0aG0gMTE6IHRyZWVTaWcgLSBHZW5lcmF0ZSBhIFdP VFMrIHNpZ25hdHVyZSBvbiBhIG1lc3NhZ2Ugd2l0aAogICBjb3JyZXNwb25kaW5nIGF1dGhl bnRpY2F0aW9uIHBhdGgKCiAgICAgSW5wdXQ6IG4tYnl0ZSBtZXNzYWdlIE0nLCBYTVNTIHBy aXZhdGUga2V5IFNLLAogICAgICAgICAgICBzaWduYXR1cmUgaW5kZXggaWR4X3NpZywgQURS UwogICAgIE91dHB1dDogQ29uY2F0ZW5hdGlvbiBvZiBXT1RTKyBzaWduYXR1cmUgc2lnX290 cyBhbmQKICAgICAgICAgICAgIGF1dGhlbnRpY2F0aW9uIHBhdGggYXV0aAoKICAgICBhdXRo ID0gYnVpbGRBdXRoKFNLLCBpZHhfc2lnLCBBRFJTKTsKICAgICBBRFJTLnNldFR5cGUoMCk7 ICAgLy8gVHlwZSA9IE9UUyBoYXNoIGFkZHJlc3MKICAgICBBRFJTLnNldE9UU0FkZHJlc3Mo aWR4X3NpZyk7CiAgICAgc2lnX290cyA9IFdPVFNfc2lnbihnZXRXT1RTX1NLKFNLLCBpZHhf c2lnKSwKICAgICAgICAgICAgICAgICAgICAgICAgIE0nLCBnZXRTRUVEKFNLKSwgQURSUyk7 CiAgICAgU2lnID0gc2lnX290cyB8fCBhdXRoOwogICAgIHJldHVybiBTaWc7CgogICBUaGUg YWxnb3JpdGhtIFhNU1Nfc2lnbiAoQWxnb3JpdGhtIDEyKSBkZXNjcmliZWQgYmVsb3cgY2Fs Y3VsYXRlcyBhbgogICB1cGRhdGVkIHByaXZhdGUga2V5IFNLIGFuZCBhIHNpZ25hdHVyZSBv biBhIG1lc3NhZ2UgTS4gIFhNU1Nfc2lnbgogICB0YWtlcyBhcyBpbnB1dHMgYSBtZXNzYWdl IE0gb2YgYXJiaXRyYXJ5IGxlbmd0aCwgYW5kIGFuIFhNU1MgcHJpdmF0ZQogICBrZXkgU0su ICBJdCByZXR1cm5zIHRoZSBieXRlIHN0cmluZyBjb250YWluaW5nIHRoZSBjb25jYXRlbmF0 aW9uIG9mCiAgIHRoZSB1cGRhdGVkIHByaXZhdGUga2V5IFNLIGFuZCB0aGUgc2lnbmF0dXJl IFNpZy4KCiAgIEFsZ29yaXRobSAxMjogWE1TU19zaWduIC0gR2VuZXJhdGUgYW4gWE1TUyBz aWduYXR1cmUgYW5kIHVwZGF0ZSB0aGUKICAgWE1TUyBwcml2YXRlIGtleQoKICAgICBJbnB1 dDogTWVzc2FnZSBNLCBYTVNTIHByaXZhdGUga2V5IFNLCiAgICAgT3V0cHV0OiBVcGRhdGVk IFNLLCBYTVNTIHNpZ25hdHVyZSBTaWcKCiAgICAgaWR4X3NpZyA9IGdldElkeChTSyk7CiAg ICAgc2V0SWR4KFNLLCBpZHhfc2lnICsgMSk7CiAgICAgQURSUyA9IHRvQnl0ZSgwLCAzMik7 CiAgICAgYnl0ZVtuXSByID0gUFJGKGdldFNLX1BSRihTSyksIHRvQnl0ZShpZHhfc2lnLCAz MikpOwogICAgIGJ5dGVbbl0gTScgPSBIX21zZyhyIHx8IGdldFJvb3QoU0spIHx8ICh0b0J5 dGUoaWR4X3NpZywgbikpLCBNKTsKICAgICBTaWcgPSBpZHhfc2lnIHx8IHIgfHwgdHJlZVNp ZyhNJywgU0ssIGlkeF9zaWcsIEFEUlMpOwogICAgIHJldHVybiAoU0sgfHwgU2lnKTsKCjQu MS4xMC4gIFhNU1MgU2lnbmF0dXJlIFZlcmlmaWNhdGlvbgoKICAgQW4gWE1TUyBzaWduYXR1 cmUgaXMgdmVyaWZpZWQgYnkgZmlyc3QgY29tcHV0aW5nIHRoZSBtZXNzYWdlIGRpZ2VzdAog ICB1c2luZyByYW5kb21uZXNzIHIsIGluZGV4IGlkeF9zaWcsIHRoZSByb290IGZyb20gUEsg YW5kIG1lc3NhZ2UgTS4KICAgVGhlbiB0aGUgdXNlZCBXT1RTKyBwdWJsaWMga2V5IHBrX290 cyBpcyBjb21wdXRlZCBmcm9tIHRoZSBXT1RTKwogICBzaWduYXR1cmUgdXNpbmcgV09UU19w a0Zyb21TaWcuICBUaGUgV09UUysgcHVibGljIGtleSBpbiB0dXJuIGlzIHVzZWQKICAgdG8g Y29tcHV0ZSB0aGUgY29ycmVzcG9uZGluZyBsZWFmIHVzaW5nIGFuIEwtdHJlZS4gIFRoZSBs ZWFmLAogICB0b2dldGhlciB3aXRoIGluZGV4IGlkeF9zaWcgYW5kIGF1dGhlbnRpY2F0aW9u IHBhdGggYXV0aCBpcyB1c2VkIHRvCiAgIGNvbXB1dGUgYW4gYWx0ZXJuYXRpdmUgcm9vdCB2 YWx1ZSBmb3IgdGhlIHRyZWUuICBUaGUgdmVyaWZpY2F0aW9uCiAgIHN1Y2NlZWRzIGlmIGFu ZCBvbmx5IGlmIHRoZSBjb21wdXRlZCByb290IHZhbHVlIG1hdGNoZXMgdGhlIG9uZSBpbgog ICB0aGUgWE1TUyBwdWJsaWMga2V5LiAgSW4gYW55IG90aGVyIGNhc2UgaXQgTVVTVCByZXR1 cm4gZmFpbC4KCgoKCkh1ZWxzaW5nLCBldCBhbC4gICAgICAgIEV4cGlyZXMgSmFudWFyeSAy NSwgMjAxOCAgICAgICAgICAgICAgIFtQYWdlIDI5XQoMCkludGVybmV0LURyYWZ0ICAgIFhN U1M6IEV4dGVuZGVkIEhhc2gtQmFzZWQgU2lnbmF0dXJlcyAgICAgICAgIEp1bHkgMjAxNwoK CiAgIEFzIGZvciBzaWduYXR1cmUgZ2VuZXJhdGlvbiwgd2Ugc3BsaXQgdmVyaWZpY2F0aW9u IGludG8gdHdvIHBhcnRzIHRvCiAgIGFsbG93IGZvciByZXVzZSBpbiB0aGUgWE1TU15NVCBk ZXNjcmlwdGlvbi4gIFRoZSBzdGVwcyBhbHNvIG5lZWRlZAogICBmb3IgWE1TU15NVCBhcmUg ZG9uZSBieSB0aGUgZnVuY3Rpb24gWE1TU19yb290RnJvbVNpZyAoQWxnb3JpdGhtIDEzKS4K ICAgWE1TU192ZXJpZnkgKEFsZ29yaXRobSAxNCkgY2FsbHMgWE1TU19yb290RnJvbVNpZyBh cyBhIHN1YnJvdXRpbmUgYW5kCiAgIGhhbmRsZXMgdGhlIFhNU1Mtc3BlY2lmaWMgc3RlcHMu CgogICBUaGUgbWFpbiBwYXJ0IG9mIFhNU1Mgc2lnbmF0dXJlIHZlcmlmaWNhdGlvbiBpcyBk b25lIGJ5IHRoZSBmdW5jdGlvbgogICBYTVNTX3Jvb3RGcm9tU2lnIChBbGdvcml0aG0gMTMp IGRlc2NyaWJlZCBiZWxvdy4gIFhNU1Nfcm9vdEZyb21TaWcKICAgdGFrZXMgYXMgaW5wdXRz IGFuIGluZGV4IGlkeF9zaWcsIGEgV09UUysgc2lnbmF0dXJlIHNpZ19vdHMsIGFuCiAgIGF1 dGhlbnRpY2F0aW9uIHBhdGggYXV0aCwgYW4gbi1ieXRlIG1lc3NhZ2UgTScsIHNlZWQgU0VF RCwgYW5kCiAgIGFkZHJlc3MgQURSUy4gIFhNU1Nfcm9vdEZyb21TaWcgcmV0dXJucyBhbiBu LWJ5dGUgc3RyaW5nIGhvbGRpbmcgdGhlCiAgIHZhbHVlIG9mIHRoZSByb290IG9mIGEgdHJl ZSBkZWZpbmVkIGJ5IHRoZSBpbnB1dCBkYXRhLgoKICAgQWxnb3JpdGhtIDEzOiBYTVNTX3Jv b3RGcm9tU2lnIC0gQ29tcHV0ZSBhIHJvb3Qgbm9kZSBmcm9tIGEgdHJlZQogICBzaWduYXR1 cmUKCiAgICAgSW5wdXQ6IGluZGV4IGlkeF9zaWcsIFdPVFMrIHNpZ25hdHVyZSBzaWdfb3Rz LCBhdXRoZW50aWNhdGlvbiBwYXRoCiAgICAgICAgICAgIGF1dGgsIG4tYnl0ZSBtZXNzYWdl IE0nLCBzZWVkIFNFRUQsIGFkZHJlc3MgQURSUwogICAgIE91dHB1dDogbi1ieXRlIHJvb3Qg dmFsdWUgbm9kZVswXQoKICAgICBBRFJTLnNldFR5cGUoMCk7ICAgLy8gVHlwZSA9IE9UUyBo YXNoIGFkZHJlc3MKICAgICBBRFJTLnNldE9UU0FkZHJlc3MoaWR4X3NpZyk7CiAgICAgcGtf b3RzID0gV09UU19wa0Zyb21TaWcoc2lnX290cywgTScsIFNFRUQsIEFEUlMpOwogICAgIEFE UlMuc2V0VHlwZSgxKTsgICAvLyBUeXBlID0gTC10cmVlIGFkZHJlc3MKICAgICBBRFJTLnNl dExUcmVlQWRkcmVzcyhpZHhfc2lnKTsKICAgICBieXRlW25dWzJdIG5vZGU7CiAgICAgbm9k ZVswXSA9IGx0cmVlKHBrX290cywgU0VFRCwgQURSUyk7CiAgICAgQURSUy5zZXRUeXBlKDIp OyAgIC8vIFR5cGUgPSBoYXNoIHRyZWUgYWRkcmVzcwogICAgIEFEUlMuc2V0VHJlZUluZGV4 KGlkeF9zaWcpOwogICAgIGZvciAoIGsgPSAwOyBrIDwgaDsgaysrICkgewogICAgICAgQURS Uy5zZXRUcmVlSGVpZ2h0KGspOwogICAgICAgaWYgKCAoZmxvb3IoaWR4X3NpZyAvICgyXmsp KSAlIDIpID09IDAgKSB7CiAgICAgICAgIEFEUlMuc2V0VHJlZUluZGV4KEFEUlMuZ2V0VHJl ZUluZGV4KCkgLyAyKTsKICAgICAgICAgbm9kZVsxXSA9IFJBTkRfSEFTSChub2RlWzBdLCBh dXRoW2tdLCBTRUVELCBBRFJTKTsKICAgICAgIH0gZWxzZSB7CiAgICAgICAgIEFEUlMuc2V0 VHJlZUluZGV4KChBRFJTLmdldFRyZWVJbmRleCgpIC0gMSkgLyAyKTsKICAgICAgICAgbm9k ZVsxXSA9IFJBTkRfSEFTSChhdXRoW2tdLCBub2RlWzBdLCBTRUVELCBBRFJTKTsKICAgICAg IH0KICAgICAgIG5vZGVbMF0gPSBub2RlWzFdOwogICAgIH0KICAgICByZXR1cm4gbm9kZVsw XTsKCiAgIFRoZSBmdWxsIFhNU1Mgc2lnbmF0dXJlIHZlcmlmaWNhdGlvbiBpcyBkZXBpY3Rl ZCBiZWxvdyAoQWxnb3JpdGhtCiAgIDE0KS4gIEl0IGhhbmRsZXMgbWVzc2FnZSBjb21wcmVz c2lvbiwgZGVsZWdhdGVzIHRoZSByb290IGNvbXB1dGF0aW9uCiAgIHRvIFhNU1Nfcm9vdEZy b21TaWcsIGFuZCBjb21wYXJlcyB0aGUgcmVzdWx0IHRvIHRoZSB2YWx1ZSBpbiB0aGUKICAg cHVibGljIGtleS4gIFhNU1NfdmVyaWZ5IHRha2VzIGFuIFhNU1Mgc2lnbmF0dXJlIFNpZywg YSBtZXNzYWdlIE0sCiAgIGFuZCBhbiBYTVNTIHB1YmxpYyBrZXkgUEsuICBYTVNTX3Zlcmlm eSByZXR1cm5zIHRydWUgaWYgYW5kIG9ubHkgaWYKCgoKCkh1ZWxzaW5nLCBldCBhbC4gICAg ICAgIEV4cGlyZXMgSmFudWFyeSAyNSwgMjAxOCAgICAgICAgICAgICAgIFtQYWdlIDMwXQoM CkludGVybmV0LURyYWZ0ICAgIFhNU1M6IEV4dGVuZGVkIEhhc2gtQmFzZWQgU2lnbmF0dXJl cyAgICAgICAgIEp1bHkgMjAxNwoKCiAgIFNpZyBpcyBhIHZhbGlkIHNpZ25hdHVyZSBvbiBN IHVuZGVyIHB1YmxpYyBrZXkgUEsuICBPdGhlcndpc2UsIGl0CiAgIHJldHVybnMgZmFsc2Uu CgogICBBbGdvcml0aG0gMTQ6IFhNU1NfdmVyaWZ5IC0gVmVyaWZ5IGFuIFhNU1Mgc2lnbmF0 dXJlIHVzaW5nIHRoZQogICBjb3JyZXNwb25kaW5nIFhNU1MgcHVibGljIGtleSBhbmQgYSBt ZXNzYWdlCgogICAgIElucHV0OiBYTVNTIHNpZ25hdHVyZSBTaWcsIG1lc3NhZ2UgTSwgWE1T UyBwdWJsaWMga2V5IFBLCiAgICAgT3V0cHV0OiBCb29sZWFuCgogICAgIEFEUlMgPSB0b0J5 dGUoMCwgMzIpOwogICAgIGJ5dGVbbl0gTScgPSBIX21zZyhyIHx8IGdldFJvb3QoUEspIHx8 ICh0b0J5dGUoaWR4X3NpZywgbikpLCBNKTsKCiAgICAgYnl0ZVtuXSBub2RlID0gWE1TU19y b290RnJvbVNpZyhpZHhfc2lnLCBzaWdfb3RzLCBhdXRoLCBNJywKICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIGdldFNFRUQoUEspLCBBRFJTKTsKICAgICBpZiAoIG5v ZGUgPT0gZ2V0Um9vdChQSykgKSB7CiAgICAgICByZXR1cm4gdHJ1ZTsKICAgICB9IGVsc2Ug ewogICAgICAgcmV0dXJuIGZhbHNlOwogICAgIH0KCjQuMS4xMS4gIFBzZXVkb3JhbmRvbSBL ZXkgR2VuZXJhdGlvbgoKICAgQW4gaW1wbGVtZW50YXRpb24gTUFZIHVzZSBhIGNyeXB0b2dy YXBoaWNhbGx5IHNlY3VyZSBwc2V1ZG9yYW5kb20KICAgbWV0aG9kIHRvIGdlbmVyYXRlIHRo ZSBYTVNTIHByaXZhdGUga2V5IGZyb20gYSBzaW5nbGUgbi1ieXRlIHZhbHVlLgogICBGb3Ig ZXhhbXBsZSwgdGhlIG1ldGhvZCBzdWdnZXN0ZWQgaW4gW0JESDExXSBhbmQgZXhwbGFpbmVk IGJlbG93IE1BWQogICBiZSB1c2VkLiAgT3RoZXIgbWV0aG9kcywgc3VjaCBhcyB0aGUgb25l IGluIFtIUlMxNl0sIE1BWSBiZSB1c2VkLgogICBUaGUgY2hvaWNlIG9mIGEgcHNldWRvcmFu ZG9tIG1ldGhvZCBkb2VzIG5vdCBhZmZlY3QgaW50ZXJvcGVyYWJpbGl0eSwKICAgYnV0IHRo ZSBjcnlwdG9ncmFwaGljIHN0cmVuZ3RoIE1VU1QgbWF0Y2ggdGhhdCBvZiB0aGUgdXNlZCBY TVNTCiAgIHBhcmFtZXRlcnMuCgogICBGb3IgWE1TUyBhIHNpbWlsYXIgbWV0aG9kIHRoYW4g dGhlIG9uZSB1c2VkIGZvciBXT1RTKyBjYW4gYmUgdXNlZC4KICAgVGhlIHN1Z2dlc3RlZCBt ZXRob2QgZnJvbSBbQkRIMTFdIGNhbiBiZSBkZXNjcmliZWQgdXNpbmcgUFJGLiAgRHVyaW5n CiAgIGtleSBnZW5lcmF0aW9uIGEgdW5pZm9ybWx5IHJhbmRvbSBuLWJ5dGUgc3RyaW5nIFMg aXMgc2FtcGxlZCBmcm9tIGEKICAgc2VjdXJlIHNvdXJjZSBvZiByYW5kb21uZXNzLiAgVGhp cyBzZWVkIFMgTVVTVCBOT1QgYmUgY29uZnVzZWQgd2l0aAogICB0aGUgcHVibGljIHNlZWQg U0VFRC4gIFRoZSBzZWVkIFMgTVVTVCBiZSBpbmRlcGVuZGVudCBvZiBTRUVEIGFuZCBhcwog ICBpdCBpcyB0aGUgbWFpbiBzZWNyZXQsIGl0IE1VU1QgYmUga2VwdCBzZWNyZXQuICBUaGlz IHNlZWQgUyBpcyB1c2VkCiAgIHRvIGdlbmVyYXRlIGFuIG4tYnl0ZSB2YWx1ZSBTX290cyBm b3IgZWFjaCBXT1RTKyBrZXkgcGFpci4gIFRoZQogICBuLWJ5dGUgdmFsdWUgU19vdHMgY2Fu IHRoZW4gYmUgdXNlZCB0byBjb21wdXRlIHRoZSByZXNwZWN0aXZlIFdPVFMrCiAgIHByaXZh dGUga2V5IHVzaW5nIHRoZSBtZXRob2QgZGVzY3JpYmVkIGluIFNlY3Rpb24gMy4xLjcuICBU aGUgc2VlZHMKICAgZm9yIHRoZSBXT1RTKyBrZXkgcGFpcnMgYXJlIGNvbXB1dGVkIGFzIFNf b3RzW2ldID0gUFJGKFMsIHRvQnl0ZShpLAogICAzMikpIHdoZXJlIGkgaXMgdGhlIGluZGV4 IG9mIHRoZSBXT1RTKyBrZXkgcGFpci4gIEFuIGFkdmFudGFnZSBvZgogICB0aGlzIG1ldGhv ZCBpcyB0aGF0IGEgV09UUysga2V5IGNhbiBiZSBjb21wdXRlZCB1c2luZyBvbmx5IGxlbiAr IDEKICAgZXZhbHVhdGlvbnMgb2YgUFJGIHdoZW4gUyBpcyBnaXZlbi4KCgoKCgoKCgpIdWVs c2luZywgZXQgYWwuICAgICAgICBFeHBpcmVzIEphbnVhcnkgMjUsIDIwMTggICAgICAgICAg ICAgICBbUGFnZSAzMV0KDApJbnRlcm5ldC1EcmFmdCAgICBYTVNTOiBFeHRlbmRlZCBIYXNo LUJhc2VkIFNpZ25hdHVyZXMgICAgICAgICBKdWx5IDIwMTcKCgo0LjEuMTIuICBGcmVlIElu ZGV4IEhhbmRsaW5nIGFuZCBQYXJ0aWFsIFByaXZhdGUgS2V5cwoKICAgU29tZSBhcHBsaWNh dGlvbnMgbWlnaHQgcmVxdWlyZSB0byB3b3JrIHdpdGggcGFydGlhbCBwcml2YXRlIGtleXMg b3IKICAgY29waWVzIG9mIHByaXZhdGUga2V5cy4gIEV4YW1wbGVzIGluY2x1ZGUgZGVsZWdh dGlvbiBvZiBzaWduaW5nCiAgIHJpZ2h0cyAvIHByb3h5IHNpZ25hdHVyZXMsIGFuZCBsb2Fk IGJhbGFuY2luZy4gIFN1Y2ggYXBwbGljYXRpb25zIE1BWQogICB1c2UgdGhlaXIgb3duIGtl eSBmb3JtYXQgYW5kIE1BWSB1c2UgYSBzaWduaW5nIGFsZ29yaXRobSBkaWZmZXJlbnQKICAg ZnJvbSB0aGUgb25lIGRlc2NyaWJlZCBhYm92ZS4gIFRoZSBpbmRleCBpbiBwYXJ0aWFsIHBy aXZhdGUga2V5cyBvcgogICBjb3BpZXMgb2YgYSBwcml2YXRlIGtleSBNQVkgYmUgbWFuaXB1 bGF0ZWQgYXMgcmVxdWlyZWQgYnkgdGhlCiAgIGFwcGxpY2F0aW9ucy4gIEhvd2V2ZXIsIGFw cGxpY2F0aW9ucyBNVVNUIGVzdGFibGlzaCBtZWFucyB0aGF0CiAgIGd1YXJhbnRlZSB0aGF0 IGVhY2ggaW5kZXggYW5kIHRoZXJlYnkgZWFjaCBXT1RTKyBrZXkgcGFpciBpcyB1c2VkIHRv CiAgIHNpZ24gb25seSBhIHNpbmdsZSBtZXNzYWdlLgoKNC4yLiAgWE1TU15NVDogTXVsdGkt VHJlZSBYTVNTCgogICBYTVNTXk1UIGlzIGEgbWV0aG9kIGZvciBzaWduaW5nIGEgbGFyZ2Ug YnV0IGZpeGVkIG51bWJlciBvZiBtZXNzYWdlcy4KICAgSXQgd2FzIGZpcnN0IGRlc2NyaWJl ZCBpbiBbSFJCMTNdLiAgSXQgYnVpbGRzIG9uIFhNU1MuICBYTVNTXk1UIHVzZXMKICAgYSB0 cmVlIG9mIHNldmVyYWwgbGF5ZXJzIG9mIFhNU1MgdHJlZXMsIGEgc28tY2FsbGVkIGh5cGVy dHJlZS4gIFRoZQogICB0cmVlcyBvbiB0b3AgYW5kIGludGVybWVkaWF0ZSBsYXllcnMgYXJl IHVzZWQgdG8gc2lnbiB0aGUgcm9vdCBub2RlcwogICBvZiB0aGUgdHJlZXMgb24gdGhlIHJl c3BlY3RpdmUgbGF5ZXIgYmVsb3cuICBUcmVlcyBvbiB0aGUgbG93ZXN0CiAgIGxheWVyIGFy ZSB1c2VkIHRvIHNpZ24gdGhlIGFjdHVhbCBtZXNzYWdlcy4gIEFsbCBYTVNTIHRyZWVzIGhh dmUKICAgZXF1YWwgaGVpZ2h0LgoKICAgQ29uc2lkZXIgYW4gWE1TU15NVCB0cmVlIG9mIHRv dGFsIGhlaWdodCBoIHRoYXQgaGFzIGQgbGF5ZXJzIG9mIFhNU1MKICAgdHJlZXMgb2YgaGVp Z2h0IGggLyBkLiAgVGhlbiBsYXllciBkIC0gMSBjb250YWlucyBvbmUgWE1TUyB0cmVlLAog ICBsYXllciBkIC0gMiBjb250YWlucyAyXihoIC8gZCkgWE1TUyB0cmVlcywgYW5kIHNvIG9u LiAgRmluYWxseSwgbGF5ZXIKICAgMCBjb250YWlucyAyXihoIC0gaCAvIGQpIFhNU1MgdHJl ZXMuCgo0LjIuMS4gIFhNU1NeTVQgUGFyYW1ldGVycwoKICAgSW4gYWRkaXRpb24gdG8gYWxs IFhNU1MgcGFyYW1ldGVycywgYW4gWE1TU15NVCBzeXN0ZW0gcmVxdWlyZXMgdGhlCiAgIG51 bWJlciBvZiB0cmVlIGxheWVycyBkLCBzcGVjaWZpZWQgYXMgYW4gaW50ZWdlciB2YWx1ZSB0 aGF0IGRpdmlkZXMgaAogICB3aXRob3V0IHJlbWFpbmRlci4gIFRoZSBzYW1lIHRyZWUgaGVp Z2h0IGggLyBkIGFuZCB0aGUgc2FtZQogICBXaW50ZXJuaXR6IHBhcmFtZXRlciB3IGFyZSB1 c2VkIGZvciBhbGwgdHJlZSBsYXllcnMuCgogICBBbGwgdGhlIHRyZWVzIG9uIGhpZ2hlciBs YXllcnMgc2lnbiByb290IG5vZGVzIG9mIG90aGVyIHRyZWVzIHdoaWNoCiAgIGFyZSBuLWJ5 dGUgc3RyaW5ncy4gIEhlbmNlLCBubyBtZXNzYWdlIGNvbXByZXNzaW9uIGlzIG5lZWRlZCBh bmQKICAgV09UUysgaXMgdXNlZCB0byBzaWduIHRoZSByb290IG5vZGVzIHRoZW1zZWx2ZXMg aW5zdGVhZCBvZiB0aGVpciBoYXNoCiAgIHZhbHVlcy4KCjQuMi4yLiAgWE1TU15NVCBLZXkg Z2VuZXJhdGlvbgoKICAgQW4gWE1TU15NVCBwcml2YXRlIGtleSBTS19NVCAoUyBmb3Igc2Vj cmV0KSBjb25zaXN0cyBvZiBvbmUgcmVkdWNlZAogICBYTVNTIHByaXZhdGUga2V5IGZvciBl YWNoIFhNU1MgdHJlZS4gIFRoZXNlIHJlZHVjZWQgWE1TUyBwcml2YXRlIGtleXMKICAganVz dCBjb250YWluIHRoZSBXT1RTKyBwcml2YXRlIGtleXMgY29ycmVzcG9uZGluZyB0byB0aGF0 IFhNU1Mga2V5CiAgIHBhaXIgYW5kIG5vIHBzZXVkb3JhbmRvbSBmdW5jdGlvbiBrZXksIG5v IGluZGV4LCBubyBwdWJsaWMgc2VlZCwgbm8KICAgcm9vdCBub2RlLiAgSW5zdGVhZCwgU0tf TVQgY29udGFpbnMgYSBzaW5nbGUgbi1ieXRlIHBzZXVkb3JhbmRvbQogICBmdW5jdGlvbiBr ZXkgU0tfUFJGLCBhIHNpbmdsZSAoY2VpbChoIC8gOCkpLWJ5dGUgaW5kZXggaWR4X01ULCBh CiAgIHNpbmdsZSBuLWJ5dGUgc2VlZCBTRUVELCBhbmQgYSBzaW5nbGUgcm9vdCB2YWx1ZSBy b290IHdoaWNoIGlzIHRoZQoKCgpIdWVsc2luZywgZXQgYWwuICAgICAgICBFeHBpcmVzIEph bnVhcnkgMjUsIDIwMTggICAgICAgICAgICAgICBbUGFnZSAzMl0KDApJbnRlcm5ldC1EcmFm dCAgICBYTVNTOiBFeHRlbmRlZCBIYXNoLUJhc2VkIFNpZ25hdHVyZXMgICAgICAgICBKdWx5 IDIwMTcKCgogICByb290IG9mIHRoZSBzaW5nbGUgdHJlZSBvbiB0aGUgdG9wIGxheWVyLiAg VGhlIGluZGV4IGlzIGEgZ2xvYmFsCiAgIGluZGV4IG92ZXIgYWxsIFdPVFMrIGtleSBwYWly cyBvZiBhbGwgWE1TUyB0cmVlcyBvbiBsYXllciAwLiAgSXQgaXMKICAgaW5pdGlhbGl6ZWQg d2l0aCAwLiAgSXQgc3RvcmVzIHRoZSBpbmRleCBvZiB0aGUgbGFzdCB1c2VkIFdPVFMrIGtl eQogICBwYWlyIG9uIHRoZSBib3R0b20gbGF5ZXIsIGkuZS4gYSBudW1iZXIgYmV0d2VlbiAw IGFuZCAyXmggLSAxLgoKICAgVGhlIHJlZHVjZWQgWE1TUyBwcml2YXRlIGtleXMgTVVTVCBl aXRoZXIgYmUgZ2VuZXJhdGVkIGFzIGRlc2NyaWJlZAogICBpbiBTZWN0aW9uIDQuMS4zIG9y IHVzaW5nIGEgY3J5cHRvZ3JhcGhpYyBwc2V1ZG9yYW5kb20gbWV0aG9kIGFzCiAgIGRpc2N1 c3NlZCBpbiBTZWN0aW9uIDQuMi42LiAgQXMgZm9yIFhNU1MsIHRoZSBQUkYga2V5IFNLX1BS RiBNVVNUIGJlCiAgIHNhbXBsZWQgZnJvbSBhIHNlY3VyZSBzb3VyY2Ugb2YgcmFuZG9tbmVz cyB0aGF0IGZvbGxvd3MgdGhlIHVuaWZvcm0KICAgZGlzdHJpYnV0aW9uLiAgU0VFRCBpcyBn ZW5lcmF0ZWQgYXMgYSB1bmlmb3JtbHkgcmFuZG9tIG4tYnl0ZSBzdHJpbmcuCiAgIEFsdGhv dWdoIFNFRUQgaXMgcHVibGljLCBpdCBpcyBjcml0aWNhbCBmb3Igc2VjdXJpdHkgdGhhdCBp dCBpcwogICBnZW5lcmF0ZWQgdXNpbmcgYSBnb29kIGVudHJvcHkgc291cmNlLiAgVGhlIHJv b3QgaXMgdGhlIHJvb3Qgbm9kZSBvZgogICB0aGUgc2luZ2xlIFhNU1MgdHJlZSBvbiB0aGUg dG9wIGxheWVyLiAgSXRzIGNvbXB1dGF0aW9uIGlzIGV4cGxhaW5lZAogICBiZWxvdy4gIEFz IGZvciBYTVNTLCByb290IGFuZCBTRUVEIGFyZSBwdWJsaWMgaW5mb3JtYXRpb24gYW5kIHdv dWxkCiAgIGNsYXNzaWNhbGx5IGJlIGNvbnNpZGVyZWQgcGFydCBvZiB0aGUgcHVibGljIGtl eS4gIEhvd2V2ZXIsIGFzIGJvdGgKICAgYXJlIG5lZWRlZCBmb3Igc2lnbmluZywgd2hpY2gg b25seSB0YWtlcyB0aGUgcHJpdmF0ZSBrZXksIHRoZXkgYXJlCiAgIGFsc28gcGFydCBvZiBT S19NVC4KCiAgIFRoaXMgZG9jdW1lbnQgZG9lcyBub3QgZGVmaW5lIGFueSBzcGVjaWZpYyBm b3JtYXQgZm9yIHRoZSBYTVNTXk1UCiAgIHByaXZhdGUga2V5IFNLX01UIGFzIGl0IGlzIG5v dCByZXF1aXJlZCBmb3IgaW50ZXJvcGVyYWJpbGl0eS4gIFRoZQogICBhbGdvcml0aG0gZGVz Y3JpcHRpb25zIGJlbG93IHVzZSBhIGZ1bmN0aW9uIGdldFhNU1NfU0soU0ssIHgsIHkpIHRo YXQKICAgb3V0cHV0cyB0aGUgcmVkdWNlZCBwcml2YXRlIGtleSBvZiB0aGUgeF50aCBYTVNT IHRyZWUgb24gdGhlIHledGgKICAgbGF5ZXIuCgogICBUaGUgWE1TU15NVCBwdWJsaWMga2V5 IFBLX01UIGNvbnRhaW5zIHRoZSByb290IG9mIHRoZSBzaW5nbGUgWE1TUwogICB0cmVlIG9u IGxheWVyIGQgLSAxIGFuZCB0aGUgc2VlZCBTRUVELiAgVGhlc2UgYXJlIHRoZSBzYW1lIHZh bHVlcyBhcwogICBpbiB0aGUgcHJpdmF0ZSBrZXkgU0tfTVQuICBUaGUgcHNldWRvcmFuZG9t IGZ1bmN0aW9uIFBSRiBrZXllZCB3aXRoCiAgIFNFRUQgaXMgdXNlZCB0byBnZW5lcmF0ZSB0 aGUgYml0bWFza3MgYW5kIGtleXMgZm9yIGFsbCBYTVNTIHRyZWVzLgogICBYTVNTTVRfa2V5 R2VuIChBbGdvcml0aG0gMTUpIHNob3dzIGV4YW1wbGUgcHNldWRvY29kZSB0byBnZW5lcmF0 ZQogICBTS19NVCBhbmQgUEtfTVQuICBUaGUgbi1ieXRlIHJvb3Qgbm9kZSBvZiB0aGUgdG9w IGxheWVyIHRyZWUgaXMKICAgY29tcHV0ZWQgdXNpbmcgdHJlZUhhc2guICBUaGUgYWxnb3Jp dGhtIFhNU1NNVF9rZXlHZW4gb3V0cHV0cyBhbgogICBYTVNTXk1UIHByaXZhdGUga2V5IFNL X01UIGFuZCBhbiBYTVNTXk1UIHB1YmxpYyBrZXkgUEtfTVQuICBUaGUKICAgYWxnb3JpdGht IGJlbG93IGdpdmVzIGFuIGV4YW1wbGUgb2YgaG93IHRoZSByZWR1Y2VkIFhNU1MgcHJpdmF0 ZSBrZXlzCiAgIGNhbiBiZSBnZW5lcmF0ZWQuICBIb3dldmVyLCBhbnkgb2YgdGhlIGFib3Zl IG1lbnRpb25lZCB3YXlzIGlzCiAgIGFjY2VwdGFibGUgYXMgbG9uZyBhcyB0aGUgY3J5cHRv Z3JhcGhpYyBzdHJlbmd0aCBvZiB0aGUgdXNlZCBtZXRob2QKICAgbWF0Y2hlcyBvciBzdXBl cnNlZGVzIHRoYXQgb2YgdGhlIHVzZWQgWE1TU15NVCBwYXJhbWV0ZXIgc2V0LgoKCgoKCgoK CgoKCgoKCgpIdWVsc2luZywgZXQgYWwuICAgICAgICBFeHBpcmVzIEphbnVhcnkgMjUsIDIw MTggICAgICAgICAgICAgICBbUGFnZSAzM10KDApJbnRlcm5ldC1EcmFmdCAgICBYTVNTOiBF eHRlbmRlZCBIYXNoLUJhc2VkIFNpZ25hdHVyZXMgICAgICAgICBKdWx5IDIwMTcKCgogICBB bGdvcml0aG0gMTU6IFhNU1NNVF9rZXlHZW4gLSBHZW5lcmF0ZSBhbiBYTVNTXk1UIGtleSBw YWlyCgogICAgIElucHV0OiBObyBpbnB1dAogICAgIE91dHB1dDogWE1TU15NVCBwcml2YXRl IGtleSBTS19NVCwgWE1TU15NVCBwdWJsaWMga2V5IFBLX01UCgogICAgIC8vIEV4YW1wbGUg aW5pdGlhbGl6YXRpb24KICAgICBpZHhfTVQgPSAwOwogICAgIHNldElkeChTS19NVCwgaWR4 X01UKTsKICAgICBpbml0aWFsaXplIFNLX1BSRiB3aXRoIGEgdW5pZm9ybWx5IHJhbmRvbSBu LWJ5dGUgc3RyaW5nOwogICAgIHNldFNLX1BSRihTS19NVCwgU0tfUFJGKTsKICAgICBpbml0 aWFsaXplIFNFRUQgd2l0aCBhIHVuaWZvcm1seSByYW5kb20gbi1ieXRlIHN0cmluZzsKICAg ICBzZXRTRUVEKFNLX01ULCBTRUVEKTsKCiAgICAgLy8gR2VuZXJhdGUgcmVkdWNlZCBYTVNT IHByaXZhdGUga2V5cwogICAgIEFEUlMgPSB0b0J5dGUoMCwgMzIpOwogICAgIGZvciAoIGxh eWVyID0gMDsgbGF5ZXIgPCBkOyBsYXllcisrICkgewogICAgICAgIEFEUlMuc2V0TGF5ZXJB ZGRyZXNzKGxheWVyKTsKICAgICAgICBmb3IgKCB0cmVlID0gMDsgdHJlZSA8CiAgICAgICAg ICAgICAgKDEgPDwgKChkIC0gMSAtIGxheWVyKSAqIChoIC8gZCkpKTsKICAgICAgICAgICAg ICB0cmVlKysgKSB7CiAgICAgICAgICAgQURSUy5zZXRUcmVlQWRkcmVzcyh0cmVlKTsKICAg ICAgICAgICBmb3IgKCBpID0gMDsgaSA8IDJeKGggLyBkKTsgaSsrICkgewogICAgICAgICAg ICAgd290c19za1tpXSA9IFdPVFNfZ2VuU0soKTsKICAgICAgICAgICB9CiAgICAgICAgICAg c2V0WE1TU19TSyhTS19NVCwgd290c19zaywgdHJlZSwgbGF5ZXIpOwogICAgICAgIH0KICAg ICB9CgogICAgIFNLID0gZ2V0WE1TU19TSyhTS19NVCwgMCwgZCAtIDEpOwogICAgIHNldFNF RUQoU0ssIFNFRUQpOwogICAgIHJvb3QgPSB0cmVlSGFzaChTSywgMCwgaCAvIGQsIEFEUlMp OwogICAgIHNldFJvb3QoU0tfTVQsIHJvb3QpOwoKICAgICBQS19NVCA9IE9JRCB8fCByb290 IHx8IFNFRUQ7CiAgICAgcmV0dXJuIChTS19NVCB8fCBQS19NVCk7CgogICBUaGUgYWJvdmUg aXMganVzdCBhbiBleGFtcGxlIGFsZ29yaXRobS4gIEl0IGlzIHN0cm9uZ2x5IFJFQ09NTUVO REVECiAgIHRvIHVzZSBwc2V1ZG9yYW5kb20ga2V5IGdlbmVyYXRpb24gdG8gcmVkdWNlIHRo ZSBwcml2YXRlIGtleSBzaXplLgogICBQdWJsaWMgYW5kIHByaXZhdGUga2V5IGdlbmVyYXRp b24gTUFZIGJlIGludGVybGVhdmVkIHRvIHNhdmUgc3BhY2UuCiAgIEVzcGVjaWFsbHksIHdo ZW4gYSBwc2V1ZG9yYW5kb20gbWV0aG9kIGlzIHVzZWQgdG8gZ2VuZXJhdGUgdGhlCiAgIHBy aXZhdGUga2V5LCBnZW5lcmF0aW9uIE1BWSBiZSBkZWxheWVkIHRvIHRoZSBwb2ludCB3aGVu IHRoZQogICByZXNwZWN0aXZlIFdPVFMrIGtleSBwYWlyIGlzIG5lZWRlZCBieSBhbm90aGVy IGFsZ29yaXRobS4KCiAgIFRoZSBmb3JtYXQgb2YgYW4gWE1TU15NVCBwdWJsaWMga2V5IGlz IGdpdmVuIGJlbG93LgoKCgoKCgoKSHVlbHNpbmcsIGV0IGFsLiAgICAgICAgRXhwaXJlcyBK YW51YXJ5IDI1LCAyMDE4ICAgICAgICAgICAgICAgW1BhZ2UgMzRdCgwKSW50ZXJuZXQtRHJh ZnQgICAgWE1TUzogRXh0ZW5kZWQgSGFzaC1CYXNlZCBTaWduYXR1cmVzICAgICAgICAgSnVs eSAyMDE3CgoKICAgWE1TU15NVCBQdWJsaWMgS2V5CgogICAgICAgICAgICArLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKwogICAgICAgICAgICB8ICAgICAgICAgIGFsZ29y aXRobSBPSUQgICAgICAgICAgfAogICAgICAgICAgICArLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tKwogICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgfAogICAgICAgICAgICB8ICAgICAgICAgICAgcm9vdCBub2RlICAgICAgICAgICAg fCAgICAgbiBieXRlcwogICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgfAogICAgICAgICAgICArLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t KwogICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfAogICAg ICAgICAgICB8ICAgICAgICAgICAgICBTRUVEICAgICAgICAgICAgICAgfCAgICAgbiBieXRl cwogICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfAogICAg ICAgICAgICArLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKwoKNC4yLjMuICBY TVNTXk1UIFNpZ25hdHVyZQoKICAgQW4gWE1TU15NVCBzaWduYXR1cmUgU2lnX01UIGlzIGEg Ynl0ZSBzdHJpbmcgb2YgbGVuZ3RoIChjZWlsKGggLyA4KSArCiAgIG4gKyAoaCArIGQgKiBs ZW4pICogbikuICBJdCBjb25zaXN0cyBvZgoKICAgICAgdGhlIGluZGV4IGlkeF9zaWcgb2Yg dGhlIHVzZWQgV09UUysga2V5IHBhaXIgb24gdGhlIGJvdHRvbSBsYXllcgogICAgICAoY2Vp bChoIC8gOCkgYnl0ZXMpLAoKICAgICAgYSBieXRlIHN0cmluZyByIHVzZWQgZm9yIHJhbmRv bWl6ZWQgbWVzc2FnZSBoYXNoaW5nIChuIGJ5dGVzKSwKCiAgICAgIGQgcmVkdWNlZCBYTVNT IHNpZ25hdHVyZXMgKChoIC8gZCArIGxlbikgKiBuIGJ5dGVzIGVhY2gpLgoKICAgVGhlIHJl ZHVjZWQgWE1TUyBzaWduYXR1cmVzIG9ubHkgY29udGFpbiBhIFdPVFMrIHNpZ25hdHVyZSBz aWdfb3RzCiAgIGFuZCBhbiBhdXRoZW50aWNhdGlvbiBwYXRoIGF1dGguICBUaGV5IGNvbnRh aW4gbm8gaW5kZXggaWR4IGFuZCBubwogICBieXRlIHN0cmluZyByLgoKICAgVGhlIGRhdGEg Zm9ybWF0IGZvciBhIHNpZ25hdHVyZSBpcyBnaXZlbiBiZWxvdy4KCgoKCgoKCgoKCgoKCgoK CgoKCgpIdWVsc2luZywgZXQgYWwuICAgICAgICBFeHBpcmVzIEphbnVhcnkgMjUsIDIwMTgg ICAgICAgICAgICAgICBbUGFnZSAzNV0KDApJbnRlcm5ldC1EcmFmdCAgICBYTVNTOiBFeHRl bmRlZCBIYXNoLUJhc2VkIFNpZ25hdHVyZXMgICAgICAgICBKdWx5IDIwMTcKCgogICBYTVNT Xk1UIHNpZ25hdHVyZQoKICAgICAgICAgICArLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tKwogICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8 CiAgICAgICAgICAgfCAgICAgICAgICBpbmRleCBpZHhfc2lnICAgICAgICAgIHwgICBjZWls KGggLyA4KSBieXRlcwogICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICB8CiAgICAgICAgICAgKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsK ICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfAogICAgICAg ICAgIHwgICAgICAgICAgcmFuZG9tbmVzcyByICAgICAgICAgICB8ICAgbiBieXRlcwogICAg ICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8CiAgICAgICAgICAg Ky0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsKICAgICAgICAgICB8ICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgfAogICAgICAgICAgIHwgIChyZWR1Y2VkKSBY TVNTIHNpZ25hdHVyZSBTaWcgICB8ICAgKGggLyBkICsgbGVuKSAqIG4gYnl0ZXMKICAgICAg ICAgICB8ICAgICAgICAoYm90dG9tIGxheWVyIDApICAgICAgICAgfAogICAgICAgICAgIHwg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8CiAgICAgICAgICAgKy0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsKICAgICAgICAgICB8ICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgfAogICAgICAgICAgIHwgIChyZWR1Y2VkKSBYTVNTIHNpZ25h dHVyZSBTaWcgICB8ICAgKGggLyBkICsgbGVuKSAqIG4gYnl0ZXMKICAgICAgICAgICB8ICAg ICAgICAgICAgKGxheWVyIDEpICAgICAgICAgICAgfAogICAgICAgICAgIHwgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICB8CiAgICAgICAgICAgKy0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLSsKICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgfAogICAgICAgICAgIH4gICAgICAgICAgICAgIC4uLi4gICAgICAgICAgICAg ICB+CiAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwKICAg ICAgICAgICArLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKwogICAgICAgICAg IHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8CiAgICAgICAgICAgfCAgKHJl ZHVjZWQpIFhNU1Mgc2lnbmF0dXJlIFNpZyAgIHwgICAoaCAvIGQgKyBsZW4pICogbiBieXRl cwogICAgICAgICAgIHwgICAgICAgICAgKGxheWVyIGQgLSAxKSAgICAgICAgICB8CiAgICAg ICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwKICAgICAgICAgICAr LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKwoKNC4yLjQuICBYTVNTXk1UIFNp Z25hdHVyZSBHZW5lcmF0aW9uCgogICBUbyBjb21wdXRlIHRoZSBYTVNTXk1UIHNpZ25hdHVy ZSBTaWdfTVQgb2YgYSBtZXNzYWdlIE0gdXNpbmcgYW4KICAgWE1TU15NVCBwcml2YXRlIGtl eSBTS19NVCwgWE1TU01UX3NpZ24gKEFsZ29yaXRobSAxNikgZGVzY3JpYmVkIGJlbG93CiAg IHVzZXMgdHJlZVNpZyBhcyBkZWZpbmVkIGluIFNlY3Rpb24gNC4xLjkuICBGaXJzdCwgdGhl IHNpZ25hdHVyZSBpbmRleAogICBpcyBzZXQgdG8gaWR4X3NpZy4gIE5leHQsIFBSRiBpcyB1 c2VkIHRvIGNvbXB1dGUgYSBwc2V1ZG9yYW5kb20KICAgbi1ieXRlIHN0cmluZyByLiAgVGhp cyBuLWJ5dGUgc3RyaW5nLCBpZHhfc2lnLCBhbmQgdGhlIHJvb3Qgbm9kZSBmcm9tCiAgIFBL X01UIGFyZSB0aGVuIHVzZWQgdG8gY29tcHV0ZSBhIHJhbmRvbWl6ZWQgbWVzc2FnZSBkaWdl c3Qgb2YgbGVuZ3RoCiAgIG4uICBUaGUgbWVzc2FnZSBkaWdlc3QgaXMgc2lnbmVkIHVzaW5n IHRoZSBXT1RTKyBrZXkgcGFpciBvbiB0aGUKICAgYm90dG9tIGxheWVyIHdpdGggYWJzb2x1 dGUgaW5kZXggaWR4LiAgVGhlIGF1dGhlbnRpY2F0aW9uIHBhdGggZm9yCiAgIHRoZSBXT1RT KyBrZXkgcGFpciBpcyBjb21wdXRlZCBhcyB3ZWxsIGFzIHRoZSByb290IG9mIHRoZSBjb250 YWluaW5nCiAgIFhNU1MgdHJlZS4gIFRoZSByb290IGlzIHNpZ25lZCBieSB0aGUgcGFyZW50 IFhNU1MgdHJlZS4gIFRoaXMgaXMKICAgcmVwZWF0ZWQgdW50aWwgdGhlIHRvcCB0cmVlIGlz IHJlYWNoZWQuCgoKCgoKCgpIdWVsc2luZywgZXQgYWwuICAgICAgICBFeHBpcmVzIEphbnVh cnkgMjUsIDIwMTggICAgICAgICAgICAgICBbUGFnZSAzNl0KDApJbnRlcm5ldC1EcmFmdCAg ICBYTVNTOiBFeHRlbmRlZCBIYXNoLUJhc2VkIFNpZ25hdHVyZXMgICAgICAgICBKdWx5IDIw MTcKCgogICBBbGdvcml0aG0gMTY6IFhNU1NNVF9zaWduIC0gR2VuZXJhdGUgYW4gWE1TU15N VCBzaWduYXR1cmUgYW5kIHVwZGF0ZQogICB0aGUgWE1TU15NVCBwcml2YXRlIGtleQoKICAg ICBJbnB1dDogTWVzc2FnZSBNLCBYTVNTXk1UIHByaXZhdGUga2V5IFNLX01UCiAgICAgT3V0 cHV0OiBVcGRhdGVkIFNLX01ULCBzaWduYXR1cmUgU2lnX01UCgogICAgIC8vIEluaXQKICAg ICBBRFJTID0gdG9CeXRlKDAsIDMyKTsKICAgICBTRUVEID0gZ2V0U0VFRChTS19NVCk7CiAg ICAgU0tfUFJGID0gZ2V0U0tfUFJGKFNLX01UKTsKICAgICBpZHhfc2lnID0gZ2V0SWR4KFNL X01UKTsKCiAgICAgLy8gVXBkYXRlIFNLX01UCiAgICAgc2V0SWR4KFNLX01ULCBpZHhfc2ln ICsgMSk7CgogICAgIC8vIE1lc3NhZ2UgY29tcHJlc3Npb24KICAgICBieXRlW25dIHIgPSBQ UkYoU0tfUFJGLCB0b0J5dGUoaWR4X3NpZywgMzIpKTsKICAgICBieXRlW25dIE0nID0gSF9t c2cociB8fCBnZXRSb290KFNLX01UKSB8fCAodG9CeXRlKGlkeF9zaWcsIG4pKSwgTSk7Cgog ICAgIC8vIFNpZ24KICAgICBTaWdfTVQgPSBpZHhfc2lnOwogICAgIHVuc2lnbmVkIGludCBp ZHhfdHJlZQogICAgICAgICAgICAgICAgICAgPSAoaCAtIGggLyBkKSBtb3N0IHNpZ25pZmlj YW50IGJpdHMgb2YgaWR4X3NpZzsKICAgICB1bnNpZ25lZCBpbnQgaWR4X2xlYWYgPSAoaCAv IGQpIGxlYXN0IHNpZ25pZmljYW50IGJpdHMgb2YgaWR4X3NpZzsKICAgICBTSyA9IGlkeF9s ZWFmIHx8IGdldFhNU1NfU0soU0tfTVQsIGlkeF90cmVlLCAwKSB8fCBTS19QUkYKICAgICAg ICAgICB8fCB0b0J5dGUoMCwgbikgfHwgU0VFRDsKICAgICBBRFJTLnNldExheWVyQWRkcmVz cygwKTsKICAgICBBRFJTLnNldFRyZWVBZGRyZXNzKGlkeF90cmVlKTsKICAgICBTaWdfdG1w ID0gdHJlZVNpZyhNJywgU0ssIGlkeF9sZWFmLCBBRFJTKTsKICAgICBTaWdfTVQgPSBTaWdf TVQgfHwgciB8fCBTaWdfdG1wOwogICAgIGZvciAoIGogPSAxOyBqIDwgZDsgaisrICkgewog ICAgICAgIHJvb3QgPSB0cmVlSGFzaChTSywgMCwgaCAvIGQsIEFEUlMpOwogICAgICAgIGlk eF9sZWFmID0gKGggLyBkKSBsZWFzdCBzaWduaWZpY2FudCBiaXRzIG9mIGlkeF90cmVlOwog ICAgICAgIGlkeF90cmVlID0gKGggLSBqICogKGggLyBkKSkgbW9zdCBzaWduaWZpY2FudCBi aXRzIG9mIGlkeF90cmVlOwogICAgICAgIFNLID0gaWR4X2xlYWYgfHwgZ2V0WE1TU19TSyhT S19NVCwgaWR4X3RyZWUsIGopIHx8IFNLX1BSRgogICAgICAgICAgICAgICB8fCB0b0J5dGUo MCwgbikgfHwgU0VFRDsKICAgICAgICBBRFJTLnNldExheWVyQWRkcmVzcyhqKTsKICAgICAg ICBBRFJTLnNldFRyZWVBZGRyZXNzKGlkeF90cmVlKTsKICAgICAgICBTaWdfdG1wID0gdHJl ZVNpZyhyb290LCBTSywgaWR4X2xlYWYsIEFEUlMpOwogICAgICAgIFNpZ19NVCA9IFNpZ19N VCB8fCBTaWdfdG1wOwogICAgIH0KICAgICByZXR1cm4gU0tfTVQgfHwgU2lnX01UOwoKICAg QWxnb3JpdGhtIDE2IGlzIG9ubHkgb25lIG1ldGhvZCB0byBjb21wdXRlIFhNU1NeTVQgc2ln bmF0dXJlcy4KICAgRXNwZWNpYWxseSwgdGhlcmUgZXhpc3QgdGltZS1tZW1vcnkgdHJhZGUt b2ZmcyB0aGF0IGFsbG93IHRvIHJlZHVjZQogICB0aGUgc2lnbmluZyB0aW1lIHRvIGxlc3Mg dGhhbiB0aGUgc2lnbmluZyB0aW1lIG9mIGFuIFhNU1Mgc2NoZW1lIHdpdGgKICAgdHJlZSBo ZWlnaHQgaCAvIGQuICBUaGVzZSB0cmFkZS1vZmZzIHByZXZlbnQgY2VydGFpbiB2YWx1ZXMg ZnJvbQogICBiZWluZyByZWNvbXB1dGVkIHNldmVyYWwgdGltZXMgYnkga2VlcGluZyBhIHN0 YXRlIGFuZCBkaXN0cmlidXRlIGFsbAoKCgpIdWVsc2luZywgZXQgYWwuICAgICAgICBFeHBp cmVzIEphbnVhcnkgMjUsIDIwMTggICAgICAgICAgICAgICBbUGFnZSAzN10KDApJbnRlcm5l dC1EcmFmdCAgICBYTVNTOiBFeHRlbmRlZCBIYXNoLUJhc2VkIFNpZ25hdHVyZXMgICAgICAg ICBKdWx5IDIwMTcKCgogICBjb21wdXRhdGlvbnMgb3ZlciBhbGwgc2lnbmF0dXJlIGdlbmVy YXRpb25zLiAgRGV0YWlscyBjYW4gYmUgZm91bmQgaW4KICAgW0h1ZWxzaW5nMTNhXS4KCjQu Mi41LiAgWE1TU15NVCBTaWduYXR1cmUgVmVyaWZpY2F0aW9uCgogICBYTVNTXk1UIHNpZ25h dHVyZSB2ZXJpZmljYXRpb24gKEFsZ29yaXRobSAxNykgY2FuIGJlIHN1bW1hcml6ZWQgYXMg ZAogICBYTVNTIHNpZ25hdHVyZSB2ZXJpZmljYXRpb25zIHdpdGggc21hbGwgY2hhbmdlcy4g IEZpcnN0LCB0aGUgbWVzc2FnZQogICBpcyBoYXNoZWQuICBUaGUgWE1TUyBzaWduYXR1cmVz IGFyZSB0aGVuIGFsbCBvbiBuLWJ5dGUgdmFsdWVzLgogICBTZWNvbmQsIGluc3RlYWQgb2Yg Y29tcGFyaW5nIHRoZSBjb21wdXRlZCByb290IG5vZGUgdG8gYSBnaXZlbiB2YWx1ZSwKICAg YSBzaWduYXR1cmUgb24gdGhpcyByb290IG5vZGUgaXMgdmVyaWZpZWQuICBPbmx5IHRoZSBy b290IG5vZGUgb2YgdGhlCiAgIHRvcCB0cmVlIGlzIGNvbXBhcmVkIHRvIHRoZSB2YWx1ZSBp biB0aGUgWE1TU15NVCBwdWJsaWMga2V5LgogICBYTVNTTVRfdmVyaWZ5IHVzZXMgWE1TU19y b290RnJvbVNpZy4gIFRoZSBmdW5jdGlvbgogICBnZXRYTVNTU2lnbmF0dXJlKFNpZ19NVCwg aSkgcmV0dXJucyB0aGUgaXRoIHJlZHVjZWQgWE1TUyBzaWduYXR1cmUKICAgZnJvbSB0aGUg WE1TU15NVCBzaWduYXR1cmUgU2lnX01ULiAgWE1TU01UX3ZlcmlmeSB0YWtlcyBhcyBpbnB1 dHMgYW4KICAgWE1TU15NVCBzaWduYXR1cmUgU2lnX01ULCBhIG1lc3NhZ2UgTSBhbmQgYSBw dWJsaWMga2V5IFBLX01ULgogICBYTVNTTVRfdmVyaWZ5IHJldHVybnMgdHJ1ZSBpZiBhbmQg b25seSBpZiBTaWdfTVQgaXMgYSB2YWxpZCBzaWduYXR1cmUKICAgb24gTSB1bmRlciBwdWJs aWMga2V5IFBLX01ULiAgT3RoZXJ3aXNlLCBpdCByZXR1cm5zIGZhbHNlLgoKCgoKCgoKCgoK CgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKSHVlbHNpbmcsIGV0IGFsLiAgICAgICAgRXhwaXJl cyBKYW51YXJ5IDI1LCAyMDE4ICAgICAgICAgICAgICAgW1BhZ2UgMzhdCgwKSW50ZXJuZXQt RHJhZnQgICAgWE1TUzogRXh0ZW5kZWQgSGFzaC1CYXNlZCBTaWduYXR1cmVzICAgICAgICAg SnVseSAyMDE3CgoKICAgQWxnb3JpdGhtIDE3OiBYTVNTTVRfdmVyaWZ5IC0gVmVyaWZ5IGFu IFhNU1NeTVQgc2lnbmF0dXJlIFNpZ19NVCBvbiBhCiAgIG1lc3NhZ2UgTSB1c2luZyBhbiBY TVNTXk1UIHB1YmxpYyBrZXkgUEtfTVQKCiAgICAgSW5wdXQ6IFhNU1NeTVQgc2lnbmF0dXJl IFNpZ19NVCwgbWVzc2FnZSBNLAogICAgICAgICAgICBYTVNTXk1UIHB1YmxpYyBrZXkgUEtf TVQKICAgICBPdXRwdXQ6IEJvb2xlYW4KCiAgICAgaWR4X3NpZyA9IGdldElkeChTaWdfTVQp OwogICAgIFNFRUQgPSBnZXRTRUVEKFBLX01UKTsKICAgICBBRFJTID0gdG9CeXRlKDAsIDMy KTsKCiAgICAgYnl0ZVtuXSBNJyA9IEhfbXNnKGdldFIoU2lnX01UKSB8fCBnZXRSb290KFBL X01UKQogICAgICAgICAgICAgICAgICAgICAgICB8fCAodG9CeXRlKGlkeF9zaWcsIG4pKSwg TSk7CgogICAgIHVuc2lnbmVkIGludCBpZHhfbGVhZgogICAgICAgICAgICAgICAgICAgPSAo aCAvIGQpIGxlYXN0IHNpZ25pZmljYW50IGJpdHMgb2YgaWR4X3NpZzsKICAgICB1bnNpZ25l ZCBpbnQgaWR4X3RyZWUKICAgICAgICAgICAgICAgICAgID0gKGggLSBoIC8gZCkgbW9zdCBz aWduaWZpY2FudCBiaXRzIG9mIGlkeF9zaWc7CiAgICAgU2lnJyA9IGdldFhNU1NTaWduYXR1 cmUoU2lnX01ULCAwKTsKICAgICBBRFJTLnNldExheWVyQWRkcmVzcygwKTsKICAgICBBRFJT LnNldFRyZWVBZGRyZXNzKGlkeF90cmVlKTsKICAgICBieXRlW25dIG5vZGUgPSBYTVNTX3Jv b3RGcm9tU2lnKGlkeF9sZWFmLCBnZXRTaWdfb3RzKFNpZycpLAogICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIGdldEF1dGgoU2lnJyksIE0nLCBTRUVELCBBRFJTKTsK ICAgICBmb3IgKCBqID0gMTsgaiA8IGQ7IGorKyApIHsKICAgICAgICBpZHhfbGVhZiA9ICho IC8gZCkgbGVhc3Qgc2lnbmlmaWNhbnQgYml0cyBvZiBpZHhfdHJlZTsKICAgICAgICBpZHhf dHJlZSA9IChoIC0gaiAqIGggLyBkKSBtb3N0IHNpZ25pZmljYW50IGJpdHMgb2YgaWR4X3Ry ZWU7CiAgICAgICAgU2lnJyA9IGdldFhNU1NTaWduYXR1cmUoU2lnX01ULCBqKTsKICAgICAg ICBBRFJTLnNldExheWVyQWRkcmVzcyhqKTsKICAgICAgICBBRFJTLnNldFRyZWVBZGRyZXNz KGlkeF90cmVlKTsKICAgICAgICBub2RlID0gWE1TU19yb290RnJvbVNpZyhpZHhfbGVhZiwg Z2V0U2lnX290cyhTaWcnKSwKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgZ2V0QXV0 aChTaWcnKSwgbm9kZSwgU0VFRCwgQURSUyk7CiAgICAgfQogICAgIGlmICggbm9kZSA9PSBn ZXRSb290KFBLX01UKSApIHsKICAgICAgIHJldHVybiB0cnVlOwogICAgIH0gZWxzZSB7CiAg ICAgICByZXR1cm4gZmFsc2U7CiAgICAgfQoKNC4yLjYuICBQc2V1ZG9yYW5kb20gS2V5IEdl bmVyYXRpb24KCiAgIExpa2UgZm9yIFhNU1MsIGFuIGltcGxlbWVudGF0aW9uIE1BWSB1c2Ug YSBjcnlwdG9ncmFwaGljYWxseSBzZWN1cmUKICAgcHNldWRvcmFuZG9tIG1ldGhvZCB0byBn ZW5lcmF0ZSB0aGUgWE1TU15NVCBwcml2YXRlIGtleSBmcm9tIGEgc2luZ2xlCiAgIG4tYnl0 ZSB2YWx1ZS4gIEZvciBleGFtcGxlLCB0aGUgbWV0aG9kIGV4cGxhaW5lZCBiZWxvdyBNQVkg YmUgdXNlZC4KICAgT3RoZXIgbWV0aG9kcywgc3VjaCBhcyB0aGUgb25lIGluIFtIUlMxNl0s IE1BWSBiZSB1c2VkLiAgVGhlIGNob2ljZQogICBvZiBhIHBzZXVkb3JhbmRvbSBtZXRob2Qg ZG9lcyBub3QgYWZmZWN0IGludGVyb3BlcmFiaWxpdHksIGJ1dCB0aGUKICAgY3J5cHRvZ3Jh cGhpYyBzdHJlbmd0aCBNVVNUIG1hdGNoIHRoYXQgb2YgdGhlIHVzZWQgWE1TU15NVAogICBw YXJhbWV0ZXJzLgoKCgoKSHVlbHNpbmcsIGV0IGFsLiAgICAgICAgRXhwaXJlcyBKYW51YXJ5 IDI1LCAyMDE4ICAgICAgICAgICAgICAgW1BhZ2UgMzldCgwKSW50ZXJuZXQtRHJhZnQgICAg WE1TUzogRXh0ZW5kZWQgSGFzaC1CYXNlZCBTaWduYXR1cmVzICAgICAgICAgSnVseSAyMDE3 CgoKICAgRm9yIFhNU1NeTVQgYSBtZXRob2Qgc2ltaWxhciB0byB0aGF0IGZvciBYTVNTIGFu ZCBXT1RTKyBjYW4gYmUgdXNlZC4KICAgVGhlIG1ldGhvZCB1c2VzIFBSRi4gIER1cmluZyBr ZXkgZ2VuZXJhdGlvbiBhIHVuaWZvcm1seSByYW5kb20gbi1ieXRlCiAgIHN0cmluZyBTX01U IGlzIHNhbXBsZWQgZnJvbSBhIHNlY3VyZSBzb3VyY2Ugb2YgcmFuZG9tbmVzcy4gIFRoaXMg c2VlZAogICBTX01UIGlzIHVzZWQgdG8gZ2VuZXJhdGUgb25lIG4tYnl0ZSB2YWx1ZSBTIGZv ciBlYWNoIFhNU1Mga2V5IHBhaXIuCiAgIFRoaXMgbi1ieXRlIHZhbHVlIGNhbiBiZSB1c2Vk IHRvIGNvbXB1dGUgdGhlIHJlc3BlY3RpdmUgWE1TUyBwcml2YXRlCiAgIGtleSB1c2luZyB0 aGUgbWV0aG9kIGRlc2NyaWJlZCBpbiBTZWN0aW9uIDQuMS4xMS4gIExldCBTW3hdW3ldIGJl IHRoZQogICBzZWVkIGZvciB0aGUgeF50aCBYTVNTIHByaXZhdGUga2V5IG9uIGxheWVyIHku ICBUaGUgc2VlZHMgYXJlCiAgIGNvbXB1dGVkIGFzIFNbeF1beV0gPSBQUkYoUFJGKFMsIHRv Qnl0ZSh5LCAzMikpLCB0b0J5dGUoeCwgMzIpKS4KCjQuMi43LiAgRnJlZSBJbmRleCBIYW5k bGluZyBhbmQgUGFydGlhbCBQcml2YXRlIEtleXMKCiAgIFRoZSBjb250ZW50IG9mIFNlY3Rp b24gNC4xLjEyIGFsc28gYXBwbGllcyB0byBYTVNTXk1ULgoKNS4gIFBhcmFtZXRlciBTZXRz CgogICBUaGlzIHNlY3Rpb24gcHJvdmlkZXMgYSBiYXNpYyBzZXQgb2YgcGFyYW1ldGVyIHNl dHMgd2hpY2ggYXJlIGFzc3VtZWQKICAgdG8gY292ZXIgbW9zdCByZWxldmFudCBhcHBsaWNh dGlvbnMuICBQYXJhbWV0ZXIgc2V0cyBmb3IgdHdvCiAgIGNsYXNzaWNhbCBzZWN1cml0eSBs ZXZlbHMgYXJlIGRlZmluZWQuICBQYXJhbWV0ZXJzIHdpdGggbiA9IDMyCiAgIHByb3ZpZGUg YSBjbGFzc2ljYWwgc2VjdXJpdHkgbGV2ZWwgb2YgMjU2IGJpdHMuICBQYXJhbWV0ZXJzIHdp dGggbiA9CiAgIDY0IHByb3ZpZGUgYSBjbGFzc2ljYWwgc2VjdXJpdHkgbGV2ZWwgb2YgNTEy IGJpdHMuICBDb25zaWRlcmluZwogICBxdWFudHVtLWNvbXB1dGVyLWFpZGVkIGF0dGFja3Ms IHRoZXNlIG91dHB1dCBzaXplcyB5aWVsZCBwb3N0LXF1YW50dW0KICAgc2VjdXJpdHkgb2Yg MTI4IGFuZCAyNTYgYml0cywgcmVzcGVjdGl2ZWx5LgoKICAgV2hpbGUgdGhpcyBkb2N1bWVu dCBzcGVjaWZpZXMgc2V2ZXJhbCBwYXJhbWV0ZXIgc2V0cywgYW4KICAgaW1wbGVtZW50YXRp b24gaXMgb25seSBSRVFVSVJFRCB0byBwcm92aWRlIHN1cHBvcnQgZm9yIHZlcmlmaWNhdGlv bgogICBvZiBhbGwgUkVRVUlSRUQgcGFyYW1ldGVyIHNldHMuICBUaGUgUkVRVUlSRUQgcGFy YW1ldGVyIHNldHMgYWxsIHVzZQogICBTSEEyLTI1NiB0byBpbnN0YW50aWF0ZSBhbGwgZnVu Y3Rpb25zLiAgVGhlIFJFUVVJUkVEIHBhcmFtZXRlciBzZXRzCiAgIGFyZSBvbmx5IGRpc3Rp bmd1aXNoZWQgYnkgdGhlIHRyZWUgaGVpZ2h0IHBhcmFtZXRlciBoIHdoaWNoCiAgIGRldGVy bWluZXMgdGhlIG51bWJlciBvZiBzaWduYXR1cmVzIHRoYXQgY2FuIGJlIGRvbmUgd2l0aCBh IHNpbmdsZQogICBrZXkgcGFpciBhbmQgdGhlIG51bWJlciBvZiBsYXllcnMgZCB3aGljaCBk ZWZpbmVzIGEgdHJhZGUtb2ZmIGJldHdlZW4KICAgc3BlZWQgYW5kIHNpZ25hdHVyZSBzaXpl LiAgQW4gaW1wbGVtZW50YXRpb24gTUFZIHByb3ZpZGUgc3VwcG9ydCBmb3IKICAgc2lnbmF0 dXJlIGdlbmVyYXRpb24gdXNpbmcgYW55IG9mIHRoZSBwcm9wb3NlZCBwYXJhbWV0ZXIgc2V0 cy4gIEZvcgogICBjb252ZW5pZW5jZSB0aGlzIGRvY3VtZW50IGRlZmluZXMgYSBkZWZhdWx0 IG9wdGlvbiBmb3IgWE1TUwogICAoWE1TU19TSEEyXzIwXzI1NikgYW5kIFhNU1NeTVQgKFhN U1NNVC1TSEEyXzYwLzNfMjU2KS4gIFRoZXNlIGFyZQogICBzdXBwb3NlZCB0byBtYXRjaCB0 aGUgbW9zdCBnZW5lcmljIHJlcXVpcmVtZW50cy4KCjUuMS4gIEltcGxlbWVudGluZyB0aGUg ZnVuY3Rpb25zCgogICBGb3IgdGhlIG4gPSAzMiBhbmQgbiA9IDY0IHNldHRpbmdzLCB3ZSBn aXZlIHBhcmFtZXRlcnMgdGhhdCB1c2UKICAgU0hBMi0yNTYsIFNIQTItNTEyIGFzIGRlZmlu ZWQgaW4gW0ZJUFMxODBdLCBhbmQgdGhlIFNIQTMvS2VjY2FrLWJhc2VkCiAgIGV4dGVuZGFi bGUtb3V0cHV0IGZ1bmN0aW9ucyBTSEFLRS0xMjgsIFNIQUtFLTI1NiBhcyBkZWZpbmVkIGlu CiAgIFtGSVBTMjAyXS4gIFRoZSBwYXJhbWV0ZXIgc2V0cyB1c2luZyBTSEEyLTI1NiBhcmUg bWFuZGF0b3J5IGZvcgogICBkZXBsb3ltZW50IGFuZCB0aGVyZWZvcmUgTVVTVCBiZSBwcm92 aWRlZCBieSBhbnkgaW1wbGVtZW50YXRpb24uICBUaGUKICAgcmVtYWluaW5nIHBhcmFtZXRl ciBzZXRzIHNwZWNpZmllZCBpbiB0aGlzIGRvY3VtZW50IGFyZSBPUFRJT05BTC4KCiAgIFNI QTIgZG9lcyBub3QgcHJvdmlkZSBhIGtleWVkLW1vZGUgaXRzZWxmLiAgVG8gaW1wbGVtZW50 IHRoZSBrZXllZAogICBoYXNoIGZ1bmN0aW9ucyB0aGUgZm9sbG93aW5nIGlzIHVzZWQgZm9y IFNIQTIgd2l0aCBuID0gMzI6CgoKCgpIdWVsc2luZywgZXQgYWwuICAgICAgICBFeHBpcmVz IEphbnVhcnkgMjUsIDIwMTggICAgICAgICAgICAgICBbUGFnZSA0MF0KDApJbnRlcm5ldC1E cmFmdCAgICBYTVNTOiBFeHRlbmRlZCBIYXNoLUJhc2VkIFNpZ25hdHVyZXMgICAgICAgICBK dWx5IDIwMTcKCgogICAgICBGOiBTSEEyLTI1Nih0b0J5dGUoMCwgMzIpIHx8IEtFWSB8fCBN KSwKCiAgICAgIEg6IFNIQTItMjU2KHRvQnl0ZSgxLCAzMikgfHwgS0VZIHx8IE0pLAoKICAg ICAgSF9tc2c6IFNIQTItMjU2KHRvQnl0ZSgyLCAzMikgfHwgS0VZIHx8IE0pLAoKICAgICAg UFJGOiBTSEEyLTI1Nih0b0J5dGUoMywgMzIpIHx8IEtFWSB8fCBNKS4KCiAgIEFjY29yZGlu Z2x5LCBmb3IgU0hBMiB3aXRoIG4gPSA2NCB3ZSB1c2U6CgogICAgICBGOiBTSEEyLTUxMih0 b0J5dGUoMCwgNjQpIHx8IEtFWSB8fCBNKSwKCiAgICAgIEg6IFNIQTItNTEyKHRvQnl0ZSgx LCA2NCkgfHwgS0VZIHx8IE0pLAoKICAgICAgSF9tc2c6IFNIQTItNTEyKHRvQnl0ZSgyLCA2 NCkgfHwgS0VZIHx8IE0pLAoKICAgICAgUFJGOiBTSEEyLTUxMih0b0J5dGUoMywgNjQpIHx8 IEtFWSB8fCBNKS4KCiAgIFRoZSBuLWJ5dGUgcGFkZGluZyBpcyB1c2VkIGZvciB0d28gcmVh c29ucy4gIEZpcnN0LCBpdCBpcyBuZWNlc3NhcnkKICAgdGhhdCB0aGUgaW50ZXJuYWwgY29t cHJlc3Npb24gZnVuY3Rpb24gdGFrZXMgMm4tYnl0ZSBibG9ja3MgYnV0IGtleXMKICAgYXJl IG4gYW5kIDNuIGJ5dGVzIGxvbmcuICBTZWNvbmQsIHRoZSBwYWRkaW5nIGlzIHVzZWQgdG8g YWNoaWV2ZQogICBpbmRlcGVuZGVuY2Ugb2YgdGhlIGRpZmZlcmVudCBmdW5jdGlvbiBmYW1p bGllcy4gIEZpbmFsbHksIGZvciB0aGUKICAgUFJGIG5vIGZ1bGwtZmxlZGdlZCBITUFDIGlz IG5lZWRlZCBhcyB0aGUgbWVzc2FnZSBsZW5ndGggaXMgZml4ZWQsCiAgIG1lYW5pbmcgdGhh dCBzdGFuZGFyZCBsZW5ndGggZXh0ZW5zaW9uIGF0dGFja3MgYXJlIG5vdCBhIGNvbmNlcm4K ICAgaGVyZS4gIEZvciB0aGF0IHJlYXNvbiwgdGhlIHNpbXBsZXIgY29uc3RydWN0aW9uIGFi b3ZlIHN1ZmZpY2VzLgoKICAgU2ltaWxhciBjb25zdHJ1Y3Rpb25zIGFyZSB1c2VkIHdpdGgg U0hBMy4gIFRvIGltcGxlbWVudCB0aGUga2V5ZWQKICAgaGFzaCBmdW5jdGlvbnMgdGhlIGZv bGxvd2luZyBpcyB1c2VkIGZvciBTSEEzIHdpdGggbiA9IDMyOgoKICAgICAgRjogU0hBS0Ux MjgodG9CeXRlKDAsIDMyKSB8fCBLRVkgfHwgTSwgMjU2KSwKCiAgICAgIEg6IFNIQUtFMTI4 KHRvQnl0ZSgxLCAzMikgfHwgS0VZIHx8IE0sIDI1NiksCgogICAgICBIX21zZzogU0hBS0Ux MjgodG9CeXRlKDIsIDMyKSB8fCBLRVkgfHwgTSwgMjU2KSwKCiAgICAgIFBSRjogU0hBS0Ux MjgodG9CeXRlKDMsIDMyKSB8fCBLRVkgfHwgTSwgMjU2KS4KCiAgIEFjY29yZGluZ2x5LCBm b3IgU0hBMyB3aXRoIG4gPSA2NCB3ZSB1c2U6CgogICAgICBGOiBTSEFLRTI1Nih0b0J5dGUo MCwgNjQpIHx8IEtFWSB8fCBNLCA1MTIpLAoKICAgICAgSDogU0hBS0UyNTYodG9CeXRlKDEs IDY0KSB8fCBLRVkgfHwgTSwgNTEyKSwKCiAgICAgIEhfbXNnOiBTSEFLRTI1Nih0b0J5dGUo MiwgNjQpIHx8IEtFWSB8fCBNLCA1MTIpLAoKICAgICAgUFJGOiBTSEFLRTI1Nih0b0J5dGUo MywgNjQpIHx8IEtFWSB8fCBNLCA1MTIpLgoKCgoKCkh1ZWxzaW5nLCBldCBhbC4gICAgICAg IEV4cGlyZXMgSmFudWFyeSAyNSwgMjAxOCAgICAgICAgICAgICAgIFtQYWdlIDQxXQoMCklu dGVybmV0LURyYWZ0ICAgIFhNU1M6IEV4dGVuZGVkIEhhc2gtQmFzZWQgU2lnbmF0dXJlcyAg ICAgICAgIEp1bHkgMjAxNwoKCiAgIEFzIGZvciBTSEEyLCBhbiBpbml0aWFsIG4tYnl0ZSBp ZGVudGlmaWVyIGlzIHVzZWQgdG8gYWNoaWV2ZQogICBpbmRlcGVuZGVuY2Ugb2YgdGhlIGRp ZmZlcmVudCBmdW5jdGlvbiBmYW1pbGllcy4gIFdoaWxlIGEgc2hvcnRlcgogICBpZGVudGlm aWVyIGNvdWxkIGJlIHVzZWQgaW4gY2FzZSBvZiBTSEEzLCB3ZSB1c2UgbiBieXRlcyBmb3IK ICAgY29uc2lzdGVuY3kgd2l0aCB0aGUgU0hBMiBpbXBsZW1lbnRhdGlvbnMuCgo1LjIuICBX T1RTKyBQYXJhbWV0ZXJzCgogICBUbyBmdWxseSBkZXNjcmliZSBhIFdPVFMrIHNpZ25hdHVy ZSBtZXRob2QsIHRoZSBwYXJhbWV0ZXJzIG4sIGFuZCB3LAogICBhcyB3ZWxsIGFzIHRoZSBm dW5jdGlvbnMgRiBhbmQgUFJGIE1VU1QgYmUgc3BlY2lmaWVkLiAgVGhpcyBzZWN0aW9uCiAg IGRlZmluZXMgc2V2ZXJhbCBXT1RTKyBzaWduYXR1cmUgc3lzdGVtcywgZWFjaCBvZiB3aGlj aCBpcyBpZGVudGlmaWVkCiAgIGJ5IGEgbmFtZS4gIE5hbWluZyBmb2xsb3dzIHRoZSBjb252 ZW50aW9uOiBXT1RTUC1bSGFzaGZhbWlseV1fW24gaW4KICAgYml0c10uICBOYW1pbmcgZG9l cyBub3QgaW5jbHVkZSB3IGFzIGFsbCBwYXJhbWV0ZXIgc2V0cyBpbiB0aGlzCiAgIGRvY3Vt ZW50IHVzZSB3PTE2LiAgVmFsdWVzIGZvciBsZW4gYXJlIHByb3ZpZGVkIGZvciBjb252ZW5p ZW5jZS4KCiAgICAgICAgICAgICAgKy0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0rLS0t LSstLS0tKy0tLS0tKwogICAgICAgICAgICAgIHwgTmFtZSAgICAgICAgICAgIHwgRiAvIFBS RiAgfCAgbiB8ICB3IHwgbGVuIHwKICAgICAgICAgICAgICArLS0tLS0tLS0tLS0tLS0tLS0r LS0tLS0tLS0tLSstLS0tKy0tLS0rLS0tLS0rCiAgICAgICAgICAgICAgfCBSRVFVSVJFRDog ICAgICAgfCAgICAgICAgICB8ICAgIHwgICAgfCAgICAgfAogICAgICAgICAgICAgIHwgICAg ICAgICAgICAgICAgIHwgICAgICAgICAgfCAgICB8ICAgIHwgICAgIHwKICAgICAgICAgICAg ICB8IFdPVFNQLVNIQTJfMjU2ICB8IFNIQTItMjU2IHwgMzIgfCAxNiB8ICA2NyB8CiAgICAg ICAgICAgICAgfCAgICAgICAgICAgICAgICAgfCAgICAgICAgICB8ICAgIHwgICAgfCAgICAg fAogICAgICAgICAgICAgIHwgT1BUSU9OQUw6ICAgICAgIHwgICAgICAgICAgfCAgICB8ICAg IHwgICAgIHwKICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICB8ICAgICAgICAgIHwg ICAgfCAgICB8ICAgICB8CiAgICAgICAgICAgICAgfCBXT1RTUC1TSEEyXzUxMiAgfCBTSEEy LTUxMiB8IDY0IHwgMTYgfCAxMzEgfAogICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAg IHwgICAgICAgICAgfCAgICB8ICAgIHwgICAgIHwKICAgICAgICAgICAgICB8IFdPVFNQLVNI QUtFXzI1NiB8IFNIQUtFMTI4IHwgMzIgfCAxNiB8ICA2NyB8CiAgICAgICAgICAgICAgfCAg ICAgICAgICAgICAgICAgfCAgICAgICAgICB8ICAgIHwgICAgfCAgICAgfAogICAgICAgICAg ICAgIHwgV09UU1AtU0hBS0VfNTEyIHwgU0hBS0UyNTYgfCA2NCB8IDE2IHwgMTMxIHwKICAg ICAgICAgICAgICArLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLSstLS0tKy0tLS0rLS0t LS0rCgogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgVGFibGUgMQoKICAgVGhl IGltcGxlbWVudGF0aW9uIG9mIHRoZSBzaW5nbGUgZnVuY3Rpb25zIGlzIGRvbmUgYXMgZGVz Y3JpYmVkCiAgIGFib3ZlLiAgWERSIGZvcm1hdHMgZm9yIFdPVFMrIGFyZSBsaXN0ZWQgaW4g QXBwZW5kaXggQS4KCjUuMy4gIFhNU1MgUGFyYW1ldGVycwoKICAgVG8gZnVsbHkgZGVzY3Jp YmUgYW4gWE1TUyBzaWduYXR1cmUgbWV0aG9kLCB0aGUgcGFyYW1ldGVycyBuLCB3LCBhbmQK ICAgaCwgYXMgd2VsbCBhcyB0aGUgZnVuY3Rpb25zIEYsIEgsIEhfbXNnLCBhbmQgUFJGIE1V U1QgYmUgc3BlY2lmaWVkLgogICBUaGlzIHNlY3Rpb24gZGVmaW5lcyBkaWZmZXJlbnQgWE1T UyBzaWduYXR1cmUgc3lzdGVtcywgZWFjaCBvZiB3aGljaAogICBpcyBpZGVudGlmaWVkIGJ5 IGEgbmFtZS4gIE5hbWluZyBmb2xsb3dzIHRoZSBjb252ZW50aW9uOgogICBYTVNTLVtIYXNo ZmFtaWx5XV9baF1fW24gaW4gYml0c10uICBOYW1pbmcgZG9lcyBub3QgaW5jbHVkZSB3IGFz IGFsbAogICBwYXJhbWV0ZXIgc2V0cyBpbiB0aGlzIGRvY3VtZW50IHVzZSB3PTE2LgoKCgoK CgoKCkh1ZWxzaW5nLCBldCBhbC4gICAgICAgIEV4cGlyZXMgSmFudWFyeSAyNSwgMjAxOCAg ICAgICAgICAgICAgIFtQYWdlIDQyXQoMCkludGVybmV0LURyYWZ0ICAgIFhNU1M6IEV4dGVu ZGVkIEhhc2gtQmFzZWQgU2lnbmF0dXJlcyAgICAgICAgIEp1bHkgMjAxNwoKCiAgICAgICAg ICArLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLSstLS0tKy0tLS0rLS0tLS0rLS0t LSsKICAgICAgICAgIHwgTmFtZSAgICAgICAgICAgICAgfCBGdW5jdGlvbnMgfCAgbiB8ICB3 IHwgbGVuIHwgIGggfAogICAgICAgICAgKy0tLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0t LS0rLS0tLSstLS0tKy0tLS0tKy0tLS0rCiAgICAgICAgICB8IFJFUVVJUkVEOiAgICAgICAg IHwgICAgICAgICAgIHwgICAgfCAgICB8ICAgICB8ICAgIHwKICAgICAgICAgIHwgICAgICAg ICAgICAgICAgICAgfCAgICAgICAgICAgfCAgICB8ICAgIHwgICAgIHwgICAgfAogICAgICAg ICAgfCBYTVNTLVNIQTJfMTBfMjU2ICB8IFNIQTItMjU2ICB8IDMyIHwgMTYgfCAgNjcgfCAx MCB8CiAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgIHwgICAgfCAg ICB8ICAgICB8ICAgIHwKICAgICAgICAgIHwgWE1TUy1TSEEyXzE2XzI1NiAgfCBTSEEyLTI1 NiAgfCAzMiB8IDE2IHwgIDY3IHwgMTYgfAogICAgICAgICAgfCAgICAgICAgICAgICAgICAg ICB8ICAgICAgICAgICB8ICAgIHwgICAgfCAgICAgfCAgICB8CiAgICAgICAgICB8IFhNU1Mt U0hBMl8yMF8yNTYgIHwgU0hBMi0yNTYgIHwgMzIgfCAxNiB8ICA2NyB8IDIwIHwKICAgICAg ICAgIHwgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgfCAgICB8ICAgIHwgICAgIHwg ICAgfAogICAgICAgICAgfCBPUFRJT05BTDogICAgICAgICB8ICAgICAgICAgICB8ICAgIHwg ICAgfCAgICAgfCAgICB8CiAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgIHwgICAgICAg ICAgIHwgICAgfCAgICB8ICAgICB8ICAgIHwKICAgICAgICAgIHwgWE1TUy1TSEEyXzEwXzUx MiAgfCBTSEEyLTUxMiAgfCA2NCB8IDE2IHwgMTMxIHwgMTAgfAogICAgICAgICAgfCAgICAg ICAgICAgICAgICAgICB8ICAgICAgICAgICB8ICAgIHwgICAgfCAgICAgfCAgICB8CiAgICAg ICAgICB8IFhNU1MtU0hBMl8xNl81MTIgIHwgU0hBMi01MTIgIHwgNjQgfCAxNiB8IDEzMSB8 IDE2IHwKICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgfCAgICB8 ICAgIHwgICAgIHwgICAgfAogICAgICAgICAgfCBYTVNTLVNIQTJfMjBfNTEyICB8IFNIQTIt NTEyICB8IDY0IHwgMTYgfCAxMzEgfCAyMCB8CiAgICAgICAgICB8ICAgICAgICAgICAgICAg ICAgIHwgICAgICAgICAgIHwgICAgfCAgICB8ICAgICB8ICAgIHwKICAgICAgICAgIHwgWE1T Uy1TSEFLRV8xMF8yNTYgfCBTSEFLRTEyOCAgfCAzMiB8IDE2IHwgIDY3IHwgMTAgfAogICAg ICAgICAgfCAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICB8ICAgIHwgICAgfCAgICAg fCAgICB8CiAgICAgICAgICB8IFhNU1MtU0hBS0VfMTZfMjU2IHwgU0hBS0UxMjggIHwgMzIg fCAxNiB8ICA2NyB8IDE2IHwKICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgfCAgICAg ICAgICAgfCAgICB8ICAgIHwgICAgIHwgICAgfAogICAgICAgICAgfCBYTVNTLVNIQUtFXzIw XzI1NiB8IFNIQUtFMTI4ICB8IDMyIHwgMTYgfCAgNjcgfCAyMCB8CiAgICAgICAgICB8ICAg ICAgICAgICAgICAgICAgIHwgICAgICAgICAgIHwgICAgfCAgICB8ICAgICB8ICAgIHwKICAg ICAgICAgIHwgWE1TUy1TSEFLRV8xMF81MTIgfCBTSEFLRTI1NiAgfCA2NCB8IDE2IHwgMTMx IHwgMTAgfAogICAgICAgICAgfCAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICB8ICAg IHwgICAgfCAgICAgfCAgICB8CiAgICAgICAgICB8IFhNU1MtU0hBS0VfMTZfNTEyIHwgU0hB S0UyNTYgIHwgNjQgfCAxNiB8IDEzMSB8IDE2IHwKICAgICAgICAgIHwgICAgICAgICAgICAg ICAgICAgfCAgICAgICAgICAgfCAgICB8ICAgIHwgICAgIHwgICAgfAogICAgICAgICAgfCBY TVNTLVNIQUtFXzIwXzUxMiB8IFNIQUtFMjU2ICB8IDY0IHwgMTYgfCAxMzEgfCAyMCB8CiAg ICAgICAgICArLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLSstLS0tKy0tLS0rLS0t LS0rLS0tLSsKCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBUYWJsZSAyCgog ICBUaGUgWERSIGZvcm1hdHMgZm9yIFhNU1MgYXJlIGxpc3RlZCBpbiBBcHBlbmRpeCBCLgoK NS4zLjEuICBQYXJhbWV0ZXIgZ3VpZGUKCiAgIEluIGNvbnRyYXN0IHRvIHRyYWRpdGlvbmFs IHNpZ25hdHVyZSBzY2hlbWVzIGxpa2UgUlNBIG9yIERTQSwgWE1TUwogICBoYXMgYSB0cmVl IGhlaWdodCBwYXJhbWV0ZXIgaCB3aGljaCBkZXRlcm1pbmVzIHRoZSBudW1iZXIgb2YgbWVz c2FnZXMKICAgdGhhdCBjYW4gYmUgc2lnbmVkIHdpdGggb25lIGtleSBwYWlyLiAgSW5jcmVh c2luZyB0aGUgaGVpZ2h0IGFsbG93cwogICB0byB1c2UgYSBrZXkgcGFpciBmb3IgbW9yZSBz aWduYXR1cmVzIGJ1dCBpdCBhbHNvIGluY3JlYXNlcyB0aGUKICAgc2lnbmF0dXJlIHNpemUg YW5kIHNsb3dzIGRvd24ga2V5IGdlbmVyYXRpb24sIHNpZ25pbmcsIGFuZAogICB2ZXJpZmlj YXRpb24uICBUbyBkZW1vbnN0cmF0ZSB0aGUgaW1wYWN0IG9mIGRpZmZlcmVudCB2YWx1ZXMg b2YgaCB0aGUKICAgZm9sbG93aW5nIHRhYmxlIHNob3dzIHNpZ25hdHVyZSBzaXplIGFuZCBy dW50aW1lcy4gIFJ1bnRpbWVzIGFyZQogICBnaXZlbiBhcyB0aGUgbnVtYmVyIG9mIGNhbGxz IHRvIEYgYW5kIEggd2hlbiB0aGUgQkRTIGFsZ29yaXRobSBpcwogICB1c2VkIHRvIGNvbXB1 dGUgYXV0aGVudGljYXRpb24gcGF0aHMgZm9yIHRoZSB3b3JzdCBjYXNlLiAgVGhlIGxhc3QK ICAgY29sdW1uIHNob3dzIHRoZSBudW1iZXIgb2YgbWVzc2FnZXMgdGhhdCBjYW4gYmUgc2ln bmVkIHdpdGggb25lIGtleQoKCgpIdWVsc2luZywgZXQgYWwuICAgICAgICBFeHBpcmVzIEph bnVhcnkgMjUsIDIwMTggICAgICAgICAgICAgICBbUGFnZSA0M10KDApJbnRlcm5ldC1EcmFm dCAgICBYTVNTOiBFeHRlbmRlZCBIYXNoLUJhc2VkIFNpZ25hdHVyZXMgICAgICAgICBKdWx5 IDIwMTcKCgogICBwYWlyLiAgVGhlIG51bWJlcnMgYXJlIHRoZSBzYW1lIGZvciB0aGUgWE1T Uy1TSEFLRSBpbnN0YW5jZXMgd2l0aAogICBzYW1lIHBhcmFtZXRlcnMgaCBhbmQgbi4KCiAg ICArLS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0rLS0tLS0tLS0tLS0tKy0tLS0tLS0tKy0t LS0tLS0tKy0tLS0tLS0rCiAgICB8IE5hbWUgICAgICAgICAgICAgfCB8U2lnfCB8ICAgICBL ZXlHZW4gfCAgIFNpZ24gfCBWZXJpZnkgfCAjU2lncyB8CiAgICArLS0tLS0tLS0tLS0tLS0t LS0tKy0tLS0tLS0rLS0tLS0tLS0tLS0tKy0tLS0tLS0tKy0tLS0tLS0tKy0tLS0tLS0rCiAg ICB8IFJFUVVJUkVEOiAgICAgICAgfCAgICAgICB8ICAgICAgICAgICAgfCAgICAgICAgfCAg ICAgICAgfCAgICAgICB8CiAgICB8ICAgICAgICAgICAgICAgICAgfCAgICAgICB8ICAgICAg ICAgICAgfCAgICAgICAgfCAgICAgICAgfCAgICAgICB8CiAgICB8IFhNU1MtU0hBMl8xMF8y NTYgfCAyLDUwMCB8ICAxLDIzOCwwMTYgfCAgNSw3MjUgfCAgMSwxNDkgfCAgMl4xMCB8CiAg ICB8ICAgICAgICAgICAgICAgICAgfCAgICAgICB8ICAgICAgICAgICAgfCAgICAgICAgfCAg ICAgICAgfCAgICAgICB8CiAgICB8IFhNU1MtU0hBMl8xNl8yNTYgfCAyLDY5MiB8ICAgIDc5 KjEwXjYgfCAgOSwxNjMgfCAgMSwxNTUgfCAgMl4xNiB8CiAgICB8ICAgICAgICAgICAgICAg ICAgfCAgICAgICB8ICAgICAgICAgICAgfCAgICAgICAgfCAgICAgICAgfCAgICAgICB8CiAg ICB8IFhNU1MtU0hBMl8yMF8yNTYgfCAyLDgyMCB8IDEsMjY4KjEwXjYgfCAxMSw0NTUgfCAg MSwxNTkgfCAgMl4yMCB8CiAgICB8ICAgICAgICAgICAgICAgICAgfCAgICAgICB8ICAgICAg ICAgICAgfCAgICAgICAgfCAgICAgICAgfCAgICAgICB8CiAgICB8IE9QVElPTkFMOiAgICAg ICAgfCAgICAgICB8ICAgICAgICAgICAgfCAgICAgICAgfCAgICAgICAgfCAgICAgICB8CiAg ICB8ICAgICAgICAgICAgICAgICAgfCAgICAgICB8ICAgICAgICAgICAgfCAgICAgICAgfCAg ICAgICAgfCAgICAgICB8CiAgICB8IFhNU1MtU0hBMl8xMF81MTIgfCA5LDA5MiB8ICAyLDQx Nyw2NjQgfCAxMSwxNjUgfCAgMiwyMzcgfCAgMl4xMCB8CiAgICB8ICAgICAgICAgICAgICAg ICAgfCAgICAgICB8ICAgICAgICAgICAgfCAgICAgICAgfCAgICAgICAgfCAgICAgICB8CiAg ICB8IFhNU1MtU0hBMl8xNl81MTIgfCA5LDQ3NiB8ICAgMTU1KjEwXjYgfCAxNyw4NjcgfCAg MiwyNDMgfCAgMl4xNiB8CiAgICB8ICAgICAgICAgICAgICAgICAgfCAgICAgICB8ICAgICAg ICAgICAgfCAgICAgICAgfCAgICAgICAgfCAgICAgICB8CiAgICB8IFhNU1MtU0hBMl8yMF81 MTIgfCA5LDczMiB8IDIsNDc2KjEwXjYgfCAyMiwzMzUgfCAgMiwyNDcgfCAgMl4yMCB8CiAg ICArLS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0rLS0tLS0tLS0tLS0tKy0tLS0tLS0tKy0t LS0tLS0tKy0tLS0tLS0rCgogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgVGFi bGUgMwoKICAgVXNlcnMgd2l0aG91dCBzcGVjaWFsIHJlcXVpcmVtZW50cyBzaG91bGQgdXNl IGFzIGRlZmF1bHQgb3B0aW9uIFhNU1MtCiAgIFNIQTJfMjBfMjU2IHdoaWNoIGFsbG93cyB0 byBzaWduIDJeMjAgbWVzc2FnZXMgd2l0aCBvbmUga2V5IHBhaXIgYW5kCiAgIHByb3ZpZGVz IHJlYXNvbmFibGUgc3BlZWQgYW5kIHNpZ25hdHVyZSBzaXplLiAgVXNlcnMgdGhhdCByZXF1 aXJlCiAgIG1vcmUgc2lnbmF0dXJlcyBwZXIga2V5IHBhaXIgb3IgZmFzdGVyIGtleSBnZW5l cmF0aW9uIHNob3VsZCBjb25zaWRlcgogICBYTVNTXk1ULgoKNS40LiAgWE1TU15NVCBQYXJh bWV0ZXJzCgogICBUbyBmdWxseSBkZXNjcmliZSBhbiBYTVNTXk1UIHNpZ25hdHVyZSBtZXRo b2QsIHRoZSBwYXJhbWV0ZXJzIG4sIHcsCiAgIGgsIGFuZCBkLCBhcyB3ZWxsIGFzIHRoZSBm dW5jdGlvbnMgRiwgSCwgSF9tc2csIGFuZCBQUkYgTVVTVCBiZQogICBzcGVjaWZpZWQuICBU aGlzIHNlY3Rpb24gZGVmaW5lcyBkaWZmZXJlbnQgWE1TU15NVCBzaWduYXR1cmUgc3lzdGVt cywKICAgZWFjaCBvZiB3aGljaCBpcyBpZGVudGlmaWVkIGJ5IGEgbmFtZS4gIE5hbWluZyBm b2xsb3dzIHRoZQogICBjb252ZW50aW9uOiBYTVNTTVQtW0hhc2hmYW1pbHldX1toXS9bZF1f W24gaW4gYml0c10uICBOYW1pbmcgZG9lcyBub3QKICAgaW5jbHVkZSB3IGFzIGFsbCBwYXJh bWV0ZXIgc2V0cyBpbiB0aGlzIGRvY3VtZW50IHVzZSB3PTE2LgoKICAgICArLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tKy0tLS0rLS0tLSstLS0tLSstLS0tKy0tLS0r CiAgICAgfCBOYW1lICAgICAgICAgICAgICAgICAgIHwgRnVuY3Rpb25zIHwgIG4gfCAgdyB8 IGxlbiB8ICBoIHwgIGQgfAogICAgICstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0t LS0tLS0rLS0tLSstLS0tKy0tLS0tKy0tLS0rLS0tLSsKICAgICB8IFJFUVVJUkVEOiAgICAg ICAgICAgICAgfCAgICAgICAgICAgfCAgICB8ICAgIHwgICAgIHwgICAgfCAgICB8CiAgICAg fCAgICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgIHwgICAgfCAgICB8ICAgICB8 ICAgIHwgICAgfAogICAgIHwgWE1TU01ULVNIQTJfMjAvMl8yNTYgICB8IFNIQTItMjU2ICB8 IDMyIHwgMTYgfCAgNjcgfCAyMCB8ICAyIHwKICAgICB8ICAgICAgICAgICAgICAgICAgICAg ICAgfCAgICAgICAgICAgfCAgICB8ICAgIHwgICAgIHwgICAgfCAgICB8CiAgICAgfCBYTVNT TVQtU0hBMl8yMC80XzI1NiAgIHwgU0hBMi0yNTYgIHwgMzIgfCAxNiB8ICA2NyB8IDIwIHwg IDQgfAoKCgpIdWVsc2luZywgZXQgYWwuICAgICAgICBFeHBpcmVzIEphbnVhcnkgMjUsIDIw MTggICAgICAgICAgICAgICBbUGFnZSA0NF0KDApJbnRlcm5ldC1EcmFmdCAgICBYTVNTOiBF eHRlbmRlZCBIYXNoLUJhc2VkIFNpZ25hdHVyZXMgICAgICAgICBKdWx5IDIwMTcKCgogICAg IHwgICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICB8ICAgIHwgICAgfCAgICAg fCAgICB8ICAgIHwKICAgICB8IFhNU1NNVC1TSEEyXzQwLzJfMjU2ICAgfCBTSEEyLTI1NiAg fCAzMiB8IDE2IHwgIDY3IHwgNDAgfCAgMiB8CiAgICAgfCAgICAgICAgICAgICAgICAgICAg ICAgIHwgICAgICAgICAgIHwgICAgfCAgICB8ICAgICB8ICAgIHwgICAgfAogICAgIHwgWE1T U01ULVNIQTJfNDAvNF8yNTYgICB8IFNIQTItMjU2ICB8IDMyIHwgMTYgfCAgNjcgfCA0MCB8 ICA0IHwKICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgfCAgICB8 ICAgIHwgICAgIHwgICAgfCAgICB8CiAgICAgfCBYTVNTTVQtU0hBMl80MC84XzI1NiAgIHwg U0hBMi0yNTYgIHwgMzIgfCAxNiB8ICA2NyB8IDQwIHwgIDggfAogICAgIHwgICAgICAgICAg ICAgICAgICAgICAgICB8ICAgICAgICAgICB8ICAgIHwgICAgfCAgICAgfCAgICB8ICAgIHwK ICAgICB8IFhNU1NNVC1TSEEyXzYwLzNfMjU2ICAgfCBTSEEyLTI1NiAgfCAzMiB8IDE2IHwg IDY3IHwgNjAgfCAgMyB8CiAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAg ICAgIHwgICAgfCAgICB8ICAgICB8ICAgIHwgICAgfAogICAgIHwgWE1TU01ULVNIQTJfNjAv Nl8yNTYgICB8IFNIQTItMjU2ICB8IDMyIHwgMTYgfCAgNjcgfCA2MCB8ICA2IHwKICAgICB8 ICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgfCAgICB8ICAgIHwgICAgIHwg ICAgfCAgICB8CiAgICAgfCBYTVNTTVQtU0hBMl82MC8xMl8yNTYgIHwgU0hBMi0yNTYgIHwg MzIgfCAxNiB8ICA2NyB8IDYwIHwgMTIgfAogICAgIHwgICAgICAgICAgICAgICAgICAgICAg ICB8ICAgICAgICAgICB8ICAgIHwgICAgfCAgICAgfCAgICB8ICAgIHwKICAgICB8IE9QVElP TkFMOiAgICAgICAgICAgICAgfCAgICAgICAgICAgfCAgICB8ICAgIHwgICAgIHwgICAgfCAg ICB8CiAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgIHwgICAgfCAg ICB8ICAgICB8ICAgIHwgICAgfAogICAgIHwgWE1TU01ULVNIQTJfMjAvMl81MTIgICB8IFNI QTItNTEyICB8IDY0IHwgMTYgfCAxMzEgfCAyMCB8ICAyIHwKICAgICB8ICAgICAgICAgICAg ICAgICAgICAgICAgfCAgICAgICAgICAgfCAgICB8ICAgIHwgICAgIHwgICAgfCAgICB8CiAg ICAgfCBYTVNTTVQtU0hBMl8yMC80XzUxMiAgIHwgU0hBMi01MTIgIHwgNjQgfCAxNiB8IDEz MSB8IDIwIHwgIDQgfAogICAgIHwgICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAg ICB8ICAgIHwgICAgfCAgICAgfCAgICB8ICAgIHwKICAgICB8IFhNU1NNVC1TSEEyXzQwLzJf NTEyICAgfCBTSEEyLTUxMiAgfCA2NCB8IDE2IHwgMTMxIHwgNDAgfCAgMiB8CiAgICAgfCAg ICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgIHwgICAgfCAgICB8ICAgICB8ICAg IHwgICAgfAogICAgIHwgWE1TU01ULVNIQTJfNDAvNF81MTIgICB8IFNIQTItNTEyICB8IDY0 IHwgMTYgfCAxMzEgfCA0MCB8ICA0IHwKICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAg fCAgICAgICAgICAgfCAgICB8ICAgIHwgICAgIHwgICAgfCAgICB8CiAgICAgfCBYTVNTTVQt U0hBMl80MC84XzUxMiAgIHwgU0hBMi01MTIgIHwgNjQgfCAxNiB8IDEzMSB8IDQwIHwgIDgg fAogICAgIHwgICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICB8ICAgIHwgICAg fCAgICAgfCAgICB8ICAgIHwKICAgICB8IFhNU1NNVC1TSEEyXzYwLzNfNTEyICAgfCBTSEEy LTUxMiAgfCA2NCB8IDE2IHwgMTMxIHwgNjAgfCAgMyB8CiAgICAgfCAgICAgICAgICAgICAg ICAgICAgICAgIHwgICAgICAgICAgIHwgICAgfCAgICB8ICAgICB8ICAgIHwgICAgfAogICAg IHwgWE1TU01ULVNIQTJfNjAvNl81MTIgICB8IFNIQTItNTEyICB8IDY0IHwgMTYgfCAxMzEg fCA2MCB8ICA2IHwKICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAg fCAgICB8ICAgIHwgICAgIHwgICAgfCAgICB8CiAgICAgfCBYTVNTTVQtU0hBMl82MC8xMl81 MTIgIHwgU0hBMi01MTIgIHwgNjQgfCAxNiB8IDEzMSB8IDYwIHwgMTIgfAogICAgIHwgICAg ICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICB8ICAgIHwgICAgfCAgICAgfCAgICB8 ICAgIHwKICAgICB8IFhNU1NNVC1TSEFLRV8yMC8yXzI1NiAgfCBTSEFLRTEyOCAgfCAzMiB8 IDE2IHwgIDY3IHwgMjAgfCAgMiB8CiAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgIHwg ICAgICAgICAgIHwgICAgfCAgICB8ICAgICB8ICAgIHwgICAgfAogICAgIHwgWE1TU01ULVNI QUtFXzIwLzRfMjU2ICB8IFNIQUtFMTI4ICB8IDMyIHwgMTYgfCAgNjcgfCAyMCB8ICA0IHwK ICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgfCAgICB8ICAgIHwg ICAgIHwgICAgfCAgICB8CiAgICAgfCBYTVNTTVQtU0hBS0VfNDAvMl8yNTYgIHwgU0hBS0Ux MjggIHwgMzIgfCAxNiB8ICA2NyB8IDQwIHwgIDIgfAogICAgIHwgICAgICAgICAgICAgICAg ICAgICAgICB8ICAgICAgICAgICB8ICAgIHwgICAgfCAgICAgfCAgICB8ICAgIHwKICAgICB8 IFhNU1NNVC1TSEFLRV80MC80XzI1NiAgfCBTSEFLRTEyOCAgfCAzMiB8IDE2IHwgIDY3IHwg NDAgfCAgNCB8CiAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgIHwg ICAgfCAgICB8ICAgICB8ICAgIHwgICAgfAogICAgIHwgWE1TU01ULVNIQUtFXzQwLzhfMjU2 ICB8IFNIQUtFMTI4ICB8IDMyIHwgMTYgfCAgNjcgfCA0MCB8ICA4IHwKICAgICB8ICAgICAg ICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgfCAgICB8ICAgIHwgICAgIHwgICAgfCAg ICB8CiAgICAgfCBYTVNTTVQtU0hBS0VfNjAvM18yNTYgIHwgU0hBS0UxMjggIHwgMzIgfCAx NiB8ICA2NyB8IDYwIHwgIDMgfAogICAgIHwgICAgICAgICAgICAgICAgICAgICAgICB8ICAg ICAgICAgICB8ICAgIHwgICAgfCAgICAgfCAgICB8ICAgIHwKICAgICB8IFhNU1NNVC1TSEFL RV82MC82XzI1NiAgfCBTSEFLRTEyOCAgfCAzMiB8IDE2IHwgIDY3IHwgNjAgfCAgNiB8CiAg ICAgfCAgICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgIHwgICAgfCAgICB8ICAg ICB8ICAgIHwgICAgfAogICAgIHwgWE1TU01ULVNIQUtFXzYwLzEyXzI1NiB8IFNIQUtFMTI4 ICB8IDMyIHwgMTYgfCAgNjcgfCA2MCB8IDEyIHwKICAgICB8ICAgICAgICAgICAgICAgICAg ICAgICAgfCAgICAgICAgICAgfCAgICB8ICAgIHwgICAgIHwgICAgfCAgICB8CiAgICAgfCBY TVNTTVQtU0hBS0VfMjAvMl81MTIgIHwgU0hBS0UyNTYgIHwgNjQgfCAxNiB8IDEzMSB8IDIw IHwgIDIgfAoKCgpIdWVsc2luZywgZXQgYWwuICAgICAgICBFeHBpcmVzIEphbnVhcnkgMjUs IDIwMTggICAgICAgICAgICAgICBbUGFnZSA0NV0KDApJbnRlcm5ldC1EcmFmdCAgICBYTVNT OiBFeHRlbmRlZCBIYXNoLUJhc2VkIFNpZ25hdHVyZXMgICAgICAgICBKdWx5IDIwMTcKCgog ICAgIHwgICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICB8ICAgIHwgICAgfCAg ICAgfCAgICB8ICAgIHwKICAgICB8IFhNU1NNVC1TSEFLRV8yMC80XzUxMiAgfCBTSEFLRTI1 NiAgfCA2NCB8IDE2IHwgMTMxIHwgMjAgfCAgNCB8CiAgICAgfCAgICAgICAgICAgICAgICAg ICAgICAgIHwgICAgICAgICAgIHwgICAgfCAgICB8ICAgICB8ICAgIHwgICAgfAogICAgIHwg WE1TU01ULVNIQUtFXzQwLzJfNTEyICB8IFNIQUtFMjU2ICB8IDY0IHwgMTYgfCAxMzEgfCA0 MCB8ICAyIHwKICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgfCAg ICB8ICAgIHwgICAgIHwgICAgfCAgICB8CiAgICAgfCBYTVNTTVQtU0hBS0VfNDAvNF81MTIg IHwgU0hBS0UyNTYgIHwgNjQgfCAxNiB8IDEzMSB8IDQwIHwgIDQgfAogICAgIHwgICAgICAg ICAgICAgICAgICAgICAgICB8ICAgICAgICAgICB8ICAgIHwgICAgfCAgICAgfCAgICB8ICAg IHwKICAgICB8IFhNU1NNVC1TSEFLRV80MC84XzUxMiAgfCBTSEFLRTI1NiAgfCA2NCB8IDE2 IHwgMTMxIHwgNDAgfCAgOCB8CiAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgIHwgICAg ICAgICAgIHwgICAgfCAgICB8ICAgICB8ICAgIHwgICAgfAogICAgIHwgWE1TU01ULVNIQUtF XzYwLzNfNTEyICB8IFNIQUtFMjU2ICB8IDY0IHwgMTYgfCAxMzEgfCA2MCB8ICAzIHwKICAg ICB8ICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgfCAgICB8ICAgIHwgICAg IHwgICAgfCAgICB8CiAgICAgfCBYTVNTTVQtU0hBS0VfNjAvNl81MTIgIHwgU0hBS0UyNTYg IHwgNjQgfCAxNiB8IDEzMSB8IDYwIHwgIDYgfAogICAgIHwgICAgICAgICAgICAgICAgICAg ICAgICB8ICAgICAgICAgICB8ICAgIHwgICAgfCAgICAgfCAgICB8ICAgIHwKICAgICB8IFhN U1NNVC1TSEFLRV82MC8xMl81MTIgfCBTSEFLRTI1NiAgfCA2NCB8IDE2IHwgMTMxIHwgNjAg fCAxMiB8CiAgICAgKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLSstLS0t Ky0tLS0rLS0tLS0rLS0tLSstLS0tKwoKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIFRhYmxlIDQKCiAgIFhEUiBmb3JtYXRzIGZvciBYTVNTXk1UIGFyZSBsaXN0ZWQgaW4g QXBwZW5kaXggQy4KCjUuNS4gIFBhcmFtZXRlciBndWlkZQoKICAgSW4gYWRkaXRpb24gdG8g dGhlIHRyZWUgaGVpZ2h0IHBhcmFtZXRlciBhbHJlYWR5IHVzZWQgZm9yIFhNU1MsCiAgIFhN U1NeTVQgaGFzIHRoZSBwYXJhbWV0ZXIgZCB3aGljaCBkZXRlcm1pbmVzIHRoZSBudW1iZXIg b2YgdHJlZQogICBsYXllcnMuICBYTVNTIGNhbiBiZSB1bmRlcnN0b29kIGFzIFhNU1NeTVQg d2l0aCBhIHNpbmdsZSBsYXllciwgaS5lLiwKICAgZD0xLiAgSGVuY2UsIHRoZSBjaG9pY2Ug b2YgaCBoYXMgdGhlIHNhbWUgZWZmZWN0IGFzIGZvciBYTVNTLiAgVGhlCiAgIG51bWJlciBv ZiB0cmVlIGxheWVycyBwcm92aWRlcyBhIHRyYWRlLW9mZiBiZXR3ZWVuIHNpZ25hdHVyZSBz aXplIG9uCiAgIHRoZSBvbmUgc2lkZSBhbmQga2V5IGdlbmVyYXRpb24gYW5kIHNpZ25pbmcg c3BlZWQgb24gdGhlIG90aGVyIHNpZGUuCiAgIEluY3JlYXNpbmcgdGhlIG51bWJlciBvZiBs YXllcnMgcmVkdWNlcyBrZXkgZ2VuZXJhdGlvbiB0aW1lCiAgIGV4cG9uZW50aWFsbHkgYW5k IHNpZ25pbmcgdGltZSBsaW5lYXJseSBhdCB0aGUgY29zdCBvZiBpbmNyZWFzaW5nIHRoZQog ICBzaWduYXR1cmUgc2l6ZSBsaW5lYXJseS4gIEVzc2VudGlhbGx5LCBhbiBYTVNTXk1UIHNp Z25hdHVyZSBjb250YWlucwogICBvbmUgV09UU1Agc2lnbmF0dXJlIHBlciBsYXllci4gIFNw ZWVkIHJvdWdobHkgY29ycmVzcG9uZHMgdG8gZC10aW1lcwogICB0aGUgc3BlZWQgZm9yIFhN U1Mgd2l0aCB0cmVlcyBvZiBoZWlnaHQgaC9kLgoKICAgVG8gZGVtb25zdHJhdGUgdGhlIGlt cGFjdCBvZiBkaWZmZXJlbnQgdmFsdWVzIG9mIGggYW5kIGQgdGhlCiAgIGZvbGxvd2luZyB0 YWJsZSBzaG93cyBzaWduYXR1cmUgc2l6ZSBhbmQgcnVudGltZXMuICBSdW50aW1lcyBhcmUK ICAgZ2l2ZW4gYXMgdGhlIG51bWJlciBvZiBjYWxscyB0byBGIGFuZCBIIHdoZW4gdGhlIEJE UyBhbGdvcml0aG0gYW5kCiAgIGRpc3RyaWJ1dGVkIHNpZ25hdHVyZSBnZW5lcmF0aW9uIGFy ZSB1c2VkLiAgVGltaW5ncyBhcmUgd29yc3QtY2FzZQogICB0aW1lcy4gIFRoZSBsYXN0IGNv bHVtbiBzaG93cyB0aGUgbnVtYmVyIG9mIG1lc3NhZ2VzIHRoYXQgY2FuIGJlCiAgIHNpZ25l ZCB3aXRoIG9uZSBrZXkgcGFpci4gIFRoZSBudW1iZXJzIGFyZSB0aGUgc2FtZSBmb3IgdGhl IFhNU1MtCiAgIFNIQUtFIGluc3RhbmNlcyB3aXRoIHNhbWUgcGFyYW1ldGVycyBoIGFuZCBu LiAgRHVlIHRvIGZvcm1hdHRpbmcKICAgbGltaXRhdGlvbnMsIG9ubHkgdGhlIHBhcmFtZXRl ciBwYXJ0IG9mIHRoZSBwYXJhbWV0ZXIgc2V0IG5hbWVzIGFyZQogICBnaXZlbiwgb21pdHRp bmcgdGhlIG5hbWUgWE1TU01ULgoKCgoKCgoKCkh1ZWxzaW5nLCBldCBhbC4gICAgICAgIEV4 cGlyZXMgSmFudWFyeSAyNSwgMjAxOCAgICAgICAgICAgICAgIFtQYWdlIDQ2XQoMCkludGVy bmV0LURyYWZ0ICAgIFhNU1M6IEV4dGVuZGVkIEhhc2gtQmFzZWQgU2lnbmF0dXJlcyAgICAg ICAgIEp1bHkgMjAxNwoKCiAgICArLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0rLS0tLS0t LS0tLS0tKy0tLS0tLS0tKy0tLS0tLS0tKy0tLS0tLS0rCiAgICB8IE5hbWUgICAgICAgICAg IHwgICB8U2lnfCB8ICAgICBLZXlHZW4gfCAgIFNpZ24gfCBWZXJpZnkgfCAjU2lncyB8CiAg ICArLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0rLS0tLS0tLS0tLS0tKy0tLS0tLS0tKy0t LS0tLS0tKy0tLS0tLS0rCiAgICB8IFJFUVVJUkVEOiAgICAgIHwgICAgICAgICB8ICAgICAg ICAgICAgfCAgICAgICAgfCAgICAgICAgfCAgICAgICB8CiAgICB8ICAgICAgICAgICAgICAg IHwgICAgICAgICB8ICAgICAgICAgICAgfCAgICAgICAgfCAgICAgICAgfCAgICAgICB8CiAg ICB8IFNIQTJfMjAvMl8yNTYgIHwgICA0LDk2MyB8ICAyLDQ3NiwwMzIgfCAgNywyMjcgfCAg MiwyOTggfCAgMl4yMCB8CiAgICB8ICAgICAgICAgICAgICAgIHwgICAgICAgICB8ICAgICAg ICAgICAgfCAgICAgICAgfCAgICAgICAgfCAgICAgICB8CiAgICB8IFNIQTJfMjAvNF8yNTYg IHwgICA5LDI1MSB8ICAgIDE1NCw3NTIgfCAgNCwxNzAgfCAgNCw1NzYgfCAgMl4yMCB8CiAg ICB8ICAgICAgICAgICAgICAgIHwgICAgICAgICB8ICAgICAgICAgICAgfCAgICAgICAgfCAg ICAgICAgfCAgICAgICB8CiAgICB8IFNIQTJfNDAvMl8yNTYgIHwgICA1LDYwNSB8IDIsNTM1 KjEwXjYgfCAxMyw0MTcgfCAgMiwzMTggfCAgMl40MCB8CiAgICB8ICAgICAgICAgICAgICAg IHwgICAgICAgICB8ICAgICAgICAgICAgfCAgICAgICAgfCAgICAgICAgfCAgICAgICB8CiAg ICB8IFNIQTJfNDAvNF8yNTYgIHwgICA5LDg5MyB8ICA0LDk1MiwwNjQgfCAgNywyMjcgfCAg NCw1OTYgfCAgMl40MCB8CiAgICB8ICAgICAgICAgICAgICAgIHwgICAgICAgICB8ICAgICAg ICAgICAgfCAgICAgICAgfCAgICAgICAgfCAgICAgICB8CiAgICB8IFNIQTJfNDAvOF8yNTYg IHwgIDE4LDQ2OSB8ICAgIDMwOSw1MDQgfCAgNCwxNzAgfCAgOSwxNTIgfCAgMl40MCB8CiAg ICB8ICAgICAgICAgICAgICAgIHwgICAgICAgICB8ICAgICAgICAgICAgfCAgICAgICAgfCAg ICAgICAgfCAgICAgICB8CiAgICB8IFNIQTJfNjAvM18yNTYgIHwgICA4LDM5MiB8IDMsODAz KjEwXjYgfCAxMyw0MTcgfCAgMyw0NzcgfCAgMl42MCB8CiAgICB8ICAgICAgICAgICAgICAg IHwgICAgICAgICB8ICAgICAgICAgICAgfCAgICAgICAgfCAgICAgICAgfCAgICAgICB8CiAg ICB8IFNIQTJfNjAvNl8yNTYgIHwgIDE0LDgyNCB8ICA3LDQyOCwwOTYgfCAgNywyMjcgfCAg Niw4OTQgfCAgMl42MCB8CiAgICB8ICAgICAgICAgICAgICAgIHwgICAgICAgICB8ICAgICAg ICAgICAgfCAgICAgICAgfCAgICAgICAgfCAgICAgICB8CiAgICB8IFNIQTJfNjAvMTJfMjU2 IHwgIDI3LDY4OCB8ICAgIDQ2NCwyNTYgfCAgNCwxNzAgfCAxMyw3MjggfCAgMl42MCB8CiAg ICB8ICAgICAgICAgICAgICAgIHwgICAgICAgICB8ICAgICAgICAgICAgfCAgICAgICAgfCAg ICAgICAgfCAgICAgICB8CiAgICB8IE9QVElPTkFMOiAgICAgIHwgICAgICAgICB8ICAgICAg ICAgICAgfCAgICAgICAgfCAgICAgICAgfCAgICAgICB8CiAgICB8ICAgICAgICAgICAgICAg IHwgICAgICAgICB8ICAgICAgICAgICAgfCAgICAgICAgfCAgICAgICAgfCAgICAgICB8CiAg ICB8IFNIQTJfMjAvMl81MTIgIHwgIDE4LDExNSB8ICA0LDgzNSwzMjggfCAxNCwwNzUgfCAg NCw0NzQgfCAgMl4yMCB8CiAgICB8ICAgICAgICAgICAgICAgIHwgICAgICAgICB8ICAgICAg ICAgICAgfCAgICAgICAgfCAgICAgICAgfCAgICAgICB8CiAgICB8IFNIQTJfMjAvNF81MTIg IHwgIDM0LDg4MyB8ICAgIDMwMiwyMDggfCAgOCwxMzggfCAgOCw5MjggfCAgMl4yMCB8CiAg ICB8ICAgICAgICAgICAgICAgIHwgICAgICAgICB8ICAgICAgICAgICAgfCAgICAgICAgfCAg ICAgICAgfCAgICAgICB8CiAgICB8IFNIQTJfNDAvMl81MTIgIHwgIDE5LDM5NyB8IDQsOTUx KjEwXjYgfCAyNiwwMjUgfCAgNCw0OTQgfCAgMl40MCB8CiAgICB8ICAgICAgICAgICAgICAg IHwgICAgICAgICB8ICAgICAgICAgICAgfCAgICAgICAgfCAgICAgICAgfCAgICAgICB8CiAg ICB8IFNIQTJfNDAvNF81MTIgIHwgIDM2LDE2NSB8ICA5LDY3MCw2NTYgfCAxNCwwNzUgfCAg OCw5NDggfCAgMl40MCB8CiAgICB8ICAgICAgICAgICAgICAgIHwgICAgICAgICB8ICAgICAg ICAgICAgfCAgICAgICAgfCAgICAgICAgfCAgICAgICB8CiAgICB8IFNIQTJfNDAvOF81MTIg IHwgIDY5LDcwMSB8ICAgIDYwNCw0MTYgfCAgOCwxMzggfCAxNyw4NTYgfCAgMl40MCB8CiAg ICB8ICAgICAgICAgICAgICAgIHwgICAgICAgICB8ICAgICAgICAgICAgfCAgICAgICAgfCAg ICAgICAgfCAgICAgICB8CiAgICB8IFNIQTJfNjAvM181MTIgIHwgIDI5LDA2NCB8IDcsNDI3 KjEwXjYgfCAyNiwwMjUgfCAgNiw3NDEgfCAgMl42MCB8CiAgICB8ICAgICAgICAgICAgICAg IHwgICAgICAgICB8ICAgICAgICAgICAgfCAgICAgICAgfCAgICAgICAgfCAgICAgICB8CiAg ICB8IFNIQTJfNjAvNl81MTIgIHwgIDU0LDIxNiB8IDE0LDUwNSw5ODQgfCAxNCwwNzUgfCAx Myw0MjIgfCAgMl42MCB8CiAgICB8ICAgICAgICAgICAgICAgIHwgICAgICAgICB8ICAgICAg ICAgICAgfCAgICAgICAgfCAgICAgICAgfCAgICAgICB8CiAgICB8IFNIQTJfNjAvMTJfNTEy IHwgMTA0LDUyMCB8ICAgIDkwNiw2MjQgfCAgOCwxMzggfCAyNiw3ODQgfCAgMl42MCB8CiAg ICArLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0rLS0tLS0tLS0tLS0tKy0tLS0tLS0tKy0t LS0tLS0tKy0tLS0tLS0rCgogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgVGFi bGUgNQoKICAgVXNlcnMgd2l0aG91dCBzcGVjaWFsIHJlcXVpcmVtZW50cyBzaG91bGQgdXNl IGFzIGRlZmF1bHQgb3B0aW9uCiAgIFhNU1NNVC1TSEEyXzYwLzNfMjU2IHdoaWNoIGFsbG93 cyB0byBzaWduIDJeNjAgbWVzc2FnZXMgd2l0aCBvbmUga2V5CiAgIHBhaXIsIHdoaWNoIGlz IGEgdmlydHVhbGx5IHVuYm91bmRlZCBudW1iZXIgb2Ygc2lnbmF0dXJlcy4gIEF0IHRoZQog ICBzYW1lIHRpbWUsIHNpZ25hdHVyZSBzaXplIGFuZCBzcGVlZCBhcmUgd2VsbCBiYWxhbmNl ZC4KCgoKCgpIdWVsc2luZywgZXQgYWwuICAgICAgICBFeHBpcmVzIEphbnVhcnkgMjUsIDIw MTggICAgICAgICAgICAgICBbUGFnZSA0N10KDApJbnRlcm5ldC1EcmFmdCAgICBYTVNTOiBF eHRlbmRlZCBIYXNoLUJhc2VkIFNpZ25hdHVyZXMgICAgICAgICBKdWx5IDIwMTcKCgo2LiAg UmF0aW9uYWxlCgogICBUaGUgZ29hbCBvZiB0aGlzIG5vdGUgaXMgdG8gZGVzY3JpYmUgdGhl IFdPVFMrLCBYTVNTIGFuZCBYTVNTXk1UCiAgIGFsZ29yaXRobXMgZm9sbG93aW5nIHRoZSBz Y2llbnRpZmljIGxpdGVyYXR1cmUuICBUaGUgZGVzY3JpcHRpb24gaXMKICAgZG9uZSBpbiBh IG1vZHVsYXIgd2F5IHRoYXQgYWxsb3dzIHRvIGJhc2UgYSBkZXNjcmlwdGlvbiBvZiBzdGF0 ZWxlc3MKICAgaGFzaC1iYXNlZCBzaWduYXR1cmUgYWxnb3JpdGhtcyBsaWtlIFNQSElOQ1Mg W0JISDE1XSBvbiBpdC4KCiAgIFRoaXMgbm90ZSBzbGlnaHRseSBkZXZpYXRlcyBmcm9tIHRo ZSBzY2llbnRpZmljIGxpdGVyYXR1cmUgdXNpbmcgYQogICB0d2VhayB0aGF0IHByZXZlbnRz IG11bHRpLXVzZXIgLyBtdWx0aS10YXJnZXQgYXR0YWNrcyBhZ2FpbnN0IEhfbXNnLgogICBU byB0aGlzIGVuZCwgdGhlIHB1YmxpYyBrZXkgYXMgd2VsbCBhcyB0aGUgaW5kZXggb2YgdGhl IHVzZWQgb25lLXRpbWUKICAga2V5IHBhaXIgYmVjb21lIHBhcnQgb2YgdGhlIGhhc2ggZnVu Y3Rpb24ga2V5LiAgVGhlcmVieSB3ZSBhY2hpZXZlIGEKICAgZG9tYWluIHNlcGFyYXRpb24g dGhhdCBmb3JjZXMgYW4gYXR0YWNrZXIgdG8gZGVjaWRlIHdoaWNoIGhhc2ggdmFsdWUKICAg dG8gYXR0YWNrLgoKICAgRm9yIHRoZSBnZW5lcmF0aW9uIG9mIHRoZSByYW5kb21uZXNzIHVz ZWQgZm9yIHJhbmRvbWl6ZWQgbWVzc2FnZQogICBoYXNoaW5nLCB3ZSBhcHBseSBhIFBSRiwg a2V5ZWQgd2l0aCBhIHNlY3JldCB2YWx1ZSwgdG8gdGhlIGluZGV4IG9mCiAgIHRoZSB1c2Vk IG9uZS10aW1lIGtleSBwYWlyIGluc3RlYWQgb2YgdGhlIG1lc3NhZ2UuICBUaGUgcmVhc29u IGlzCiAgIHRoYXQgdGhpcyByZXF1aXJlcyB0byBwcm9jZXNzIHRoZSBtZXNzYWdlIG9ubHkg b25jZSBpbnN0ZWFkIG9mIHR3aWNlLgogICBGb3IgbG9uZyBtZXNzYWdlcyB0aGlzIGltcHJv dmVzIHNwZWVkIGFuZCBzaW1wbGlmaWVzIGltcGxlbWVudGF0aW9ucwogICBvbiByZXNvdXJj ZSBjb25zdHJhaW5lZCBkZXZpY2VzIHRoYXQgY2Fubm90IGhvbGQgdGhlIGVudGlyZSBtZXNz YWdlCiAgIGluIHN0b3JhZ2UuCgogICBXZSBnaXZlIG9uZSBtYW5kYXRvcnkgc2V0IG9mIHBh cmFtZXRlcnMgdXNpbmcgU0hBMi0yNTYuICBUaGUgcmVhc29ucwogICBhcmUgdHdvZm9sZC4g IE9uIHRoZSBvbmUgaGFuZCwgU0hBMi0yNTYgaXMgcGFydCBvZiBtb3N0IGNyeXB0b2dyYXBo aWMKICAgbGlicmFyaWVzLiAgT24gdGhlIG90aGVyIGhhbmQsIGEgMjU2LWJpdCBoYXNoIGZ1 bmN0aW9uIGxlYWRzIHRvCiAgIHBhcmFtZXRlcnMgdGhhdCBwcm92aWRlIDEyOCBiaXQgb2Yg c2VjdXJpdHkgZXZlbiBhZ2FpbnN0IHF1YW50dW0tCiAgIGNvbXB1dGVyLWFpZGVkIGF0dGFj a3MuICBBIHBvc3QtcXVhbnR1bSBzZWN1cml0eSBsZXZlbCBvZiAyNTYgYml0CiAgIHNlZW1z IG92ZXJseSBjb25zZXJ2YXRpdmUuICBIb3dldmVyLCB0byBwcmVwYXJlIGZvciBwb3NzaWJs ZQogICBjcnlwdGFuYWx5dGljIGJyZWFrdGhyb3VnaHMsIHdlIGFsc28gcHJvdmlkZSBPUFRJ T05BTCBwYXJhbWV0ZXIgc2V0cwogICB1c2luZyB0aGUgbGVzcyB3aWRlbHkgc3VwcG9ydGVk IFNIQTItNTEyLCBTSEFLRS0yNTYsIGFuZCBTSEFLRS01MTIKICAgZnVuY3Rpb25zLgoKICAg V2Ugc3VnZ2VzdCB0aGUgdmFsdWUgdyA9IDE2IGZvciB0aGUgV2ludGVybml0eiBwYXJhbWV0 ZXIuICBObyBiaWdnZXIKICAgdmFsdWVzIGFyZSBpbmNsdWRlZCBzaW5jZSB0aGUgZGVjcmVh c2UgaW4gc2lnbmF0dXJlIHNpemUgdGhlbiBiZWNvbWVzCiAgIGxlc3Mgc2lnbmlmaWNhbnQu ICBGdXJ0aGVybW9yZSwgdGhlIHZhbHVlIHcgPSAxNiBjb25zaWRlcmFibHkKICAgc2ltcGxp ZmllcyB0aGUgaW1wbGVtZW50YXRpb25zIG9mIHNvbWUgb2YgdGhlIGFsZ29yaXRobXMuICBQ bGVhc2UKICAgbm90ZSB0aGF0IHdlIGRvIGFsbG93IHcgPSA0LCBidXQgbGltaXQgdGhlIHNw ZWNpZmllZCBwYXJhbWV0ZXIgc2V0cwogICB0byB3ID0gMTYgZm9yIGVmZmljaWVuY3kgcmVh c29ucy4KCiAgIFRoZSBzaWduYXR1cmUgYW5kIHB1YmxpYyBrZXkgZm9ybWF0cyBhcmUgZGVz aWduZWQgc28gdGhhdCB0aGV5IGFyZQogICBlYXN5IHRvIHBhcnNlLiAgRWFjaCBmb3JtYXQg c3RhcnRzIHdpdGggYSAzMi1iaXQgZW51bWVyYXRpb24gdmFsdWUKICAgdGhhdCBpbmRpY2F0 ZXMgYWxsIG9mIHRoZSBkZXRhaWxzIG9mIHRoZSBzaWduYXR1cmUgYWxnb3JpdGhtIGFuZAog ICBoZW5jZSBkZWZpbmVzIGFsbCBvZiB0aGUgaW5mb3JtYXRpb24gdGhhdCBpcyBuZWVkZWQg aW4gb3JkZXIgdG8gcGFyc2UKICAgdGhlIGZvcm1hdC4KCiAgIFRoZSBlbnVtZXJhdGlvbiB2 YWx1ZXMgdXNlZCBpbiB0aGlzIG5vdGUgYXJlIHBhbGluZHJvbWVzLCB3aGljaCBoYXZlCiAg IHRoZSBzYW1lIGJ5dGUgcmVwcmVzZW50YXRpb24gaW4gZWl0aGVyIGhvc3Qgb3JkZXIgb3Ig bmV0d29yayBvcmRlci4KICAgVGhpcyBmYWN0IGFsbG93cyBhbiBpbXBsZW1lbnRhdGlvbiB0 byBvbWl0IHRoZSBjb252ZXJzaW9uIGJldHdlZW4KCgoKSHVlbHNpbmcsIGV0IGFsLiAgICAg ICAgRXhwaXJlcyBKYW51YXJ5IDI1LCAyMDE4ICAgICAgICAgICAgICAgW1BhZ2UgNDhdCgwK SW50ZXJuZXQtRHJhZnQgICAgWE1TUzogRXh0ZW5kZWQgSGFzaC1CYXNlZCBTaWduYXR1cmVz ICAgICAgICAgSnVseSAyMDE3CgoKICAgYnl0ZSBvcmRlciBmb3IgdGhvc2UgZW51bWVyYXRp b25zLiAgTm90ZSBob3dldmVyIHRoYXQgdGhlIGlkeCBmaWVsZAogICB1c2VkIGluIFhNU1Mg YW5kIFhNU1NeTVQgc2lnbmF0dXJlcyBhbmQgcHJpdmF0ZSBrZXlzIE1VU1QgYmUgcHJvcGVy bHkKICAgY29udmVydGVkIHRvIGFuZCBmcm9tIG5ldHdvcmsgYnl0ZSBvcmRlcjsgdGhpcyBp cyB0aGUgb25seSBmaWVsZCB0aGF0CiAgIHJlcXVpcmVzIHN1Y2ggY29udmVyc2lvbi4gIFRo ZXJlIGFyZSAyXjMyIFhEUiBlbnVtZXJhdGlvbiB2YWx1ZXMsCiAgIDJeMTYgb2Ygd2hpY2gg YXJlIHBhbGluZHJvbWVzLCB3aGljaCBpcyBhZGVxdWF0ZSBmb3IgdGhlIGZvcmVzZWVhYmxl CiAgIGZ1dHVyZS4gIElmIHRoZXJlIGlzIGEgbmVlZCBmb3IgZnVydGhlciBhc3NpZ25tZW50 cywgbm9uLXBhbGluZHJvbWVzCiAgIGNhbiBiZSBhc3NpZ25lZC4KCjcuICBSZWZlcmVuY2Ug Q29kZQoKICAgRm9yIHRlc3RpbmcgcHVycG9zZXMsIGEgcmVmZXJlbmNlIGltcGxlbWVudGF0 aW9uIGluIEMgaXMgYXZhaWxhYmxlLgogICBUaGUgY29kZSBjb250YWlucyBhIGJhc2ljIGlt cGxlbWVudGF0aW9uIHRoYXQgY2xvc2VseSBmb2xsb3dzIHRoZQogICBwc2V1ZG9jb2RlIGlu IHRoaXMgZG9jdW1lbnQgYW5kIGFuIG9wdGltaXplZCBpbXBsZW1lbnRhdGlvbiB3aGljaAog ICB1c2VzIHRoZSBCRFMgYWxnb3JpdGhtIFtCRFMwOF0gdG8gY29tcHV0ZSBhdXRoZW50aWNh dGlvbiBwYXRocyBhbmQKICAgZGlzdHJpYnV0ZWQgc2lnbmF0dXJlIGdlbmVyYXRpb24gYXMg ZGVzY3JpYmVkIGluIFtIUkIxM10gZm9yIFhNU1NeTVQuCgogICBUaGUgY29kZSBpcyBwZXJt YW5lbnRseSBhdmFpbGFibGUgYXQKICAgaHR0cHM6Ly9naXRodWIuY29tL2pvb3N0cmlqbmV2 ZWxkL3htc3MtcmVmZXJlbmNlCgo4LiAgSUFOQSBDb25zaWRlcmF0aW9ucwoKICAgVGhlIElu dGVybmV0IEFzc2lnbmVkIE51bWJlcnMgQXV0aG9yaXR5IChJQU5BKSBpcyByZXF1ZXN0ZWQg dG8gY3JlYXRlCiAgIHRocmVlIHJlZ2lzdHJpZXM6IG9uZSBmb3IgV09UUysgc2lnbmF0dXJl cyBhcyBkZWZpbmVkIGluIFNlY3Rpb24gMywKICAgb25lIGZvciBYTVNTIHNpZ25hdHVyZXMg YW5kIG9uZSBmb3IgWE1TU15NVCBzaWduYXR1cmVzOyB0aGUgbGF0dGVyCiAgIHR3byBiZWlu ZyBkZWZpbmVkIGluIFNlY3Rpb24gNC4gIEZvciB0aGUgc2FrZSBvZiBjbGFyaXR5IGFuZAog ICBjb252ZW5pZW5jZSwgdGhlIGZpcnN0IHNldHMgb2YgV09UUyssIFhNU1MsIGFuZCBYTVNT Xk1UIHBhcmFtZXRlcgogICBzZXRzIGFyZSBkZWZpbmVkIGluIFNlY3Rpb24gNS4gIEFkZGl0 aW9ucyB0byB0aGVzZSByZWdpc3RyaWVzIHJlcXVpcmUKICAgdGhhdCBhIHNwZWNpZmljYXRp b24gYmUgZG9jdW1lbnRlZCBpbiBhbiBSRkMgb3IgYW5vdGhlciBwZXJtYW5lbnQgYW5kCiAg IHJlYWRpbHkgYXZhaWxhYmxlIHJlZmVyZW5jZSBpbiBzdWZmaWNpZW50IGRldGFpbCB0byBt YWtlCiAgIGludGVyb3BlcmFiaWxpdHkgYmV0d2VlbiBpbmRlcGVuZGVudCBpbXBsZW1lbnRh dGlvbnMgcG9zc2libGUuICBFYWNoCiAgIGVudHJ5IGluIHRoZSByZWdpc3RyeSBjb250YWlu cyB0aGUgZm9sbG93aW5nIGVsZW1lbnRzOgoKICAgICAgYSBzaG9ydCBuYW1lLCBzdWNoIGFz ICJYTVNTX1NIQTJfMjBfMjU2IiwKCiAgICAgIGEgcG9zaXRpdmUgbnVtYmVyLCBhbmQKCiAg ICAgIGEgcmVmZXJlbmNlIHRvIGEgc3BlY2lmaWNhdGlvbiB0aGF0IGNvbXBsZXRlbHkgZGVm aW5lcyB0aGUKICAgICAgc2lnbmF0dXJlIG1ldGhvZCB0ZXN0IGNhc2VzIHRoYXQgY2FuIGJl IHVzZWQgdG8gdmVyaWZ5IHRoZQogICAgICBjb3JyZWN0bmVzcyBvZiBhbiBpbXBsZW1lbnRh dGlvbi4KCiAgIFJlcXVlc3RzIHRvIGFkZCBhbiBlbnRyeSB0byB0aGUgcmVnaXN0cnkgTVVT VCBpbmNsdWRlIHRoZSBuYW1lIGFuZAogICB0aGUgcmVmZXJlbmNlLiAgVGhlIG51bWJlciBp cyBhc3NpZ25lZCBieSBJQU5BLiAgVGhlc2UgbnVtYmVyCiAgIGFzc2lnbm1lbnRzIFNIT1VM RCB1c2UgdGhlIHNtYWxsZXN0IGF2YWlsYWJsZSBwYWxpbmRyb21pYyBudW1iZXIuCiAgIFN1 Ym1pdHRlcnMgU0hPVUxEIGhhdmUgdGhlaXIgcmVxdWVzdHMgcmV2aWV3ZWQgYnkgdGhlIElS VEYgQ3J5cHRvCiAgIEZvcnVtIFJlc2VhcmNoIEdyb3VwIChDRlJHKSBhdCBjZnJnQGlldGYu b3JnLiAgSW50ZXJlc3RlZCBhcHBsaWNhbnRzCiAgIHRoYXQgYXJlIHVuZmFtaWxpYXIgd2l0 aCBJQU5BIHByb2Nlc3NlcyBzaG91bGQgdmlzaXQKICAgaHR0cDovL3d3dy5pYW5hLm9yZy4K CgoKCkh1ZWxzaW5nLCBldCBhbC4gICAgICAgIEV4cGlyZXMgSmFudWFyeSAyNSwgMjAxOCAg ICAgICAgICAgICAgIFtQYWdlIDQ5XQoMCkludGVybmV0LURyYWZ0ICAgIFhNU1M6IEV4dGVu ZGVkIEhhc2gtQmFzZWQgU2lnbmF0dXJlcyAgICAgICAgIEp1bHkgMjAxNwoKCiAgIFRoZSBu dW1iZXJzIGJldHdlZW4gMHhERERERERERCAoZGVjaW1hbCAzLDcyMiwzMDQsOTg5KSBhbmQg MHhGRkZGRkZGRgogICAoZGVjaW1hbCA0LDI5NCw5NjcsMjk1KSBpbmNsdXNpdmUsIHdpbGwg bm90IGJlIGFzc2lnbmVkIGJ5IElBTkEsIGFuZAogICBhcmUgcmVzZXJ2ZWQgZm9yIHByaXZh dGUgdXNlOyBubyBhdHRlbXB0IHdpbGwgYmUgbWFkZSB0byBwcmV2ZW50CiAgIG11bHRpcGxl IHNpdGVzIGZyb20gdXNpbmcgdGhlIHNhbWUgdmFsdWUgaW4gZGlmZmVyZW50IChhbmQKICAg aW5jb21wYXRpYmxlKSB3YXlzIFtSRkM4MTI2XS4KCiAgIFRoZSBXT1RTKyByZWdpc3RyeSBp cyBhcyBmb2xsb3dzLgoKICAgICAgICAgICstLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0t LS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tKwogICAgICAgICAgfCBOYW1lICAgICAgICAgICAg fCAgUmVmZXJlbmNlICB8IE51bWVyaWMgSWRlbnRpZmllciB8CiAgICAgICAgICArLS0tLS0t LS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLSsKICAgICAg ICAgIHwgV09UU1AtU0hBMl8yNTYgIHwgU2VjdGlvbiA1LjIgfCAgICAgMHgwMTAwMDAwMSAg ICAgfAogICAgICAgICAgfCAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICB8ICAgICAg ICAgICAgICAgICAgICB8CiAgICAgICAgICB8IFdPVFNQLVNIQTJfNTEyICB8IFNlY3Rpb24g NS4yIHwgICAgIDB4MDIwMDAwMDIgICAgIHwKICAgICAgICAgIHwgICAgICAgICAgICAgICAg IHwgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgfAogICAgICAgICAgfCBXT1RT UC1TSEFLRV8yNTYgfCBTZWN0aW9uIDUuMiB8ICAgICAweDAzMDAwMDAzICAgICB8CiAgICAg ICAgICB8ICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAg ICAgIHwKICAgICAgICAgIHwgV09UU1AtU0hBS0VfNTEyIHwgU2VjdGlvbiA1LjIgfCAgICAg MHgwNDAwMDAwNCAgICAgfAogICAgICAgICAgKy0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0t LS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0rCgogICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgVGFibGUgNgoKICAgVGhlIFhNU1MgcmVnaXN0cnkgaXMgYXMgZm9sbG93cy4K CgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCkh1ZWxzaW5nLCBldCBhbC4gICAgICAgIEV4 cGlyZXMgSmFudWFyeSAyNSwgMjAxOCAgICAgICAgICAgICAgIFtQYWdlIDUwXQoMCkludGVy bmV0LURyYWZ0ICAgIFhNU1M6IEV4dGVuZGVkIEhhc2gtQmFzZWQgU2lnbmF0dXJlcyAgICAg ICAgIEp1bHkgMjAxNwoKCiAgICAgICAgICstLS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0t LS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0rCiAgICAgICAgIHwgTmFtZSAgICAgICAgICAg ICAgfCAgUmVmZXJlbmNlICB8IE51bWVyaWMgSWRlbnRpZmllciB8CiAgICAgICAgICstLS0t LS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0rCiAg ICAgICAgIHwgWE1TUy1TSEEyXzEwXzI1NiAgfCBTZWN0aW9uIDUuMyB8ICAgICAweDAxMDAw MDAxICAgICB8CiAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICB8 ICAgICAgICAgICAgICAgICAgICB8CiAgICAgICAgIHwgWE1TUy1TSEEyXzE2XzI1NiAgfCBT ZWN0aW9uIDUuMyB8ICAgICAweDAyMDAwMDAyICAgICB8CiAgICAgICAgIHwgICAgICAgICAg ICAgICAgICAgfCAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICB8CiAgICAgICAg IHwgWE1TUy1TSEEyXzIwXzI1NiAgfCBTZWN0aW9uIDUuMyB8ICAgICAweDAzMDAwMDAzICAg ICB8CiAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICB8ICAgICAg ICAgICAgICAgICAgICB8CiAgICAgICAgIHwgWE1TUy1TSEEyXzEwXzUxMiAgfCBTZWN0aW9u IDUuMyB8ICAgICAweDA0MDAwMDA0ICAgICB8CiAgICAgICAgIHwgICAgICAgICAgICAgICAg ICAgfCAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICB8CiAgICAgICAgIHwgWE1T Uy1TSEEyXzE2XzUxMiAgfCBTZWN0aW9uIDUuMyB8ICAgICAweDA1MDAwMDA1ICAgICB8CiAg ICAgICAgIHwgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICB8ICAgICAgICAgICAg ICAgICAgICB8CiAgICAgICAgIHwgWE1TUy1TSEEyXzIwXzUxMiAgfCBTZWN0aW9uIDUuMyB8 ICAgICAweDA2MDAwMDA2ICAgICB8CiAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgfCAg ICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICB8CiAgICAgICAgIHwgWE1TUy1TSEFL RV8xMF8yNTYgfCBTZWN0aW9uIDUuMyB8ICAgICAweDA3MDAwMDA3ICAgICB8CiAgICAgICAg IHwgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAg ICB8CiAgICAgICAgIHwgWE1TUy1TSEFLRV8xNl8yNTYgfCBTZWN0aW9uIDUuMyB8ICAgICAw eDA4MDAwMDA4ICAgICB8CiAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgfCAgICAgICAg ICAgICB8ICAgICAgICAgICAgICAgICAgICB8CiAgICAgICAgIHwgWE1TUy1TSEFLRV8yMF8y NTYgfCBTZWN0aW9uIDUuMyB8ICAgICAweDA5MDAwMDA5ICAgICB8CiAgICAgICAgIHwgICAg ICAgICAgICAgICAgICAgfCAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICB8CiAg ICAgICAgIHwgWE1TUy1TSEFLRV8xMF81MTIgfCBTZWN0aW9uIDUuMyB8ICAgICAweDBhMDAw MDBhICAgICB8CiAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICB8 ICAgICAgICAgICAgICAgICAgICB8CiAgICAgICAgIHwgWE1TUy1TSEFLRV8xNl81MTIgfCBT ZWN0aW9uIDUuMyB8ICAgICAweDBiMDAwMDBiICAgICB8CiAgICAgICAgIHwgICAgICAgICAg ICAgICAgICAgfCAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICB8CiAgICAgICAg IHwgWE1TUy1TSEFLRV8yMF81MTIgfCBTZWN0aW9uIDUuMyB8ICAgICAweDBjMDAwMDBjICAg ICB8CiAgICAgICAgICstLS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0rLS0tLS0t LS0tLS0tLS0tLS0tLS0rCgogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgVGFi bGUgNwoKICAgVGhlIFhNU1NeTVQgcmVnaXN0cnkgaXMgYXMgZm9sbG93cy4KCiAgICAgICAr LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0t LS0tLS0rCiAgICAgICB8IE5hbWUgICAgICAgICAgICAgICAgICAgfCAgUmVmZXJlbmNlICB8 IE51bWVyaWMgSWRlbnRpZmllciB8CiAgICAgICArLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t Ky0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0rCiAgICAgICB8IFhNU1NNVC1T SEEyXzIwLzJfMjU2ICAgfCBTZWN0aW9uIDUuNCB8ICAgICAweDAxMDAwMDAxICAgICB8CiAg ICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICB8ICAgICAgICAg ICAgICAgICAgICB8CiAgICAgICB8IFhNU1NNVC1TSEEyXzIwLzRfMjU2ICAgfCBTZWN0aW9u IDUuNCB8ICAgICAweDAyMDAwMDAyICAgICB8CiAgICAgICB8ICAgICAgICAgICAgICAgICAg ICAgICAgfCAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICB8CiAgICAgICB8IFhN U1NNVC1TSEEyXzQwLzJfMjU2ICAgfCBTZWN0aW9uIDUuNCB8ICAgICAweDAzMDAwMDAzICAg ICB8CiAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICB8ICAg ICAgICAgICAgICAgICAgICB8CiAgICAgICB8IFhNU1NNVC1TSEEyXzQwLzRfMjU2ICAgfCBT ZWN0aW9uIDUuNCB8ICAgICAweDA0MDAwMDA0ICAgICB8CiAgICAgICB8ICAgICAgICAgICAg ICAgICAgICAgICAgfCAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICB8CiAgICAg ICB8IFhNU1NNVC1TSEEyXzQwLzhfMjU2ICAgfCBTZWN0aW9uIDUuNCB8ICAgICAweDA1MDAw MDA1ICAgICB8CiAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAg ICB8ICAgICAgICAgICAgICAgICAgICB8CiAgICAgICB8IFhNU1NNVC1TSEEyXzYwLzNfMjU2 ICAgfCBTZWN0aW9uIDUuNCB8ICAgICAweDA2MDAwMDA2ICAgICB8CiAgICAgICB8ICAgICAg ICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICB8 CiAgICAgICB8IFhNU1NNVC1TSEEyXzYwLzZfMjU2ICAgfCBTZWN0aW9uIDUuNCB8ICAgICAw eDA3MDAwMDA3ICAgICB8CgoKCkh1ZWxzaW5nLCBldCBhbC4gICAgICAgIEV4cGlyZXMgSmFu dWFyeSAyNSwgMjAxOCAgICAgICAgICAgICAgIFtQYWdlIDUxXQoMCkludGVybmV0LURyYWZ0 ICAgIFhNU1M6IEV4dGVuZGVkIEhhc2gtQmFzZWQgU2lnbmF0dXJlcyAgICAgICAgIEp1bHkg MjAxNwoKCiAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICB8 ICAgICAgICAgICAgICAgICAgICB8CiAgICAgICB8IFhNU1NNVC1TSEEyXzYwLzEyXzI1NiAg fCBTZWN0aW9uIDUuNCB8ICAgICAweDA4MDAwMDA4ICAgICB8CiAgICAgICB8ICAgICAgICAg ICAgICAgICAgICAgICAgfCAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICB8CiAg ICAgICB8IFhNU1NNVC1TSEEyXzIwLzJfNTEyICAgfCBTZWN0aW9uIDUuNCB8ICAgICAweDA5 MDAwMDA5ICAgICB8CiAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAg ICAgICB8ICAgICAgICAgICAgICAgICAgICB8CiAgICAgICB8IFhNU1NNVC1TSEEyXzIwLzRf NTEyICAgfCBTZWN0aW9uIDUuNCB8ICAgICAweDBhMDAwMDBhICAgICB8CiAgICAgICB8ICAg ICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAg ICB8CiAgICAgICB8IFhNU1NNVC1TSEEyXzQwLzJfNTEyICAgfCBTZWN0aW9uIDUuNCB8ICAg ICAweDBiMDAwMDBiICAgICB8CiAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgfCAg ICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICB8CiAgICAgICB8IFhNU1NNVC1TSEEy XzQwLzRfNTEyICAgfCBTZWN0aW9uIDUuNCB8ICAgICAweDBjMDAwMDBjICAgICB8CiAgICAg ICB8ICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICB8ICAgICAgICAgICAg ICAgICAgICB8CiAgICAgICB8IFhNU1NNVC1TSEEyXzQwLzhfNTEyICAgfCBTZWN0aW9uIDUu NCB8ICAgICAweDBkMDAwMDBkICAgICB8CiAgICAgICB8ICAgICAgICAgICAgICAgICAgICAg ICAgfCAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICB8CiAgICAgICB8IFhNU1NN VC1TSEEyXzYwLzNfNTEyICAgfCBTZWN0aW9uIDUuNCB8ICAgICAweDBlMDAwMDBlICAgICB8 CiAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICB8ICAgICAg ICAgICAgICAgICAgICB8CiAgICAgICB8IFhNU1NNVC1TSEEyXzYwLzZfNTEyICAgfCBTZWN0 aW9uIDUuNCB8ICAgICAweDBmMDAwMDBmICAgICB8CiAgICAgICB8ICAgICAgICAgICAgICAg ICAgICAgICAgfCAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICB8CiAgICAgICB8 IFhNU1NNVC1TSEEyXzYwLzEyXzUxMiAgfCBTZWN0aW9uIDUuNCB8ICAgICAweDAxMDEwMTAx ICAgICB8CiAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICB8 ICAgICAgICAgICAgICAgICAgICB8CiAgICAgICB8IFhNU1NNVC1TSEFLRV8yMC8yXzI1NiAg fCBTZWN0aW9uIDUuNCB8ICAgICAweDAyMDEwMTAyICAgICB8CiAgICAgICB8ICAgICAgICAg ICAgICAgICAgICAgICAgfCAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICB8CiAg ICAgICB8IFhNU1NNVC1TSEFLRV8yMC80XzI1NiAgfCBTZWN0aW9uIDUuNCB8ICAgICAweDAz MDEwMTAzICAgICB8CiAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAg ICAgICB8ICAgICAgICAgICAgICAgICAgICB8CiAgICAgICB8IFhNU1NNVC1TSEFLRV80MC8y XzI1NiAgfCBTZWN0aW9uIDUuNCB8ICAgICAweDA0MDEwMTA0ICAgICB8CiAgICAgICB8ICAg ICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAg ICB8CiAgICAgICB8IFhNU1NNVC1TSEFLRV80MC80XzI1NiAgfCBTZWN0aW9uIDUuNCB8ICAg ICAweDA1MDEwMTA1ICAgICB8CiAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgfCAg ICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICB8CiAgICAgICB8IFhNU1NNVC1TSEFL RV80MC84XzI1NiAgfCBTZWN0aW9uIDUuNCB8ICAgICAweDA2MDEwMTA2ICAgICB8CiAgICAg ICB8ICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICB8ICAgICAgICAgICAg ICAgICAgICB8CiAgICAgICB8IFhNU1NNVC1TSEFLRV82MC8zXzI1NiAgfCBTZWN0aW9uIDUu NCB8ICAgICAweDA3MDEwMTA3ICAgICB8CiAgICAgICB8ICAgICAgICAgICAgICAgICAgICAg ICAgfCAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICB8CiAgICAgICB8IFhNU1NN VC1TSEFLRV82MC82XzI1NiAgfCBTZWN0aW9uIDUuNCB8ICAgICAweDA4MDEwMTA4ICAgICB8 CiAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICB8ICAgICAg ICAgICAgICAgICAgICB8CiAgICAgICB8IFhNU1NNVC1TSEFLRV82MC8xMl8yNTYgfCBTZWN0 aW9uIDUuNCB8ICAgICAweDA5MDEwMTA5ICAgICB8CiAgICAgICB8ICAgICAgICAgICAgICAg ICAgICAgICAgfCAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICB8CiAgICAgICB8 IFhNU1NNVC1TSEFLRV8yMC8yXzUxMiAgfCBTZWN0aW9uIDUuNCB8ICAgICAweDBhMDEwMTBh ICAgICB8CiAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICB8 ICAgICAgICAgICAgICAgICAgICB8CiAgICAgICB8IFhNU1NNVC1TSEFLRV8yMC80XzUxMiAg fCBTZWN0aW9uIDUuNCB8ICAgICAweDBiMDEwMTBiICAgICB8CiAgICAgICB8ICAgICAgICAg ICAgICAgICAgICAgICAgfCAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICB8CiAg ICAgICB8IFhNU1NNVC1TSEFLRV80MC8yXzUxMiAgfCBTZWN0aW9uIDUuNCB8ICAgICAweDBj MDEwMTBjICAgICB8CiAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAg ICAgICB8ICAgICAgICAgICAgICAgICAgICB8CiAgICAgICB8IFhNU1NNVC1TSEFLRV80MC80 XzUxMiAgfCBTZWN0aW9uIDUuNCB8ICAgICAweDBkMDEwMTBkICAgICB8CiAgICAgICB8ICAg ICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAg ICB8CiAgICAgICB8IFhNU1NNVC1TSEFLRV80MC84XzUxMiAgfCBTZWN0aW9uIDUuNCB8ICAg ICAweDBlMDEwMTBlICAgICB8CiAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgfCAg ICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICB8CiAgICAgICB8IFhNU1NNVC1TSEFL RV82MC8zXzUxMiAgfCBTZWN0aW9uIDUuNCB8ICAgICAweDBmMDEwMTBmICAgICB8CiAgICAg ICB8ICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICB8ICAgICAgICAgICAg ICAgICAgICB8CiAgICAgICB8IFhNU1NNVC1TSEFLRV82MC82XzUxMiAgfCBTZWN0aW9uIDUu NCB8ICAgICAweDAxMDIwMjAxICAgICB8CgoKCkh1ZWxzaW5nLCBldCBhbC4gICAgICAgIEV4 cGlyZXMgSmFudWFyeSAyNSwgMjAxOCAgICAgICAgICAgICAgIFtQYWdlIDUyXQoMCkludGVy bmV0LURyYWZ0ICAgIFhNU1M6IEV4dGVuZGVkIEhhc2gtQmFzZWQgU2lnbmF0dXJlcyAgICAg ICAgIEp1bHkgMjAxNwoKCiAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAg ICAgICAgICB8ICAgICAgICAgICAgICAgICAgICB8CiAgICAgICB8IFhNU1NNVC1TSEFLRV82 MC8xMl81MTIgfCBTZWN0aW9uIDUuNCB8ICAgICAweDAyMDIwMjAyICAgICB8CiAgICAgICAr LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0t LS0tLS0rCgogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgVGFibGUgOAoKICAg QW4gSUFOQSByZWdpc3RyYXRpb24gb2YgYSBzaWduYXR1cmUgc3lzdGVtIGRvZXMgbm90IGNv bnN0aXR1dGUgYW4KICAgZW5kb3JzZW1lbnQgb2YgdGhhdCBzeXN0ZW0gb3IgaXRzIHNlY3Vy aXR5LgoKOS4gIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zCgogICBBIHNpZ25hdHVyZSBzeXN0 ZW0gaXMgY29uc2lkZXJlZCBzZWN1cmUgaWYgaXQgcHJldmVudHMgYW4gYXR0YWNrZXIKICAg ZnJvbSBmb3JnaW5nIGEgdmFsaWQgc2lnbmF0dXJlLiAgTW9yZSBzcGVjaWZpY2FsbHksIGNv bnNpZGVyIGEKICAgc2V0dGluZyBpbiB3aGljaCBhbiBhdHRhY2tlciBnZXRzIGEgcHVibGlj IGtleSBhbmQgY2FuIGxlYXJuCiAgIHNpZ25hdHVyZXMgb24gYXJiaXRyYXJ5IG1lc3NhZ2Vz IG9mIGhpcyBjaG9pY2UuICBBIHNpZ25hdHVyZSBzeXN0ZW0KICAgaXMgc2VjdXJlIGlmLCBl dmVuIGluIHRoaXMgc2V0dGluZywgdGhlIGF0dGFja2VyIGNhbiBub3QgcHJvZHVjZSBhCiAg IG5ldyBtZXNzYWdlLCBzaWduYXR1cmUgcGFpciBvZiBoaXMgY2hvb3Npbmcgc3VjaCB0aGF0 IHRoZQogICB2ZXJpZmljYXRpb24gYWxnb3JpdGhtIGFjY2VwdHMuCgogICBQcmV2ZW50aW5n IGFuIGF0dGFja2VyIGZyb20gbW91bnRpbmcgYW4gYXR0YWNrIG1lYW5zIHRoYXQgdGhlIGF0 dGFjawogICBpcyBjb21wdXRhdGlvbmFsbHkgdG9vIGV4cGVuc2l2ZSB0byBiZSBjYXJyaWVk IG91dC4gIFRoZXJlIGV4aXN0CiAgIHZhcmlvdXMgZXN0aW1hdGVzIGZvciB3aGVuIGEgY29t cHV0YXRpb24gaXMgdG9vIGV4cGVuc2l2ZSB0byBiZSBkb25lLgogICBGb3IgdGhhdCByZWFz b24sIHRoaXMgbm90ZSBvbmx5IGRlc2NyaWJlcyBob3cgZXhwZW5zaXZlIGl0IGlzIGZvciBh bgogICBhdHRhY2tlciB0byBnZW5lcmF0ZSBhIGZvcmdlcnkuICBQYXJhbWV0ZXJzIGFyZSBh Y2NvbXBhbmllZCBieSBhIGJpdAogICBzZWN1cml0eSB2YWx1ZS4gIFRoZSBtZWFuaW5nIG9m IGJpdCBzZWN1cml0eSBpcyBhcyBmb2xsb3dzLiAgQQogICBwYXJhbWV0ZXIgc2V0IGdyYW50 cyBiIGJpdHMgb2Ygc2VjdXJpdHkgaWYgdGhlIGJlc3QgYXR0YWNrIHRha2VzIGF0CiAgIGxl YXN0IDJeKGIgLSAxKSBiaXQgb3BlcmF0aW9ucyB0byBhY2hpZXZlIGEgc3VjY2VzcyBwcm9i YWJpbGl0eSBvZgogICAxLzIuICBIZW5jZSwgdG8gbW91bnQgYSBzdWNjZXNzZnVsIGF0dGFj aywgYW4gYXR0YWNrZXIgbmVlZHMgdG8KICAgcGVyZm9ybSAyXmIgYml0IG9wZXJhdGlvbnMg b24gYXZlcmFnZS4gIFRoZSBnaXZlbiB2YWx1ZXMgZm9yIGJpdAogICBzZWN1cml0eSB3ZXJl IGVzdGltYXRlZCBhY2NvcmRpbmcgdG8gW0hSUzE2XS4KCjkuMS4gIFNlY3VyaXR5IFByb29m cwoKICAgQSBmdWxsIHNlY3VyaXR5IHByb29mIGZvciBhbGwgc2NoZW1lcyBkZXNjcmliZWQg aW4gdGhpcyBkb2N1bWVudCBjYW4KICAgYmUgZm91bmQgaW4gW0hSUzE2XS4gIFRoaXMgcHJv b2Ygc2hvd3MgdGhhdCBhbiBhdHRhY2tlciBoYXMgdG8gYnJlYWsKICAgYXQgbGVhc3Qgb25l IG91dCBvZiBjZXJ0YWluIHNlY3VyaXR5IHByb3BlcnRpZXMgb2YgdGhlIHVzZWQgaGFzaAog ICBmdW5jdGlvbnMgYW5kIFBSRnMgdG8gZm9yZ2UgYSBzaWduYXR1cmUgaW4gYW55IG9mIHRo ZSBkZXNjcmliZWQKICAgc2NoZW1lcy4gIFRoZSBwcm9vZiBpbiBbSFJTMTZdIGNvbnNpZGVy cyBhIGRpZmZlcmVudCBpbml0aWFsIG1lc3NhZ2UKICAgY29tcHJlc3Npb24gdGhhbiB0aGUg cmFuZG9taXplZCBoYXNoaW5nIHVzZWQgaGVyZS4gIFdlIGNvbW1lbnQgb24KICAgdGhpcyBi ZWxvdy4gIEZvciB0aGUgb3JpZ2luYWwgc2NoZW1lcywgdGhlc2UgcHJvb2ZzIHNob3cgdGhh dCBhbgogICBhdHRhY2tlciBoYXMgdG8gYnJlYWsgY2VydGFpbiBtaW5pbWFsIHNlY3VyaXR5 IHByb3BlcnRpZXMuICBJbgogICBwYXJ0aWN1bGFyLCBpdCBpcyBub3Qgc3VmZmljaWVudCB0 byBicmVhayB0aGUgY29sbGlzaW9uIHJlc2lzdGFuY2Ugb2YKICAgdGhlIGhhc2ggZnVuY3Rp b25zIHRvIGdlbmVyYXRlIGEgZm9yZ2VyeS4KCiAgIE1vcmUgc3BlY2lmaWNhbGx5LCB0aGUg cmVxdWlyZW1lbnRzIG9uIHRoZSB1c2VkIGZ1bmN0aW9ucyBhcmUgdGhhdCBGCiAgIGFuZCBI IGFyZSBwb3N0LXF1YW50dW0gbXVsdGktZnVuY3Rpb24gbXVsdGktdGFyZ2V0IHNlY29uZC1w cmVpbWFnZQogICByZXNpc3RhbnQga2V5ZWQgZnVuY3Rpb25zLCBGIGZ1bGZpbGxzIGFuIGFk ZGl0aW9uYWwgc3RhdGlzdGljYWwKICAgcmVxdWlyZW1lbnQgdGhhdCByb3VnaGx5IHNheXMg dGhhdCBtb3N0IGltYWdlcyBoYXZlIGF0IGxlYXN0IHR3bwoKCgpIdWVsc2luZywgZXQgYWwu ICAgICAgICBFeHBpcmVzIEphbnVhcnkgMjUsIDIwMTggICAgICAgICAgICAgICBbUGFnZSA1 M10KDApJbnRlcm5ldC1EcmFmdCAgICBYTVNTOiBFeHRlbmRlZCBIYXNoLUJhc2VkIFNpZ25h dHVyZXMgICAgICAgICBKdWx5IDIwMTcKCgogICBwcmVpbWFnZXMsIFBSRiBpcyBhIHBvc3Qt cXVhbnR1bSBwc2V1ZG9yYW5kb20gZnVuY3Rpb24sIEhfbXNnIGlzIGEKICAgcG9zdC1xdWFu dHVtIG11bHRpLXRhcmdldCBleHRlbmRlZCB0YXJnZXQgY29sbGlzaW9uIHJlc2lzdGFudCBr ZXllZAogICBoYXNoIGZ1bmN0aW9uLiAgRm9yIGRldGFpbGVkIGRlZmluaXRpb25zIG9mIHRo ZXNlIHByb3BlcnRpZXMgc2VlCiAgIFtIUlMxNl0uICBUbyBnaXZlIHNvbWUgaW50dWl0aW9u OiBNdWx0aS1mdW5jdGlvbiBtdWx0aS10YXJnZXQgc2Vjb25kCiAgIHByZWltYWdlIHJlc2lz dGFuY2UgaXMgYW4gZXh0ZW5zaW9uIG9mIHNlY29uZCBwcmVpbWFnZSByZXNpc3RhbmNlIHRv CiAgIGtleWVkIGhhc2ggZnVuY3Rpb25zLCBjb3ZlcmluZyB0aGUgY2FzZSB3aGVyZSBhbiBh ZHZlcnNhcnkgc3VjY2VlZHMKICAgaWYgaXQgZmluZHMgYSBzZWNvbmQgcHJlaW1hZ2UgZm9y IG9uZSBvdXQgb2YgbWFueSB2YWx1ZXMuICBUaGUgc2FtZQogICBob2xkcyBmb3IgbXVsdGkt dGFyZ2V0IGV4dGVuZGVkIHRhcmdldCBjb2xsaXNpb24gcmVzaXN0YW5jZSB3aGljaAogICBq dXN0IGxhY2tzIHRoZSBtdWx0aS1mdW5jdGlvbiBpZGVudGlmaWVyIGFzIHRhcmdldCBjb2xs aXNpb24KICAgcmVzaXN0YW5jZSBhbHJlYWR5IGNvbnNpZGVycyBrZXllZCBoYXNoIGZ1bmN0 aW9ucy4gIFRoZSBwcm9vZiBpbgogICBbSFJTMTZdIHNwbGl0cyBQUkYgaW50byB0d28gZnVu Y3Rpb25zLiAgV2hlbiBQUkYgaXMgdXNlZCBmb3IKICAgcHNldWRvcmFuZG9tIGtleSBnZW5l cmF0aW9uIG9yIGdlbmVyYXRpb24gb2YgcmFuZG9tbmVzcyBmb3IKICAgcmFuZG9taXplZCBt ZXNzYWdlIGhhc2hpbmcgaXQgaXMgc3RpbGwgY29uc2lkZXJlZCBhIHBzZXVkb3JhbmRvbQog ICBmdW5jdGlvbi4gIFdoZW5ldmVyIFBSRiBpcyB1c2VkIHRvIGdlbmVyYXRlIGJpdG1hc2tz IGFuZCBoYXNoCiAgIGZ1bmN0aW9uIGtleXMgaXQgaXMgbW9kZWxlZCBhcyBhIHJhbmRvbSBv cmFjbGUuICBUaGlzIGlzIGR1ZSB0bwogICB0ZWNobmljYWwgcmVhc29ucyBpbiB0aGUgcHJv b2YgYW5kIGFuIGltcGxlbWVudGF0aW9uIHVzaW5nIGEKICAgcHNldWRvcmFuZG9tIGZ1bmN0 aW9uIGlzIHNlY3VyZS4KCiAgIFRoZSBwcm9vZiBpbiBbSFJTMTZdIGNvbnNpZGVycyBjbGFz c2ljYWwgcmFuZG9taXplZCBoYXNoaW5nIGZvciB0aGUKICAgaW5pdGlhbCBtZXNzYWdlIGNv bXByZXNzaW9uLCBpLmUuLCBIKHIsIE0pIGluc3RlYWQgb2YgSChyIHx8CiAgIGdldFJvb3Qo UEspIHx8IGluZGV4LCBNKS4gIFRoaXMgY2xhc3NpY2FsIHJhbmRvbWl6ZWQgaGFzaGluZyBh bGxvd3MKICAgdG8gZ2V0IGEgc2VjdXJpdHkgcmVkdWN0aW9uIGZyb20gZXh0ZW5kZWQgdGFy Z2V0IGNvbGxpc2lvbiByZXNpc3RhbmNlCiAgIFtIUlMxNl0sIGEgcHJvcGVydHkgdGhhdCBp cyBjb25qZWN0dXJlZCB0byBiZSBzdHJpY3RseSB3ZWFrZXIgdGhhbgogICBjb2xsaXNpb24g cmVzaXN0YW5jZS4gIEhvd2V2ZXIsIGl0IHR1cm5zIG91dCB0aGF0IGluIHRoaXMgY2FzZSwg YW4KICAgYXR0YWNrZXIgY291bGQgc3RpbGwgbGF1bmNoIGEgbXVsdGktdGFyZ2V0IGF0dGFj ayBldmVuIGFnYWluc3QKICAgbXVsdGlwbGUgdXNlcnMgYXQgdGhlIHNhbWUgdGltZS4gIFRo ZSByZWFzb24gaXMgdGhhdCB0aGUgYWR2ZXJzYXJ5CiAgIGF0dGFja2luZyB1IHVzZXJzIGF0 IHRoZSBzYW1lIHRpbWUgbGVhcm5zIHUgKiAyXmggcmFuZG9taXplZCBoYXNoZXMKICAgSChy X2lfaiB8fCBNX2lfaikgd2l0aCBzaWduYXR1cmUgaW5kZXggaSBpbiBbMCwgMl5oIC0gMV0g YW5kIHVzZXIKICAgaW5kZXggaiBpbiBbMCwgdV0uICBJdCBzdWZmaWNlcyB0byBmaW5kIGEg c2luZ2xlIHBhaXIgKHIqLCBNKikgc3VjaAogICB0aGF0IEgociogfHwgTSopID0gSChyX2lf dSB8fCBNX2lfdSkgZm9yIG9uZSBvdXQgb2YgdGhlIHUgKiAyXmgKICAgbGVhcm5lZCBoYXNo ZXMuICBIZW5jZSwgYW4gYXR0YWNrZXIgY2FuIGRvIGEgYnJ1dGUgZm9yY2Ugc2VhcmNoIGlu CiAgIHRpbWUgMl5uIC8gdSAqIDJeaCBpbnN0ZWFkIG9mIDJebi4KCiAgIFRoZSBpbmRleGVk IHJhbmRvbWl6ZWQgaGFzaGluZyBIKHIgfHwgZ2V0Um9vdChQSykgfHwgdG9CeXRlKGlkeCwg biksCiAgIE0pIHVzZWQgaW4gdGhpcyB3b3JrIG1ha2VzIHRoZSBoYXNoIGZ1bmN0aW9uIGNh bGxzIHBvc2l0aW9uLSBhbmQKICAgdXNlci1kZXBlbmRlbnQuICBUaGlzIHRod2FydHMgdGhl IGFib3ZlIGF0dGFjayBiZWNhdXNlIGVhY2ggaGFzaAogICBmdW5jdGlvbiBldmFsdWF0aW9u IGR1cmluZyBhbiBhdHRhY2sgY2FuIG9ubHkgdGFyZ2V0IG9uZSBvZiB0aGUKICAgbGVhcm5l ZCByYW5kb21pemVkIGhhc2ggdmFsdWVzLiAgTW9yZSBzcGVjaWZpY2FsbHksIGFuIGF0dGFj a2VyIG5vdwogICBoYXMgdG8gZGVjaWRlIHdoaWNoIGluZGV4IGlkeCBhbmQgd2hpY2ggcm9v dCB2YWx1ZSB0byB1c2UgZm9yIGVhY2gKICAgcXVlcnkuICBJZiBvbmUgYXNzdW1lcyB0aGF0 IHRoZSB1c2VkIGhhc2ggZnVuY3Rpb24gaXMgYSByYW5kb20KICAgZnVuY3Rpb24gaXQgY2Fu IGJlIHNob3duIHRoYXQgYSBtdWx0aS11c2VyIGV4aXN0ZW50aWFsIGZvcmdlcnkgYXR0YWNr CiAgIHRoYXQgdGFyZ2V0cyB0aGlzIG1lc3NhZ2UgY29tcHJlc3Npb24gaGFzIGEgY29tcGxl eGl0eSBvZiAyXm4gaGFzaAogICBmdW5jdGlvbiBjYWxscy4KCiAgIFRoZSBnaXZlbiBiaXQg c2VjdXJpdHkgdmFsdWVzIHdlcmUgZXN0aW1hdGVkIGJhc2VkIG9uIHRoZSBjb21wbGV4aXR5 CiAgIG9mIHRoZSBiZXN0IGtub3duIGdlbmVyaWMgYXR0YWNrcyBhZ2FpbnN0IHRoZSByZXF1 aXJlZCBzZWN1cml0eQogICBwcm9wZXJ0aWVzIG9mIHRoZSB1c2VkIGhhc2ggYW5kIHBzZXVk b3JhbmRvbSBmdW5jdGlvbnMgYXNzdW1pbmcKICAgY29udmVudGlvbmFsIGFuZCBxdWFudHVt IGFkdmVyc2FyaWVzLiAgQXQgdGhlIHRpbWUgb2Ygd3JpdGluZywKCgoKSHVlbHNpbmcsIGV0 IGFsLiAgICAgICAgRXhwaXJlcyBKYW51YXJ5IDI1LCAyMDE4ICAgICAgICAgICAgICAgW1Bh Z2UgNTRdCgwKSW50ZXJuZXQtRHJhZnQgICAgWE1TUzogRXh0ZW5kZWQgSGFzaC1CYXNlZCBT aWduYXR1cmVzICAgICAgICAgSnVseSAyMDE3CgoKICAgZ2VuZXJpYyBhdHRhY2tzIGFyZSB0 aGUgYmVzdCBrbm93biBhdHRhY2tzIGZvciB0aGUgcGFyYW1ldGVycwogICBzdWdnZXN0ZWQg aW4gdGhlIGNsYXNzaWNhbCBzZXR0aW5nLiAgQWxzbyBpbiB0aGUgcXVhbnR1bSBzZXR0aW5n CiAgIHRoZXJlIGFyZSBubyBkZWRpY2F0ZWQgYXR0YWNrcyBrbm93biB0aGF0IHBlcmZvcm0g YmV0dGVyIHRoYW4gZ2VuZXJpYwogICBhdHRhY2tzLiAgTmV2ZXJ0aGVsZXNzLCB0aGUgdG9w aWMgb2YgcXVhbnR1bSBjcnlwdGFuYWx5c2lzIG9mIGhhc2gKICAgZnVuY3Rpb25zIGlzIG5v dCBhcyB3ZWxsIHVuZGVyc3Rvb2QgYXMgaW4gdGhlIGNsYXNzaWNhbCBzZXR0aW5nLgoKOS4y LiAgTWluaW1hbCBTZWN1cml0eSBBc3N1bXB0aW9ucwoKICAgVGhlIHNlY3VyaXR5IGFzc3Vt cHRpb25zIG1hZGUgdG8gYXJndWUgZm9yIHRoZSBzZWN1cml0eSBvZiB0aGUKICAgZGVzY3Jp YmVkIHNjaGVtZXMgYXJlIG1pbmltYWwuICBBbnkgc2lnbmF0dXJlIGFsZ29yaXRobSB0aGF0 IGFsbG93cwogICBhcmJpdHJhcnkgc2l6ZSBtZXNzYWdlcyByZWxpZXMgb24gdGhlIHNlY3Vy aXR5IG9mIGEgY3J5cHRvZ3JhcGhpYwogICBoYXNoIGZ1bmN0aW9uLCBlaXRoZXIgb24gY29s bGlzaW9uIHJlc2lzdGFuY2Ugb3Igb24gZXh0ZW5kZWQgdGFyZ2V0CiAgIGNvbGxpc2lvbiBy ZXNpc3RhbmNlIGlmIHJhbmRvbWl6ZWQgaGFzaGluZyBpcyB1c2VkIGZvciBtZXNzYWdlCiAg IGNvbXByZXNzaW9uLiAgRm9yIHRoZSBzY2hlbWVzIGRlc2NyaWJlZCBoZXJlIHRoaXMgaXMg YWxyZWFkeQogICBzdWZmaWNpZW50IHRvIGJlIHNlY3VyZS4gIEluIGNvbnRyYXN0LCBjb21t b24gc2lnbmF0dXJlIHNjaGVtZXMgbGlrZQogICBSU0EsIERTQSwgYW5kIEVDRFNBIGFkZGl0 aW9uYWxseSByZWx5IG9uIHRoZSBjb25qZWN0dXJlZCBoYXJkbmVzcyBvZgogICBjZXJ0YWlu IG1hdGhlbWF0aWNhbCBwcm9ibGVtcy4KCjkuMy4gIFBvc3QtUXVhbnR1bSBTZWN1cml0eQoK ICAgQSBwb3N0LXF1YW50dW0gY3J5cHRvc3lzdGVtIGlzIGEgc3lzdGVtIHRoYXQgaXMgc2Vj dXJlIGFnYWluc3QKICAgYXR0YWNrZXJzIHdpdGggYWNjZXNzIHRvIGEgcmVhc29uYWJseSBz aXplZCBxdWFudHVtIGNvbXB1dGVyLiAgQXQgdGhlCiAgIHRpbWUgb2Ygd3JpdGluZyB0aGlz IG5vdGUsIHdoZXRoZXIgb3Igbm90IGl0IGlzIGZlYXNpYmxlIHRvIGJ1aWxkCiAgIHN1Y2gg YSBtYWNoaW5lIGlzIGFuIG9wZW4gY29uamVjdHVyZS4gIEhvd2V2ZXIsIHNpZ25pZmljYW50 IHByb2dyZXNzCiAgIHdhcyBtYWRlIG92ZXIgdGhlIGxhc3QgZmV3IHllYXJzIGluIHRoaXMg cmVnYXJkLiAgSGVuY2UsIHdlIGNvbnNpZGVyCiAgIGl0IGEgbWF0dGVyIG9mIHJpc2sgYXNz ZXNzbWVudCB0byBwcmVwYXJlIGZvciB0aGlzIGNhc2UuCgogICBJbiBjb250cmFzdCB0byBS U0EsIERTQSwgYW5kIEVDRFNBLCB0aGUgZGVzY3JpYmVkIHNpZ25hdHVyZSBzeXN0ZW1zCiAg IGFyZSBwb3N0LXF1YW50dW0tc2VjdXJlIGlmIHRoZXkgYXJlIHVzZWQgd2l0aCBhbiBhcHBy b3ByaWF0ZQogICBjcnlwdG9ncmFwaGljIGhhc2ggZnVuY3Rpb24uICBJbiBwYXJ0aWN1bGFy LCBmb3IgcG9zdC1xdWFudHVtCiAgIHNlY3VyaXR5LCB0aGUgc2l6ZSBvZiBuIG11c3QgYmUg dHdpY2UgdGhlIHNpemUgcmVxdWlyZWQgZm9yIGNsYXNzaWNhbAogICBzZWN1cml0eS4gIFRo aXMgaXMgaW4gb3JkZXIgdG8gcHJvdGVjdCBhZ2FpbnN0IHF1YW50dW0gc3F1YXJlIHJvb3QK ICAgYXR0YWNrcyBkdWUgdG8gR3JvdmVyJ3MgYWxnb3JpdGhtLiAgSXQgaGFzIGJlZW4gc2hv d24gaW4gW0hSUzE2XSB0aGF0CiAgIHZhcmlhbnRzIG9mIEdyb3ZlcidzIGFsZ29yaXRobSBh cmUgdGhlIG9wdGltYWwgZ2VuZXJpYyBhdHRhY2tzCiAgIGFnYWluc3QgdGhlIHNlY3VyaXR5 IHByb3BlcnRpZXMgb2YgaGFzaCBmdW5jdGlvbnMgcmVxdWlyZWQgZm9yIHRoZQogICBkZXNj cmliZWQgc2NoZW1lLgoKICAgQXMgc3RhdGVkIGFib3ZlLCB3ZSBvbmx5IGNvbnNpZGVyIGdl bmVyaWMgYXR0YWNrcyBoZXJlLCBhcwogICBjcnlwdG9ncmFwaGljIGhhc2ggZnVuY3Rpb25z IHNob3VsZCBiZSBkZXByZWNhdGVkIGFzIHNvb24gYXMgdGhlcmUKICAgZXhpc3QgZGVkaWNh dGVkIGF0dGFja3MgdGhhdCBwZXJmb3JtIHNpZ25pZmljYW50bHkgYmV0dGVyLiAgVGhpcyBh bHNvCiAgIGFwcGxpZXMgZm9yIHRoZSBxdWFudHVtIHNldHRpbmcuICBBcyBzb29uIGFzIHRo ZXJlIGV4aXN0IGRlZGljYXRlZAogICBxdWFudHVtIGF0dGFja3MgYWdhaW5zdCB0aGUgdXNl ZCBoYXNoIGZ1bmN0aW9uIHRoYXQgcGVyZm9ybQogICBzaWduaWZpY2FudGx5IGJldHRlciB0 aGFuIHRoZSBkZXNjcmliZWQgZ2VuZXJpYyBhdHRhY2tzIHRoZXNlIGhhc2gKICAgZnVuY3Rp b25zIHNob3VsZCBub3QgYmUgdXNlZCBhbnltb3JlIGZvciB0aGUgZGVzY3JpYmVkIHNjaGVt ZXMgb3IgdGhlCiAgIGNvbXB1dGF0aW9uIG9mIHRoZSBzZWN1cml0eSBsZXZlbCBoYXMgdG8g YmUgcmVkb25lLgoKCgoKCgpIdWVsc2luZywgZXQgYWwuICAgICAgICBFeHBpcmVzIEphbnVh cnkgMjUsIDIwMTggICAgICAgICAgICAgICBbUGFnZSA1NV0KDApJbnRlcm5ldC1EcmFmdCAg ICBYTVNTOiBFeHRlbmRlZCBIYXNoLUJhc2VkIFNpZ25hdHVyZXMgICAgICAgICBKdWx5IDIw MTcKCgoxMC4gIEFja25vd2xlZGdlbWVudHMKCiAgIFdlIHdvdWxkIGxpa2UgdG8gdGhhbmsg Sm9oYW5uZXMgQnJhdW4sIFBldGVyIENhbXBiZWxsLCBTdGVwaGVuCiAgIEZhcnJlbGwsIFNj b3R0IEZsdWhyZXIsIEJ1cnQgS2FsaXNraSwgQWRhbSBMYW5nbGV5LCBNYXJjb3MgTWFuemFu bywKICAgRGF2aWQgTWNHcmV3LCBSYWZhZWwgTWlzb2N6a2ksIFNlYW4gUGFya2luc29uLCBT ZWJhc3RpYW4gUm9sYW5kLCBhbmQKICAgdGhlIEtlY2NhayB0ZWFtIGZvciB0aGVpciBoZWxw IGFuZCBjb21tZW50cy4KCjExLiAgUmVmZXJlbmNlcwoKMTEuMS4gIE5vcm1hdGl2ZSBSZWZl cmVuY2VzCgogICBbRklQUzE4MF0gIE5hdGlvbmFsIEluc3RpdHV0ZSBvZiBTdGFuZGFyZHMg YW5kIFRlY2hub2xvZ3ksICJTZWN1cmUKICAgICAgICAgICAgICBIYXNoIFN0YW5kYXJkIChT SFMpIiwgRklQUyAxODAtNCwgMjAxMi4KCiAgIFtGSVBTMjAyXSAgTmF0aW9uYWwgSW5zdGl0 dXRlIG9mIFN0YW5kYXJkcyBhbmQgVGVjaG5vbG9neSwgIlNIQS0zCiAgICAgICAgICAgICAg U3RhbmRhcmQ6IFBlcm11dGF0aW9uLUJhc2VkIEhhc2ggYW5kIEV4dGVuZGFibGUtT3V0cHV0 CiAgICAgICAgICAgICAgRnVuY3Rpb25zIiwgRklQUyAyMDIsIDIwMTUuCgogICBbUkZDMjEx OV0gIEJyYWRuZXIsIFMuLCAiS2V5IHdvcmRzIGZvciB1c2UgaW4gUkZDcyB0byBJbmRpY2F0 ZQogICAgICAgICAgICAgIFJlcXVpcmVtZW50IExldmVscyIsIEJDUCAxNCwgUkZDIDIxMTks CiAgICAgICAgICAgICAgRE9JIDEwLjE3NDg3L1JGQzIxMTksIE1hcmNoIDE5OTcsCiAgICAg ICAgICAgICAgPGh0dHA6Ly93d3cucmZjLWVkaXRvci5vcmcvaW5mby9yZmMyMTE5Pi4KCiAg IFtSRkM0NTA2XSAgRWlzbGVyLCBNLiwgRWQuLCAiWERSOiBFeHRlcm5hbCBEYXRhIFJlcHJl c2VudGF0aW9uCiAgICAgICAgICAgICAgU3RhbmRhcmQiLCBTVEQgNjcsIFJGQyA0NTA2LCBE T0kgMTAuMTc0ODcvUkZDNDUwNiwgTWF5CiAgICAgICAgICAgICAgMjAwNiwgPGh0dHA6Ly93 d3cucmZjLWVkaXRvci5vcmcvaW5mby9yZmM0NTA2Pi4KCiAgIFtSRkM4MTI2XSAgQ290dG9u LCBNLiwgTGVpYmEsIEIuLCBhbmQgVC4gTmFydGVuLCAiR3VpZGVsaW5lcyBmb3IKICAgICAg ICAgICAgICBXcml0aW5nIGFuIElBTkEgQ29uc2lkZXJhdGlvbnMgU2VjdGlvbiBpbiBSRkNz IiwgQkNQIDI2LAogICAgICAgICAgICAgIFJGQyA4MTI2LCBET0kgMTAuMTc0ODcvUkZDODEy NiwgSnVuZSAyMDE3LAogICAgICAgICAgICAgIDxodHRwOi8vd3d3LnJmYy1lZGl0b3Iub3Jn L2luZm8vcmZjODEyNj4uCgoxMS4yLiAgSW5mb3JtYXRpdmUgUmVmZXJlbmNlcwoKICAgW0JE SDExXSAgICBCdWNobWFubiwgSi4sIERhaG1lbiwgRS4sIGFuZCBBLiBIdWVsc2luZywgIlhN U1MgLSBBCiAgICAgICAgICAgICAgUHJhY3RpY2FsIEZvcndhcmQgU2VjdXJlIFNpZ25hdHVy ZSBTY2hlbWUgQmFzZWQgb24gTWluaW1hbAogICAgICAgICAgICAgIFNlY3VyaXR5IEFzc3Vt cHRpb25zIiwgTGVjdHVyZSBOb3RlcyBpbiBDb21wdXRlciBTY2llbmNlCiAgICAgICAgICAg ICAgdm9sdW1lIDcwNzEuIFBvc3QtUXVhbnR1bSBDcnlwdG9ncmFwaHksIDIwMTEuCgogICBb QkRTMDhdICAgIEJ1Y2htYW5uLCBKLiwgRGFobWVuLCBFLiwgYW5kIE0uIFNjaG5laWRlciwg Ik1lcmtsZSBUcmVlCiAgICAgICAgICAgICAgVHJhdmVyc2FsIFJldmlzaXRlZCIsIExlY3R1 cmUgTm90ZXMgaW4gQ29tcHV0ZXIgU2NpZW5jZQogICAgICAgICAgICAgIHZvbHVtZSA1Mjk5 LiBQb3N0LVF1YW50dW0gQ3J5cHRvZ3JhcGh5LCAyMDA4LgoKICAgW0JEUzA5XSAgICBCdWNo bWFubiwgSi4sIERhaG1lbiwgRS4sIGFuZCBNLiBTenlkbG8sICJIYXNoLWJhc2VkCiAgICAg ICAgICAgICAgRGlnaXRhbCBTaWduYXR1cmUgU2NoZW1lcyIsIEJvb2sgY2hhcHRlciBQb3N0 LVF1YW50dW0KICAgICAgICAgICAgICBDcnlwdG9ncmFwaHksIFNwcmluZ2VyLCAyMDA5LgoK CgoKCkh1ZWxzaW5nLCBldCBhbC4gICAgICAgIEV4cGlyZXMgSmFudWFyeSAyNSwgMjAxOCAg ICAgICAgICAgICAgIFtQYWdlIDU2XQoMCkludGVybmV0LURyYWZ0ICAgIFhNU1M6IEV4dGVu ZGVkIEhhc2gtQmFzZWQgU2lnbmF0dXJlcyAgICAgICAgIEp1bHkgMjAxNwoKCiAgIFtCSEgx NV0gICAgQmVybnN0ZWluLCBELiwgSG9wd29vZCwgRC4sIEh1ZWxzaW5nLCBBLiwgTGFuZ2Us IFQuLAogICAgICAgICAgICAgIE5pZWRlcmhhZ2VuLCBSLiwgUGFwYWNocmlzdG9kb3Vsb3Us IEwuLCBTY2huZWlkZXIsIE0uLAogICAgICAgICAgICAgIFNjaHdhYmUsIFAuLCBhbmQgWi4g V2lsY294LU8nSGVhcm4sICJTUEhJTkNTOiBQcmFjdGljYWwKICAgICAgICAgICAgICBTdGF0 ZWxlc3MgSGFzaC1CYXNlZCBTaWduYXR1cmVzIiwgTGVjdHVyZSBOb3RlcyBpbgogICAgICAg ICAgICAgIENvbXB1dGVyIFNjaWVuY2Ugdm9sdW1lIDkwNTYuIEFkdmFuY2VzIGluIENyeXB0 b2xvZ3kgLQogICAgICAgICAgICAgIEVVUk9DUllQVCwgMjAxNS4KCiAgIFtIUkIxM10gICAg SHVlbHNpbmcsIEEuLCBSYXVzY2gsIEwuLCBhbmQgSi4gQnVjaG1hbm4sICJPcHRpbWFsCiAg ICAgICAgICAgICAgUGFyYW1ldGVycyBmb3IgWE1TU15NVCIsIExlY3R1cmUgTm90ZXMgaW4g Q29tcHV0ZXIgU2NpZW5jZQogICAgICAgICAgICAgIHZvbHVtZSA4MTI4LiBDRC1BUkVTLCAy MDEzLgoKICAgW0hSUzE2XSAgICBIdWVsc2luZywgQS4sIFJpam5ldmVsZCwgSi4sIGFuZCBG LiBTb25nLCAiTWl0aWdhdGluZwogICAgICAgICAgICAgIE11bHRpLVRhcmdldCBBdHRhY2tz IGluIEhhc2gtYmFzZWQgU2lnbmF0dXJlcyIsIExlY3R1cmUKICAgICAgICAgICAgICBOb3Rl cyBpbiBDb21wdXRlciBTY2llbmNlIHZvbHVtZSA5NjE0LiBQdWJsaWMtS2V5CiAgICAgICAg ICAgICAgQ3J5cHRvZ3JhcGh5IC0gUEtDIDIwMTYsIDIwMTYuCgogICBbSHVlbHNpbmcxM10K ICAgICAgICAgICAgICBIdWVsc2luZywgQS4sICJXLU9UUysgLSBTaG9ydGVyIFNpZ25hdHVy ZXMgZm9yIEhhc2gtQmFzZWQKICAgICAgICAgICAgICBTaWduYXR1cmUgU2NoZW1lcyIsIExl Y3R1cmUgTm90ZXMgaW4gQ29tcHV0ZXIgU2NpZW5jZQogICAgICAgICAgICAgIHZvbHVtZSA3 OTE4LiBQcm9ncmVzcyBpbiBDcnlwdG9sb2d5IC0gQUZSSUNBQ1JZUFQsIDIwMTMuCgogICBb SHVlbHNpbmcxM2FdCiAgICAgICAgICAgICAgSHVlbHNpbmcsIEEuLCAiUHJhY3RpY2FsIEZv cndhcmQgU2VjdXJlIFNpZ25hdHVyZXMgdXNpbmcKICAgICAgICAgICAgICBNaW5pbWFsIFNl Y3VyaXR5IEFzc3VtcHRpb25zIiwgUGhEIHRoZXNpcyBUVSBEYXJtc3RhZHQsCiAgICAgICAg ICAgICAgMjAxMywKICAgICAgICAgICAgICA8aHR0cDovL3R1cHJpbnRzLnVsYi50dS1kYXJt c3RhZHQuZGUvMzY1MS8xL1RoZXNpcy5wZGY+LgoKICAgW0thbGlza2kxNV0KICAgICAgICAg ICAgICBLYWxpc2tpLCBCLiwgIlBhbmVsOiBTaG9yaW5nIHVwIHRoZSBJbmZyYXN0cnVjdHVy ZTogQQogICAgICAgICAgICAgIFN0cmF0ZWd5IGZvciBTdGFuZGFyZGl6aW5nIEhhc2ggU2ln bmF0dXJlcyIsIE5JU1QgV29ya3Nob3AKICAgICAgICAgICAgICBvbiBDeWJlcnNlY3VyaXR5 IGluIGEgUG9zdC1RdWFudHVtIFdvcmxkLCAyMDE1LgoKICAgW0tNTjE0XSAgICBLbmVjaHQs IE0uLCBNZWllciwgVy4sIGFuZCBDLiBOaWNvbGEsICJBIHNwYWNlLSBhbmQgdGltZS0KICAg ICAgICAgICAgICBlZmZpY2llbnQgSW1wbGVtZW50YXRpb24gb2YgdGhlIE1lcmtsZSBUcmVl IFRyYXZlcnNhbAogICAgICAgICAgICAgIEFsZ29yaXRobSIsIENvbXB1dGluZyBSZXNlYXJj aCBSZXBvc2l0b3J5CiAgICAgICAgICAgICAgKENvUlIpLiBhclhpdjoxNDA5LjQwODEsIDIw MTQuCgogICBbTUNGMTddICAgIE1jR3JldywgRC4sIEN1cmNpbywgTS4sIGFuZCBTLiBGbHVo cmVyLCAiSGFzaC1CYXNlZAogICAgICAgICAgICAgIFNpZ25hdHVyZXMiLCBXb3JrIGluIFBy b2dyZXNzLCBkcmFmdC1tY2dyZXctaGFzaC1zaWdzLTA3LAogICAgICAgICAgICAgIEp1bmUg MjAxNywgPGh0dHA6Ly93d3cuaWV0Zi5vcmcvYXJjaGl2ZS9pZC8KICAgICAgICAgICAgICBk cmFmdC1tY2dyZXctaGFzaC1zaWdzLTA3LnR4dD4uCgogICBbTWVya2xlNzldCiAgICAgICAg ICAgICAgTWVya2xlLCBSLiwgIlNlY3JlY3ksIEF1dGhlbnRpY2F0aW9uLCBhbmQgUHVibGlj IEtleQogICAgICAgICAgICAgIFN5c3RlbXMiLCBTdGFuZm9yZCBVbml2ZXJzaXR5IEluZm9y bWF0aW9uIFN5c3RlbXMKICAgICAgICAgICAgICBMYWJvcmF0b3J5IFRlY2huaWNhbCBSZXBv cnQgMTk3OS0xLCAxOTc5LAogICAgICAgICAgICAgIDxodHRwOi8vd3d3Lm1lcmtsZS5jb20v cGFwZXJzL1RoZXNpczE5NzkucGRmPi4KCgoKCkh1ZWxzaW5nLCBldCBhbC4gICAgICAgIEV4 cGlyZXMgSmFudWFyeSAyNSwgMjAxOCAgICAgICAgICAgICAgIFtQYWdlIDU3XQoMCkludGVy bmV0LURyYWZ0ICAgIFhNU1M6IEV4dGVuZGVkIEhhc2gtQmFzZWQgU2lnbmF0dXJlcyAgICAg ICAgIEp1bHkgMjAxNwoKCkFwcGVuZGl4IEEuICBXT1RTKyBYRFIgRm9ybWF0cwoKICAgVGhl IFdPVFMrIHNpZ25hdHVyZSBhbmQgcHVibGljIGtleSBmb3JtYXRzIGFyZSBmb3JtYWxseSBk ZWZpbmVkIHVzaW5nCiAgIFhEUiBbUkZDNDUwNl0gaW4gb3JkZXIgdG8gcHJvdmlkZSBhbiB1 bmFtYmlndW91cywgbWFjaGluZSByZWFkYWJsZQogICBkZWZpbml0aW9uLiAgVGhvdWdoIFhE UiBpcyB1c2VkLCB0aGVzZSBmb3JtYXRzIGFyZSBzaW1wbGUgYW5kIGVhc3kgdG8KICAgcGFy c2Ugd2l0aG91dCBhbnkgc3BlY2lhbCB0b29scy4gIFRvIGF2b2lkIHRoZSBuZWVkIHRvIGNv bnZlcnQgdG8gYW5kCiAgIGZyb20gbmV0d29yayAvIGhvc3QgYnl0ZSBvcmRlciwgdGhlIGVu dW1lcmF0aW9uIHZhbHVlcyBhcmUgYWxsCiAgIHBhbGluZHJvbWVzLiAgTm90ZSB0aGF0IHRo aXMgcmVwcmVzZW50YXRpb24gaW5jbHVkZXMgYWxsIG9wdGlvbmFsCiAgIHBhcmFtZXRlciBz ZXRzLiAgVGhlIHNhbWUgYXBwbGllcyBmb3IgdGhlIFhNU1MgYW5kIFhNU1NeTVQgZm9ybWF0 cwogICBiZWxvdy4KCiAgIFdPVFMrIHBhcmFtZXRlciBzZXRzIGFyZSBkZWZpbmVkIHVzaW5n IFhEUiBzeW50YXggYXMgZm9sbG93czoKCgogICAgICAvKiBvdHNfYWxnb3JpdGhtX3R5cGUg aWRlbnRpZmllcyBhIHBhcnRpY3VsYXIKICAgICAgICAgc2lnbmF0dXJlIGFsZ29yaXRobSAq LwoKICAgICAgZW51bSBvdHNfYWxnb3JpdGhtX3R5cGUgewogICAgICAgIHdvdHNwX3Jlc2Vy dmVkICAgICA9IDB4MDAwMDAwMDAsCiAgICAgICAgd290c3Atc2hhMl8yNTYgPSAweDAxMDAw MDAxLAogICAgICAgIHdvdHNwLXNoYTJfNTEyID0gMHgwMjAwMDAwMiwKICAgICAgICB3b3Rz cC1zaGFrZV8yNTYgPSAweDAzMDAwMDAzLAogICAgICAgIHdvdHNwLXNoYWtlXzUxMiA9IDB4 MDQwMDAwMDQsCiAgICAgIH07CgoKICAgV09UUysgc2lnbmF0dXJlcyBhcmUgZGVmaW5lZCB1 c2luZyBYRFIgc3ludGF4IGFzIGZvbGxvd3M6CgoKICAgICAgLyogQnl0ZSBzdHJpbmdzICov CgogICAgICB0eXBlZGVmIG9wYXF1ZSBieXRlc3RyaW5nMzJbMzJdOwogICAgICB0eXBlZGVm IG9wYXF1ZSBieXRlc3RyaW5nNjRbNjRdOwoKICAgICAgdW5pb24gb3RzX3NpZ25hdHVyZSBz d2l0Y2ggKG90c19hbGdvcml0aG1fdHlwZSB0eXBlKSB7CiAgICAgICAgY2FzZSB3b3RzcC1z aGEyXzI1NjoKICAgICAgICBjYXNlIHdvdHNwLXNoYWtlXzI1NjoKICAgICAgICAgIGJ5dGVz dHJpbmczMiBvdHNfc2lnX24zMl9sZW42N1s2N107CgogICAgICAgIGNhc2Ugd290c3Atc2hh Ml81MTI6CiAgICAgICAgY2FzZSB3b3RzcC1zaGFrZV81MTI6CiAgICAgICAgICBieXRlc3Ry aW5nNjQgb3RzX3NpZ19uNjRfbGVuMThbMTMxXTsKCiAgICAgICAgZGVmYXVsdDoKICAgICAg ICAgIHZvaWQ7ICAgLyogZXJyb3IgY29uZGl0aW9uICovCiAgICAgIH07CgoKCgoKSHVlbHNp bmcsIGV0IGFsLiAgICAgICAgRXhwaXJlcyBKYW51YXJ5IDI1LCAyMDE4ICAgICAgICAgICAg ICAgW1BhZ2UgNThdCgwKSW50ZXJuZXQtRHJhZnQgICAgWE1TUzogRXh0ZW5kZWQgSGFzaC1C YXNlZCBTaWduYXR1cmVzICAgICAgICAgSnVseSAyMDE3CgoKICAgV09UUysgcHVibGljIGtl eXMgYXJlIGRlZmluZWQgdXNpbmcgWERSIHN5bnRheCBhcyBmb2xsb3dzOgoKCiAgICAgIHVu aW9uIG90c19wdWJrZXkgc3dpdGNoIChvdHNfYWxnb3JpdGhtX3R5cGUgdHlwZSkgewogICAg ICAgIGNhc2Ugd290c3Atc2hhMl8yNTY6CiAgICAgICAgY2FzZSB3b3RzcC1zaGFrZV8yNTY6 CiAgICAgICAgICBieXRlc3RyaW5nMzIgb3RzX3B1YmtfbjMyX2xlbjY3WzY3XTsKCiAgICAg ICAgY2FzZSB3b3RzcC1zaGEyXzUxMjoKICAgICAgICBjYXNlIHdvdHNwLXNoYWtlXzUxMjoK ICAgICAgICAgIGJ5dGVzdHJpbmc2NCBvdHNfcHVia19uNjRfbGVuMThbMTMxXTsKCiAgICAg ICAgZGVmYXVsdDoKICAgICAgICAgIHZvaWQ7ICAgLyogZXJyb3IgY29uZGl0aW9uICovCiAg ICAgIH07CgoKQXBwZW5kaXggQi4gIFhNU1MgWERSIEZvcm1hdHMKCgoKCgoKCgoKCgoKCgoK CgoKCgoKCgoKCgoKCgoKCgoKSHVlbHNpbmcsIGV0IGFsLiAgICAgICAgRXhwaXJlcyBKYW51 YXJ5IDI1LCAyMDE4ICAgICAgICAgICAgICAgW1BhZ2UgNTldCgwKSW50ZXJuZXQtRHJhZnQg ICAgWE1TUzogRXh0ZW5kZWQgSGFzaC1CYXNlZCBTaWduYXR1cmVzICAgICAgICAgSnVseSAy MDE3CgoKICAgWE1TUyBwYXJhbWV0ZXIgc2V0cyBhcmUgZGVmaW5lZCB1c2luZyBYRFIgc3lu dGF4IGFzIGZvbGxvd3M6CgoKICAgICAgLyogQnl0ZSBzdHJpbmdzICovCgogICAgICB0eXBl ZGVmIG9wYXF1ZSBieXRlc3RyaW5nNFs0XTsKCiAgICAgIC8qIERlZmluaXRpb24gb2YgcGFy YW1ldGVyIHNldHMgKi8KCiAgICAgIGVudW0geG1zc19hbGdvcml0aG1fdHlwZSB7CiAgICAg ICAgeG1zc19yZXNlcnZlZCAgICAgICAgID0gMHgwMDAwMDAwMCwKCiAgICAgICAgLyogMjU2 IGJpdCBjbGFzc2ljYWwgc2VjdXJpdHksIDEyOCBiaXQgcG9zdC1xdWFudHVtIHNlY3VyaXR5 ICovCgogICAgICAgIHhtc3Mtc2hhMl8xMF8yNTYgPSAweDAxMDAwMDAxLAogICAgICAgIHht c3Mtc2hhMl8xNl8yNTYgPSAweDAyMDAwMDAyLAogICAgICAgIHhtc3Mtc2hhMl8yMF8yNTYg PSAweDAzMDAwMDAzLAoKICAgICAgICAvKiA1MTIgYml0IGNsYXNzaWNhbCBzZWN1cml0eSwg MjU2IGJpdCBwb3N0LXF1YW50dW0gc2VjdXJpdHkgKi8KCiAgICAgICAgeG1zcy1zaGEyXzEw XzUxMiA9IDB4MDQwMDAwMDQsCiAgICAgICAgeG1zcy1zaGEyXzE2XzUxMiA9IDB4MDUwMDAw MDUsCiAgICAgICAgeG1zcy1zaGEyXzIwXzUxMiA9IDB4MDYwMDAwMDYsCgogICAgICAgIC8q IDI1NiBiaXQgY2xhc3NpY2FsIHNlY3VyaXR5LCAxMjggYml0IHBvc3QtcXVhbnR1bSBzZWN1 cml0eSAqLwoKICAgICAgICB4bXNzLXNoYWtlXzEwXzI1NiA9IDB4MDcwMDAwMDcsCiAgICAg ICAgeG1zcy1zaGFrZV8xNl8yNTYgPSAweDA4MDAwMDA4LAogICAgICAgIHhtc3Mtc2hha2Vf MjBfMjU2ID0gMHgwOTAwMDAwOSwKCiAgICAgICAgLyogNTEyIGJpdCBjbGFzc2ljYWwgc2Vj dXJpdHksIDI1NiBiaXQgcG9zdC1xdWFudHVtIHNlY3VyaXR5ICovCgogICAgICAgIHhtc3Mt c2hha2VfMTBfNTEyID0gMHgwYTAwMDAwYSwKICAgICAgICB4bXNzLXNoYWtlXzE2XzUxMiA9 IDB4MGIwMDAwMGIsCiAgICAgICAgeG1zcy1zaGFrZV8yMF81MTIgPSAweDBjMDAwMDBjLAog ICAgICB9OwoKCiAgIFhNU1Mgc2lnbmF0dXJlcyBhcmUgZGVmaW5lZCB1c2luZyBYRFIgc3lu dGF4IGFzIGZvbGxvd3M6CgoKICAgICAgLyogQXV0aGVudGljYXRpb24gcGF0aCB0eXBlcyAq LwoKICAgICAgdW5pb24geG1zc19wYXRoIHN3aXRjaCAoeG1zc19hbGdvcml0aG1fdHlwZSB0 eXBlKSB7CiAgICAgICAgY2FzZSB4bXNzLXNoYTJfMTBfMjU2OgogICAgICAgIGNhc2UgeG1z cy1zaGFrZV8xMF8yNTY6CiAgICAgICAgICBieXRlc3RyaW5nMzIgcGF0aF9uMzJfdDEwWzEw XTsKCgoKCkh1ZWxzaW5nLCBldCBhbC4gICAgICAgIEV4cGlyZXMgSmFudWFyeSAyNSwgMjAx OCAgICAgICAgICAgICAgIFtQYWdlIDYwXQoMCkludGVybmV0LURyYWZ0ICAgIFhNU1M6IEV4 dGVuZGVkIEhhc2gtQmFzZWQgU2lnbmF0dXJlcyAgICAgICAgIEp1bHkgMjAxNwoKCiAgICAg ICAgY2FzZSB4bXNzLXNoYTJfMTZfMjU2OgogICAgICAgIGNhc2UgeG1zcy1zaGFrZV8xNl8y NTY6CiAgICAgICAgICBieXRlc3RyaW5nMzIgcGF0aF9uMzJfdDE2WzE2XTsKCiAgICAgICAg Y2FzZSB4bXNzLXNoYTJfMjBfMjU2OgogICAgICAgIGNhc2UgeG1zcy1zaGFrZV8yMF8yNTY6 CiAgICAgICAgICBieXRlc3RyaW5nMzIgcGF0aF9uMzJfdDIwWzIwXTsKCiAgICAgICAgY2Fz ZSB4bXNzLXNoYTJfMTBfNTEyOgogICAgICAgIGNhc2UgeG1zcy1zaGFrZV8xMF81MTI6CiAg ICAgICAgICBieXRlc3RyaW5nNjQgcGF0aF9uNjRfdDEwWzEwXTsKCiAgICAgICAgY2FzZSB4 bXNzLXNoYTJfMTZfNTEyOgogICAgICAgIGNhc2UgeG1zcy1zaGFrZV8xNl81MTI6CiAgICAg ICAgICBieXRlc3RyaW5nNjQgcGF0aF9uNjRfdDE2WzE2XTsKCiAgICAgICAgY2FzZSB4bXNz LXNoYTJfMjBfNTEyOgogICAgICAgIGNhc2UgeG1zcy1zaGFrZV8yMF81MTI6CiAgICAgICAg ICBieXRlc3RyaW5nNjQgcGF0aF9uNjRfdDIwWzIwXTsKCiAgICAgICAgZGVmYXVsdDoKICAg ICAgICAgIHZvaWQ7ICAgICAvKiBlcnJvciBjb25kaXRpb24gKi8KICAgICAgfTsKCiAgICAg IC8qIFR5cGVzIGZvciBYTVNTIHJhbmRvbSBzdHJpbmdzICovCgogICAgICB1bmlvbiByYW5k b21fc3RyaW5nX3htc3Mgc3dpdGNoICh4bXNzX2FsZ29yaXRobV90eXBlIHR5cGUpIHsKICAg ICAgICBjYXNlIHhtc3Mtc2hhMl8xMF8yNTY6CiAgICAgICAgY2FzZSB4bXNzLXNoYTJfMTZf MjU2OgogICAgICAgIGNhc2UgeG1zcy1zaGEyXzIwXzI1NjoKICAgICAgICBjYXNlIHhtc3Mt c2hha2VfMTBfMjU2OgogICAgICAgIGNhc2UgeG1zcy1zaGFrZV8xNl8yNTY6CiAgICAgICAg Y2FzZSB4bXNzLXNoYWtlXzIwXzI1NjoKICAgICAgICAgIGJ5dGVzdHJpbmczMiByYW5kX24z MjsKCiAgICAgICAgY2FzZSB4bXNzLXNoYTJfMTBfNTEyOgogICAgICAgIGNhc2UgeG1zcy1z aGEyXzE2XzUxMjoKICAgICAgICBjYXNlIHhtc3Mtc2hhMl8yMF81MTI6CiAgICAgICAgY2Fz ZSB4bXNzLXNoYWtlXzEwXzUxMjoKICAgICAgICBjYXNlIHhtc3Mtc2hha2VfMTZfNTEyOgog ICAgICAgIGNhc2UgeG1zcy1zaGFrZV8yMF81MTI6CiAgICAgICAgICBieXRlc3RyaW5nNjQg cmFuZF9uNjQ7CgogICAgICAgIGRlZmF1bHQ6CiAgICAgICAgICB2b2lkOyAgICAgLyogZXJy b3IgY29uZGl0aW9uICovCiAgICAgIH07CgogICAgICAvKiBDb3JyZXNwb25kaW5nIFdPVFMr IHR5cGUgZm9yIGdpdmVuIFhNU1MgdHlwZSAqLwoKCgpIdWVsc2luZywgZXQgYWwuICAgICAg ICBFeHBpcmVzIEphbnVhcnkgMjUsIDIwMTggICAgICAgICAgICAgICBbUGFnZSA2MV0KDApJ bnRlcm5ldC1EcmFmdCAgICBYTVNTOiBFeHRlbmRlZCBIYXNoLUJhc2VkIFNpZ25hdHVyZXMg ICAgICAgICBKdWx5IDIwMTcKCgogICAgICB1bmlvbiB4bXNzX290c19zaWduYXR1cmUgc3dp dGNoICh4bXNzX2FsZ29yaXRobV90eXBlIHR5cGUpIHsKICAgICAgICBjYXNlIHhtc3Mtc2hh Ml8xMF8yNTY6CiAgICAgICAgY2FzZSB4bXNzLXNoYTJfMTZfMjU2OgogICAgICAgIGNhc2Ug eG1zcy1zaGEyXzIwXzI1NjoKICAgICAgICAgIHdvdHNwLXNoYTJfMjU2OwoKICAgICAgICBj YXNlIHhtc3Mtc2hhMl8xMF81MTI6CiAgICAgICAgY2FzZSB4bXNzLXNoYTJfMTZfNTEyOgog ICAgICAgIGNhc2UgeG1zcy1zaGEyXzIwXzUxMjoKICAgICAgICAgIHdvdHNwLXNoYTJfNTEy OwoKICAgICAgICBjYXNlIHhtc3Mtc2hha2VfMTBfMjU2OgogICAgICAgIGNhc2UgeG1zcy1z aGFrZV8xNl8yNTY6CiAgICAgICAgY2FzZSB4bXNzLXNoYWtlXzIwXzI1NjoKICAgICAgICAg IHdvdHNwLXNoYWtlXzI1NjsKCiAgICAgICAgY2FzZSB4bXNzLXNoYWtlXzEwXzUxMjoKICAg ICAgICBjYXNlIHhtc3Mtc2hha2VfMTZfNTEyOgogICAgICAgIGNhc2UgeG1zcy1zaGFrZV8y MF81MTI6CiAgICAgICAgICB3b3RzcC1zaGFrZV81MTI7CgogICAgICAgIGRlZmF1bHQ6CiAg ICAgICAgICB2b2lkOyAgICAgLyogZXJyb3IgY29uZGl0aW9uICovCiAgICAgIH07CgogICAg ICAvKiBYTVNTIHNpZ25hdHVyZSBzdHJ1Y3R1cmUgKi8KCiAgICAgIHN0cnVjdCB4bXNzX3Np Z25hdHVyZSB7CiAgICAgICAgLyogV09UUysga2V5IHBhaXIgaW5kZXggKi8KICAgICAgICBi eXRlc3RyaW5nNCBpZHhfc2lnOwogICAgICAgIC8qIFJhbmRvbSBzdHJpbmcgZm9yIHJhbmRv bWl6ZWQgaGFzaGluZyAqLwogICAgICAgIHJhbmRvbV9zdHJpbmdfeG1zcyByYW5kX3N0cmlu ZzsKICAgICAgICAvKiBXT1RTKyBzaWduYXR1cmUgKi8KICAgICAgICB4bXNzX290c19zaWdu YXR1cmUgc2lnX290czsKICAgICAgICAvKiBhdXRoZW50aWNhdGlvbiBwYXRoICovCiAgICAg ICAgeG1zc19wYXRoIG5vZGVzOwogICAgICB9OwoKCiAgIFhNU1MgcHVibGljIGtleXMgYXJl IGRlZmluZWQgdXNpbmcgWERSIHN5bnRheCBhcyBmb2xsb3dzOgoKCiAgICAgIC8qIFR5cGVz IGZvciBiaXRtYXNrIHNlZWQgKi8KCiAgICAgIHVuaW9uIHNlZWQgc3dpdGNoICh4bXNzX2Fs Z29yaXRobV90eXBlIHR5cGUpIHsKICAgICAgICBjYXNlIHhtc3Mtc2hhMl8xMF8yNTY6CiAg ICAgICAgY2FzZSB4bXNzLXNoYTJfMTZfMjU2OgogICAgICAgIGNhc2UgeG1zcy1zaGEyXzIw XzI1NjoKCgoKSHVlbHNpbmcsIGV0IGFsLiAgICAgICAgRXhwaXJlcyBKYW51YXJ5IDI1LCAy MDE4ICAgICAgICAgICAgICAgW1BhZ2UgNjJdCgwKSW50ZXJuZXQtRHJhZnQgICAgWE1TUzog RXh0ZW5kZWQgSGFzaC1CYXNlZCBTaWduYXR1cmVzICAgICAgICAgSnVseSAyMDE3CgoKICAg ICAgICBjYXNlIHhtc3Mtc2hha2VfMTBfMjU2OgogICAgICAgIGNhc2UgeG1zcy1zaGFrZV8x Nl8yNTY6CiAgICAgICAgY2FzZSB4bXNzLXNoYWtlXzIwXzI1NjoKICAgICAgICAgIGJ5dGVz dHJpbmczMiBzZWVkX24zMjsKCiAgICAgICAgY2FzZSB4bXNzLXNoYTJfMTBfNTEyOgogICAg ICAgIGNhc2UgeG1zcy1zaGEyXzE2XzUxMjoKICAgICAgICBjYXNlIHhtc3Mtc2hhMl8yMF81 MTI6CiAgICAgICAgY2FzZSB4bXNzLXNoYWtlXzEwXzUxMjoKICAgICAgICBjYXNlIHhtc3Mt c2hha2VfMTZfNTEyOgogICAgICAgIGNhc2UgeG1zcy1zaGFrZV8yMF81MTI6CiAgICAgICAg ICBieXRlc3RyaW5nNjQgc2VlZF9uNjQ7CgogICAgICAgIGRlZmF1bHQ6CiAgICAgICAgICB2 b2lkOyAgICAgLyogZXJyb3IgY29uZGl0aW9uICovCiAgICAgIH07CgogICAgICAvKiBUeXBl cyBmb3IgWE1TUyByb290IG5vZGUgKi8KCiAgICAgIHVuaW9uIHhtc3Nfcm9vdCBzd2l0Y2gg KHhtc3NfYWxnb3JpdGhtX3R5cGUgdHlwZSkgewogICAgICAgIGNhc2UgeG1zcy1zaGEyXzEw XzI1NjoKICAgICAgICBjYXNlIHhtc3Mtc2hhMl8xNl8yNTY6CiAgICAgICAgY2FzZSB4bXNz LXNoYTJfMjBfMjU2OgogICAgICAgIGNhc2UgeG1zcy1zaGFrZV8xMF8yNTY6CiAgICAgICAg Y2FzZSB4bXNzLXNoYWtlXzE2XzI1NjoKICAgICAgICBjYXNlIHhtc3Mtc2hha2VfMjBfMjU2 OgogICAgICAgICAgYnl0ZXN0cmluZzMyIHJvb3RfbjMyOwoKICAgICAgICBjYXNlIHhtc3Mt c2hhMl8xMF81MTI6CiAgICAgICAgY2FzZSB4bXNzLXNoYTJfMTZfNTEyOgogICAgICAgIGNh c2UgeG1zcy1zaGEyXzIwXzUxMjoKICAgICAgICBjYXNlIHhtc3Mtc2hha2VfMTBfNTEyOgog ICAgICAgIGNhc2UgeG1zcy1zaGFrZV8xNl81MTI6CiAgICAgICAgY2FzZSB4bXNzLXNoYWtl XzIwXzUxMjoKICAgICAgICAgIGJ5dGVzdHJpbmc2NCByb290X242NDsKCiAgICAgICAgZGVm YXVsdDoKICAgICAgICAgIHZvaWQ7ICAgICAvKiBlcnJvciBjb25kaXRpb24gKi8KICAgICAg fTsKCiAgICAgIC8qIFhNU1MgcHVibGljIGtleSBzdHJ1Y3R1cmUgKi8KCiAgICAgIHN0cnVj dCB4bXNzX3B1YmxpY19rZXkgewogICAgICAgIHhtc3Nfcm9vdCByb290OyAgLyogUm9vdCBu b2RlICovCiAgICAgICAgc2VlZCBTRUVEOyAgLyogU2VlZCBmb3IgYml0bWFza3MgKi8KICAg ICAgfTsKCgoKCgpIdWVsc2luZywgZXQgYWwuICAgICAgICBFeHBpcmVzIEphbnVhcnkgMjUs IDIwMTggICAgICAgICAgICAgICBbUGFnZSA2M10KDApJbnRlcm5ldC1EcmFmdCAgICBYTVNT OiBFeHRlbmRlZCBIYXNoLUJhc2VkIFNpZ25hdHVyZXMgICAgICAgICBKdWx5IDIwMTcKCgpB cHBlbmRpeCBDLiAgWE1TU15NVCBYRFIgRm9ybWF0cwoKICAgWE1TU15NVCBwYXJhbWV0ZXIg c2V0cyBhcmUgZGVmaW5lZCB1c2luZyBYRFIgc3ludGF4IGFzIGZvbGxvd3M6CgoKICAgICAg LyogQnl0ZSBzdHJpbmdzICovCgogICAgICB0eXBlZGVmIG9wYXF1ZSBieXRlc3RyaW5nM1sz XTsKICAgICAgdHlwZWRlZiBvcGFxdWUgYnl0ZXN0cmluZzVbNV07CiAgICAgIHR5cGVkZWYg b3BhcXVlIGJ5dGVzdHJpbmc4WzhdOwoKICAgICAgLyogRGVmaW5pdGlvbiBvZiBwYXJhbWV0 ZXIgc2V0cyAqLwoKICAgICAgZW51bSB4bXNzbXRfYWxnb3JpdGhtX3R5cGUgewogICAgICAg IHhtc3NtdF9yZXNlcnZlZCAgICAgICAgICAgICA9IDB4MDAwMDAwMDAsCgogICAgICAgIC8q IDI1NiBiaXQgY2xhc3NpY2FsIHNlY3VyaXR5LCAxMjggYml0IHBvc3QtcXVhbnR1bSBzZWN1 cml0eSAqLwoKICAgICAgICB4bXNzbXQtc2hhMl8yMC8yXzI1NiAgPSAweDAxMDAwMDAxLAog ICAgICAgIHhtc3NtdC1zaGEyXzIwLzRfMjU2ICA9IDB4MDIwMDAwMDIsCiAgICAgICAgeG1z c210LXNoYTJfNDAvMl8yNTYgID0gMHgwMzAwMDAwMywKICAgICAgICB4bXNzbXQtc2hhMl80 MC80XzI1NiAgPSAweDA0MDAwMDA0LAogICAgICAgIHhtc3NtdC1zaGEyXzQwLzhfMjU2ICA9 IDB4MDUwMDAwMDUsCiAgICAgICAgeG1zc210LXNoYTJfNjAvM18yNTYgID0gMHgwNjAwMDAw NiwKICAgICAgICB4bXNzbXQtc2hhMl82MC82XzI1NiAgPSAweDA3MDAwMDA3LAogICAgICAg IHhtc3NtdC1zaGEyXzYwLzEyXzI1NiA9IDB4MDgwMDAwMDgsCgogICAgICAgIC8qIDUxMiBi aXQgY2xhc3NpY2FsIHNlY3VyaXR5LCAyNTYgYml0IHBvc3QtcXVhbnR1bSBzZWN1cml0eSAq LwoKICAgICAgICB4bXNzbXQtc2hhMl8yMC8yXzUxMiAgPSAweDA5MDAwMDA5LAogICAgICAg IHhtc3NtdC1zaGEyXzIwLzRfNTEyICA9IDB4MGEwMDAwMGEsCiAgICAgICAgeG1zc210LXNo YTJfNDAvMl81MTIgID0gMHgwYjAwMDAwYiwKICAgICAgICB4bXNzbXQtc2hhMl80MC80XzUx MiAgPSAweDBjMDAwMDBjLAogICAgICAgIHhtc3NtdC1zaGEyXzQwLzhfNTEyICA9IDB4MGQw MDAwMGQsCiAgICAgICAgeG1zc210LXNoYTJfNjAvM181MTIgID0gMHgwZTAwMDAwZSwKICAg ICAgICB4bXNzbXQtc2hhMl82MC82XzUxMiAgPSAweDBmMDAwMDBmLAogICAgICAgIHhtc3Nt dC1zaGEyXzYwLzEyXzUxMiA9IDB4MDEwMTAxMDEsCgogICAgICAgIC8qIDI1NiBiaXQgY2xh c3NpY2FsIHNlY3VyaXR5LCAxMjggYml0IHBvc3QtcXVhbnR1bSBzZWN1cml0eSAqLwoKICAg ICAgICB4bXNzbXQtc2hha2VfMjAvMl8yNTYgID0gMHgwMjAxMDEwMiwKICAgICAgICB4bXNz bXQtc2hha2VfMjAvNF8yNTYgID0gMHgwMzAxMDEwMywKICAgICAgICB4bXNzbXQtc2hha2Vf NDAvMl8yNTYgID0gMHgwNDAxMDEwNCwKICAgICAgICB4bXNzbXQtc2hha2VfNDAvNF8yNTYg ID0gMHgwNTAxMDEwNSwKICAgICAgICB4bXNzbXQtc2hha2VfNDAvOF8yNTYgID0gMHgwNjAx MDEwNiwKICAgICAgICB4bXNzbXQtc2hha2VfNjAvM18yNTYgID0gMHgwNzAxMDEwNywKICAg ICAgICB4bXNzbXQtc2hha2VfNjAvNl8yNTYgID0gMHgwODAxMDEwOCwKICAgICAgICB4bXNz bXQtc2hha2VfNjAvMTJfMjU2ID0gMHgwOTAxMDEwOSwKCgoKSHVlbHNpbmcsIGV0IGFsLiAg ICAgICAgRXhwaXJlcyBKYW51YXJ5IDI1LCAyMDE4ICAgICAgICAgICAgICAgW1BhZ2UgNjRd CgwKSW50ZXJuZXQtRHJhZnQgICAgWE1TUzogRXh0ZW5kZWQgSGFzaC1CYXNlZCBTaWduYXR1 cmVzICAgICAgICAgSnVseSAyMDE3CgoKICAgICAgICAvKiA1MTIgYml0IGNsYXNzaWNhbCBz ZWN1cml0eSwgMjU2IGJpdCBwb3N0LXF1YW50dW0gc2VjdXJpdHkgKi8KCiAgICAgICAgeG1z c210LXNoYWtlXzIwLzJfNTEyICA9IDB4MGEwMTAxMGEsCiAgICAgICAgeG1zc210LXNoYWtl XzIwLzRfNTEyICA9IDB4MGIwMTAxMGIsCiAgICAgICAgeG1zc210LXNoYWtlXzQwLzJfNTEy ICA9IDB4MGMwMTAxMGMsCiAgICAgICAgeG1zc210LXNoYWtlXzQwLzRfNTEyICA9IDB4MGQw MTAxMGQsCiAgICAgICAgeG1zc210LXNoYWtlXzQwLzhfNTEyICA9IDB4MGUwMTAxMGUsCiAg ICAgICAgeG1zc210LXNoYWtlXzYwLzNfNTEyICA9IDB4MGYwMTAxMGYsCiAgICAgICAgeG1z c210LXNoYWtlXzYwLzZfNTEyICA9IDB4MDEwMjAyMDEsCiAgICAgICAgeG1zc210LXNoYWtl XzYwLzEyXzUxMiA9IDB4MDIwMjAyMDIsCiAgICAgIH07CgoKICAgWE1TU15NVCBzaWduYXR1 cmVzIGFyZSBkZWZpbmVkIHVzaW5nIFhEUiBzeW50YXggYXMgZm9sbG93czoKCgogICAgICAv KiBUeXBlIGZvciBYTVNTXk1UIGtleSBwYWlyIGluZGV4ICovCiAgICAgIC8qIERlcGVuZHMg c29sZWx5IG9uIGggKi8KCiAgICAgIHVuaW9uIGlkeF9zaWdfeG1zc210IHN3aXRjaCAoeG1z c19hbGdvcml0aG1fdHlwZSB0eXBlKSB7CiAgICAgICAgY2FzZSB4bXNzbXQtc2hhMl8yMC8y XzI1NjoKICAgICAgICBjYXNlIHhtc3NtdC1zaGEyXzIwLzRfMjU2OgogICAgICAgIGNhc2Ug eG1zc210LXNoYTJfMjAvMl81MTI6CiAgICAgICAgY2FzZSB4bXNzbXQtc2hhMl8yMC80XzUx MjoKICAgICAgICBjYXNlIHhtc3NtdC1zaGFrZV8yMC8yXzI1NjoKICAgICAgICBjYXNlIHht c3NtdC1zaGFrZV8yMC80XzI1NjoKICAgICAgICBjYXNlIHhtc3NtdC1zaGFrZV8yMC8yXzUx MjoKICAgICAgICBjYXNlIHhtc3NtdC1zaGFrZV8yMC80XzUxMjoKICAgICAgICAgIGJ5dGVz dHJpbmczIGlkeDM7CgogICAgICAgIGNhc2UgeG1zc210LXNoYTJfNDAvMl8yNTY6CiAgICAg ICAgY2FzZSB4bXNzbXQtc2hhMl80MC80XzI1NjoKICAgICAgICBjYXNlIHhtc3NtdC1zaGEy XzQwLzhfMjU2OgogICAgICAgIGNhc2UgeG1zc210LXNoYTJfNDAvMl81MTI6CiAgICAgICAg Y2FzZSB4bXNzbXQtc2hhMl80MC80XzUxMjoKICAgICAgICBjYXNlIHhtc3NtdC1zaGEyXzQw LzhfNTEyOgogICAgICAgIGNhc2UgeG1zc210LXNoYWtlXzQwLzJfMjU2OgogICAgICAgIGNh c2UgeG1zc210LXNoYWtlXzQwLzRfMjU2OgogICAgICAgIGNhc2UgeG1zc210LXNoYWtlXzQw LzhfMjU2OgogICAgICAgIGNhc2UgeG1zc210LXNoYWtlXzQwLzJfNTEyOgogICAgICAgIGNh c2UgeG1zc210LXNoYWtlXzQwLzRfNTEyOgogICAgICAgIGNhc2UgeG1zc210LXNoYWtlXzQw LzhfNTEyOgogICAgICAgICAgYnl0ZXN0cmluZzUgaWR4NTsKCiAgICAgICAgY2FzZSB4bXNz bXQtc2hhMl82MC8zXzI1NjoKICAgICAgICBjYXNlIHhtc3NtdC1zaGEyXzYwLzZfMjU2Ogog ICAgICAgIGNhc2UgeG1zc210LXNoYTJfNjAvMTJfMjU2OgogICAgICAgIGNhc2UgeG1zc210 LXNoYTJfNjAvM181MTI6CgoKCkh1ZWxzaW5nLCBldCBhbC4gICAgICAgIEV4cGlyZXMgSmFu dWFyeSAyNSwgMjAxOCAgICAgICAgICAgICAgIFtQYWdlIDY1XQoMCkludGVybmV0LURyYWZ0 ICAgIFhNU1M6IEV4dGVuZGVkIEhhc2gtQmFzZWQgU2lnbmF0dXJlcyAgICAgICAgIEp1bHkg MjAxNwoKCiAgICAgICAgY2FzZSB4bXNzbXQtc2hhMl82MC82XzUxMjoKICAgICAgICBjYXNl IHhtc3NtdC1zaGEyXzYwLzEyXzUxMjoKICAgICAgICBjYXNlIHhtc3NtdC1zaGFrZV82MC8z XzI1NjoKICAgICAgICBjYXNlIHhtc3NtdC1zaGFrZV82MC82XzI1NjoKICAgICAgICBjYXNl IHhtc3NtdC1zaGFrZV82MC8xMl8yNTY6CiAgICAgICAgY2FzZSB4bXNzbXQtc2hha2VfNjAv M181MTI6CiAgICAgICAgY2FzZSB4bXNzbXQtc2hha2VfNjAvNl81MTI6CiAgICAgICAgY2Fz ZSB4bXNzbXQtc2hha2VfNjAvMTJfNTEyOgogICAgICAgICAgYnl0ZXN0cmluZzggaWR4ODsK CiAgICAgICAgZGVmYXVsdDoKICAgICAgICAgIHZvaWQ7ICAgICAvKiBlcnJvciBjb25kaXRp b24gKi8KICAgICAgfTsKCiAgICAgIHVuaW9uIHJhbmRvbV9zdHJpbmdfeG1zc210IHN3aXRj aCAoeG1zc210X2FsZ29yaXRobV90eXBlIHR5cGUpIHsKICAgICAgICBjYXNlIHhtc3NtdC1z aGEyXzIwLzJfMjU2OgogICAgICAgIGNhc2UgeG1zc210LXNoYTJfMjAvNF8yNTY6CiAgICAg ICAgY2FzZSB4bXNzbXQtc2hhMl80MC8yXzI1NjoKICAgICAgICBjYXNlIHhtc3NtdC1zaGEy XzQwLzRfMjU2OgogICAgICAgIGNhc2UgeG1zc210LXNoYTJfNDAvOF8yNTY6CiAgICAgICAg Y2FzZSB4bXNzbXQtc2hhMl82MC8zXzI1NjoKICAgICAgICBjYXNlIHhtc3NtdC1zaGEyXzYw LzZfMjU2OgogICAgICAgIGNhc2UgeG1zc210LXNoYTJfNjAvMTJfMjU2OgogICAgICAgIGNh c2UgeG1zc210LXNoYWtlXzIwLzJfMjU2OgogICAgICAgIGNhc2UgeG1zc210LXNoYWtlXzIw LzRfMjU2OgogICAgICAgIGNhc2UgeG1zc210LXNoYWtlXzQwLzJfMjU2OgogICAgICAgIGNh c2UgeG1zc210LXNoYWtlXzQwLzRfMjU2OgogICAgICAgIGNhc2UgeG1zc210LXNoYWtlXzQw LzhfMjU2OgogICAgICAgIGNhc2UgeG1zc210LXNoYWtlXzYwLzNfMjU2OgogICAgICAgIGNh c2UgeG1zc210LXNoYWtlXzYwLzZfMjU2OgogICAgICAgIGNhc2UgeG1zc210LXNoYWtlXzYw LzEyXzI1NjoKICAgICAgICAgIGJ5dGVzdHJpbmczMiByYW5kX24zMjsKCiAgICAgICAgY2Fz ZSB4bXNzbXQtc2hhMl8yMC8yXzUxMjoKICAgICAgICBjYXNlIHhtc3NtdC1zaGEyXzIwLzRf NTEyOgogICAgICAgIGNhc2UgeG1zc210LXNoYTJfNDAvMl81MTI6CiAgICAgICAgY2FzZSB4 bXNzbXQtc2hhMl80MC80XzUxMjoKICAgICAgICBjYXNlIHhtc3NtdC1zaGEyXzQwLzhfNTEy OgogICAgICAgIGNhc2UgeG1zc210LXNoYTJfNjAvM181MTI6CiAgICAgICAgY2FzZSB4bXNz bXQtc2hhMl82MC82XzUxMjoKICAgICAgICBjYXNlIHhtc3NtdC1zaGEyXzYwLzEyXzUxMjoK ICAgICAgICBjYXNlIHhtc3NtdC1zaGFrZV8yMC8yXzUxMjoKICAgICAgICBjYXNlIHhtc3Nt dC1zaGFrZV8yMC80XzUxMjoKICAgICAgICBjYXNlIHhtc3NtdC1zaGFrZV80MC8yXzUxMjoK ICAgICAgICBjYXNlIHhtc3NtdC1zaGFrZV80MC80XzUxMjoKICAgICAgICBjYXNlIHhtc3Nt dC1zaGFrZV80MC84XzUxMjoKICAgICAgICBjYXNlIHhtc3NtdC1zaGFrZV82MC8zXzUxMjoK ICAgICAgICBjYXNlIHhtc3NtdC1zaGFrZV82MC82XzUxMjoKCgoKSHVlbHNpbmcsIGV0IGFs LiAgICAgICAgRXhwaXJlcyBKYW51YXJ5IDI1LCAyMDE4ICAgICAgICAgICAgICAgW1BhZ2Ug NjZdCgwKSW50ZXJuZXQtRHJhZnQgICAgWE1TUzogRXh0ZW5kZWQgSGFzaC1CYXNlZCBTaWdu YXR1cmVzICAgICAgICAgSnVseSAyMDE3CgoKICAgICAgICBjYXNlIHhtc3NtdC1zaGFrZV82 MC8xMl81MTI6CiAgICAgICAgICBieXRlc3RyaW5nNjQgcmFuZF9uNjQ7CgogICAgICAgIGRl ZmF1bHQ6CiAgICAgICAgICB2b2lkOyAgICAgLyogZXJyb3IgY29uZGl0aW9uICovCiAgICAg IH07CgogICAgICAvKiBUeXBlIGZvciByZWR1Y2VkIFhNU1Mgc2lnbmF0dXJlcyAqLwoKICAg ICAgdW5pb24geG1zc19yZWR1Y2VkICh4bXNzX2FsZ29yaXRobV90eXBlIHR5cGUpIHsKICAg ICAgICBjYXNlIHhtc3NtdC1zaGEyXzIwLzJfMjU2OgogICAgICAgIGNhc2UgeG1zc210LXNo YTJfNDAvNF8yNTY6CiAgICAgICAgY2FzZSB4bXNzbXQtc2hhMl82MC82XzI1NjoKICAgICAg ICBjYXNlIHhtc3NtdC1zaGFrZV8yMC8yXzI1NjoKICAgICAgICBjYXNlIHhtc3NtdC1zaGFr ZV80MC80XzI1NjoKICAgICAgICBjYXNlIHhtc3NtdC1zaGFrZV82MC82XzI1NjoKICAgICAg ICAgIGJ5dGVzdHJpbmczMiB4bXNzX3JlZHVjZWRfbjMyX3Q3N1s3N107CgogICAgICAgIGNh c2UgeG1zc210LXNoYTJfMjAvNF8yNTY6CiAgICAgICAgY2FzZSB4bXNzbXQtc2hhMl80MC84 XzI1NjoKICAgICAgICBjYXNlIHhtc3NtdC1zaGEyXzYwLzEyXzI1NjoKICAgICAgICBjYXNl IHhtc3NtdC1zaGFrZV8yMC80XzI1NjoKICAgICAgICBjYXNlIHhtc3NtdC1zaGFrZV80MC84 XzI1NjoKICAgICAgICBjYXNlIHhtc3NtdC1zaGFrZV82MC8xMl8yNTY6CiAgICAgICAgICBi eXRlc3RyaW5nMzIgeG1zc19yZWR1Y2VkX24zMl90NzJbNzJdOwoKICAgICAgICBjYXNlIHht c3NtdC1zaGEyXzQwLzJfMjU2OgogICAgICAgIGNhc2UgeG1zc210LXNoYTJfNjAvM18yNTY6 CiAgICAgICAgY2FzZSB4bXNzbXQtc2hha2VfNDAvMl8yNTY6CiAgICAgICAgY2FzZSB4bXNz bXQtc2hha2VfNjAvM18yNTY6CiAgICAgICAgICBieXRlc3RyaW5nMzIgeG1zc19yZWR1Y2Vk X24zMl90ODdbODddOwoKICAgICAgICBjYXNlIHhtc3NtdC1zaGEyXzIwLzJfNTEyOgogICAg ICAgIGNhc2UgeG1zc210LXNoYTJfNDAvNF81MTI6CiAgICAgICAgY2FzZSB4bXNzbXQtc2hh Ml82MC82XzUxMjoKICAgICAgICBjYXNlIHhtc3NtdC1zaGFrZV8yMC8yXzUxMjoKICAgICAg ICBjYXNlIHhtc3NtdC1zaGFrZV80MC80XzUxMjoKICAgICAgICBjYXNlIHhtc3NtdC1zaGFr ZV82MC82XzUxMjoKICAgICAgICAgIGJ5dGVzdHJpbmc2NCB4bXNzX3JlZHVjZWRfbjMyX3Qx NDFbMTQxXTsKCiAgICAgICAgY2FzZSB4bXNzbXQtc2hhMl8yMC80XzUxMjoKICAgICAgICBj YXNlIHhtc3NtdC1zaGEyXzQwLzhfNTEyOgogICAgICAgIGNhc2UgeG1zc210LXNoYTJfNjAv MTJfNTEyOgogICAgICAgIGNhc2UgeG1zc210LXNoYWtlXzIwLzRfNTEyOgogICAgICAgIGNh c2UgeG1zc210LXNoYWtlXzQwLzhfNTEyOgogICAgICAgIGNhc2UgeG1zc210LXNoYWtlXzYw LzEyXzUxMjoKICAgICAgICAgIGJ5dGVzdHJpbmc2NCB4bXNzX3JlZHVjZWRfbjMyX3QxMzZb MTM2XTsKCgoKCkh1ZWxzaW5nLCBldCBhbC4gICAgICAgIEV4cGlyZXMgSmFudWFyeSAyNSwg MjAxOCAgICAgICAgICAgICAgIFtQYWdlIDY3XQoMCkludGVybmV0LURyYWZ0ICAgIFhNU1M6 IEV4dGVuZGVkIEhhc2gtQmFzZWQgU2lnbmF0dXJlcyAgICAgICAgIEp1bHkgMjAxNwoKCiAg ICAgICAgY2FzZSB4bXNzbXQtc2hhMl80MC8yXzUxMjoKICAgICAgICBjYXNlIHhtc3NtdC1z aGEyXzYwLzNfNTEyOgogICAgICAgIGNhc2UgeG1zc210LXNoYWtlXzQwLzJfNTEyOgogICAg ICAgIGNhc2UgeG1zc210LXNoYWtlXzYwLzNfNTEyOgogICAgICAgICAgYnl0ZXN0cmluZzY0 IHhtc3NfcmVkdWNlZF9uMzJfdDE1MVsxNTFdOwoKICAgICAgICBkZWZhdWx0OgogICAgICAg ICAgdm9pZDsgICAgIC8qIGVycm9yIGNvbmRpdGlvbiAqLwogICAgICB9OwoKICAgICAgLyog eG1zc19yZWR1Y2VkX2FycmF5IGRlcGVuZHMgb24gZCAqLwoKICAgICAgdW5pb24geG1zc19y ZWR1Y2VkX2FycmF5ICh4bXNzX2FsZ29yaXRobV90eXBlIHR5cGUpIHsKICAgICAgICBjYXNl IHhtc3NtdC1zaGEyXzIwLzJfMjU2OgogICAgICAgIGNhc2UgeG1zc210LXNoYTJfMjAvMl81 MTI6CiAgICAgICAgY2FzZSB4bXNzbXQtc2hhMl80MC8yXzI1NjoKICAgICAgICBjYXNlIHht c3NtdC1zaGEyXzQwLzJfNTEyOgogICAgICAgIGNhc2UgeG1zc210LXNoYWtlXzIwLzJfMjU2 OgogICAgICAgIGNhc2UgeG1zc210LXNoYWtlXzIwLzJfNTEyOgogICAgICAgIGNhc2UgeG1z c210LXNoYWtlXzQwLzJfMjU2OgogICAgICAgIGNhc2UgeG1zc210LXNoYWtlXzQwLzJfNTEy OgogICAgICAgICAgeG1zc19yZWR1Y2VkIHhtc3NfcmVkX2Fycl9kMlsyXTsKCiAgICAgICAg Y2FzZSB4bXNzbXQtc2hhMl82MC8zXzI1NjoKICAgICAgICBjYXNlIHhtc3NtdC1zaGEyXzYw LzNfNTEyOgogICAgICAgIGNhc2UgeG1zc210LXNoYWtlXzYwLzNfMjU2OgogICAgICAgIGNh c2UgeG1zc210LXNoYWtlXzYwLzNfNTEyOgogICAgICAgICAgeG1zc19yZWR1Y2VkIHhtc3Nf cmVkX2Fycl9kM1szXTsKCiAgICAgICAgY2FzZSB4bXNzbXQtc2hhMl8yMC80XzI1NjoKICAg ICAgICBjYXNlIHhtc3NtdC1zaGEyXzIwLzRfNTEyOgogICAgICAgIGNhc2UgeG1zc210LXNo YTJfNDAvNF8yNTY6CiAgICAgICAgY2FzZSB4bXNzbXQtc2hhMl80MC80XzUxMjoKICAgICAg ICBjYXNlIHhtc3NtdC1zaGFrZV8yMC80XzI1NjoKICAgICAgICBjYXNlIHhtc3NtdC1zaGFr ZV8yMC80XzUxMjoKICAgICAgICBjYXNlIHhtc3NtdC1zaGFrZV80MC80XzI1NjoKICAgICAg ICBjYXNlIHhtc3NtdC1zaGFrZV80MC80XzUxMjoKICAgICAgICAgIHhtc3NfcmVkdWNlZCB4 bXNzX3JlZF9hcnJfZDRbNF07CgogICAgICAgIGNhc2UgeG1zc210LXNoYTJfNjAvNl8yNTY6 CiAgICAgICAgY2FzZSB4bXNzbXQtc2hhMl82MC82XzUxMjoKICAgICAgICBjYXNlIHhtc3Nt dC1zaGFrZV82MC82XzI1NjoKICAgICAgICBjYXNlIHhtc3NtdC1zaGFrZV82MC82XzUxMjoK ICAgICAgICAgIHhtc3NfcmVkdWNlZCB4bXNzX3JlZF9hcnJfZDZbNl07CgogICAgICAgIGNh c2UgeG1zc210LXNoYTJfNDAvOF8yNTY6CiAgICAgICAgY2FzZSB4bXNzbXQtc2hhMl80MC84 XzUxMjoKICAgICAgICBjYXNlIHhtc3NtdC1zaGFrZV80MC84XzI1NjoKCgoKSHVlbHNpbmcs IGV0IGFsLiAgICAgICAgRXhwaXJlcyBKYW51YXJ5IDI1LCAyMDE4ICAgICAgICAgICAgICAg W1BhZ2UgNjhdCgwKSW50ZXJuZXQtRHJhZnQgICAgWE1TUzogRXh0ZW5kZWQgSGFzaC1CYXNl ZCBTaWduYXR1cmVzICAgICAgICAgSnVseSAyMDE3CgoKICAgICAgICBjYXNlIHhtc3NtdC1z aGFrZV80MC84XzUxMjoKICAgICAgICAgIHhtc3NfcmVkdWNlZCB4bXNzX3JlZF9hcnJfZDhb OF07CgogICAgICAgIGNhc2UgeG1zc210LXNoYTJfNjAvMTJfMjU2OgogICAgICAgIGNhc2Ug eG1zc210LXNoYTJfNjAvMTJfNTEyOgogICAgICAgIGNhc2UgeG1zc210LXNoYWtlXzYwLzEy XzI1NjoKICAgICAgICBjYXNlIHhtc3NtdC1zaGFrZV82MC8xMl81MTI6CiAgICAgICAgICB4 bXNzX3JlZHVjZWQgeG1zc19yZWRfYXJyX2QxMlsxMl07CgogICAgICAgIGRlZmF1bHQ6CiAg ICAgICAgICB2b2lkOyAgICAgLyogZXJyb3IgY29uZGl0aW9uICovCiAgICAgIH07CgogICAg ICAvKiBYTVNTXk1UIHNpZ25hdHVyZSBzdHJ1Y3R1cmUgKi8KCiAgICAgIHN0cnVjdCB4bXNz bXRfc2lnbmF0dXJlIHsKICAgICAgICAvKiBXT1RTKyBrZXkgcGFpciBpbmRleCAqLwogICAg ICAgIGlkeF9zaWdfeG1zc210IGlkeF9zaWc7CiAgICAgICAgLyogUmFuZG9tIHN0cmluZyBm b3IgcmFuZG9taXplZCBoYXNoaW5nICovCiAgICAgICAgcmFuZG9tX3N0cmluZ194bXNzbXQg cmFuZG9tbmVzczsKICAgICAgICAvKiBBcnJheSBvZiBkIHJlZHVjZWQgWE1TUyBzaWduYXR1 cmVzICovCiAgICAgICAgeG1zc19yZWR1Y2VkX2FycmF5OwogICAgICB9OwoKCiAgIFhNU1Ne TVQgcHVibGljIGtleXMgYXJlIGRlZmluZWQgdXNpbmcgWERSIHN5bnRheCBhcyBmb2xsb3dz OgoKCiAgICAgIC8qIFR5cGVzIGZvciBiaXRtYXNrIHNlZWQgKi8KCiAgICAgIHVuaW9uIHNl ZWQgc3dpdGNoICh4bXNzbXRfYWxnb3JpdGhtX3R5cGUgdHlwZSkgewogICAgICAgIGNhc2Ug eG1zc210LXNoYTJfMjAvMl8yNTY6CiAgICAgICAgY2FzZSB4bXNzbXQtc2hhMl80MC80XzI1 NjoKICAgICAgICBjYXNlIHhtc3NtdC1zaGEyXzYwLzZfMjU2OgogICAgICAgIGNhc2UgeG1z c210LXNoYTJfMjAvNF8yNTY6CiAgICAgICAgY2FzZSB4bXNzbXQtc2hhMl80MC84XzI1NjoK ICAgICAgICBjYXNlIHhtc3NtdC1zaGEyXzYwLzEyXzI1NjoKICAgICAgICBjYXNlIHhtc3Nt dC1zaGEyXzQwLzJfMjU2OgogICAgICAgIGNhc2UgeG1zc210LXNoYTJfNjAvM18yNTY6CiAg ICAgICAgY2FzZSB4bXNzbXQtc2hha2VfMjAvMl8yNTY6CiAgICAgICAgY2FzZSB4bXNzbXQt c2hha2VfNDAvNF8yNTY6CiAgICAgICAgY2FzZSB4bXNzbXQtc2hha2VfNjAvNl8yNTY6CiAg ICAgICAgY2FzZSB4bXNzbXQtc2hha2VfMjAvNF8yNTY6CiAgICAgICAgY2FzZSB4bXNzbXQt c2hha2VfNDAvOF8yNTY6CiAgICAgICAgY2FzZSB4bXNzbXQtc2hha2VfNjAvMTJfMjU2Ogog ICAgICAgIGNhc2UgeG1zc210LXNoYWtlXzQwLzJfMjU2OgogICAgICAgIGNhc2UgeG1zc210 LXNoYWtlXzYwLzNfMjU2OgogICAgICAgICAgYnl0ZXN0cmluZzMyIHNlZWRfbjMyOwoKCgpI dWVsc2luZywgZXQgYWwuICAgICAgICBFeHBpcmVzIEphbnVhcnkgMjUsIDIwMTggICAgICAg ICAgICAgICBbUGFnZSA2OV0KDApJbnRlcm5ldC1EcmFmdCAgICBYTVNTOiBFeHRlbmRlZCBI YXNoLUJhc2VkIFNpZ25hdHVyZXMgICAgICAgICBKdWx5IDIwMTcKCgogICAgICAgIGNhc2Ug eG1zc210LXNoYTJfMjAvMl81MTI6CiAgICAgICAgY2FzZSB4bXNzbXQtc2hhMl80MC80XzUx MjoKICAgICAgICBjYXNlIHhtc3NtdC1zaGEyXzYwLzZfNTEyOgogICAgICAgIGNhc2UgeG1z c210LXNoYTJfMjAvNF81MTI6CiAgICAgICAgY2FzZSB4bXNzbXQtc2hhMl80MC84XzUxMjoK ICAgICAgICBjYXNlIHhtc3NtdC1zaGEyXzYwLzEyXzUxMjoKICAgICAgICBjYXNlIHhtc3Nt dC1zaGEyXzQwLzJfNTEyOgogICAgICAgIGNhc2UgeG1zc210LXNoYTJfNjAvM181MTI6CiAg ICAgICAgY2FzZSB4bXNzbXQtc2hha2VfMjAvMl81MTI6CiAgICAgICAgY2FzZSB4bXNzbXQt c2hha2VfNDAvNF81MTI6CiAgICAgICAgY2FzZSB4bXNzbXQtc2hha2VfNjAvNl81MTI6CiAg ICAgICAgY2FzZSB4bXNzbXQtc2hha2VfMjAvNF81MTI6CiAgICAgICAgY2FzZSB4bXNzbXQt c2hha2VfNDAvOF81MTI6CiAgICAgICAgY2FzZSB4bXNzbXQtc2hha2VfNjAvMTJfNTEyOgog ICAgICAgIGNhc2UgeG1zc210LXNoYWtlXzQwLzJfNTEyOgogICAgICAgIGNhc2UgeG1zc210 LXNoYWtlXzYwLzNfNTEyOgogICAgICAgICAgYnl0ZXN0cmluZzY0IHNlZWRfbjY0OwoKICAg ICAgICBkZWZhdWx0OgogICAgICAgICAgdm9pZDsgICAgIC8qIGVycm9yIGNvbmRpdGlvbiAq LwogICAgICB9OwoKICAgICAgLyogVHlwZXMgZm9yIFhNU1NeTVQgcm9vdCBub2RlICovCgog ICAgICB1bmlvbiB4bXNzbXRfcm9vdCBzd2l0Y2ggKHhtc3NtdF9hbGdvcml0aG1fdHlwZSB0 eXBlKSB7CiAgICAgICAgY2FzZSB4bXNzbXQtc2hhMl8yMC8yXzI1NjoKICAgICAgICBjYXNl IHhtc3NtdC1zaGEyXzIwLzRfMjU2OgogICAgICAgIGNhc2UgeG1zc210LXNoYTJfNDAvMl8y NTY6CiAgICAgICAgY2FzZSB4bXNzbXQtc2hhMl80MC80XzI1NjoKICAgICAgICBjYXNlIHht c3NtdC1zaGEyXzQwLzhfMjU2OgogICAgICAgIGNhc2UgeG1zc210LXNoYTJfNjAvM18yNTY6 CiAgICAgICAgY2FzZSB4bXNzbXQtc2hhMl82MC82XzI1NjoKICAgICAgICBjYXNlIHhtc3Nt dC1zaGEyXzYwLzEyXzI1NjoKICAgICAgICBjYXNlIHhtc3NtdC1zaGFrZV8yMC8yXzI1NjoK ICAgICAgICBjYXNlIHhtc3NtdC1zaGFrZV8yMC80XzI1NjoKICAgICAgICBjYXNlIHhtc3Nt dC1zaGFrZV80MC8yXzI1NjoKICAgICAgICBjYXNlIHhtc3NtdC1zaGFrZV80MC80XzI1NjoK ICAgICAgICBjYXNlIHhtc3NtdC1zaGFrZV80MC84XzI1NjoKICAgICAgICBjYXNlIHhtc3Nt dC1zaGFrZV82MC8zXzI1NjoKICAgICAgICBjYXNlIHhtc3NtdC1zaGFrZV82MC82XzI1NjoK ICAgICAgICBjYXNlIHhtc3NtdC1zaGFrZV82MC8xMl8yNTY6CiAgICAgICAgICBieXRlc3Ry aW5nMzIgcm9vdF9uMzI7CgogICAgICAgIGNhc2UgeG1zc210LXNoYTJfMjAvMl81MTI6CiAg ICAgICAgY2FzZSB4bXNzbXQtc2hhMl8yMC80XzUxMjoKICAgICAgICBjYXNlIHhtc3NtdC1z aGEyXzQwLzJfNTEyOgogICAgICAgIGNhc2UgeG1zc210LXNoYTJfNDAvNF81MTI6CiAgICAg ICAgY2FzZSB4bXNzbXQtc2hhMl80MC84XzUxMjoKCgoKSHVlbHNpbmcsIGV0IGFsLiAgICAg ICAgRXhwaXJlcyBKYW51YXJ5IDI1LCAyMDE4ICAgICAgICAgICAgICAgW1BhZ2UgNzBdCgwK SW50ZXJuZXQtRHJhZnQgICAgWE1TUzogRXh0ZW5kZWQgSGFzaC1CYXNlZCBTaWduYXR1cmVz ICAgICAgICAgSnVseSAyMDE3CgoKICAgICAgICBjYXNlIHhtc3NtdC1zaGEyXzYwLzNfNTEy OgogICAgICAgIGNhc2UgeG1zc210LXNoYTJfNjAvNl81MTI6CiAgICAgICAgY2FzZSB4bXNz bXQtc2hhMl82MC8xMl81MTI6CiAgICAgICAgY2FzZSB4bXNzbXQtc2hha2VfMjAvMl81MTI6 CiAgICAgICAgY2FzZSB4bXNzbXQtc2hha2VfMjAvNF81MTI6CiAgICAgICAgY2FzZSB4bXNz bXQtc2hha2VfNDAvMl81MTI6CiAgICAgICAgY2FzZSB4bXNzbXQtc2hha2VfNDAvNF81MTI6 CiAgICAgICAgY2FzZSB4bXNzbXQtc2hha2VfNDAvOF81MTI6CiAgICAgICAgY2FzZSB4bXNz bXQtc2hha2VfNjAvM181MTI6CiAgICAgICAgY2FzZSB4bXNzbXQtc2hha2VfNjAvNl81MTI6 CiAgICAgICAgY2FzZSB4bXNzbXQtc2hha2VfNjAvMTJfNTEyOgogICAgICAgICAgYnl0ZXN0 cmluZzY0IHJvb3RfbjY0OwoKICAgICAgICBkZWZhdWx0OgogICAgICAgICAgdm9pZDsgICAg IC8qIGVycm9yIGNvbmRpdGlvbiAqLwogICAgICB9OwoKICAgICAgLyogWE1TU15NVCBwdWJs aWMga2V5IHN0cnVjdHVyZSAqLwoKICAgICAgc3RydWN0IHhtc3NtdF9wdWJsaWNfa2V5IHsK ICAgICAgICB4bXNzbXRfcm9vdCByb290OyAgLyogUm9vdCBub2RlICovCiAgICAgICAgc2Vl ZCBTRUVEOyAgLyogU2VlZCBmb3IgYml0bWFza3MgKi8KICAgICAgfTsKCgpBdXRob3JzJyBB ZGRyZXNzZXMKCiAgIEFuZHJlYXMgSHVlbHNpbmcKICAgVFUgRWluZGhvdmVuCiAgIFAuTy4g Qm94IDUxMwogICBFaW5kaG92ZW4gIDU2MDAgTUIKICAgTkwKCiAgIEVtYWlsOiBpZXRmQGh1 ZWxzaW5nLm5ldAoKCiAgIERlbmlzIEJ1dGluCiAgIFRVIERhcm1zdGFkdAogICBIb2Noc2No dWxzdHJhc3NlIDEwCiAgIERhcm1zdGFkdCAgNjQyODkKICAgREUKCiAgIEVtYWlsOiBkYnV0 aW5AY2RjLmluZm9ybWF0aWsudHUtZGFybXN0YWR0LmRlCgoKCgoKCgoKSHVlbHNpbmcsIGV0 IGFsLiAgICAgICAgRXhwaXJlcyBKYW51YXJ5IDI1LCAyMDE4ICAgICAgICAgICAgICAgW1Bh Z2UgNzFdCgwKSW50ZXJuZXQtRHJhZnQgICAgWE1TUzogRXh0ZW5kZWQgSGFzaC1CYXNlZCBT aWduYXR1cmVzICAgICAgICAgSnVseSAyMDE3CgoKICAgU3RlZmFuLUx1a2FzIEdhemRhZwog ICBnZW51YSBHbWJICiAgIERvbWFna3N0cmFzc2UgNwogICBLaXJjaGhlaW0gYmVpIE11ZW5j aGVuICA4NTU1MQogICBERQoKICAgRW1haWw6IGlldGZAZ2F6ZGFnLmRlCgoKICAgSm9vc3Qg UmlqbmV2ZWxkCiAgIFJhZGJvdWQgVW5pdmVyc2l0eQogICBUb2Vybm9vaXZlbGQgMjEyCiAg IE5pam1lZ2VuICA2NTI1IEVDCiAgIE5MCgogICBFbWFpbDogaWV0ZkBqb29zdHJpam5ldmVs ZC5ubAoKCiAgIEF6aXogTW9oYWlzZW4KICAgU1VOWSBCdWZmYWxvCiAgIDMyMyBEYXZpcyBI YWxsCiAgIEJ1ZmZhbG8sIE5ZICAxNDI2MAogICBVUwoKICAgUGhvbmU6ICsxIDcxNiA2NDUt MTU5MgogICBFbWFpbDogbW9oYWlzZW5AYnVmZmFsby5lZHUKCgoKCgoKCgoKCgoKCgoKCgoK CgoKCgoKCkh1ZWxzaW5nLCBldCBhbC4gICAgICAgIEV4cGlyZXMgSmFudWFyeSAyNSwgMjAx OCAgICAgICAgICAgICAgIFtQYWdlIDcyXQo= --------------EDA0ADC751965DA00E77AF10-- From nobody Wed Jul 26 13:57:01 2017 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 45F6E13146C for ; Wed, 26 Jul 2017 13:57:00 -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_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 N1iR4iXlA6jo for ; Wed, 26 Jul 2017 13:56:57 -0700 (PDT) Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-eopbgr10078.outbound.protection.outlook.com [40.107.1.78]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 88521129A9F for ; Wed, 26 Jul 2017 13:56:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rhul.onmicrosoft.com; s=selector1-rhul-ac-uk; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=hd/iMxrQRUEhkcAW+2MvR2ph9uL7lBVnI3wksr5Jg8U=; b=0mwSdmYdpdG1C3JCWPzKmtDiVEFqg2uKPA1HYKdDST9pWAUanNUXLXvKRIwG12VJFGiz1bkK24/dm1UK2s/LAsn/AoGpCv9W8Im6ZDpW1Li4UXAn7HdRbhrbP9EER/2Kad+B7i5uIzpr1G6NpbwOIITK/taRO7DKFJzKJ3MBn/0= Received: from AM4PR0301MB1906.eurprd03.prod.outlook.com (10.168.2.156) by AM4PR0301MB1907.eurprd03.prod.outlook.com (10.168.3.7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1282.10; Wed, 26 Jul 2017 20:56:53 +0000 Received: from AM4PR0301MB1906.eurprd03.prod.outlook.com ([fe80::e475:7abc:5c25:5e28]) by AM4PR0301MB1906.eurprd03.prod.outlook.com ([fe80::e475:7abc:5c25:5e28%14]) with mapi id 15.01.1282.021; Wed, 26 Jul 2017 20:56:52 +0000 From: "Paterson, Kenny" To: Yannick Seurin , Tetsu Iwata CC: "cfrg@ietf.org" , Adam Langley , Yehuda Lindell , Shay Gueron , Alexey Melnikov Thread-Topic: [Cfrg] Updated bounds in AES-GCM-SIV paper Thread-Index: AQHS/qHBtQ7+7q8LEkGkBdeni4MsaKJmEV+AgAClr4A= Date: Wed, 26 Jul 2017 20:56:52 +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.7.1.161129 authentication-results: spf=none (sender IP is ) smtp.mailfrom=Kenny.Paterson@rhul.ac.uk; x-originating-ip: [78.25.226.140] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM4PR0301MB1907; 7:Aw0OIEDN4FCqgCJMCy6z3iBh6Gi80VI3XmXRHEax5dM88fPxKMwGa7oWf+vV1CQg4DTqA66xM7PvhzaqlOid8FUFG22IeVsAGJjplkw6/sb+XjxiZOvt6cllh9aMUve4FHyOVcTU3yJenn4iw76v+F7XdKrJbA6wbychRJQb9Qtt9bDkVtc7l6VXPc4xfK60P0yjOvNDsf5jwr7LnoT14We3oyAqPbZAKk8lw/5t535uy72onyHxiFYo0WCgcobdMJlT06+8vYNrGq3Y8YSp0MND0QDZZfYymPayQDkq89dYtw6ZWxGFBAbbKifhqsc5fCvK3P3T2Z/2l5xlfFIEysOQ6HHsIdN3E6nXBCWvOKLRXCxAH8ki6fgzl/PRKOcPClK6xUz3D6axuQ/RA7nhr6Qf/z/2BiXvKdRd/uPKniI/jTfX+LcX/kzNxIErbyFrLefmAr86pgu8BijG5ZN8cji2YjwL5ttVGXTiA8cpDJ9NgkmzJWNKOTXt5LKCA4dPWllLYFUV8BM21vZdLjCTL+qIy/DpLbLUaJ1OlEaPd/YnGOtqrPVx8gEyjEcSbVgEenJkqcJb89tpDwzykStFhfzpAj76ROiDJbbSYSfy+YbTyB7VYlIAytP0IaeMjPU5mM3mvzf9/89DAVe6qOdY9uFx86Zo65A8/+yUnbrk/6GPxYzdAF65t6aKjeKCmkdCbIbIaRY8DjoP042n13IJAByEDguTo0rHRdYNa2EeBUa7g5iD3vr8kSem6KqT/gwtzjcCiyM7qbkzVK7FvgQe99WaplATcnaOJTpfywYzkUM= x-forefront-antispam-report: SFV:SKI; SCL:-1; SFV:NSPM; SFS:(10009020)(6009001)(39400400002)(39410400002)(39840400002)(39450400003)(39850400002)(189002)(377424004)(66654002)(199003)(24454002)(2950100002)(106356001)(36756003)(39060400002)(42882006)(54906002)(6512007)(6306002)(966005)(4001350100001)(72206003)(97736004)(2906002)(74482002)(38730400002)(68736007)(53936002)(99286003)(4326008)(105586002)(66066001)(6246003)(25786009)(83506001)(2900100001)(101416001)(3280700002)(7736002)(14454004)(189998001)(15650500001)(102836003)(6116002)(305945005)(3660700001)(5660300001)(561944003)(3846002)(50986999)(6436002)(8676002)(81166006)(81156014)(8936002)(230783001)(478600001)(5250100002)(6506006)(6486002)(76176999)(53546010)(54356999)(229853002)(86362001)(21314002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM4PR0301MB1907; H:AM4PR0301MB1906.eurprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; x-ms-office365-filtering-correlation-id: 4bc9ed72-c2db-4a68-1126-08d4d468d7de x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:AM4PR0301MB1907; x-ms-traffictypediagnostic: AM4PR0301MB1907: x-exchange-antispam-report-test: UriScan:(192374486261705); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(8121501046)(5005006)(100000703101)(100105400095)(93006095)(93001095)(10201501046)(3002001)(6041248)(201703131423075)(201702281529075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(20161123555025)(20161123562025)(20161123560025)(20161123558100)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:AM4PR0301MB1907; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:AM4PR0301MB1907; x-forefront-prvs: 038002787A received-spf: None (protection.outlook.com: rhul.ac.uk does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <6178C87165B28043A59220DE50B1DED3@eurprd03.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: rhul.ac.uk X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Jul 2017 20:56:52.8113 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2efd699a-1922-4e69-b601-108008d28a2e X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR0301MB1907 Archived-At: Subject: Re: [Cfrg] Updated bounds in AES-GCM-SIV paper X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jul 2017 20:57:00 -0000 RGVhciBUZXRzdSBhbmQgWWFubmljaywNCg0KTWFueSB0aGFua3MgZm9yIHBlcmZvcm1pbmcgdGhp cyB0aG9yb3VnaCBzZWN1cml0eSBhbmFseXNpcyBvZiBBRVMtR0NNLVNJVi4NCllvdXIgY29udHJp YnV0aW9uIHRvIHRoZSBwcm9jZXNzIGlzIGFuIGltcG9ydGFudCBhbmQgdGltZWx5IG9uZSBhcyB0 aGUNCmRvY3VtZW50IGRlc2NyaWJpbmcgdGhpcyBzY2hlbWUgcHJvZ3Jlc3NlcyB0b3dhcmRzIGl0 cyBmaW5hbCBmb3JtIGluIENGUkcuDQoNCkkgdHJ1c3QgdGhhdCB0aGUgYXV0aG9ycyBvZiBkcmFm dC1pcnRmLWNmcmctZ2Ntc2l2IHdpbGwgY2FyZWZ1bGx5IHVwZGF0ZQ0KdGhlaXIgdGV4dCBpbiB0 aGUgbGlnaHQgb2YgdGhpcyBuZXcgYW5hbHlzaXMuDQoNCkFkYW0sIFNoYXksIFllaHVkYTogY291 bGQgeW91IGFsc28gcGxlYXNlIGdpdmUgZHVlIGNvbnNpZGVyYXRpb24gdG8gVGV0c3UNCmFuZCBZ YW5uaWNrJ3MgcHJvcG9zYWwgZm9yIGFuIGFsdGVybmF0aXZlIGtleS1kZXJpdmF0aW9uIGZ1bmN0 aW9uPw0KDQpNYW55IHRoYW5rcywNCg0KS2VubnkgKGZvciB0aGUgY2hhaXJzKQ0KDQoNCk9uIDI2 LzA3LzIwMTcgMTM6MDQsICJDZnJnIG9uIGJlaGFsZiBvZiBZYW5uaWNrIFNldXJpbiINCjxjZnJn LWJvdW5jZXNAaXJ0Zi5vcmcgb24gYmVoYWxmIG9mIHlhbm5pY2suc2V1cmluQGdtYWlsLmNvbT4g d3JvdGU6DQoNCj5EZWFyIENGUkcsDQo+DQo+DQo+T3VyIHBhcGVyICJSZWNvbnNpZGVyaW5nIHRo ZSBTZWN1cml0eSBCb3VuZCBvZiBBRVMtR0NNLVNJViIsIHdoaWNoDQo+cHJvbXB0ZWQgQWRhbSdz IGVtYWlsLCBpcyBub3cgYXZhaWxhYmxlIG9uIGVQcmludDoNCj5odHRwczovL2VwcmludC5pYWNy Lm9yZy8yMDE3LzcwOA0KPg0KPg0KPlRoZSBtYWluIGNvbnRyaWJ1dGlvbiBvZiB0aGlzIHBhcGVy IGlzIGFuIGluZGVwZW5kZW50IHNlY3VyaXR5IGFuYWx5c2lzDQo+Zm9yIEFFUy1HQ00tU0lWIG1v dGl2YXRlZCBieSBzb21lIHByb2JsZW1zIHRoYXQgd2UgZGlzY292ZXJlZCBpbiB0aGUNCj5zZWN1 cml0eSBwcm9vZnMgcHJlc2VudGVkIGluIFsxXSBhbmQgWzJdLiBXZSBhbHNvIHByb3Bvc2UgYSBk aWZmZXJlbnQNCj5rZXktZGVyaXZhdGlvbiBmdW5jdGlvbiB3aXRoIHNpbWlsYXIgZWZmaWNpZW5j eQ0KPiBidXQgYmV0dGVyIHNlY3VyaXR5IHRoYW4gdGhlIG9uZSBjdXJyZW50bHkgc3BlY2lmaWVk Lg0KPg0KPg0KPkFzIGV4cGxhaW5lZCBieSBBZGFtLCB3ZSBub3RpY2VkIHRoYXQgdGhlIHNlY3Vy aXR5IGNsYWltcyBtYWRlIGluIFsyXQ0KPndlcmUgb3Zlcmx5IG9wdGltaXN0aWMgYmVjYXVzZSB0 aGUgUFJQLVBSRiBpbmRpc3Rpbmd1aXNoYWJpbGl0eSB0ZXJtIGhhZA0KPmJlZW4gbmVnbGVjdGVk LCB3aGVyZWFzIGl0IHdhcyBhY3R1YWxseSB0aGUgZG9taW5hdGluZyB0ZXJtIG9mIHRoZQ0KPnNl Y3VyaXR5IGJvdW5kLiBBcyBhIGNvbnNlcXVlbmNlLCB0aGUgc2VjdXJpdHkNCj4gZ3VhcmFudGVl cyBwcm92aWRlZCBieSBBRVMtR0NNLVNJViBtdXN0IGJlIGxvd2VyZWQgY29tcGFyZWQgd2l0aCB3 aGF0DQo+d2FzIG9yaWdpbmFsbHkgYW5ub3VuY2VkIGluIFsyXSwgZXNwZWNpYWxseSBmb3IgbG9u ZyBtZXNzYWdlcy4NCj4NCj4NCj5XZSBzdHJlc3MgdGhhdCBvdXIgcGFwZXIgaXMgYmFzZWQgb24g dmVyc2lvbiAyMDE2MDMxMDowNjM3MDEgb2YgWzFdIGFuZA0KPnZlcnNpb24gMjAxNzAyMjM6MTQw NzU5IG9mIFsyXS4gQm90aCBbMV0gYW5kIFsyXSB3ZXJlIHVwZGF0ZWQgYWZ0ZXIgd2UNCj5zZW50 IG91ciBwYXBlciB0byBBRVMtR0NNLVNJVidzIGRlc2lnbmVycyBvbiBKdWx5IDcuDQo+DQo+DQo+ V2UgYmVsaWV2ZSB0aGF0IHRoZSBDRlJHIHNwZWNpZmljYXRpb24gKGVzcGVjaWFsbHkgU2VjdGlv biA5KSBzaG91bGQgYmUNCj51cGRhdGVkIGFzIHdlbGwgdG8gcmVmbGVjdCB0aGUgbmV3IHNlY3Vy aXR5IGFuYWx5c2lzLiBSZWNvbW1lbmRlZCB1c2FnZQ0KPmxpbWl0YXRpb25zIGZvciBhbiBBRUFE IHNjaGVtZSAoc3VjaCBhcyB0aGUgbWF4aW1hbCBudW1iZXIgb2YgbWVzc2FnZXMNCj50aGF0IGNh biBiZSBlbmNyeXB0ZWQgd2l0aCB0aGUgc2FtZSBrZXkpDQo+IHNob3VsZCBiZSBiYXNlZCBvbiB0 aGUgbWF4aW1hbCBtZXNzYWdlIGxlbmd0aCBhbGxvd2VkIGJ5IGl0cw0KPnNwZWNpZmljYXRpb24g KGN1cnJlbnRseSwgMl57MzJ9IDEyOC1iaXQgYmxvY2tzKS4gTW9yZSBmaW5lLWdyYWluZWQNCj5y ZWNvbW1lbmRhdGlvbnMgKHN1Y2ggYXMgImlmIHRoZSBtYXhpbWFsIG1lc3NhZ2UgbGVuZ3RoIGlu IGFuIGFwcGxpY2F0aW9uDQo+aXMgMl5tIGFuZCB0aGUgbWF4aW1hbCBudW1iZXIgb2Ygbm9uY2Ug cmVwZXRpdGlvbnMgaXMNCj4gUiwgdGhlbiB0aGUgbWF4aW1hbCBudW1iZXIgb2YgbWVzc2FnZXMg dGhhdCBjYW4gYmUgZW5jcnlwdGVkIHdpdGggdGhlDQo+c2FtZSBrZXkgY2FuIGJlIHB1c2hlZCB0 byBYWFgiKSBhcmUgbGlrZWx5IHRvIGNyZWF0ZSBjb25mdXNpb24gYW5kIGluY3VyDQo+aW1wbGVt ZW50YXRpb25zIGVycm9ycy4gRm9yIEFFUy1HQ00tU0lWIHdpdGggcmFuZG9tbHkgZ2VuZXJhdGVk IG5vbmNlcw0KPih3aGljaCBoYXMgYmVlbiBwdXQgZm9yd2FyZCBieSB0aGUgZGVzaWduZXJzDQo+ IGFzIHRoZSBwcmVmZXJyZWQgd2F5IG9mIGdlbmVyYXRpbmcgbm9uY2VzIHdoZW4gbm8gc3RhdGUg Y2FuIGJlIHNhdmVkIGJ5DQo+ZW5jcnlwdGluZyBkZXZpY2VzKSwgdGhpcyBtZWFucyB0aGF0IG5v IG1vcmUgdGhhbiAyXnszMH0gbWVzc2FnZXMgc2hvdWxkDQo+YmUgZW5jcnlwdGVkIHdpdGggdGhl IHNhbWUga2V5LCB3aGljaCBjb250cmFzdHMgd2l0aCB0aGUgcmVjb21tZW5kZWQNCj5saW1pdCBv ZiAyXns1MH0gZ2l2ZW4gKHdpdGhvdXQgY29udGV4dCkgaW4NCj4gU2VjdGlvbiA5IG9mIHRoZSBD RlJHIHNwZWNpZmljYXRpb24gYW5kIGluIHRoZSBhYnN0cmFjdCBvZiBbMl0uDQo+DQo+DQo+Q2hl ZXJzLA0KPlRldHN1IGFuZCBZYW5uaWNrLg0KPg0KPg0KPlsxXSBodHRwczovL2VwcmludC5pYWNy Lm9yZy8yMDE1LzEwMg0KPlsyXSBodHRwczovL2VwcmludC5pYWNyLm9yZy8yMDE3LzE2OA0KPg0K PjIwMTctMDctMTcgNDowOSBHTVQrMDI6MDAgQWRhbSBMYW5nbGV5IDxhZ2xAaW1wZXJpYWx2aW9s ZXQub3JnPjoNCj4NCj5EZWFyIENGUkcsDQo+DQo+V2Ugd291bGQgbGlrZSB0byB0aGFuayBZYW5u aWNrIFNldXJpbiBhbmQgVGV0c3UgSXdhdGEgZm9yIGFsZXJ0aW5nIHVzDQo+dG8gdGhlIGZhY3Qg dGhhdCB3ZSBoYWQgZXJyb25lb3VzbHkgYXNzdW1lZCB0aGF0IG9uZSBvZiB0aGUgdGVybXMgaW4N Cj50aGUgc2VjdXJpdHkgYm91bmRzIG9mIEFFUy1HQ00tU0lWIHdhcyBuZWdsaWdpYmxlIHdoZW4s IGZvcg0KPmluZGlzdGluZ3Vpc2hhYmlsaXR5LCBpdCB3YXMgbm90LiBUaHVzLCB3aGlsZSB0aGUg c2VjdXJpdHkgcHJvb2Ygd2FzDQo+Y29ycmVjdCwgdGhlIGV4YW1wbGUgY29uY3JldGUgYm91bmRz IHdlcmUgb3ZlciBvcHRpbWlzdGljLCBtb3N0DQo+bm90YWJseSBmb3IgdmVyeSBsYXJnZSBtZXNz YWdlcy4gVGhpcyB3YXMgbW9zdCBldmlkZW50IGluIEZpZyA0Lg0KPg0KPldlIGhhdmUgdXBkYXRl ZCB0aGUgcGFwZXJbMV0gdG8gY29ycmVjdCB0aGlzIG1pc3Rha2UgYW5kIHdlIGRyYXcgdGhlDQo+ Z3JvdXAncyBhdHRlbnRpb24gdG8gdGhlIHJldmlzZWQgZmlndXJlIGZvdXIgKG5vdyBjYWxsZWQg VGFibGUgMSkuIEZvcg0KPnR5cGljYWwgdXNlcywgdGhhbmtmdWxseSwgdGhlIGRpZmZlcmVuY2Ug aXMgbm90IG1hdGVyaWFsIGJ1dCBmb3Igd2UNCj53aXNoIHRvIGhpZ2hsaWdodCB0aGF0IG9uZSBj YW5ub3QgZW5jcnlwdCBtYW55IG1lc3NhZ2VzIG9mDQo+bWFueS1naWdhYnl0ZXMgdXNpbmcgQUVT LUdDTS1TSVYsIGluIGNvbnRyYXN0IHRvIHdoYXQgdGhlIGZpZ3VyZXMNCj5wcmV2aW91c2x5IHN1 Z2dlc3RlZC4gSG93ZXZlciwgZXZlbiBpbiBzdWNoIGEgY2FzZSBvZiB2ZXJ5IGxvbmcNCj5tZXNz YWdlcywgdGhlIG92ZXJhbGwgbnVtYmVyIG9mIGJsb2NrcyBlbmNyeXB0ZWQgc2FmZWx5IGlzIHN0 aWxsDQo+c2lnbmlmaWNhbnRseSBoaWdoZXIgdGhhbiBwcmV2aW91cyBzY2hlbWVzLg0KPg0KPlsx XSBodHRwczovL2VwcmludC5pYWNyLm9yZy8yMDE3LzE2OA0KPg0KPg0KPkNoZWVycw0KPg0KPkFH TA0KPg0KPi0tDQo+QWRhbSBMYW5nbGV5IGFnbEBpbXBlcmlhbHZpb2xldC5vcmdodHRwczovL3d3 dy5pbXBlcmlhbHZpb2xldC5vcmcNCj4NCj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KPkNmcmcgbWFpbGluZyBsaXN0DQo+Q2ZyZ0BpcnRmLm9yZw0KPmh0 dHBzOi8vd3d3LmlydGYub3JnL21haWxtYW4vbGlzdGluZm8vY2ZyZw0KPg0KPg0KPg0KPg0KPg0K Pg0KDQo= From nobody Wed Jul 26 15:21:10 2017 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 F1E9212EC05; Wed, 26 Jul 2017 15:21:08 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: cfrg@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.57.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150110766894.11509.12368469438683367329@ietfa.amsl.com> Date: Wed, 26 Jul 2017 15:21:08 -0700 Archived-At: Subject: [Cfrg] I-D Action: draft-irtf-cfrg-gcmsiv-06.txt X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.22 List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jul 2017 22:21:09 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Crypto Forum RG of the IRTF. Title : AES-GCM-SIV: Nonce Misuse-Resistant Authenticated Encryption Authors : Shay Gueron Adam Langley Yehuda Lindell Filename : draft-irtf-cfrg-gcmsiv-06.txt Pages : 38 Date : 2017-07-26 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 are also htmlized versions available at: https://tools.ietf.org/html/draft-irtf-cfrg-gcmsiv-06 https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-gcmsiv-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-irtf-cfrg-gcmsiv-06 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 Wed Jul 26 15:22:12 2017 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 02057131E82 for ; Wed, 26 Jul 2017 15:22:11 -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 W7CGHOfMGb4g for ; Wed, 26 Jul 2017 15:22:08 -0700 (PDT) Received: from mail-io0-x22f.google.com (mail-io0-x22f.google.com [IPv6:2607:f8b0:4001:c06::22f]) (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 A7EB712EC05 for ; Wed, 26 Jul 2017 15:22:08 -0700 (PDT) Received: by mail-io0-x22f.google.com with SMTP id g35so40424900ioi.3 for ; Wed, 26 Jul 2017 15:22:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-transfer-encoding; bh=4BfszeuYLcJl1hco6lUcftjec0LsDK2yykXR8t3AbVU=; b=Zgg+aQyss0jHA7ZIuTQXGFUAUe3uaCGNpn0Ov0m01s0HlPqN7AyZBlKtTYbqIjJHOY nwv8TDhONekif7R0qd15uyC1pv3yiiDqKYfSC+/SSSXFhdq0rekdICJX7QWOdl3fKfMc BxsXpWUi/jWZ+tonDvJR5EFVbkDBtN8lmN+5C2TaKT4Jp3a/2WLIgzpyyIR+7f1ddQSi UbIs2JrARfmhLzwdMbTDosM/FFucxULKULSscNn8qrUoxm8tMbmp0BKk9WxRd3bMO/bE s168aH/kXPb87TD9s7E0ogIRw/5GPsT+HFUSfAmSFLUQnpmpGb4QXtHstTw7VyPzmFlQ ZQJw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc:content-transfer-encoding; bh=4BfszeuYLcJl1hco6lUcftjec0LsDK2yykXR8t3AbVU=; b=Ki6JkHE2LaMC85SMUP/Nag9dFBAk9jiI67F/FQHVRWKTZf0zdaxvoRbNQUKChdN8TG cP8F0hjF9ZlEW5UALs1M9ZlxIjq8HuLo/TE8ecl6iUoNb6LB+JiyJ7JEb8SWqOmEqrOY Zwx+jfi6znmVuCMl/cBu9ytg6FfFdHGy3ia3/RYeVU5FUSWUJl45CB8oyp1S8KTQ3F1A iHgHqoCA5DbvCvaAuqIuKsTezDBqfUu4asiyf6YXcAbbX1kywYyTf3WeE36/74Cndc+b +juVEh5ANGCFPr5gCEidDwkYjPBQkyPTIt3vtNRdlQX7YDExtImUohri6gYizdIoJvWm BBjg== X-Gm-Message-State: AIVw111rugeDKSzvN4qoueCdHqcBAca6Jy2eLjT6eWjcZcrD8Cuh2Nem yBCqXuLZg3IXdK9DI8zT1wy+kgR7Jw== X-Received: by 10.107.182.132 with SMTP id g126mr2728642iof.216.1501107727824; Wed, 26 Jul 2017 15:22:07 -0700 (PDT) MIME-Version: 1.0 Sender: alangley@gmail.com Received: by 10.79.38.216 with HTTP; Wed, 26 Jul 2017 15:22:07 -0700 (PDT) In-Reply-To: References: From: Adam Langley Date: Wed, 26 Jul 2017 15:22:07 -0700 X-Google-Sender-Auth: gNPVqrNj0iTxQwxv_u0eREQlv5Q Message-ID: To: "Paterson, Kenny" Cc: Shay Gueron , Yehuda Lindell , "cfrg@irtf.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Cfrg] Reviews of AES-GCM-SIV (draft-irtf-cfrg-gcmsiv-04.txt) X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jul 2017 22:22:11 -0000 On Wed, Jul 5, 2017 at 12:43 AM, Paterson, Kenny wrote: > Please read these reviews carefully and take them into account in the nex= t > version of your draft. It would be helpful if you could respond on list a= s > to how you have handled the various comments. Now that the IETF meeting is complete and the submission window has reopened, we've just published -06. Please see below for details on the changes. We would like to thank the reviewers for their time and attention. All three reviewers requested that pseudo-code be included in addition to the English descriptions. This has been done. Several requested clarity about whether inputs that are not a whole number of bytes are valid. We have clarified that they are not. However, the lengths in the length block are still multiplied by eight in keeping with AES-GCM. As noted in the appendix, POLYVAL and GHASH have a simple relationship and it may be useful for implementations that which to support both in minimal space to be able to exploit this. > One thing that may be problematic to an implementor was the nonces listed > in the test vectors. AES-GCM-SIV takes 12 byte nonces, the nonces listed > are 16 bytes long. While this is unlikely to be a major source of > confusion for an implementator, I suggest that the nonces be trimmed down > before publishing. This was a mistake on our part and has been corrected. > While the test vectors are quite good in general, they use only one nonce= , > and two keys (one for each key length). Eight additional test vectors have been added (for each of the 128- and 256-bit versions) that have random keys, nonces and inputs. > The bytes in the test vector are listed LSB to MSB. This rather assumes > that the implementor is using little-endian byte ordering; I would sugges= t > that this be changed to a more endian-neutral notation (possibly by just > omitted the LSB and MSB labels). The labels have been removed. > Reviewer: Tibor Jager > Section 1 "Introduction", 1st paragraph: I suggest to replace > "...that is easier for practitioners to use correctly." > with > "that is easier to use correctly." Agreed. Done. > In Section 4, first paragraph, the text suggests that plaintexts and > additional data of arbitrary length can be encrypted. However, the > description of the decryption procedure in Section 5 rejects ciphertexts > of size larger than 2^36+16 bytes, and Section 6 gives upper bounds on > the plaintext and AD sizes P_MAX and A_MAX. "arbitrary" has been replaced with "variable". > In Section 4, last paragraph, the result of encryption is the "resulting > ciphertext ... followed by the tag". Thus, in this notation, the tag is > not part of the "ciphertext", but it is separate and sent along with the > ciphertext. > However, at the beginning of Section 5, decryption algorithm receives as > input key, nonce, AD, and a ciphertext, and the ciphertext is split into > the encrypted plaintext and the tag, thus the "ciphertext" contains the > tag here. One could unify this, by always considering the tag as part of > the ciphertext. We agree that this is confusing and have changed the wording so that the "ciphertext" that results from AES-GCM-SIV always refers to the final result. > Section 8, very very nitpicking: One could mention here that the > plaintext are the bit strings corresponding to the *ASCII encoding* of > "Hello world" and "example". Done. > Section 8, 5th paragraph, again very nitpicking: Some developers may > have difficulties in understanding immediately which numbers are given > in hexadecimal notation, and which in decimal notation. For clarity, one > could write here something like: > "example": 7 characters =3D 56 bits =3D 0x38 bits > "Hello world": 11 characters =3D 88 bits =3D 0x58 bits Done. > Section 9, 7th paragraph: "Suzuki et al. [multibirthday]", the reference > lists Kazuhiro as first author, so it seems this should be Kazuhiro et al= . The authors are likely Japanese and thus typically would put their family name first. However, as best we can tell, the family name is "Suzuki" and thus it seems that the authors may have written their names in the western style for this paper. The BibTeX citation provided by Springer supports this. So we /think/ that "Suzuki et al" is correct here. > Reviewer: Bjoern Tackmann > In that description, I stumbled particularly over the =E2=80=9C_length bl= ock_=E2=80=9D - > why the underscores? The underscores are how xml2rfc was interpreting in plain text format. We agree that that's not the correct notation in that case and have changed to quotation marks. > Also, I think it would make sense to explicitly > clarify that the 32-bit counter value for the CTR part is explicitly > allowed to overflow. Done. There are also now test vectors that depend on the overflow behaviour= . > One aspect that read a bit arbitrary to me was the domain separation for > AES by setting the first bit of the last byte to 1/0, and in particular > that seemed a bit wasteful since it is evaluated only once with the bit > set to 0. Wouldn't it be simpler (and possibly even with better security, > but at the cost of limiting the length to 2^32 - 1 blocks) to not fiddle > with the bits but just use the first counter-block to compute the tag? > Note that this would certainly require re-doing some part of the security > analysis, and the gains seem moderate, so I=E2=80=99m fine with this comm= ent being > discarded. (Just wanted to make sure it is discarded consciously.) There may be a small security gain to be had by using a more subtle method for domain separation. But we believe that the benefit would be minor and the current design has the advantage the the separation is completely unambiguous. Our feeling is that the clarity here is useful, so the gain from changing is unclear and not worth redoing the proofs for. Cheers AGL From nobody Wed Jul 26 15:26:13 2017 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 4DE81131E92 for ; Wed, 26 Jul 2017 15:26:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 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, SPF_PASS=-0.001] autolearn=no 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 ZAjUwUILCbJy for ; Wed, 26 Jul 2017 15:26: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 AE319131E8F for ; Wed, 26 Jul 2017 15:26:09 -0700 (PDT) Received: by mail-io0-x231.google.com with SMTP id g13so72907292ioj.5 for ; Wed, 26 Jul 2017 15:26:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=kLcoOjvEzo7C4Lt5TcaB65/AVcWwIHj7R4wrQOlFxds=; b=lNBy5ASetdQgACJwfS6HB//2is0HkFqiscECcaFEKkjOoWDKPS9GAu7sgfcU4aPG7n XIhBVVODpdUVihEBXm0/hPLqpm0Snd4mgUoR0pVYGRLpelxIcCsjVJQFtpENgRLbwCnY YqqEMHUwdZ6JNIuqtOwdsQGOe+CoyfYYDjGM1OhM6ec2xvvIdJyiqmVFdMuhznGPXL9o 9WKWvuYo/XyEa9xSVDIJNoGMxwhk8ufw0kWace/ieG7/+araGfbACtTxPMQ0dbWVjtKl WyvZW/ruzH9UEwlh+ORMndM/evFdFqNh5SlrMSC70HFykKIICMqixvgbaL5tA2m0KtBf ngVw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=kLcoOjvEzo7C4Lt5TcaB65/AVcWwIHj7R4wrQOlFxds=; b=d2SHvUzPYNF6pT5DnDRtqjc9Cmx63JGTTObYZAiwsaAMPApPECUgsTm+2q49CgqqP1 ufcvngiCGaD//eJsJo/0L94N9Mq4sJSmq69PCxy0y2sJMjSUv37OcfcYMW9yLm8DJzvo mt7WkYmulxWzkA70EjgRbvRQOot1qFPI82ES5pKsSi1L8jSW3wcUXK7Zl+hPDGZtLn/x AD/tGENd1wgoYSok83zDqJUGB+z9a0/fj88caLon/28+Zsg5me/ZCoLoliCtIr1opATc mkD+zIGxAglPWp0US0Mf8vMK5ejxu54oBT2weGzqAUlgIJXoqkIh0VVV6zyxyGDhR3oV KQsg== X-Gm-Message-State: AIVw110zpg+0ltzvZJQZF6Hdwvh5hG0nfnggPGuBEMb7qGZjNJ29FTLB LpCTJUeAYggIe1nVCvCJwYOfDNagsg== X-Received: by 10.107.157.8 with SMTP id g8mr2999688ioe.200.1501107968919; Wed, 26 Jul 2017 15:26:08 -0700 (PDT) MIME-Version: 1.0 Sender: alangley@gmail.com Received: by 10.79.38.216 with HTTP; Wed, 26 Jul 2017 15:26:08 -0700 (PDT) In-Reply-To: References: From: Adam Langley Date: Wed, 26 Jul 2017 15:26:08 -0700 X-Google-Sender-Auth: j0xIBh_SpRK6xLdTSV6THJzBJBI Message-ID: To: Yannick Seurin Cc: cfrg@ietf.org, Tetsu Iwata Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Cfrg] Updated bounds in AES-GCM-SIV paper X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jul 2017 22:26:11 -0000 On Wed, Jul 26, 2017 at 5:04 AM, Yannick Seurin wrote: > We believe that the CFRG specification (especially Section 9) should be > updated as well to reflect the new security analysis. Recommended usage > limitations for an AEAD scheme (such as the maximal number of messages that > can be encrypted with the same key) should be based on the maximal message > length allowed by its specification (currently, 2^{32} 128-bit blocks). More > fine-grained recommendations (such as "if the maximal message length in an > application is 2^m and the maximal number of nonce repetitions is R, then > the maximal number of messages that can be encrypted with the same key can > be pushed to XXX") are likely to create confusion and incur implementations > errors. For AES-GCM-SIV with randomly generated nonces (which has been put > forward by the designers as the preferred way of generating nonces when no > state can be saved by encrypting devices), this means that no more than > 2^{30} messages should be encrypted with the same key, which contrasts with > the recommended limit of 2^{50} given (without context) in Section 9 of the > CFRG specification and in the abstract of [2]. While the maximal message length of AES-GCM-SIV is very large, we do not think it useful to limit the total number of messages based on it. Using such large messages is very rare (at best) and unwise with any AEAD: large messages pressure consumers to process plaintext before the whole message has been received and authenticated, because buffering would be so costly. We have just published -06, which contains updates in response to several reviewer's feedback and also contains updated guidance on the maximum number of messages for the case where the maximum number of nonce repeats is 256 (which covers choosing nonces randomly): 2^29 messages, where each plaintext is at most 1GiB 2^35 messages, where each plaintext is at most 128MiB 2^49 messages, where each plaintext is at most 1MiB 2^61 messages, where each plaintext is at most 16KiB Cheers AGL From nobody Wed Jul 26 15:28:42 2017 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 A0D5C12EC14 for ; Wed, 26 Jul 2017 15:28:40 -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 QrlzOkD9zJ2f for ; Wed, 26 Jul 2017 15:28:39 -0700 (PDT) Received: from mail-it0-x22c.google.com (mail-it0-x22c.google.com [IPv6:2607:f8b0:4001:c0b::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 D69A51252BA for ; Wed, 26 Jul 2017 15:28:38 -0700 (PDT) Received: by mail-it0-x22c.google.com with SMTP id v127so74991335itd.0 for ; Wed, 26 Jul 2017 15:28:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to; bh=GC/SCW8taJ7dnrLUW1b1XGERIjvOf5yUvlaIqzkIaac=; b=shw3io2JaLQlY42MhwlCWESfHJ4BnPfOjRv65+g573XefPV5oqtUE+hC0B2JbnFWWj LUAoxGa5Ba+df3JnoYy7QtD8P44jeQW6AWHY7pPJaG8EQoThZQjliP1c1aPEyczvzY/m nONVwRyxjq7ifcE1SfhIB3oQL4IQZG/T9xSQf6n79moCf036Cb+KHxkZRDk+xMFdOQLn xG4FwE48UHh//Kab1F23XJdORJBfatq/lyQZ+LsfPt1Q+4gK++tf8Nob9LbSU8Npc4gV DDm9aESX5rSdv6wJlo9ckIpn7hmBxNOfBlFXr8gnC01LMk/oHomJXbAVkZIYioOMUs8+ Xh1Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to; bh=GC/SCW8taJ7dnrLUW1b1XGERIjvOf5yUvlaIqzkIaac=; b=cRWkAljImtLzf76CIGNyHN28+XaWD/8PKvM7QLiwlY5SngjGNXBWokgHk2kVdZ8u1m uwXeJvflP1zfSOrBHdb7jL7eqLoblxhh6X6XelNMPuDHb2BfNop9l2j9rsaF1WlNSYxh qKB28fqHF13XKMmmfs0Lat3JWkpZf/o24hlM30b8lGQm0KGuefjjHl+8YtTNia37a1L7 d6bCPPg9Y/Gf2d2kGYG/EReEhDUoPy0vQJnC1mktDY5xKxqVximbvci4YHjAvmEwJgxo V9bKOSjNwzLb8mpWoUBAowq7eWpB47MjY2Yqm9puaAiRrbQbVUMUIXudx5uFfJJi2jhm DEBA== X-Gm-Message-State: AIVw110Nnpd/eEgv2xxbEhO0bMRCx3Un4PZKb0uDe8ZXnklMbe+fYDD4 HPph+zcDmHOkQa+UN3+aROd1Sz0neyoIdpQ= X-Received: by 10.36.227.130 with SMTP id d124mr2704607ith.173.1501108118068; Wed, 26 Jul 2017 15:28:38 -0700 (PDT) MIME-Version: 1.0 Sender: alangley@gmail.com Received: by 10.79.38.216 with HTTP; Wed, 26 Jul 2017 15:28:37 -0700 (PDT) In-Reply-To: <150110766894.11509.12368469438683367329@ietfa.amsl.com> References: <150110766894.11509.12368469438683367329@ietfa.amsl.com> From: Adam Langley Date: Wed, 26 Jul 2017 15:28:37 -0700 X-Google-Sender-Auth: K7F9lsmaSuf-LEJX6QeGJPiiP3Y Message-ID: To: cfrg@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Cfrg] I-D Action: draft-irtf-cfrg-gcmsiv-06.txt X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jul 2017 22:28:40 -0000 On Wed, Jul 26, 2017 at 3:21 PM, wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Crypto Forum RG of the IRTF. > > Title : AES-GCM-SIV: Nonce Misuse-Resistant Authenticated Encryption > Authors : Shay Gueron > Adam Langley > Yehuda Lindell > Filename : draft-irtf-cfrg-gcmsiv-06.txt > Pages : 38 > Date : 2017-07-26 This version contains updates in response to the CFRG reviewers' feedback, as detailed in the thread "Reviews of AES-GCM-SIV (draft-irtf-cfrg-gcmsiv-04.txt)", and also in response to the bounds issue noted in the thread "Updated bounds in AES-GCM-SIV paper". Cheers AGL From nobody Thu Jul 27 01:51:56 2017 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 BF2E0131FBF for ; Thu, 27 Jul 2017 01:51:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=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 pEC9TJPQ4orx for ; Thu, 27 Jul 2017 01:51:51 -0700 (PDT) Received: from mail-lf0-x22e.google.com (mail-lf0-x22e.google.com [IPv6:2a00:1450:4010:c07::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 09A03127136 for ; Thu, 27 Jul 2017 01:51:51 -0700 (PDT) Received: by mail-lf0-x22e.google.com with SMTP id g25so73737045lfh.1 for ; Thu, 27 Jul 2017 01:51:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=qwOrxtq/CICr1raa85Ces1FmQWjyllGldEGZGtHNTCw=; b=Yd9v6Xv7BFzBSyxUJ48uDBVA/GkK+UA4HeAdoUFY5Hb6mPUtwN7jHQJz3aZ7Pm+0WO j9+3FZKQMmosh+b3xplG5YtPmUWo7IKOzosBq4GwPn/9UAdICe9cVRQ4tY0Y7RqwBiB3 4BhXJCQuLzQK1kEgXCevI8X6Dxa4FiOqRTvCE1x8HFe+F+lneIH8It+Lt/tJA5H4Fq2P tGzvLw7rAsgnX08kbUAVdceSu1Z2VOAvyzUgjbKf2pO8BMiNqGmS9Ebdd3Yu7d1TDzYF k7y0aH9PO8oyFqT+JILqpMWhymPYtBVLiiVVU9QbltnmUd5jwIdc4xngWIOc0Bn6DC0u WcLQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=qwOrxtq/CICr1raa85Ces1FmQWjyllGldEGZGtHNTCw=; b=Xu+uYCzwbjEuCnqAUWdCChx2BPfL8W9OxdeVpDk6mafyBB84prX/r/AVoKNr7LJJPI j0uSUbn/mYx00pZd6XnZOFU+Gyg0FoIxLdd+fXb/UYTRFi5MRMT1+JzhD25byT36Hyn9 pmoYx03VXN8U3VUVE9jEP14MNE+hQaGPQqekgKXS51Wf4uMepdu0uw92pmnwb6BTRqyA Hq/pOpOZnDkBv5SX/oeUqfte8SA3+1f0OR1X2lGkbyfQinwsfDtKfqBZpeaVxTUyfo/Z AQtdHEizCEaBceTc6i5XKFz7w5GKt9bW4+PqNcqdOSp74L/a/SbUck7lvzUPn9it+pFJ WqAw== X-Gm-Message-State: AIVw113MeSkHzRKdrI0OEhsWzHBM2C2yGvJqItiGB9XwiZVI0PqZLwVv rSieLtna1JEcH8QqnY6tHkqKXydhLg== X-Received: by 10.46.84.83 with SMTP id y19mr1588622ljd.186.1501145509149; Thu, 27 Jul 2017 01:51:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.22.40 with HTTP; Thu, 27 Jul 2017 01:51:48 -0700 (PDT) In-Reply-To: References: <810C31990B57ED40B2062BA10D43FBF501B63B22@XMB116CNC.rim.net> <20170721163204.8573013.1016.15939@blackberry.com> From: Thomas Garcia Date: Thu, 27 Jul 2017 09:51:48 +0100 Message-ID: To: Sharon Goldberg Cc: Dan Brown , "jan@ns1.com" , "cfrg@irtf.org" , Dimitrios Papadopoulos , Leonid Reyzin Content-Type: multipart/alternative; boundary="f403045fc2f2d43ee0055548acd5" Archived-At: Subject: Re: [Cfrg] draft-goldbe-vrf: Verifiable Random Functions X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jul 2017 08:51:55 -0000 --f403045fc2f2d43ee0055548acd5 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks for helping me clear those things up! Thomas G. On Wed, Jul 26, 2017 at 12:42 PM, Sharon Goldberg wrote: > Hi Thomas, > > 1. It seems that one of the properties that you are interested that the >> VRF will have is determinism. On the other hand, the EC-VRF value is >> dependent on the choice of some random number k. How are these two facts >> compatible? Am I missing something? >> > > We require determinism from the VRF hash output, which is obtained from > the VRF proof via the "proof2hash" function. > > The EC-VRF proof has 3 values: gamma, c, s > Values c and s depends on the choice of random number k > But value gamma does not depend on k. > > We get determinism because the VRF hash output (derived using > "proof2hash") depends only on gamma, but not on c and s. > > Slide 28 from my CFRG presentations gives a pictorial explanation of this= : > http://www.cs.bu.edu/~goldbe/papers/VRF_ietf99_print.pdf > > 2. The value c calculated in EC-VRF is only 128 bits long for Ed25519. In >> normal usage of Ed25519 the signature uses the full length of the hash >> output. Doesn't this expose the signature to collision attacks? >> >> No. We worked this out in our proofs of security. Section B.2.1 of this > paper explains why this works. > > https://eprint.iacr.org/2017/099.pdf > > Thanks, > Sharon > > > >> Thank you for your comments. Indeed, VRFs have been around since 1999. >>> They are really "verifiable PRFs" but the name is by now standard in th= e >>> crypto literature, and changing it will cause more confusion than keepi= ng >>> it. >>> >>> In terms of the VRF's security properties, there are three: uniqueness= , >>> collision resistance, and pseudorandomness. These are defined in our dr= aft ( >>> https://tools.ietf.org/html/draft-goldbe-vrf-01#section-3). >>> >>> How VRFs prevent dictionary attacks: a public hash is subject to a >>> dictionary attack because, given the output, an adversary can evaluate = the >>> hash on different inputs and see what hits the outputs. In a VRF, the >>> adversary can't evaluate the hash on different inputs. >>> >>> You say it's not surprising that "random oracle model proof can prove >>> the output of a hash to be random". But actually, the output of a hash = is >>> NOT random if the input and the hash function are known. This is becaus= e >>> the output of a hash is deterministic (every input maps to a unique >>> output). That's exactly what enables dictionary attacks. This is in >>> contrast to a VRF, where the output is (pseudo)random even given knowle= dge >>> of the input. Only once the VRF proof is given, does the VRF output sto= p >>> looking random. Note that random oracles are not essential for VRFs, an= d >>> non-random-oracles constructions exist (but are less efficient than wha= t we >>> propose to standardize). >>> >>> As far as use cases, here are a few: >>> >>> In the NSEC5 use case for DNSSEC, you have sensitive data (domain names= ) >>> and you sign consecutive pairs of hashes of domain names in order to be >>> able to prove absence of a name. If you just use standard hashing, when= ever >>> signed hash values are disclosed, your sensitive data is subject to >>> dictionary attacks. VRFs solve that problem, and sensitive names don't = have >>> to be disclosed at all. More details are in https://eprint.iacr.org/201 >>> 7/099.pdf >>> >>> In CONIKS (also Google Key Transparency, Signal secure messaging, Yahoo= ! >>> Coname) you also have some sensitive data (user names) that are put int= o a >>> Merkle-like authenticated data structure. If you just use standard hash= ing, >>> whenever hash values are disclosed, sensitive data is subject to dictio= nary >>> attacks. If you use VRFs, sensitive data again can be disclosed only on= an >>> as-needed basis. More details are in https://eprint.iacr.org/2014/ >>> 1004.pdf. >>> >>> In a cryptocurrency use case, you wish perform a coin flip that is >>> deterministic and provably correct, but cannot be done by just anyone. >>> More details are in https://people.csail.mit.ed >>> u/nickolai/papers/gilad-algorand-eprint.pdf and possibly other >>> cryptocurrency papers. >>> >>> Bryan Ford mentioned an additional usecase at the mic on Tuesday: >>> distributed password protection protocols >>> >>> Many of these use case are already putting VRFs into production use >>> (esp. the CONIKS one). You can see a list of the various implementatio= ns >>> we have found in the "implementation status" section of our draft. One= of >>> the reasons we think this spec is so important is that we found flaws i= n >>> several of the implementations that can be used to trivially break >>> uniqueness. (See eg: https://github.com/google/ >>> keytransparency/issues/567) >>> >>> Thanks, >>> Sharon >>> >>> On Fri, Jul 21, 2017 at 7:32 PM, Dan Brown >>> wrote: >>> >>>> Answering myself below: VRFs have been around since 1999, so are not s= o >>>> new. =E2=80=8EStill don't like the name, and still have trouble seein= g the value. >>>> >>>> *From: *Dan Brown >>>> *Sent: *Tuesday, July 18, 2017 2:29 PM >>>> *To: *Sharon Goldberg; cfrg@irtf.org >>>> *Cc: *jan@ns1.com; Leonid Reyzin; Dimitrios Papadopoulos >>>> *Subject: *Re: [Cfrg] draft-goldbe-vrf: Verifiable Random Functions >>>> >>>> Hi Sharon and CFRG, >>>> >>>> >>>> >>>> On VRFs, my uncertain comments to consider at your leisure: >>>> >>>> >>>> >>>> Is it fair to say VRFs are relatively new? If so, then maybe a little >>>> more caution is needed about their use. It seems a tad hasty that it = is >>>> being used already. >>>> >>>> >>>> >>>> To me, it seems that VRFs are basically signatures, with an extra >>>> feature. My concern is that this extra feature might get overused, be= fore >>>> it is thoroughly reviewed. >>>> >>>> >>>> >>>> It is unsurprising to me that random oracle model proof can prove the >>>> output of a hash to be random. My intuitive concern is that at least >>>> informally, this is kind of circular. Hashes often have some >>>> non-random-ish properties that might affect the extra security (over >>>> signatures) that VRFs are aiming for. I guess I would much prefer a p= roof >>>> saying if the hash has (well-studied) properties XYZ, then your >>>> construction are VRFs. (Maybe you have this already? If so, then tel= l me >>>> so.) >>>> >>>> >>>> >>>> Since, VRFs require sending the =E2=80=9Cproofs=E2=80=9D on the wire, = I find it hard to >>>> see how it could be used to prevent dictionary attacks. I assume that= you >>>> are saying the proofs must be encrypted when one needs to avoid dictio= nary >>>> models? I suppose all the details are there in I-D and papers, but fo= r >>>> now, I am confused about the threat model (which parties have keys, et= c., >>>> if they require a secure channel and mutual trust, why just use plain = old >>>> hash,=E2=80=A6). To resist dictionary attacks, were already have PAKEs= and >>>> PBHashing. Now this? >>>> >>>> >>>> >>>> Finally, on a bikeshed-coloring note, I object to the name =E2=80=9Cve= rifiable >>>> random function=E2=80=9D, on several grounds. >>>> >>>> >>>> >>>> 1. It is not a function. It is at least four functions, keygen, >>>> sign, verify, and hashify. >>>> 2. If you make it into a keyed function F_sk(m), as in >>>> prooftohash(sign_sk(m)), it is not verifiable. >>>> 3. Verification requires the intermediate proof, which is certainly >>>> not even pseudorandom (it is easy to distinguish valid signatures f= rom >>>> random). >>>> 4. It is pseudorandom, not random. (The keys are random, but many >>>> crypto has keys, without having =E2=80=9Crandom=E2=80=9D in its nam= e: encryption, MAC, >>>> signatures, key exchange, =E2=80=A6, they also don=E2=80=99t verifi= able or random in their >>>> names either.) >>>> 5. The similar phrase =E2=80=9Cverifiably random=E2=80=9D, albeit a= s a misnomer, >>>> has past precedents, see NIST P-256 and Brainpool, etc. When I see= VRF, I >>>> think a function, that aims to VR in that sense, and great, now we = can >>>> improve on Brainpool, etc. >>>> 6. =E2=80=9CRandom function=E2=80=9D should be reserved for the ide= al random >>>> mapping concept, for example, as studied by Flajolet-Odlyzko (ok th= ey only >>>> studied the case of equal size domain and range). The random oracl= e model, >>>> is the idea of approximating this ideal, etc. An actual approximat= ion >>>> should not be name as the ideal (sorry, I=E2=80=99m kind of repeati= ng my point 4). >>>> >>>> >>>> >>>> Please forgive the fact that my comments above are not very >>>> constructive (or if the tone is wrong). This is a new topic for me, s= o I >>>> am reluctant too many suggestions. Nonetheless, I suggest (0) waiting= a >>>> little, (1) a non-random-oracle security proof (if you don=E2=80=99t h= ave it yet), >>>> (2) re-naming the scheme to something like re-hashable (or digestible) >>>> signatures (and re-name the various parts, i.e. proof -> signature, et= c.). >>>> >>>> >>>> >>>> Best regards, >>>> >>>> >>>> >>>> Dan >>>> >>>> >>>> >>>> >>>> >>>> *From:* Cfrg [mailto:cfrg-bounces@irtf.org] *On Behalf Of *Sharon >>>> Goldberg >>>> *Sent:* Wednesday, July 12, 2017 5:42 AM >>>> *To:* cfrg@irtf.org >>>> *Cc:* jan@ns1.com; Dimitrios Papadopoulos ; Leonid >>>> Reyzin >>>> *Subject:* [Cfrg] draft-goldbe-vrf: Verifiable Random Functions >>>> >>>> >>>> >>>> Dear CFRG, >>>> >>>> I'm presenting at next week's meeting on Verifiable Random Functions. = A >>>> VRF is the public-key version of keyed cryptographic hash. Only the ho= lder >>>> of the VRF secret key can compute the hash, but anyone with the public= key >>>> can verify it. VRFs can be used to prevent dictionary attacks on >>>> hash-based data structures, and have applications to key transparency >>>> (CONIKS), DNSSEC (NSEC5), and cryptocurrencies (Algorand). >>>> >>>> In advance of the meeting, please see: >>>> >>>> 1) Our substantially updated -01 draft: >>>> https://datatracker.ietf.org/doc/draft-goldbe-vrf/ >>>> >>>> 2) Our project page, with links to various VRF implementations: >>>> https://www.cs.bu.edu/~goldbe/projects/vrf >>>> >>>> Comments welcome. Thanks, >>>> >>>> Sharon >>>> >>>> -- >>>> Sharon Goldberg >>>> Computer Science, Boston University >>>> http://www.cs.bu.edu/~goldbe >>>> >>> >>> >>> >>> -- >>> --- >>> Sharon Goldberg >>> Computer Science, Boston University >>> http://www.cs.bu.edu/~goldbe >>> >>> _______________________________________________ >>> Cfrg mailing list >>> Cfrg@irtf.org >>> https://www.irtf.org/mailman/listinfo/cfrg >>> >>> >> > > > -- > --- > Sharon Goldberg > Computer Science, Boston University > http://www.cs.bu.edu/~goldbe > --f403045fc2f2d43ee0055548acd5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Thanks for helping me clear those thin= gs up!

Thomas G.

On Wed, Jul 26, 2017 at 12:42 PM, Sharo= n Goldberg <sharon.goldbe@gmail.com> wrote:
Hi Thomas,

1. It seems that= one of the properties that you are interested that the VRF will have is de= terminism. On the other hand, the EC-VRF value is dependent on the choice o= f some random number k. How are these two facts compatible? Am I missing so= mething?

We require dete= rminism from the VRF hash output, which is obtained from the VRF proof via = the "proof2hash" function.

The EC-VRF pr= oof has 3 values: gamma, c, s
Values c and s depends on the choic= e of random number k
But value gamma does not depend on k.
<= div>
We get determinism because the VRF hash output (derived = using "proof2hash") depends only on gamma, but not on c and s.
=C2=A0
Slide 28 from my CFRG presentations gives a pictor= ial explanation of this:

2. The value c calculated in EC-VRF is only 128 bits long for Ed25519. In = normal usage of Ed25519 the signature uses the full length of the hash outp= ut. Doesn't this expose the signature to collision attacks?
<= br>
No. We worked this out in our proof= s of security.=C2=A0 Section B.2.1 of this paper explains why this works.


Thanks,
Sharon
<= br>
=C2=A0
Thank you for your comments. Indeed, VRFs have been around= since 1999. They are really "verifiable PRFs" but the name is by= now standard in the crypto literature, and changing it will cause more con= fusion than keeping it.

In terms of the VRF's security properties, = there are three: =C2=A0uniqueness, collision resistance, and pseudorandomne= ss. These are defined in our draft (https://tools.ietf.org/html/draft-goldbe-vrf-01#section-3).=C2=A0

How VRFs pr= event dictionary attacks: a public hash is subject to a dictionary attack b= ecause, given the output, an adversary can evaluate the hash on different i= nputs and see what hits the outputs. In a VRF, the adversary can't eval= uate the hash on different inputs.=C2=A0

You say it's not surprisin= g that "random oracle model proof can prove the output of a hash to be= random". But actually, the output of a hash is NOT random if the inpu= t and the hash function are known. This is because the output of a hash is = deterministic (every input maps to a unique output). That's exactly wha= t enables dictionary attacks. This is in contrast to a VRF, where the outpu= t is (pseudo)random even given knowledge of the input. Only once the VRF pr= oof is given, does the VRF output stop looking random. Note that random ora= cles are not essential for VRFs, and non-random-oracles constructions exist= (but are less efficient than what we propose to standardize).

As far a= s use cases, here are a few:=C2=A0
In the NSEC5 use case for DNSSEC, yo= u have sensitive data (domain names) and you sign consecutive pairs of hash= es of domain names in order to be able to prove absence of a name. If you j= ust use standard hashing, whenever signed hash values are disclosed, your s= ensitive data is subject to dictionary attacks. VRFs solve that problem, an= d sensitive names don't have to be disclosed at all. More details are i= n=C2=A0h= ttps://eprint.iacr.org/2017/099.pdf

In CONIKS (also Google Key= Transparency, Signal secure messaging, Yahoo! Coname) you also have some s= ensitive data (user names) that are put into a Merkle-like authenticated da= ta structure. If you just use standard hashing, whenever hash values are di= sclosed, sensitive data is subject to dictionary attacks. If you use VRFs, = sensitive data again can be disclosed only on an as-needed basis. More deta= ils are in =C2=A0https://eprint.iacr.org/2014/1004.pdf.

In a crypto= currency use case, you wish perform a coin flip that is deterministic and p= rovably correct, but cannot be done by just anyone.=C2=A0 More details are = in=C2=A0https://people.csail.mit.edu/nickola= i/papers/gilad-algorand-eprint.pdf=C2=A0and possibly other cryptoc= urrency papers.

Bryan Ford mentioned an additional usecase at the mic= on Tuesday: distributed password protection protocols

Many of these us= e case are already putting VRFs into production use (esp. the CONIKS one).= =C2=A0 You can see a list of the various implementations we have found in t= he "implementation status" section of our draft.=C2=A0 One of the= reasons we think this spec is so important is that we found flaws in sever= al of the implementations that can be used to trivially break uniqueness. = =C2=A0(See eg:=C2=A0https://github.com/google/keytransparency/= issues/567)

Thanks,
Sharon=C2=A0

On Fri, Jul 21, 2017 at 7:32 PM, Dan Brown= <danibrown@blackberry.com> wrote:
Answering myself below: VRFs have been around since 1999, so are not so new= . =C2=A0=E2=80=8EStill don't like the name, and still have trouble seei= ng the value.

From: Dan Brown
Sent: Tuesday, July 18, 2017 2:29 PM
To: Sharon Goldberg; cfrg@irtf.org
Cc: jan@ns1.co= m; Leonid Reyzin; Dimitrios Papadopoulos
Subject: Re: [Cfrg] draft-goldbe-vrf: Verifiable Random Functio= ns

Hi Sharon and CFRG,

=C2=A0

On VRFs, my uncertain comments to consider at your leisure:

=C2=A0

Is it fair to say VRFs are relatively new?=C2=A0 If so, then mayb= e a little more caution is needed about their use.=C2=A0 It seems a tad has= ty that it is being used already.

=C2=A0

To me, it seems that VRFs are basically signatures, with an extra= feature.=C2=A0 My concern is that this extra feature might get overused, b= efore it is thoroughly reviewed.=C2=A0

=C2=A0

It is unsurprising to me that random oracle model proof can prove= the output of a hash to be random.=C2=A0 My intuitive concern is that at l= east informally, this is kind of circular.=C2=A0 Hashes often have some non-random-ish properties that might affect the ext= ra security (over signatures) that VRFs are aiming for.=C2=A0 I guess I wou= ld much prefer a proof saying if the hash has (well-studied) properties XYZ= , then your construction are VRFs.=C2=A0 (Maybe you have this already?=C2=A0 If so, then tell me so.)

=C2=A0

Since, VRFs require sending the =E2=80=9Cproofs=E2=80=9D on the w= ire, I find it hard to see how it could be used to prevent dictionary attac= ks.=C2=A0 I assume that you are saying the proofs must be encrypted when one needs to avoid dictionary models?=C2=A0 I suppose al= l the details are there in I-D and papers, but for now, I am confused about= the threat model (which parties have keys, etc., if they require a secure = channel and mutual trust, why just use plain old hash,=E2=80=A6). To resist dictionary attacks, were already have= PAKEs and PBHashing.=C2=A0 Now this?

=C2=A0

Finally, on a bikeshed-coloring note, I object to the name =E2=80= =9Cverifiable random function=E2=80=9D, on several grounds.

=C2=A0

  1. It is not a function.=C2=A0 It is at least four functions, keyg= en, sign, verify, and hashify.
  2. If you make it into a= keyed function F_sk(m), as in prooftohash(sign_sk(m)), it is not verifiabl= e.=C2=A0
  3. Verification requires the intermediate proof, which= is certainly not even pseudorandom (it is easy to distinguish valid signat= ures from random).
  4. It is pseudorandom, not random.= =C2=A0 (The keys are random, but many crypto has keys, without having =E2= =80=9Crandom=E2=80=9D in its name: encryption, MAC, signatures, key exchange, =E2=80=A6, they also don=E2=80=99t verifiable or random in t= heir names either.)
  5. The similar phrase =E2=80=9Cveri= fiably random=E2=80=9D, albeit as a misnomer, has past precedents, see NIST= P-256 and Brainpool, etc.=C2=A0 When I see VRF, I think a function, that aims to VR in that sense, and great, now we can improve o= n Brainpool, etc.
  6. =E2=80=9CRandom function=E2=80=9D = should be reserved for the ideal random mapping concept, for example, as st= udied by Flajolet-Odlyzko (ok they only studied the case of equal size domain and range).=C2=A0 The random oracle model, i= s the idea of approximating this ideal, etc.=C2=A0 An actual approximation = should not be name as the ideal (sorry, I=E2=80=99m kind of repeating my po= int 4).

=C2=A0

Please forgive the fact that my comments above are not very const= ructive (or if the tone is wrong).=C2=A0 This is a new topic for me, so I a= m reluctant too many suggestions.=C2=A0 Nonetheless, I suggest (0) waiting a little, (1) a non-random-oracle security proof (if= you don=E2=80=99t have it yet), (2) re-naming the scheme to something like= re-hashable (or digestible) signatures (and re-name the various parts, i.e= . proof -> signature, etc.).

=C2=A0

Best regards,

=C2=A0

Dan

=C2=A0

=C2=A0

From: Cfrg [mailto:cfrg-bounces@irtf.org] On Behalf Of Sharon Goldberg
Sent: Wednesday, July 12, 2017 5:42 AM
To: cfrg@irtf.org=
Cc: jan@ns1.com= ; Dimitrios Papadopoulos <dipapado@umd.edu>; Leonid Reyzin <reyzin@cs.bu.edu>
Subject: [Cfrg] draft-goldbe-vrf: Verifiable Random Functions=

=C2=A0

Dear CFRG,

I'm presenting at next week's meeting on Verifiable Random Function= s. A VRF is the public-key version of keyed cryptographic hash. Only the ho= lder of the VRF secret key can compute the hash, but anyone with the public= key can verify it.=C2=A0 VRFs can be used to prevent dictionary attacks on hash-based data structures, and have applica= tions to key transparency (CONIKS), DNSSEC (NSEC5), and cryptocurrencies (A= lgorand).

In advance of the meeting, please see:

1) Our substantially updated -01 draft:
https://datatracker.ietf.org/doc/draft-goldbe-vrf/

2) Our project page, with links to various VRF implementations:
ht= tps://www.cs.bu.edu/~goldbe/projects/vrf

Comments welcome.=C2=A0 Thanks,

Sharon

--
Sharon Goldberg
Computer Science, Boston University
http://www.cs.bu= .edu/~goldbe




--
=
---
Sharon Goldberg=
Computer Science, Boston University
http://www.cs.bu.edu/~goldbe

_______________= ________________________________
Cfrg mailing list
Cfrg@irtf.org
https://www.irtf.org/mailman/listinfo/cfrg





--
= ---
Sharon Goldberg
Computer Science, Boston University
http://www.cs.bu.edu/~gold= be

--f403045fc2f2d43ee0055548acd5-- From nobody Thu Jul 27 07:43:45 2017 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 BC0CF1200C5 for ; Thu, 27 Jul 2017 07:43:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.809 X-Spam-Level: X-Spam-Status: No, score=0.809 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FORGED_MUA_MOZILLA=2.309, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, FREEMAIL_REPLYTO_END_DIGIT=0.25, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.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 BYeoluUchfar for ; Thu, 27 Jul 2017 07:43:43 -0700 (PDT) Received: from sonic309-47.consmr.mail.gq1.yahoo.com (sonic309-47.consmr.mail.gq1.yahoo.com [98.137.65.173]) (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 E997D1317CC for ; Thu, 27 Jul 2017 07:43:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1501166622; bh=xyxh6/CwsHUAW0NlKH8wbyw1htULd9dthy1TVB9A83I=; h=Date:From:Reply-To:To:Cc:Subject:References:From:Subject; b=BmKNnKaU+4VGmj0b1zEVfwTmS8AQumATqbhRqiiHnoa1w8nHy8ZvAhXGsRHTRJBkzF3Y8Xvqt94JqhY6Tjd3ZGMTDzv0AoTBH98PwXklZe+4qEvGJNe53qOplHPqKsolHcFHgf2A+zDvh2AdR4NXYwBa3LkXS350zCuIz1yzHQlmtsMmpwVfaSadzVzd8fc5So1GSnLuImQasIIvTHOyTq7j+rK2zAUQt6S14v4QyeNfOpLbx504RaJKR1bm0rm3zpwRzQayuiLr1BK7lklTj9xCzPQTPOHA6IeoVZPOFknXlFBn3PNSe29fC50qoRQu+SkN9WkPm++Vsc6UQc1tfw== X-YMail-OSG: 7pFz9g4VM1n8xRMsit.X1268zRG5MlyjrRr9JwXnXwvcJWIrEgmYTvOYFHVUUic uGUyV.rm7RmBpccABI_LA1CfkxRA7QpTMAPVNglaWBG956n4rjhzakksotgS5Ml5RINZVErHNd5Q 6XxiKs2HFX9uTFhO.XKU7OYdEtbL3w6MHfaLgGWja499RcnpXoYST.cd5hD3ZmQx3pk3fMsgUWK2 iDWZLpWzpWXN_4opC1A7Z8UmbwW7bzSqBWJtu_3a6eicCq_IpCeCZ0bT1AIu9NGhRbwVOYp16Aar KE56_wnSRiVpvdhIwVz_Uv8IkF2iHMJ_0HdY8QprDVJAod67prMs6cF0XHitak27gEFr9enuHdCg fhjwBQ_U5spLMgEB9IWEHIQQTopD9Jp1oXNqyuwxvohCICTKrSXUBeyLm1Cb3RyRAg8T22gcMGLL ofSH03Y5LIs.z585.RDVHaI0P.1w1EROcF4.DiRq5bShYxB0w84Cy3S7kwy4OXMLjXkKGf70_MFV T4gO2rNO0iEavXQEt5qpGLCChi9M7GxM5kyUL6teytjIv4GHLmQ-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic309.consmr.mail.gq1.yahoo.com with HTTP; Thu, 27 Jul 2017 14:43:42 +0000 Date: Thu, 27 Jul 2017 14:39:41 +0000 (UTC) From: Jonathan Trostle Reply-To: Jonathan Trostle To: , Yannick Seurin Cc: Tetsu Iwata , Message-ID: <428591570.717584.1501166381333@mail.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable References: <428591570.717584.1501166381333.ref@mail.yahoo.com> X-Mailer: WebService/1.1.10181 YahooMailBasic Mozilla/5.0 (Windows NT 6.1; WOW64; rv:54.0) Gecko/20100101 Firefox/54.0 Archived-At: Subject: Re: [Cfrg] Updated bounds in AES-GCM-SIV paper X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jul 2017 14:43:45 -0000 [2] incorrectly states that the only fully nonce misuse-resistant AE scheme= s submitted to Caesar were Julius, AEZ, and HS1-SIV. CMCC is also fully non= ce misuse-resistant. Jonathan -------------------------------------------- On Wed, 7/26/17, Yannick Seurin wrote: Subject: Re: [Cfrg] Updated bounds in AES-GCM-SIV paper To: cfrg@ietf.org Cc: "Tetsu Iwata" Date: Wednesday, July 26, 2017, 5:04 AM =20 Dear CFRG, Our paper "Reconsidering the Security Bound of AES-GCM-SIV", which prompted Adam's email, is now available on ePrint:https://eprint.iacr.org/2017/ 708 The main contribution of this paper is an independent security analysis for AES-GCM-SIV motivated by some problems that we discovered in the security proofs presented in [1] and [2]. We also propose a different key-derivation function with similar efficiency but better security than the one currently specified.=C2=A0 As explained by Adam, we noticed that the security claims made in [2] were overly optimistic because the PRP-PRF indistinguishability term had been neglected, whereas it was actually the dominating term of the security bound. As a consequence, the security guarantees provided by AES-GCM-SIV must be lowered compared with what was originally announced in [2], especially for long messages. We stress that our paper is based on version 20160310:063701 of [1] and version 20170223:140759 of [2]. Both [1] and [2] were updated after we sent our paper to AES-GCM-SIV's designers on July 7. We believe that the CFRG specification (especially Section 9) should be updated as well to reflect the new security analysis. Recommended usage limitations for an AEAD scheme (such as the maximal number of messages that can be encrypted with the same key) should be based on the maximal message length allowed by its specification (currently, 2^{32} 128-bit blocks). More fine-grained recommendations (such as "if the maximal message length in an application is 2^m and the maximal number of nonce repetitions is R, then the maximal number of messages that can be encrypted with the same key can be pushed to XXX") are likely to create confusion and incur implementations errors. For AES-GCM-SIV with randomly generated nonces (which has been put forward by the designers as the preferred way of generating nonces when no state can be saved by encrypting devices), this means that no more than 2^{30} messages should be encrypted with the same key, which contrasts with the recommended limit of 2^{50} given (without context) in Section 9 of the CFRG specification and in the abstract of [2]. Cheers,Tetsu and Yannick. [1] https://eprint.iacr.org/2015/ 102[2] https://eprint.iacr.org/2017/ 168 2017-07-17 4:09 GMT+02:00 Adam Langley : Dear CFRG, =20 =20 =20 We would like to thank Yannick Seurin and Tetsu Iwata for alerting us =20 to the fact that we had erroneously assumed that one of the terms in =20 the security bounds of AES-GCM-SIV was negligible when, for =20 indistinguishability, it was not. Thus, while the security proof was =20 correct, the example concrete bounds were over optimistic, most =20 notably for very large messages. This was most evident in Fig 4. =20 =20 =20 We have updated the paper[1] to correct this mistake and we draw the =20 group's attention to the revised figure four (now called Table 1). For =20 typical uses, thankfully, the difference is not material but for we =20 wish to highlight that one cannot encrypt many messages of =20 many-gigabytes using AES-GCM-SIV, in contrast to what the figures =20 previously suggested. However, even in such a case of very long =20 messages, the overall number of blocks encrypted safely is still =20 significantly higher than previous schemes. =20 =20 =20 [1] https://eprint.iacr.org/2017/1 68 =20 =20 =20 =20 =20 Cheers =20 =20 =20 AGL =20 =20 =20 -- =20 Adam Langley agl@imperialviolet.org https://www.imperialviolet.org =20 =20 =20 ______________________________ _________________ =20 Cfrg mailing list =20 Cfrg@irtf.org =20 https://www.irtf.org/mailman/l istinfo/cfrg =20 =20 _______________________________________________ Cfrg mailing list Cfrg@irtf.org https://www.irtf.org/mailman/listinfo/cfrg =20 -----Inline Attachment Follows----- =20 =20 From nobody Sun Jul 30 10:02:47 2017 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 D1FD5129AB2 for ; Sun, 30 Jul 2017 10:02:44 -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 0ouZpt2fv4BO for ; Sun, 30 Jul 2017 10:02:42 -0700 (PDT) Received: from mail-yw0-x230.google.com (mail-yw0-x230.google.com [IPv6:2607:f8b0:4002:c05::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 CE60B1200C5 for ; Sun, 30 Jul 2017 10:02:41 -0700 (PDT) Received: by mail-yw0-x230.google.com with SMTP id u207so84284525ywc.3 for ; Sun, 30 Jul 2017 10:02:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=eU6Zbo0rsgWt09yie6qxkdXrZSD7fZ7hNFJgYSAOC24=; b=CBgcPlLp+OO1ffzIyfftYbYUx3GNi5v8NbALyG91TjnMe2WpwV0+kmozjiuII+uILM uuf3VdMRN+phwQrASWkT2Z/POisnD4xCPEKqoKk1WXcus6j0YO1yUbKBFDUs/4u0rDQP OXu30rQUQz5nrBJBKnb9Fy48LZcydQY97I+03aYcEataDrluDFrho+yVxv8EYGIrUjMI HOhbIdCEL9gDxUvahc80lhdZZSn6gYoJKkE2rbFetOQg/ipzP/l/CPaNpuCQXaZbvB1i WiXIFV1kGo0PG8aMrKCaqTcTspxZyahzx2o7OpaQm4wqIHT4xdBaVtyW/IED/TJn5evb HUhw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=eU6Zbo0rsgWt09yie6qxkdXrZSD7fZ7hNFJgYSAOC24=; b=DdADwBBMYfGt8XwdREUrTm9DYJEy7nu1D9t8yLqHw7hVCQxHDVr7anGjay8iqDac6O /2hGhwx4dxUF7chlUC4VSOWLLV8vj6kgZ8IGQrKmUQlXmsDIvPKaUhurzyMJi4jhzn31 qXBCVX2Tq5G7mKsiby8LL1lxPEviet86qd5kIZn+Jv433QsLStdxZku/ILlbMSEOcwRB WBQ1PkowXapAQ6cKm9tSjoabjfymgOdvULTFhD5BxX0Bxc1KDPTZUK7PbDJ4LCuyJ8U0 DEoqQx2vcdOO1jVF0Kqowmx1yiv1T+/pGFE86KYZhKEUb/wz0a2O/PecOFkNhVvEzUGJ WMKA== X-Gm-Message-State: AIVw111RdOwWEgq18fob6NYu+Bi8BVqDeb5tfYJ1JkOXqw271GRL50fP D9xZUOQjz02ur1ZCTxaSRIBy/kljiw== X-Received: by 10.13.219.80 with SMTP id d77mr10280653ywe.2.1501434160931; Sun, 30 Jul 2017 10:02:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.53.208 with HTTP; Sun, 30 Jul 2017 10:02:20 -0700 (PDT) In-Reply-To: References: <810C31990B57ED40B2062BA10D43FBF501B63B22@XMB116CNC.rim.net> <20170721163204.8573013.1016.15939@blackberry.com> From: Philip L Date: Sun, 30 Jul 2017 13:02:20 -0400 Message-ID: To: Thomas Garcia Cc: Sharon Goldberg , "cfrg@irtf.org" , "jan@ns1.com" , Leonid Reyzin , Dimitrios Papadopoulos Content-Type: multipart/alternative; boundary="001a114fab7ed0eced05558be18f" Archived-At: Subject: Re: [Cfrg] draft-goldbe-vrf: Verifiable Random Functions X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Jul 2017 17:02:45 -0000 --001a114fab7ed0eced05558be18f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Please excuse the spam. I thought for just a moment somehow that the function was verifiably random... like one of those hard problems (for decidability?). Just a random thought... On Thu, Jul 27, 2017 at 4:51 AM, Thomas Garcia wrote: > > Thanks for helping me clear those things up! > > Thomas G. > > On Wed, Jul 26, 2017 at 12:42 PM, Sharon Goldberg > wrote: > >> Hi Thomas, >> >> 1. It seems that one of the properties that you are interested that the >>> VRF will have is determinism. On the other hand, the EC-VRF value is >>> dependent on the choice of some random number k. How are these two fact= s >>> compatible? Am I missing something? >>> >> >> We require determinism from the VRF hash output, which is obtained from >> the VRF proof via the "proof2hash" function. >> >> The EC-VRF proof has 3 values: gamma, c, s >> Values c and s depends on the choice of random number k >> But value gamma does not depend on k. >> >> We get determinism because the VRF hash output (derived using >> "proof2hash") depends only on gamma, but not on c and s. >> >> Slide 28 from my CFRG presentations gives a pictorial explanation of thi= s: >> http://www.cs.bu.edu/~goldbe/papers/VRF_ietf99_print.pdf >> >> 2. The value c calculated in EC-VRF is only 128 bits long for Ed25519. I= n >>> normal usage of Ed25519 the signature uses the full length of the hash >>> output. Doesn't this expose the signature to collision attacks? >>> >>> No. We worked this out in our proofs of security. Section B.2.1 of thi= s >> paper explains why this works. >> >> https://eprint.iacr.org/2017/099.pdf >> >> Thanks, >> Sharon >> >> >> >>> Thank you for your comments. Indeed, VRFs have been around since 1999. >>>> They are really "verifiable PRFs" but the name is by now standard in t= he >>>> crypto literature, and changing it will cause more confusion than keep= ing >>>> it. >>>> >>>> In terms of the VRF's security properties, there are three: >>>> uniqueness, collision resistance, and pseudorandomness. These are def= ined >>>> in our draft (https://tools.ietf.org/html/draft-goldbe-vrf-01#section-= 3 >>>> ). >>>> >>>> How VRFs prevent dictionary attacks: a public hash is subject to a >>>> dictionary attack because, given the output, an adversary can evaluate= the >>>> hash on different inputs and see what hits the outputs. In a VRF, the >>>> adversary can't evaluate the hash on different inputs. >>>> >>>> You say it's not surprising that "random oracle model proof can prove >>>> the output of a hash to be random". But actually, the output of a hash= is >>>> NOT random if the input and the hash function are known. This is becau= se >>>> the output of a hash is deterministic (every input maps to a unique >>>> output). That's exactly what enables dictionary attacks. This is in >>>> contrast to a VRF, where the output is (pseudo)random even given knowl= edge >>>> of the input. Only once the VRF proof is given, does the VRF output st= op >>>> looking random. Note that random oracles are not essential for VRFs, a= nd >>>> non-random-oracles constructions exist (but are less efficient than wh= at we >>>> propose to standardize). >>>> >>>> As far as use cases, here are a few: >>>> >>>> In the NSEC5 use case for DNSSEC, you have sensitive data (domain >>>> names) and you sign consecutive pairs of hashes of domain names in ord= er to >>>> be able to prove absence of a name. If you just use standard hashing, >>>> whenever signed hash values are disclosed, your sensitive data is subj= ect >>>> to dictionary attacks. VRFs solve that problem, and sensitive names do= n't >>>> have to be disclosed at all. More details are in >>>> https://eprint.iacr.org/2017/099.pdf >>>> >>>> In CONIKS (also Google Key Transparency, Signal secure messaging, >>>> Yahoo! Coname) you also have some sensitive data (user names) that are= put >>>> into a Merkle-like authenticated data structure. If you just use stand= ard >>>> hashing, whenever hash values are disclosed, sensitive data is subject= to >>>> dictionary attacks. If you use VRFs, sensitive data again can be discl= osed >>>> only on an as-needed basis. More details are in >>>> https://eprint.iacr.org/2014/1004.pdf. >>>> >>>> In a cryptocurrency use case, you wish perform a coin flip that is >>>> deterministic and provably correct, but cannot be done by just anyone. >>>> More details are in https://people.csail.mit.ed >>>> u/nickolai/papers/gilad-algorand-eprint.pdf and possibly other >>>> cryptocurrency papers. >>>> >>>> Bryan Ford mentioned an additional usecase at the mic on Tuesday: >>>> distributed password protection protocols >>>> >>>> Many of these use case are already putting VRFs into production use >>>> (esp. the CONIKS one). You can see a list of the various implementati= ons >>>> we have found in the "implementation status" section of our draft. On= e of >>>> the reasons we think this spec is so important is that we found flaws = in >>>> several of the implementations that can be used to trivially break >>>> uniqueness. (See eg: https://github.com/google/ >>>> keytransparency/issues/567) >>>> >>>> Thanks, >>>> Sharon >>>> >>>> On Fri, Jul 21, 2017 at 7:32 PM, Dan Brown >>>> wrote: >>>> >>>>> Answering myself below: VRFs have been around since 1999, so are not >>>>> so new. =E2=80=8EStill don't like the name, and still have trouble s= eeing the >>>>> value. >>>>> >>>>> *From: *Dan Brown >>>>> *Sent: *Tuesday, July 18, 2017 2:29 PM >>>>> *To: *Sharon Goldberg; cfrg@irtf.org >>>>> *Cc: *jan@ns1.com; Leonid Reyzin; Dimitrios Papadopoulos >>>>> *Subject: *Re: [Cfrg] draft-goldbe-vrf: Verifiable Random Functions >>>>> >>>>> Hi Sharon and CFRG, >>>>> >>>>> >>>>> >>>>> On VRFs, my uncertain comments to consider at your leisure: >>>>> >>>>> >>>>> >>>>> Is it fair to say VRFs are relatively new? If so, then maybe a littl= e >>>>> more caution is needed about their use. It seems a tad hasty that it= is >>>>> being used already. >>>>> >>>>> >>>>> >>>>> To me, it seems that VRFs are basically signatures, with an extra >>>>> feature. My concern is that this extra feature might get overused, b= efore >>>>> it is thoroughly reviewed. >>>>> >>>>> >>>>> >>>>> It is unsurprising to me that random oracle model proof can prove the >>>>> output of a hash to be random. My intuitive concern is that at least >>>>> informally, this is kind of circular. Hashes often have some >>>>> non-random-ish properties that might affect the extra security (over >>>>> signatures) that VRFs are aiming for. I guess I would much prefer a = proof >>>>> saying if the hash has (well-studied) properties XYZ, then your >>>>> construction are VRFs. (Maybe you have this already? If so, then te= ll me >>>>> so.) >>>>> >>>>> >>>>> >>>>> Since, VRFs require sending the =E2=80=9Cproofs=E2=80=9D on the wire,= I find it hard >>>>> to see how it could be used to prevent dictionary attacks. I assume = that >>>>> you are saying the proofs must be encrypted when one needs to avoid >>>>> dictionary models? I suppose all the details are there in I-D and pa= pers, >>>>> but for now, I am confused about the threat model (which parties have= keys, >>>>> etc., if they require a secure channel and mutual trust, why just use= plain >>>>> old hash,=E2=80=A6). To resist dictionary attacks, were already have = PAKEs and >>>>> PBHashing. Now this? >>>>> >>>>> >>>>> >>>>> Finally, on a bikeshed-coloring note, I object to the name =E2=80=9Cv= erifiable >>>>> random function=E2=80=9D, on several grounds. >>>>> >>>>> >>>>> >>>>> 1. It is not a function. It is at least four functions, keygen, >>>>> sign, verify, and hashify. >>>>> 2. If you make it into a keyed function F_sk(m), as in >>>>> prooftohash(sign_sk(m)), it is not verifiable. >>>>> 3. Verification requires the intermediate proof, which is >>>>> certainly not even pseudorandom (it is easy to distinguish valid s= ignatures >>>>> from random). >>>>> 4. It is pseudorandom, not random. (The keys are random, but many >>>>> crypto has keys, without having =E2=80=9Crandom=E2=80=9D in its na= me: encryption, MAC, >>>>> signatures, key exchange, =E2=80=A6, they also don=E2=80=99t verif= iable or random in their >>>>> names either.) >>>>> 5. The similar phrase =E2=80=9Cverifiably random=E2=80=9D, albeit = as a misnomer, >>>>> has past precedents, see NIST P-256 and Brainpool, etc. When I se= e VRF, I >>>>> think a function, that aims to VR in that sense, and great, now we= can >>>>> improve on Brainpool, etc. >>>>> 6. =E2=80=9CRandom function=E2=80=9D should be reserved for the id= eal random >>>>> mapping concept, for example, as studied by Flajolet-Odlyzko (ok t= hey only >>>>> studied the case of equal size domain and range). The random orac= le model, >>>>> is the idea of approximating this ideal, etc. An actual approxima= tion >>>>> should not be name as the ideal (sorry, I=E2=80=99m kind of repeat= ing my point 4). >>>>> >>>>> >>>>> >>>>> Please forgive the fact that my comments above are not very >>>>> constructive (or if the tone is wrong). This is a new topic for me, = so I >>>>> am reluctant too many suggestions. Nonetheless, I suggest (0) waitin= g a >>>>> little, (1) a non-random-oracle security proof (if you don=E2=80=99t = have it yet), >>>>> (2) re-naming the scheme to something like re-hashable (or digestible= ) >>>>> signatures (and re-name the various parts, i.e. proof -> signature, e= tc.). >>>>> >>>>> >>>>> >>>>> Best regards, >>>>> >>>>> >>>>> >>>>> Dan >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> *From:* Cfrg [mailto:cfrg-bounces@irtf.org] *On Behalf Of *Sharon >>>>> Goldberg >>>>> *Sent:* Wednesday, July 12, 2017 5:42 AM >>>>> *To:* cfrg@irtf.org >>>>> *Cc:* jan@ns1.com; Dimitrios Papadopoulos ; Leonid >>>>> Reyzin >>>>> *Subject:* [Cfrg] draft-goldbe-vrf: Verifiable Random Functions >>>>> >>>>> >>>>> >>>>> Dear CFRG, >>>>> >>>>> I'm presenting at next week's meeting on Verifiable Random Functions. >>>>> A VRF is the public-key version of keyed cryptographic hash. Only the >>>>> holder of the VRF secret key can compute the hash, but anyone with th= e >>>>> public key can verify it. VRFs can be used to prevent dictionary att= acks >>>>> on hash-based data structures, and have applications to key transpare= ncy >>>>> (CONIKS), DNSSEC (NSEC5), and cryptocurrencies (Algorand). >>>>> >>>>> In advance of the meeting, please see: >>>>> >>>>> 1) Our substantially updated -01 draft: >>>>> https://datatracker.ietf.org/doc/draft-goldbe-vrf/ >>>>> >>>>> 2) Our project page, with links to various VRF implementations: >>>>> https://www.cs.bu.edu/~goldbe/projects/vrf >>>>> >>>>> Comments welcome. Thanks, >>>>> >>>>> Sharon >>>>> >>>>> -- >>>>> Sharon Goldberg >>>>> Computer Science, Boston University >>>>> http://www.cs.bu.edu/~goldbe >>>>> >>>> >>>> >>>> >>>> -- >>>> --- >>>> Sharon Goldberg >>>> Computer Science, Boston University >>>> http://www.cs.bu.edu/~goldbe >>>> >>>> _______________________________________________ >>>> Cfrg mailing list >>>> Cfrg@irtf.org >>>> https://www.irtf.org/mailman/listinfo/cfrg >>>> >>>> >>> >> >> >> -- >> --- >> Sharon Goldberg >> Computer Science, Boston University >> http://www.cs.bu.edu/~goldbe >> > > > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > https://www.irtf.org/mailman/listinfo/cfrg > > --001a114fab7ed0eced05558be18f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Please excuse the spam. I thought for just a moment someho= w that the function was verifiably random... like one of those hard problem= s (for decidability?).

Just a random thought...

On Thu, Jul 27, 2017 at 4:5= 1 AM, Thomas Garcia <tgarcia.3141@gmail.com> wrote:
=

Thanks = for helping me clear those things up!

Thomas G.

On Wed, Jul 26, 2017 at 12:42 PM, Sharon Go= ldberg <sharon.goldbe@gmail.com> wrote:
Hi Thomas,

1. It seems that one of the pro= perties that you are interested that the VRF will have is determinism. On t= he other hand, the EC-VRF value is dependent on the choice of some random n= umber k. How are these two facts compatible? Am I missing something?
<= /div>

We require determinism from th= e VRF hash output, which is obtained from the VRF proof via the "proof= 2hash" function.

The EC-VRF proof has 3 value= s: gamma, c, s
Values c and s depends on the choice of random num= ber k
But value gamma does not depend on k.

<= div>We get determinism because the VRF hash output (derived using "pro= of2hash") depends only on gamma, but not on c and s.
=C2=A0<= /div>
Slide 28 from my CFRG presentations gives a pictorial explanation= of this:

2. The value c calculated= in EC-VRF is only 128 bits long for Ed25519. In normal usage of Ed25519 th= e signature uses the full length of the hash output. Doesn't this expos= e the signature to collision attacks?

No. We worked this out in our proofs of security.=C2=A0 Secti= on B.2.1 of this paper explains why this works.

https://ep= rint.iacr.org/2017/099.pdf

Thanks,
Sharon

<= /div>
=C2=A0
Thank you for your comments. Indeed, VRF= s have been around since 1999. They are really "verifiable PRFs" = but the name is by now standard in the crypto literature, and changing it w= ill cause more confusion than keeping it.

In terms of the VRF's sec= urity properties, there are three: =C2=A0uniqueness, collision resistance, = and pseudorandomness. These are defined in our draft (https://tools.ietf.org/html/draft-goldbe-vrf-= 01#section-3).=C2=A0

How VRFs prevent dictionary attacks: a public hash is subject to a di= ctionary attack because, given the output, an adversary can evaluate the ha= sh on different inputs and see what hits the outputs. In a VRF, the adversa= ry can't evaluate the hash on different inputs.=C2=A0

You say it&= #39;s not surprising that "random oracle model proof can prove the out= put of a hash to be random". But actually, the output of a hash is NOT= random if the input and the hash function are known. This is because the o= utput of a hash is deterministic (every input maps to a unique output). Tha= t's exactly what enables dictionary attacks. This is in contrast to a V= RF, where the output is (pseudo)random even given knowledge of the input. O= nly once the VRF proof is given, does the VRF output stop looking random. N= ote that random oracles are not essential for VRFs, and non-random-oracles = constructions exist (but are less efficient than what we propose to standar= dize).

As far as use cases, here are a few:=C2=A0

In the NSEC5 use = case for DNSSEC, you have sensitive data (domain names) and you sign consec= utive pairs of hashes of domain names in order to be able to prove absence = of a name. If you just use standard hashing, whenever signed hash values ar= e disclosed, your sensitive data is subject to dictionary attacks. VRFs sol= ve that problem, and sensitive names don't have to be disclosed at all.= More details are in=C2=A0https://eprint.iacr.org/2017/099.pdf

In CONI= KS (also Google Key Transparency, Signal secure messaging, Yahoo! Coname) y= ou also have some sensitive data (user names) that are put into a Merkle-li= ke authenticated data structure. If you just use standard hashing, whenever= hash values are disclosed, sensitive data is subject to dictionary attacks= . If you use VRFs, sensitive data again can be disclosed only on an as-need= ed basis. More details are in =C2=A0https://eprint.iacr.org/2014/1004.pdf= .

In a cryptocurrency use case, you wish perform a coin flip that is de= terministic and provably correct, but cannot be done by just anyone.=C2=A0 = More details are in=C2=A0https://people.csail.mit= .edu/nickolai/papers/gilad-algorand-eprint.pdf=C2=A0and possi= bly other cryptocurrency papers.

<= /div>
Bryan Ford mentioned an additional use= case at the mic on Tuesday: distributed password protection protocols
=

M= any of these use case are already putting VRFs into production use (esp. th= e CONIKS one).=C2=A0 You can see a list of the various implementations we h= ave found in the "implementation status" section of our draft.=C2= =A0 One of the reasons we think this spec is so important is that we found = flaws in several of the implementations that can be used to trivially break= uniqueness. =C2=A0(See eg:=C2=A0https://github.com/google/key= transparency/issues/567)

Thanks,
Sharon=C2=A0

On Fri, J= ul 21, 2017 at 7:32 PM, Dan Brown <danibrown@blackberry.com>= wrote:
Answering myself below: VRFs have been around since 1999, so are not so new= . =C2=A0=E2=80=8EStill don't like the name, and still have trouble seei= ng the value.

From: Dan Brown
Sent: Tuesday, July 18, 2017 2:29 PM
To: Sharon Goldberg; cfrg@irtf.org
Cc: jan@ns1.co= m; Leonid Reyzin; Dimitrios Papadopoulos
Subject: Re: [Cfrg] draft-goldbe-vrf: Verifiable Random Functio= ns

Hi Sharon and CFRG,

=C2=A0

On VRFs, my uncertain comments to consider at your leisure:

=C2=A0

Is it fair to say VRFs are relatively new?=C2=A0 If so, then mayb= e a little more caution is needed about their use.=C2=A0 It seems a tad has= ty that it is being used already.

=C2=A0

To me, it seems that VRFs are basically signatures, with an extra= feature.=C2=A0 My concern is that this extra feature might get overused, b= efore it is thoroughly reviewed.=C2=A0

=C2=A0

It is unsurprising to me that random oracle model proof can prove= the output of a hash to be random.=C2=A0 My intuitive concern is that at l= east informally, this is kind of circular.=C2=A0 Hashes often have some non-random-ish properties that might affect the ext= ra security (over signatures) that VRFs are aiming for.=C2=A0 I guess I wou= ld much prefer a proof saying if the hash has (well-studied) properties XYZ= , then your construction are VRFs.=C2=A0 (Maybe you have this already?=C2=A0 If so, then tell me so.)

=C2=A0

Since, VRFs require sending the =E2=80=9Cproofs=E2=80=9D on the w= ire, I find it hard to see how it could be used to prevent dictionary attac= ks.=C2=A0 I assume that you are saying the proofs must be encrypted when one needs to avoid dictionary models?=C2=A0 I suppose al= l the details are there in I-D and papers, but for now, I am confused about= the threat model (which parties have keys, etc., if they require a secure = channel and mutual trust, why just use plain old hash,=E2=80=A6). To resist dictionary attacks, were already have= PAKEs and PBHashing.=C2=A0 Now this?

=C2=A0

Finally, on a bikeshed-coloring note, I object to the name =E2=80= =9Cverifiable random function=E2=80=9D, on several grounds.

=C2=A0

  1. It is not a function.=C2=A0 It is at leas= t four functions, keygen, sign, verify, and hashify.
  2. If you make it into a keyed function F_sk(m), as i= n prooftohash(sign_sk(m)), it is not verifiable.=C2=A0
  3. Verification requires the int= ermediate proof, which is certainly not even pseudorandom (it is easy to di= stinguish valid signatures from random).
  4. It is pseudorandom, not random.=C2=A0 (The keys are random, but = many crypto has keys, without having =E2=80=9Crandom=E2=80=9D in its name: = encryption, MAC, signatures, key exchange, =E2=80=A6, they also don=E2=80=99t verifiable or random in t= heir names either.)
  5. The simila= r phrase =E2=80=9Cverifiably random=E2=80=9D, albeit as a misnomer, has pas= t precedents, see NIST P-256 and Brainpool, etc.=C2=A0 When I see VRF, I th= ink a function, that aims to VR in that sense, and great, now we can improve o= n Brainpool, etc.
  6. =E2=80=9CRan= dom function=E2=80=9D should be reserved for the ideal random mapping conce= pt, for example, as studied by Flajolet-Odlyzko (ok they only studied the case of equal size domain and range).=C2=A0 The random oracle model, i= s the idea of approximating this ideal, etc.=C2=A0 An actual approximation = should not be name as the ideal (sorry, I=E2=80=99m kind of repeating my po= int 4).

=C2=A0

Please forgive the fact that my comments above are not very const= ructive (or if the tone is wrong).=C2=A0 This is a new topic for me, so I a= m reluctant too many suggestions.=C2=A0 Nonetheless, I suggest (0) waiting a little, (1) a non-random-oracle security proof (if= you don=E2=80=99t have it yet), (2) re-naming the scheme to something like= re-hashable (or digestible) signatures (and re-name the various parts, i.e= . proof -> signature, etc.).

=C2=A0

Best regards,

=C2=A0

Dan

=C2=A0

=C2=A0

From: Cfrg [mailto:cfrg-bounces@irtf.org] On Behalf Of Sharon Goldberg
Sent: Wednesday, July 12, 2017 5:42 AM
To: cfrg@irtf.org=
Cc: jan@ns1.com= ; Dimitrios Papadopoulos <dipapado@umd.edu>; Leonid Reyzin <reyzin@cs.bu.edu>
Subject: [Cfrg] draft-goldbe-vrf: Verifiable Random Functions=

=C2=A0

Dear CFRG,

I'm presenting at next week's meeting on Verifiable Random Function= s. A VRF is the public-key version of keyed cryptographic hash. Only the ho= lder of the VRF secret key can compute the hash, but anyone with the public= key can verify it.=C2=A0 VRFs can be used to prevent dictionary attacks on hash-based data structures, and have applica= tions to key transparency (CONIKS), DNSSEC (NSEC5), and cryptocurrencies (A= lgorand).

In advance of the meeting, please see:

1) Our substantially updated -01 draft:
https://datatracker.ietf.org/doc/draft-goldbe-vrf/

2) Our project page, with links to various VRF implementations:
ht= tps://www.cs.bu.edu/~goldbe/projects/vrf

Comments welcome.=C2=A0 Thanks,

Sharon

--
Sharon Goldberg
Computer Science, Boston University
http://www.cs.bu= .edu/~goldbe




--
=
---
Sharon Goldberg
Computer Science, Boston University
http://www.cs.bu.edu/~gold= be

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





--
---
Sharon Goldberg
Compu= ter Science, Boston University
http://www.cs.bu.edu/~goldbe


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


--001a114fab7ed0eced05558be18f-- From nobody Mon Jul 31 02:04:57 2017 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 23E7E129AD3 for ; Mon, 31 Jul 2017 02:04:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 u_hjDZ5kEHfh for ; Mon, 31 Jul 2017 02:04:51 -0700 (PDT) Received: from mail-io0-x230.google.com (mail-io0-x230.google.com [IPv6:2607:f8b0:4001:c06::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 A9185131F6A for ; Mon, 31 Jul 2017 02:04:51 -0700 (PDT) Received: by mail-io0-x230.google.com with SMTP id g35so75932059ioi.3 for ; Mon, 31 Jul 2017 02:04:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=xToRZDDGXz4e98F4Iwb4Z21cTP7o/2592zg9utqxr48=; b=mXBzxLPXHLCnqeIcm7X/KpEH+xjdFXzekjz1m7J5id3lXlLmhgPhoEdL/qSb5b3QXh XoXl9oiFdYqOczzLc8QmKv2/u4Y4SVmMkdoM3Bq2bvtiWe/5JjAba5aUHSGNT3Vgtg9X AhlmqPYkv8/qsBhXghckDwi/MipPPbT6LaRXknIdryOPDKom1cuwOMG2WKA24huUoCn7 ue4a4NJrnTnv2KC4dCzyJr4M/FHFYF6Dfpea1aO/WT1VWgKVG8+YtEzBd/flTi+GBKQn z1Xr7Kq7rIHfm5EA84SVNQtO8kTqkiJ2igrHObQMQdfvjf+iYWpZ79rd2OE40URL3d3s EHNQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=xToRZDDGXz4e98F4Iwb4Z21cTP7o/2592zg9utqxr48=; b=rLFCeKBXlePRE6y2PvY8PZq3voTHXZHfDcOgkw0INyeGoYUfS6vyDzlSCYglU0WscH E9+/BSWKkTXQEnzPmbTIiIsSx/2TsMkxZte61muuoK/8zpeACCKie1klmUKj8oQQD+fa RqCp9qflag0FgIkA3jOF/RhEpJtYi7NHH9y9/vs9cWmFGSDe7wErMsPw2+Se55KZ3n0a wNLbQKOhbv81oFtK0ctDnZjyDifzBwROaBU8fe7tN/+lb4X7M2SWv6T9L1uBROLgZq5p VkNwJXkw1vwRQqWHOM1EqXFc8GEw/js49pwIQpqaydnRw3hBdl/Lw4NVEurM7DBTQPRB 1VrA== X-Gm-Message-State: AIVw1108KfMKMMACDyY1lE081ctewsXHDv2zQ4QkoWY2qTioo94shl6z PlzipP7nqHMxpsTSL6RBXI8UIEnlEQ== X-Received: by 10.107.147.66 with SMTP id v63mr18692320iod.126.1501491890929; Mon, 31 Jul 2017 02:04:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.39.83 with HTTP; Mon, 31 Jul 2017 02:04:10 -0700 (PDT) In-Reply-To: References: <810C31990B57ED40B2062BA10D43FBF501B63B22@XMB116CNC.rim.net> <20170721163204.8573013.1016.15939@blackberry.com> From: Sharon Goldberg Date: Mon, 31 Jul 2017 12:04:10 +0300 Message-ID: To: Philip L Cc: Thomas Garcia , "cfrg@irtf.org" , "jan@ns1.com" , Leonid Reyzin , Dimitrios Papadopoulos Content-Type: multipart/alternative; boundary="001a1148e222cad5c105559952ab" Archived-At: Subject: Re: [Cfrg] draft-goldbe-vrf: Verifiable Random Functions X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jul 2017 09:04:55 -0000 --001a1148e222cad5c105559952ab Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable It is "verifiable pseudorandomness". (Not true randomness.) Think of a pseudorandom function (PRF) that comes with a public key that allows anyone to check that the output of the PRF was computed correctly. Sharon On Sun, Jul 30, 2017 at 8:02 PM, Philip L wrote: > Please excuse the spam. I thought for just a moment somehow that the > function was verifiably random... like one of those hard problems (for > decidability?). > > Just a random thought... > > On Thu, Jul 27, 2017 at 4:51 AM, Thomas Garcia > wrote: > >> >> Thanks for helping me clear those things up! >> >> Thomas G. >> >> On Wed, Jul 26, 2017 at 12:42 PM, Sharon Goldberg < >> sharon.goldbe@gmail.com> wrote: >> >>> Hi Thomas, >>> >>> 1. It seems that one of the properties that you are interested that the >>>> VRF will have is determinism. On the other hand, the EC-VRF value is >>>> dependent on the choice of some random number k. How are these two fac= ts >>>> compatible? Am I missing something? >>>> >>> >>> We require determinism from the VRF hash output, which is obtained from >>> the VRF proof via the "proof2hash" function. >>> >>> The EC-VRF proof has 3 values: gamma, c, s >>> Values c and s depends on the choice of random number k >>> But value gamma does not depend on k. >>> >>> We get determinism because the VRF hash output (derived using >>> "proof2hash") depends only on gamma, but not on c and s. >>> >>> Slide 28 from my CFRG presentations gives a pictorial explanation of >>> this: >>> http://www.cs.bu.edu/~goldbe/papers/VRF_ietf99_print.pdf >>> >>> 2. The value c calculated in EC-VRF is only 128 bits long for Ed25519. >>>> In normal usage of Ed25519 the signature uses the full length of the h= ash >>>> output. Doesn't this expose the signature to collision attacks? >>>> >>>> No. We worked this out in our proofs of security. Section B.2.1 of >>> this paper explains why this works. >>> >>> https://eprint.iacr.org/2017/099.pdf >>> >>> Thanks, >>> Sharon >>> >>> >>> >>>> Thank you for your comments. Indeed, VRFs have been around since 1999. >>>>> They are really "verifiable PRFs" but the name is by now standard in = the >>>>> crypto literature, and changing it will cause more confusion than kee= ping >>>>> it. >>>>> >>>>> In terms of the VRF's security properties, there are three: >>>>> uniqueness, collision resistance, and pseudorandomness. These are de= fined >>>>> in our draft (https://tools.ietf.org/html/d >>>>> raft-goldbe-vrf-01#section-3). >>>>> >>>>> How VRFs prevent dictionary attacks: a public hash is subject to a >>>>> dictionary attack because, given the output, an adversary can evaluat= e the >>>>> hash on different inputs and see what hits the outputs. In a VRF, the >>>>> adversary can't evaluate the hash on different inputs. >>>>> >>>>> You say it's not surprising that "random oracle model proof can prove >>>>> the output of a hash to be random". But actually, the output of a has= h is >>>>> NOT random if the input and the hash function are known. This is beca= use >>>>> the output of a hash is deterministic (every input maps to a unique >>>>> output). That's exactly what enables dictionary attacks. This is in >>>>> contrast to a VRF, where the output is (pseudo)random even given know= ledge >>>>> of the input. Only once the VRF proof is given, does the VRF output s= top >>>>> looking random. Note that random oracles are not essential for VRFs, = and >>>>> non-random-oracles constructions exist (but are less efficient than w= hat we >>>>> propose to standardize). >>>>> >>>>> As far as use cases, here are a few: >>>>> >>>>> In the NSEC5 use case for DNSSEC, you have sensitive data (domain >>>>> names) and you sign consecutive pairs of hashes of domain names in or= der to >>>>> be able to prove absence of a name. If you just use standard hashing, >>>>> whenever signed hash values are disclosed, your sensitive data is sub= ject >>>>> to dictionary attacks. VRFs solve that problem, and sensitive names d= on't >>>>> have to be disclosed at all. More details are in >>>>> https://eprint.iacr.org/2017/099.pdf >>>>> >>>>> In CONIKS (also Google Key Transparency, Signal secure messaging, >>>>> Yahoo! Coname) you also have some sensitive data (user names) that ar= e put >>>>> into a Merkle-like authenticated data structure. If you just use stan= dard >>>>> hashing, whenever hash values are disclosed, sensitive data is subjec= t to >>>>> dictionary attacks. If you use VRFs, sensitive data again can be disc= losed >>>>> only on an as-needed basis. More details are in >>>>> https://eprint.iacr.org/2014/1004.pdf. >>>>> >>>>> In a cryptocurrency use case, you wish perform a coin flip that is >>>>> deterministic and provably correct, but cannot be done by just anyone= . >>>>> More details are in https://people.csail.mit.ed >>>>> u/nickolai/papers/gilad-algorand-eprint.pdf and possibly other >>>>> cryptocurrency papers. >>>>> >>>>> Bryan Ford mentioned an additional usecase at the mic on Tuesday: >>>>> distributed password protection protocols >>>>> >>>>> Many of these use case are already putting VRFs into production use >>>>> (esp. the CONIKS one). You can see a list of the various implementat= ions >>>>> we have found in the "implementation status" section of our draft. O= ne of >>>>> the reasons we think this spec is so important is that we found flaws= in >>>>> several of the implementations that can be used to trivially break >>>>> uniqueness. (See eg: https://github.com/google/ >>>>> keytransparency/issues/567) >>>>> >>>>> Thanks, >>>>> Sharon >>>>> >>>>> On Fri, Jul 21, 2017 at 7:32 PM, Dan Brown >>>>> wrote: >>>>> >>>>>> Answering myself below: VRFs have been around since 1999, so are not >>>>>> so new. =E2=80=8EStill don't like the name, and still have trouble = seeing the >>>>>> value. >>>>>> >>>>>> *From: *Dan Brown >>>>>> *Sent: *Tuesday, July 18, 2017 2:29 PM >>>>>> *To: *Sharon Goldberg; cfrg@irtf.org >>>>>> *Cc: *jan@ns1.com; Leonid Reyzin; Dimitrios Papadopoulos >>>>>> *Subject: *Re: [Cfrg] draft-goldbe-vrf: Verifiable Random Functions >>>>>> >>>>>> Hi Sharon and CFRG, >>>>>> >>>>>> >>>>>> >>>>>> On VRFs, my uncertain comments to consider at your leisure: >>>>>> >>>>>> >>>>>> >>>>>> Is it fair to say VRFs are relatively new? If so, then maybe a >>>>>> little more caution is needed about their use. It seems a tad hasty= that >>>>>> it is being used already. >>>>>> >>>>>> >>>>>> >>>>>> To me, it seems that VRFs are basically signatures, with an extra >>>>>> feature. My concern is that this extra feature might get overused, = before >>>>>> it is thoroughly reviewed. >>>>>> >>>>>> >>>>>> >>>>>> It is unsurprising to me that random oracle model proof can prove th= e >>>>>> output of a hash to be random. My intuitive concern is that at leas= t >>>>>> informally, this is kind of circular. Hashes often have some >>>>>> non-random-ish properties that might affect the extra security (over >>>>>> signatures) that VRFs are aiming for. I guess I would much prefer a= proof >>>>>> saying if the hash has (well-studied) properties XYZ, then your >>>>>> construction are VRFs. (Maybe you have this already? If so, then t= ell me >>>>>> so.) >>>>>> >>>>>> >>>>>> >>>>>> Since, VRFs require sending the =E2=80=9Cproofs=E2=80=9D on the wire= , I find it hard >>>>>> to see how it could be used to prevent dictionary attacks. I assume= that >>>>>> you are saying the proofs must be encrypted when one needs to avoid >>>>>> dictionary models? I suppose all the details are there in I-D and p= apers, >>>>>> but for now, I am confused about the threat model (which parties hav= e keys, >>>>>> etc., if they require a secure channel and mutual trust, why just us= e plain >>>>>> old hash,=E2=80=A6). To resist dictionary attacks, were already have= PAKEs and >>>>>> PBHashing. Now this? >>>>>> >>>>>> >>>>>> >>>>>> Finally, on a bikeshed-coloring note, I object to the name >>>>>> =E2=80=9Cverifiable random function=E2=80=9D, on several grounds. >>>>>> >>>>>> >>>>>> >>>>>> 1. It is not a function. It is at least four functions, keygen, >>>>>> sign, verify, and hashify. >>>>>> 2. If you make it into a keyed function F_sk(m), as in >>>>>> prooftohash(sign_sk(m)), it is not verifiable. >>>>>> 3. Verification requires the intermediate proof, which is >>>>>> certainly not even pseudorandom (it is easy to distinguish valid = signatures >>>>>> from random). >>>>>> 4. It is pseudorandom, not random. (The keys are random, but >>>>>> many crypto has keys, without having =E2=80=9Crandom=E2=80=9D in = its name: encryption, MAC, >>>>>> signatures, key exchange, =E2=80=A6, they also don=E2=80=99t veri= fiable or random in their >>>>>> names either.) >>>>>> 5. The similar phrase =E2=80=9Cverifiably random=E2=80=9D, albeit= as a misnomer, >>>>>> has past precedents, see NIST P-256 and Brainpool, etc. When I s= ee VRF, I >>>>>> think a function, that aims to VR in that sense, and great, now w= e can >>>>>> improve on Brainpool, etc. >>>>>> 6. =E2=80=9CRandom function=E2=80=9D should be reserved for the i= deal random >>>>>> mapping concept, for example, as studied by Flajolet-Odlyzko (ok = they only >>>>>> studied the case of equal size domain and range). The random ora= cle model, >>>>>> is the idea of approximating this ideal, etc. An actual approxim= ation >>>>>> should not be name as the ideal (sorry, I=E2=80=99m kind of repea= ting my point 4). >>>>>> >>>>>> >>>>>> >>>>>> Please forgive the fact that my comments above are not very >>>>>> constructive (or if the tone is wrong). This is a new topic for me,= so I >>>>>> am reluctant too many suggestions. Nonetheless, I suggest (0) waiti= ng a >>>>>> little, (1) a non-random-oracle security proof (if you don=E2=80=99t= have it yet), >>>>>> (2) re-naming the scheme to something like re-hashable (or digestibl= e) >>>>>> signatures (and re-name the various parts, i.e. proof -> signature, = etc.). >>>>>> >>>>>> >>>>>> >>>>>> Best regards, >>>>>> >>>>>> >>>>>> >>>>>> Dan >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> *From:* Cfrg [mailto:cfrg-bounces@irtf.org] *On Behalf Of *Sharon >>>>>> Goldberg >>>>>> *Sent:* Wednesday, July 12, 2017 5:42 AM >>>>>> *To:* cfrg@irtf.org >>>>>> *Cc:* jan@ns1.com; Dimitrios Papadopoulos ; Leonid >>>>>> Reyzin >>>>>> *Subject:* [Cfrg] draft-goldbe-vrf: Verifiable Random Functions >>>>>> >>>>>> >>>>>> >>>>>> Dear CFRG, >>>>>> >>>>>> I'm presenting at next week's meeting on Verifiable Random Functions= . >>>>>> A VRF is the public-key version of keyed cryptographic hash. Only th= e >>>>>> holder of the VRF secret key can compute the hash, but anyone with t= he >>>>>> public key can verify it. VRFs can be used to prevent dictionary at= tacks >>>>>> on hash-based data structures, and have applications to key transpar= ency >>>>>> (CONIKS), DNSSEC (NSEC5), and cryptocurrencies (Algorand). >>>>>> >>>>>> In advance of the meeting, please see: >>>>>> >>>>>> 1) Our substantially updated -01 draft: >>>>>> https://datatracker.ietf.org/doc/draft-goldbe-vrf/ >>>>>> >>>>>> 2) Our project page, with links to various VRF implementations: >>>>>> https://www.cs.bu.edu/~goldbe/projects/vrf >>>>>> >>>>>> Comments welcome. Thanks, >>>>>> >>>>>> Sharon >>>>>> >>>>>> -- >>>>>> Sharon Goldberg >>>>>> Computer Science, Boston University >>>>>> http://www.cs.bu.edu/~goldbe >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> --- >>>>> Sharon Goldberg >>>>> Computer Science, Boston University >>>>> http://www.cs.bu.edu/~goldbe >>>>> >>>>> _______________________________________________ >>>>> Cfrg mailing list >>>>> Cfrg@irtf.org >>>>> https://www.irtf.org/mailman/listinfo/cfrg >>>>> >>>>> >>>> >>> >>> >>> -- >>> --- >>> Sharon Goldberg >>> Computer Science, Boston University >>> http://www.cs.bu.edu/~goldbe >>> >> >> >> _______________________________________________ >> Cfrg mailing list >> Cfrg@irtf.org >> https://www.irtf.org/mailman/listinfo/cfrg >> >> > --=20 --- Sharon Goldberg Computer Science, Boston University http://www.cs.bu.edu/~goldbe --001a1148e222cad5c105559952ab Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
It is "verifiable pseudorandomness". (= Not true randomness.)
Think of a pseudorandom function (PRF) that = comes with a public key that allows anyone to check that the output of the = PRF was computed correctly.

Sharon

On Sun, Jul 30, 2017 at 8:02 PM, Philip L= <philippl.lee@gmail.com> wrote:
Please excuse the spam. I thought for just a= moment somehow that the function was verifiably random... like one of thos= e hard problems (for decidability?).

Just a random thought...

On Thu,= Jul 27, 2017 at 4:51 AM, Thomas Garcia <tgarcia.3141@gmail.com&g= t; wrote:
Thanks for helping me clear those things up!

Thomas G.

On Wed, Jul 26= , 2017 at 12:42 PM, Sharon Goldberg <sharon.goldbe@gmail.com>= wrote:
Hi Thomas= ,

1.= It seems that one of the properties that you are interested that the VRF w= ill have is determinism. On the other hand, the EC-VRF value is dependent o= n the choice of some random number k. How are these two facts compatible? A= m I missing something?

W= e require determinism from the VRF hash output, which is obtained from the = VRF proof via the "proof2hash" function.

The EC-VRF proof has 3 values: gamma, c, s
Values c and s depend= s on the choice of random number k
But value gamma does not depen= d on k.

We get determinism because the VRF hash ou= tput (derived using "proof2hash") depends only on gamma, but not = on c and s.
=C2=A0
Slide 28 from my CFRG presentations = gives a pictorial explanation of this:
<= div>2. The value c calculated in EC-VRF is only 128 bits long for Ed25519. = In normal usage of Ed25519 the signature uses the full length of the hash o= utput. Doesn't this expose the signature to collision attacks?

No. We worked this out in our pr= oofs of security.=C2=A0 Section B.2.1 of this paper explains why this works= .

<= div>
Thanks,
Sharon

=C2=A0
Th= ank you for your comments. Indeed, VRFs have been around since 1999. They a= re really "verifiable PRFs" but the name is by now standard in th= e crypto literature, and changing it will cause more confusion than keeping= it.

In terms of the VRF's security properties, there are three: = =C2=A0uniqueness, collision resistance, and pseudorandomness. These are def= ined in our draft (https://to= ols.ietf.org/html/draft-goldbe-vrf-01#section-3).=C2=A0

How VRFs prevent dictionary = attacks: a public hash is subject to a dictionary attack because, given the= output, an adversary can evaluate the hash on different inputs and see wha= t hits the outputs. In a VRF, the adversary can't evaluate the hash on = different inputs.=C2=A0

You say it's not surprising that "rand= om oracle model proof can prove the output of a hash to be random". Bu= t actually, the output of a hash is NOT random if the input and the hash fu= nction are known. This is because the output of a hash is deterministic (ev= ery input maps to a unique output). That's exactly what enables diction= ary attacks. This is in contrast to a VRF, where the output is (pseudo)rand= om even given knowledge of the input. Only once the VRF proof is given, doe= s the VRF output stop looking random. Note that random oracles are not esse= ntial for VRFs, and non-random-oracles constructions exist (but are less ef= ficient than what we propose to standardize).

As far as use cases, here= are a few:=C2=A0

In the NSEC5 use case for DNSSEC, you have sensitive = data (domain names) and you sign consecutive pairs of hashes of domain name= s in order to be able to prove absence of a name. If you just use standard = hashing, whenever signed hash values are disclosed, your sensitive data is = subject to dictionary attacks. VRFs solve that problem, and sensitive names= don't have to be disclosed at all. More details are in=C2=A0https://eprint.iac= r.org/2017/099.pdf

=
In CONIKS (also Google Key Transparency, Si= gnal secure messaging, Yahoo! Coname) you also have some sensitive data (us= er names) that are put into a Merkle-like authenticated data structure. If = you just use standard hashing, whenever hash values are disclosed, sensitiv= e data is subject to dictionary attacks. If you use VRFs, sensitive data ag= ain can be disclosed only on an as-needed basis. More details are in =C2=A0= https:/= /eprint.iacr.org/2014/1004.pdf.

In a cryptocurrency use case, = you wish perform a coin flip that is deterministic and provably correct, bu= t cannot be done by just anyone.=C2=A0 More details are in=C2=A0https://people.csail.mit.edu/nickolai/papers/gilad-algo= rand-eprint.pdf=C2=A0and possibly other cryptocurrency papers.

Bryan Ford mentioned an additional usecase at the mic on Tuesday: distribu= ted password protection protocols

=
Many of these use case are already pu= tting VRFs into production use (esp. the CONIKS one).=C2=A0 You can see a l= ist of the various implementations we have found in the "implementatio= n status" section of our draft.=C2=A0 One of the reasons we think this= spec is so important is that we found flaws in several of the implementati= ons that can be used to trivially break uniqueness. =C2=A0(See eg:=C2=A0https://github.com/google/keytransparency/issues/567)

Thanks,
Sharon=C2=A0

On = Fri, Jul 21, 2017 at 7:32 PM, Dan Brown <danibrown@blackberry.com> wrote:
Answering myself below: VRFs have been around since 1999, so are not so new= . =C2=A0=E2=80=8EStill don't like the name, and still have trouble seei= ng the value.

From: Dan Brown
Sent: Tuesday, July 18, 2017 2:29 PM
To: Sharon Goldberg; cfrg@irtf.org
Cc: jan@ns1.co= m; Leonid Reyzin; Dimitrios Papadopoulos
Subject: Re: [Cfrg] draft-goldbe-vrf: Verifiable Random Functio= ns

Hi Sharon and CFRG,

=C2=A0

On VRFs, my uncertain comments to consider at your leisure:

=C2=A0

Is it fair to say VRFs are relatively new?=C2=A0 If so, then mayb= e a little more caution is needed about their use.=C2=A0 It seems a tad has= ty that it is being used already.

=C2=A0

To me, it seems that VRFs are basically signatures, with an extra= feature.=C2=A0 My concern is that this extra feature might get overused, b= efore it is thoroughly reviewed.=C2=A0

=C2=A0

It is unsurprising to me that random oracle model proof can prove= the output of a hash to be random.=C2=A0 My intuitive concern is that at l= east informally, this is kind of circular.=C2=A0 Hashes often have some non-random-ish properties that might affect the ext= ra security (over signatures) that VRFs are aiming for.=C2=A0 I guess I wou= ld much prefer a proof saying if the hash has (well-studied) properties XYZ= , then your construction are VRFs.=C2=A0 (Maybe you have this already?=C2=A0 If so, then tell me so.)

=C2=A0

Since, VRFs require sending the =E2=80=9Cproofs=E2=80=9D on the w= ire, I find it hard to see how it could be used to prevent dictionary attac= ks.=C2=A0 I assume that you are saying the proofs must be encrypted when one needs to avoid dictionary models?=C2=A0 I suppose al= l the details are there in I-D and papers, but for now, I am confused about= the threat model (which parties have keys, etc., if they require a secure = channel and mutual trust, why just use plain old hash,=E2=80=A6). To resist dictionary attacks, were already have= PAKEs and PBHashing.=C2=A0 Now this?

=C2=A0

Finally, on a bikeshed-coloring note, I object to the name =E2=80= =9Cverifiable random function=E2=80=9D, on several grounds.

=C2=A0

  1. It is not a function.=C2=A0 It is at least four functions, keygen, sign, v= erify, and hashify.
  2. If you make it into a keyed function F_sk(m= ), as in prooftohash(sign_sk(m)), it is not verifiable.=C2=A0
  3. Verification requires the intermediate proof, which is certain= ly not even pseudorandom (it is easy to distinguish valid signatures from r= andom).
  4. It is pseudorandom, not random.=C2=A0 (The keys are ran= dom, but many crypto has keys, without having =E2=80=9Crandom=E2=80=9D in i= ts name: encryption, MAC, signatures, key exchange, =E2=80=A6, they also don=E2=80=99t verifiable or random in t= heir names either.)
  5. The similar phrase =E2=80=9Cverifiably rand= om=E2=80=9D, albeit as a misnomer, has past precedents, see NIST P-256 and = Brainpool, etc.=C2=A0 When I see VRF, I think a function, that aims to VR in that sense, and great, now we can improve o= n Brainpool, etc.
  6. =E2=80=9CRandom function=E2=80=9D should be r= eserved for the ideal random mapping concept, for example, as studied by Fl= ajolet-Odlyzko (ok they only studied the case of equal size domain and range).=C2=A0 The random oracle model, i= s the idea of approximating this ideal, etc.=C2=A0 An actual approximation = should not be name as the ideal (sorry, I=E2=80=99m kind of repeating my po= int 4).

=C2=A0

Please forgive the fact that my comments above are not very const= ructive (or if the tone is wrong).=C2=A0 This is a new topic for me, so I a= m reluctant too many suggestions.=C2=A0 Nonetheless, I suggest (0) waiting a little, (1) a non-random-oracle security proof (if= you don=E2=80=99t have it yet), (2) re-naming the scheme to something like= re-hashable (or digestible) signatures (and re-name the various parts, i.e= . proof -> signature, etc.).

=C2=A0

Best regards,

=C2=A0

Dan

=C2=A0

=C2=A0

From: Cfrg [mailto:cfrg-bounces@irtf.org] On Behalf Of Sharon Goldberg
Sent: Wednesday, July 12, 2017 5:42 AM
To: cfrg@irtf.org=
Cc: jan@ns1.com= ; Dimitrios Papadopoulos <dipapado@umd.edu>; Leonid Reyzin <reyzin@cs.bu.edu>
Subject: [Cfrg] draft-goldbe-vrf: Verifiable Random Functions=

=C2=A0

Dear CFRG,

I'm presenting at next week's meeting on Verifiable Random Function= s. A VRF is the public-key version of keyed cryptographic hash. Only the ho= lder of the VRF secret key can compute the hash, but anyone with the public= key can verify it.=C2=A0 VRFs can be used to prevent dictionary attacks on hash-based data structures, and have applica= tions to key transparency (CONIKS), DNSSEC (NSEC5), and cryptocurrencies (A= lgorand).

In advance of the meeting, please see:

1) Our substantially updated -01 draft:
https://datatracker.ietf.org/doc/draft-goldbe-vrf/

2) Our project page, with links to various VRF implementations:
ht= tps://www.cs.bu.edu/~goldbe/projects/vrf

Comments welcome.=C2=A0 Thanks,

Sharon

--
Sharon Goldberg
Computer Science, Boston University
http://www.cs.bu= .edu/~goldbe




--
=
---
Sharon Goldberg
Compute= r Science, Boston University
http://www.cs.bu.edu/~goldbe

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





<= /div>--
---
Sharon Goldberg=
Computer Science, Boston University
http://www.cs.bu.edu/~goldbe


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





--
---
Sharon Goldberg
Computer Science, Boston University
http://www.cs.bu.edu/~g= oldbe
--001a1148e222cad5c105559952ab--