From stephen.farrell@cs.tcd.ie Wed Jun 6 07:54:52 2012 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 AF5C221F87C1 for ; Wed, 6 Jun 2012 07:54:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b1aY7I3ZxAJY for ; Wed, 6 Jun 2012 07:54:51 -0700 (PDT) Received: from scss.tcd.ie (hermes.scss.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id CA7D521F8507 for ; Wed, 6 Jun 2012 07:54:49 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 2AF4B171479 for ; Wed, 6 Jun 2012 15:54:44 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:subject:mime-version :user-agent:from:date:message-id:received:received: x-virus-scanned; s=cs; t=1338994483; bh=/IUI7jsYljcq4mk9QPkUsxUM mQh18mxHo/1L4y2COv0=; b=OZWN3s6yYDahwyEU0JvJmfl63M1O/ewmz2N+5k4U n76skNQ0xU1qXvlv1TVc38z8ISjn3ONrNyAiR7x9vFXJibZsoTs5fChLjdGd2g8i sKqEe50VFM9yNjktCUunu8+lXTQ4mS2Uoa3YvnSvr5cEbQf2QMaQNDEeeW3NP+TI yLOUllzh9aZtDhfSIPSKzCNSq/PKPa+EoG66oKp75+HtL6qqkSoxU9rlAGa+uWC+ Zo3bw6JWg0g8dMVUjobpUtKAHGtGjtoRNDe3QmQxwCh46ZSKAhfsqweEJcNSuP2J SOp3EQ+L+5Ixpt9TfHweb7JoW86LYGXo4NRowQFQdQLIsQ== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id cvmObpBnIYEm for ; Wed, 6 Jun 2012 15:54:43 +0100 (IST) Received: from [IPv6:2001:770:10:203:bd88:d721:7222:9395] (unknown [IPv6:2001:770:10:203:bd88:d721:7222:9395]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 75EAB171476 for ; Wed, 6 Jun 2012 15:54:43 +0100 (IST) Message-ID: <4FCF6F34.1040302@cs.tcd.ie> Date: Wed, 06 Jun 2012 15:54:44 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: "cfrg@irtf.org" X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [Cfrg] possibly dumb question about the opus codec and padding X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jun 2012 14:54:52 -0000 Hiya, I'm reviewing the opus codec spec [1] for this week's IESG telechat. On p20, they say to zero out padding bits to avoid a covert channel. Now I don't know how often that might happen, nor for how many bits (its a complicated beast;-) but I wondered if there's a possible problem there if the resulting encoded bits are stream-enciphered with a not-quite-good-enough cipher and for whatever reason there's a lot of padding. I could ask 'em to say "pad randomly if these may be stream enciphered since you can hide the covert channel in the ciphertext nicely in any case" but it may be hard to know from within the codec if a stream cipher will be used elsewhere in the stack. Or, perhaps I could suggest they add a warning that these zero'd padding bits would be problematic if you use a crap stream cipher, but then that's motherhood/apple-pie and would be ignored, buried as it is within the bowels of a 331 page spec. Any thoughts? (Most usefully before 1530 UTC tomorrow:-) Ta, S. [1] http://tools.ietf.org/html/draft-ietf-codec-opus-14 From jon@callas.org Wed Jun 6 08:10:58 2012 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 40FE521F8670 for ; Wed, 6 Jun 2012 08:10:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.74 X-Spam-Level: X-Spam-Status: No, score=-0.74 tagged_above=-999 required=5 tests=[BAYES_20=-0.74] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JKjGo5RmnAz5 for ; Wed, 6 Jun 2012 08:10:57 -0700 (PDT) Received: from mail.merrymeet.com (merrymeet.com [173.164.244.100]) by ietfa.amsl.com (Postfix) with ESMTP id 8C0B821F853F for ; Wed, 6 Jun 2012 08:10:57 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.merrymeet.com (Postfix) with ESMTP id C603BB7AD87 for ; Wed, 6 Jun 2012 08:10:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at merrymeet.com Received: from mail.merrymeet.com ([127.0.0.1]) by localhost (merrymeet.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ChgB+jijYKAj for ; Wed, 6 Jun 2012 08:10:56 -0700 (PDT) Received: from keys.merrymeet.com (keys.merrymeet.com [173.164.244.97]) by mail.merrymeet.com (Postfix) with ESMTPSA id 1B218B7AD76 for ; Wed, 6 Jun 2012 08:10:56 -0700 (PDT) Received: from mab.corp.ad.entrust.com ([216.191.251.36]) by keys.merrymeet.com (PGP Universal service); Wed, 06 Jun 2012 08:10:56 -0700 X-PGP-Universal: processed; by keys.merrymeet.com on Wed, 06 Jun 2012 08:10:56 -0700 Mime-Version: 1.0 (Apple Message framework v1278) From: Jon Callas In-Reply-To: <4FCF6F34.1040302@cs.tcd.ie> Date: Wed, 6 Jun 2012 08:10:54 -0700 Message-Id: <8B35D1AD-8922-456B-A8BE-1B398F6F1A03@callas.org> References: <4FCF6F34.1040302@cs.tcd.ie> To: Stephen Farrell X-Mailer: Apple Mail (2.1278) X-PGP-Encoding-Format: Partitioned X-PGP-Encoding-Version: 2.0.2 X-Content-PGP-Universal-Saved-Content-Transfer-Encoding: quoted-printable X-Content-PGP-Universal-Saved-Content-Type: text/plain; charset=us-ascii Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: "cfrg@irtf.org" , Jon Callas Subject: Re: [Cfrg] possibly dumb question about the opus codec and padding X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jun 2012 15:10:58 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 In my opinion, the best compromise on this would be to change MUST to SHOUL= D. The spec as written says you MUST zero-pad, but you MUST accept any padding= . That means that a non-compliant implementation is still interoperable, an= d the MUST pad is just a fig leaf. Be honest with yourself. There is always a dilemma, because they're right, there's a covert channel.= On the other hand, zero-padding creates known plaintext. Pick your poison. In general, worrying about covert-channels is not worth it. If someone want= s to create a covert channel, they can. There are infinite ways to create o= ne, and worrying about it isn't worth the effort. Moreover, if you leave th= e easy way to create one in, you have an easy way to detect one, too. You c= an also argue that anyone who wants a covert channel wouldn't use that, bec= ause a covert channel has to be -- well, you know, *covert* -- and sticking= data in the padding is pretty darned obvious. Since I brought it up, the known plaintext in the zero-padding isn't a huge= leak, either and I wouldn't worry about it.=20 Thus, I think the most reasonable thing to do would be to just make the MUS= T a SHOULD because the MUST-accept pulls all the teeth out of the MUST-pad. Jon -----BEGIN PGP SIGNATURE----- Version: PGP Universal 3.2.0 (Build 1672) Charset: us-ascii wj8DBQFPz3MAsTedWZOD3gYRArV6AKCETR736FriR2EEoJWMjPfUAfai5wCg6BFN lnbfTECLak7dhRIqZKqWTpw=3D =3DKUJm -----END PGP SIGNATURE----- From housley@vigilsec.com Wed Jun 6 08:57:37 2012 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 56F8921F86A2 for ; Wed, 6 Jun 2012 08:57:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.575 X-Spam-Level: X-Spam-Status: No, score=-102.575 tagged_above=-999 required=5 tests=[AWL=0.024, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D-y-yWCzo9ua for ; Wed, 6 Jun 2012 08:57:36 -0700 (PDT) Received: from odin.smetech.net (mail.smetech.net [208.254.26.82]) by ietfa.amsl.com (Postfix) with ESMTP id B752A21F8618 for ; Wed, 6 Jun 2012 08:57:36 -0700 (PDT) Received: from localhost (unknown [208.254.26.81]) by odin.smetech.net (Postfix) with ESMTP id D5CBBF2403B; Wed, 6 Jun 2012 11:57:52 -0400 (EDT) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([208.254.26.82]) by localhost (ronin.smetech.net [208.254.26.81]) (amavisd-new, port 10024) with ESMTP id SItUoU-nKEbA; Wed, 6 Jun 2012 11:57:15 -0400 (EDT) Received: from [192.168.2.110] (pool-96-255-37-161.washdc.fios.verizon.net [96.255.37.161]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 0E21BF2403A; Wed, 6 Jun 2012 11:57:51 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Russ Housley In-Reply-To: <4FCF6F34.1040302@cs.tcd.ie> Date: Wed, 6 Jun 2012 11:57:31 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <610BE690-1A25-45A6-A1AE-65F569992484@vigilsec.com> References: <4FCF6F34.1040302@cs.tcd.ie> To: Stephen Farrell X-Mailer: Apple Mail (2.1084) Cc: "cfrg@irtf.org" Subject: Re: [Cfrg] possibly dumb question about the opus codec and padding X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jun 2012 15:57:37 -0000 I'd encourage the documentation of the concerns with known plaintext = (the zero pad) and a poor stream cipher. It seems like a simple = sentence or two in the Security Considerations section. Russ On Jun 6, 2012, at 10:54 AM, Stephen Farrell wrote: >=20 > Hiya, >=20 > I'm reviewing the opus codec spec [1] for this week's > IESG telechat. >=20 > On p20, they say to zero out padding bits to avoid a covert > channel. >=20 > Now I don't know how often that might happen, nor for how > many bits (its a complicated beast;-) but I wondered if > there's a possible problem there if the resulting encoded > bits are stream-enciphered with a not-quite-good-enough > cipher and for whatever reason there's a lot of padding. >=20 > I could ask 'em to say "pad randomly if these may be > stream enciphered since you can hide the covert channel > in the ciphertext nicely in any case" but it may be > hard to know from within the codec if a stream cipher > will be used elsewhere in the stack. Or, perhaps I > could suggest they add a warning that these zero'd > padding bits would be problematic if you use a crap > stream cipher, but then that's motherhood/apple-pie > and would be ignored, buried as it is within the bowels > of a 331 page spec. >=20 > Any thoughts? (Most usefully before 1530 UTC tomorrow:-) >=20 > Ta, > S. >=20 > [1] http://tools.ietf.org/html/draft-ietf-codec-opus-14 From sfluhrer@cisco.com Wed Jun 6 09:55:08 2012 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 A023121F866D for ; Wed, 6 Jun 2012 09:55:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T5zslnOqYLsO for ; Wed, 6 Jun 2012 09:55:07 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id AF99B21F85A0 for ; Wed, 6 Jun 2012 09:55:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sfluhrer@cisco.com; l=2012; q=dns/txt; s=iport; t=1339001705; x=1340211305; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=Sghg04Aky/sSb73y/O5cnpoPgkNcC6TxJjj/deE8hvQ=; b=NIi1EB6UZUsB2dDvZ08VH+sOBSVQYhm7kZyQbhzZwoE+ZoRTrZF0tY/p SeUXlustNScAqWdNLi69uq8fJRFd+dJS1xSwx4MFHB2dH0xhd3WfRJTJt c6O+MbEcsbGu0DPsJENpMisrtoDYTIaCtSqZ0F0/W0JWqHNhJjajxGC1Z w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAMaKz0+rRDoI/2dsb2JhbABFtDWBB4IYAQEBAwEBAQEPAR0KNAsMBAIBCBEEAQELBhcBBgEmHwkIAQEEARIIARmHZAQBC5gqn3iLGIU5YAOIQI1vjQKBZoMA X-IronPort-AV: E=Sophos;i="4.75,725,1330905600"; d="scan'208";a="45325694" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-3.cisco.com with ESMTP; 06 Jun 2012 16:55:05 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by mtv-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id q56Gt46C030721; Wed, 6 Jun 2012 16:55:05 GMT Received: from xmb-sjc-23e.amer.cisco.com ([128.107.191.15]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 6 Jun 2012 09:55:04 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Wed, 6 Jun 2012 09:55:00 -0700 Message-ID: In-Reply-To: <610BE690-1A25-45A6-A1AE-65F569992484@vigilsec.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Cfrg] possibly dumb question about the opus codec and padding thread-index: Ac1D/Scbt331AsTuSOm5+mTl66Yz1QAB75nw References: <4FCF6F34.1040302@cs.tcd.ie> <610BE690-1A25-45A6-A1AE-65F569992484@vigilsec.com> From: "Scott Fluhrer (sfluhrer)" To: "Russ Housley" , "Stephen Farrell" X-OriginalArrivalTime: 06 Jun 2012 16:55:04.0367 (UTC) FILETIME=[1EAB23F0:01CD4405] Cc: cfrg@irtf.org Subject: Re: [Cfrg] possibly dumb question about the opus codec and padding X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jun 2012 16:55:08 -0000 On the other hand, if a stream cipher is so weak that it can be broken with a bit of known plaintext, I'm pretty confident that we shouldn't use that stream cipher in any case. -----Original Message----- From: cfrg-bounces@irtf.org [mailto:cfrg-bounces@irtf.org] On Behalf Of Russ Housley Sent: Wednesday, June 06, 2012 11:58 AM To: Stephen Farrell Cc: cfrg@irtf.org Subject: Re: [Cfrg] possibly dumb question about the opus codec and padding I'd encourage the documentation of the concerns with known plaintext (the zero pad) and a poor stream cipher. It seems like a simple sentence or two in the Security Considerations section. Russ On Jun 6, 2012, at 10:54 AM, Stephen Farrell wrote: >=20 > Hiya, >=20 > I'm reviewing the opus codec spec [1] for this week's > IESG telechat. >=20 > On p20, they say to zero out padding bits to avoid a covert > channel. >=20 > Now I don't know how often that might happen, nor for how > many bits (its a complicated beast;-) but I wondered if > there's a possible problem there if the resulting encoded > bits are stream-enciphered with a not-quite-good-enough > cipher and for whatever reason there's a lot of padding. >=20 > I could ask 'em to say "pad randomly if these may be > stream enciphered since you can hide the covert channel > in the ciphertext nicely in any case" but it may be > hard to know from within the codec if a stream cipher > will be used elsewhere in the stack. Or, perhaps I > could suggest they add a warning that these zero'd > padding bits would be problematic if you use a crap > stream cipher, but then that's motherhood/apple-pie > and would be ignored, buried as it is within the bowels > of a 331 page spec. >=20 > Any thoughts? (Most usefully before 1530 UTC tomorrow:-) >=20 > Ta, > S. >=20 > [1] http://tools.ietf.org/html/draft-ietf-codec-opus-14 _______________________________________________ Cfrg mailing list Cfrg@irtf.org http://www.irtf.org/mailman/listinfo/cfrg From hal.finney@gmail.com Wed Jun 6 16:52:04 2012 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 B7EE911E8079 for ; Wed, 6 Jun 2012 16:52:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FkExK2NvrO4T for ; Wed, 6 Jun 2012 16:52:04 -0700 (PDT) Received: from mail-we0-f182.google.com (mail-we0-f182.google.com [74.125.82.182]) by ietfa.amsl.com (Postfix) with ESMTP id D953E11E809B for ; Wed, 6 Jun 2012 16:52:03 -0700 (PDT) Received: by werg1 with SMTP id g1so14664wer.13 for ; Wed, 06 Jun 2012 16:52:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=elLhyCkPYqybAGqRHpGvZgFeiOLYhAQPgs5RsjyHDjM=; b=XRts4QWKfbH0hbKdFueB0pUdlRGdnPL1oTgSJUEmZpG0X42Yuaus3i7sUS/9MzWSja fKI+oBgDWOobo9/fidOKb+glsrKkaKVT13ruC8KOhEQaJ+ozV6Gt3ynVhQszqI1f8P/M bRM8+v3jx5IPxJ0AzJIoRpkPfnFJZ8ngbwqJs3FWift+BhR+YhG73QgxOK+E4jKtI/Cg qOFS8d2qUZXjqILXj84jKmXctw0QaS5NvOvSnejCGKK3+T0DisJ5kfGvqWnOx9B2ZQqg AH5ny/f2K8Gjtfb/OlxCUhZyHsWbReUV2/JlrgbAtMk1jZBtpIX4a9FfIkKrghx9kZC/ eJdQ== MIME-Version: 1.0 Received: by 10.216.228.152 with SMTP id f24mr49077weq.85.1339026720838; Wed, 06 Jun 2012 16:52:00 -0700 (PDT) Received: by 10.216.18.209 with HTTP; Wed, 6 Jun 2012 16:52:00 -0700 (PDT) In-Reply-To: References: <4FCF6F34.1040302@cs.tcd.ie> <610BE690-1A25-45A6-A1AE-65F569992484@vigilsec.com> Date: Wed, 6 Jun 2012 16:52:00 -0700 Message-ID: From: Hal Finney To: "Scott Fluhrer (sfluhrer)" Content-Type: multipart/alternative; boundary=0016e6dd8eca0a537104c1d674fa Cc: cfrg@irtf.org, Russ Housley Subject: Re: [Cfrg] possibly dumb question about the opus codec and padding X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jun 2012 23:52:05 -0000 --0016e6dd8eca0a537104c1d674fa Content-Type: text/plain; charset=ISO-8859-1 What time is it when you're worrying about known plaintext in your cipher? Time to get a new cipher. --0016e6dd8eca0a537104c1d674fa Content-Type: text/html; charset=ISO-8859-1 What time is it when you're worrying about known plaintext in your cipher?


Time to get a new cipher.

--0016e6dd8eca0a537104c1d674fa-- From stephen.farrell@cs.tcd.ie Wed Jun 6 17:15:21 2012 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 DF15C21F8476 for ; Wed, 6 Jun 2012 17:15:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.553 X-Spam-Level: X-Spam-Status: No, score=-102.553 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oyhFLMJFfMR9 for ; Wed, 6 Jun 2012 17:15:20 -0700 (PDT) Received: from scss.tcd.ie (hermes.scss.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id B1DD421F8596 for ; Wed, 6 Jun 2012 17:15:20 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 79BFD1714DD; Thu, 7 Jun 2012 01:15:19 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1339028119; bh=WlXG6nIa9wxfrL yGbgkkvjamtXjrhd+1oa+faAbVpZM=; b=GmzXObhEmsM760Px9sDA6EjtcTrG9R QbFb5kuv/OBVw8U8jga3Gp2i5XYSq91R085IH8mfAeFAYVl+fxS9+V1ManR/qgRd pvJXqxh3poWtK3sN5ajuLLR7QML7iRmtAtHEoVODV6loVR/SJZNGrN0hSidLyJgo aSwA72Vcklbk5OwwHuJiX4aOy/euPFSnPLEQEPctHfYMG2f6TyNVDjjGDGWaPf9z tzz+d0DlPYy0v78Gs9oFHmTD5NGca22AdhJUHQDxqv2nzlh/nKapqI9ooxSj8sGP k+vdMJlld6Vg9kfYViITjXqZe0kx4nonnopfvyyOz97JNZr/r1MUFD9Q== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id iG2Qa4vS0kNS; Thu, 7 Jun 2012 01:15:19 +0100 (IST) Received: from [10.87.48.8] (unknown [86.44.77.44]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id CDDC41714DE; Thu, 7 Jun 2012 01:15:16 +0100 (IST) Message-ID: <4FCFF292.2050009@cs.tcd.ie> Date: Thu, 07 Jun 2012 01:15:14 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: Hal Finney References: <4FCF6F34.1040302@cs.tcd.ie> <610BE690-1A25-45A6-A1AE-65F569992484@vigilsec.com> In-Reply-To: X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: cfrg@irtf.org, Russ Housley , "Scott Fluhrer \(sfluhrer\)" Subject: Re: [Cfrg] possibly dumb question about the opus codec and padding X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jun 2012 00:15:22 -0000 On 06/07/2012 12:52 AM, Hal Finney wrote: > What time is it when you're worrying about known plaintext in your cipher? > > Time to get a new cipher. Sure. But that's not what happens with popular ciphers is it? They tend to hang around past their sell-by date in at least some cases. Current news wrt md5 for example. And the problem mightn't be the algorithm but bad keying. Old news wrt WEP for example. Part of the reason for asking is a concern that it might be possible to manipulate things so lots of padding bits are added. (I don't know that yet, trying to find out.) If that's not the case then there's probably nothing to worry about in this case. But more generally, do we have any results about how much known plaintext might be (un)safe with a not-quite-good-enough cipher that could help when considering protocol design? S From jon@callas.org Wed Jun 6 18:25:39 2012 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 A2C2B21F85A3 for ; Wed, 6 Jun 2012 18:25:39 -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=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ITU3xBqlpH3x for ; Wed, 6 Jun 2012 18:25:39 -0700 (PDT) Received: from mail.merrymeet.com (merrymeet.com [173.164.244.100]) by ietfa.amsl.com (Postfix) with ESMTP id 1F58D21F856C for ; Wed, 6 Jun 2012 18:25:38 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.merrymeet.com (Postfix) with ESMTP id 1D6DAB810CF for ; Wed, 6 Jun 2012 18:25:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at merrymeet.com Received: from mail.merrymeet.com ([127.0.0.1]) by localhost (merrymeet.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tl6TwgpKFOAl for ; Wed, 6 Jun 2012 18:25:37 -0700 (PDT) Received: from keys.merrymeet.com (keys.merrymeet.com [173.164.244.97]) by mail.merrymeet.com (Postfix) with ESMTPSA id 4C090B810C9 for ; Wed, 6 Jun 2012 18:25:37 -0700 (PDT) Received: from [10.255.250.92] ([208.97.118.162]) by keys.merrymeet.com (PGP Universal service); Wed, 06 Jun 2012 18:25:37 -0700 X-PGP-Universal: processed; by keys.merrymeet.com on Wed, 06 Jun 2012 18:25:37 -0700 Mime-Version: 1.0 (Apple Message framework v1278) From: Jon Callas In-Reply-To: <4FCFF292.2050009@cs.tcd.ie> Date: Wed, 6 Jun 2012 18:25:34 -0700 Message-Id: <20A54183-2245-4EA9-A7F2-7B2FAE6B00B5@callas.org> References: <4FCF6F34.1040302@cs.tcd.ie> <610BE690-1A25-45A6-A1AE-65F569992484@vigilsec.com> <4FCFF292.2050009@cs.tcd.ie> To: cfrg@irtf.org X-Mailer: Apple Mail (2.1278) X-PGP-Encoding-Format: Partitioned X-PGP-Encoding-Version: 2.0.2 X-Content-PGP-Universal-Saved-Content-Transfer-Encoding: quoted-printable X-Content-PGP-Universal-Saved-Content-Type: text/plain; charset=us-ascii Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: QUOTED-PRINTABLE Subject: Re: [Cfrg] possibly dumb question about the opus codec and padding X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jun 2012 01:25:39 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I might need to clarify my remarks a bit. I don't think a few bits of known plaintext is a serious issue. I mean heck= , pick just about any XML document and it's got an entire *block* of known = plaintext in it via its XML/DTD header. On the other hand, there are a number of problems including the Mister/Zucc= herato attack on OpenPGP and the Paterson et al. attack on SSH that boiled = down to known plaintext. Add to that the PKCS1 attacks, and any number of p= adding oracles, it can't just be waved away. Back to the first hand, zeroing out a field isn't a serious issue, and I do= n't mean to imply that it is. But moving on to the third hand, worrying about a few bytes of covert chann= el is equally as daft. My larger point was that saying you MUST zero a field to stop a covert chan= nel is no more (nor less) sensical than saying you MUST NOT zero it to stop= known plaintext. It's sort of, "I'll see your paranoia and raise you one."= Especially when that MUST for zeroing is followed up with a MUST accept no= n-zero.=20 That's why I opined that changing the MUST to a SHOULD is a good idea. I tr= uly believe that one SHOULD zero all unused bits because of cleanliness. It= 's just a good idea.=20 If you don't like changing that MUST to a SHOULD on zeroing, then at least = change the MUST accept to MUST reject. If you're going to legislate, have a= backbone about your legislation. Jon -----BEGIN PGP SIGNATURE----- Version: PGP Universal 3.2.0 (Build 1672) Charset: us-ascii wj8DBQFP0AMRsTedWZOD3gYRArMAAKDOj78r2s+05WDeO6cWDvdPAeYz1QCeNbOO oZm9XwLUmxpOFzPI0+SDSq4=3D =3Dfqjl -----END PGP SIGNATURE----- From stephen.farrell@cs.tcd.ie Wed Jun 6 18:51:46 2012 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 6397211E80C1 for ; Wed, 6 Jun 2012 18:51:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.559 X-Spam-Level: X-Spam-Status: No, score=-102.559 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G9E4wqt6GwPa for ; Wed, 6 Jun 2012 18:51:44 -0700 (PDT) Received: from scss.tcd.ie (hermes.scss.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id E8D0C11E80BC for ; Wed, 6 Jun 2012 18:51:43 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 4DF751714DD; Thu, 7 Jun 2012 02:51:39 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1339033898; bh=f63UL4Cin5HWEA pL5ZiyyuzJAedWA245CgH8c6A+Axk=; b=u8F4O3zKZ+n/Krhup/RI2aqROAMfZB 0jaw6yixIPMfNUxy1DxR5FNgixj5KYC2SEfi20uESkRzp5+lQjwtkZeJxokqQnxZ PyKXsrfiphaZr1vgeI3IbLYdJCiVBu8Fpw/FtWRzAJB9eq4WMGesZNi80Tz1BVWf 34BtzsH2ITvV+5791dvjcKOpbGQuUHd1ivepCnl0cXD0KEWOOhZjC4QzUR6yH7rk p/ud2gonfWmiWTmR6sB2WR/v6MJw7WO3+F+QQW9WxJo2oIl6jSmAtYyLkl2Le2Fk sCPeqGZNom3qY2N/kzoCERzn3VGsPKfyf+gKnJ5FraqXB1N2m8tcdH6A== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id oTso7yQDpCfd; Thu, 7 Jun 2012 02:51:38 +0100 (IST) Received: from [10.87.48.8] (unknown [86.44.77.44]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id E3479171479; Thu, 7 Jun 2012 02:51:37 +0100 (IST) Message-ID: <4FD00929.3010808@cs.tcd.ie> Date: Thu, 07 Jun 2012 02:51:37 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: Jon Callas References: <4FCF6F34.1040302@cs.tcd.ie> <610BE690-1A25-45A6-A1AE-65F569992484@vigilsec.com> <4FCFF292.2050009@cs.tcd.ie> <20A54183-2245-4EA9-A7F2-7B2FAE6B00B5@callas.org> In-Reply-To: <20A54183-2245-4EA9-A7F2-7B2FAE6B00B5@callas.org> X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: cfrg@irtf.org Subject: Re: [Cfrg] possibly dumb question about the opus codec and padding X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jun 2012 01:51:47 -0000 Thanks Jon, I asked if they'd change MUST->SHOULD. (Not, its not my spec, its the codec wg's.) S On 06/07/2012 02:25 AM, Jon Callas wrote: > I might need to clarify my remarks a bit. > > I don't think a few bits of known plaintext is a serious issue. I mean heck, pick just about any XML document and it's got an entire *block* of known plaintext in it via its XML/DTD header. > > On the other hand, there are a number of problems including the Mister/Zuccherato attack on OpenPGP and the Paterson et al. attack on SSH that boiled down to known plaintext. Add to that the PKCS1 attacks, and any number of padding oracles, it can't just be waved away. > > Back to the first hand, zeroing out a field isn't a serious issue, and I don't mean to imply that it is. > > But moving on to the third hand, worrying about a few bytes of covert channel is equally as daft. > > My larger point was that saying you MUST zero a field to stop a covert channel is no more (nor less) sensical than saying you MUST NOT zero it to stop known plaintext. It's sort of, "I'll see your paranoia and raise you one." Especially when that MUST for zeroing is followed up with a MUST accept non-zero. > > That's why I opined that changing the MUST to a SHOULD is a good idea. I truly believe that one SHOULD zero all unused bits because of cleanliness. It's just a good idea. > > If you don't like changing that MUST to a SHOULD on zeroing, then at least change the MUST accept to MUST reject. If you're going to legislate, have a backbone about your legislation. > > Jon > > > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > http://www.irtf.org/mailman/listinfo/cfrg > > From daw@cs.berkeley.edu Thu Jun 7 02:04:55 2012 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 810CC21F8775 for ; Thu, 7 Jun 2012 02:04:55 -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=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c5xD4CmDk2wU for ; Thu, 7 Jun 2012 02:04:53 -0700 (PDT) Received: from taverner.cs.berkeley.edu (taverner.CS.Berkeley.EDU [128.32.153.193]) by ietfa.amsl.com (Postfix) with ESMTP id 03CA921F85EF for ; Thu, 7 Jun 2012 02:04:52 -0700 (PDT) Received: from taverner.cs.berkeley.edu (localhost.localdomain [127.0.0.1]) by taverner.cs.berkeley.edu (8.14.2/8.14.2) with ESMTP id q5794lWL010344 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 7 Jun 2012 02:04:47 -0700 Received: (from daw@localhost) by taverner.cs.berkeley.edu (8.14.2/8.14.2/Submit) id q5794llZ010342; Thu, 7 Jun 2012 02:04:47 -0700 From: David Wagner Message-Id: <201206070904.q5794llZ010342@taverner.cs.berkeley.edu> To: cfrg@irtf.org Date: Thu, 7 Jun 2012 02:04:47 -0700 (PDT) Secret-Bounce-Tag: 9a029cbee41caf2ca77a77efa3c13981 X-Mailer: ELM [version 2.5 PL6] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: jon@callas.org Subject: Re: [Cfrg] possibly dumb question about the opus codec and padding X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jun 2012 09:04:55 -0000 [Let's see if this email makes it through the moderation filter...] Jon Callas wrote: > I don't think a few bits of known plaintext is a serious issue. I mean > heck, pick just about any XML document and it's got an entire *block* > of known plaintext in it via its XML/DTD header. > > On the other hand, there are a number of problems including the > Mister/Zuccherato attack on OpenPGP and the Paterson et al. attack on > SSH that boiled down to known plaintext. Add to that the PKCS1 attacks, > and any number of padding oracles, it can't just be waved away. I don't agree. In my view, the problems in the Mister/Zuccherato attack and the Paterson et al. attack had little or nothing to do with known plaintext. Rather, the problems arose because those systems didn't use cryptographic algorithms properly. In particular, the systems failed to use a mode of operation that provides secure against chosen-ciphertext attacks, and consequently the system ended up being (surprise!) vulnerable to chosen-ciphertext attacks. The same is true of PKCS1 and padding oracle attacks. Those failures all occurred because of failure to use a mode that's been shown to be secure against chosen-ciphertext attacks. In my opinion, the lesson from those systems has nothing to do with known plaintext. The lesson is: any time you encrypt, make sure you use a mode of operation that is secure against chosen-ciphertext attacks. Any time you encrypt, make sure you use a mode that provides authenticated encryption. Encryption without authentication is almost always a bad idea. Sadly, many software developers are not familiar with these lessons. Further references: Don't use encryption without message authentication http://security.stackexchange.com/a/2206/ Side-Channel Attacks on Symmetric Encryption Schemes: The Case for Authenticated Encryption, John Black and Hector Urtubia, Usenix Security 2002. http://www.cs.colorado.edu/~jrblack/papers/padding.pdf From jon@callas.org Thu Jun 7 06:01:22 2012 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 5659821F8789 for ; Thu, 7 Jun 2012 06:01:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.67 X-Spam-Level: X-Spam-Status: No, score=-1.67 tagged_above=-999 required=5 tests=[AWL=0.930, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P-SgIKqFe8tv for ; Thu, 7 Jun 2012 06:01:21 -0700 (PDT) Received: from mail.merrymeet.com (merrymeet.com [173.164.244.100]) by ietfa.amsl.com (Postfix) with ESMTP id C18B621F8596 for ; Thu, 7 Jun 2012 06:01:21 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.merrymeet.com (Postfix) with ESMTP id 967A1B860BF for ; Thu, 7 Jun 2012 06:01:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at merrymeet.com Received: from mail.merrymeet.com ([127.0.0.1]) by localhost (merrymeet.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dqT90kOdGfKS for ; Thu, 7 Jun 2012 06:01:19 -0700 (PDT) Received: from keys.merrymeet.com (keys.merrymeet.com [173.164.244.97]) by mail.merrymeet.com (Postfix) with ESMTPSA id 37194B860AC for ; Thu, 7 Jun 2012 06:01:19 -0700 (PDT) Received: from mab.corp.ad.entrust.com ([216.191.251.36]) by keys.merrymeet.com (PGP Universal service); Thu, 07 Jun 2012 06:01:19 -0700 X-PGP-Universal: processed; by keys.merrymeet.com on Thu, 07 Jun 2012 06:01:19 -0700 Mime-Version: 1.0 (Apple Message framework v1278) From: Jon Callas In-Reply-To: <201206070904.q5794llZ010342@taverner.cs.berkeley.edu> Date: Thu, 7 Jun 2012 06:01:16 -0700 Message-Id: References: <201206070904.q5794llZ010342@taverner.cs.berkeley.edu> To: David Wagner X-Mailer: Apple Mail (2.1278) X-PGP-Encoding-Format: Partitioned X-PGP-Encoding-Version: 2.0.2 X-Content-PGP-Universal-Saved-Content-Transfer-Encoding: quoted-printable X-Content-PGP-Universal-Saved-Content-Type: text/plain; charset=us-ascii Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: cfrg@irtf.org, Jon Callas Subject: Re: [Cfrg] possibly dumb question about the opus codec and padding X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jun 2012 13:01:22 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >=20 > ....The lesson is: any time you encrypt, make sure you > use a mode of operation that is secure against chosen-ciphertext attacks. > Any time you encrypt, make sure you use a mode that provides authenticated > encryption. Encryption without authentication is almost always a bad > idea. Sadly, many software developers are not familiar with these > lessons. I don't disagree, and in fact, your last sentence is pretty much what I'm s= aying. The real issue is that a naive "You MUST X because of Y" is always countere= d with a naive "You MUST do ~X because of Z." Y and Z aren't the issues, th= e MUST is. I brought up a crap issue to make a point, not because I believe= the crap issue. Nonetheless, I've recently been concerned with that last sentence. Software= developers aren't familiar with tetchy modes of crypto. The lesson is to g= ive them things that they are less likely to screw up. The fact that lots = of crypto requires specialized practitioners is a bug, not a feature. Jon -----BEGIN PGP SIGNATURE----- Version: PGP Universal 3.2.0 (Build 1672) Charset: us-ascii wj8DBQFP0KYfsTedWZOD3gYRAk9vAKDx+mkqpdKmhlk7RkirdNR/Cj8MBgCbBH7+ KeyQq47KWc9cqGolNHplDNI=3D =3DB3TP -----END PGP SIGNATURE----- From smb@cs.columbia.edu Thu Jun 7 14:00:48 2012 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 6C16821F86A1 for ; Thu, 7 Jun 2012 14:00:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BYPCYrxXzS6r for ; Thu, 7 Jun 2012 14:00:47 -0700 (PDT) Received: from salak.cc.columbia.edu (salak.cc.columbia.edu [128.59.29.6]) by ietfa.amsl.com (Postfix) with ESMTP id 48CC121F86A0 for ; Thu, 7 Jun 2012 14:00:47 -0700 (PDT) Received: from [10.9.0.74] (fireball.cs.columbia.edu [128.59.13.10]) (user=smb2132 mech=PLAIN bits=0) by salak.cc.columbia.edu (8.14.4/8.14.3) with ESMTP id q57L0ann018652 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 7 Jun 2012 17:00:37 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Steven Bellovin In-Reply-To: <201206070904.q5794llZ010342@taverner.cs.berkeley.edu> Date: Thu, 7 Jun 2012 17:00:34 -0400 Content-Transfer-Encoding: 7bit Message-Id: References: <201206070904.q5794llZ010342@taverner.cs.berkeley.edu> To: David Wagner X-Mailer: Apple Mail (2.1278) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.68 on 128.59.29.6 Cc: cfrg@irtf.org, jon@callas.org Subject: Re: [Cfrg] possibly dumb question about the opus codec and padding X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jun 2012 21:00:48 -0000 On Jun 7, 2012, at 5:04 AM, David Wagner wrote: > [Let's see if this email makes it through the moderation filter...] > > Jon Callas wrote: >> I don't think a few bits of known plaintext is a serious issue. I mean >> heck, pick just about any XML document and it's got an entire *block* >> of known plaintext in it via its XML/DTD header. >> >> On the other hand, there are a number of problems including the >> Mister/Zuccherato attack on OpenPGP and the Paterson et al. attack on >> SSH that boiled down to known plaintext. Add to that the PKCS1 attacks, >> and any number of padding oracles, it can't just be waved away. > > I don't agree. In my view, the problems in the Mister/Zuccherato attack > and the Paterson et al. attack had little or nothing to do with known > plaintext. Rather, the problems arose because those systems didn't use > cryptographic algorithms properly. In particular, the systems failed to > use a mode of operation that provides secure against chosen-ciphertext > attacks, and consequently the system ended up being (surprise!) vulnerable > to chosen-ciphertext attacks. > > The same is true of PKCS1 and padding oracle attacks. Those failures > all occurred because of failure to use a mode that's been shown to be > secure against chosen-ciphertext attacks. > > In my opinion, the lesson from those systems has nothing to do with > known plaintext. The lesson is: any time you encrypt, make sure you > use a mode of operation that is secure against chosen-ciphertext attacks. > Any time you encrypt, make sure you use a mode that provides authenticated > encryption. Encryption without authentication is almost always a bad > idea. Sadly, many software developers are not familiar with these > lessons. > > Further references: > > Don't use encryption without message authentication > http://security.stackexchange.com/a/2206/ > > Side-Channel Attacks on Symmetric Encryption Schemes: The Case for > Authenticated Encryption, John Black and Hector Urtubia, Usenix Security > 2002. http://www.cs.colorado.edu/~jrblack/papers/padding.pdf And two older papers of mine: Problem areas for the IP security protocols. In Proceedings of the Sixth Usenix Unix Security Symposium, pages 205-214, July 1996. https://www.cs.columbia.edu/~smb/papers/badesp.pdf Probable plaintext cryptanalysis of the IP security protocols. In Proceedings of the Symposium on Network and Distributed System Security, pages 155-160, 1997. https://www.cs.columbia.edu/~smb/papers/probtxt.pdf The first paper shows that, as David said, you have to authenticate when you encrypt; the second shows that even absent known plaintext, there's frequently probable plaintext. In particular see the two packet attacks, where you have no idea what something is but do know that it's probably the same as in the previous packet. --Steve Bellovin, https://www.cs.columbia.edu/~smb From daw@cs.berkeley.edu Thu Jun 7 18:29:43 2012 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 B36FA11E808F for ; Thu, 7 Jun 2012 18:29:43 -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=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5U2F6amjcqrq for ; Thu, 7 Jun 2012 18:29:43 -0700 (PDT) Received: from taverner.cs.berkeley.edu (taverner.CS.Berkeley.EDU [128.32.153.193]) by ietfa.amsl.com (Postfix) with ESMTP id 4B01F11E8079 for ; Thu, 7 Jun 2012 18:29:40 -0700 (PDT) Received: from taverner.cs.berkeley.edu (localhost.localdomain [127.0.0.1]) by taverner.cs.berkeley.edu (8.14.2/8.14.2) with ESMTP id q581TaUH032702 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 7 Jun 2012 18:29:36 -0700 Received: (from daw@localhost) by taverner.cs.berkeley.edu (8.14.2/8.14.2/Submit) id q581TZfT032699; Thu, 7 Jun 2012 18:29:35 -0700 From: David Wagner Message-Id: <201206080129.q581TZfT032699@taverner.cs.berkeley.edu> To: Cfrg@irtf.org Date: Thu, 7 Jun 2012 18:29:35 -0700 (PDT) Secret-Bounce-Tag: 9a029cbee41caf2ca77a77efa3c13981 X-Mailer: ELM [version 2.5 PL6] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: jon@callas.org Subject: Re: [Cfrg] possibly dumb question about the opus codec and padding X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jun 2012 01:29:43 -0000 Jon Callas wrote: >> ....The lesson is: any time you encrypt, make sure you >> use a mode of operation that is secure against chosen-ciphertext attacks. >> Any time you encrypt, make sure you use a mode that provides authenticated >> encryption. Encryption without authentication is almost always a bad >> idea. Sadly, many software developers are not familiar with these >> lessons. > >I don't disagree, and in fact, your last sentence is pretty much what >I'm saying. We may be drifting, but to come back to the original topic/question: In my opinion, as long as you choose the cipher and modes of operation reasonably, there's nothing wrong with having some known plaintext. There's no great harm or risk to having lots of known plaintext in the plaintext. If there is some security benefit from having fixed padding (e.g., increase in security against side channels), I think the original poster should go for it, and not let concerns about known-plaintext stop them. Of course, if you don't choose the cipher or modes of operation reasonably, you've got bigger problems.... From stephen.farrell@cs.tcd.ie Fri Jun 8 04:57:50 2012 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 E344821F891A for ; Fri, 8 Jun 2012 04:57:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 34j-ZYFGah1H for ; Fri, 8 Jun 2012 04:57:50 -0700 (PDT) Received: from scss.tcd.ie (hermes.scss.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id 2C24D21F8919 for ; Fri, 8 Jun 2012 04:57:50 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 9094917180C; Fri, 8 Jun 2012 12:57:49 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1339156669; bh=ehj3p7UxEHzTm4 cuo32ow+sDq+HwWwA3umb/qVyFh+8=; b=sYAbZ/n34hI6p3x2v7SLNx/LtXDTlb CwbBt8+IEv39M/cTSrW2zPzSdmmBG8Qg5pL9HUfVGi/9pD3X10fajsgfWzWHhr6r eR78pf5esGWZT6F/GXgD+qq7n3jMZ/V7PszzwoWwzC+rSj6ot1v0qsy2JiJ8iXzF bMEUWDqn6FxzyYDYZhjoZ1SN6n6kJhZz4jSbZ95P/jwfw6slkcvxoNLhQJdaSQ41 /JwZxn36kdEUp2sHjjcKm1IR3KbUKPGnYZcvoMQSjfhLe+2e0eSFBrtiKtuuOPV8 43GM9wtwCegNEeP2gv4pX02sZofAtiQsQJiZK50i69QCnCrRol423PYA== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id yUKzenD4aBv8; Fri, 8 Jun 2012 12:57:49 +0100 (IST) Received: from [IPv6:2001:770:10:203:ccd0:6c1c:533b:ca48] (unknown [IPv6:2001:770:10:203:ccd0:6c1c:533b:ca48]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 79703154252; Fri, 8 Jun 2012 12:57:44 +0100 (IST) Message-ID: <4FD1E8B4.7040601@cs.tcd.ie> Date: Fri, 08 Jun 2012 12:57:40 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: David Wagner References: <201206080129.q581TZfT032699@taverner.cs.berkeley.edu> In-Reply-To: <201206080129.q581TZfT032699@taverner.cs.berkeley.edu> X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Cfrg@irtf.org, jon@callas.org Subject: Re: [Cfrg] possibly dumb question about the opus codec and padding X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jun 2012 11:57:51 -0000 On 06/08/2012 02:29 AM, David Wagner wrote: > > In my opinion, as long as you choose the cipher and modes of operation > reasonably, there's nothing wrong with having some known plaintext. > There's no great harm or risk to having lots of known plaintext in the > plaintext. If there is some security benefit from having fixed padding > (e.g., increase in security against side channels), I think the original > poster should go for it, and not let concerns about known-plaintext > stop them. > > Of course, if you don't choose the cipher or modes of operation > reasonably, you've got bigger problems.... The situation here is that the folks doing the work are defining an audio codec that'll be used by all and sundry, certainly including some who do unreasonable cryptographic things. So simply saying "use proper crypto" arguably isn't enough of an answer, though is clearly an important part of the answer. I guess my original question might be better stated as: other than saying "use proper crypto," what *else* should we be saying about known plaintext (or padding specifically) in cases such as these when we do know that dodgy crypto will get used sometimes? Of course, maybe the full answer is "use proper crypto, or else suffer the consequences":-) Note as well that it appears that a bad actor on the network could apparently manipulate things to cause padding events in this particular case, perhaps by throttling bandwidth so that the codec responds when in variable bit-rate (VBR) mode. I don't really understand the details there yet, but am trying to find out. There is already a recommendation in the document that constant bit rate SHOULD be used for "highly sensitive" audio, but VBR will get used a lot I'd expect. Ta, S. From mcgrew@cisco.com Fri Jun 8 07:24:06 2012 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 9154E21F88A2 for ; Fri, 8 Jun 2012 07:24:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g6G1ND1dKq6R for ; Fri, 8 Jun 2012 07:24:06 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id B9BD021F891F for ; Fri, 8 Jun 2012 07:24:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mcgrew@cisco.com; l=1905; q=dns/txt; s=iport; t=1339165445; x=1340375045; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=jBe2uzp3VALzUZgBm9fwuEKPjE9L4s5IeJopCOOGotg=; b=FnZ31UrEKBFXXCjt/ncPghpv7Pt2I00iDcSj2jlBw7RiL8Yzxe7e08FG vafpuNRVQQuUm/ImtVB0gI1e/dfa7Lulrd9YnxN6ZZK/RZ97IVGyn4QLY lZoFOBjGEraOyHtsxQU/QfTC5vgIfvoLTQ1VxXdTaL0NWq/Va5Dsi/mON g=; X-IronPort-AV: E=Sophos;i="4.75,738,1330905600"; d="scan'208";a="90749528" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-6.cisco.com with ESMTP; 08 Jun 2012 14:24:05 +0000 Received: from rtp-mcgrew-8912.cisco.com (rtp-mcgrew-8912.cisco.com [10.117.10.227]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id q58EO4Hd005597; Fri, 8 Jun 2012 14:24:04 GMT Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: David McGrew In-Reply-To: <4FCFF292.2050009@cs.tcd.ie> Date: Fri, 8 Jun 2012 10:24:04 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <6303CF76-6C12-4E2B-A9C6-FB5B5421EE36@cisco.com> References: <4FCF6F34.1040302@cs.tcd.ie> <610BE690-1A25-45A6-A1AE-65F569992484@vigilsec.com> <4FCFF292.2050009@cs.tcd.ie> To: Stephen Farrell X-Mailer: Apple Mail (2.1278) Cc: Russ Housley , cfrg@irtf.org, "Scott Fluhrer \(sfluhrer\)" Subject: Re: [Cfrg] possibly dumb question about the opus codec and padding X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jun 2012 14:24:06 -0000 On Jun 6, 2012, at 8:15 PM, Stephen Farrell wrote: >=20 >=20 > On 06/07/2012 12:52 AM, Hal Finney wrote: >> What time is it when you're worrying about known plaintext in your = cipher? >>=20 >> Time to get a new cipher. +1 on that. >=20 > Sure. But that's not what happens with popular ciphers is it? > They tend to hang around past their sell-by date in at least > some cases. Current news wrt md5 for example. >=20 > And the problem mightn't be the algorithm but bad keying. Old > news wrt WEP for example. >=20 Agreed. There are many good ciphers that appear to be secure even when = the attacker can adaptively choose exabytes worth of data. This list = includes AES and many other 128-bit wide block ciphers used in = standards. However, it doesn't include RC4 and 3DES, the latter = because of its 64-bit block width. =20 > Part of the reason for asking is a concern that it might be > possible to manipulate things so lots of padding bits are > added. (I don't know that yet, trying to find out.) If that's > not the case then there's probably nothing to worry about in > this case. >=20 > But more generally, do we have any results about how much > known plaintext might be (un)safe with a not-quite-good-enough > cipher that could help when considering protocol design? >=20 There is an interesting threshold around one gigabyte, which corresponds = to the birthday bound for 64-bit block ciphers. =20 Another interesting and related question is: how much known plaintext is = available in network encryption protocols? Many protocols that get = encrypted are predictable enough that an attacker who has done their = homework should be able to guess some fraction of the plaintext. =20 David > S > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > http://www.irtf.org/mailman/listinfo/cfrg From mcgrew@cisco.com Fri Jun 8 07:41:42 2012 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 3D60621F8505 for ; Fri, 8 Jun 2012 07:41:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XRg7H0IMuf1q for ; Fri, 8 Jun 2012 07:41:41 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 45B7D21F8503 for ; Fri, 8 Jun 2012 07:41:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mcgrew@cisco.com; l=2400; q=dns/txt; s=iport; t=1339166501; x=1340376101; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=m8PJOAG3ZFj/lV70Dq1JgvV2Tce1FhJZgZ8UY4dLLl4=; b=jdpxzDWZT2bbsze4bl/vyaL2IW02jq1FtFRNJUjRBSJgAEoevSJ1uodr OQscmkyhKDN5sgxn2HMCNeOUhXXbgZM9TTKoNLpMgms5nvK8uwlDEIsM6 NuIMczysGY0dTF5SZGpDUExkJEVnwyrM+kT31Zo1nVZ6utNNgMuLxqP+P 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAHQO0k+tJV2c/2dsb2JhbABEAbROgQeCGAEBAQMBAQEBDwEnNAsQCzECEycwBhMJGYdkBQuZL59uiyaCeAGDBwOVHo4VgWaCfA X-IronPort-AV: E=Sophos;i="4.75,738,1330905600"; d="scan'208";a="90762952" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-7.cisco.com with ESMTP; 08 Jun 2012 14:41:41 +0000 Received: from rtp-mcgrew-8912.cisco.com (rtp-mcgrew-8912.cisco.com [10.117.10.227]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id q58EfeOE015966; Fri, 8 Jun 2012 14:41:40 GMT Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: David McGrew In-Reply-To: <20A54183-2245-4EA9-A7F2-7B2FAE6B00B5@callas.org> Date: Fri, 8 Jun 2012 10:41:40 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4FCF6F34.1040302@cs.tcd.ie> <610BE690-1A25-45A6-A1AE-65F569992484@vigilsec.com> <4FCFF292.2050009@cs.tcd.ie> <20A54183-2245-4EA9-A7F2-7B2FAE6B00B5@callas.org> To: Jon Callas X-Mailer: Apple Mail (2.1278) Cc: cfrg@irtf.org Subject: Re: [Cfrg] possibly dumb question about the opus codec and padding X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jun 2012 14:41:42 -0000 Hi Jon, On Jun 6, 2012, at 9:25 PM, Jon Callas wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 >=20 > I might need to clarify my remarks a bit. >=20 > I don't think a few bits of known plaintext is a serious issue. I mean = heck, pick just about any XML document and it's got an entire *block* of = known plaintext in it via its XML/DTD header. >=20 > On the other hand, there are a number of problems including the = Mister/Zuccherato attack on OpenPGP and the Paterson et al. attack on = SSH that boiled down to known plaintext. Add to that the PKCS1 attacks, = and any number of padding oracles, it can't just be waved away. This is a good point: known plaintext can make chosen-ciphertext attacks = easier, even if the underlying block cipher resists exabytes of known = plaintext. I think the main lesson from this is: use authenticated = encryption. But I think it is reasonable to say that avoiding known = plaintext is a good idea if it is not possible to ensure that encryption = uses AE. David >=20 > Back to the first hand, zeroing out a field isn't a serious issue, and = I don't mean to imply that it is. >=20 > But moving on to the third hand, worrying about a few bytes of covert = channel is equally as daft. >=20 > My larger point was that saying you MUST zero a field to stop a covert = channel is no more (nor less) sensical than saying you MUST NOT zero it = to stop known plaintext. It's sort of, "I'll see your paranoia and raise = you one." Especially when that MUST for zeroing is followed up with a = MUST accept non-zero.=20 >=20 > That's why I opined that changing the MUST to a SHOULD is a good idea. = I truly believe that one SHOULD zero all unused bits because of = cleanliness. It's just a good idea.=20 >=20 > If you don't like changing that MUST to a SHOULD on zeroing, then at = least change the MUST accept to MUST reject. If you're going to = legislate, have a backbone about your legislation. >=20 > Jon >=20 >=20 > -----BEGIN PGP SIGNATURE----- > Version: PGP Universal 3.2.0 (Build 1672) > Charset: us-ascii >=20 > wj8DBQFP0AMRsTedWZOD3gYRArMAAKDOj78r2s+05WDeO6cWDvdPAeYz1QCeNbOO > oZm9XwLUmxpOFzPI0+SDSq4=3D > =3Dfqjl > -----END PGP SIGNATURE----- > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > http://www.irtf.org/mailman/listinfo/cfrg From smb@cs.columbia.edu Fri Jun 8 10:08:38 2012 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 5911821F87F5 for ; Fri, 8 Jun 2012 10:08:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u5yY9wDMJldO for ; Fri, 8 Jun 2012 10:08:37 -0700 (PDT) Received: from paneer.cc.columbia.edu (paneer.cc.columbia.edu [128.59.29.4]) by ietfa.amsl.com (Postfix) with ESMTP id C156921F87F7 for ; Fri, 8 Jun 2012 10:08:36 -0700 (PDT) Received: from sb-far.cs.columbia.edu (sb-far.cs.columbia.edu [128.59.13.244]) (user=smb2132 mech=PLAIN bits=0) by paneer.cc.columbia.edu (8.14.4/8.14.3) with ESMTP id q58H8Pjo016208 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 8 Jun 2012 13:08:26 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Steven Bellovin In-Reply-To: <4FD1E8B4.7040601@cs.tcd.ie> Date: Fri, 8 Jun 2012 13:08:26 -0400 Content-Transfer-Encoding: 7bit Message-Id: References: <201206080129.q581TZfT032699@taverner.cs.berkeley.edu> <4FD1E8B4.7040601@cs.tcd.ie> To: Stephen Farrell X-Mailer: Apple Mail (2.1278) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.68 on 128.59.29.4 Cc: Cfrg@irtf.org, jon@callas.org, David Wagner Subject: Re: [Cfrg] possibly dumb question about the opus codec and padding X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jun 2012 17:08:38 -0000 On Jun 8, 2012, at 7:57 AM, Stephen Farrell wrote: > > > On 06/08/2012 02:29 AM, David Wagner wrote: >> >> In my opinion, as long as you choose the cipher and modes of operation >> reasonably, there's nothing wrong with having some known plaintext. >> There's no great harm or risk to having lots of known plaintext in the >> plaintext. If there is some security benefit from having fixed padding >> (e.g., increase in security against side channels), I think the original >> poster should go for it, and not let concerns about known-plaintext >> stop them. >> >> Of course, if you don't choose the cipher or modes of operation >> reasonably, you've got bigger problems.... > > The situation here is that the folks doing the work are defining > an audio codec that'll be used by all and sundry, certainly > including some who do unreasonable cryptographic things. > > So simply saying "use proper crypto" arguably isn't enough of an > answer, though is clearly an important part of the answer. I guess > my original question might be better stated as: other than saying > "use proper crypto," what *else* should we be saying about known > plaintext (or padding specifically) in cases such as these when > we do know that dodgy crypto will get used sometimes? > > Of course, maybe the full answer is "use proper crypto, or > else suffer the consequences":-) I think that that really is the only answer. If there's one thing we've learned about crypto over the years, it's that it's a really hard field, with many opportunities for very subtle mistakes. "Finally, protocols such as those developed here are prone to extremely subtle errors that are unlikely to be detected in normal operation. The need for techniques to verify the correctness of such protocols is great, and we encourage those interested in such problems to con- sider this area." This is from the classic 1978 Needham and Schroeder paper. It was a remarkably prescient statement. Maybe some day things will be understood well enough that warnings like this aren't necessary. That day won't be soon. --Steve Bellovin, https://www.cs.columbia.edu/~smb From prvs=750686662e=dbrown@certicom.com Fri Jun 8 11:44:16 2012 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 1EEBC11E80E7 for ; Fri, 8 Jun 2012 11:44:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.782 X-Spam-Level: X-Spam-Status: No, score=-2.782 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, EXTRA_MPART_TYPE=1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4, SARE_GIF_ATTACH=1.42] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k+274ZSEu++Y for ; Fri, 8 Jun 2012 11:44:11 -0700 (PDT) Received: from mhs061cnc.rim.net (mhs061cnc.rim.net [208.65.73.35]) by ietfa.amsl.com (Postfix) with ESMTP id 9E38C11E80D3 for ; Fri, 8 Jun 2012 11:44:10 -0700 (PDT) X-AuditID: 0a412830-b7ff56d000003d5c-1e-4fd247f8ec20 Received: from XCT106CNC.rim.net (xct106cnc.rim.net [10.65.161.206]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by mhs061cnc.rim.net (SBG) with SMTP id 90.CE.15708.8F742DF4; Fri, 8 Jun 2012 18:44:09 +0000 (GMT) Received: from XMB111CNC.rim.net ([fe80::fcd6:cc6c:9e0b:25bc]) by XCT106CNC.rim.net ([fe80::d824:6c98:60dc:3918%16]) with mapi id 14.01.0339.001; Fri, 8 Jun 2012 14:44:08 -0400 From: Dan Brown To: "cfrg@ietf.org" Thread-Topic: [CFRG] Dual use (vs key separation) questions Thread-Index: Ac1Fpq/Et+mFYYSRSwSCB6UjcN4rjw== Date: Fri, 8 Jun 2012 18:44:08 +0000 Message-ID: <810C31990B57ED40B2062BA10D43FBF5080E01@XMB111CNC.rim.net> Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.65.160.246] Content-Type: multipart/related; boundary="_004_810C31990B57ED40B2062BA10D43FBF5080E01XMB111CNCrimnet_"; type="multipart/alternative" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprAJsWRmVeSWpSXmKPExsXC5bjwnO5P90v+BjNWs1oc3dXG4sDosWTJ T6YAxqgGRpukxJKy4Mz0PH07m8S8vPySxJJUhZTU4mRbJZ/U9MQchYCizLLE5EoFl8zi5JzE zNzUIiWFzBRbJRMlhYKcxOTU3NS8ElulxIKC1LwUJTsuBQxgA1SWmaeQmpecn5KZl26r5Bns r2thYWqpa6hkp5vQyZPx7+1PxoLfExgrfiy4x9bAuLu+i5GTQ0LARGLP/kXMELaYxIV769m6 GLk4hAT6mCT2bp0G5WxhlJi96DcjSBWbgKrE/aPnwDpEBJQlpu57yARiCwuYSRzd9ZsJIm4t 8f31PDYIW0/i0Y65YDaLgIrE2VutYHN4BdwkXi2aB2YzCshK7D57HayXWUBc4taT+UwQF4lI PLx4mg3CFpV4+fgfK4StKPHk5DUWiPpORokjL9QhZgpKnJz5hGUCo9AsJKNmISmbhaQMIp4r sW37IUYIW0diwe5PbBC2tsSyha+ZYewzBx4zYYrrSGy+tBNqjqJEW+dsoBouIHspo8Trfxvh hr6de4AJpmhK90P2BYy8qxgFczOKDcwMk/OS9Yoyc/XyUks2MYITkobBDsYJe7UOMQpwMCrx 8OY6XvIXYk0sK67MPcQowcGsJMK7lQkoxJuSWFmVWpQfX1Sak1p8iDEeGLwTmaW4k/OByTKv JN7YwIAcjpI4r93BE/5CAunANJqdmlqQWgSzgYmDE+QCLimRYmAyTC1KLC3JiAel7PhiYNKW amAMWP3eSPEmS1bHzYWdNiEPVyc82cas2d1243bF01aeVZkshXKGT3m5lp+fr7N7yX6xbYJN 75MOONXLx3xcefDm1pVl7xbeEKqx5Yk5qWlq9Vqs8XvM7PsWvK+XF+kHnFqy0LPL4qQ7++nm O5+68pbM04n7vXT1p+5jZvu5bs2svRByQMq5hc1KiaU4I9FQi7moOBEAsR4UwaMDAAA= Subject: [Cfrg] [CFRG] Dual use (vs key separation) questions X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jun 2012 18:44:16 -0000 --_004_810C31990B57ED40B2062BA10D43FBF5080E01XMB111CNCrimnet_ Content-Type: multipart/alternative; boundary="_000_810C31990B57ED40B2062BA10D43FBF5080E01XMB111CNCrimnet_" --_000_810C31990B57ED40B2062BA10D43FBF5080E01XMB111CNCrimnet_ Content-Type: text/plain; charset="us-ascii" content-transfer-encoding: quoted-printable Dear CFRG members, My colleague Alex Truskovsky has brought to my attention the issue of dual u= se of a single private key (of a public key scheme, e.g. RSA or ECC), where= the private key is used for both signing and for key exchange (such as decr= yption or key agreement). Some standards address dual use: 1: NIST Special Publication 800-57 forbids a dual use with one exception: a= key exchange private key may be used to sign a certificate request. 2: PKIX certificates (a) can be configured to allow or forbid dual use (thou= gh this may only apply to the public key side), and (b) when a cert for key= exchange key forbids "dual use", a signed certificate request is also forbi= dden. Restrictions against dual use are usually called key separation. Above, 1 i= s key separation (with exception), and 2b is key separation (when the cert a= sks for it). Questions (not necessarily independent): So, in terms of "dual use", NIST and PKIX are not totally aligned. Should t= here be better alignment? For example, should PKIX move towards NIST by har= dening (a) to forbid dual use, and softening (b) to allow dual use signed ce= rt requests? Are there scheme-generic attacks of dual use? Of course, dual use introduce= s a potential risk, which can be shown by using a contrived pathological exa= mple, in which any use of the signature scheme reveals the private, but I am= asking here if there is an attack that applies for schemes, even when both= schemes are secure. Dual use raw RSA, i.e. without padding, is subject to some severe attacks: (= i) chosen-ciphertext forgery, where a signature is forged using a decryption= oracle, and (ii) chosen-message decipherment, where a challenge ciphertext= is deciphered using a signing oracle, because decryption and signing are th= e same operation in raw RSA. In both attacks the private key owner follows= key separation, so key separation prevents these attacks only if done on th= e public key side. Are these attacks the main justification for key separat= ion? Are there any other scheme-specific attacks with dual use? For exampl= e, is there any other attack (e.g. even stronger, not using an oracle for th= e private key operation, i.e. a more passive attack) on raw RSA? Is there a= ny attack on any type of padded RSA? (I think I saw one paper on it.) Is the= re an attack on ECDH and ECDSA dual use? Security proofs, e.g. for RSA-OAEP, often assume dual use is forbidden. Wha= t security analysis (e.g. proofs) work under "dual use"? A paper by Paterso= n does this, and mentions some others, but they seem not to cover the usual= IETF schemes? Does universal composability also address dual use? Do the current conventional most common suite of public key schemes in IETF= sufficiently resist dual attacks? So, is key separation overkill for these= schemes? Or, should key separation be added as precaution, because of a la= ck of thorough study? What general expectations should there be for public key schemes regarding d= ual use? Suppose a new public key scheme is proposed (e.g. pairing-based, q= uantum-resistant, homomorphic, etc.). Should developers of application stand= ards, who may be using signatures and encryption at a high level interface a= llowing algorithm agility, always use key separation to prevent potential du= al use attacks? Or should developers and cryptographers have to keep a shar= p eye out for dual use attacks, or else proofs of security against dual use,= before considering public key schemes secure? Best regards, Daniel Brown Research In Motion Limited [cid:image001.gif@01CD457D.C408C4F0] --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential infor= mation, privileged material (including material protected by the solicitor-c= lient or other applicable privileges), or constitute non-public information.= Any use of this information by anyone other than the intended recipient is= prohibited. If you have received this transmission in error, please immedia= tely reply to the sender and delete this information from your system. Use,= dissemination, distribution, or reproduction of this transmission by uninte= nded recipients is not authorized and may be unlawful. --_000_810C31990B57ED40B2062BA10D43FBF5080E01XMB111CNCrimnet_ Content-Type: text/html; charset="us-ascii" content-transfer-encoding: quoted-printable

Dear CFRG members,

 

My colleague Alex Truskovsky has brought to my attent= ion the issue of dual use of a single private key (of a public key scheme, e= .g. RSA or ECC), where the private key is used for both signing and for key= exchange (such as decryption or key agreement).  Some standards address dual use:

 

1: NIST Special Publication 800-57 forbids a dual use= with one exception: a key exchange private key may be used to sign a certif= icate request. 

 

2: PKIX certificates (a) can be configured to allow o= r forbid dual use (though this may only apply to the public key side), and (= b) when a cert for key exchange key forbids “dual use”, a signed= certificate request is also forbidden. 

 

Restrictions against dual use are usually called key= separation.  Above, 1 is key separation (with exception), and 2b is ke= y separation (when the cert asks for it).

 

Questions (not necessarily independent):

 

So, in terms of “dual use”, NIST and PKIX= are not totally aligned.  Should there be better alignment?  For= example, should PKIX move towards NIST by hardening (a) to forbid dual use,= and softening (b) to allow dual use signed cert requests?

 

Are there scheme-generic attacks of dual use?  O= f course, dual use introduces a potential risk, which can be shown by using= a contrived pathological example, in which any use of the signature scheme= reveals the private, but I am asking here if there is an attack that applies for schemes, even when both schemes= are secure.

 

Dual use raw RSA, i.e. without padding, is subject to= some severe attacks: (i) chosen-ciphertext forgery, where a signature is fo= rged using a decryption oracle, and (ii) chosen-message decipherment, where= a challenge ciphertext is deciphered using a signing oracle, because decryption and signing are the same operati= on in raw RSA.  In both attacks the private key owner follows key separ= ation, so key separation prevents these attacks only if done on the public k= ey side.  Are these attacks the main justification for key separation?  Are there any other scheme-specific= attacks with dual use?  For example, is there any other attack (e.g. e= ven stronger, not using an oracle for the private key operation, i.e. a more= passive attack) on raw RSA?  Is there any attack on any type of padded RSA? (I think I saw one paper on it.) Is t= here an attack on ECDH and ECDSA dual use?

 

Security proofs, e.g. for RSA-OAEP, often assume dual= use is forbidden.  What security analysis (e.g. proofs) work under = 220;dual use”?  A paper by Paterson does this, and mentions some= others, but they seem not to cover the usual IETF schemes?  Does universal composability also address dual use?

 

Do the current conventional most common suite of publ= ic key schemes in IETF sufficiently resist dual attacks? So, is key separati= on overkill for these schemes?  Or, should key separation be added as p= recaution, because of a lack of thorough study?

 

What general expectations should there be for public= key schemes regarding dual use?  Suppose a new public key scheme is pr= oposed (e.g. pairing-based, quantum-resistant, homomorphic, etc.). Should de= velopers of application standards, who may be using signatures and encryption at a high level interface allowing a= lgorithm agility, always use key separation to prevent potential dual use at= tacks?  Or should developers and cryptographers have to keep a sharp ey= e out for dual use attacks, or else proofs of security against dual use, before considering public key schemes= secure?

 

Best regards,

 

Dani= el Brown

Res= earch In Motion Limited

 <= /p>

 <= /p>

 

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential infor= mation, privileged material (including material protected by the solicitor-c= lient or other applicable privileges), or constitute non-public information.= Any use of this information by anyone other than the intended recipient is= prohibited. If you have received this transmission in error, please immedia= tely reply to the sender and delete this information from your system. Use,= dissemination, distribution, or reproduction of this transmission by uninte= nded recipients is not authorized and may be unlawful. --_000_810C31990B57ED40B2062BA10D43FBF5080E01XMB111CNCrimnet_-- --_004_810C31990B57ED40B2062BA10D43FBF5080E01XMB111CNCrimnet_ Content-Type: image/gif; name="image001.gif" Content-Description: image001.gif Content-Disposition: inline; filename="image001.gif"; size=2577; creation-date="Fri, 08 Jun 2012 17:51:12 GMT"; modification-date="Fri, 08 Jun 2012 17:51:12 GMT" Content-ID: Content-Transfer-Encoding: base64 R0lGODlhjQAiANUAAF5bXMrJydjX1zIvMF5bW+Xl5fLx8UE9PsvKyvPy8np3eJSTkzIvL5WTlMvK ycrKybCvr4eFhk9MTV5cXJSSk6KhoEI+PoeGhmtqaXp4eOTk5KOhoa+urmxqab68vUE9PZWTk727 vHp3d2xqauTl5LCvrtjY19nY2FBNTdnY16KgoKOhoE9MTL28vK+vrvPy8WtpaTIuLzEuL11bW4iG hkI9Pr68vIiGh09NTSMfHyQgICMfICQfIP///wAAAAAAACH/C1hNUCBEYXRhWE1QPD94cGFja2V0 IGJlZ2luPSLvu78iIGlkPSJXNU0wTXBDZWhpSHpyZVN6TlRjemtjOWQiPz4gPHg6eG1wbWV0YSB4 bWxuczp4PSJhZG9iZTpuczptZXRhLyIgeDp4bXB0az0iQWRvYmUgWE1QIENvcmUgNS4wLWMwNjAg NjEuMTM0Nzc3LCAyMDEwLzAyLzEyLTE3OjMyOjAwICAgICAgICAiPiA8cmRmOlJERiB4bWxuczpy ZGY9Imh0dHA6Ly93d3cudzMub3JnLzE5OTkvMDIvMjItcmRmLXN5bnRheC1ucyMiPiA8cmRmOkRl c2NyaXB0aW9uIHJkZjphYm91dD0iIiB4bWxuczp4bXA9Imh0dHA6Ly9ucy5hZG9iZS5jb20veGFw LzEuMC8iIHhtbG5zOnhtcE1NPSJodHRwOi8vbnMuYWRvYmUuY29tL3hhcC8xLjAvbW0vIiB4bWxu czpzdFJlZj0iaHR0cDovL25zLmFkb2JlLmNvbS94YXAvMS4wL3NUeXBlL1Jlc291cmNlUmVmIyIg eG1wOkNyZWF0b3JUb29sPSJBZG9iZSBQaG90b3Nob3AgQ1M1IFdpbmRvd3MiIHhtcE1NOkluc3Rh bmNlSUQ9InhtcC5paWQ6QTk5QzA5MUNFQkExMTFFMDg4OTZBOEYxNkFFRjgzRjEiIHhtcE1NOkRv Y3VtZW50SUQ9InhtcC5kaWQ6QTk5QzA5MURFQkExMTFFMDg4OTZBOEYxNkFFRjgzRjEiPiA8eG1w TU06RGVyaXZlZEZyb20gc3RSZWY6aW5zdGFuY2VJRD0ieG1wLmlpZDpBOTlDMDkxQUVCQTExMUUw ODg5NkE4RjE2QUVGODNGMSIgc3RSZWY6ZG9jdW1lbnRJRD0ieG1wLmRpZDpBOTlDMDkxQkVCQTEx MUUwODg5NkE4RjE2QUVGODNGMSIvPiA8L3JkZjpEZXNjcmlwdGlvbj4gPC9yZGY6UkRGPiA8L3g6 eG1wbWV0YT4gPD94cGFja2V0IGVuZD0iciI/PgH//v38+/r5+Pf29fTz8vHw7+7t7Ovq6ejn5uXk 4+Lh4N/e3dzb2tnY19bV1NPS0dDPzs3My8rJyMfGxcTDwsHAv769vLu6ubi3trW0s7KxsK+urayr qqmop6alpKOioaCfnp2cm5qZmJeWlZSTkpGQj46NjIuKiYiHhoWEg4KBgH9+fXx7enl4d3Z1dHNy cXBvbm1sa2ppaGdmZWRjYmFgX15dXFtaWVhXVlVUU1JRUE9OTUxLSklIR0ZFRENCQUA/Pj08Ozo5 ODc2NTQzMjEwLy4tLCsqKSgnJiUkIyIhIB8eHRwbGhkYFxYVFBMSERAPDg0MCwoJCAcGBQQDAgEA ACH5BAAAAAAALAAAAACNACIAAAb/wJ5wSCwaj8ikcslsOp/QqHRKrVqv2Kx2y+16v+CweEwum89o 7oYwAQA8wgsBQOgI0vh8D6Db8XgDQn88OjwdeohmO4uLDD0Cg3+HiZRgAn6EORw9Kn08OQN3Ag8B AXdFpAgIpQ+nQyelBVsODgEJRwIItaUBDpVDBrWrGkIFugEIt3s5zDoRRZk8O54HLUMWfQ9aBn45 skY4hNLSoA2/UMyDAEQBOdLTjH8BPQY5hQZaD4UfSIv2hX925DBHSYQ0HQcgCEGxiIeEOwHG5dih gEiFaQPcABggDkMPD58ObFmgI8ekIgim6Zgz4QOzHY4oSfAEkx6jQodCEJgDYIEy/yEY3HkUYkCC tHUUpI1gp4BAjgMzSqDMYPQABoVDJvShIMTEiJ0AFLjjNwQDvCEFRBi1AMNXEQMUwN4psIEOgDYX iHigMwHfkXGLRAYoJDBHxSUHFlUgAsCPR608FguJ4AdgnwxDLhDCdNQvA3mPBkzkwaGDtJM9LhSS IQTC6NE8DgsRINrejgQQYryTEJjIgT8ikAwWx8BFj6SYDohChsDvkAQCdVRAFmIEIR0hesSY5lZz ST8CP5noscDd5nfOehT4nuAEAx06BiDo8aGQggCkKC/iWgKg+T47LFDMAPB9YgECAf0RwSc8DLHB JwM499YDtWhTDH6mDJGYedYMEf9RdJ/Ak8MNPWhQiA5CmPgHAbIkYIEfARQAHgMbBNDAdzoY4ME0 ByDAgDvK9fCCJwH9s8NSCXD0FBwCoPBHTAoQMgAIpgDwhwwc2OKODrIYMIAfBFlhQCQ7rDMEBfCQ s9kGrfUhQTGrxBgABBmAF0AGJTHgSgWjBRCBOxyVJIEyCAA0ziDP9HDRRN/0kEAfOmjzZWRCkHCi KwdMNF8Di1ggBU9h4fMheMENYeUOB7TxpSe+qKaDbCRE8FtDABnwYg40oORAMo2F6I5zCxDCwAwA fBDQDotNsOVBlTFDiz0NtrkDC4z9wYEG0/DQ4RMapCONOQ18Ep8CEjIwjQpDkPD/5Q6H8CFda+mY ly0/zcyDBGDjYNUDAZ9gJsQLLEjjKb+fMPNSQA5ssIiZPfzJQ6JCNGDPAgr4wfATHhDmh4BKYCuQ Kz1kMNEEPXQjynUHLODBAxdM5NE72R2RQkADGLUDAUNMqq+iheSwB3wo0MHTBHOQECUPYQIwkVRD VFDIi36A7ARlf+TAAAlLpLQIEQWYywMAl3wixAI8+pWAuTmgm2kOJAtxQmUUcNCIAOv9MV8PDLqS AAt+OGKWYeyUcseGMeP9x3geAuiHbFAIQEspPyURtgUUULAABqtG5oA4xIQLSAgJlGBBiPMZdJQN K3zpTgoRlHQYAdOYWfACIFDM/9HiPXAAX4AkFFDnIhA86s43JhRcBHSeDBC5GDVg0k1AKJT4hycR Jbjl1ur9yCBsec2kwyY9PNBnD2KFB94fA3wz63WbvfnAk0Os8MfFQigZ4BkCeL2ZHyMoM8H064hS ZeLTkCFA4DOG4kGpCuaKXq0jATPJlkBuloIhCOA359nBoHoQrh3AYAgV40FeijABP4gEDQaAQAMa sIAGbKBR9FiAG9jUAxcIjQIGoN0CGlWACLiBABmwVwFqxzEhpKABIMBhayiARBYijggGWAFPRmAc IYRghXfrQQmQKLW65QAO5wijGGCnA/qJ8Yz5CM8J0MjGLXxgEYxroxynwAEIwRRwjnh8ggCQIbU8 +vGPgAykIPMYBAA7 --_004_810C31990B57ED40B2062BA10D43FBF5080E01XMB111CNCrimnet_-- From Kenny.Paterson@rhul.ac.uk Fri Jun 8 13:52:37 2012 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 9A61811E8187 for ; Fri, 8 Jun 2012 13:52:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.317 X-Spam-Level: X-Spam-Status: No, score=0.317 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z0nt0Cu91N-S for ; Fri, 8 Jun 2012 13:52:36 -0700 (PDT) Received: from gse-mta-17.emailfiltering.com (ixe-mta-17-tx.emailfiltering.com [194.116.198.149]) by ietfa.amsl.com (Postfix) with ESMTP id 15FDC11E8188 for ; Fri, 8 Jun 2012 13:52:32 -0700 (PDT) Received: from exch-hub02.rhul.ac.uk ([134.219.208.108]) by gse-mta-17.emailfiltering.com with emfmta (version 4.8.5.86) by TLS id 3146249364 ;47c4b4fdd74b9463; Fri, 08 Jun 2012 21:52:32 +0100 Received: from exch-cas01.cc.rhul.local (134.219.208.109) by EXCH-HUB02.cc.rhul.local (134.219.208.108) with Microsoft SMTP Server (TLS) id 14.2.247.3; Fri, 8 Jun 2012 21:52:31 +0100 Received: from EXCH-MB02.cc.rhul.local ([169.254.1.13]) by exch-cas01.cc.rhul.local ([2002:86db:d06d::86db:d06d]) with mapi id 14.02.0247.003; Fri, 8 Jun 2012 21:52:30 +0100 From: "Paterson, Kenny" To: Dan Brown Thread-Topic: [Cfrg] [CFRG] Dual use (vs key separation) questions Thread-Index: Ac1Fpq/Et+mFYYSRSwSCB6UjcN4rjwACYvUA Date: Fri, 8 Jun 2012 20:52:29 +0000 Message-ID: References: <810C31990B57ED40B2062BA10D43FBF5080E01@XMB111CNC.rim.net> In-Reply-To: <810C31990B57ED40B2062BA10D43FBF5080E01@XMB111CNC.rim.net> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [78.146.60.38] Content-Type: multipart/alternative; boundary="_000_D8537542E09944C9B1EE9960DE5DD702rhulacuk_" MIME-Version: 1.0 Cc: "cfrg@ietf.org" Subject: Re: [Cfrg] [CFRG] Dual use (vs key separation) questions X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jun 2012 20:52:37 -0000 --_000_D8537542E09944C9B1EE9960DE5DD702rhulacuk_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Dan, I think I can answer some of your questions - see in-line below. Let me kno= w if I mis-understood anything. On 8 Jun 2012, at 19:44, Dan Brown wrote: Dear CFRG members, My colleague Alex Truskovsky has brought to my attention the issue of dual = use of a single private key (of a public key scheme, e.g. RSA or ECC), wher= e the private key is used for both signing and for key exchange (such as de= cryption or key agreement). Some standards address dual use: 1: NIST Special Publication 800-57 forbids a dual use with one exception: a= key exchange private key may be used to sign a certificate request. 2: PKIX certificates (a) can be configured to allow or forbid dual use (tho= ugh this may only apply to the public key side), and (b) when a cert for ke= y exchange key forbids =93dual use=94, a signed certificate request is also= forbidden. Restrictions against dual use are usually called key separation. Above, 1 = is key separation (with exception), and 2b is key separation (when the cert= asks for it). Questions (not necessarily independent): So, in terms of =93dual use=94, NIST and PKIX are not totally aligned. Sho= uld there be better alignment? For example, should PKIX move towards NIST = by hardening (a) to forbid dual use, and softening (b) to allow dual use si= gned cert requests? No idea, sorry. Are there scheme-generic attacks of dual use? Of course, dual use introduc= es a potential risk, which can be shown by using a contrived pathological e= xample, in which any use of the signature scheme reveals the private, but I= am asking here if there is an attack that applies for schemes, even when b= oth schemes are secure. Here, I think you mean: can it be shown that dual use always leads to crypt= ographic weakness, no matter what the key or algorithm? The answer is then = "no", in the sense that there are combined signature and encryption (CSE) s= chemes which are provably "jointly secure", i.e. where the dual use of the = key provides both a secure encryption and a secure signature scheme, even w= hen the adversary has simultaneous access to signing/decryption oracles for= the two schemes. For a recent paper on this, with constructions of schemes= in the standard model, and extensive references to the prior literature, s= ee: K.G. Paterson, J.C.N. Schuldt, M. Stam and S. Thomson, On the Joint Securit= y of Encryption and Signature, Revisited. In D.H. Lee and X. Wang (eds.), A= siacrypt 2011, Lecture Notes in Computer Science Vol. 7073, pp. 161-178, Sp= ringer, 2011. (Full version at: http://eprint.iacr.org/2011/486) This paper also contains pathological examples of the type you mention. For= example, we describe encryption and signature schemes that are individuall= y IND-CCA and UF-CMA secure, but whose security totally falls apart once du= al use is allowed. Dual use raw RSA, i.e. without padding, is subject to some severe attacks: = (i) chosen-ciphertext forgery, where a signature is forged using a decrypti= on oracle, and (ii) chosen-message decipherment, where a challenge cipherte= xt is deciphered using a signing oracle, because decryption and signing are= the same operation in raw RSA. In both attacks the private key owner foll= ows key separation, so key separation prevents these attacks only if done o= n the public key side. Are these attacks the main justification for key se= paration? Are there any other scheme-specific attacks with dual use? For = example, is there any other attack (e.g. even stronger, not using an oracle= for the private key operation, i.e. a more passive attack) on raw RSA? Is= there any attack on any type of padded RSA? (I think I saw one paper on it= .) Yes. See for example: J.P. Degabriele, A. Lehmann, K.G. Paterson, N.P. Smart and M. Strefler, On = the Joint Security of Encryption and Signature in EMV. In O. Dunkelmann (ed= .), CT-RSA 2012, Lecture Notes in Computer Science Vol. 7178, pp. 116-135, = Springer, 2012. (Full version at: http://eprint.iacr.org/2011/615) This paper gives an attack which shows how to use a Bleichenbacher-style or= acle for RSA-PKCS#1v1.5 encryption to forge EMV signatures for the same RSA= key pair , in the specific context of EMV. So it's an example of the type = you seek. Is there an attack on ECDH and ECDSA dual use? Not currently known. But the above paper does prove security of dual use fo= r ECDSA +ECIES and EC-Schnorr+ECIES. And ECDH is sufficiently close to ECIE= S that I'd guess the proofs could be adapted to the ECDH case. Let me know = if you are seriously interested in knowing the answer to this question. Security proofs, e.g. for RSA-OAEP, often assume dual use is forbidden. Wh= at security analysis (e.g. proofs) work under =93dual use=94? A paper by P= aterson does this, and mentions some others, but they seem not to cover the usual I= ETF schemes? Thanks for the mention. I guess this is the Asiacrypt paper above, which an= swers some of your earlier questions. If there are specific pairs of scheme= s which you are interested in (e.g. RSA-OAEP + ???) let me know and I can p= ut a student to work on it :-). Offhand, generally schemes in the ROM are OK, especially if you allow a bit= of domain separation in the inputs to the Random Oracle(s). Does universal composability also address dual use? I'm not an expert on UC, but I very much doubt it automatically covers this= . Maybe the UC experts can pitch in here. Do the current conventional most common suite of public key schemes in IETF= sufficiently resist dual attacks? Again, what specific schemes do you have in mind? (Note that TLS still uses= PKCS#1 v1.5 for RSA encryption, so we won't be able to prove anything ther= e...) So, is key separation overkill for these schemes? Or, should key separatio= n be added as precaution, because of a lack of thorough study? Clearly, it's a good idea to enforce it if you can afford the additional co= sts of key generation (non-trivial if you have a deployment involving milli= ons of EMV cards, each containing a unique RSA key pair), certificate manag= ement, etc. What general expectations should there be for public key schemes regarding = dual use? Suppose a new public key scheme is proposed (e.g. pairing-based,= quantum-resistant, homomorphic, etc.). Should developers of application st= andards, who may be using signatures and encryption at a high level interfa= ce allowing algorithm agility, always use key separation to prevent potenti= al dual use attacks? Personally, I would recommend this, because it's hard to anticipate exactly= what schemes people will try to use and how they will end up being impleme= nted. If there's a general principle we can apply which improves security a= nd which is not too costly, then we should apply it. I say this despite the= many known positive results on the security of dual use. Or should developers and cryptographers have to keep a sharp eye out for d= ual use attacks, or else proofs of security against dual use, before consid= ering public key schemes secure? See above. Best regards, Daniel Brown Research In Motion Limited Cheers Kenny --_000_D8537542E09944C9B1EE9960DE5DD702rhulacuk_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable Dan,

I think I can answer some of your questions - see in-line below. Let m= e know if I mis-understood anything.

On 8 Jun 2012, at 19:44, Dan Brown wrote:

Dear CFRG members,
 
My colleague Alex Truskovsky has brought to my attention the issue of dual = use of a single private key (of a public key scheme, e.g. RSA or ECC), wher= e the private key is used for both signing and for key exchange (such as de= cryption or key agreement).  Some standards address dual use:
 
1: NIST Special Publication 800-57 forbids a dual use with one exception: a= key exchange private key may be used to sign a certificate request. <= o:p>
 
2: PKIX certificates (a) can be configured to allow or forbid dual use (tho= ugh this may only apply to the public key side), and (b) when a cert for ke= y exchange key forbids =93dual use=94, a signed certificate request is also= forbidden. 
 
Restrictions against dual use are usually called key separation.  Abov= e, 1 is key separation (with exception), and 2b is key separation (when the= cert asks for it).
 
Questions (not necessarily independent):
 
So, in terms of =93dual use=94, NIST and PKIX are not totally aligned. = ; Should there be better alignment?  For example, should PKIX move tow= ards NIST by hardening (a) to forbid dual use, and softening (b) to allow d= ual use signed cert requests?

No idea, sorry.

Are there scheme-generic attacks of dual use?  Of course, dual use int= roduces a potential risk, which can be shown by using a contrived pathologi= cal example, in which any use of the signature scheme reveals the private, = but I am asking here if there is an attack that applies for schemes, even when both schemes are secure.

Here, I think you mean: can it be shown that dual use always leads to = cryptographic weakness, no matter what the key or algorithm? The answe= r is then "no", in the sense that there are combined signature an= d encryption (CSE) schemes which are provably "jointly secure", i.e. where the dual use of the key provides both a secure en= cryption and a secure signature scheme, even when the adversary has simulta= neous access to signing/decryption oracles for the two schemes. For a recen= t paper on this, with constructions of schemes in the standard model, and extensive references to the prior liter= ature, see:

K.G. Paterson, J.C.N. Schuldt, M. Stam and S. Thomson, On the Joint Se= curity of Encryption and Signature, Revisited. In D.H. Lee and X. Wang (eds.), Asiacrypt 2011, Lecture Notes in Comput= er Science Vol. 7073, pp. 161-178, Springer, 2011.


This paper also contains pathological examples of the type you mention= . For example, we describe encryption and signature schemes that are indivi= dually IND-CCA and UF-CMA secure, but whose security totally falls apart on= ce dual use is allowed.

Dual use raw RSA, i.e. without padding, is subject to some severe attacks: = (i) chosen-ciphertext forgery, where a signature is forged using a decrypti= on oracle, and (ii) chosen-message decipherment, where a challenge cipherte= xt is deciphered using a signing oracle, because decryption and signing are the same operation in raw RSA.&= nbsp; In both attacks the private key owner follows key separation, so key = separation prevents these attacks only if done on the public key side. = ; Are these attacks the main justification for key separation?  Are there any other scheme-specific attacks with= dual use?  For example, is there any other attack (e.g. even stronger= , not using an oracle for the private key operation, i.e. a more passive at= tack) on raw RSA?  Is there any attack on any type of padded RSA? (I think I saw one paper on it.)

Yes. See for example:

J.P. Degabriele, A. Lehmann, K.G. Paterson, N.P. Smart and M. Strefler= , On the Joint Security of Encryption and Signature in EMV. In O. Dunkelmann (ed.), CT-RSA 2012, Lecture Notes in Computer Science = Vol. 7178, pp. 116-135, Springer, 2012.


This paper gives an attack which shows how to use a Bleichenbacher-sty= le oracle for RSA-PKCS#1v1.5 encryption to forge EMV signatures for the sam= e RSA key pair , in the specific context of EMV. So it's an example of the = type you seek.

Is there an attack on ECDH and ECDSA dual use?

Not currently known. But the above paper does prove security of dual u= se for ECDSA +ECIES and EC-Schnorr+ECIES. And ECDH is sufficiently = close to ECIES that I'd guess the proofs could be adapted to the ECDH case.= Let me know if you are seriously interested in knowing the answer to this question.

Security proofs, e.g. for RSA-OAEP, often assume dual use is forbidden.&nbs= p; What security analysis (e.g. proofs) work under =93dual use=94?  A = paper by Paterson
does this, and mentions some others, but they seem not to cover the usual I= ETF schemes? 

Thanks for the mention. I guess this is the Asiacrypt paper above, whi= ch answers some of your earlier questions. If there are specific pairs of s= chemes which you are interested in (e.g. RSA-OAEP + ???) let me know an= d I can put a student to work on it :-). 

Offhand, generally schemes in the ROM are OK, especially if you allow = a bit of domain separation in the inputs to the Random Oracle(s).

Does universal composability also address dual use?

I'm not an expert on UC, but I very much doubt it automatically covers= this. Maybe the UC experts can pitch in here.

Do the current conventional most common suite of public key schemes in IETF= sufficiently resist dual attacks?

Again, what specific schemes do you have in mind? (Note that TLS still= uses PKCS#1 v1.5 for RSA encryption, so we won't be able to prove anything= there...)

So, is key separation overkill for these schemes?  Or, should key sepa= ration be added as precaution, because of a lack of thorough study?

Clearly, it's a good idea to enforce it if you can afford the additional co= sts of key generation (non-trivial if you have a deployment involving milli= ons of EMV cards, each containing a unique RSA key pair), certificate manag= ement, etc.

What general expectations should there be for public key schemes regarding = dual use?  Suppose a new public key scheme is proposed (e.g. pairing-b= ased, quantum-resistant, homomorphic, etc.). Should developers of applicati= on standards, who may be using signatures and encryption at a high level interface allowing algorithm agility, alway= s use key separation to prevent potential dual use attacks?

Personally, I would recommend this, because it's hard to anticipate ex= actly what schemes people will try to use and how they will end up being im= plemented. If there's a general principle we can apply which improves secur= ity and which is not too costly, then we should apply it. I say this despite the many known positive result= s on the security of dual use.

 Or should developers and cryptographers have to keep a sharp eye out = for dual use attacks, or else proofs of security against dual use, before c= onsidering public key schemes secure?

See above.

 
Best regards,
 
Daniel Brown

Research In Motion Limited


Cheers

Kenny

--_000_D8537542E09944C9B1EE9960DE5DD702rhulacuk_-- From mcgrew@cisco.com Mon Jun 11 17:46:05 2012 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 8B3EC11E808F for ; Mon, 11 Jun 2012 17:46:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.598 X-Spam-Level: X-Spam-Status: No, score=-110.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PHS51+wzw8uH for ; Mon, 11 Jun 2012 17:46:04 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id A6B5011E8087 for ; Mon, 11 Jun 2012 17:46:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mcgrew@cisco.com; l=6901; q=dns/txt; s=iport; t=1339461964; x=1340671564; h=from:mime-version:subject:date:references:cc:to: message-id; bh=B3zVpMEN7u8aJDEkZRqvFnH22Ipnv6SUCyIoKljWG2k=; b=fTOcEwBb8pEZ4ZZ33XIWnjlHB679TbD96cdb9NnWExRm7h4dETPFKd6A RSH3ZbjXLMM8adQaNO7kw8r0NPnfgRM89Nj2czMeB2VVZeLuDPl5GPW/O SVgU02RwMUagGX4ogvz0Jn+UsCsrpM7u/HQ4V2ob6+F1vtANl7wVmPmVZ I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApIGAAGR1k+tJV2d/2dsb2JhbABFpGiHMgGIfYEHghgBAQEDARIBZAIFCxwDAQIvTQIIGQkZh2QFC5kcn3KLJIUxYAOVHoESjQOBZoJ8 X-IronPort-AV: E=Sophos;i="4.75,752,1330905600"; d="scan'208,217";a="91571789" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-3.cisco.com with ESMTP; 12 Jun 2012 00:46:04 +0000 Received: from rtp-vpn3-1531.cisco.com (rtp-vpn3-1531.cisco.com [10.82.222.2]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id q5C0k2c2010805; Tue, 12 Jun 2012 00:46:03 GMT From: David McGrew Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/alternative; boundary="Apple-Mail=_3E73591F-3246-4BB6-BE3C-4ED5E98B3610" Date: Mon, 11 Jun 2012 20:46:01 -0400 References: <20120612004334.9198.82973.idtracker@ietfa.amsl.com> To: cfrg@irtf.org Message-Id: X-Mailer: Apple Mail (2.1278) Subject: [Cfrg] Fwd: New Version Notification for draft-mcgrew-aead-aes-cbc-hmac-sha2-00.txt X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jun 2012 00:46:05 -0000 --Apple-Mail=_3E73591F-3246-4BB6-BE3C-4ED5E98B3610 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, Kenny and I put together this internet draft defining AEAD algorithms = based on AES-CBC and HMAC-SHA. The main idea behind this work is that = current and future standards efforts that use CBC and HMAC can use AEAD, = and thus omit unauthenticated encryption altogether. Your feedback = will be welcome. thanks, David Begin forwarded message: > From: internet-drafts@ietf.org > Subject: New Version Notification for = draft-mcgrew-aead-aes-cbc-hmac-sha2-00.txt > Date: June 11, 2012 8:43:34 PM EDT > To: mcgrew@cisco.com > Cc: kenny.paterson@rhul.ac.uk >=20 >=20 > A new version of I-D, draft-mcgrew-aead-aes-cbc-hmac-sha2-00.txt > has been successfully submitted by David A. McGrew and posted to the > IETF repository. >=20 > Filename: draft-mcgrew-aead-aes-cbc-hmac-sha2 > Revision: 00 > Title: Authenticated Encryption with AES-CBC and = HMAC-SHA > Creation date: 2012-06-11 > WG ID: Individual Submission > Number of pages: 23 > URL: = http://www.ietf.org/internet-drafts/draft-mcgrew-aead-aes-cbc-hmac-sha2-00= .txt > Status: = http://datatracker.ietf.org/doc/draft-mcgrew-aead-aes-cbc-hmac-sha2 > Htmlized: http://tools.ietf.org/html/submission.filename }}-00 >=20 >=20 > Abstract: > This document specifies algorithms for authenticated encryption with > associated data (AEAD) that are based on the composition of the > Advanced Encryption Standard (AES) in the Cipher Block Chaining = (CBC) > mode of operation for encryption, and the HMAC-SHA message > authentication code (MAC). >=20 > These are randomized encryption algorithms, and thus are suitable = for > use with applications that cannot provide distinct nonces to each > invocation of the AEAD encrypt operation. >=20 >=20 >=20 >=20 > The IETF Secretariat --Apple-Mail=_3E73591F-3246-4BB6-BE3C-4ED5E98B3610 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Subject: New Version Notification for = draft-mcgrew-aead-aes-cbc-hmac-sha2-00.txt
Date: June 11, 2012 = 8:43:34 PM EDT
Cc: kenny.paterson@rhul.ac.uk

A new version of I-D, = draft-mcgrew-aead-aes-cbc-hmac-sha2-00.txt
has been successfully = submitted by David A. McGrew and posted to the
IETF = repository.

Filename: = draft-mcgrew-aead-aes-cbc-hmac-sha2
Revision: = 00
Title: = = Authenticated Encryption with AES-CBC and HMAC-SHA
Creation = date: = 2012-06-11
WG ID: Individual Submission
Number = of pages: 23
URL: =             http://www.ietf.org/internet-drafts/draft-mcgrew-aead-aes-cb= c-hmac-sha2-00.txt
Status: =          http://datatracker.ietf.org/doc/draft-mcgrew-aead-aes-cbc-hmac-sha2=
Htmlized:        http://tools.ietf.= org/html/submission.filename }}-00


Abstract:
=   This document specifies algorithms for authenticated = encryption with
  associated data (AEAD) that are based on = the composition of the
  Advanced Encryption Standard = (AES) in the Cipher Block Chaining (CBC)
  mode of = operation for encryption, and the HMAC-SHA message
=   authentication code (MAC).

  These are = randomized encryption algorithms, and thus are suitable for
=   use with applications that cannot provide distinct nonces to = each
  invocation of the AEAD encrypt = operation.




The IETF = Secretariat

= --Apple-Mail=_3E73591F-3246-4BB6-BE3C-4ED5E98B3610-- From James.H.Manger@team.telstra.com Tue Jun 12 19:32:39 2012 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 4A22721F8643 for ; Tue, 12 Jun 2012 19:32:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.79 X-Spam-Level: X-Spam-Status: No, score=-0.79 tagged_above=-999 required=5 tests=[AWL=-0.489, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, J_CHICKENPOX_41=0.6, RELAY_IS_203=0.994] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9l8E3JQwc6UZ for ; Tue, 12 Jun 2012 19:32:38 -0700 (PDT) Received: from ipxbno.tcif.telstra.com.au (ipxbno.tcif.telstra.com.au [203.35.82.204]) by ietfa.amsl.com (Postfix) with ESMTP id 7CB9421F863B for ; Tue, 12 Jun 2012 19:32:34 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.77,400,1336312800"; d="scan'208";a="76518894" Received: from unknown (HELO ipcani.tcif.telstra.com.au) ([10.97.216.200]) by ipobni.tcif.telstra.com.au with ESMTP; 13 Jun 2012 12:32:33 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,6740"; a="17071403" Received: from wsmsg3754.srv.dir.telstra.com ([172.49.40.198]) by ipcani.tcif.telstra.com.au with ESMTP; 13 Jun 2012 12:32:33 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3754.srv.dir.telstra.com ([172.49.40.198]) with mapi; Wed, 13 Jun 2012 12:32:32 +1000 From: "Manger, James H" To: "cfrg@irtf.org" , David McGrew Date: Wed, 13 Jun 2012 12:32:31 +1000 Thread-Topic: draft-mcgrew-aead-aes-cbc-hmac-sha2-00: unsafe to optionally hash A's length Thread-Index: Ac1Il9We7OUFiS6ZT1mPEv0MCuf7aQAbOzCQ Message-ID: <255B9BB34FB7D647A506DC292726F6E114F557CCA2@WSMSG3153V.srv.dir.telstra.com> References: <1B8956F6-81C5-4921-BA03-4097BE58F471@bbn.com> In-Reply-To: <1B8956F6-81C5-4921-BA03-4097BE58F471@bbn.com> Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: [Cfrg] draft-mcgrew-aead-aes-cbc-hmac-sha2-00: unsafe to optionally hash A's length X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jun 2012 02:32:39 -0000 UkU6IEF1dGhlbnRpY2F0ZWQgRW5jcnlwdGlvbiB3aXRoIEFFUy1DQkMgYW5kIEhNQUMtU0hBDQoN CkdyZWF0IGRvY3VtZW50Lg0KDQpJIGFtIG5vdCBjZXJ0YWluIHRoYXQgdGhlIHdheSB0aGUgbGVu Z3RoIG9mIHRoZSBhZGRpdGlvbmFsIGRhdGEgKEEpIGlzIG9wdGlvbmFsbHkgaGFzaGVkIGlzIHNh ZmUuDQoNCjEuIExlZ2l0aW1hdGUgdXNlciBzZW5kcyBBIGFuZCBDID0gUyB8fCBULCB3aGVyZSBU ID0gSE1BQyhBIHx8IFMgfHwgbGVuKEEpKS4NCg0KMi4gQXR0YWNrZXIgaW50ZXJjZXB0cyAmIHJl YXJyYW5nZXMgdGhlIG1lc3NhZ2UsIHNlbmRpbmcgYW4gZW1wdHkgQScgYW5kIEMnID0gQSB8fCBT IHx8IGxlbihBKSB8fCBULg0KDQozLiBSZWNpcGllbnQgdmVyaWZpZXMgVCcgPSBITUFDKFMnKSwg c2luY2UgbGVuKEEpID0gMCA9IE1JTl9MRU5fQSBzbyBBTCBpcyBlbXB0eS4NCiAgVCcgPSBITUFD KFMnKSA9IEhNQUMoQSB8fCBTIHx8IGxlbihBKSkgPSBUDQpUaGUgdmVyaWZpY2F0aW9uIHBhc3Nl cyEgWWlrZXMhIFRoZSByZWNpcGllbnQgbm93IGdldHMgZ2FyYmFnZSBmcm9tIHRoZSBkZWNyeXB0 aW9uLg0KVGhlIGF0dGFjayBtaWdodCBvbmx5IHdvcmsgaWYgbGVuKEEpIG1vZCAxMjggPSA2NCwg YnV0IHRoYXQgaXMgbm90IGhhcmQgZW5vdWdoLg0KDQoNCkFuIGF0dGFjayBjYW4gYWxzbyB3b3Jr IGlmIHRoZSBsZWdpdGltYXRlIHVzZXIgc2VuZHMgYW4gZW1wdHkgQS4NCjEuIExlZ2l0aW1hdGUg dXNlciBzZW5kcyBlbXB0eSBBIGFuZCBDID0gUyB8fCBULCB3aGVyZSBUID0gSE1BQyhTKS4NCg0K Mi4gQXR0YWNrZXIgc3BsaXRzIFMgaW50byAzIHBhcnRzLCBTID0gUzEgfHwgUzIgfHwgUzMsIGNo b29zaW5nIGxlbihTMykgPSA2NCBhbmQgbGVuKFMxKSA9IFMzLiBUaGUgYXR0YWNrZXIgc2VuZHMg QScgPSBTMSBhbmQgQycgPSBTMiB8fCBULg0KDQozLiBSZWNpcGllbnQncyB2ZXJpZmljYXRpb24g d29ya3MhIFlpa2VzIQ0KICBUJyA9IEhNQUMoQScgfHwgUycgfHwgbGVuKEEpKSA9IEhNQUMoUzEg fHwgUzIgfHwgUzMpID0gSE1BQyhTKSA9IFQNClRoZSByZWNpcGllbnQgbm93IGdldHMgZ2FyYmFn ZSBmcm9tIHRoZSBkZWNyeXB0aW9uLg0KVGhlIGF0dGFjayBtaWdodCBvbmx5IHdvcmsgaWYgdGhl IGxhc3QgNjQgYml0cyBhcmUgYSBzbWFsbCBlbm91Z2ggaW50ZWdlciAoYW5kIGVxdWFsIDY0IG1v ZCAxMjgpLCBidXQgdGhhdCBpcyBub3QgaGFyZCBlbm91Z2guDQoNCg0KDQoNClR5cG9zOg0KDQpT ZWN0aW9uIDIuMTogVGhlIGxhc3QgcGFkZGluZyBzdHJpbmcgKFBTKSBpbiBzdGVwIDMgc2hvdWxk IGJlIDEwMTDigKYsIG5vdCAwRjBG4oCmLCBhcyBjYW4gYmUgc2VlbiBpbiB0aGUgUF85IGxpbmUg aW4gdGhlIHNlY3Rpb24gNS4xIHRlc3QgY2FzZS4gQ2hhbmdlIGl0IHRvOg0KDQogIFBTID0gMTAx MDEwMTAxMDEwMTAxMDEwMTAxMDEwMTAxMDEwMTAsIGlmIGxlbihQKSBtb2QgMTI4ID0gMC4NCg0K U2VjdGlvbiAyLjI6IERlY3J5cHRpb24gc3RlcCAzIHNob3VsZCByZWZlciB0byBlbmNyeXB0aW9u ICJzdGVwcyA1IGFuZCA2Iiwgbm90IGp1c3QgdG8gInN0ZXAgNSIuDQoNClNlY3Rpb24gMzogQSBy YW5kb20gSVYgc2hvdWxkIGhhdmUgbWluLWVudHJvcHkgd2l0aGluIDEgYml0IG9mIHRoZSBibG9j ayBzaXplICgxMjgtYml0cyksIG5vdCB3aXRoaW4gMSBiaXQgb2YgdGhlIGtleSBsZW5ndGggKHdo aWNoIGlzIGxvbmdlciB0aGFuIHRoZSBJViBmb3IgQUVTLTE5MiBhbmQgQUVTLTI1NiBhbGdvcml0 aG1zKS4NCg0KU2VjdGlvbiA0OiBTdHJheSAiIGF0IGVuZCBvZiBSYXRpb25hbGUuDQoNClNlY3Rp b24gNTogU29tZSBjYXNlcyBleHBsaWNpdGx5IGxpc3QgUFMgYW5kIEFMIHZhbHVlcywgb3RoZXJz IGRvbid0Lg0KDQotLQ0KSmFtZXMgTWFuZ2VyDQo= From daw@cs.berkeley.edu Wed Jun 13 10:46:22 2012 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 B8CC121F8567 for ; Wed, 13 Jun 2012 10:46:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_31=0.6, J_CHICKENPOX_41=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AtF3bX3YRCYj for ; Wed, 13 Jun 2012 10:46:22 -0700 (PDT) Received: from taverner.cs.berkeley.edu (taverner.CS.Berkeley.EDU [128.32.153.193]) by ietfa.amsl.com (Postfix) with ESMTP id 5A75E21F855F for ; Wed, 13 Jun 2012 10:46:22 -0700 (PDT) Received: from taverner.cs.berkeley.edu (localhost.localdomain [127.0.0.1]) by taverner.cs.berkeley.edu (8.14.2/8.14.2) with ESMTP id q5DHkLLg021821 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 13 Jun 2012 10:46:21 -0700 Received: (from daw@localhost) by taverner.cs.berkeley.edu (8.14.2/8.14.2/Submit) id q5DHkL8C021819; Wed, 13 Jun 2012 10:46:21 -0700 From: David Wagner Message-Id: <201206131746.q5DHkL8C021819@taverner.cs.berkeley.edu> To: cfrg@irtf.org Date: Wed, 13 Jun 2012 10:46:21 -0700 (PDT) Secret-Bounce-Tag: 9a029cbee41caf2ca77a77efa3c13981 X-Mailer: ELM [version 2.5 PL6] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [Cfrg] draft-mcgrew-aead-aes-cbc-hmac-sha2-00: unsafe to optionally hash A's length X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jun 2012 17:46:22 -0000 Manger, James H wrote: >I am not certain that the way the length of the additional data (A) is >optionally hashed is safe. > >1. Legitimate user sends A and C = S || T, where T = HMAC(A || S || len(A)). > >2. Attacker intercepts & rearranges the message, sending an empty A' and >C' = A || S || len(A) || T. > >3. Recipient verifies T' = HMAC(S'), since len(A) = 0 = MIN_LEN_A so AL >is empty. > T' = HMAC(S') = HMAC(A || S || len(A)) = T >The verification passes! Yikes! The recipient now gets garbage from the >decryption. Doesn't the length field take care of this concern? The recipient will try to verify whether T' = HMAC(A' || S' || len(A')), I presume. [not T' = HMAC(S'), as you wrote] Note that HMAC(A' || S' || len(A')) = HMAC(A' || S' || 0) = HMAC(S' || 0) = HMAC(A || S || len(A) || 0) which is not the same as HMAC(A || S || len(A)), i.e., it is not the same as T'. So the recipient's MAC check fail, and the recipient will reject the message. In short, the format looks fine to me. Have I misunderstood something somewhere? From daw@cs.berkeley.edu Wed Jun 13 12:34:58 2012 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 6BC6E21F8595 for ; Wed, 13 Jun 2012 12:34:58 -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=[AWL=0.300, BAYES_00=-2.599, J_CHICKENPOX_41=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id siPmKtWtpYq3 for ; Wed, 13 Jun 2012 12:34:57 -0700 (PDT) Received: from taverner.cs.berkeley.edu (taverner.CS.Berkeley.EDU [128.32.153.193]) by ietfa.amsl.com (Postfix) with ESMTP id D70F521F8569 for ; Wed, 13 Jun 2012 12:34:54 -0700 (PDT) Received: from taverner.cs.berkeley.edu (localhost.localdomain [127.0.0.1]) by taverner.cs.berkeley.edu (8.14.2/8.14.2) with ESMTP id q5DJYsDf024473 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 13 Jun 2012 12:34:54 -0700 Received: (from daw@localhost) by taverner.cs.berkeley.edu (8.14.2/8.14.2/Submit) id q5DJYssj024472; Wed, 13 Jun 2012 12:34:54 -0700 From: David Wagner Message-Id: <201206131934.q5DJYssj024472@taverner.cs.berkeley.edu> To: cfrg@irtf.org Date: Wed, 13 Jun 2012 12:34:54 -0700 (PDT) Secret-Bounce-Tag: 9a029cbee41caf2ca77a77efa3c13981 X-Mailer: ELM [version 2.5 PL6] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [Cfrg] draft-mcgrew-aead-aes-cbc-hmac-sha2-00: unsafe to optionally hash A's length X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jun 2012 19:34:58 -0000 David Wagner wrote: >Manger, James H wrote: >>I am not certain that the way the length of the additional data (A) is >>optionally hashed is safe. >> >>1. Legitimate user sends A and C = S || T, where T = HMAC(A || S || len(A)). >> >>2. Attacker intercepts & rearranges the message, sending an empty A' and >>C' = A || S || len(A) || T. >> >>3. Recipient verifies T' = HMAC(S'), since len(A) = 0 = MIN_LEN_A so AL >>is empty. >> T' = HMAC(S') = HMAC(A || S || len(A)) = T >>The verification passes! Yikes! The recipient now gets garbage from the >>decryption. > >Doesn't the length field take care of this concern? Oops, I was confused. I missed the following statement in Section 2.1 of the draft: 5. The octet string AL is computed as follows. If len(A) = MIN_LEN_A, then AL is the zero-length string. Otherwise, it is equal to the number of bits in A expressed as a 64-bit unsigned integer in network byte order. Consequently, my email was wrong, and James Manger was perfectly correct. Thank you to Santosh Chokhani for pointing out my error. So I think James Manger has a good point. Now that I re-read James's email more carefully, the special case for len(A) = MIN_LEN_A looks unsafe to me, too. The rationale does not explain why it is safe to include this special case. Some commentary on the rationale (Section 4): : The MIN_LEN_A parameter is included : so that it is possible to use CBC-HMAC in a way that corresponds to : existing uses of CBC and HMAC. Some existing systems (such as ESP or : IEEE 1619.1) make use of those algorithms, but do not include the : length of the associated data in the HMAC input. These systems can : be secure because the length of the associated data is fixed, or can : be inferred by other means. The MIN_LEN_A parameter allows the AL : field to be zero-length when both the encrypter and the decrypter : know the length of the associated data field. This enables : implementations of CBC-HMAC to be compatible with existing systems : that do not include the length of A in the HMAC input. This justifies why the special case provides compatibility, but does not justify why the special case is secure. Here's one possible way to handle this that might meet the security and compatibility needs. For each of the existing algorithms, you could create a separate partner algorithm that does not support authenticated data. In those algorithms, A and AL are always the empty string. It is assumed that the sender and recipient have an out-of-band way to agree on the algorithm used, with no possibility of confusion and no possibility for them to get out of sync on this; the security of the scheme relies upon this assumption. From mcgrew@cisco.com Wed Jun 13 13:23:25 2012 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 209A121F8474 for ; Wed, 13 Jun 2012 13:23:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.299 X-Spam-Level: X-Spam-Status: No, score=-110.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_41=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yNWbm0qBf7uc for ; Wed, 13 Jun 2012 13:23:24 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 0510811E8083 for ; Wed, 13 Jun 2012 13:23:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2860; q=dns/txt; s=iport; t=1339619004; x=1340828604; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=H5m0qakBn02ahX47ABL479ZlF+hDlmopAN/2yCumf/k=; b=lx//7eImSIIWoCw/hhwpSzRGQ2bO9CyPmsX4Z4M5HcZnu6s4tjbwq5+p xkTRjI4Vn9Tu53lkuAPDvhajgMz/KJ3aJ7igfvVJejjoSmO1dJCv0Io1h ddc/m44wXHevAFCOonov3LL3RJA4XbpAN5B8M9TYxdEHKdCptFt5n3k8E k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqcGAOD12E+tJXHA/2dsb2JhbABFsWmDWIEHghgBAQEDARIBZgULC0ZXBjWHZAWaMqAHizGFMWADlSGOFoFmgnw X-IronPort-AV: E=Sophos;i="4.75,766,1330905600"; d="scan'208";a="89219679" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-9.cisco.com with ESMTP; 13 Jun 2012 20:23:23 +0000 Received: from rtp-vpn5-1719.cisco.com (rtp-vpn5-1719.cisco.com [10.82.238.189]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id q5DKNMFM010967; Wed, 13 Jun 2012 20:23:22 GMT Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=windows-1252 From: David McGrew In-Reply-To: <255B9BB34FB7D647A506DC292726F6E114F557CCA2@WSMSG3153V.srv.dir.telstra.com> Date: Wed, 13 Jun 2012 16:23:21 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <149B9613-82A9-4D27-934D-A15F854233BE@cisco.com> References: <1B8956F6-81C5-4921-BA03-4097BE58F471@bbn.com> <255B9BB34FB7D647A506DC292726F6E114F557CCA2@WSMSG3153V.srv.dir.telstra.com> To: "Manger, James H" X-Mailer: Apple Mail (2.1278) Cc: "cfrg@irtf.org" Subject: Re: [Cfrg] draft-mcgrew-aead-aes-cbc-hmac-sha2-00: unsafe to optionally hash A's length X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jun 2012 20:23:25 -0000 Hi James, thanks for the quick feedback, more inline: On Jun 12, 2012, at 10:32 PM, Manger, James H wrote: > RE: Authenticated Encryption with AES-CBC and HMAC-SHA >=20 > Great document. >=20 > I am not certain that the way the length of the additional data (A) is = optionally hashed is safe. Agreed. MIN_LEN_A was an under analyzed suggestion of mine, intended = as a way to enable these AEAD algorithms to interoperate with some = existing implementations of CBC and HMAC. It is not clear that the = interoperability I was going for is even important, and as you point = out, the particular way that the length of A was included doesn't work. = Change is clearly needed. I suggest that Step 5 should read: "The = octet string AL is equal to the number of bits in A expressed as a = 64-bit unsigned integer in network byte order." >=20 > 1. Legitimate user sends A and C =3D S || T, where T =3D HMAC(A || S = || len(A)). >=20 > 2. Attacker intercepts & rearranges the message, sending an empty A' = and C' =3D A || S || len(A) || T. >=20 > 3. Recipient verifies T' =3D HMAC(S'), since len(A) =3D 0 =3D = MIN_LEN_A so AL is empty. > T' =3D HMAC(S') =3D HMAC(A || S || len(A)) =3D T > The verification passes! Yikes! The recipient now gets garbage from = the decryption. > The attack might only work if len(A) mod 128 =3D 64, but that is not = hard enough. >=20 >=20 > An attack can also work if the legitimate user sends an empty A. > 1. Legitimate user sends empty A and C =3D S || T, where T =3D = HMAC(S). >=20 > 2. Attacker splits S into 3 parts, S =3D S1 || S2 || S3, choosing = len(S3) =3D 64 and len(S1) =3D S3. The attacker sends A' =3D S1 and C' =3D= S2 || T. >=20 > 3. Recipient's verification works! Yikes! > T' =3D HMAC(A' || S' || len(A)) =3D HMAC(S1 || S2 || S3) =3D HMAC(S) = =3D T > The recipient now gets garbage from the decryption. > The attack might only work if the last 64 bits are a small enough = integer (and equal 64 mod 128), but that is not hard enough. >=20 >=20 >=20 >=20 > Typos: >=20 > Section 2.1: The last padding string (PS) in step 3 should be 1010=85, = not 0F0F=85, as can be seen in the P_9 line in the section 5.1 test = case. Change it to: >=20 > PS =3D 10101010101010101010101010101010, if len(P) mod 128 =3D 0. >=20 > Section 2.2: Decryption step 3 should refer to encryption "steps 5 and = 6", not just to "step 5". >=20 > Section 3: A random IV should have min-entropy within 1 bit of the = block size (128-bits), not within 1 bit of the key length (which is = longer than the IV for AES-192 and AES-256 algorithms). Agreed on all points. >=20 > Section 4: Stray " at end of Rationale. >=20 > Section 5: Some cases explicitly list PS and AL values, others don't. Thanks again! David >=20 > -- > James Manger From mcgrew@cisco.com Wed Jun 13 13:31:35 2012 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 DC1DE21F8463 for ; Wed, 13 Jun 2012 13:31:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.149 X-Spam-Level: X-Spam-Status: No, score=-110.149 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, J_CHICKENPOX_41=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id obXN8roAHRfb for ; Wed, 13 Jun 2012 13:31:35 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 89C0A11E8089 for ; Wed, 13 Jun 2012 13:31:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mcgrew@cisco.com; l=3269; q=dns/txt; s=iport; t=1339619487; x=1340829087; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=KrQ/y19kchIgsmnx2jQpJ8JdjT0Y+/EFAS9W50DK3LY=; b=auvON4W8HPAFbuYUzaW58KKpZPrlk/F+Z3GYljKyPaPfDRZEC8mF22ul ZKL5nJ6rBo4iFzJ3sz+kdS3hUUc4/9ICKneJpddgv7URfh4IRIwvg48OS RrJTYGXcdmRtgW37sXzW1GWbxNSQAfAzw9SbLJZOcpi9zlHuEypvLad5L E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EACn42E+tJXHA/2dsb2JhbABFtUGBB4IYAQEBAwEBAQEPAVsLBQsLGC4nMAYTCRmHZAULmiygBosxhTFgA5UhjhaBZoJ8 X-IronPort-AV: E=Sophos;i="4.75,766,1330905600"; d="scan'208";a="92240500" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-3.cisco.com with ESMTP; 13 Jun 2012 20:31:27 +0000 Received: from rtp-vpn5-1719.cisco.com (rtp-vpn5-1719.cisco.com [10.82.238.189]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id q5DKVPux017864; Wed, 13 Jun 2012 20:31:26 GMT Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=windows-1252 From: David McGrew In-Reply-To: <149B9613-82A9-4D27-934D-A15F854233BE@cisco.com> Date: Wed, 13 Jun 2012 16:31:25 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <4C7FB346-7592-4747-A495-7832B147784F@cisco.com> References: <1B8956F6-81C5-4921-BA03-4097BE58F471@bbn.com> <255B9BB34FB7D647A506DC292726F6E114F557CCA2@WSMSG3153V.srv.dir.telstra.com> <149B9613-82A9-4D27-934D-A15F854233BE@cisco.com> To: "Manger, James H" X-Mailer: Apple Mail (2.1278) Cc: "cfrg@irtf.org" Subject: Re: [Cfrg] draft-mcgrew-aead-aes-cbc-hmac-sha2-00: unsafe to optionally hash A's length X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jun 2012 20:31:36 -0000 On Jun 13, 2012, at 4:23 PM, David McGrew wrote: > Hi James, >=20 > thanks for the quick feedback, more inline: >=20 > On Jun 12, 2012, at 10:32 PM, Manger, James H wrote: >=20 >> RE: Authenticated Encryption with AES-CBC and HMAC-SHA >>=20 >> Great document. >>=20 >> I am not certain that the way the length of the additional data (A) = is optionally hashed is safe. >=20 > Agreed. MIN_LEN_A was an under analyzed suggestion of mine, intended = as a way to enable these AEAD algorithms to interoperate with some = existing implementations of CBC and HMAC. It is not clear that the = interoperability I was going for is even important, and as you point = out, the particular way that the length of A was included doesn't work. = Change is clearly needed. I suggest that Step 5 should read: "The = octet string AL is equal to the number of bits in A expressed as a = 64-bit unsigned integer in network byte order." I should add that the test cases are all consistent with this change - = they all have MIN_LEN_A =3D 0. David >=20 >>=20 >> 1. Legitimate user sends A and C =3D S || T, where T =3D HMAC(A || S = || len(A)). >>=20 >> 2. Attacker intercepts & rearranges the message, sending an empty A' = and C' =3D A || S || len(A) || T. >>=20 >> 3. Recipient verifies T' =3D HMAC(S'), since len(A) =3D 0 =3D = MIN_LEN_A so AL is empty. >> T' =3D HMAC(S') =3D HMAC(A || S || len(A)) =3D T >> The verification passes! Yikes! The recipient now gets garbage from = the decryption. >> The attack might only work if len(A) mod 128 =3D 64, but that is not = hard enough. >>=20 >>=20 >> An attack can also work if the legitimate user sends an empty A. >> 1. Legitimate user sends empty A and C =3D S || T, where T =3D = HMAC(S). >>=20 >> 2. Attacker splits S into 3 parts, S =3D S1 || S2 || S3, choosing = len(S3) =3D 64 and len(S1) =3D S3. The attacker sends A' =3D S1 and C' =3D= S2 || T. >>=20 >> 3. Recipient's verification works! Yikes! >> T' =3D HMAC(A' || S' || len(A)) =3D HMAC(S1 || S2 || S3) =3D HMAC(S) = =3D T >> The recipient now gets garbage from the decryption. >> The attack might only work if the last 64 bits are a small enough = integer (and equal 64 mod 128), but that is not hard enough. >>=20 >>=20 >>=20 >>=20 >> Typos: >>=20 >> Section 2.1: The last padding string (PS) in step 3 should be 1010=85, = not 0F0F=85, as can be seen in the P_9 line in the section 5.1 test = case. Change it to: >>=20 >> PS =3D 10101010101010101010101010101010, if len(P) mod 128 =3D 0. >>=20 >> Section 2.2: Decryption step 3 should refer to encryption "steps 5 = and 6", not just to "step 5". >>=20 >> Section 3: A random IV should have min-entropy within 1 bit of the = block size (128-bits), not within 1 bit of the key length (which is = longer than the IV for AES-192 and AES-256 algorithms). >=20 > Agreed on all points. >=20 >>=20 >> Section 4: Stray " at end of Rationale. >>=20 >> Section 5: Some cases explicitly list PS and AL values, others don't. >=20 > Thanks again! >=20 > David >=20 >>=20 >> -- >> James Manger >=20 > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > http://www.irtf.org/mailman/listinfo/cfrg From thomas.r.henderson@boeing.com Wed Jun 13 14:28:16 2012 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 07EF711E8098 for ; Wed, 13 Jun 2012 14:28:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z8kvhvreU5Rv for ; Wed, 13 Jun 2012 14:28:11 -0700 (PDT) Received: from slb-mbsout-02.boeing.com (slb-mbsout-02.boeing.com [130.76.64.129]) by ietfa.amsl.com (Postfix) with ESMTP id 3BF7511E8097 for ; Wed, 13 Jun 2012 14:28:11 -0700 (PDT) Received: from slb-mbsout-02.boeing.com (localhost.localdomain [127.0.0.1]) by slb-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with ESMTP id q5DLS7L2013102 for ; Wed, 13 Jun 2012 14:28:07 -0700 Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [130.247.228.54]) by slb-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id q5DLS5l4013080 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 13 Jun 2012 14:28:05 -0700 Received: from stl-av-01.boeing.com (localhost.localdomain [127.0.0.1]) by stl-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id q5DLS7eO008784; Wed, 13 Jun 2012 16:28:07 -0500 Received: from XCH-NWHT-04.nw.nos.boeing.com (xch-nwht-04.nw.nos.boeing.com [130.247.64.250]) by stl-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id q5DLS7xJ008765 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Wed, 13 Jun 2012 16:28:07 -0500 Received: from XCH-NW-16V.nw.nos.boeing.com ([130.247.25.238]) by XCH-NWHT-04.nw.nos.boeing.com ([130.247.64.250]) with mapi; Wed, 13 Jun 2012 14:28:06 -0700 From: "Henderson, Thomas R" To: "'Igoe, Kevin M.'" , "cfrg@irtf.org" Date: Wed, 13 Jun 2012 14:28:06 -0700 Thread-Topic: [Cfrg] HIP Help (I hope!) Thread-Index: Ac0x1mO4SqW+ChrlSvGTnFlpVMgdPwAK/YfwBelZ67A= Message-ID: <758141CC3D829043A8C3164DD3D593EA1BD324E07D@XCH-NW-16V.nw.nos.boeing.com> References: <80F9AC969A517A4DA0DE3E7CF74CC1BB425C0A@MSIS-GH1-UEA06.corp.nsa.gov> <80F9AC969A517A4DA0DE3E7CF74CC1BB425C0D@MSIS-GH1-UEA06.corp.nsa.gov> In-Reply-To: <80F9AC969A517A4DA0DE3E7CF74CC1BB425C0D@MSIS-GH1-UEA06.corp.nsa.gov> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_758141CC3D829043A8C3164DD3D593EA1BD324E07DXCHNW16Vnwnos_" MIME-Version: 1.0 X-TM-AS-MML: No Cc: 'Robert Moskowitz' Subject: Re: [Cfrg] HIP Help (I hope!) X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jun 2012 21:28:16 -0000 --_000_758141CC3D829043A8C3164DD3D593EA1BD324E07DXCHNW16Vnwnos_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Kevin and all, Here is an attempted rollup of the advice that I received; if no other comm= ents, I'll take this back to the HIP WG. I'm summarizing this below in the= hopes that it could be sanity checked by CFRG. To recap, we were asked by the IESG to consider the use of OEAP and PSS in = HIP. In the course of this discussion, some other suggestions were made. For the keys used in HIP themselves (used for signing/authentication), HIP = specifies these types: DSA 3 [RFC2536] (R= ECOMMENDED) RSA 5 [RFC3110] (R= EQUIRED) ECDSA 7 [RFC4754] (R= ECOMMENDED) ECDSA_LOW 9 [SECG] (RECOMMENDED) The feedback that I received was to follow NIST 800-131A on key strength re= garding all of these key types, and to consider not using ECDSA_LOW. We'd = like to retain ECDSA_LOW, suitably caveated ("defined for devices with low = computational capabilities"). For DSA, we could replace the existing refer= ence to a reference to FIPS 186-3 and also reference RFC 5114 2.3 with 2048= -bit subgroups for use with SHA2-256. The hash used for RSA and DSA signature is SHA-256, so I don't think any ch= ange is needed there. For RSA signature padding, the RSAASA-PSS [RFC3447] should replace the refe= rence to RFC3110 above, and explicitly state that PSS instead of PKCS1.5 pa= dding is used. I am not sure whether we need to state anything about paddi= ng for other signature types (guidance here would be helpful). Regarding OAEP, currently HIP specifies these ciphers for use in the ENCRYP= TED parameter (used to encrypt small blocks of data): AES-128-CBC 2 ([RFC3602]) required 3DES-CBC 3 ([RFC2451]) AES-256-CBC 4 ([RFC3602]) I believe that we are being asked to also support RSA-OAEP here (RFC 4055).= Would specifing an additional (non-required) option for RSAES-OAEP ([RFC4= 055]) suffice, or is OAEP a preferred technique for encrypting parameters o= ver AES-128-CBC? Also, I understand that we ought to consider clarifying t= hat 3DES-CBC is the three-key variant (NIST 800-131A), or removing it altog= ether (which I think is what you advocated below). Regarding encryption padding, the current draft specifies to use whatever p= adding is specified by the encryption algorithm, citing PKCS5 for AES, and = not mentioning 3DES-CBC padding (in practice, our implementation also pads = this according to PKCS5). Thanks for the feedback so far, Tom From: cfrg-bounces@irtf.org [mailto:cfrg-bounces@irtf.org] On Behalf Of Igo= e, Kevin M. Sent: Monday, May 14, 2012 11:55 AM To: Igoe, Kevin M.; cfrg@irtf.org Subject: Re: [Cfrg] HIP Help (I hope!) I did some double checking with some certificate guru's & they agree that = RSA-OAEP is precisely what you should be using. I've also had some discussions about HIP's use of 3DES. It will be difficu= lt to uproot once it has been fielded, so it might be prudent to remove it now. The same app= lies to DSA SHA1/2048 and ECDSA_low. From: cfrg-bounces@irtf.org [mailto:cfrg-bounces@irtf.org] On Behalf Of Igo= e, Kevin M. Sent: Monday, May 14, 2012 9:35 AM To: cfrg@irtf.org Subject: [Cfrg] HIP Help (I hope!) I do have an obvious observation on the use of DSA. In SP-800-131A, NIST states that for signing, a 1024 bit DSA modulus with a= 160-bit subgroup is acceptable through 2010, deprecated from 2011 through = 2013, and disallowed after 2013. While we are not bound by NIST's authority= , I for one feel it would be prudent to follow their lead. (SP-800-131A=3D http://csrc.nist.gov/publications/nistpubs/800-131A/sp800-1= 31A.pdf ) RFC 5114 [Additional Diffie-Hellman Groups for Use with IETF Standards] pr= ovides an alternative to 1024-bit/SHA1 DSA. Sections 2.2 and 2.3 lists 204= 8 bit groups suitable for use with DSA/SHA2-224 and DSA/SHA2-256 respective= ly. Is either of these this in the latest version of openSSL? In all the e= xcitement, I've kinda lost track myself. Comments anyone? Anyone with comments on the padding? My gut instinct so to keep it as sim= ple as possible, avoid defining new key types & use as much pre-existing co= de as possible. Dare to be consistent! We could really use some input here from folks with concrete experience on = the padding issues! Speak now or forever hold your peace. P.S. I'm impressed by the amount of detailed work that went into this draft= . Well done! > -----Original Message----- > From: cfrg-bounces@irtf.org [mailto:cfrg-bo= unces@irtf.org] On Behalf Of > Henderson, Thomas R > Sent: Friday, May 11, 2012 10:30 AM > To: 'cfrg@irtf.org' > Cc: 'Robert Moskowitz' > Subject: Re: [Cfrg] advice about best current practices for HIP > > Hi, I was wondering if anyone was going to be able to respond to the > below questions, or if we should proceed otherwise. > > - Tom > > > -----Original Message----- > > From: Henderson, Thomas R > > Sent: Tuesday, April 24, 2012 5:03 PM > > To: 'cfrg@irtf.org' > > Cc: 'Tobias Heer'; 'Robert Moskowitz' > > Subject: advice about best current practices for HIP > > > > Hello, I'm one of the authors working on revising HIP [*], and I > would > > like advice on how to respond to an IESG comment on RFC5201. > > > > The IESG comment in the experimental specification for HIP reads as > > follows: > > > > HIP defines the usage of RSA in signing and encrypting data. > > Current > > recommendations propose usage of, for example, RSA OAEP/PSS for > > these > > operations in new protocols. Changing the algorithms to more > > current > > best practice should be considered. > > > > This comment was made over four years ago, and I'm not an expert on > > cryptography, so I thought I'd check with the CFRG for advice on how > to > > respond now. > > > > 1) signature padding > > > > Presently, the HIP draft specifies these algorithms for keys (section > > 5.2.9 of the draft): > > > > DSA 3 [RFC2536] (RECOMMENDED) > > RSA 5 [RFC3110] (REQUIRED) > > ECDSA 7 [RFC4754] (RECOMMENDED) > > ECDSA_LOW 9 [SECG] (RECOMMENDED) > > > > However, the specification of how to compute the signature is > somewhat > > vague: > > > > 3. Compute the signature using the private key corresponding to > the > > Host Identifier (public key). > > > > I believe that, in practice, whatever default padding was provided by > > OpenSSL RSA_sign() has been used (I believe it to be PKCS#1 v1.5). > I'm > > wondering whether the way to address this comment is to mandate that, > > when signatures are computed, and RSA is the key type, the RSAASA-PSS > > [RFC3447] method of padding is required, and to replace the reference > > to RFC3110 above with RFC3447. > > > > The above discussion is limited to RSA. Do we need signature > > specifications for all of these key types, or is it well implied for > > the other key types how to perform the signatures? > > > > 2) encryption padding > > > > HIP uses a block cipher to generate ENCRYPTED parameters, using > > encryption keys generated by the Diffie Hellman exchange. In > practice, > > the Host Identity (a public key) may be encrypted for privacy in the > I2 > > message. > > > > These ciphers are specified for HIP (section 5.2.8 of the draft): > > > > AES-128-CBC 2 ([RFC3602]) > > 3DES-CBC 3 ([RFC2451]) > > AES-256-CBC 4 ([RFC3602]) > > > > The draft specifies also to use whatever padding is specified by the > > encryption algorithm, citing PKCS5 for AES, and not mentioning 3DES- > CBC > > padding (in practice, our implementation also pads this according to > > PKCS5). > > > > I understand that RSAES-OAEP is a padding technique for key transport > > in particular. However, HIP does not specify RSA for encryption, and > > does not use 'key transport' mode but rather 'data encryption' mode. > > Does RSAES-OAEP apply in this case? Should HIP be considering > another > > best practice algorithm for doing this? > > > > In closing, an important consideration for our implementations is > > availability in OpenSSL, so required algorithms should be supported > > there. > > > > Thanks, > > Tom > > > > [*] http://tools.ietf.org/html/draft-ietf-hip-rfc5201-bis-08 > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > http://www.irtf.org/mailman/listinfo/cfrg --_000_758141CC3D829043A8C3164DD3D593EA1BD324E07DXCHNW16Vnwnos_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Kevin and all,

 

= Here is an attempted rollup of the advice tha= t I received; if no other comments, I'll take this back to the HIP WG. = ; I'm summarizing this below in the hopes that it could be sanity checked b= y CFRG.

 

To recap, we were asked by the IESG to consider the use of OEAP an= d PSS in HIP.  In the course of this discussion, some other suggestion= s were made.

 

For the keys used in HIP themselves (used for signing/authent= ication), HIP specifies these types:

 

 &n= bsp;      DSA      &= nbsp;       3 [RFC2536] (RECOMMENDED)

 &n= bsp;      RSA      &= nbsp;       5 [RFC3110] (REQUIRED)

&= nbsp;       ECDSA    &nbs= p;       7 [RFC4754] (RECOMMENDE= D)

        ECD= SA_LOW        9 [SECG]    = (RECOMMENDED)

 

The feedback that I received was to follow NIST 800-131A on = key strength regarding all of these key types, and to consider not using EC= DSA_LOW.  We'd like to retain ECDSA_LOW, suitably caveated ("defi= ned for devices with low computational capabilities").  For DSA, = we could replace the existing reference to a reference to FIPS 186-3 and al= so reference RFC 5114 2.3 with 2048-bit subgroups for use with SHA2-256.

=  

T= he hash used for RSA and DSA signature is SHA-256, so I don't think any cha= nge is needed there.

 

For RSA signature padding, the RSAASA-PSS [RFC3447] = should replace the reference to RFC3110 above, and explicitly state that PS= S instead of PKCS1.5 padding is used.  I am not sure whether we need t= o state anything about padding for other signature types (guidance here wou= ld be helpful).

 

Regarding OAEP, currently HIP specifies these ciphers fo= r use in the ENCRYPTED parameter (used to encrypt small blocks of data):

=  

  AES-128-CBC &nbs= p;      2     ([RFC3602]) = ; required

  3DES-CBC  = ;         3    = ([RFC2451])

  AES-256-CBC =        4     ([RFC3602])<= o:p>

 = ;

I beli= eve that we are being asked to also support RSA-OAEP here (RFC 4055). = Would specifing an additional (non-required) option for RSAES-OAEP ([RFC40= 55]) suffice, or is OAEP a preferred technique for encrypting parameters ov= er AES-128-CBC?  Also, I understand that we ought to consider clarifyi= ng that 3DES-CBC is the three-key variant (NIST 800-131A), or removing it a= ltogether (which I think is what you advocated below).

 

Regarding encryptio= n padding, the current draft specifies to use whatever padding is specified= by the encryption algorithm, citing PKCS5 for AES, and not mentioning 3DES= -CBC padding (in practice, our implementation also pads this according to P= KCS5).

 

Thanks for the feedback so far,

Tom

 

 

From: cfrg-bounces@irtf.org [mailto:cfr= g-bounces@irtf.org] On Behalf Of Igoe, Kevin M.
Sent: Mond= ay, May 14, 2012 11:55 AM
To: Igoe, Kevin M.; cfrg@irtf.org
Subject: Re: [Cfrg] HIP Help (I hope!)

 

I did some double checking with  some certificate = guru’s & they agree that RSA-OAEP

is precisely what you should be = using.

 

I’ve also had some discussions about HIP’s use of 3DES.=   It will be difficult to uproot once

it has been fielded, so it might be= prudent to remove it now.  The same applies

to DSA SHA1/2048 and ECDSA_l= ow.

 

= From:= cfrg-bounces@irtf.org [mailto:cfrg-bounces@irtf.org] On Behalf Of I= goe, Kevin M.
Sent: Monday, May 14, 2012 9:35 AM
To: cf= rg@irtf.org
Subject: [Cfrg] HIP Help (I hope!)<= /p>

 

I do have an obvious observation on the use of DSA.

 

In SP-800= -131A, NIST states that for signing, a 1024 bit DSA modulus with a 160-bit = subgroup is acceptable through 2010, deprecated from 2011 through 2013, and= disallowed after 2013. While we are not bound by NIST's authority, I for o= ne feel it would be prudent to follow their lead.

(SP-800-131A=3D http://csrc.nist.gov/publications/nistpubs= /800-131A/sp800-131A.pdf )

&= nbsp;

RFC 5114  [Additional Diffie-He= llman Groups for Use with IETF Standards] provides an alternative to 1024-b= it/SHA1 DSA.  Sections 2.2 and 2.3 lists 2048 bit groups suitable for = use with DSA/SHA2-224 and DSA/SHA2-256 respectively. Is either of these thi= s in the latest version of openSSL?  In all the excitement, I've kinda= lost track myself.

 

Comments anyone?

 

 

=

Anyone with comments on the padding?  My gut i= nstinct so  to keep it as simple as possible, avoid defining new key t= ypes & use as much pre-existing code as possible. Dare to be consistent= ! 

 

 

<impassion= ed_plea>

We could really use some = input here from folks with concrete experience on the

padding issues!  Speak now or forever hold your peac= e.

</impassioned_plea>

 

= P.S. I'm impressed by the amount of detailed work that went into this draft= . 

Well done!

 

&nbs= p;

> -----Original Message-----

> From: cfrg-bounces@irtf.org [mailto:cfrg-bounces@irtf.org] On Behalf Of

> Henderson, Thomas R

> Sent: Friday, May 11, 2012 10:30 AM

> To: 'cfrg@irtf.org'

= > Cc: 'Robert Moskowitz'

> Subj= ect: Re: [Cfrg] advice about best current practices for HIP

<= p class=3DMsoPlainText>>

> Hi,= I was wondering if anyone was going to be able to respond to the

> below questions, or if we should proceed = otherwise.

>

> - Tom

>

> > -----Original Message-----

> > From: Henderson, Thomas R

> > Sent: Tuesday, April 24, 2012 = 5:03 PM

> > To: 'cfrg@irtf.org'=

> > Cc: 'Tobias Heer'; 'Robert= Moskowitz'

> > Subject: advice= about best current practices for HIP

> >

> > Hello, I'm one o= f the authors working on revising HIP [*], and I

> would

> > like= advice on how to respond to an IESG comment on RFC5201.

> >

> &g= t; The IESG comment in the experimental specification for HIP reads as=

> > follows:

> >

> >&n= bsp;   HIP defines the usage of RSA in signing and encrypting dat= a.

> > Current

> >    recommendations propose u= sage of, for example, RSA OAEP/PSS for

> > these

> > &nbs= p;  operations in new protocols.  Changing the algorithms to more=

> > current

> >    best practice should be con= sidered.

> >

> > This comment was made over four years ago, an= d I'm not an expert on

> > cryp= tography, so I thought I'd check with the CFRG for advice on how=

> to

&= gt; > respond now.

> ><= /o:p>

> > 1) signature padding<= /p>

> >

= > > Presently, the HIP draft specifies these algorithms for keys (sec= tion

> > 5.2.9 of the draft):

> >

> >         DSA&nbs= p;             = 3 [RFC2536] (RECOMMENDED)

> >&n= bsp;        RSA    &= nbsp;         5 [RFC3110] (REQUIRED= )

> >    &n= bsp;    ECDSA        = ;    7 [RFC4754] (RECOMMENDED)

> >         ECDSA_LO= W        9 [SECG]    (REC= OMMENDED)

> >

> > However, the specification of how to compute= the signature is

> somewhat<= /o:p>

> > vague:

> >

> > = ;   3.  Compute the signature using the private key correspo= nding to

> the

> >        Host= Identifier (public key).

> >

> > I believe that, in practice,= whatever default padding was provided by

> > OpenSSL RSA_sign() has been used (I believe it to be PKCS#1 = v1.5).

> I'm

> > wondering whether the way to address this commen= t is to mandate that,

> > when = signatures are computed, and RSA is the key type, the RSAASA-PSS=

> > [RFC3447] method of padding is requir= ed, and to replace the reference

>= > to RFC3110 above with RFC3447.

= > >

> > The above discuss= ion is limited to RSA.  Do we need signature

> > specifications for all of these key types, or is it = well implied for

> > the other = key types how to perform the signatures?

> >

> > 2) encryption= padding

> >

> > HIP uses a block cipher to generate ENCRYPTED= parameters, using

> > encrypti= on keys generated by the Diffie Hellman exchange.  In

> practice,

= > > the Host Identity (a public key) may be encrypted for privacy in = the

> I2

> > message.

> = >

> > These ciphers are spec= ified for HIP (section 5.2.8 of the draft):

> >

> >  = ;       AES-128-CBC    &n= bsp;   2     ([RFC3602])

> >        = 3DES-CBC           3&nbs= p;    ([RFC2451])

>= >         AES-256-CBC &nbs= p;      4     ([RFC3602])=

> >

> > The draft specifies also to use whatever padding is specif= ied by the

> > encryption algor= ithm, citing PKCS5 for AES, and not mentioning 3DES-

> CBC

> > pa= dding (in practice, our implementation also pads this according to

> > PKCS5).

> >

> > I unde= rstand that RSAES-OAEP is a padding technique for key transport<= /p>

> > in particular.  However, HIP does= not specify RSA for encryption, and

= > > does not use 'key transport' mode but rather 'data encryption' mo= de.

> > Does RSAES-OAEP apply i= n this case?  Should HIP be considering

> another

> > best p= ractice algorithm for doing this?

>= ; >

> > In closing, an impor= tant consideration for our implementations is

> > availability in OpenSSL, so required algorithms should b= e supported

> > there.

> >

> > Thanks,

> > Tom

> >

> > [*] http://tools.ietf.org/html/draft-ietf-hip-rfc5201-bis-08

> _____________________________= __________________

> Cfrg mailing = list

> Cfrg@irtf.org

> http://www.irtf.org/mailman/list= info/cfrg

= --_000_758141CC3D829043A8C3164DD3D593EA1BD324E07DXCHNW16Vnwnos_-- From Joachim@Strombergson.com Thu Jun 14 04:25:49 2012 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 8804221F86B5 for ; Thu, 14 Jun 2012 04:25:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.81 X-Spam-Level: X-Spam-Status: No, score=-1.81 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dWWscWjO7zgd for ; Thu, 14 Jun 2012 04:25:49 -0700 (PDT) Received: from susano.oderland.com (susano.oderland.com [91.201.63.143]) by ietfa.amsl.com (Postfix) with ESMTP id C953F21F86B2 for ; Thu, 14 Jun 2012 04:25:48 -0700 (PDT) Received: from [62.80.223.74] (port=4385 helo=secworks85.gotanet.se) by susano.oderland.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from ) id 1Sf8BO-002wOz-NF for cfrg@irtf.org; Thu, 14 Jun 2012 13:25:46 +0200 Message-ID: <4FD9CA36.3020001@Strombergson.com> Date: Thu, 14 Jun 2012 13:25:42 +0200 From: =?UTF-8?B?Sm9hY2hpbSBTdHLDtm1iZXJnc29u?= Organization: Kryptologik User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:13.0) Gecko/20120601 Thunderbird/13.0 MIME-Version: 1.0 To: cfrg@irtf.org References: <1B8956F6-81C5-4921-BA03-4097BE58F471@bbn.com> <255B9BB34FB7D647A506DC292726F6E114F557CCA2@WSMSG3153V.srv.dir.telstra.com> <149B9613-82A9-4D27-934D-A15F854233BE@cisco.com> <4C7FB346-7592-4747-A495-7832B147784F@cisco.com> In-Reply-To: <4C7FB346-7592-4747-A495-7832B147784F@cisco.com> X-Enigmail-Version: 1.4.2 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig5B27B8E61C3E659E1B1A991E" X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - susano.oderland.com X-AntiAbuse: Original Domain - irtf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - Strombergson.com Subject: Re: [Cfrg] draft-mcgrew-aead-aes-cbc-hmac-sha2-00: unsafe to optionally hash A's length X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Joachim@Strombergson.com List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jun 2012 11:25:49 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig5B27B8E61C3E659E1B1A991E Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Aloha! On 2012-06-13 22:31 , David McGrew wrote: > I should add that the test cases are all consistent with this change - = they all have MIN_LEN_A =3D 0. Would it make sense to add a TC for when MIN_LEN!=3D0? Yours JoachimS --=20 Med v=C3=A4nlig h=C3=A4lsning, Yours Joachim Str=C3=B6mbergson - Alltid i harmonisk sv=C3=A4ngning. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --------------enig5B27B8E61C3E659E1B1A991E Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk/ZyjYACgkQZoPr8HT30QEOgQCg2lCgrbNdY47xs/zwePbQEW4W gjoAoLX3W7n4c7Zbh161YWfFyGtMeD/E =T6iU -----END PGP SIGNATURE----- --------------enig5B27B8E61C3E659E1B1A991E-- From prvs=75126a4a1d=uri@ll.mit.edu Thu Jun 14 08:12:49 2012 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 66FAD21F86BD for ; Thu, 14 Jun 2012 08:12:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.201 X-Spam-Level: X-Spam-Status: No, score=-5.201 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8+oV-srMIYLy for ; Thu, 14 Jun 2012 08:12:46 -0700 (PDT) Received: from mx2.ll.mit.edu (MX2.LL.MIT.EDU [129.55.12.46]) by ietfa.amsl.com (Postfix) with ESMTP id 5E0D721F86B9 for ; Thu, 14 Jun 2012 08:12:46 -0700 (PDT) Received: from LLE2K7-HUB02.mitll.ad.local (LLE2K7-HUB02.mitll.ad.local) by mx2.ll.mit.edu (unknown) with ESMTP id q5EFCb3w007940; Thu, 14 Jun 2012 11:12:37 -0400 From: "Blumenthal, Uri - 0668 - MITLL" To: "Henderson, Thomas R" , "'Igoe, Kevin M.'" , "cfrg@irtf.org" Date: Thu, 14 Jun 2012 11:12:32 -0400 Thread-Topic: [Cfrg] HIP Help (I hope!) Thread-Index: Ac1KQCEZKsWUFmHtQtGmNwhu60BAcw== Message-ID: In-Reply-To: <758141CC3D829043A8C3164DD3D593EA1BD324E07D@XCH-NW-16V.nw.nos.boeing.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.12.0.110505 acceptlanguage: en-US Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3422517153_124503962" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.7.7855, 1.0.260, 0.0.0000 definitions=2012-06-14_04:2012-06-14, 2012-06-14, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=2 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=6.0.2-1203120001 definitions=main-1206140131 Cc: 'Robert Moskowitz' Subject: Re: [Cfrg] HIP Help (I hope!) X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jun 2012 15:12:49 -0000 --B_3422517153_124503962 Content-type: multipart/alternative; boundary="B_3422517153_124459957" --B_3422517153_124459957 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable > Kevin and all, =8A=8A=8A=8A.. > For the keys used in HIP themselves (used for signing/authentication), HI= P > specifies these types: > DSA 3 [RFC2536 = ] > (RECOMMENDED) Considering Suite B, I am not sure I'd still recommend DSA. > RSA 5 [RFC3110 = ] > (REQUIRED) Well, I'd move from RSA, but I recognize the reality =AD megatons of already-deployed RSA code and certs=8A > ECDSA 7 [RFC4754 = ] > (RECOMMENDED) Yes, and I'd consider elevating ECDSA to REQUIRED, to facilitate and encourage the move. > ECDSA_LOW 9 [SECG > ] > (RECOMMENDED) I would drop ECDSA_LOW altogether. > The feedback that I received was to follow NIST 800-131A on key strength > regarding all of these key types, and to consider not using ECDSA_LOW. W= e'd > like to retain ECDSA_LOW, suitably caveated ("defined for devices with lo= w > computational capabilities"). For DSA, we could replace the existing > reference to a reference to FIPS 186-3 and also reference RFC 5114 2.3 wi= th > 2048-bit subgroups for use with SHA2-256. At the very least. SHA3 should come out some time this year =AD do you care t= o wait=8A? > The hash used for RSA and DSA signature is SHA-256, so I don't think any > change is needed there. It should be sufficient, based on what we currently know. > For RSA signature padding, the RSAASA-PSS [RFC3447] should replace the > reference to RFC3110 above, and explicitly state that PSS instead of PKCS= 1.5 > padding is used. I am not sure whether we need to state anything about > padding for other signature types (guidance here would be helpful). I'll let others comment on this. > Regarding OAEP, currently HIP specifies these ciphers for use in the > ENCRYPTED parameter (used to encrypt small blocks of data): > AES-128-CBC 2 ([RFC3602]) required > 3DES-CBC 3 ([RFC2451]) > AES-256-CBC 4 ([RFC3602]) > =20 > I believe that we are being asked to also support RSA-OAEP here (RFC 4055= ). > Would specifing an additional (non-required) option for RSAES-OAEP ([RFC4= 055]) > suffice, or is OAEP a preferred technique for encrypting parameters over > AES-128-CBC? RSA-OAEP as a preferred technique to encrypt what? For passing along AES an= d other cryptographic keys =AD sure, it's a great mechanism. To encrypt data chunks (large or small) if/when you already have an AES key established between the parties =AD no way. To infrequently send small things when you don't have a symmetric key established =AD if you want to be 10% stateless, then yes, RSA-OAEP would do the job; but if you can afford setting up a symmetric channel and/or plan on exchanging a whole bunch of these small things =AD you're better off not using RSA-OAEP for data transfer... > Also, I understand that we ought to consider clarifying that 3DES-CBC i= s the > three-key variant (NIST 800-131A), or removing it altogether (which I thi= nk is > what you advocated below). I would just remove it, as I see no purpose in carrying 3DES over. > Regarding encryption padding, the current draft specifies to use whateve= r > padding is specified by the encryption algorithm, citing PKCS5 for AES, a= nd > not mentioning 3DES-CBC padding (in practice, our implementation also pad= s > this according to PKCS5). Why not=8A :) From: cfrg-bounces@irtf.org [mailto:cfrg-bounces@irtf.org] On Behalf Of Igoe, Kevin M. Sent: Monday, May 14, 2012 11:55 AM To: Igoe, Kevin M.; cfrg@irtf.org Subject: Re: [Cfrg] HIP Help (I hope!) =20 I did some double checking with some certificate guru=B9s & they agree that RSA-OAEP is precisely what you should be using. If you have a hammer, the whole world starts looking like a nail. :) I=B9ve also had some discussions about HIP=B9s use of 3DES. It will be difficult to uproot once it has been fielded, so it might be prudent to remove it now. The same applies to DSA SHA1/2048 and ECDSA_low. I concur. --B_3422517153_124459957 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable
<= div lang=3D"EN-US" link=3D"blue" vlink=3D"purple">

Kevin and all, ……= ;……..

For the keys used in H= IP themselves (used for signing/authentication), HIP specifies these types:<= /span>

        DSA=             &nbs= p; 3 [RFC2536] (RECOMMENDED)

Considering Suite B,&n= bsp;I am not sure I'd still recommend DSA.
=

        RSA &nb= sp;            5 [RFC3110] (REQUIRED)=

Well, I'd move from RSA, but = I recognize the reality – megatons of already-deployed RSA code and ce= rts…

<= /o:p>

        ECDSA&n= bsp;           7 [RFC47= 54] (RECOMMENDED)

Yes, and I'd consider elevating ECDSA to REQUIRED, to facilitate and enc= ourage the move.

=

        E= CDSA_LOW        9 [SECG]    (RECO= MMENDED)

I would d= rop ECDSA_LOW altogether.

The= feedback that I received was to follow NIST 800-131A on key strength regard= ing all of these key types, and to consider not using ECDSA_LOW.  We'd = like to retain ECDSA_LOW, suitably caveated ("defined for devices with low c= omputational capabilities").  For DSA, we could replace the existing re= ference to a reference to FIPS 186-3 and also reference RFC 5114 2.3 with 20= 48-bit subgroups for use with SHA2-256.

At the very least. SHA3 should come out some time this= year – do you care to wait…?

 The hash used for RSA and DSA signature is SHA-256= , so I don't think any change is needed there.

<= /blockquote>
It should be sufficient, based on what we cu= rrently know.

 = I'll let others comment on = this.


<= p class=3D"MsoNormal" style=3D"font-family: Calibri, sans-serif; font-size: 14px= ; color: rgb(0, 0, 0); "> Regarding = OAEP, currently HIP specifies these ciphers for use in the ENCRYPTED paramet= er (used to encrypt small blocks of data):

   AES-128-CBC&nb= sp;       2     ([RFC3602]= )  required

  3DES-CBC       &n= bsp;   3     ([RFC2451])

  AES-256-CBC      =   4     ([RFC3602])

 

I believe that we are being asked= to also support RSA-OAEP here (RFC 4055).  Would specifing an addition= al (non-required) option for RSAES-OAEP ([RFC4055]) suffice, or is OAEP a pr= eferred technique for encrypting parameters over AES-128-CBC?

RSA-OAEP as a preferred techniqu= e to encrypt what? For passing along AES and other cryptographic keys= – sure, it's a great mechanism. To encrypt data chunks (large or smal= l) if/when you already have an AES key established between the parties ̵= 1; no way. To infrequently send small things when you don't have a symmetric= key established – if you want to be 10% stateless, then yes, RSA-OAEP= would do the job; but if you can afford setting up a symmetric channel and/= or plan on exchanging a whole bunch of these small things – you're bet= ter off not using RSA-OAEP for data transfer...

&= nbsp; Also, I understand that we ought to consider clarifying that 3DES-CBC = is the three-key variant (NIST 800-131A), or removing it altogether (which I= think is what you advocated below).

I would just remove it, as I see no purpose in carrying 3= DES over.

 Regarding encryption paddin= g, the current draft specifies to use whatever padding is specified by the e= ncryption algorithm, citing PKCS5 for AES, and not mentioning 3DES-CBC paddi= ng (in practice, our implementation also pads this according to PKCS5).

Why not… :)


=

<= div style=3D"color: rgb(0, 0, 0); font-family: Calibri, sans-serif; font-size:= 14px; ">

From: cfr= g-bounces@irtf.org [mailto:cfrg-b= ounces@irtf.org] On Behalf Of Igoe, Kevin M.
Sent: Mond= ay, May 14, 2012 11:55 AM
To: Igoe, Kevin M.; cfrg@irtf.org
Subject: Re: [Cfrg] HIP Help (I hope!= )

 

I did some doubl= e checking with  some certificate guru’s & they agree that RS= A-OAEP is precisely what you should be using.

=
If you have a hammer, the whole world starts looking like a nail= . :)

 I’ve also had some discussions about HIP’s use of 3DES.&= nbsp; It will be difficult to uproot once it has been fielded, so it might = be prudent to remove it now.  The same applies to DSA SHA1/2048 and EC= DSA_low.

