Re: [Cfrg] considering new topics for CFRG
Dan Brown <dbrown@certicom.com> Wed, 08 January 2014 17:32 UTC
Return-Path: <dbrown@certicom.com>
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E8B51AE063 for <cfrg@ietfa.amsl.com>; Wed, 8 Jan 2014 09:32:47 -0800 (PST)
X-Quarantine-ID: <pXkoBvNaDSTd>
X-Virus-Scanned: amavisd-new at amsl.com
X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "MIME-Version"
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pXkoBvNaDSTd for <cfrg@ietfa.amsl.com>; Wed, 8 Jan 2014 09:32:44 -0800 (PST)
Received: from smtp-p01.blackberry.com (smtp-p01.blackberry.com [208.65.78.88]) by ietfa.amsl.com (Postfix) with ESMTP id 7B59A1ADFF8 for <cfrg@irtf.org>; Wed, 8 Jan 2014 09:32:44 -0800 (PST)
Content-Type: multipart/mixed; boundary="===============2014767363=="
MIME-Version: 1.0
Received: from xct108cnc.rim.net ([10.65.161.208]) by mhs210cnc.rim.net with ESMTP/TLS/AES128-SHA; 08 Jan 2014 12:32:30 -0500
Received: from XMB116CNC.rim.net ([fe80::45d:f4fe:6277:5d1b]) by XCT108CNC.rim.net ([fe80::8dc1:9551:6ed8:c618%17]) with mapi id 14.03.0158.001; Wed, 8 Jan 2014 12:32:29 -0500
From: Dan Brown <dbrown@certicom.com>
To: "'TurnerS@ieca.com'" <TurnerS@ieca.com>, "'mcgrew@cisco.com'" <mcgrew@cisco.com>, "'cfrg@irtf.org'" <cfrg@irtf.org>
Thread-Topic: [Cfrg] considering new topics for CFRG
Thread-Index: AQHPCOZ5+Ps+p+/cFU6uojPzahL32Zp6pkWAgABbH6A=
Date: Wed, 08 Jan 2014 17:32:29 +0000
Message-ID: <810C31990B57ED40B2062BA10D43FBF5C1BF54@XMB116CNC.rim.net>
References: <52C755AA.70200@cisco.com> <33E0BF53-A331-4646-B080-FD4F6E13916E@ieca.com>
In-Reply-To: <33E0BF53-A331-4646-B080-FD4F6E13916E@ieca.com>
Accept-Language: en-CA, en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-originating-ip: [10.65.160.249]
MIME-Version: 1.0
Subject: Re: [Cfrg] considering new topics for CFRG
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Crypto Forum Research Group <cfrg.irtf.org>
List-Unsubscribe: <http://www.irtf.org/mailman/options/cfrg>, <mailto:cfrg-request@irtf.org?subject=unsubscribe>
List-Archive: <http://www.irtf.org/mail-archive/web/cfrg/>
List-Post: <mailto:cfrg@irtf.org>
List-Help: <mailto:cfrg-request@irtf.org?subject=help>
List-Subscribe: <http://www.irtf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Wed, 08 Jan 2014 17:32:47 -0000
> -----Original Message----- > From: Sean Turner > Sent: Wednesday, January 08, 2014 12:26 AM > > 0) Could the CFRG get behind these recommendations for RSA-OAEP/PSS or not: > http://www.ietf.org/mail-archive/web/saag/current/msg04481.html > http://www.ietf.org/mail-archive/web/saag/current/msg04482.html > Maybe CFRG should compare RSA-KEM to RSA-OAEP? Is there a signature analogue to RSA-KEM? KEM is ISO 18033-2, but not in PKCS#1 (last I checked, which was long ago). RSA-KEM looks cleaner and simpler, at least to me, though is perhaps less efficient? Since some in CFRG are interested in provable security, how do these two compare on that front? Especially, in the standard model? A while back several people (including) me found some theoretical impossibility results against security proofs about RSA-OAEP and RSA-PSS in the standard model, but since then I have mostly forgotten about that topic. These results mostly concerned IND-CCA2 security. I forget if these results apply to RSA-KEM. I vaguely recall some positive research results. > > 1) Assuming RSA goes kaput, it seems like we're moving towards EC (am I wrong > here) then are these EC-based documents worth saying more about (e.g., in the > next version of the protocol use this or run away in fear): > https://datatracker.ietf.org/doc/rfc6979/ Seems good. In my own security analyses, one of the security arguments for ECDSA needed the ephemeral keys to be message-constant to make the ROM work. Maybe that was just a deficiency in my proof techniques. I haven't reviewed the specific algorithm in 6979, but I would be inclined to give a slight edge to deterministic algs for ECDSA ephemeral keys. > https://datatracker.ietf.org/doc/draft-peck-ecdhpop/ Seems good. I had no idea the existing IETF POP excluded using ECDSA signatures for ECDH keys. > https://datatracker.ietf.org/doc/draft-jivsov-ecc-compact/ I don't see a security problem. Indeed, SEC1 permits similar filtering in the key generation algorithm to facilitate accelerated verification of ECDSA signatures. The SEC1 encoding is really meant to be inserted wherever a definite octet string is needed, mainly in ASN.1. I believe the header byte was meant to serve a dual tag-length role (that provided what was missing from the curve id). Maybe this I-D could propose something more specific to ASN.1. I wonder if this compact representation might conflict with other proposals, in that it becomes an untagged integer. > > 2) Is QKD something we need to start considering: > http://tools.ietf.org/id/draft-nagayama-ipsecme-ipsec-with-qkd-00.txt > http://tools.ietf.org/id/draft-ghernaouti-sfaxi-ppp-qkd-00.txt I am more interested in the issue of whether quantum computing (for Shor's algorithm) will, or even has, become feasible? I am not an expert in the area, but am interested. Of course, we can just go ahead and get prepared with proposals for postquantum algs. That's great to do, but still doesn't address the question. I expect some may argue that asking this whole question just begs pointless speculation, on the grounds that if your adversary (soon) has a QC, then you should have spent your time switching to PQ rather than thinking about whether the adversary had a QC. In other words, I'm expecting some may say that consideration of postquantum crypto is perfectly reasonable, but asking about the existence of a quantum computer is pointless. But I think it is okay for CFRG to consider it, and, nay, even try to boldly quantify these, say with likelihood 2^(-64) of some well-defined claim, calculated via a series of estimates. The status quo is to just claim that algorithm X with key size provides 128 bit security, whatever that means, perhaps adding the exclusion against quantum computers. Adding an estimated likelihood of a quantum computer gives a more meaning of what kind of security is being claimed. Maybe the postquantum researchers already have made such an estimate, as part of an effort to justify a switch to postquantum. I would understand if the CFRG chairs deem this out of scope for CFRG. If so, I hope that somebody could suggest to me off-list an alternative forum. An informal, perhaps dubious, argument that comes to my mind is the following. The most likely party to have a quantum computer is a large nation. If they had such a thing, then they could break almost all IETF crypto, except pre-shared key based stuff, and wouldn't have to resort to any other chicanery. But reports are now suggesting the latter. Well, the chicanery could all be just a cover-up ruse. Or more realistically, maybe the quantum computer is kept on reserve, and more mundane cryptanalysis is used on a daily basis, maybe because it is cheaper. Still, why not just lay little lower, if a QC is available? Anyway, the loose inference I'm drawing is that a quantum computer does not yet exist, and further that the most likely parties to have one do not anticipate being able to have one in the near future. Well, this argument does not give any kind of quantified likelihood. If I had to dead-reckon a likelihood, I'd make a wildly different number every time, but most of them would be above 2^(-128), unfortunately. I wonder if others have more substantial arguments.
--------------------------------------------------------------------- This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client 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 immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.
- Re: [Cfrg] considering new topics for CFRG David McGrew
- Re: [Cfrg] considering new topics for CFRG David McGrew
- Re: [Cfrg] considering new topics for CFRG Trevor Perrin
- [Cfrg] considering new topics for CFRG David McGrew
- Re: [Cfrg] considering new topics for CFRG Sean Turner
- Re: [Cfrg] considering new topics for CFRG Henrick Hellström
- Re: [Cfrg] considering new topics for CFRG David Wagner
- Re: [Cfrg] considering new topics for CFRG Henrick Hellström
- Re: [Cfrg] considering new topics for CFRG Henrick Hellström
- Re: [Cfrg] considering new topics for CFRG Paul Lambert
- Re: [Cfrg] considering new topics for CFRG David McGrew
- Re: [Cfrg] considering new topics for CFRG Paul Lambert
- Re: [Cfrg] considering new topics for CFRG Stephen Farrell
- Re: [Cfrg] considering new topics for CFRG William Whyte
- Re: [Cfrg] considering new topics for CFRG Stephen Farrell
- Re: [Cfrg] considering new topics for CFRG Watson Ladd
- Re: [Cfrg] considering new topics for CFRG Paul Lambert
- Re: [Cfrg] considering new topics for CFRG Dan Brown
- Re: [Cfrg] considering new topics for CFRG Blumenthal, Uri - 0558 - MITLL
- Re: [Cfrg] considering new topics for CFRG Paul Lambert
- Re: [Cfrg] considering new topics for CFRG William Whyte
- Re: [Cfrg] considering new topics for CFRG Max Pritikin (pritikin)
- Re: [Cfrg] considering new topics for CFRG Watson Ladd
- Re: [Cfrg] considering new topics for CFRG Sean Turner
- Re: [Cfrg] considering new topics for CFRG Sean Turner
- Re: [Cfrg] considering new topics for CFRG Adam Back
- [Cfrg] QKD is pointless (was: Re: considering new… David McGrew
- Re: [Cfrg] considering new topics for CFRG Stephen Farrell
- Re: [Cfrg] QKD is pointless (was: Re: considering… Paterson, Kenny
- Re: [Cfrg] QKD is pointless (was: Re: considering… Sean Turner
- Re: [Cfrg] considering new topics for CFRG Sean Turner
- Re: [Cfrg] considering new topics for CFRG Max Pritikin (pritikin)
- Re: [Cfrg] considering new topics for CFRG Dan Brown
- Re: [Cfrg] considering new topics for CFRG Paul Lambert
- Re: [Cfrg] QKD is pointless (was: Re: considering… Igoe, Kevin M.
- Re: [Cfrg] QKD is pointless (was: Re: considering… Igoe, Kevin M.
- Re: [Cfrg] QKD is pointless (was: Re: considering… Watson Ladd
- [Cfrg] DANE in the IETF (was: Re: considering new… Paul Hoffman
- [Cfrg] One Key -> RE: considering new topics for … Paul Lambert
- Re: [Cfrg] QKD is pointless (was: Re: considering… Paul Lambert
- [Cfrg] ReL DANE in the IETF (was: Re: considering… Paul Hoffman
- Re: [Cfrg] QKD is pointless David McGrew
- Re: [Cfrg] QKD is pointless Hilarie Orman
- [Cfrg] likelihood that someone has a quantum comp… David McGrew
- Re: [Cfrg] considering new topics for CFRG dan
- Re: [Cfrg] likelihood that someone has a quantum … David Jacobson
- Re: [Cfrg] likelihood that someone has a quantum … William Whyte
- Re: [Cfrg] likelihood that someone has a quantum … Watson Ladd
- Re: [Cfrg] likelihood that someone has a quantum … Yoav Nir
- Re: [Cfrg] likelihood that someone has a quantum … Stephen Farrell
- Re: [Cfrg] likelihood that someone has a quantum … William Whyte
- Re: [Cfrg] likelihood that someone has a quantum … David McGrew
- Re: [Cfrg] likelihood that someone has a quantum … David McGrew
- Re: [Cfrg] likelihood that someone has a quantum … William Whyte
- Re: [Cfrg] likelihood that someone has a quantum … arne renkema-padmos
- Re: [Cfrg] likelihood that someone has a quantum … Igoe, Kevin M.
- Re: [Cfrg] QKD is pointless David Wagner
- Re: [Cfrg] likelihood that someone has a quantum … William Whyte
- Re: [Cfrg] likelihood that someone has a quantum … William Whyte
- Re: [Cfrg] likelihood that someone has a quantum … William Whyte
- Re: [Cfrg] likelihood that someone has a quantum … David McGrew
- Re: [Cfrg] likelihood that someone has a quantum … arne renkema-padmos
- Re: [Cfrg] considering new topics for CFRG Paul Lambert
- Re: [Cfrg] considering new topics for CFRG Igoe, Kevin M.
- Re: [Cfrg] considering new topics for CFRG Paul Lambert
- Re: [Cfrg] considering new topics for CFRG David McGrew
- [Cfrg] 'key centric' architecture (was: Re: consi… Rene Struik
- Re: [Cfrg] 'key centric' architecture (was: Re: c… Richard Barnes
- Re: [Cfrg] considering new topics for CFRG David McGrew