I concur.
--B_3422517153_124459957-- --B_3422517153_124503962 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIUAAYJKoZIhvcNAQcCoIIT8TCCE+0CAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC EeMwggTLMIIDs6ADAgECAgoYeP+3AAAAAByAMA0GCSqGSIb3DQEBCwUAMFExCzAJBgNVBAYT AlVTMR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxEzAR BgNVBAMTCk1JVExMIENBLTIwHhcNMTEwNzEzMjAyMzU1WhcNMTIwNzEyMjAyMzU1WjBhMQsw CQYDVQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEPMA0GA1UECxMG UGVvcGxlMSAwHgYDVQQDExdCbHVtZW50aGFsLlVyaS41MDAxMDU4NDCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAL4TeQPMpFpVQVbz3C9Es122DpioIq8JSZDol89SV3kYUPMj G8K3uynPscCziyfPlF6dJveeRp2DneKKkmgWbCrwN2zPOEu8fBqNHfWsRqsPA66SkA9XrkpQ v0wgw9sZNOf4oU1l+KGCn6bbZkHdbNLrlUV3R99TpQwY6qolZMy/uvYjWLmH3NutWEDsODl6 FP0nKt5nKiuG9t2FGPUYVyOKdf/u39VMzDApcOgKub3NlkXW+zzQZ7zF2aW4GQdUf7BUYMRX x0B5p1YiBRAoX8orCW5FFZ0vrUlTyNKu7NHMZwWm899JIVYD+EBASC40fNB/afphCsAgXDsh QTikAkkCAwEAAaOCAZMwggGPMB0GA1UdDgQWBBSQq3VtNOCIqvvszUnlxLlhFXsEFDAOBgNV HQ8BAf8EBAMCBsAwHwYDVR0jBBgwFoAUjkp9iaFjFxyBiDRXNyZFXhmKfiQwMwYDVR0fBCww KjAooCagJIYiaHR0cDovL2NybC5sbC5taXQuZWR1L2dldGNybC9MTENBMjBiBggrBgEFBQcB AQRWMFQwLQYIKwYBBQUHMAKGIWh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXR0by9MTENBMjAj BggrBgEFBQcwAYYXaHR0cDovL29jc3AubGwubWl0LmVkdS8wDAYDVR0TAQH/BAIwADA9Bgkr BgEEAYI3FQcEMDAuBiYrBgEEAYI3FQiDg+Udh+ynZoathxWD6vBFhbahHx2Fy94yh/+KcwIB ZAIBBTAiBgNVHSUBAf8EGDAWBggrBgEFBQcDBAYKKwYBBAGCNwoDDDAYBgNVHSAEETAPMA0G CyqGSIb3EgIBAwEIMBkGA1UdEQQSMBCBDnVyaUBsbC5taXQuZWR1MA0GCSqGSIb3DQEBCwUA A4IBAQCfzOm9Ms0oupY104yKv6x3gTnVunF9Yc0Jok2zUUy8DNPLzUMYeVaV9SQu7Z6JmQXB gqgjnnpfVjCO0kg61uyL9bpovn2E4mmneRmetQdNq56/rtrxnlh3gNbGidWH+FfvxL97AVpD bccsV7wDBT2MQgaLVtUHNqDrPEC+0dtkMFK/6vgrShfUh3pCm6G3BhDFlBFMSTl/mcxO/x10 KbXVbhMUz7biweTBbiJUQdG7iemRG//HXOpMHtKZ94ro3YUJ52nhkjfnMJMqzX+aKM116CbM gmJji36vaZK2l6Y7+Es59SZUTwxkTupZTqXADFXO9LWAmYdZjZYcumaToubrMIIEtzCCA5+g AwIBAgIBFDANBgkqhkiG9w0BAQsFADBUMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlUIExp bmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRYwFAYDVQQDEw1NSVRMTCBSb290IENB MB4XDTA5MTIxNDEyMDAwMFoXDTE1MTIzMTIzNTk1OVowUTELMAkGA1UEBhMCVVMxHzAdBgNV BAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsTA1BLSTETMBEGA1UEAxMKTUlU TEwgQ0EtMjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKcEyyNhSIfsN6AzBwVh Zkzo6SdjNGAQ7mA2A8T0kmdCB8MH6jWjVVMwFZwlg9cgjgLKEuEO9KN8K9M8jgeZEMoinlRf k3YELPC7sEkkzBQkcVpLhEwALue9iHowgSLGmXZpYKmRhfvhvYJ4MNCuIaWpcK/GaDZCE+U2 aTg42kv/zQrH3AoqFX81OF7niwXNnanP1hQRfkMTRrnaEW8DX0TMaG/t9Ry5xSMrLTNc9DvQ tjA5ZcuWnECiUpyDBFWxLr9yx7xgf1/LwgCxcoBeKSBBoWzkQmKAsgMo9Mq1Fp/nnIqw5FKm gOs7Vy+6e0Dk+cgf+oAV8AK8ZFMQrVE0uH0CAwEAAaOCAZUwggGRMBIGA1UdEwEB/wQIMAYB Af8CAQAwHQYDVR0OBBYEFI5KfYmhYxccgYg0VzcmRV4Zin4kMB8GA1UdIwQYMBaAFGeqes/0 Cqa5crWKoNKd8hDDQ+0pMA4GA1UdDwEB/wQEAwIBhjBhBggrBgEFBQcBAQRVMFMwLQYIKwYB BQUHMAKGIWh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXR0bz9MTFJDQTAiBggrBgEFBQcwAYYW aHR0cDovL29jc3AubGwubWl0LmVkdTAzBgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLmxs Lm1pdC5lZHUvZ2V0Y3JsP0xMUkNBMIGSBgNVHSAEgYowgYcwDQYLKoZIhvcSAgEDAQYwDQYL KoZIhvcSAgEDAQgwDQYLKoZIhvcSAgEDAQcwDQYLKoZIhvcSAgEDAQkwDQYLKoZIhvcSAgED AQowDQYLKoZIhvcSAgEDAQswDQYLKoZIhvcSAgEDAQ4wDQYLKoZIhvcSAgEDAQ8wDQYLKoZI hvcSAgEDARAwDQYJKoZIhvcNAQELBQADggEBAIh3BqHQ/XH8C6DCL+eEGroOzxBcCqTNItms v4MANaOTodgU2jrjHcGjXlzqhpb8ZxOlkAK3dK09rc6+yACcoK2TzVtDRZXYxov/SqZRjI3d ufU2JatAPxosCyy/1otjl1TKUY47Wvft31vdf5i0XK2DQVEJ+XlqtgBiFTVIMIfBJwPajrsi z+pgFEYwhhwJxvs8flSi0FLCE77VYLEioP5hxG6zIPeQRxzh1bogbfphWHHtoiTDkBSZ4Ufv GXQTVf7QjhD5yYw10yICtjHmtgbfgBkH5/vvR92NY9RSlNPzZqmGKIia61bJCmagRYGyexfe dVNF0cJWL4J/cLHhgNYwggODMIICa6ADAgECAgEBMA0GCSqGSIb3DQEBBQUAMFQxCzAJBgNV BAYTAlVTMR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kx FjAUBgNVBAMTDU1JVExMIFJvb3QgQ0EwHhcNMDgwOTIzMTIwMDAwWhcNMjkxMjMxMjM1OTU5 WjBUMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoG A1UECxMDUEtJMRYwFAYDVQQDEw1NSVRMTCBSb290IENBMIIBIjANBgkqhkiG9w0BAQEFAAOC AQ8AMIIBCgKCAQEAxU4pF1iyJrL5rYq/XBAKg93kCTATG7Bw0NGFpEJ1A3Xsr6UIIq9/1VJB OgCwDqrVsAK1lRwy/lkrHzPkobiMr1wzjQ28SR/9sg5kAcmrMqBYbc302qtwCGKZxdNdhAh2 nUOCO10AMpUsCNdpikPY9ukT8lsA+eorM4Q1rc/L0J6AHRptOU7IuDBdZj+tdNb7gv+GKknr 6wj9m2sVGawoaG7AAqhsWvQUM/q4h/H5FpYlwnVAEh2AzhqiG9bwl6uJJIzJ/8uUWldNkVwz 1I5fR/vCaxiLXIW4oUydBuRKTG+ekEoxHGuD73yx5JtsSciS8HQL2oEM8tv+VAC+albqgwID AQABo2AwXjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdDgQWBBRnqnrP9AqmuXK1iqDSnfIQw0Pt KTAfBgNVHSMEGDAWgBRnqnrP9AqmuXK1iqDSnfIQw0PtKTALBgNVHQ8EBAMCAYYwDQYJKoZI hvcNAQEFBQADggEBAD4bbQVg0Hh42EpYX4/JPkNS3OUAEWR/YgzZUY1QGi9rQZ4pfcjU1/Ta oNT8Y7Yf0RO+e9NiG9+BDhQH/kQiZOQo9rv9NUb8xDtKCYCad7zEQtVsYsWuvK2XLw/Ji1m2 eBvoOB4RS/5LAWfNws7W+DWt2ayzeTCyrLSrx7ZVgBjzNOm0TPIkbfppdwgxuo7FZL8ts+M2 492Al87d3VasevUS1pprRBEupChmPTt1hjtajkQOpT4BQAzP1lVEYrWzlv+O/lbP9iujKpYW cfYqQ3FGf37YCvuDeues4xm+nqmyraNsNeI8Gh3XDIwqfzHnLhy4Y80VyqN/Jj8df3SK9AAw ggTOMIIDtqADAgECAgpDgT5qAAAAADKHMA0GCSqGSIb3DQEBCwUAMFExCzAJBgNVBAYTAlVT MR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxEzARBgNV BAMTCk1JVExMIENBLTIwHhcNMTIwMzA1MTUxODA3WhcNMTMwMzA1MTUxODA3WjBhMQswCQYD VQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEPMA0GA1UECxMGUGVv cGxlMSAwHgYDVQQDExdCbHVtZW50aGFsLlVyaS41MDAxMDU4NDCCASIwDQYJKoZIhvcNAQEB BQADggEPADCCAQoCggEBAM1hd7gYE3EAuUHpQXBAAsld4ttPFF2dJILTwLxpMAwAOeuCE2FN Qm7r5aIXSmwfYReSBSvZ01k6YOx3hqxMUJYgDTWvQ9A5OEufC3aD71g18VhHvqMs8uBEj7aX Na6dNd8V10yl4GZ4pXffNSN1Qb1S6pQ0r9NNILb+ZSevs3DGNE5rZwHxM0Ed62MjDyR4r7tL pFbkvlEFDdj8epEz7C6zEUPLyr8JjCDbLqhV4uoNdQQxweEPhSVadd5bDoT5w9OM4h4g/1hU PI/zuzp1pZLWiRigsmsCiT2YQUs3phYnRGkRzyenY3Usu+HtXtG1fSleaoeZtOqlcT01RBtP K1MCAwEAAaOCAZYwggGSMB0GA1UdDgQWBBShib6es0uFKEYxkMQRe+e7efVhBzAOBgNVHQ8B Af8EBAMCBSAwHwYDVR0jBBgwFoAUjkp9iaFjFxyBiDRXNyZFXhmKfiQwMwYDVR0fBCwwKjAo oCagJIYiaHR0cDovL2NybC5sbC5taXQuZWR1L2dldGNybC9MTENBMjBiBggrBgEFBQcBAQRW MFQwLQYIKwYBBQUHMAKGIWh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXR0by9MTENBMjAjBggr BgEFBQcwAYYXaHR0cDovL29jc3AubGwubWl0LmVkdS8wDAYDVR0TAQH/BAIwADA9BgkrBgEE AYI3FQcEMDAuBiYrBgEEAYI3FQiDg+Udh+ynZoathxWD6vBFhbahHx2F69Bwg+vtIAIBZAIB BDAlBgNVHSUEHjAcBgRVHSUABggrBgEFBQcDBAYKKwYBBAGCNwoDBDAYBgNVHSAEETAPMA0G CyqGSIb3EgIBAwEIMBkGA1UdEQQSMBCBDnVyaUBsbC5taXQuZWR1MA0GCSqGSIb3DQEBCwUA A4IBAQBqmZjWIBD5zFsLODc5rYV8zKQKukfF+u4DpNFzEHbCjNn1TBLBa0HVy1kLBA1ZwQPi cOw/XFgW8GHJo6Zpnd0NWwr02KbzJEn3wm5NmYWRTvuW9ld9O8/vkoPl0EmOfCbLoeQHNiEM lkBgoiC3nx54JaUTubWVcY7/caYldaT+VllH+y3PDB5yfO0YnAXkDbDqr+OBAM7dRe0QhcgS ZxTcRnrWGTUHwVV1yl4+Mxc++V1iLX1HdC1IdfKYHhswJbKOteuuCRLuhbKLpX/+y5cl6I/w 9u44Y86l34NExCasoNebcTzSVR5bKEWGhbntpDULl8cLMzXGlPQ5Oh614HeSMYIB5TCCAeEC AQEwXzBRMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEM MAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBDQS0yAgoYeP+3AAAAAByAMAkGBSsOAwIa BQCgXTAjBgkqhkiG9w0BCQQxFgQU/FEow+6va0WCuTzB/apBREDlkzgwGAYJKoZIhvcNAQkD MQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTIwNjE0MTUxMjMzWjANBgkqhkiG9w0B AQEFAASCAQAF/bUove3ixQBHmpY/SpMeFXwEp/dIGCeBm5MDpQ9ZwHlJPqVg+1AFmnJROWUA fz/d7Pe9r8AgxDe5qtGzsy1W8gkeJGWT41QjsOhpck14Y4/68I0cf2pkSaTwInqOmTC96dLQ /uX0D0WgH+y4EEGweoWT0jfOrhdsxs3oW8qzK4dR1cNdakNuUDzucpNo1FzKBX0ZW7OtVt8l Mc5EVKhjr3Hi5y2VQEg4sfo6gEj5mD/cov1zH6ca9K01GCmVp3LPQv5bh3sVihTIcbF+M+Cm jRzjubACFRtY0EPRVrUyKeKauruyB1S82/rbX6tokj41NS5e540wsT8/DSGN6+bq --B_3422517153_124503962-- From prvs=75126a4a1d=uri@ll.mit.edu Thu Jun 14 08:21:04 2012 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 4CC6321F86E8 for ; Thu, 14 Jun 2012 08:21:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.201 X-Spam-Level: X-Spam-Status: No, score=-5.201 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0rn61wZItKJQ for ; Thu, 14 Jun 2012 08:21:01 -0700 (PDT) Received: from mx2.ll.mit.edu (MX2.LL.MIT.EDU [129.55.12.46]) by ietfa.amsl.com (Postfix) with ESMTP id 4AF8E21F86DB for ; Thu, 14 Jun 2012 08:21:01 -0700 (PDT) Received: from LLE2K7-HUB02.mitll.ad.local (LLE2K7-HUB02.mitll.ad.local) by mx2.ll.mit.edu (unknown) with ESMTP id q5EFKmiZ013077; Thu, 14 Jun 2012 11:20:49 -0400 From: "Blumenthal, Uri - 0668 - MITLL" To: "Blumenthal, Uri - 0668 - MITLL" , "Henderson, Thomas R" , "'Igoe, Kevin M.'" , "cfrg@irtf.org" Date: Thu, 14 Jun 2012 11:20:45 -0400 Thread-Topic: [Cfrg] HIP Help (I hope!) Thread-Index: Ac1KQUaKUXuLcxqISOyYU+PSEwQiMA== Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.12.0.110505 acceptlanguage: en-US Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3422517645_124514339" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.7.7855, 1.0.260, 0.0.0000 definitions=2012-06-14_04:2012-06-14, 2012-06-14, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=2 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=6.0.2-1203120001 definitions=main-1206140131 Cc: 'Robert Moskowitz' Subject: Re: [Cfrg] HIP Help (I hope!) X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jun 2012 15:21:04 -0000 --B_3422517645_124514339 Content-type: multipart/alternative; boundary="B_3422517645_124538300" --B_3422517645_124538300 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Oops, just noticed that this seems to be about transporting the keys. Sorry= ! Yes, RSA-OAEP is very good for that (though my argument about not using RSA if you already have a symmetric key established still holds). You may also consider ECIES instead of or in addition to RSA, to support Elliptic Curve suite. --=20 Regards, Uri Blumenthal Voice: (781) 981-1638 >> Kevin and all, =8A=8A=8A=8A.. >> For the keys used in HIP themselves (used for signing/authentication), H= IP >> specifies these types: >> DSA 3 [RFC2536 = ] >> (RECOMMENDED) > Considering Suite B, I am not sure I'd still recommend DSA. >> RSA 5 [RFC3110 = ] >> (REQUIRED) > Well, I'd move from RSA, but I recognize the reality =AD megatons of > already-deployed RSA code and certs=8A >> ECDSA 7 [RFC4754 = ] >> (RECOMMENDED) > Yes, and I'd consider elevating ECDSA to REQUIRED, to facilitate and enco= urage > the move. >> ECDSA_LOW 9 [SECG >> ] >> (RECOMMENDED) > I would drop ECDSA_LOW altogether. >=20 >> The feedback that I received was to follow NIST 800-131A on key strength >> regarding all of these key types, and to consider not using ECDSA_LOW. = We'd >> like to retain ECDSA_LOW, suitably caveated ("defined for devices with l= ow >> computational capabilities"). For DSA, we could replace the existing >> reference to a reference to FIPS 186-3 and also reference RFC 5114 2.3 w= ith >> 2048-bit subgroups for use with SHA2-256. > At the very least. SHA3 should come out some time this year =AD do you care= to > wait=8A? >=20 >> The hash used for RSA and DSA signature is SHA-256, so I don't think an= y >> change is needed there. > It should be sufficient, based on what we currently know. >=20 >> For RSA signature padding, the RSAASA-PSS [RFC3447] should replace the >> reference to RFC3110 above, and explicitly state that PSS instead of PKC= S1.5 >> padding is used. I am not sure whether we need to state anything about >> padding for other signature types (guidance here would be helpful). > I'll let others comment on this. >=20 >> Regarding OAEP, currently HIP specifies these ciphers for use in the >> ENCRYPTED parameter (used to encrypt small blocks of data): >> AES-128-CBC 2 ([RFC3602]) required >> 3DES-CBC 3 ([RFC2451]) >> AES-256-CBC 4 ([RFC3602]) >> =20 >> I believe that we are being asked to also support RSA-OAEP here (RFC 405= 5). >> Would specifing an additional (non-required) option for RSAES-OAEP >> ([RFC4055]) suffice, or is OAEP a preferred technique for encrypting >> parameters over AES-128-CBC? > RSA-OAEP as a preferred technique to encrypt what? For passing along AES = and > other cryptographic keys =AD sure, it's a great mechanism. To encrypt data > chunks (large or small) if/when you already have an AES key established > between the parties =AD no way. To infrequently send small things when you = don't > have a symmetric key established =AD if you want to be 10% stateless, then = yes, > RSA-OAEP would do the job; but if you can afford setting up a symmetric > channel and/or plan on exchanging a whole bunch of these small things =AD y= ou're > better off not using RSA-OAEP for data transfer... >> Also, I understand that we ought to consider clarifying that 3DES-CBC = is >> the three-key variant (NIST 800-131A), or removing it altogether (which = I >> think is what you advocated below). > I would just remove it, as I see no purpose in carrying 3DES over. >=20 >> Regarding encryption padding, the current draft specifies to use whatev= er >> padding is specified by the encryption algorithm, citing PKCS5 for AES, = and >> not mentioning 3DES-CBC padding (in practice, our implementation also pa= ds >> this according to PKCS5). > Why not=8A :) --B_3422517645_124538300 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable
= Oops, just noticed that this seems to be about transporting the keys.= Sorry! Yes, RSA-OAEP is very good for that (though my argument about not=  using RSA if you already have a symmetric key established still ho= lds). You may also consider ECIES instead of or in addition to RSA, to suppo= rt Elliptic Curve suite.
-= - 
Regards,<= /div>
Uri Blumenthal       =                      = Voice: (781) 981-1638


Kevin and all, …………..

For the keys used in HIP themselves (used for = signing/authentication), HIP specifies these types:

        DSA    =           3 [RFC2536] (RECOMMENDED)

=
Considering Suite B, I am not sure I'd&nb= sp;still recommend DSA.

        RSA     &nb= sp;        5 [RFC3110] (REQUIRED)

Well, I'd move from RSA, but I recognize the rea= lity – megatons of already-deployed RSA code and certs…

        ECDSA   &nb= sp;        7 [RFC4754] (RECOMMENDE= D)

Yes, and I'd co= nsider elevating ECDSA to REQUIRED, to facilitate and encourage the move.

<= /p>

        ECDSA_LOW  = ;      9 [SECG]    (RECOMMENDED)

=
I would drop ECDSA_LOW altog= ether.

=

The feedback that I re= ceived was to follow NIST 800-131A on key strength regarding all of these ke= y types, and to consider not using ECDSA_LOW.  We'd like to retain ECDS= A_LOW, suitably caveated ("defined for devices with low computational capabi= lities").  For DSA, we could replace the existing reference to a refere= nce to FIPS 186-3 and also reference RFC 5114 2.3 with 2048-bit subgroups fo= r use with SHA2-256.


<= /o:p>

&= nbsp;The hash used for RSA and DSA signature is SHA-256, so I don't think = any change is needed there.

=
It should be sufficient, based on what we currently know.

 For RSA signature= padding, the RSAASA-PSS [RFC3447] should replace the reference to RFC3110 a= bove, and explicitly state that PSS instead of PKCS1.5 padding is used. = ; I am not sure whether we need to state anything about padding for other si= gnature types (guidance here would be helpful).

=
I'll let others comment on this.

 Regarding OAEP, currently HIP= specifies these ciphers for use in the ENCRYPTED parameter (used to encrypt= small blocks of data):

   AES-128-CBC   &nbs= p;    2     ([RFC3602])  required

&n= bsp; 3DES-CBC           3&= nbsp;    ([RFC2451])

 

I believe that we are being asked to also support RS= A-OAEP here (RFC 4055).  Would specifing an additional (non-required) o= ption for RSAES-OAEP ([RFC4055]) suffice, or is OAEP a preferred technique f= or encrypting parameters over AES-128-CBC?

RSA-OAEP as a preferred technique to encrypt wha= t? For passing along AES and other cryptographic keys – sure, it's= a great mechanism. To encrypt data chunks (large or small) if/when you alre= ady have an AES key established between the parties – no way. To infre= quently send small things when you don't have a symmetric key established &#= 8211; if you want to be 10% stateless, then yes, RSA-OAEP would do the job; = but if you can afford setting up a symmetric channel and/or plan on exchangi= ng a whole bunch of these small things – you're better off not using R= SA-OAEP for data transfer...

  Also, I under= stand that we ought to consider clarifying that 3DES-CBC is the three-key va= riant (NIST 800-131A), or removing it altogether (which I think is what you = advocated below).

= I would just remove it, as I see no purpose in carrying 3DES over.

 Regarding encryption padd= ing, the current draft specifies to use whatever padding is specified by the= encryption algorithm, citing PKCS5 for AES, and not mentioning 3DES-CBC pad= ding (in practice, our implementation also pads this according to PKCS5).

Why not… :)
 --B_3422517645_124538300-- --B_3422517645_124514339 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIUAAYJKoZIhvcNAQcCoIIT8TCCE+0CAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC EeMwggTLMIIDs6ADAgECAgoYeP+3AAAAAByAMA0GCSqGSIb3DQEBCwUAMFExCzAJBgNVBAYT AlVTMR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxEzAR BgNVBAMTCk1JVExMIENBLTIwHhcNMTEwNzEzMjAyMzU1WhcNMTIwNzEyMjAyMzU1WjBhMQsw CQYDVQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEPMA0GA1UECxMG UGVvcGxlMSAwHgYDVQQDExdCbHVtZW50aGFsLlVyaS41MDAxMDU4NDCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAL4TeQPMpFpVQVbz3C9Es122DpioIq8JSZDol89SV3kYUPMj G8K3uynPscCziyfPlF6dJveeRp2DneKKkmgWbCrwN2zPOEu8fBqNHfWsRqsPA66SkA9XrkpQ v0wgw9sZNOf4oU1l+KGCn6bbZkHdbNLrlUV3R99TpQwY6qolZMy/uvYjWLmH3NutWEDsODl6 FP0nKt5nKiuG9t2FGPUYVyOKdf/u39VMzDApcOgKub3NlkXW+zzQZ7zF2aW4GQdUf7BUYMRX x0B5p1YiBRAoX8orCW5FFZ0vrUlTyNKu7NHMZwWm899JIVYD+EBASC40fNB/afphCsAgXDsh QTikAkkCAwEAAaOCAZMwggGPMB0GA1UdDgQWBBSQq3VtNOCIqvvszUnlxLlhFXsEFDAOBgNV HQ8BAf8EBAMCBsAwHwYDVR0jBBgwFoAUjkp9iaFjFxyBiDRXNyZFXhmKfiQwMwYDVR0fBCww KjAooCagJIYiaHR0cDovL2NybC5sbC5taXQuZWR1L2dldGNybC9MTENBMjBiBggrBgEFBQcB AQRWMFQwLQYIKwYBBQUHMAKGIWh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXR0by9MTENBMjAj BggrBgEFBQcwAYYXaHR0cDovL29jc3AubGwubWl0LmVkdS8wDAYDVR0TAQH/BAIwADA9Bgkr BgEEAYI3FQcEMDAuBiYrBgEEAYI3FQiDg+Udh+ynZoathxWD6vBFhbahHx2Fy94yh/+KcwIB ZAIBBTAiBgNVHSUBAf8EGDAWBggrBgEFBQcDBAYKKwYBBAGCNwoDDDAYBgNVHSAEETAPMA0G CyqGSIb3EgIBAwEIMBkGA1UdEQQSMBCBDnVyaUBsbC5taXQuZWR1MA0GCSqGSIb3DQEBCwUA A4IBAQCfzOm9Ms0oupY104yKv6x3gTnVunF9Yc0Jok2zUUy8DNPLzUMYeVaV9SQu7Z6JmQXB gqgjnnpfVjCO0kg61uyL9bpovn2E4mmneRmetQdNq56/rtrxnlh3gNbGidWH+FfvxL97AVpD bccsV7wDBT2MQgaLVtUHNqDrPEC+0dtkMFK/6vgrShfUh3pCm6G3BhDFlBFMSTl/mcxO/x10 KbXVbhMUz7biweTBbiJUQdG7iemRG//HXOpMHtKZ94ro3YUJ52nhkjfnMJMqzX+aKM116CbM gmJji36vaZK2l6Y7+Es59SZUTwxkTupZTqXADFXO9LWAmYdZjZYcumaToubrMIIEtzCCA5+g AwIBAgIBFDANBgkqhkiG9w0BAQsFADBUMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlUIExp bmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRYwFAYDVQQDEw1NSVRMTCBSb290IENB MB4XDTA5MTIxNDEyMDAwMFoXDTE1MTIzMTIzNTk1OVowUTELMAkGA1UEBhMCVVMxHzAdBgNV BAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsTA1BLSTETMBEGA1UEAxMKTUlU TEwgQ0EtMjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKcEyyNhSIfsN6AzBwVh Zkzo6SdjNGAQ7mA2A8T0kmdCB8MH6jWjVVMwFZwlg9cgjgLKEuEO9KN8K9M8jgeZEMoinlRf k3YELPC7sEkkzBQkcVpLhEwALue9iHowgSLGmXZpYKmRhfvhvYJ4MNCuIaWpcK/GaDZCE+U2 aTg42kv/zQrH3AoqFX81OF7niwXNnanP1hQRfkMTRrnaEW8DX0TMaG/t9Ry5xSMrLTNc9DvQ tjA5ZcuWnECiUpyDBFWxLr9yx7xgf1/LwgCxcoBeKSBBoWzkQmKAsgMo9Mq1Fp/nnIqw5FKm gOs7Vy+6e0Dk+cgf+oAV8AK8ZFMQrVE0uH0CAwEAAaOCAZUwggGRMBIGA1UdEwEB/wQIMAYB Af8CAQAwHQYDVR0OBBYEFI5KfYmhYxccgYg0VzcmRV4Zin4kMB8GA1UdIwQYMBaAFGeqes/0 Cqa5crWKoNKd8hDDQ+0pMA4GA1UdDwEB/wQEAwIBhjBhBggrBgEFBQcBAQRVMFMwLQYIKwYB BQUHMAKGIWh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXR0bz9MTFJDQTAiBggrBgEFBQcwAYYW aHR0cDovL29jc3AubGwubWl0LmVkdTAzBgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLmxs Lm1pdC5lZHUvZ2V0Y3JsP0xMUkNBMIGSBgNVHSAEgYowgYcwDQYLKoZIhvcSAgEDAQYwDQYL KoZIhvcSAgEDAQgwDQYLKoZIhvcSAgEDAQcwDQYLKoZIhvcSAgEDAQkwDQYLKoZIhvcSAgED AQowDQYLKoZIhvcSAgEDAQswDQYLKoZIhvcSAgEDAQ4wDQYLKoZIhvcSAgEDAQ8wDQYLKoZI hvcSAgEDARAwDQYJKoZIhvcNAQELBQADggEBAIh3BqHQ/XH8C6DCL+eEGroOzxBcCqTNItms v4MANaOTodgU2jrjHcGjXlzqhpb8ZxOlkAK3dK09rc6+yACcoK2TzVtDRZXYxov/SqZRjI3d ufU2JatAPxosCyy/1otjl1TKUY47Wvft31vdf5i0XK2DQVEJ+XlqtgBiFTVIMIfBJwPajrsi z+pgFEYwhhwJxvs8flSi0FLCE77VYLEioP5hxG6zIPeQRxzh1bogbfphWHHtoiTDkBSZ4Ufv GXQTVf7QjhD5yYw10yICtjHmtgbfgBkH5/vvR92NY9RSlNPzZqmGKIia61bJCmagRYGyexfe dVNF0cJWL4J/cLHhgNYwggODMIICa6ADAgECAgEBMA0GCSqGSIb3DQEBBQUAMFQxCzAJBgNV BAYTAlVTMR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kx FjAUBgNVBAMTDU1JVExMIFJvb3QgQ0EwHhcNMDgwOTIzMTIwMDAwWhcNMjkxMjMxMjM1OTU5 WjBUMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoG A1UECxMDUEtJMRYwFAYDVQQDEw1NSVRMTCBSb290IENBMIIBIjANBgkqhkiG9w0BAQEFAAOC AQ8AMIIBCgKCAQEAxU4pF1iyJrL5rYq/XBAKg93kCTATG7Bw0NGFpEJ1A3Xsr6UIIq9/1VJB OgCwDqrVsAK1lRwy/lkrHzPkobiMr1wzjQ28SR/9sg5kAcmrMqBYbc302qtwCGKZxdNdhAh2 nUOCO10AMpUsCNdpikPY9ukT8lsA+eorM4Q1rc/L0J6AHRptOU7IuDBdZj+tdNb7gv+GKknr 6wj9m2sVGawoaG7AAqhsWvQUM/q4h/H5FpYlwnVAEh2AzhqiG9bwl6uJJIzJ/8uUWldNkVwz 1I5fR/vCaxiLXIW4oUydBuRKTG+ekEoxHGuD73yx5JtsSciS8HQL2oEM8tv+VAC+albqgwID AQABo2AwXjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdDgQWBBRnqnrP9AqmuXK1iqDSnfIQw0Pt KTAfBgNVHSMEGDAWgBRnqnrP9AqmuXK1iqDSnfIQw0PtKTALBgNVHQ8EBAMCAYYwDQYJKoZI hvcNAQEFBQADggEBAD4bbQVg0Hh42EpYX4/JPkNS3OUAEWR/YgzZUY1QGi9rQZ4pfcjU1/Ta oNT8Y7Yf0RO+e9NiG9+BDhQH/kQiZOQo9rv9NUb8xDtKCYCad7zEQtVsYsWuvK2XLw/Ji1m2 eBvoOB4RS/5LAWfNws7W+DWt2ayzeTCyrLSrx7ZVgBjzNOm0TPIkbfppdwgxuo7FZL8ts+M2 492Al87d3VasevUS1pprRBEupChmPTt1hjtajkQOpT4BQAzP1lVEYrWzlv+O/lbP9iujKpYW cfYqQ3FGf37YCvuDeues4xm+nqmyraNsNeI8Gh3XDIwqfzHnLhy4Y80VyqN/Jj8df3SK9AAw ggTOMIIDtqADAgECAgpDgT5qAAAAADKHMA0GCSqGSIb3DQEBCwUAMFExCzAJBgNVBAYTAlVT MR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxEzARBgNV BAMTCk1JVExMIENBLTIwHhcNMTIwMzA1MTUxODA3WhcNMTMwMzA1MTUxODA3WjBhMQswCQYD VQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEPMA0GA1UECxMGUGVv cGxlMSAwHgYDVQQDExdCbHVtZW50aGFsLlVyaS41MDAxMDU4NDCCASIwDQYJKoZIhvcNAQEB BQADggEPADCCAQoCggEBAM1hd7gYE3EAuUHpQXBAAsld4ttPFF2dJILTwLxpMAwAOeuCE2FN Qm7r5aIXSmwfYReSBSvZ01k6YOx3hqxMUJYgDTWvQ9A5OEufC3aD71g18VhHvqMs8uBEj7aX Na6dNd8V10yl4GZ4pXffNSN1Qb1S6pQ0r9NNILb+ZSevs3DGNE5rZwHxM0Ed62MjDyR4r7tL pFbkvlEFDdj8epEz7C6zEUPLyr8JjCDbLqhV4uoNdQQxweEPhSVadd5bDoT5w9OM4h4g/1hU PI/zuzp1pZLWiRigsmsCiT2YQUs3phYnRGkRzyenY3Usu+HtXtG1fSleaoeZtOqlcT01RBtP K1MCAwEAAaOCAZYwggGSMB0GA1UdDgQWBBShib6es0uFKEYxkMQRe+e7efVhBzAOBgNVHQ8B Af8EBAMCBSAwHwYDVR0jBBgwFoAUjkp9iaFjFxyBiDRXNyZFXhmKfiQwMwYDVR0fBCwwKjAo oCagJIYiaHR0cDovL2NybC5sbC5taXQuZWR1L2dldGNybC9MTENBMjBiBggrBgEFBQcBAQRW MFQwLQYIKwYBBQUHMAKGIWh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXR0by9MTENBMjAjBggr BgEFBQcwAYYXaHR0cDovL29jc3AubGwubWl0LmVkdS8wDAYDVR0TAQH/BAIwADA9BgkrBgEE AYI3FQcEMDAuBiYrBgEEAYI3FQiDg+Udh+ynZoathxWD6vBFhbahHx2F69Bwg+vtIAIBZAIB BDAlBgNVHSUEHjAcBgRVHSUABggrBgEFBQcDBAYKKwYBBAGCNwoDBDAYBgNVHSAEETAPMA0G CyqGSIb3EgIBAwEIMBkGA1UdEQQSMBCBDnVyaUBsbC5taXQuZWR1MA0GCSqGSIb3DQEBCwUA A4IBAQBqmZjWIBD5zFsLODc5rYV8zKQKukfF+u4DpNFzEHbCjNn1TBLBa0HVy1kLBA1ZwQPi cOw/XFgW8GHJo6Zpnd0NWwr02KbzJEn3wm5NmYWRTvuW9ld9O8/vkoPl0EmOfCbLoeQHNiEM lkBgoiC3nx54JaUTubWVcY7/caYldaT+VllH+y3PDB5yfO0YnAXkDbDqr+OBAM7dRe0QhcgS ZxTcRnrWGTUHwVV1yl4+Mxc++V1iLX1HdC1IdfKYHhswJbKOteuuCRLuhbKLpX/+y5cl6I/w 9u44Y86l34NExCasoNebcTzSVR5bKEWGhbntpDULl8cLMzXGlPQ5Oh614HeSMYIB5TCCAeEC AQEwXzBRMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEM MAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBDQS0yAgoYeP+3AAAAAByAMAkGBSsOAwIa BQCgXTAjBgkqhkiG9w0BCQQxFgQUBtqDmiSX7bzTRXG3DUGYK/Qq/S4wGAYJKoZIhvcNAQkD MQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTIwNjE0MTUyMDQ1WjANBgkqhkiG9w0B AQEFAASCAQB33nUNroyfzpJmPwWYFLYUuhv+aonM7QIJf9L1DnmYLfp9s5AeZaKNrRWuyt2g ohGT54O0YKTTn688UR/JVNr5YVKDGHA+19RPq5mVVDcmDJxlKfyqD+HIbuXfVNZv+4P6Tley TNNvgywg5yYN5rgZaZLex4Byxnx57HO5Oysi1Ts2QWpGFwimvP+VuLb7aclLlpEJ955P+8RL EI8+YYtjNmpjnyFlOebl8M7yVxz727hria1VgRT5mz0GRVHAOsUc2G/oe+0P5fArLMgYEKCG kl0FfMO3E1SWa8JVa7Ts/iew17xHUUOZO3KPxjKGJzDZRmx988St7JvVXBRdKYPD --B_3422517645_124514339-- From thomas.r.henderson@boeing.com Thu Jun 14 08:47:45 2012 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 A741721F8707 for ; Thu, 14 Jun 2012 08:47:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.223 X-Spam-Level: X-Spam-Status: No, score=-102.223 tagged_above=-999 required=5 tests=[AWL=-0.376, BAYES_00=-2.599, HTML_MESSAGE=0.001, SARE_OBFU_ALL=0.751, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aqhyHFJb6BFJ for ; Thu, 14 Jun 2012 08:47:42 -0700 (PDT) Received: from stl-mbsout-01.boeing.com (stl-mbsout-01.boeing.com [130.76.96.169]) by ietfa.amsl.com (Postfix) with ESMTP id 9118621F86D4 for ; Thu, 14 Jun 2012 08:47:42 -0700 (PDT) Received: from stl-mbsout-01.boeing.com (localhost.localdomain [127.0.0.1]) by stl-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with ESMTP id q5EFlfwL003436 for ; Thu, 14 Jun 2012 10:47:41 -0500 Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [130.247.16.37]) by stl-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id q5EFldO9003416 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 14 Jun 2012 10:47:40 -0500 Received: from blv-av-01.boeing.com (localhost.localdomain [127.0.0.1]) by blv-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id q5EFldWf016538; Thu, 14 Jun 2012 08:47:39 -0700 Received: from XCH-NWHT-08.nw.nos.boeing.com (xch-nwht-08.nw.nos.boeing.com [130.247.25.112]) by blv-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id q5EFlctb016520 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Thu, 14 Jun 2012 08:47:38 -0700 Received: from XCH-NW-16V.nw.nos.boeing.com ([130.247.25.238]) by XCH-NWHT-08.nw.nos.boeing.com ([130.247.25.112]) with mapi; Thu, 14 Jun 2012 08:47:38 -0700 From: "Henderson, Thomas R" To: "'Blumenthal, Uri - 0668 - MITLL'" , "'Igoe, Kevin M.'" , "cfrg@irtf.org" Date: Thu, 14 Jun 2012 08:47:38 -0700 Thread-Topic: [Cfrg] HIP Help (I hope!) Thread-Index: Ac1KQUaKUXuLcxqISOyYU+PSEwQiMAAAlO0Q Message-ID: <758141CC3D829043A8C3164DD3D593EA1BD324E084@XCH-NW-16V.nw.nos.boeing.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_003D_01CD4A0A.59C8C270" MIME-Version: 1.0 X-TM-AS-MML: No Cc: 'Robert Moskowitz' Subject: Re: [Cfrg] HIP Help (I hope!) X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jun 2012 15:47:45 -0000 ------=_NextPart_000_003D_01CD4A0A.59C8C270 Content-Type: multipart/alternative; boundary="----=_NextPart_001_003E_01CD4A0A.59C8C270" ------=_NextPart_001_003E_01CD4A0A.59C8C270 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To clarify, the ENCRYPTED parameter is currently used (optionally) in only one HIP message (the I2), to encrypt another HIP parameter (the initiator's host identity): http://tools.ietf.org/html/draft-ietf-hip-rfc5201-bis-08#section-5.2.18 I suppose that other uses could be invented for this parameter in the future. My sense of this issue is that OEAP is not required (we have symmetric keys available at this point), but OEAP could be used, and opinions differ on whether OEAP is the best technique for this. - Tom From: Blumenthal, Uri - 0668 - MITLL [mailto:uri@ll.mit.edu] Sent: Thursday, June 14, 2012 8:21 AM To: Blumenthal, Uri - 0668 - MITLL; Henderson, Thomas R; 'Igoe, Kevin M.'; cfrg@irtf.org Cc: 'Robert Moskowitz' Subject: Re: [Cfrg] HIP Help (I hope!) Oops, just noticed that this seems to be about transporting the keys. Sorry! Yes, RSA-OAEP is very good for that (though my argument about not using RSA if you already have a symmetric key established still holds). You may also consider ECIES instead of or in addition to RSA, to support Elliptic Curve suite. -- Regards, Uri Blumenthal Voice: (781) 981-1638 Kevin and all, ...... For the keys used in HIP themselves (used for signing/authentication), HIP specifies these types: DSA 3 [RFC2536 ] (RECOMMENDED) Considering Suite B, I am not sure I'd still recommend DSA. RSA 5 [RFC3110 ] (REQUIRED) Well, I'd move from RSA, but I recognize the reality - megatons of already-deployed RSA code and certs. ECDSA 7 [RFC4754 ] (RECOMMENDED) Yes, and I'd consider elevating ECDSA to REQUIRED, to facilitate and encourage the move. ECDSA_LOW 9 [SECG ] (RECOMMENDED) I would drop ECDSA_LOW altogether. The feedback that I received was to follow NIST 800-131A on key strength regarding all of these key types, and to consider not using ECDSA_LOW. We'd like to retain ECDSA_LOW, suitably caveated ("defined for devices with low computational capabilities"). For DSA, we could replace the existing reference to a reference to FIPS 186-3 and also reference RFC 5114 2.3 with 2048-bit subgroups for use with SHA2-256. At the very least. SHA3 should come out some time this year - do you care to wait.? The hash used for RSA and DSA signature is SHA-256, so I don't think any change is needed there. It should be sufficient, based on what we currently know. For RSA signature padding, the RSAASA-PSS [RFC3447] should replace the reference to RFC3110 above, and explicitly state that PSS instead of PKCS1.5 padding is used. I am not sure whether we need to state anything about padding for other signature types (guidance here would be helpful). I'll let others comment on this. Regarding OAEP, currently HIP specifies these ciphers for use in the ENCRYPTED parameter (used to encrypt small blocks of data): AES-128-CBC 2 ([RFC3602]) required 3DES-CBC 3 ([RFC2451]) AES-256-CBC 4 ([RFC3602]) I believe that we are being asked to also support RSA-OAEP here (RFC 4055). Would specifing an additional (non-required) option for RSAES-OAEP ([RFC4055]) suffice, or is OAEP a preferred technique for encrypting parameters over AES-128-CBC? RSA-OAEP as a preferred technique to encrypt what? For passing along AES and other cryptographic keys - sure, it's a great mechanism. To encrypt data chunks (large or small) if/when you already have an AES key established between the parties - no way. To infrequently send small things when you don't have a symmetric key established - if you want to be 10% stateless, then yes, RSA-OAEP would do the job; but if you can afford setting up a symmetric channel and/or plan on exchanging a whole bunch of these small things - you're better off not using RSA-OAEP for data transfer... Also, I understand that we ought to consider clarifying that 3DES-CBC is the three-key variant (NIST 800-131A), or removing it altogether (which I think is what you advocated below). I would just remove it, as I see no purpose in carrying 3DES over. Regarding encryption padding, the current draft specifies to use whatever padding is specified by the encryption algorithm, citing PKCS5 for AES, and not mentioning 3DES-CBC padding (in practice, our implementation also pads this according to PKCS5). Why not. :) ------=_NextPart_001_003E_01CD4A0A.59C8C270 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

To clarify, the ENCRYPTED parameter is currently used (optionally) in = only one HIP message (the I2), to encrypt another HIP parameter (the = initiator's host identity):

http://tools.ietf.org/html/draft-ietf-hip-rfc5201-bis-08#section-5.2.1= 8

I suppose that other uses could be invented for this parameter in the = future.

 

My sense of this issue is that OEAP is not required (we have = symmetric keys available at this point), but OEAP could be used, and = opinions differ on whether OEAP is the best technique for = this.

 

- Tom

 

From:= = Blumenthal, Uri - 0668 - MITLL [mailto:uri@ll.mit.edu]
Sent: = Thursday, June 14, 2012 8:21 AM
To: Blumenthal, Uri - 0668 - = MITLL; Henderson, Thomas R; 'Igoe, Kevin M.'; = cfrg@irtf.org
Cc: 'Robert Moskowitz'
Subject: Re: = [Cfrg] HIP Help (I hope!)

 

= Oops, just noticed that this seems to be about transporting the = keys. Sorry! Yes, RSA-OAEP is very good for that (though my = argument about not using RSA if you already have a symmetric = key established still holds). You may also consider ECIES instead of or = in addition to RSA, to support Elliptic Curve = suite.

-- =

Regards,=

Uri Blumenthal         =                   =  Voice: (781) 981-1638=

 

<= /div>

=  

Kevin and all, …………..=

For the keys used in HIP themselves (used for signing/authentication), = HIP specifies these types:=

  =       = DSA           &nbs= p;  3 [RFC2536] (RECOMMENDED)=

= Considering Suite B, I am not sure I'd still recommend = DSA.

  =       = RSA           &nbs= p;  5 [RFC3110] (REQUIRED)=

= Well, I'd move from RSA, but I recognize the reality – megatons of = already-deployed RSA code and = certs…

       =  ECDSA          &n= bsp; 7 [RFC4754] = (RECOMMENDED)=

= Yes, and I'd consider elevating ECDSA to REQUIRED, to facilitate and = encourage the move.

        = ECDSA_LOW        9 [SECG]    (RECOMMENDED)=

= I would drop ECDSA_LOW altogether.

=  

The feedback that I received was to follow NIST 800-131A on key = strength regarding all of these key types, and to consider not using = ECDSA_LOW.  We'd like to retain ECDSA_LOW, suitably caveated = ("defined for devices with low computational = capabilities").  For DSA, we could replace the existing = reference to a reference to FIPS 186-3 and also reference RFC 5114 2.3 = with 2048-bit subgroups for use with SHA2-256.=

= At the very least. SHA3 should come out some time this year – do = you care to wait…?

=  

 The hash used for RSA and DSA = signature is SHA-256, so I don't think any change is needed = there.=

= It should be sufficient, based on what we currently = know.

=  

 For RSA signature padding, the = RSAASA-PSS [RFC3447] should replace the reference to RFC3110 above, and = explicitly state that PSS instead of PKCS1.5 padding is used.  I am = not sure whether we need to state anything about padding for other = signature types (guidance here would be helpful).=

= I'll let others comment on this.

=  

 Regarding OAEP, currently HIP = specifies these ciphers for use in the ENCRYPTED parameter (used to = encrypt small blocks of data):=

 =   AES-128-CBC        = 2     ([RFC3602])  = required

=   = 3DES-CBC           = 3     ([RFC2451])

=   AES-256-CBC        = 4     ([RFC3602])

 =

I believe that we are being asked to also support RSA-OAEP here (RFC = 4055).  Would specifing an additional (non-required) option for = RSAES-OAEP ([RFC4055]) suffice, or is OAEP a preferred technique for = encrypting parameters over AES-128-CBC?=

= RSA-OAEP as a preferred technique to encrypt what? For passing = along AES and other cryptographic keys – sure, it's a great = mechanism. To encrypt data chunks (large or small) if/when you already = have an AES key established between the parties – no way. To = infrequently send small things when you don't have a symmetric key = established – if you want to be 10% stateless, then yes, RSA-OAEP = would do the job; but if you can afford setting up a symmetric channel = and/or plan on exchanging a whole bunch of these small things – = you're better off not using RSA-OAEP for data = transfer...

  Also, I understand that we ought to consider clarifying that = 3DES-CBC is the three-key variant (NIST 800-131A), or removing it = altogether (which I think is what you advocated below).=

= I would just remove it, as I see no purpose in carrying 3DES = over.

=  

 Regarding encryption padding, the = current draft specifies to use whatever padding is specified by the = encryption algorithm, citing PKCS5 for AES, and not mentioning 3DES-CBC = padding (in practice, our implementation also pads this according to = PKCS5).=

= Why not… = :)

------=_NextPart_001_003E_01CD4A0A.59C8C270-- ------=_NextPart_000_003D_01CD4A0A.59C8C270 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIWHDCCBCcw ggMPoAMCAQICECF2PaKfTBqRTnjJxGi7hjUwDQYJKoZIhvcNAQEFBQAwfzELMAkGA1UEBhMCVVMx DzANBgNVBAoTBkJvZWluZzEUMBIGA1UECxMLY2VydHNlcnZlcnMxETAPBgNVBAsTCG5ldHNjYXBl MTYwNAYDVQQDEy1UaGUgQm9laW5nIENvbXBhbnkgUm9vdCBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkw HhcNMDAwMzE3MDgwMDAwWhcNMjExMjE1MDAxNjIwWjB/MQswCQYDVQQGEwJVUzEPMA0GA1UEChMG Qm9laW5nMRQwEgYDVQQLEwtjZXJ0c2VydmVyczERMA8GA1UECxMIbmV0c2NhcGUxNjA0BgNVBAMT LVRoZSBCb2VpbmcgQ29tcGFueSBSb290IENlcnRpZmljYXRlIEF1dGhvcml0eTCCASIwDQYJKoZI hvcNAQEBBQADggEPADCCAQoCggEBAMQjWT4y7Hftm6Ucjl1iE8kmd3jukPKkWmg2T/STJmRRnl2F JKDYRNc0HmgHbZqb/RUiAlIvWogHb1WbTdFG3aj2mRp8iFsAaTPl0yxq3TrsdWh8FpaKnYzxp2nF R/pZgH/Dj7DFQo8RCW1JghP+bvgDHNvMa0I3FKHxfN9JiEkWO4fGvo96kjIvwXHHW6wZer5r+jwa FhCDs5mhMPe+YFdUOPC4Yf3DHDYUoCLScGfkkvgeeYJHuGpfEEsFRIHCVaC+utfuP9NbVBihNerT N2ZWIjN4rdoQ+kADKgbzuHH5fDohu9ktX4isClvXP1rBxmNGUP7tjdV+ntjSoLDlLu0CAwEAAaOB njCBmzARBglghkgBhvhCAQEEBAMCAAcwDwYDVR0TAQH/BAUwAwEB/zAfBgNVHSMEGDAWgBQ0Yvzg /aYq8ohbBb00yBpxUQaSgTAdBgNVHQ4EFgQUNGL84P2mKvKIWwW9NMgacVEGkoEwEAYJKwYBBAGC NxUBBAMCAQEwIwYJKwYBBAGCNxUCBBYEFNAvWn93Mvxk+0L4K22nnhdsByxbMA0GCSqGSIb3DQEB BQUAA4IBAQChJxOLrU97lJEXLPauW4mXs9qtag/huL1TnRppOWfya14SpSMkV0MP15ACHUw+lpBt bHJu151lX5Diq2zJ+VtzTW+sxm2q+nuduqC9XgIw09CSkrzzIK1AB/3hFKnlg2FD9rc8wT08vkRU NaAp0afJPd1RhKCzrXiLq//lRkfatz10+ByYXumadmpC9mUi8M8vMyvtK6OpxYjN9BREPT/3foO0 BN7zTX1C00zW5qBsiGfqPgZdCqHL35fQgQLwso8fsqJpBxZX8H7+eybmxrkFI7xC1fWrF12TVDB6 IPbq/IVTLKVVDyPPICyWdQINe2dGZNz96hbwxASOO69aAGnoMIIFzzCCBLegAwIBAgIKLLjCQwAC AB7oyTANBgkqhkiG9w0BAQUFADA5MQswCQYDVQQGEwJVUzEPMA0GA1UEChMGQm9laW5nMRkwFwYD VQQDExBTZWN1cmUgTWVzc2FnaW5nMB4XDTEwMDkwMzE3NTk1MFoXDTEyMDkwMjE3NTk1MFowgYkx DzANBgNVBAoTBkJvZWluZzEZMBcGA1UECxMQU2VjdXJlIE1lc3NhZ2luZzEbMBkGA1UEAxMSVGhv bWFzIFIgSGVuZGVyc29uMRAwDgYDVQQDEwcxMDYwOTMyMSwwKgYJKoZIhvcNAQkBFh10aG9tYXMu ci5oZW5kZXJzb25AYm9laW5nLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAyNwF8nZh NHELVvH7g+xTu0KVeIuGjZ5OuRZb/IjHOjL+fczLrROjq4me4oySjnu4mNUhAWxDZOGGEQ7PLhqu /y6jiqRvXteb6mvOUb67lqUvjf7KOkaFiQci8uJ3X29kNuWW5qOroCcQJa+/1+azH/8pvk2DYxV1 Laf2zPnglaMCAwEAAaOCAwowggMGMAsGA1UdDwQEAwIHgDATBgNVHSUEDDAKBggrBgEFBQcDBDAd BgNVHQ4EFgQUmpla5aqhfM3v2RezROSlcobXEqMwHwYDVR0jBBgwFoAUtRjTuxkZKvuKLnMJZU+g 6D4FKNkwggEPBgNVHR8EggEGMIIBAjCB/6CB/KCB+YYwaHR0cDovL2NybC5ib2VpbmcuY29tL2Ny bC9TZWN1cmUlMjBNZXNzYWdpbmcuY3JshoHEbGRhcDovLy9DTj1TZWN1cmUlMjBNZXNzYWdpbmcs Q049UEtJLUJMVkNBLTA1LENOPUNEUCxDTj1QdWJsaWMlMjBLZXklMjBTZXJ2aWNlcyxDTj1TZXJ2 aWNlcyxDTj1Db25maWd1cmF0aW9uLERDPW5vcyxEQz1ib2VpbmcsREM9Y29tP2NlcnRpZmljYXRl UmV2b2NhdGlvbkxpc3Q/YmFzZT9vYmplY3RDbGFzcz1jUkxEaXN0cmlidXRpb25Qb2ludDCCAQgG CCsGAQUFBwEBBIH7MIH4MIG3BggrBgEFBQcwAoaBqmxkYXA6Ly8vQ049U2VjdXJlJTIwTWVzc2Fn aW5nLENOPUFJQSxDTj1QdWJsaWMlMjBLZXklMjBTZXJ2aWNlcyxDTj1TZXJ2aWNlcyxDTj1Db25m aWd1cmF0aW9uLERDPW5vcyxEQz1ib2VpbmcsREM9Y29tP2NBQ2VydGlmaWNhdGU/YmFzZT9vYmpl Y3RDbGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MDwGCCsGAQUFBzAChjBodHRwOi8vY3JsLmJv ZWluZy5jb20vY3JsL1NlY3VyZSUyME1lc3NhZ2luZy5jcnQwPAYJKwYBBAGCNxUHBC8wLQYlKwYB BAGCNxUIgcHFTYKsqS6E+Y8h5qpPlIMAgVeF5fEpgfmOWwIBZAIBAzAbBgkrBgEEAYI3FQoEDjAM MAoGCCsGAQUFBwMEMCgGA1UdEQQhMB+BHXRob21hcy5yLmhlbmRlcnNvbkBib2VpbmcuY29tMA0G CSqGSIb3DQEBBQUAA4IBAQAfBAxTmS1AP8SYSiyiIsfX6JNvYvHDvnDprKSpyz8m/hHp88n0t/+V BmNlYrr3g+8m3xqvm6l8E9mzwayFpSuAGrkhK/S4pVolbRDbMoTdut6TU23GiMa18Gb68lY80hOl 4p+l4KXRmU/5pkJGzb3kCcpVRIfh3Swynat1IbSTHn6JE6uPViT6NMoc6GRCf76rScqE/2BzefIx yot7SDn3A2JilKah89k/Z6969eEygz/R22UFyE7izjZ8JZrHJTg/v9vVV/CdlapTuFezWpt1C/dD mf7NFO+iMttlx34BO3qyPdSYVf0bxqaQ0L/wosrQt/Zi9cVGIozF6QQvDnVwMIIGAzCCBOugAwIB AgIBNDANBgkqhkiG9w0BAQUFADB/MQswCQYDVQQGEwJVUzEPMA0GA1UEChMGQm9laW5nMRQwEgYD VQQLEwtjZXJ0c2VydmVyczERMA8GA1UECxMIbmV0c2NhcGUxNjA0BgNVBAMTLVRoZSBCb2Vpbmcg Q29tcGFueSBSb290IENlcnRpZmljYXRlIEF1dGhvcml0eTAeFw0xMDAxMjExOTI4NTNaFw0xNTAx MjAxOTI4NTNaMDkxCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZCb2VpbmcxGTAXBgNVBAMTEFNlY3Vy ZSBNZXNzYWdpbmcwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDTG6B3BPbUvvMQpHAr tTtiisAJhmOUSTKsSdkjjms2DCZTKj7WZ+7j0xxvGFS2RApB4Ta/IDljTycyn+R+OaOL6Bsi7Rrx ybKCBwMSa9sfRaBoz08dBFxopMtAxwthl7IMk6TKGlljYsmxeo/CmB5uCOXFHMur+TWw7172G2PR zJP1k/JKcFBx0jvoqUOMTB1iHh+YJIonYQONzXtZ/6VnMQDkzk9YwEmOxvpeOs8ZXsV5yzgYYz3T JGiIcCaGoDJzpEeKILxt92/0Tv0gfJoP945E7Nk7bGAq/7XeRG3vxmJeAftxqNidjT9SV4IGvLps Glga5Y2rnYFFh9ia5dRtAgMBAAGjggLOMIICyjARBglghkgBhvhCAQEEBAMCAIcwDgYDVR0PAQH/ BAQDAgHGMB0GA1UdDgQWBBS1GNO7GRkq+4oucwllT6DoPgUo2TAPBgNVHRMBAf8EBTADAQH/MIIC UgYDVR0fBIICSTCCAkUwgeqggeeggeSGgeFsZGFwOi8vL0NOPVRoZSUyMEJvZWluZyUyMENvbXBh bnklMjBSb290JTIwQ2VydGlmaWNhdGUlMjBBdXRob3JpdHksQ049Um9vdCxDTj1DRFAsQ049UHVi bGljJTIwS2V5JTIwU2VydmljZXMsQ049U2VydmljZXMsQ049Q29uZmlndXJhdGlvbixEQz1ub3Ms REM9Ym9laW5nLERDPWNvbT9jZXJ0aWZpY2F0ZVJldm9jYXRpb25MaXN0P2Jhc2U/b2JqZWN0Y2xh c3M9Y1JMRGlzdHJpYnV0aW9uUG9pbnQwgfiggfWggfKGge9sZGFwOi8vZGlyLmJvZWluZy5jb20v Q049VGhlJTIwQm9laW5nJTIwQ29tcGFueSUyMFJvb3QlMjBDZXJ0aWZpY2F0ZSUyMEF1dGhvcml0 eSxDTj1Sb290LENOPUNEUCxDTj1QdWJsaWMlMjBLZXklMjBTZXJ2aWNlcyxDTj1TZXJ2aWNlcyxD Tj1Db25maWd1cmF0aW9uLERDPW5vcyxEQz1ib2VpbmcsREM9Y29tP2NlcnRpZmljYXRlUmV2b2Nh dGlvbkxpc3Q/YmFzZT9vYmplY3RjbGFzcz1jUkxEaXN0cmlidXRpb25Qb2ludDBboFmgV4ZVaHR0 cDovL2NybC5ib2VpbmcuY29tL2NybC9UaGUlMjBCb2VpbmclMjBDb21wYW55JTIwUm9vdCUyMENl cnRpZmljYXRlJTIwQXV0aG9yaXR5LmNybDAfBgNVHSMEGDAWgBQ0Yvzg/aYq8ohbBb00yBpxUQaS gTANBgkqhkiG9w0BAQUFAAOCAQEAIVSm2CNZfPMMgrLQslP5PIRpoWR1sJ8P91xNHTawT/khjZrZ 5by2cLGLcdrQ8uNGQAJurasI/iSEY9e/Pt7HJ6UfsJ2fi3CuwNFkrzIISEU0xylzgaOHnZ9NAR3C Mfu0c8V15Ez7TOtuC7wL+FDSk7Y60qIh9ZdvJhD+1W0sIapjr4cIMdwJNRC5xEppcWk4YWFRgEUB bTPLTMDZz2PRUezg0SofUBQE418ohi+jtN3DLbgSHQt4lbNcb7/uiazNGeXtxpVTEC+VNEEO+RvC +cbEqol7DXcnqcdsGDz0xDSmNiMDnetXZlkJ0FZPtsA24rEOKgM2xJXFr7oQQQoSYTCCBhMwggT7 oAMCAQICCiy4nScAAgAe6MgwDQYJKoZIhvcNAQEFBQAwOTELMAkGA1UEBhMCVVMxDzANBgNVBAoT BkJvZWluZzEZMBcGA1UEAxMQU2VjdXJlIE1lc3NhZ2luZzAeFw0xMDA5MDMxNzU5NDBaFw0xMjA5 MDIxNzU5NDBaMIGJMQ8wDQYDVQQKEwZCb2VpbmcxGTAXBgNVBAsTEFNlY3VyZSBNZXNzYWdpbmcx GzAZBgNVBAMTElRob21hcyBSIEhlbmRlcnNvbjEQMA4GA1UEAxMHMTA2MDkzMjEsMCoGCSqGSIb3 DQEJARYddGhvbWFzLnIuaGVuZGVyc29uQGJvZWluZy5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0A MIGJAoGBALfcKzGLz8oUAEoB9VTfUkMjzKZgczOGfLhNTuNw6iqIhlSRXdp6mA59lBLV+8Wnuzo2 HVI8NDRBbocy/okRLM9niuxyuNAMtHdmdGqCP4ADvkJSNuLpGpBKwLWPeBeGjsZV9xc6YOvqASQB kKEKEzXAN8DeeSmWzNYW/yTwPPlDAgMBAAGjggNOMIIDSjALBgNVHQ8EBAMCBSAwRAYJKoZIhvcN AQkPBDcwNTAOBggqhkiG9w0DAgICAIAwDgYIKoZIhvcNAwQCAgCAMAcGBSsOAwIHMAoGCCqGSIb3 DQMHMB0GA1UdDgQWBBTB06qe5BH3BmjbLKJ3W5IyIZESsjATBgNVHSUEDDAKBggrBgEFBQcDBDAf BgNVHSMEGDAWgBS1GNO7GRkq+4oucwllT6DoPgUo2TCCAQ8GA1UdHwSCAQYwggECMIH/oIH8oIH5 hjBodHRwOi8vY3JsLmJvZWluZy5jb20vY3JsL1NlY3VyZSUyME1lc3NhZ2luZy5jcmyGgcRsZGFw Oi8vL0NOPVNlY3VyZSUyME1lc3NhZ2luZyxDTj1QS0ktQkxWQ0EtMDUsQ049Q0RQLENOPVB1Ymxp YyUyMEtleSUyMFNlcnZpY2VzLENOPVNlcnZpY2VzLENOPUNvbmZpZ3VyYXRpb24sREM9bm9zLERD PWJvZWluZyxEQz1jb20/Y2VydGlmaWNhdGVSZXZvY2F0aW9uTGlzdD9iYXNlP29iamVjdENsYXNz PWNSTERpc3RyaWJ1dGlvblBvaW50MIIBCAYIKwYBBQUHAQEEgfswgfgwgbcGCCsGAQUFBzAChoGq bGRhcDovLy9DTj1TZWN1cmUlMjBNZXNzYWdpbmcsQ049QUlBLENOPVB1YmxpYyUyMEtleSUyMFNl cnZpY2VzLENOPVNlcnZpY2VzLENOPUNvbmZpZ3VyYXRpb24sREM9bm9zLERDPWJvZWluZyxEQz1j b20/Y0FDZXJ0aWZpY2F0ZT9iYXNlP29iamVjdENsYXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkw PAYIKwYBBQUHMAKGMGh0dHA6Ly9jcmwuYm9laW5nLmNvbS9jcmwvU2VjdXJlJTIwTWVzc2FnaW5n LmNydDA6BgkrBgEEAYI3FQcELTArBiMrBgEEAYI3FQiBwcVNgqypLoT5jyHmqk+UgwCBV8GuGv3D HQIBZAIBAzAbBgkrBgEEAYI3FQoEDjAMMAoGCCsGAQUFBwMEMCgGA1UdEQQhMB+BHXRob21hcy5y LmhlbmRlcnNvbkBib2VpbmcuY29tMA0GCSqGSIb3DQEBBQUAA4IBAQDPvLQyBUTANvawdYZ5DH+W c4CbBQuwLmw3KIC8UwOsNrLyKeT8me4D3SgGSmAIX3jpKKso46B3iFVsuXSLSXqdjqT0qFIZFAUH q3c3DHts837sEHmjH4fK3IotkYW6RJ8qh5anERFZRi7rLv/++ga3gtKvxTW6RYK3iBtPUUCfm2/g XNMz9JiNlXQcO5zOp43/YwdBbZtc7XSvqOh+Nt9MEHZUzo3Q5HM0JXA1It0X1b0ex5cGhbaax976 6ZVUbhTncqi7gqGzeJvus3wA45j/NZp5+lqF60m9tZ4b9r1f7NlQlpQ5yUlmosKBg6DpCqSb7MyW VAOUXakfQXtEaD/MMYICujCCArYCAQEwRzA5MQswCQYDVQQGEwJVUzEPMA0GA1UEChMGQm9laW5n MRkwFwYDVQQDExBTZWN1cmUgTWVzc2FnaW5nAgosuMJDAAIAHujJMAkGBSsOAwIaBQCgggHJMBgG CSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDYxNDE1NDczOFowIwYJ KoZIhvcNAQkEMRYEFMtN92ezj21qHIKjmyk4LduD4LvkMFYGCSsGAQQBgjcQBDFJMEcwOTELMAkG A1UEBhMCVVMxDzANBgNVBAoTBkJvZWluZzEZMBcGA1UEAxMQU2VjdXJlIE1lc3NhZ2luZwIKLLid JwACAB7oyDBYBgsqhkiG9w0BCRACCzFJoEcwOTELMAkGA1UEBhMCVVMxDzANBgNVBAoTBkJvZWlu ZzEZMBcGA1UEAxMQU2VjdXJlIE1lc3NhZ2luZwIKLLidJwACAB7oyDCBtwYJKoZIhvcNAQkPMYGp MIGmMAsGCWCGSAFlAwQBKjALBglghkgBZQMEARYwCgYIKoZIhvcNAwcwCwYJYIZIAWUDBAECMA4G CCqGSIb3DQMCAgIAgDAHBgUrDgMCBzANBggqhkiG9w0DAgIBQDANBggqhkiG9w0DAgIBKDAHBgUr DgMCGjALBglghkgBZQMEAgMwCwYJYIZIAWUDBAICMAsGCWCGSAFlAwQCATAKBggqhkiG9w0CBTAN BgkqhkiG9w0BAQEFAASBgERgWL4asMqEXrPWX6/MhSkywqz763IHuWPYsL3OzLQRjBScwXKkohVH 2xkdCA/pGZANFnTfP86KJBkhvM0EH59S8koPjhRQLQ8M7x8lJpUU6Z163fr6QL84D3lzG5EMnTqu sP1Yf/72NaW/H1q4+DC9f+dinroOarWpdivNYgahAAAAAAAA ------=_NextPart_000_003D_01CD4A0A.59C8C270-- From mcgrew@cisco.com Fri Jun 15 09:00:40 2012 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 59B5021F85EE for ; Fri, 15 Jun 2012 09:00:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.399 X-Spam-Level: X-Spam-Status: No, score=-110.399 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gy8XpyOqqAYm for ; Fri, 15 Jun 2012 09:00:39 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 5ECF021F85E1 for ; Fri, 15 Jun 2012 09:00:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mcgrew@cisco.com; l=1160; q=dns/txt; s=iport; t=1339776037; x=1340985637; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=pr+BgHFmAFWBSmpQIrD2FAq+s/Qs7EOb/vW4TD9mWkg=; b=dE4Sp8otMe/WwE7dHV3g5N5wUVhyd2cG7s9VwARYbB6Afw+PhOao1Lvg pIaBegrPTT+adbEqUNu1bJhieyHEVOXWQ+eQuWLzKhPYZBg48QLzG6khK weJNb5TsZ+QNeXNP0H6jZw//993thjE/aaWlhToZ8xPF+InHaI4tq8kxb M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAPJa20+tJV2Z/2dsb2JhbABFtVOBB4IYAQEBAwEBAQEPAVsLBQsLGC4nMBkJGYdkBQuZXaArizaCdoI7YAOVJI4XgWaCfA X-IronPort-AV: E=Sophos;i="4.75,778,1330905600"; d="scan'208";a="92840963" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-7.cisco.com with ESMTP; 15 Jun 2012 16:00:35 +0000 Received: from rtp-vpn4-1070.cisco.com (rtp-vpn4-1070.cisco.com [10.82.212.46]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q5FG0ZTk003287; Fri, 15 Jun 2012 16:00:35 GMT Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=iso-8859-1 From: David McGrew In-Reply-To: <4FD9CA36.3020001@Strombergson.com> Date: Fri, 15 Jun 2012 12:00:34 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <05D7537D-3D2F-4D49-A031-C9813F43160E@cisco.com> References: <1B8956F6-81C5-4921-BA03-4097BE58F471@bbn.com> <255B9BB34FB7D647A506DC292726F6E114F557CCA2@WSMSG3153V.srv.dir.telstra.com> <149B9613-82A9-4D27-934D-A15F854233BE@cisco.com> <4C7FB346-7592-4747-A495-7832B147784F@cisco.com> <4FD9CA36.3020001@Strombergson.com> To: Joachim@Strombergson.com X-Mailer: Apple Mail (2.1278) Cc: cfrg@irtf.org Subject: Re: [Cfrg] draft-mcgrew-aead-aes-cbc-hmac-sha2-00: unsafe to optionally hash A's length X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jun 2012 16:00:40 -0000 Hi Joachim, On Jun 14, 2012, at 7:25 AM, Joachim Str=F6mbergson wrote: > Aloha! >=20 > On 2012-06-13 22:31 , David McGrew wrote: >> I should add that the test cases are all consistent with this change = - they all have MIN_LEN_A =3D 0. >=20 > Would it make sense to add a TC for when MIN_LEN!=3D0? I think it would be best to abandon the option of having a MIN_LEN_A = parameter, use David Wagner's suggestion of dealing with cases in which = interoperability with existing systems is needed by having a separately = defined AEAD algorithm that is not intended for general-purpose use. =20 thanks, David >=20 > Yours > JoachimS >=20 > --=20 > Med v=E4nlig h=E4lsning, Yours >=20 > Joachim Str=F6mbergson - Alltid i harmonisk sv=E4ngning. > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 >=20 >=20 >=20 > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > http://www.irtf.org/mailman/listinfo/cfrg From housley@vigilsec.com Thu Jun 21 06:54:39 2012 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 875F321F866B for ; Thu, 21 Jun 2012 06:54:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.439 X-Spam-Level: X-Spam-Status: No, score=-101.439 tagged_above=-999 required=5 tests=[AWL=-1.060, BAYES_00=-2.599, HTML_MESSAGE=0.001, TVD_SPACE_RATIO=2.219, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vGTnYM87JeAL for ; Thu, 21 Jun 2012 06:54:39 -0700 (PDT) Received: from odin.smetech.net (mail.smetech.net [208.254.26.82]) by ietfa.amsl.com (Postfix) with ESMTP id 0538421F8669 for ; Thu, 21 Jun 2012 06:54:39 -0700 (PDT) Received: from localhost (unknown [208.254.26.81]) by odin.smetech.net (Postfix) with ESMTP id 786E49A472A for ; Thu, 21 Jun 2012 09:54:58 -0400 (EDT) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([208.254.26.82]) by localhost (ronin.smetech.net [208.254.26.81]) (amavisd-new, port 10024) with ESMTP id 1z5gyvBz4kzQ for ; Thu, 21 Jun 2012 09:54:11 -0400 (EDT) Received: from [192.168.2.110] (pool-96-255-37-161.washdc.fios.verizon.net [96.255.37.161]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 628809A4724 for ; Thu, 21 Jun 2012 09:54:54 -0400 (EDT) From: Russ Housley Content-Type: multipart/alternative; boundary=Apple-Mail-8--945063385 Date: Thu, 21 Jun 2012 09:54:32 -0400 Message-Id: To: IRTF CFRG Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [Cfrg] Identity-based 923-bit encryption broken X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jun 2012 13:54:39 -0000 --Apple-Mail-8--945063385 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii h= ttp://news.cnet.com/8301-1009_3-57457470-83/code-crackers-break-923-bit-en= cryption-record/?tag=3Dmncol;cnetRiver =20= --Apple-Mail-8--945063385 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii

http://news.cnet.com/8301-1009_3-57457470-83/code-crackers-break-923-bit-encryption-record/?tag=mncol;cnetRiver

 

--Apple-Mail-8--945063385-- From paul.hoffman@vpnc.org Thu Jun 21 07:59:55 2012 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 2B7D721F8703 for ; Thu, 21 Jun 2012 07:59:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AZOp3Si0PfAV for ; Thu, 21 Jun 2012 07:59:54 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id AB11D21F8649 for ; Thu, 21 Jun 2012 07:59:54 -0700 (PDT) Received: from [10.20.30.101] (50-1-50-97.dsl.dynamic.fusionbroadband.com [50.1.50.97] (may be forged)) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id q5LExqFp061468 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 21 Jun 2012 07:59:53 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: Date: Thu, 21 Jun 2012 07:59:53 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <51ECF220-BFDE-4479-9871-15FF0063134B@vpnc.org> References: To: Russ Housley X-Mailer: Apple Mail (2.1278) Cc: IRTF CFRG Subject: Re: [Cfrg] Identity-based 923-bit encryption broken X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jun 2012 14:59:55 -0000 =46rom the discussion of this topic on one of the cryptography lists, I = think a better subject line would be "Some identity-based ...". Having said that, there is still a dearth of analysis from EC folks on = this paper and the one that preceded it. --Paul Hoffman From mcgrew@cisco.com Thu Jun 21 09:50:04 2012 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 4612121F8617 for ; Thu, 21 Jun 2012 09:50:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.478 X-Spam-Level: X-Spam-Status: No, score=-110.478 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YRxUjnjTX-0x for ; Thu, 21 Jun 2012 09:50:03 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 81E4C21F8610 for ; Thu, 21 Jun 2012 09:50:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mcgrew@cisco.com; l=3707; q=dns/txt; s=iport; t=1340297403; x=1341507003; h=from:mime-version:subject:date:in-reply-to:to:references: message-id; bh=rvUFfyKeStDMLe2x3eHGgYekhoT5Jjl7NOUIeZ5niDA=; b=AsnZTktnijF7av2YTJDrWBiVs2gJPYeFWAgXUYlCXqIO1Oirp6SUWK7y awfGTkqGPJCbTqmaXtDDsn24SXH0GNgrQprf7Di4rR1PMgGL7PW0IWZXl VG3t2JupOOVqTGv/0pfvoDzZTwrUn7FusWhMXxcrEawMSGUmiU1EoFqu1 A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ak8FACdQ40+tJXG9/2dsb2JhbAA8CYJFqikBiGOBB4IZAQEEAQEBDwFbEAsLBEInMAYBEgkRCIdpC5l8oBaLLhGFLGADlSqBEo0JgWaCew X-IronPort-AV: E=Sophos;i="4.77,452,1336348800"; d="scan'208,217";a="94642785" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-7.cisco.com with ESMTP; 21 Jun 2012 16:50:03 +0000 Received: from rtp-mcgrew-8912.cisco.com (rtp-mcgrew-8912.cisco.com [10.117.10.227]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id q5LGo2ab011618; Thu, 21 Jun 2012 16:50:02 GMT From: David McGrew Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/alternative; boundary="Apple-Mail=_A132BA59-09D1-4DFF-91A2-A089A0396036" Date: Thu, 21 Jun 2012 12:50:02 -0400 In-Reply-To: To: Russ Housley , IRTF CFRG References: Message-Id: <3A4AB06F-941F-4394-954D-B27FF4E466F9@cisco.com> X-Mailer: Apple Mail (2.1278) Subject: Re: [Cfrg] Identity-based 923-bit encryption broken X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jun 2012 16:50:04 -0000 --Apple-Mail=_A132BA59-09D1-4DFF-91A2-A089A0396036 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Thanks Russ. For comparison, the IBC recommended parameters are here = I don't see the full report on the official announcement site at = Has anyone seen the full technical report? David On Jun 21, 2012, at 9:54 AM, Russ Housley wrote: > = http://news.cnet.com/8301-1009_3-57457470-83/code-crackers-break-923-bit-e= ncryption-record/?tag=3Dmncol;cnetRiver > =20 > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > http://www.irtf.org/mailman/listinfo/cfrg --Apple-Mail=_A132BA59-09D1-4DFF-91A2-A089A0396036 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii http://tools.ietf.or= g/html/rfc5091#section-9>

I don't see the full = report on the official announcement site at <http://www.fujitsu.com/global/news/pr/archives/month/2012/201206= 18-01.html>   Has anyone seen the full technical = report?

David

On Jun 21, = 2012, at 9:54 AM, Russ Housley wrote:

___________________________________________= ____
Cfrg mailing list
 To: Russ Housley , IRTF CFRG Thread-Topic: [Cfrg] Identity-based 923-bit encryption broken Thread-Index: AQHNT7VqDxxvQmQk30W6ujMY3o83NZcGCOww Date: Fri, 22 Jun 2012 09:05:17 +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: x-originating-ip: [10.109.62.6] Content-Type: multipart/alternative; boundary="_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D1382C8GLKXM0002VGREENLN_" MIME-Version: 1.0 Subject: Re: [Cfrg] Identity-based 923-bit encryption broken X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jun 2012 09:05:32 -0000 --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D1382C8GLKXM0002VGREENLN_ Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Rather misleading headline, as the real key size would be in a component of the domain of the pairing, not the codomain, and there's a factor of 6 (the embedding degree) difference. That makes this equivalent to a 154 bit key. If you apply the NIST guidelines (assuming they apply in the ternary, rather than binary, case that was cracked) that suggest a key size that is double the security level, then that's a security level of 77 bits, which is in line with 80 bit security becoming deprecated. (Apart from the quoting of number of bits that has certainly thrown many commentators, I think that's exactly the message the originators intended, as they comment on establishing strength, not making PBC obsolete - and a good thing too, as people are using it. Many commentators on technology news sites have missed that however. It wasn't a great press release in that regard.) -- Christopher Dearlove Senior Principal Engineer, Communications Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194 | Fax: +44 1245 242124 chris.dearlove@baesystems.com | http://www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 From: cfrg-bounces@irtf.org [mailto:cfrg-bounces@irtf.org] On Behalf Of Russ Housley Sent: 21 June 2012 14:55 To: IRTF CFRG Subject: [Cfrg] Identity-based 923-bit encryption broken *** WARNING *** This message originates from outside our organisation, either from an external partner or the internet. Keep this in mind if you answer this message. Please see this process on how to deal with suspicious emails. http://news.cnet.com/8301-1009_3-57457470-83/code-crackers-break-923-bit-encryption-record/?tag=mncol;cnetRiver ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D1382C8GLKXM0002VGREENLN_ Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit

Rather misleading headline, as the real key size would be in a component of the domain of the pairing, not the codomain, and there's a factor of 6 (the embedding degree) difference. That makes this equivalent to a 154 bit key.  If you apply the NIST guidelines (assuming they apply in the ternary, rather than binary, case that was cracked)  that suggest a key size that is double the security level, then that's a security level of 77 bits, which is in line with 80 bit security becoming deprecated.

 

(Apart from the quoting of number of bits that has certainly thrown many commentators, I think that's exactly the message the originators intended, as they comment on establishing strength, not making PBC obsolete - and a good thing too, as people are using it. Many commentators on technology news sites have missed that however. It wasn't a great press release in that regard.)

 

--

Christopher Dearlove

Senior Principal Engineer, Communications Group
Communications, Networks and Image Analysis Capability
BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 242194 |  Fax: +44 1245 242124

chris.dearlove@baesystems.com | http://www.baesystems.com

BAE Systems (Operations) Limited
Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, Farnborough, Hants, GU14 6YU, UK
Registered in England & Wales No: 1996687

 

From: cfrg-bounces@irtf.org [mailto:cfrg-bounces@irtf.org] On Behalf Of Russ Housley
Sent: 21 June 2012 14:55
To: IRTF CFRG
Subject: [Cfrg] Identity-based 923-bit encryption broken

 

 

*** WARNING ***

This message originates from outside our organisation, either from an external partner or the internet.
Keep this in mind if you answer this message.
Please see this process on how to deal with suspicious emails.

http://news.cnet.com/8301-1009_3-57457470-83/code-crackers-break-923-bit-encryption-record/?tag=mncol;cnetRiver

 


********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************

--_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D1382C8GLKXM0002VGREENLN_-- From smatsuo@nict.go.jp Fri Jun 22 02:43:41 2012 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 3CFF021F8674 for ; Fri, 22 Jun 2012 02:43:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.355 X-Spam-Level: X-Spam-Status: No, score=-1.355 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TAiqQGrxzxDn for ; Fri, 22 Jun 2012 02:43:40 -0700 (PDT) Received: from ns1.nict.go.jp (ns1.nict.go.jp [IPv6:2001:df0:232:300::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A45921F8675 for ; Fri, 22 Jun 2012 02:43:39 -0700 (PDT) Received: from gw1.nict.go.jp (gw1 [133.243.18.250]) by ns1.nict.go.jp with ESMTP id q5M9hcDd005986 for ; Fri, 22 Jun 2012 18:43:38 +0900 (JST) Received: from gw1.nict.go.jp (localhost [127.0.0.1]) by gw1.nict.go.jp with ESMTP id q5M9hcwn023531 for ; Fri, 22 Jun 2012 18:43:38 +0900 (JST) Received: from mail3.nict.go.jp (mail.nict.go.jp [133.243.18.3]) by gw1.nict.go.jp with ESMTP id q5M9hbha023526 for ; Fri, 22 Jun 2012 18:43:37 +0900 (JST) Received: from mail3.nict.go.jp (localhost [127.0.0.1]) by mail3.nict.go.jp (NICT Mail) with ESMTP id B68842C2E0 for ; Fri, 22 Jun 2012 18:43:37 +0900 (JST) Received: from [133.243.119.194] (unknown [133.243.119.194]) by mail3.nict.go.jp (NICT Mail) with ESMTP id B289D2C283 for ; Fri, 22 Jun 2012 18:43:37 +0900 (JST) From: "Shin'ichiro Matsuo" Content-Type: text/plain; charset=iso-2022-jp Content-Transfer-Encoding: quoted-printable Date: Fri, 22 Jun 2012 18:43:36 +0900 Message-Id: <6D037211-1B2E-43D5-AD9D-612311CB3685@nict.go.jp> To: cfrg@irtf.org Mime-Version: 1.0 (Apple Message framework v1278) X-Mailer: Apple Mail (2.1278) Subject: Re: [Cfrg] Identity-based 923-bit encryption broken X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jun 2012 09:43:41 -0000 This result is solving discrete logarithm problem (DLP) on GF(3^6n) = where n=3D97. This result is applicable for ETA T pairing on GH(3^n) where n=3D97. It is specific result for that paring, and it is not general result for = pairing based cryptography including identity-based cryptography. The full paper will be disclosed from IACR e-Print in the near future. Regards, Shin'ichiro Matsuo > Message: 3 > Date: Thu, 21 Jun 2012 12:50:02 -0400 > From: David McGrew > To: Russ Housley , IRTF CFRG > Subject: Re: [Cfrg] Identity-based 923-bit encryption broken > Message-ID: <3A4AB06F-941F-4394-954D-B27FF4E466F9@cisco.com> > Content-Type: text/plain; charset=3D"us-ascii" >=20 > Thanks Russ. >=20 > For comparison, the IBC recommended parameters are here = >=20 > I don't see the full report on the official announcement site at = Has anyone seen the full technical report? >=20 > David From smatsuo@nict.go.jp Fri Jun 22 22:22:40 2012 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 632DB21F8575 for ; Fri, 22 Jun 2012 22:22:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.055 X-Spam-Level: X-Spam-Status: No, score=-1.055 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_EQ_JP=1.244, J_CHICKENPOX_46=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V7sAi-WdE-b0 for ; Fri, 22 Jun 2012 22:22:36 -0700 (PDT) Received: from ns1.nict.go.jp (ns1.nict.go.jp [IPv6:2001:df0:232:300::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EAE521F8530 for ; Fri, 22 Jun 2012 22:22:35 -0700 (PDT) Received: from gw1.nict.go.jp (gw1 [133.243.18.250]) by ns1.nict.go.jp with ESMTP id q5N5MWK5000750 for ; Sat, 23 Jun 2012 14:22:32 +0900 (JST) Received: from gw1.nict.go.jp (localhost [127.0.0.1]) by gw1.nict.go.jp with ESMTP id q5N5MW17011195 for ; Sat, 23 Jun 2012 14:22:32 +0900 (JST) Received: from [IPv6:::1] (ssh2.nict.go.jp [133.243.3.50]) by gw1.nict.go.jp with ESMTP id q5N5MWOk011192; Sat, 23 Jun 2012 14:22:32 +0900 (JST) From: "Matsuo Shin'ichiro" Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Sat, 23 Jun 2012 14:22:31 +0900 Message-Id: To: cfrg@irtf.org Mime-Version: 1.0 (Apple Message framework v1278) X-Mailer: Apple Mail (2.1278) Subject: Re: [Cfrg] Identity-based 923-bit encryption broken X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Jun 2012 05:22:40 -0000 The paper is now disclosed at IACR e-Print Archive. http://eprint.iacr.org/2012/345 Shin'ichiro > This result is solving discrete logarithm problem (DLP) on GF(3^6n) = where n=3D97. > This result is applicable for ETA T pairing on GH(3^n) where n=3D97. >=20 > It is specific result for that paring, and it is not general result = for pairing based cryptography including identity-based cryptography. >=20 > The full paper will be disclosed from IACR e-Print in the near future. >=20 > Regards, >=20 > Shin'ichiro Matsuo