From mailnull@www1.ietf.org Fri Apr 4 19:42:01 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15272 for ; Fri, 4 Apr 2003 19:42:01 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h350j1j04995 for cfrg-archive@odin.ietf.org; Fri, 4 Apr 2003 19:45:01 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h350j1804990 for ; Fri, 4 Apr 2003 19:45:01 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15269 for ; Fri, 4 Apr 2003 19:41:29 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h350h3804878; Fri, 4 Apr 2003 19:43:03 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h350fm804833 for ; Fri, 4 Apr 2003 19:41:48 -0500 Received: from pacific-carrier-annex.mit.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15246 for ; Fri, 4 Apr 2003 19:38:16 -0500 (EST) Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by pacific-carrier-annex.mit.edu (8.12.4/8.9.2) with ESMTP id h350ekwJ020634 for ; Fri, 4 Apr 2003 19:40:47 -0500 (EST) Received: from manawatu-mail-centre.mit.edu (MANAWATU-MAIL-CENTRE.MIT.EDU [18.7.7.71]) by grand-central-station.mit.edu (8.12.4/8.9.2) with ESMTP id h350cZWb015814; Fri, 4 Apr 2003 19:38:35 -0500 (EST) Received: from all-in-one.mit.edu (ALL-IN-ONE.MIT.EDU [18.18.1.71]) ) by manawatu-mail-centre.mit.edu (8.12.4/8.12.4) with ESMTP id h350cZFJ029779; Fri, 4 Apr 2003 19:38:35 -0500 (EST) Received: (from raeburn@localhost) by all-in-one.mit.edu (8.9.3) id TAA30112; Fri, 4 Apr 2003 19:38:34 -0500 To: cfrg@ietf.org From: Ken Raeburn Date: Fri, 04 Apr 2003 19:38:34 -0500 Message-ID: Lines: 40 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [Cfrg] Kerberos crypto framework Sender: cfrg-admin@ietf.org Errors-To: cfrg-admin@ietf.org X-BeenThere: cfrg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Crypto Forum Research Group List-Post: List-Help: List-Subscribe: , The Kerberos working group (ietf-krb-wg@anl.gov) has two drafts we're finishing up that could use some review by people with real crypto backgrounds, unlike some of us total amateurs who are working on the drafts. We'd appreciate any comments people may have. These documents attempt to: - describe an "interface" for cryptographic functionality for use in Kerberos and related protocols and extensions, with what we hope will be all the operations we need - describe a profile system for additional encryption systems (e.g., Microsoft's RC4, or PacketCable's version of 3DES) - specify profiles for some existing encryption systems used by Kerberos (DES and 3DES), and some known problems with them - specify a profile for using AES in Kerberos The first document http://www.mit.edu/~raeburn/draft-ietf-krb-wg-crypto-04.txt covers the first three points, and should go to WG last call as soon as it gets published in the I-D area. The somewhat arbitrary crypto specifications were pulled out of various versions of the Kerberos protocol specification into a separate specification, and a somewhat generalized framework added at that time. We actually specify two types of profiles for encryption systems, a low-level more detailed one, and a simplified one needing fewer parameters specified, with a process for deriving the more detailed one from it. The DES and 3DES mechanisms are defined for compabitibility with existing implementations. The second document, draft-raeburn-krb-rijndael-krb-03.txt, in WG last call now, gives a profile for plugging AES into the framework specified in the first document, and stands as an example of how to define a new encryption system for Kerberos. AES support will be required for version 5.2 of the Kerberos protocol (also in WG last call). We're hoping to finish up the working group last call and move on to IETF-wide last call soon. Any comments people have would be welcome. Ken _______________________________________________ Cfrg mailing list Cfrg@ietf.org https://www1.ietf.org/mailman/listinfo/cfrg From mailnull@www1.ietf.org Thu Apr 10 00:57:03 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA26164 for ; Thu, 10 Apr 2003 00:57:03 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3A52Za27484 for cfrg-archive@odin.ietf.org; Thu, 10 Apr 2003 01:02:35 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3A52Z827481 for ; Thu, 10 Apr 2003 01:02:35 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA26154 for ; Thu, 10 Apr 2003 00:56:32 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3A4t0827204; Thu, 10 Apr 2003 00:55:00 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3A4r4827125 for ; Thu, 10 Apr 2003 00:53:04 -0400 Received: from igw2.watson.ibm.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA26057 for ; Thu, 10 Apr 2003 00:47:01 -0400 (EDT) Received: from sp1n293en1.watson.ibm.com (sp1n293en1.watson.ibm.com [9.2.112.57]) by igw2.watson.ibm.com (8.11.7/8.11.4) with ESMTP id h3A4nZQ112382 for ; Thu, 10 Apr 2003 00:49:35 -0400 Received: from ornavella.watson.ibm.com (ornavella.watson.ibm.com [9.2.16.80]) by sp1n293en1.watson.ibm.com (8.11.6/8.11.4) with ESMTP id h3A4nZl55674 for ; Thu, 10 Apr 2003 00:49:35 -0400 Received: (from canetti@localhost) by ornavella.watson.ibm.com (AIX4.3/8.9.3/8.9.3/09-18-2002) id AAA37132 for cfrg@ietf.org; Thu, 10 Apr 2003 00:49:35 -0400 Date: Thu, 10 Apr 2003 00:49:35 -0400 From: Ran Canetti Message-Id: <200304100449.AAA37132@ornavella.watson.ibm.com> To: cfrg@ietf.org Subject: Re: [Cfrg] AES-based PRF - comment please Sender: cfrg-admin@ietf.org Errors-To: cfrg-admin@ietf.org X-BeenThere: cfrg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Crypto Forum Research Group List-Post: List-Help: List-Subscribe: , - A few belated remarks on this thread. (Sorry for not being able to respond in a more on-line fashion.) Let me first recap the discussion as I understand it. The overall question is how to construct a good key-derivation function for key-exchange protocols, and for Diffie-Hellman based protocols in particular. There were three main topics: 1. How to deal with the case where the "rough keying material" we start with is not guaranteed to be "pseudorandom" - ie, not completely secret or not uniformly distributed. 2. How to deal with the case where the "rough keying material" we start with is of variable length. 3. How to obtain a variable-length output. I believe topic 3 is pretty well understood, once we have a pseudorandom key; there are several ways to do it, with known tradeoffs, and with good analysis that provides concrete and quantitative security bounds. (Some of these ways were suggested in this thread.) Topic 2 is also well understood - at least for the case where the keying material we start with is pseudorandom and is of sufficient length. In this case, we simply use as many bits of the key as are necessary to key the cyptographic function we're working with. Unused key bits can be prepended to the "non-secret" input of the underlying cryptographic function - this may help reduce the assumptions on that function. If the keying material is too short then we're back to topic 1. Topic 1 is much more of an unstable ground - and the focus of the rest of this note. First, at the risk of being redundant, let me recap what is usually meant by a "pseudorandom keying material": Roughly speaking, the keying material to the key derivation function is said to be "pseudorandom" if no adversary that (uses a given amount of computational resources and) is given all the publicly available information can win in the following game with probability that is non-negligibly more than one half. In the game, the adversary is given either the real keying material (with probability one half) or an independently and uniformly chosen string of the same length. It wins if it guesses correctly which is the case. (Ofcourse, this qualitative definition can be made quantitative, relating the actual success probability to the resources used by the adversary.) For sake of presentation let me concentrate on DH-based key exchange. Here the keying material is g^xy and the adversary knows g^x,g^y. So, if the DDH assumption holds (ie, if g^xy is pseudorandom given g^x,g^y) then we're golden. But what if not? (This is the "belt and suspenders" question. Great term.) Ofcourse, if DH is completely broken and g^xy is completely computable from g^x,g^y then nothing can be done. But what if we're in an "in-between" situation, where g^xy canot be completely computed, but it is possible to distinguish it from random, either by predicting some of the bits based on the public info, or in other ways? How can we "extract" a pseudorandom key from g^xy? As a side remark, let me first say that, at least in principle, the problem is solved: The theory of cryptography offers a number of generic ways to extract pseudorandom bits from g^xy, based only on the minimal assumption that g^xy cannot be completely computed given g^x,g^y. But these methods are highly inefficient. In particular, we'd be able to extract only very few bits from each DH exchange - or in other words we'd need several DH exchanges to get a sizable key. (I'm referring here to the standard constructions of pseudorandom generators based on any one-way function.) So the question is how to do it in a more reasonable way from an efficiency point of view. In other words we're looking for a way to use some readily avaliable cryptographic function (say SHA, AES etc) in order to extract a significant number of bits from g^xy, so that these bits will be pseudorandom based on minimal assumptions on the DH problem and on the underlying cryptographic function. I dont have a good, well analyzed proposal here. I think this is a good research topic. Ran A couple more remarks: 1. A cryptographic primitive that is closely related to what we need is "exposure resilient function (ERF)". These are functions whose output is pseudorandom even if part of the input is known. Some initial and theoretical study of such functionas was done in [1]. Unfortunately, I didnt see an immediate way to use the techniques from there in our case. [1] R. Canetti, Y. Dodis, S. Halevi, E. Kushilevitz, A. Sahai, ``Exposure-Resilient Functions and All-or-Nothing Transforms,'' Eurocrypt, 2000. 2. Regarding random oracles. It was suggested to model the underlying cryptographic function (SHA, AES, etc.) as a random oracle and analyze the security of the construction using the random oracle methodology (David gave a great description of this methodology - it ought to be quoted in some textbook). But I dont think that such a modeling will be helpful in our context. One issue is ofourse the inherent unsoundness of this methodology, as was already discussed on this thread. But there is a much more immediate issue. Recall that we're trying to find a construction that would make only minimal assumption on the underlying functions. But if we model these functions as random oracles then almost any construction would be labeled "secure" - good ones as well as less good ones. In other words, this modeling is so "coarse grained" that it doesnt allow investigating what we are interested in (minimizing assumptions). It is a bit like using a 10 pounds axe to trim fingernails... [Something somewhat similar happens in the case of hash-based MACs. If we model the hash function as a random oracle then many different ways of keying the underlying hash function result in equally secure MACs. But constructions do differ a lot in the assumption they make on the underlying hash function. In particular, HMAC tries to minimize those assumptions, and I believe that this is at least partly why it was chosen over other constructions.] _______________________________________________ Cfrg mailing list Cfrg@ietf.org https://www1.ietf.org/mailman/listinfo/cfrg From mailnull@www1.ietf.org Thu Apr 10 01:12:32 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA26404 for ; Thu, 10 Apr 2003 01:12:32 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3A5I4X28961 for cfrg-archive@odin.ietf.org; Thu, 10 Apr 2003 01:18:04 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3A5I3828958 for ; Thu, 10 Apr 2003 01:18:03 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA26401 for ; Thu, 10 Apr 2003 01:12:00 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3A5B2828718; Thu, 10 Apr 2003 01:11:02 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3A5Ag828692 for ; Thu, 10 Apr 2003 01:10:42 -0400 Received: from igw2.watson.ibm.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA26303 for ; Thu, 10 Apr 2003 01:04:39 -0400 (EDT) Received: from sp1n293en1.watson.ibm.com (sp1n293en1.watson.ibm.com [9.2.112.57]) by igw2.watson.ibm.com (8.11.7/8.11.4) with ESMTP id h3A57DQ237432; Thu, 10 Apr 2003 01:07:13 -0400 Received: from ornavella.watson.ibm.com (ornavella.watson.ibm.com [9.2.16.80]) by sp1n293en1.watson.ibm.com (8.11.6/8.11.4) with ESMTP id h3A57Dl95394; Thu, 10 Apr 2003 01:07:13 -0400 Received: (from canetti@localhost) by ornavella.watson.ibm.com (AIX4.3/8.9.3/8.9.3/09-18-2002) id BAA37648; Thu, 10 Apr 2003 01:07:13 -0400 Date: Thu, 10 Apr 2003 01:07:13 -0400 From: Ran Canetti Message-Id: <200304100507.BAA37648@ornavella.watson.ibm.com> To: daw@mozart.cs.berkeley.edu, uri@bell-labs.com Subject: Re: [Cfrg] AES-based PRF - comment please Cc: cfrg@ietf.org, mcgrew@cisco.com, sfluhrer@cisco.com Sender: cfrg-admin@ietf.org Errors-To: cfrg-admin@ietf.org X-BeenThere: cfrg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Crypto Forum Research Group List-Post: List-Help: List-Subscribe: , Uri, > From: Uri Blumenthal > > ... > > > Of course for sufficiently large k, this is effectively the same thing as > > "all bets are off". For k < 8, say, it is probably harmless. Anyway, this > > argument does not in any way justify using non-secret or non-random keys, > > unless you know that they are only "slightly" non-random. > > In pratice - but not in theory, right? Because the theory deals with > the degradation - which is quantifiable? So if only 8 out of 128 key > bits are random - it still means degradation by 2^120, not "all bets > are off"? > > Thanks! > > Regards, > Uri. Wouldnt it be great if life were that easy... In an ideal world, with ideal ciphers, you would be 100% correct. Each non-random bit of the key reduces the work of the attacker by exactly a half, no more, no less. Problem is that we're not dealing with ideal ciphers, and we don't know for sure what is the actual strength of AES (or any other block cipher for that matter). In particular we only assume that it is "secure" for uniform keys. So it may well be, in principle, that if you fix the first, say, 64 bits of the key to some value (say all zeroes) then AES becomes breakable in much less than 2^64 operations. This would not contradict the security of AES with totally uniform keys. (You would have a bad event occuring with probability 1/2^64, but as long as this event does not happen AES remains "fully secure".) Maybe this happens, maybe it doesnt. We dont know. So I think it's best to stick to what we can prove based on the requirements for which AES was designed (ie, to be an invertible PRP). Ran _______________________________________________ Cfrg mailing list Cfrg@ietf.org https://www1.ietf.org/mailman/listinfo/cfrg From mailnull@www1.ietf.org Thu Apr 10 01:14:39 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA26450 for ; Thu, 10 Apr 2003 01:14:39 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3A5KBA29062 for cfrg-archive@odin.ietf.org; Thu, 10 Apr 2003 01:20:11 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3A5KB829059 for ; Thu, 10 Apr 2003 01:20:11 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA26444 for ; Thu, 10 Apr 2003 01:14:08 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3A5A2828651; Thu, 10 Apr 2003 01:10:02 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3A59M828618 for ; Thu, 10 Apr 2003 01:09:22 -0400 Received: from igw2.watson.ibm.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA26270 for ; Thu, 10 Apr 2003 01:03:19 -0400 (EDT) Received: from sp1n293en1.watson.ibm.com (sp1n293en1.watson.ibm.com [9.2.112.57]) by igw2.watson.ibm.com (8.11.7/8.11.4) with ESMTP id h3A55rQ172846; Thu, 10 Apr 2003 01:05:53 -0400 Received: from ornavella.watson.ibm.com (ornavella.watson.ibm.com [9.2.16.80]) by sp1n293en1.watson.ibm.com (8.11.6/8.11.4) with ESMTP id h3A55rl75486; Thu, 10 Apr 2003 01:05:53 -0400 Received: (from canetti@localhost) by ornavella.watson.ibm.com (AIX4.3/8.9.3/8.9.3/09-18-2002) id BAA27524; Thu, 10 Apr 2003 01:05:53 -0400 Date: Thu, 10 Apr 2003 01:05:53 -0400 From: Ran Canetti Message-Id: <200304100505.BAA27524@ornavella.watson.ibm.com> To: cfrg@ietf.org, moeller@cdc.informatik.tu-darmstadt.de Subject: Re: [Cfrg] reductions vs. random-oracles Sender: cfrg-admin@ietf.org Errors-To: cfrg-admin@ietf.org X-BeenThere: cfrg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Crypto Forum Research Group List-Post: List-Help: List-Subscribe: , Bodo, > From: Bodo Moeller > > On Thu, Mar 27, 2003 at 12:33:49PM -0500, Shai Halevi wrote: > > On Thursday 27 March 2003 13:58:43 +0100, Bodo Moeller wrote: > > >> It should be noted that all such counterexamples make statements about > >> *asymptotic* security: they assume that a fixed description of the > >> hash function is used across all security parameters and exploit > >> anomalies in this setting. > > > That's just not true. These examples have nothing to do with "asymptotic" > > vs. "concrete" security. > > The asymptotic aspect in your paper lies in enumerating "efficiently > computable" function ensembles. Sloppily said, the examples assume > that function descriptions are shorter than the complete > function table of a random oracle: polynomial size compared with > exponential size. This certainly makes a lot of sense, but it's > inherently asymptotic. Good to see someone actually reads those proofs. But I agree with Shai that the asymptotics here are, as usual, only used for convenience of exposition and are not essential. Using the standard modeling of SHA1 as a function family that is keyed via the 160-bit IV, the [CGH] result can be interpreted as saying the following: There exist signature schemes that are secure in the RO model, and are able to sign at least 160 bits, and such that any instantiation of the RO using a function family whose key length is at most 160 bits causes the scheme to be (completely) insecure. Ran _______________________________________________ Cfrg mailing list Cfrg@ietf.org https://www1.ietf.org/mailman/listinfo/cfrg From mailnull@www1.ietf.org Thu Apr 10 01:16:00 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA26507 for ; Thu, 10 Apr 2003 01:16:00 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3A5LWv29126 for cfrg-archive@odin.ietf.org; Thu, 10 Apr 2003 01:21:32 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3A5LW829123 for ; Thu, 10 Apr 2003 01:21:32 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA26479 for ; Thu, 10 Apr 2003 01:15:29 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3A5E1828829; Thu, 10 Apr 2003 01:14:01 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3A5Dp828812 for ; Thu, 10 Apr 2003 01:13:51 -0400 Received: from mail.zork.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA26332 for ; Thu, 10 Apr 2003 01:07:48 -0400 (EDT) Received: from list.org (pcp732336pcs.arlngt01.va.comcast.net [68.49.161.231]) by mail.zork.org (Postfix) with ESMTP id 81EE054C9; Thu, 10 Apr 2003 01:15:51 -0400 (EDT) Date: Thu, 10 Apr 2003 01:10:19 -0400 Subject: Re: [Cfrg] AES-based PRF - comment please Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: cfrg@ietf.org To: Ran Canetti From: John Viega In-Reply-To: <200304100449.AAA37132@ornavella.watson.ibm.com> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Content-Transfer-Encoding: 7bit Sender: cfrg-admin@ietf.org Errors-To: cfrg-admin@ietf.org X-BeenThere: cfrg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Crypto Forum Research Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On Thursday, April 10, 2003, at 12:49 AM, Ran Canetti wrote: > There were three main topics: > 1. How to deal with the case where the "rough keying material" we > start with > is not guaranteed to be "pseudorandom" - ie, not completely secret > or > not uniformly distributed. > 2. How to deal with the case where the "rough keying material" we > start with > is of variable length. > 3. How to obtain a variable-length output. > [...] > Topic 1 is much more of an unstable ground [...] I disagree. We know how to do 1 quite well. David McGrew and I were recently talking about this thread. A simple PRF that takes a variable length input and produces a variable length output is to hash the input (if necessary), then produce as much output as necessary by using a keyed counter mode operation. When using SHA1 as a primitive, you could simply use the keying material as-is, and HMAC-SHA1 a counter for however much output you need. Or, if the keying material is large, you can hash it down and use the result to key HMAC-SHA1 in counter mode. If using AES as a primitive, one can first hash the input down to the size of an AES key by using one of the many constructions that turn a block cipher into a hash function. Then, one simply uses the result to key counter mode. The real issue we couldn't get past is how to create a PRF based from a single primitive that is easy to pipeline in hardware. The AES-based solution looks particularly unappealing from that point of view. Nonetheless, either of those PRFs should be fine for fairly general-purpose use, unless you care about protecting against password computation attacks, in which case there's no reason not to use PKCS#5's PBKDF2. John _______________________________________________ Cfrg mailing list Cfrg@ietf.org https://www1.ietf.org/mailman/listinfo/cfrg From mailnull@www1.ietf.org Thu Apr 10 01:25:13 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA26761 for ; Thu, 10 Apr 2003 01:25:13 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3A5Ujh29487 for cfrg-archive@odin.ietf.org; Thu, 10 Apr 2003 01:30:45 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3A5Uj829484 for ; Thu, 10 Apr 2003 01:30:45 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA26754 for ; Thu, 10 Apr 2003 01:24:41 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3A5N3829238; Thu, 10 Apr 2003 01:23:03 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3A5Mn829194 for ; Thu, 10 Apr 2003 01:22:49 -0400 Received: from igw2.watson.ibm.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA26531 for ; Thu, 10 Apr 2003 01:16:46 -0400 (EDT) Received: from sp1n293en1.watson.ibm.com (sp1n293en1.watson.ibm.com [9.2.112.57]) by igw2.watson.ibm.com (8.11.7/8.11.4) with ESMTP id h3A5JKQ118400; Thu, 10 Apr 2003 01:19:20 -0400 Received: from ornavella.watson.ibm.com (ornavella.watson.ibm.com [9.2.16.80]) by sp1n293en1.watson.ibm.com (8.11.6/8.11.4) with ESMTP id h3A5JKl83686; Thu, 10 Apr 2003 01:19:20 -0400 Received: (from canetti@localhost) by ornavella.watson.ibm.com (AIX4.3/8.9.3/8.9.3/09-18-2002) id BAA18748; Thu, 10 Apr 2003 01:19:19 -0400 Date: Thu, 10 Apr 2003 01:19:19 -0400 From: Ran Canetti Message-Id: <200304100519.BAA18748@ornavella.watson.ibm.com> To: canetti@watson.ibm.com, viega@list.org Subject: Re: [Cfrg] AES-based PRF - comment please Cc: cfrg@ietf.org Sender: cfrg-admin@ietf.org Errors-To: cfrg-admin@ietf.org X-BeenThere: cfrg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Crypto Forum Research Group List-Post: List-Help: List-Subscribe: , > From viega@list.org Thu Apr 10 01:11:40 2003 > > On Thursday, April 10, 2003, at 12:49 AM, Ran Canetti wrote: > > > There were three main topics: > > 1. How to deal with the case where the "rough keying material" we > > start with > > is not guaranteed to be "pseudorandom" - ie, not completely secret > > or > > not uniformly distributed. > > 2. How to deal with the case where the "rough keying material" we > > start with > > is of variable length. > > 3. How to obtain a variable-length output. > > [...] > > Topic 1 is much more of an unstable ground [...] > > I disagree. We know how to do 1 quite well. David McGrew and I were > recently talking about this thread. A simple PRF that takes a variable > length input and produces a variable length output is to hash the input > (if necessary), then produce as much output as necessary by using a > keyed counter mode operation. > > When using SHA1 as a primitive, you could simply use the keying > material as-is, and HMAC-SHA1 a counter for however much output you > need. Or, if the keying material is large, you can hash it down and > use the result to key HMAC-SHA1 in counter mode. > > If using AES as a primitive, one can first hash the input down to the > size of an AES key by using one of the many constructions that turn a > block cipher into a hash function. Then, one simply uses the result to > key counter mode. > > The real issue we couldn't get past is how to create a PRF based from a > single primitive that is easy to pipeline in hardware. The AES-based > solution looks particularly unappealing from that point of view. > > Nonetheless, either of those PRFs should be fine for fairly > general-purpose use, unless you care about protecting against password > computation attacks, in which case there's no reason not to use > PKCS#5's PBKDF2. > > John John, I think you missed my point. Ofcourse you can do it. The question is which security guarantees you'll get... Ran _______________________________________________ Cfrg mailing list Cfrg@ietf.org https://www1.ietf.org/mailman/listinfo/cfrg From mailnull@www1.ietf.org Thu Apr 10 09:24:36 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19421 for ; Thu, 10 Apr 2003 09:24:36 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3ADUG509991 for cfrg-archive@odin.ietf.org; Thu, 10 Apr 2003 09:30:16 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3ADUG809988 for ; Thu, 10 Apr 2003 09:30:16 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19405 for ; Thu, 10 Apr 2003 09:24:04 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3ADJJ809423; Thu, 10 Apr 2003 09:19:19 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3A5QE829323 for ; Thu, 10 Apr 2003 01:26:14 -0400 Received: from mail.securesoftware.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA26575 for ; Thu, 10 Apr 2003 01:20:11 -0400 (EDT) Received: from securesoftware.com (pcp732336pcs.arlngt01.va.comcast.net [68.49.161.231]) by mail.securesoftware.com (Postfix) with ESMTP id C21F7134649; Thu, 10 Apr 2003 01:23:35 -0400 (EDT) Date: Thu, 10 Apr 2003 01:22:42 -0400 Subject: Re: [Cfrg] AES-based PRF - comment please Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: cfrg@ietf.org To: Ran Canetti From: John Viega In-Reply-To: <200304100507.BAA37648@ornavella.watson.ibm.com> Message-Id: <7469745E-6B14-11D7-B648-000A959CFBBA@securesoftware.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Content-Transfer-Encoding: 7bit Sender: cfrg-admin@ietf.org Errors-To: cfrg-admin@ietf.org X-BeenThere: cfrg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Crypto Forum Research Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Ok, sure. Now that I see that you're back on the ideal cipher issue, I agree with you, and I said the same thing much earlier in the thread. I personally suspect that we're unlikely to see a hash construct from a PRP in the near future, but I'd love to be proven wrong. In the mean time, I'm happy using SHA1, and I think, in practice, assuming AES has the properties of an ideal cipher isn't even close to the most unreasonable thing the average person will do in his or her designs. John On Thursday, April 10, 2003, at 01:07 AM, Ran Canetti wrote: > Maybe this happens, maybe it doesnt. We dont know. So I think it's > best to > stick to what we can prove based on the requirements for which AES was > designed > (ie, to be an invertible PRP). _______________________________________________ Cfrg mailing list Cfrg@ietf.org https://www1.ietf.org/mailman/listinfo/cfrg From mailnull@www1.ietf.org Thu Apr 10 12:15:54 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25395 for ; Thu, 10 Apr 2003 12:15:54 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3AGLdL23691 for cfrg-archive@odin.ietf.org; Thu, 10 Apr 2003 12:21:39 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3AGLd823688 for ; Thu, 10 Apr 2003 12:21:39 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25380 for ; Thu, 10 Apr 2003 12:15:22 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3AGDN823324; Thu, 10 Apr 2003 12:13:23 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3AGCt823271 for ; Thu, 10 Apr 2003 12:12:55 -0400 Received: from sj-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25150 for ; Thu, 10 Apr 2003 12:06:38 -0400 (EDT) Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h3AG9Ami002764; Thu, 10 Apr 2003 09:09:11 -0700 (PDT) Received: from MCGREWW2K (stealth-10-34-251-100.cisco.com [10.34.251.100]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with SMTP id AFZ46710; Thu, 10 Apr 2003 09:07:29 -0700 (PDT) From: "David A. Mcgrew" To: "Ran Canetti" , Subject: RE: [Cfrg] AES-based PRF - comment please Date: Thu, 10 Apr 2003 09:09:08 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <200304100449.AAA37132@ornavella.watson.ibm.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Importance: Normal Content-Transfer-Encoding: 7bit Sender: cfrg-admin@ietf.org Errors-To: cfrg-admin@ietf.org X-BeenThere: cfrg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Crypto Forum Research Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Ran, an excellent writeup, more inline: > -----Original Message----- > From: cfrg-admin@ietf.org [mailto:cfrg-admin@ietf.org]On Behalf Of Ran > Canetti > Sent: Wednesday, April 09, 2003 9:50 PM > To: cfrg@ietf.org > Subject: Re: [Cfrg] AES-based PRF - comment please > > > > - A few belated remarks on this thread. (Sorry for not being able to respond > in a more on-line fashion.) > > Let me first recap the discussion as I understand it. The overall question > is how to construct a good key-derivation function for key-exchange > protocols, and for Diffie-Hellman based protocols in particular. > There were three main topics: > 1. How to deal with the case where the "rough keying material" we start with > is not guaranteed to be "pseudorandom" - ie, not completely secret or > not uniformly distributed. > 2. How to deal with the case where the "rough keying material" we start with > is of variable length. > 3. How to obtain a variable-length output. Agreed. > > > I believe topic 3 is pretty well understood, once we have a pseudorandom key; > there are several ways to do it, with known tradeoffs, and with good analysis > that provides concrete and quantitative security bounds. (Some of these ways > were suggested in this thread.) > > Topic 2 is also well understood - at least for the case where > the keying material we start with is pseudorandom and is of > sufficient length. In this case, we simply use as many bits of the key > as are necessary to key the cyptographic function we're working with. > Unused key bits can be prepended to the "non-secret" input of the > underlying cryptographic function - this may help reduce the assumptions on > that function. If the keying material is too short then we're back to topic 1. > > Topic 1 is much more of an unstable ground - and the focus of the rest of > this note. First, at the risk of being redundant, let me recap what is > usually meant by a "pseudorandom keying material": Roughly speaking, > the keying material to the key derivation function is said to be > "pseudorandom" if no adversary that (uses a given amount of > computational resources and) is given all the publicly available > information can win in the following game with probability that > is non-negligibly more than one half. In the game, the adversary is given > either the real keying material (with probability one half) or an > independently and uniformly chosen string of the same length. It wins if it > guesses correctly which is the case. > (Ofcourse, this qualitative definition can be made quantitative, relating > the actual success probability to the resources used by the adversary.) > > For sake of presentation let me concentrate on DH-based key exchange. > Here the keying material is g^xy and the adversary knows g^x,g^y. > So, if the DDH assumption holds (ie, if g^xy is pseudorandom given g^x,g^y) > then we're golden. But what if not? (This is the "belt and suspenders" > question. Great term.) > > Ofcourse, if DH is completely broken and g^xy is completely computable from > g^x,g^y then nothing can be done. But what if we're in an "in-between" > situation, where g^xy canot be completely computed, but it is possible to > distinguish it from random, either by predicting some of the bits based on > the public info, or in other ways? How can we "extract" a pseudorandom > key from g^xy? > > As a side remark, let me first say that, at least in principle, > the problem is solved: The theory of cryptography offers a number of generic > ways to extract pseudorandom bits from g^xy, based only on the minimal > assumption that g^xy cannot be completely computed given g^x,g^y. > But these methods are highly inefficient. In particular, we'd be able to > extract only very few bits from each DH exchange - or in other words we'd > need several DH exchanges to get a sizable key. (I'm referring here to the > standard constructions of pseudorandom generators based on any > one-way function.) > > So the question is how to do it in a more reasonable way from an efficiency > point of view. In other words we're looking for a way to use some readily > avaliable cryptographic function (say SHA, AES etc) in order to extract a > significant number of bits from g^xy, so that these bits will be > pseudorandom based on minimal assumptions on the DH problem and on the > underlying cryptographic function. I dont have a good, well analyzed > proposal here. I think this is a good research topic. Agreed. FWIW, I would expect that any AES-based solution to this problem would involve an AES-based unkeyed collision-resistant hash function. Such a construct, if efficient and proven secure under reasonable assumptions, would be of general utility. From an engineering standpoint, it seems to me that the responsibility for producing uniformly random output bits should be put onto the DH component. I'm thinking of the following structure: - a DH component, which takes public keys as input and outputs a (uniformly unpredictable) secret, and - a key derivation component, which takes a (uniformly unpredictable) secret and some set of public data (e.g. nonces, labels, and so forth) and produces a set of unpredictable keys. Using this structure, we get the benefits that we've isolated the well-solved problem, and that the DH component can be swapped out for other components (e.g. symmetric or asymmetric key transport, elliptic curve variants, out-of-band keys, or whatever). Also, this separation can help the key derivation component meet other secondary design goals, such as providing forward security (in the sense of the 'serial' method in "Increasing the lifetime of a key", by Abdalla and Bellare, - Asiacrypt 2000, online at http://www.cs.ucsd.edu/users/mihir/papers/rekey.html). > > Ran > > > A couple more remarks: > > 1. A cryptographic primitive that is closely related to what we need is > "exposure resilient function (ERF)". These are functions whose output is > pseudorandom even if part of the input is known. Some initial and theoretical > study of such functionas was done in [1]. Unfortunately, I didnt see > an immediate way to use the techniques from there in our case. > > [1] R. Canetti, Y. Dodis, S. Halevi, E. Kushilevitz, A. Sahai, > ``Exposure-Resilient Functions and All-or-Nothing Transforms,'' > Eurocrypt, 2000. > > > 2. Regarding random oracles. It was suggested to model the underlying > cryptographic function (SHA, AES, etc.) as a random oracle and analyze the > security of the construction using the random oracle methodology > (David gave a great description of this methodology - it ought to be quoted > in some textbook). But I dont think that such a modeling will be > helpful in our context. One issue is ofourse the inherent unsoundness of > this methodology, as was already discussed on this thread. But there is > a much more immediate issue. Recall that we're trying to find a construction > that would make only minimal assumption on the underlying functions. > But if we model these functions as random oracles then almost any > construction would be labeled "secure" - good ones as well as > less good ones. In other words, this modeling is so "coarse grained" > that it doesnt allow investigating what we are interested > in (minimizing assumptions). It is a bit like using a 10 pounds axe > to trim fingernails... ugh! :-) David > > [Something somewhat similar happens in the case of hash-based MACs. If we > model the hash function as a random oracle then many different ways of > keying the underlying hash function result in equally secure MACs. > But constructions do differ a lot in the assumption they make on the > underlying hash function. In particular, HMAC tries to minimize those > assumptions, and I believe that this is at least partly why it was chosen > over other constructions.] > > > > _______________________________________________ > Cfrg mailing list > Cfrg@ietf.org > https://www1.ietf.org/mailman/listinfo/cfrg _______________________________________________ Cfrg mailing list Cfrg@ietf.org https://www1.ietf.org/mailman/listinfo/cfrg From mailnull@www1.ietf.org Thu Apr 10 12:30:59 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25886 for ; Thu, 10 Apr 2003 12:30:59 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3AGajs24448 for cfrg-archive@odin.ietf.org; Thu, 10 Apr 2003 12:36:45 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3AGaj824445 for ; Thu, 10 Apr 2003 12:36:45 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25822 for ; Thu, 10 Apr 2003 12:30:28 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3AGQ5823940; Thu, 10 Apr 2003 12:26:05 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3AGPI823898 for ; Thu, 10 Apr 2003 12:25:18 -0400 Received: from sj-core-5.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25500 for ; Thu, 10 Apr 2003 12:19:01 -0400 (EDT) Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-5.cisco.com (8.12.6/8.12.6) with ESMTP id h3AGLTGO003722; Thu, 10 Apr 2003 09:21:30 -0700 (PDT) Received: from MCGREWW2K (stealth-10-34-251-100.cisco.com [10.34.251.100]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with SMTP id AFZ47822; Thu, 10 Apr 2003 09:19:44 -0700 (PDT) From: "David A. Mcgrew" To: "John Viega" , "Ran Canetti" Cc: Subject: RE: [Cfrg] AES-based PRF - comment please Date: Thu, 10 Apr 2003 09:21:24 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <7469745E-6B14-11D7-B648-000A959CFBBA@securesoftware.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Importance: Normal Content-Transfer-Encoding: 7bit Sender: cfrg-admin@ietf.org Errors-To: cfrg-admin@ietf.org X-BeenThere: cfrg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Crypto Forum Research Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit John, > -----Original Message----- > From: cfrg-admin@ietf.org [mailto:cfrg-admin@ietf.org]On Behalf Of John > Viega > Sent: Wednesday, April 09, 2003 10:23 PM > To: Ran Canetti > Cc: cfrg@ietf.org > Subject: Re: [Cfrg] AES-based PRF - comment please > > > Ok, sure. Now that I see that you're back on the ideal cipher issue, I > agree with you, and I said the same thing much earlier in the thread. > I personally suspect that we're unlikely to see a hash construct from a > PRP in the near future, but I'd love to be proven wrong. It would be neat if there were some assumption in between that of indistinguishability from a PRP and that of the ideal cipher that could be used to make a collision-resistant hash out of AES. But it's not obvious to me :-) My $0.02 on AES-hashes: depending on how the hash function is used, it may be acceptable for it to be relatively inefficient. For example, if it is used in conjunction with a public-key operation, it could require loads of invocations of the PRP and still not change the order of magnitude of the total amount of computation done. But for sure computational inefficiency would impact utility. It would be nice if we could eliminate SHA from our implementations in favor of an AES mode, but in practice it is probably not so important. I think that a good case can be made for getting SHA out of the data-plane (that is, replacing HMAC-SHA with something that can be pipelined), but I'm not sure that there's much need to eliminate it from key derivation. David > > In the mean time, I'm happy using SHA1, and I think, in practice, > assuming AES has the properties of an ideal cipher isn't even close to > the most unreasonable thing the average person will do in his or her > designs. > > John > > On Thursday, April 10, 2003, at 01:07 AM, Ran Canetti wrote: > > > Maybe this happens, maybe it doesnt. We dont know. So I think it's > > best to > > stick to what we can prove based on the requirements for which AES was > > designed > > (ie, to be an invertible PRP). > > _______________________________________________ > Cfrg mailing list > Cfrg@ietf.org > https://www1.ietf.org/mailman/listinfo/cfrg _______________________________________________ Cfrg mailing list Cfrg@ietf.org https://www1.ietf.org/mailman/listinfo/cfrg From mailnull@www1.ietf.org Thu Apr 10 13:25:36 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27231 for ; Thu, 10 Apr 2003 13:25:36 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3AHVNu28705 for cfrg-archive@odin.ietf.org; Thu, 10 Apr 2003 13:31:23 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3AHVN828702 for ; Thu, 10 Apr 2003 13:31:23 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27210 for ; Thu, 10 Apr 2003 13:25:06 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 193fXI-0002ve-00 for cfrg-web-archive@ietf.org; Thu, 10 Apr 2003 13:08:28 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3AHMP828295; Thu, 10 Apr 2003 13:22:25 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3AHLO828226 for ; Thu, 10 Apr 2003 13:21:24 -0400 Received: from igw2.watson.ibm.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26919 for ; Thu, 10 Apr 2003 13:15:06 -0400 (EDT) Received: from sp1n293en1.watson.ibm.com (sp1n293en1.watson.ibm.com [9.2.112.57]) by igw2.watson.ibm.com (8.11.7/8.11.4) with ESMTP id h3AHHeQ128164; Thu, 10 Apr 2003 13:17:41 -0400 Received: from ornavella.watson.ibm.com (ornavella.watson.ibm.com [9.2.16.80]) by sp1n293en1.watson.ibm.com (8.11.6/8.11.4) with ESMTP id h3AHHel59098; Thu, 10 Apr 2003 13:17:40 -0400 Received: (from canetti@localhost) by ornavella.watson.ibm.com (AIX4.3/8.9.3/8.9.3/09-18-2002) id NAA18836; Thu, 10 Apr 2003 13:17:40 -0400 Date: Thu, 10 Apr 2003 13:17:40 -0400 From: Ran Canetti Message-Id: <200304101717.NAA18836@ornavella.watson.ibm.com> To: canetti@watson.ibm.com, cfrg@ietf.org, mcgrew@cisco.com Subject: RE: [Cfrg] AES-based PRF - comment please Sender: cfrg-admin@ietf.org Errors-To: cfrg-admin@ietf.org X-BeenThere: cfrg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Crypto Forum Research Group List-Post: List-Help: List-Subscribe: , I very much agree that this "pseudorandomness extraction" function is best treated separately from straightforward key derivation. But I'd say that it also deserves to be separate also from the DH component. In fact, it probably deserves being a component by itself, both from an engineering point of view and from a conceptual/theoretical pont of view. (It may well be useful in contexts other than DH-based key exchange.) Ran > From mcgrew@cisco.com Thu Apr 10 12:10:48 2003 > > From an engineering standpoint, it seems to me that the responsibility for > producing uniformly random output bits should be put onto the DH component. > I'm thinking of the following structure: > > - a DH component, which takes public keys as input and outputs a (uniformly > unpredictable) secret, and > > - a key derivation component, which takes a (uniformly unpredictable) secret > and some set of public data (e.g. nonces, labels, and so forth) and produces a > set of unpredictable keys. > > Using this structure, we get the benefits that we've isolated the well-solved > problem, and that the DH component can be swapped out for other components (e.g. > symmetric or asymmetric key transport, elliptic curve variants, out-of-band > keys, or whatever). Also, this separation can help the key derivation component > meet other secondary design goals, such as providing forward security (in the > sense of the 'serial' method in "Increasing the lifetime of a key", by Abdalla > and Bellare, - Asiacrypt 2000, online at > http://www.cs.ucsd.edu/users/mihir/papers/rekey.html). > _______________________________________________ Cfrg mailing list Cfrg@ietf.org https://www1.ietf.org/mailman/listinfo/cfrg From mailnull@www1.ietf.org Thu Apr 10 13:53:09 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28056 for ; Thu, 10 Apr 2003 13:53:09 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3AHwuw30980 for cfrg-archive@odin.ietf.org; Thu, 10 Apr 2003 13:58:56 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3AHwu830977 for ; Thu, 10 Apr 2003 13:58:56 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28033 for ; Thu, 10 Apr 2003 13:52:38 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 193fxx-00035V-00 for cfrg-web-archive@ietf.org; Thu, 10 Apr 2003 13:36:01 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 193fxw-00035S-00 for cfrg-web-archive@ietf.org; Thu, 10 Apr 2003 13:36:00 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3AHp5830463; Thu, 10 Apr 2003 13:51:05 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3AHnB830379 for ; Thu, 10 Apr 2003 13:49:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27685 for ; Thu, 10 Apr 2003 13:42:54 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 193foW-00030c-00 for cfrg@ietf.org; Thu, 10 Apr 2003 13:26:16 -0400 Received: from auemail1.lucent.com ([192.11.223.161] helo=auemail1.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 193foW-00030S-00 for cfrg@ietf.org; Thu, 10 Apr 2003 13:26:16 -0400 Received: from nwmail.wh.lucent.com (h135-5-40-100.lucent.com [135.5.40.100]) by auemail1.firewall.lucent.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3AHivJ02971 for ; Thu, 10 Apr 2003 13:44:57 -0400 (EDT) Received: by nwmail.wh.lucent.com (8.11.6+Sun/EMS-1.5 sol2) id h3AHitC17657; Thu, 10 Apr 2003 13:44:55 -0400 (EDT) Received: from bell-labs.com by nwmail.wh.lucent.com (8.11.6+Sun/EMS-1.5 sol2) id h3AHisI17630; Thu, 10 Apr 2003 13:44:55 -0400 (EDT) Message-ID: <3E95AD95.6040008@bell-labs.com> Date: Thu, 10 Apr 2003 13:44:53 -0400 From: Uri Blumenthal Organization: Lucent Tehcnologies / Bell Labs User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en, zh-cn, ru, de, he MIME-Version: 1.0 To: cfrg@ietf.org Subject: Re: [Cfrg] AES-based PRF - comment please References: <200304100449.AAA37132@ornavella.watson.ibm.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: cfrg-admin@ietf.org Errors-To: cfrg-admin@ietf.org X-BeenThere: cfrg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Crypto Forum Research Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Ran Canetti wrote: > There were three main topics: > 1. How to deal with the case where the "rough keying material" we start with > is not guaranteed to be "pseudorandom" - ie, not completely secret or > not uniformly distributed. > 2........ > 3........ > > I believe topic 3 is pretty well understood, once we have a > pseudorandom key..........Topic 2 is also well understood - > at least for the case where the keying material we start > with is pseudorandom and is of sufficient length........ Yes. > Topic 1 is much more of an unstable ground............. Yes. And we'll deal with two cases: (a) the input is "hopefully" random "enough" - e.g. g^xy, and (b) we know nothing of the input quality but assume that it can have fewer bits of randomness thn the required key size. > For sake of presentation let me concentrate on DH-based key exchange. > Here the keying material is g^xy and the adversary knows g^x,g^y. > So, if the DDH assumption holds (ie, if g^xy is pseudorandom given g^x,g^y) > then we're golden. But what if not? (This is the "belt and suspenders" > question. Great term.) Yes, the term is great. The problem is: if DDH doesn't hold - then you have to resort to unproved properties of SHA, actually modeling it as a random oracle - which you don't seem to like. > ...[assume].... we're in an "in-between" > situation, where g^xy canot be completely computed, but it is possible to > distinguish it from random, either by predicting some of the bits based on > the public info, or in other ways? How can we "extract" a pseudorandom > key from g^xy?...how to do it in a more reasonable way from an efficiency > point of view. In other words we're looking for a way to use some readily > avaliable cryptographic function (say SHA, AES etc) in order to extract a > significant number of bits from g^xy, so that these bits will be > pseudorandom based on minimal assumptions on the DH problem and on the > underlying cryptographic function. A nicer way IMHO would be to "post-process" g^xy and extract some "random" bits with quantitative guarantees... Though it may be that the most reasonable way of doing it is running, say AES-hash over it... > I dont have a good, well analyzed > proposal here. I think this is a good research topic. :-) > 1. A cryptographic primitive that is closely related to what we need is > "exposure resilient function (ERF)". These are functions whose output is > pseudorandom even if part of the input is known.... > [1] R. Canetti, Y. Dodis, S. Halevi, E. Kushilevitz, A. Sahai, > ``Exposure-Resilient Functions and All-or-Nothing Transforms,'' > Eurocrypt, 2000. Would love to look at this paper. > 2. Regarding random oracles. It was suggested to model the underlying > cryptographic function (SHA, AES, etc.) as a random oracle and analyze the > security of the construction using the random oracle methodology > (David gave a great description of this methodology - it ought to be quoted > in some textbook). But I dont think that such a modeling will be > helpful in our context. You already use such a modeling of the currently defined PRF. Recall David's description: two assumptions "balancing" each other - either DDH holds, or SHA behaves like a random oracle. If you assume that SHA does NOT behave like a random oracle, then your security proofs are dependent on DDH. Now since you can't just go from "it's collision-resistant" to "it behaves like a random oracle" - it has to be a leap of faith, supported by the fact that the opposite hasn't been proven/demonstrated. _______________________________________________ Cfrg mailing list Cfrg@ietf.org https://www1.ietf.org/mailman/listinfo/cfrg From mailnull@www1.ietf.org Thu Apr 10 13:57:00 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28251 for ; Thu, 10 Apr 2003 13:57:00 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3AI2ld31350 for cfrg-archive@odin.ietf.org; Thu, 10 Apr 2003 14:02:47 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3AI2l831347 for ; Thu, 10 Apr 2003 14:02:47 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28205 for ; Thu, 10 Apr 2003 13:56:29 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 193g1g-00038M-00 for cfrg-web-archive@ietf.org; Thu, 10 Apr 2003 13:39:52 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 193g1f-00038J-00 for cfrg-web-archive@ietf.org; Thu, 10 Apr 2003 13:39:51 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3AHr2830606; Thu, 10 Apr 2003 13:53:02 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3AHqA830562 for ; Thu, 10 Apr 2003 13:52:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27759 for ; Thu, 10 Apr 2003 13:45:52 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 193frO-00031i-00 for cfrg@ietf.org; Thu, 10 Apr 2003 13:29:14 -0400 Received: from hoemail1.lucent.com ([192.11.226.161] helo=hoemail1.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 193frO-00031Q-00 for cfrg@ietf.org; Thu, 10 Apr 2003 13:29:14 -0400 Received: from nwmail.wh.lucent.com (h135-5-40-100.lucent.com [135.5.40.100]) by hoemail1.firewall.lucent.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3AHlqt10338 for ; Thu, 10 Apr 2003 13:47:52 -0400 (EDT) Received: by nwmail.wh.lucent.com (8.11.6+Sun/EMS-1.5 sol2) id h3AHlqW19266; Thu, 10 Apr 2003 13:47:52 -0400 (EDT) Received: from bell-labs.com by nwmail.wh.lucent.com (8.11.6+Sun/EMS-1.5 sol2) id h3AHlpI19260; Thu, 10 Apr 2003 13:47:51 -0400 (EDT) Message-ID: <3E95AE45.30404@bell-labs.com> Date: Thu, 10 Apr 2003 13:47:49 -0400 From: Uri Blumenthal Organization: Lucent Tehcnologies / Bell Labs User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en, zh-cn, ru, de, he MIME-Version: 1.0 To: cfrg@ietf.org Subject: Extracting random bits from g^xy (was Re: [Cfrg] AES-based PRF - comment please) References: <200304101717.NAA18836@ornavella.watson.ibm.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: cfrg-admin@ietf.org Errors-To: cfrg-admin@ietf.org X-BeenThere: cfrg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Crypto Forum Research Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Ran Canetti wrote: > I very much agree that this "pseudorandomness extraction" function is best > treated separately from straightforward key derivation. Yes. > But I'd say that it also deserves to be separate also from the > DH component. In fact, it probably deserves being a component > by itself, both from an engineering point of view and from > a conceptual/theoretical pont of view. (It may well be useful > in contexts other than DH-based key exchange.) From a coneptual point of view, since this function is likely to be dependent on DH output structure, it probably belongs with DH. >>From mcgrew@cisco.com Thu Apr 10 12:10:48 2003 >> >>From an engineering standpoint, it seems to me that the responsibility for >>producing uniformly random output bits should be put onto the DH component. >>I'm thinking of the following structure: >> >> - a DH component, which takes public keys as input and outputs a (uniformly >>unpredictable) secret, and >> >> - a key derivation component, which takes a (uniformly unpredictable) secret >>and some set of public data (e.g. nonces, labels, and so forth) and produces a >>set of unpredictable keys. >> >>Using this structure, we get the benefits that we've isolated the well-solved >>problem, and that the DH component can be swapped out for other components (e.g. >>symmetric or asymmetric key transport, elliptic curve variants, out-of-band >>keys, or whatever). Also, this separation can help the key derivation component >>meet other secondary design goals, such as providing forward security (in the >>sense of the 'serial' method in "Increasing the lifetime of a key", by Abdalla >>and Bellare, - Asiacrypt 2000, online at >>http://www.cs.ucsd.edu/users/mihir/papers/rekey.html). >> > > _______________________________________________ > Cfrg mailing list > Cfrg@ietf.org > https://www1.ietf.org/mailman/listinfo/cfrg _______________________________________________ Cfrg mailing list Cfrg@ietf.org https://www1.ietf.org/mailman/listinfo/cfrg From mailnull@www1.ietf.org Fri Apr 11 12:25:10 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19991 for ; Fri, 11 Apr 2003 12:25:10 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3BGVOb07749 for cfrg-archive@odin.ietf.org; Fri, 11 Apr 2003 12:31:24 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3BGVO807746 for ; Fri, 11 Apr 2003 12:31:24 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19956 for ; Fri, 11 Apr 2003 12:24:39 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 1941Mx-0003wz-00 for cfrg-web-archive@ietf.org; Fri, 11 Apr 2003 12:27:15 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1941Mw-0003ww-00 for cfrg-web-archive@ietf.org; Fri, 11 Apr 2003 12:27:14 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3BGO5807223; Fri, 11 Apr 2003 12:24:05 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3BGLf807097 for ; Fri, 11 Apr 2003 12:21:41 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19601 for ; Fri, 11 Apr 2003 12:14:57 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 1941DY-0003rI-00 for cfrg@ietf.org; Fri, 11 Apr 2003 12:17:32 -0400 Received: from ee.technion.ac.il ([132.68.48.5]) by ietf-mx with esmtp (Exim 4.12) id 1941DX-0003rF-00 for cfrg@ietf.org; Fri, 11 Apr 2003 12:17:32 -0400 Received: from localhost (hugo@localhost) by ee.technion.ac.il (8.11.6+Sun/8.10.2) with ESMTP id h3BGHYS05161; Fri, 11 Apr 2003 19:17:34 +0300 (IDT) Date: Fri, 11 Apr 2003 19:17:34 +0300 (IDT) From: Hugo Krawczyk To: Soy Yo cc: cfrg@ietf.org, mcgrew@cisco.com Subject: RE: [Cfrg] AES-based PRF - comment please In-Reply-To: <200304101717.NAA18836@ornavella.watson.ibm.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: cfrg-admin@ietf.org Errors-To: cfrg-admin@ietf.org X-BeenThere: cfrg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Crypto Forum Research Group List-Post: List-Help: List-Subscribe: , what happened to UH? give me a source of public randomness and I extract all the secret entropy (computational entropy) My IKE proposal: use prf as UH On Thu, 10 Apr 2003, Ran Canetti wrote: > I very much agree that this "pseudorandomness extraction" function is best > treated separately from straightforward key derivation. > But I'd say that it also deserves to be separate also from the DH component. > In fact, it probably deserves being a component by itself, > both from an engineering point of view and from a conceptual/theoretical > pont of view. (It may well be useful in contexts other than DH-based key > exchange.) > > Ran > > > > From mcgrew@cisco.com Thu Apr 10 12:10:48 2003 > > > > From an engineering standpoint, it seems to me that the responsibility for > > producing uniformly random output bits should be put onto the DH component. > > I'm thinking of the following structure: > > > > - a DH component, which takes public keys as input and outputs a (uniformly > > unpredictable) secret, and > > > > - a key derivation component, which takes a (uniformly unpredictable) secret > > and some set of public data (e.g. nonces, labels, and so forth) and produces a > > set of unpredictable keys. > > > > Using this structure, we get the benefits that we've isolated the well-solved > > problem, and that the DH component can be swapped out for other components (e.g. > > symmetric or asymmetric key transport, elliptic curve variants, out-of-band > > keys, or whatever). Also, this separation can help the key derivation component > > meet other secondary design goals, such as providing forward security (in the > > sense of the 'serial' method in "Increasing the lifetime of a key", by Abdalla > > and Bellare, - Asiacrypt 2000, online at > > http://www.cs.ucsd.edu/users/mihir/papers/rekey.html). > > > _______________________________________________ > Cfrg mailing list > Cfrg@ietf.org > https://www1.ietf.org/mailman/listinfo/cfrg > _______________________________________________ Cfrg mailing list Cfrg@ietf.org https://www1.ietf.org/mailman/listinfo/cfrg From mailnull@www1.ietf.org Fri Apr 11 18:28:34 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04000 for ; Fri, 11 Apr 2003 18:28:34 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3BMYtl04078 for cfrg-archive@odin.ietf.org; Fri, 11 Apr 2003 18:34:55 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3BMYt804075 for ; Fri, 11 Apr 2003 18:34:55 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03983 for ; Fri, 11 Apr 2003 18:28:03 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 19472c-0006O5-00 for cfrg-web-archive@ietf.org; Fri, 11 Apr 2003 18:30:38 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19472c-0006O1-00 for cfrg-web-archive@ietf.org; Fri, 11 Apr 2003 18:30:38 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3BMSh803869; Fri, 11 Apr 2003 18:28:43 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3BMRc803823 for ; Fri, 11 Apr 2003 18:27:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03857 for ; Fri, 11 Apr 2003 18:20:46 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 1946vZ-0006M5-00 for cfrg@ietf.org; Fri, 11 Apr 2003 18:23:21 -0400 Received: from sj-core-1.cisco.com ([171.71.177.237]) by ietf-mx with esmtp (Exim 4.12) id 1946vY-0006M2-00 for cfrg@ietf.org; Fri, 11 Apr 2003 18:23:20 -0400 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h3BMMmmi017079; Fri, 11 Apr 2003 15:22:48 -0700 (PDT) Received: from MCGREWW2K (stealth-10-34-251-100.cisco.com [10.34.251.100]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with SMTP id AGA82015; Fri, 11 Apr 2003 15:21:16 -0700 (PDT) From: "David A. Mcgrew" To: "Ken Raeburn" , Subject: RE: [Cfrg] Kerberos crypto framework Date: Fri, 11 Apr 2003 15:22:46 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Importance: Normal Content-Transfer-Encoding: 7bit Sender: cfrg-admin@ietf.org Errors-To: cfrg-admin@ietf.org X-BeenThere: cfrg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Crypto Forum Research Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Ken, thanks for pointing out these drafts. You mention that draft-raeburn-krb-rijndael-krb-03.txt is in WG last call (good to see AES adoption :-). Is draft-ietf-krb-wg-crypto-04.txt in last call as well? If not, I assume that it would be good for reviewers to concentrate on the former. More inline: > -----Original Message----- > From: cfrg-admin@ietf.org [mailto:cfrg-admin@ietf.org]On Behalf Of Ken > Raeburn > Sent: Friday, April 04, 2003 4:39 PM > To: cfrg@ietf.org > Subject: [Cfrg] Kerberos crypto framework > > > The Kerberos working group (ietf-krb-wg@anl.gov) has two drafts we're > finishing up that could use some review by people with real crypto > backgrounds, unlike some of us total amateurs who are working on the > drafts. We'd appreciate any comments people may have. > > These documents attempt to: > > - describe an "interface" for cryptographic functionality for use in > Kerberos and related protocols and extensions, with what we hope > will be all the operations we need > - describe a profile system for additional encryption systems (e.g., > Microsoft's RC4, or PacketCable's version of 3DES) I didn't see references for these mechanisms. Are there IDs describing them? > - specify profiles for some existing encryption systems used by > Kerberos (DES and 3DES), and some known problems with them > - specify a profile for using AES in Kerberos > > The first document > http://www.mit.edu/~raeburn/draft-ietf-krb-wg-crypto-04.txt covers the > first three points, and should go to WG last call as soon as it gets > published in the I-D area. The somewhat arbitrary crypto > specifications were pulled out of various versions of the Kerberos > protocol specification into a separate specification, and a somewhat > generalized framework added at that time. We actually specify two > types of profiles for encryption systems, a low-level more detailed > one, and a simplified one needing fewer parameters specified, with a > process for deriving the more detailed one from it. The DES and 3DES > mechanisms are defined for compabitibility with existing > implementations. > > The second document, draft-raeburn-krb-rijndael-krb-03.txt, in WG last > call now, gives a profile for plugging AES into the framework > specified in the first document, and stands as an example of how to > define a new encryption system for Kerberos. AES support will be > required for version 5.2 of the Kerberos protocol (also in WG last > call). > > We're hoping to finish up the working group last call and move on to > IETF-wide last call soon. Any comments people have would be welcome. Sounds good. I'm sure that the WG is eager to move to AES, so I encourage all interested CFRGites to check it out. Note to KDF fans: Section 4.1. of draft-ietf-krb-wg-crypto-04.txt defines a key derivation function :-) David > > Ken > _______________________________________________ > Cfrg mailing list > Cfrg@ietf.org > https://www1.ietf.org/mailman/listinfo/cfrg _______________________________________________ Cfrg mailing list Cfrg@ietf.org https://www1.ietf.org/mailman/listinfo/cfrg From mailnull@www1.ietf.org Sat Apr 12 15:25:57 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03472 for ; Sat, 12 Apr 2003 15:25:57 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3CJWjX17642 for cfrg-archive@odin.ietf.org; Sat, 12 Apr 2003 15:32:45 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3CJWj817639 for ; Sat, 12 Apr 2003 15:32:45 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03462 for ; Sat, 12 Apr 2003 15:25:26 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 194QfR-0002Ga-00 for cfrg-web-archive@ietf.org; Sat, 12 Apr 2003 15:28:01 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 194QfR-0002GX-00 for cfrg-web-archive@ietf.org; Sat, 12 Apr 2003 15:28:01 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3CJV1817593; Sat, 12 Apr 2003 15:31:01 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3CJTH817525 for ; Sat, 12 Apr 2003 15:29:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03420 for ; Sat, 12 Apr 2003 15:21:58 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 194Qc5-0002G1-00 for cfrg@ietf.org; Sat, 12 Apr 2003 15:24:33 -0400 Received: from sccrmhc02.attbi.com ([204.127.202.62]) by ietf-mx with esmtp (Exim 4.12) id 194Qc5-0002Fy-00 for cfrg@ietf.org; Sat, 12 Apr 2003 15:24:33 -0400 Received: from alten.attbi.com (12-232-7-235.client.attbi.com[12.232.7.235]) by sccrmhc02.attbi.com (sccrmhc02) with SMTP id <200304121923590020071inne>; Sat, 12 Apr 2003 19:23:59 +0000 Message-Id: <5.2.0.9.0.20030412121621.034f95a8@mail.attbi.com> X-Sender: alten@mail.attbi.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Sat, 12 Apr 2003 12:21:01 -0700 To: Don Davis , daw@mozart.cs.berkeley.edu (David Wagner) From: Alex Alten Subject: Re: [Cfrg] AES-based PRF - comment please Cc: cfrg@ietf.org In-Reply-To: References: <3E823791.3080702@bell-labs.com> <3E832D47.8080909@bell-labs.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: cfrg-admin@ietf.org Errors-To: cfrg-admin@ietf.org X-BeenThere: cfrg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Crypto Forum Research Group List-Post: List-Help: List-Subscribe: , At 03:31 PM 3/27/2003 -0500, Don Davis wrote: >David Wagner wrote: > >>> No, there's no proof [that SHA-1 behaves like a random oracle] > > After years of scrutiny, noone has found any troubling anomalies > > in SHA. ... SHA1 would fit the bill, because cryptanalysts have > > tried really hard to find any anomaly that indicates it is not > > behaving like a random function, and they've all failed. > >unfortunately, SHA1 probably hasn't gotten all of the >scrutiny its predecessors got, but for an interesting >reason. > >in '96, Bart Preneel mentioned an interesting tidbit about >SHA1's prospects for survival. Even though SHA is closely >related to MD5, Dobbertin was not _allowed_ to extend his >MD5 attack to SHA, because Dobbertin works for the German >government's Security Service, and so is forbidden by law >to undermine US federal crypto standards. Since Dobbertin >is by far the strongest worker in the field of hash-function >inversions (RIPE-MD, MD4, MD5), SHA1 probably won't suffer >MD5's fate, even if SHA1 deserves to die. > >has someone else has come along to fill dobbertin's shoes? > >finally, i'll mention that before SHA1 came along, a hash >function's lifetime (spec to crack) was about 6 years. > > - don davis, boston This is interesting. What about SHA2? I assume it's just the SHA1 design extended to longer digests? BTW, IMHO I think that designing a good & fast 1-way hash is harder than a good & fast block cipher, especially with all the micro-instruction pipelining that occurs inside microprocessors. - Alex >- >_______________________________________________ >Cfrg mailing list >Cfrg@ietf.org >https://www1.ietf.org/mailman/listinfo/cfrg -- Alex Alten Alten@ATTBI.com _______________________________________________ Cfrg mailing list Cfrg@ietf.org https://www1.ietf.org/mailman/listinfo/cfrg From mailnull@www1.ietf.org Sat Apr 12 19:12:29 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07438 for ; Sat, 12 Apr 2003 19:12:23 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3CNJFD30562 for cfrg-archive@odin.ietf.org; Sat, 12 Apr 2003 19:19:15 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3CNJF830559 for ; Sat, 12 Apr 2003 19:19:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07433 for ; Sat, 12 Apr 2003 19:11:46 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 194UCR-0002v6-00 for cfrg-web-archive@ietf.org; Sat, 12 Apr 2003 19:14:19 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 194UCR-0002v2-00 for cfrg-web-archive@ietf.org; Sat, 12 Apr 2003 19:14:19 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3CNHS830517; Sat, 12 Apr 2003 19:17:28 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3CNGU830501 for ; Sat, 12 Apr 2003 19:16:30 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07409 for ; Sat, 12 Apr 2003 19:09:07 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 194U9s-0002uh-00 for cfrg@ietf.org; Sat, 12 Apr 2003 19:11:40 -0400 Received: from fort-point-station.mit.edu ([18.7.7.76]) by ietf-mx with esmtp (Exim 4.12) id 194U9s-0002ud-00 for cfrg@ietf.org; Sat, 12 Apr 2003 19:11:40 -0400 Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by fort-point-station.mit.edu (8.12.4/8.9.2) with ESMTP id h3CNBeXX010002; Sat, 12 Apr 2003 19:11:40 -0400 (EDT) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by grand-central-station.mit.edu (8.12.4/8.9.2) with ESMTP id h3CNBem5007456; Sat, 12 Apr 2003 19:11:40 -0400 (EDT) Received: from all-in-one.mit.edu (ALL-IN-ONE.MIT.EDU [18.18.1.71]) ) by melbourne-city-street.mit.edu (8.12.4/8.12.4) with ESMTP id h3CNBeU8028302; Sat, 12 Apr 2003 19:11:40 -0400 (EDT) Received: (from raeburn@localhost) by all-in-one.mit.edu (8.9.3) id TAA01440; Sat, 12 Apr 2003 19:11:39 -0400 To: "David A. Mcgrew" Cc: Subject: Re: [Cfrg] Kerberos crypto framework References: From: Ken Raeburn Date: Sat, 12 Apr 2003 19:11:39 -0400 In-Reply-To: ("David A. Mcgrew"'s message of "Fri, 11 Apr 2003 15:22:46 -0700") Message-ID: Lines: 45 User-Agent: Gnus/5.090005 (Oort Gnus v0.05) Emacs/21.2 (i686-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: cfrg-admin@ietf.org Errors-To: cfrg-admin@ietf.org X-BeenThere: cfrg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Crypto Forum Research Group List-Post: List-Help: List-Subscribe: , "David A. Mcgrew" writes: > thanks for pointing out these drafts. You mention that > draft-raeburn-krb-rijndael-krb-03.txt is in WG last call (good to see AES > adoption :-). Is draft-ietf-krb-wg-crypto-04.txt in last call as well? If not, > I assume that it would be good for reviewers to concentrate on the former. Actually, the former just finished WG last call, but we have one issue to work out, and either another WG last call or IETF last call should be coming up soon. The crypto draft is still in WG last call, but the WG chair only specified a one-week WG last call, meaning that's about to end (though I think that means we get a longer IETF last call period). Of course, no one needs to wait for the IETF last call to make comments. :-) >> - describe a profile system for additional encryption systems (e.g., >> Microsoft's RC4, or PacketCable's version of 3DES) > > I didn't see references for these mechanisms. Are there IDs describing them? There was an old I-D describing the RC4 system, but not based on the framework presented. There's occasionally talk about reworking that draft to describe a profile for the crypto framework, but I don't know if anyone's working on it at the moment. The Packet Cable folks are, I believe, using some old 3DES code that never got properly written up. All that's in the crypto draft is (should be) enough of a framework and descriptions of the necessary parameters to produce a complete and interoperable profile for either of these systems. As opposed to what we had before, where some of the crypto stuff was collected in one place, some kind of scattered throughout the rest of the Kerberos document, and some just left unspecified. > Note to KDF fans: Section 4.1. of draft-ietf-krb-wg-crypto-04.txt defines a key > derivation function :-) Yep. We can't have too many home-grown key derivation functions, can we? :-( This one was specified by Marc Horowitz several years ago in another I-D, and folded into an earlier Kerberos I-D before the crypto stuff was broken out again. Ken _______________________________________________ Cfrg mailing list Cfrg@ietf.org https://www1.ietf.org/mailman/listinfo/cfrg From mailnull@www1.ietf.org Mon Apr 14 01:05:50 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA12586 for ; Mon, 14 Apr 2003 01:05:50 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3E5DK309943 for cfrg-archive@odin.ietf.org; Mon, 14 Apr 2003 01:13:20 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3E5DK809940 for ; Mon, 14 Apr 2003 01:13:20 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA12580 for ; Mon, 14 Apr 2003 01:05:20 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 194wC9-0007Q9-00 for cfrg-web-archive@ietf.org; Mon, 14 Apr 2003 01:07:53 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 194wC9-0007Q5-00 for cfrg-web-archive@ietf.org; Mon, 14 Apr 2003 01:07:53 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3E5Bk809790; Mon, 14 Apr 2003 01:11:46 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3E572808911 for ; Mon, 14 Apr 2003 01:07:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA12440 for ; Mon, 14 Apr 2003 00:59:02 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 194w64-0007Oc-00 for cfrg@ietf.org; Mon, 14 Apr 2003 01:01:36 -0400 Received: from abraham.cs.berkeley.edu ([128.32.37.170] helo=mx2.cypherpunks.ca) by ietf-mx with esmtp (Exim 4.12) id 194w63-0007OY-00 for cfrg@ietf.org; Mon, 14 Apr 2003 01:01:35 -0400 X-Envelope-To: cfrg@ietf.org Received: (from news@localhost) by mx2.cypherpunks.ca (8.11.0/8.11.0) id h3E4aAL05800 for cfrg@ietf.org; Sun, 13 Apr 2003 21:36:10 -0700 To: cfrg@ietf.org Path: not-for-mail From: daw@mozart.cs.berkeley.edu (David Wagner) Newsgroups: isaac.lists.ietf-cfrg Date: 14 Apr 2003 04:36:10 GMT Organization: University of California, Berkeley Lines: 35 Distribution: isaac Message-ID: NNTP-Posting-Host: mozart.cs.berkeley.edu X-Trace: abraham.cs.berkeley.edu 1050294970 5754 128.32.153.211 (14 Apr 2003 04:36:10 GMT) X-Complaints-To: news@abraham.cs.berkeley.edu NNTP-Posting-Date: 14 Apr 2003 04:36:10 GMT X-Newsreader: trn 4.0-test74 (May 26, 2000) Originator: daw@mozart.cs.berkeley.edu (David Wagner) Subject: [Cfrg] Authenticated encryption Sender: cfrg-admin@ietf.org Errors-To: cfrg-admin@ietf.org X-BeenThere: cfrg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Crypto Forum Research Group List-Post: List-Help: List-Subscribe: , I'd like to report the availability of two research papers on the subject of authenticated encryption, which might be relevant to this forum. Any feedback you might have would be welcomed. A Conventional Authenticated-Encryption Mode M. Bellare and P. Rogaway and D. Wagner http://www.cs.berkeley.edu/~daw/papers/eax.html Abstract. We propose a block-cipher mode of operation, EAX, for authenticated-encryption with associated-data (AEAD). Given a nonce $N$, a message $M$, and a header $H$, the mode protects the privacy of $M$ and the authenticity of both $M$ and $H$. Strings $N,M,H \in \{0,1\}^*$ are arbitrary, and the mode uses $2\lceil M/n \rceil + \lceil H/n\rceil + \lceil N/n\rceil$ block-cipher calls when these strings are nonempty and $n$ is the block length of the underlying block cipher. Among EAX's characteristics are that it is on-line (the length of a message isn't needed to begin processing it) and a fixed header can be pre-processed, effectively removing the per-message cost of binding it to the ciphertext. EAX is obtained by instantiating a simple generic-composition method, EAX2, and then collapsing its two keys into one. EAX is provably secure under a standard complexity-theoretic assumption. EAX is an alternative to CCM [19], and is likewise patent-free. A Critique of CCM P. Rogaway and D. Wagner http://www.cs.berkeley.edu/~daw/papers/ccm.html Abstract. CCM is a conventional authenticated-encryption scheme obtained from a 128-bit block cipher. The mechanism has been adopted as the mandatory encryption algorithm in an IEEE 802.11 draft standard [15], and its use has been proposed more broadly [16,17]. In this note we point out a number of limitations of CCM. A related note provides an alternative to CCM [5]. _______________________________________________ Cfrg mailing list Cfrg@ietf.org https://www1.ietf.org/mailman/listinfo/cfrg From mailnull@www1.ietf.org Wed Apr 16 21:10:28 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA23090 for ; Wed, 16 Apr 2003 21:10:28 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3H1JKQ07918 for cfrg-archive@odin.ietf.org; Wed, 16 Apr 2003 21:19:20 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3H1JK807915 for ; Wed, 16 Apr 2003 21:19:20 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA23050 for ; Wed, 16 Apr 2003 21:09:58 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 195xwx-0004bT-00 for cfrg-web-archive@ietf.org; Wed, 16 Apr 2003 21:12:27 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 195xwx-0004bP-00 for cfrg-web-archive@ietf.org; Wed, 16 Apr 2003 21:12:27 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3H1I8807873; Wed, 16 Apr 2003 21:18:08 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3G2xQ828466 for ; Tue, 15 Apr 2003 22:59:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA20572 for ; Tue, 15 Apr 2003 22:50:31 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 195d2j-00067N-00 for cfrg@ietf.org; Tue, 15 Apr 2003 22:53:01 -0400 Received: from w168.z205158144.scl-ca.dsl.cnc.net ([205.158.144.168] helo=mail.securesoftware.com) by ietf-mx with esmtp (Exim 4.12) id 195d2j-00067E-00 for cfrg@ietf.org; Tue, 15 Apr 2003 22:53:01 -0400 Received: from securesoftware.com (pcp732336pcs.arlngt01.va.comcast.net [68.49.161.231]) by mail.securesoftware.com (Postfix) with ESMTP id CFE4F1345CF for ; Tue, 15 Apr 2003 22:53:29 -0400 (EDT) Date: Tue, 15 Apr 2003 22:52:36 -0400 Subject: Re: [Cfrg] Authenticated encryption Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) From: John Viega To: cfrg@ietf.org Content-Transfer-Encoding: 7bit In-Reply-To: Message-Id: <7AB89324-6FB6-11D7-971F-000A959CFBBA@securesoftware.com> X-Mailer: Apple Mail (2.552) Content-Transfer-Encoding: 7bit Sender: cfrg-admin@ietf.org Errors-To: cfrg-admin@ietf.org X-BeenThere: cfrg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Crypto Forum Research Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Nice work! I'd also like to point people to another new authenticated encryption mode called CWC: http://www.ietf.org/internet-drafts/draft-irtf-cfrg-cwc-00.txt The main thing that CWC offers that other such modes don't is that is that it is simultaneously patent-free, provably-secure and parallelizable (meaning that it will be suitable for securing data over 10 gigabit/sec links). We will be releasing the full version of our paper (including security proofs) shortly. There are some minor issues we'll fix in the next version of the draft, such as using bit lengths to refer to CWC instances, instead of octet lengths (i.e., AES-CWC-256 instead of AES-CWC-32). John _______________________________________________ Cfrg mailing list Cfrg@ietf.org https://www1.ietf.org/mailman/listinfo/cfrg From mailnull@www1.ietf.org Tue Apr 22 13:50:07 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18107 for ; Tue, 22 Apr 2003 13:50:07 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3MI1kF26026 for cfrg-archive@odin.ietf.org; Tue, 22 Apr 2003 14:01:46 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3MI1k826023 for ; Tue, 22 Apr 2003 14:01:46 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18079 for ; Tue, 22 Apr 2003 13:49:36 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1981vx-0003Z1-00 for cfrg-web-archive@ietf.org; Tue, 22 Apr 2003 13:51:57 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1981vx-0003Yx-00 for cfrg-web-archive@ietf.org; Tue, 22 Apr 2003 13:51:57 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3MHw6825777; Tue, 22 Apr 2003 14:00:07 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3MHuj825659 for ; Tue, 22 Apr 2003 13:56:45 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17903 for ; Tue, 22 Apr 2003 13:44:36 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1981r7-0003Vp-00 for cfrg@ietf.org; Tue, 22 Apr 2003 13:46:57 -0400 Received: from sottmxssm.entrust.com ([216.191.252.10]) by ietf-mx with esmtp (Exim 4.12) id 1981r6-0003VL-00 for cfrg@ietf.org; Tue, 22 Apr 2003 13:46:56 -0400 Received: from sottguard01.entrust.com ([10.4.61.249]) by sottmxssm.entrust.com (Switch-2.2.6/Switch-2.2.4) with SMTP id V3MH27NB12834 for ; Tue, 22 Apr 2003 13:43:23 -0400 Received: (qmail 21021 invoked by uid 64014); 22 Apr 2003 17:44:48 -0000 Received: from robert.zuccherato@entrust.com by sottguard01.entrust.com with AmikaGuardian-Server-1.1.2 (Processed in 0.267455 secs); 22 Apr 2003 17:44:48 -0000 Received: from unknown (HELO SOTTMXS01.entrust.com) (10.4.61.7) by 10.4.61.249 with SMTP; 22 Apr 2003 17:44:48 -0000 Received: by sottmxs01.entrust.com with Internet Mail Service (5.5.2656.59) id <2ZN4X19R>; Tue, 22 Apr 2003 13:46:13 -0400 Message-ID: From: Robert Zuccherato To: cfrg@ietf.org Date: Tue, 22 Apr 2003 13:46:12 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C308F7.10904320" Subject: [Cfrg] Final CFP: SAC 2003 - Deadline May 2nd Sender: cfrg-admin@ietf.org Errors-To: cfrg-admin@ietf.org X-BeenThere: cfrg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Crypto Forum Research Group List-Post: List-Help: List-Subscribe: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C308F7.10904320 Content-Type: text/plain; charset="iso-8859-1" FINAL CALL FOR PAPERS - SUBMISSIONS DUE MAY 2, 2003 Online submission is now available at http://www.scs.carleton.ca/~sac2003/cyberchair.html. See http://www.scs.carleton.ca/~sac2003/ for further information. ____________________________________________________________________________ _______ SAC 2003 Tenth Annual Workshop on SELECTED AREAS IN CRYPTOGRAPHY August 14 & 15, 2003 Carleton University Ottawa, Ontario, Canada The Workshop on Selected Areas in Cryptography (SAC) is an annual conference dedicated to specific themes in the area of cryptographic system design and analysis. Authors are encouraged to submit original papers related to the themes for the SAC 2003 workshop: * Design and analysis of symmetric key cryptosystems. * Primitives for symmetric key cryptography, including block and stream ciphers, hash functions, and MACs. * Efficient implementation of cryptographic systems in public and symmetric key cryptography. * Cryptographic solutions for Web services security. * Cryptography and security of trusted and distributed systems. In addition to talks from accepted submissions, SAC 2003 will include seminars from invited speakers: * Nicolas Courtois, Schlumberger Smart Cards * Virgil D. Gligor, University of Maryland This year's workshop is chaired by Mitsuru Matsui from Mitsubishi Electric, Japan, and Robert Zuccherato from Entrust, Inc., Canada. Questions regarding the conference should be sent to sac2003@scs.carleton.ca . Online submission is now available at http://www.scs.carleton.ca/~sac2003/cyberchair.html Important Dates Paper Submission Deadline May 2, 2003 Notification of Acceptance Jun. 18, 2003 Early Registration Deadline Jul. 11, 2003 Workshop Aug. 14 and 15, 2003 Proceedings Version Deadline Sep. 14, 2003 ------_=_NextPart_001_01C308F7.10904320 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Final CFP: SAC 2003 - Deadline May 2nd

FINAL CALL FOR PAPERS - = SUBMISSIONS DUE MAY 2, 2003
Online submission is now = available at http://www.scs.carleton.ca/~sac2003/cyberchair.html.
See http://www.scs.carleton.ca/~sac2003/ for further = information.
___________________________________________________________________= ________________
SAC 2003
Tenth Annual Workshop on = SELECTED AREAS IN CRYPTOGRAPHY
August 14 & 15, 2003
Carleton University
Ottawa, Ontario, Canada
 
The Workshop on Selected Areas = in Cryptography (SAC) is an annual conference dedicated to specific = themes in the area of cryptographic system design and analysis. Authors = are encouraged to submit original papers related to the themes for the = SAC 2003 workshop:

*       Design and analysis of = symmetric key cryptosystems.
*       Primitives for symmetric key = cryptography, including block and stream ciphers, hash functions, and = MACs.
*       Efficient implementation of = cryptographic systems in public and symmetric key cryptography.
*       Cryptographic solutions for = Web services security.
*       Cryptography and security of = trusted and distributed systems.
 
In addition to talks from = accepted submissions, SAC 2003 will include seminars from invited = speakers:
*   Nicolas Courtois, = Schlumberger Smart Cards
*   Virgil D. Gligor, = University of Maryland

This year's workshop is chaired = by Mitsuru Matsui from Mitsubishi Electric, Japan, and Robert = Zuccherato from Entrust, Inc., Canada.

Questions regarding the = conference should be sent to sac2003@scs.carleton.ca .

Online submission is now = available at http://www.scs.carleton.ca/~sac2003/cyberchair.html

Important Dates
Paper Submission = Deadline     May 2, 2003
Notification of = Acceptance    Jun. 18, 2003
Early Registration = Deadline   Jul. 11, 2003
Workshop          = ;            = Aug. 14 and 15, 2003 
Proceedings Version = Deadline  Sep. 14, 2003


------_=_NextPart_001_01C308F7.10904320-- _______________________________________________ Cfrg mailing list Cfrg@ietf.org https://www1.ietf.org/mailman/listinfo/cfrg From mailnull@www1.ietf.org Wed Apr 23 14:49:10 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00279 for ; Wed, 23 Apr 2003 14:49:10 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3NJ1J118767 for cfrg-archive@odin.ietf.org; Wed, 23 Apr 2003 15:01:19 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3NJ1J818764 for ; Wed, 23 Apr 2003 15:01:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00238 for ; Wed, 23 Apr 2003 14:48:39 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 198PKd-0006N3-00 for cfrg-web-archive@ietf.org; Wed, 23 Apr 2003 14:50:59 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 198PKd-0006Mz-00 for cfrg-web-archive@ietf.org; Wed, 23 Apr 2003 14:50:59 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3NIwq818513; Wed, 23 Apr 2003 14:58:52 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3NHQ7811416 for ; Wed, 23 Apr 2003 13:26:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26740 for ; Wed, 23 Apr 2003 13:13:30 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 198NqX-0005f8-00 for cfrg@ietf.org; Wed, 23 Apr 2003 13:15:49 -0400 Received: from frogadmin.yi.org ([80.65.224.85] helo=Gilgamesh) by ietf-mx with esmtp (Exim 4.12) id 198NqW-0005f4-00 for cfrg@ietf.org; Wed, 23 Apr 2003 13:15:48 -0400 Received: from Spooler by Gilgamesh (Mercury/32 v3.31) ID MO035706; 23 Apr 03 19:13:21 +0200 Received: from spooler by frogadmin.yi.org (Mercury/32 v3.31); 23 Apr 03 19:13:14 +0200 Received: from gilgamesh (127.0.0.1) by Frog's Mercury SMTP (Server) (Mercury/32 v3.31) ID MG0356E7; 23 Apr 03 19:11:26 +0200 To: cfrg@ietf.org Date: 23 Apr 2003 17:11:26 -0000 Message-ID: From: Martin4 Comments: This message probably did not originate from the above address. It was automatically remailed by one or more anonymous mail services. You should NEVER trust ANY address on Usenet ANYWAYS: use PGP !!! Get information about complaints from the URL below X-Remailer-Contact: http://80.65.224.85/ ,, Subject: [Cfrg] Re: Anyone looked at Mithra ? Sender: cfrg-admin@ietf.org Errors-To: cfrg-admin@ietf.org X-BeenThere: cfrg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Crypto Forum Research Group List-Post: List-Help: List-Subscribe: , Seen on sci.crypt, subject: "Re: Anyone looked at Mithra ?": "Rex Stewart" escreveu na mensagem: >A new.. protocol is discussed in this month's Doctor Dobbs Journal.. >The protocol is named Mithra, and is designed.. to detect MITM attacks. "Mads Rasmussen" wrote: > The source is available from > http://www.ddj.com/ftp/2003/2003_05/ > The protocol is very ad hoc ... We see that a dictionary attack > would be very easy assuming that the IP adresses are known. http://groups.google.com/groups?selm=b85tk1$sb3$1@newsreader.mailgate.org _______________________________________________ Cfrg mailing list Cfrg@ietf.org https://www1.ietf.org/mailman/listinfo/cfrg From mailnull@www1.ietf.org Wed Apr 23 15:13:45 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02174 for ; Wed, 23 Apr 2003 15:13:45 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3NJPt320932 for cfrg-archive@odin.ietf.org; Wed, 23 Apr 2003 15:25:55 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3NJPs820929 for ; Wed, 23 Apr 2003 15:25:54 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02118 for ; Wed, 23 Apr 2003 15:13:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 198PiQ-0006YK-00 for cfrg-web-archive@ietf.org; Wed, 23 Apr 2003 15:15:34 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 198PiP-0006YH-00 for cfrg-web-archive@ietf.org; Wed, 23 Apr 2003 15:15:33 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3NJO6820821; Wed, 23 Apr 2003 15:24:06 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3NJNt820786 for ; Wed, 23 Apr 2003 15:23:55 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01897 for ; Wed, 23 Apr 2003 15:11:15 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 198PgV-0006Xl-00 for cfrg@ietf.org; Wed, 23 Apr 2003 15:13:35 -0400 Received: from [200.182.84.33] (helo=sparta.opencs.com.br) by ietf-mx with smtp (Exim 4.12) id 198PgS-0006XX-00 for cfrg@ietf.org; Wed, 23 Apr 2003 15:13:33 -0400 Received: (qmail 26891 invoked from network); 23 Apr 2003 17:44:07 -0000 Received: from unknown (HELO olimpia.opencs.com.br) (200.182.84.62) by sparta.opencs.com.br with SMTP; 23 Apr 2003 17:44:07 -0000 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RES: [Cfrg] Re: Anyone looked at Mithra ? X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0 Date: Wed, 23 Apr 2003 16:18:05 -0300 Message-ID: <23F980CFF4C45B4792FFF3CE015C541A090FD9@olimpia.opencs.com.br> Thread-Topic: [Cfrg] Re: Anyone looked at Mithra ? thread-index: AcMJy9a6nonHvMJDSG6c+JQlxRByswAAIz+w From: "Mads Rasmussen" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h3NJNt820787 Sender: cfrg-admin@ietf.org Errors-To: cfrg-admin@ietf.org X-BeenThere: cfrg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Crypto Forum Research Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit > -----Mensagem original----- > De: Martin4 [mailto:ANON@frogadmin.yi.org] > Enviada em: quarta-feira, 23 de abril de 2003 14:11 > Para: cfrg@ietf.org > Assunto: [Cfrg] Re: Anyone looked at Mithra ? > > Seen on sci.crypt, subject: "Re: Anyone looked at Mithra ?": > > "Rex Stewart" escreveu na mensagem: > >A new.. protocol is discussed in this month's Doctor Dobbs Journal.. > >The protocol is named Mithra, and is designed.. to detect MITM attacks. > > "Mads Rasmussen" wrote: > > The source is available from > > http://www.ddj.com/ftp/2003/2003_05/ > > The protocol is very ad hoc ... We see that a dictionary attack > > would be very easy assuming that the IP adresses are known. > > http://groups.google.com/groups?selm=b85tk1$sb3$1@newsreader.mailgate.or g This should not have appeared here, the protocol is not very interesting Sorry Mads _______________________________________________ Cfrg mailing list Cfrg@ietf.org https://www1.ietf.org/mailman/listinfo/cfrg From mailnull@www1.ietf.org Wed Apr 23 21:01:23 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16740 for ; Wed, 23 Apr 2003 21:01:23 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3O13j514246 for cfrg-archive@odin.ietf.org; Wed, 23 Apr 2003 21:03:45 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3O13j814243 for ; Wed, 23 Apr 2003 21:03:45 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16705 for ; Wed, 23 Apr 2003 21:00:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 198V8q-0001c8-00 for cfrg-web-archive@ietf.org; Wed, 23 Apr 2003 21:03:12 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 198V8p-0001c5-00 for cfrg-web-archive@ietf.org; Wed, 23 Apr 2003 21:03:11 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3O12j814155; Wed, 23 Apr 2003 21:02:45 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3O10L814019 for ; Wed, 23 Apr 2003 21:00:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16649 for ; Wed, 23 Apr 2003 20:57:28 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 198V5X-0001aw-00 for cfrg@ietf.org; Wed, 23 Apr 2003 20:59:47 -0400 Received: from abraham.cs.berkeley.edu ([128.32.37.170] helo=mx2.cypherpunks.ca) by ietf-mx with esmtp (Exim 4.12) id 198V5T-0001ab-00 for cfrg@ietf.org; Wed, 23 Apr 2003 20:59:43 -0400 X-Envelope-To: cfrg@ietf.org Received: (from news@localhost) by mx2.cypherpunks.ca (8.11.0/8.11.0) id h3O0YKU29915 for cfrg@ietf.org; Wed, 23 Apr 2003 17:34:20 -0700 To: cfrg@ietf.org Path: not-for-mail From: daw@mozart.cs.berkeley.edu (David Wagner) Newsgroups: isaac.lists.ietf-cfrg Subject: Re: [Cfrg] Re: Anyone looked at Mithra ? Date: 24 Apr 2003 00:34:20 GMT Organization: University of California, Berkeley Lines: 2 Distribution: isaac Message-ID: References: NNTP-Posting-Host: mozart.cs.berkeley.edu X-Trace: abraham.cs.berkeley.edu 1051144460 29907 128.32.153.211 (24 Apr 2003 00:34:20 GMT) X-Complaints-To: news@abraham.cs.berkeley.edu NNTP-Posting-Date: 24 Apr 2003 00:34:20 GMT X-Newsreader: trn 4.0-test74 (May 26, 2000) Originator: daw@mozart.cs.berkeley.edu (David Wagner) Sender: cfrg-admin@ietf.org Errors-To: cfrg-admin@ietf.org X-BeenThere: cfrg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Crypto Forum Research Group List-Post: List-Help: List-Subscribe: , Yeah, I looked. It looks like a silly protocol to me. It's not worth anyone's time. _______________________________________________ Cfrg mailing list Cfrg@ietf.org https://www1.ietf.org/mailman/listinfo/cfrg From mailnull@www1.ietf.org Thu Apr 24 09:54:29 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16439 for ; Thu, 24 Apr 2003 09:54:29 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3ODv7h11945 for cfrg-archive@odin.ietf.org; Thu, 24 Apr 2003 09:57:07 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3ODv7811942 for ; Thu, 24 Apr 2003 09:57:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16430 for ; Thu, 24 Apr 2003 09:53:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 198hCy-00064e-00 for cfrg-web-archive@ietf.org; Thu, 24 Apr 2003 09:56:16 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 198hCy-00064b-00 for cfrg-web-archive@ietf.org; Thu, 24 Apr 2003 09:56:16 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3ODt4811888; Thu, 24 Apr 2003 09:55:04 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3ODrX811817 for ; Thu, 24 Apr 2003 09:53:33 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16361 for ; Thu, 24 Apr 2003 09:50:24 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 198h9X-00063g-00 for cfrg@ietf.org; Thu, 24 Apr 2003 09:52:43 -0400 Received: from sj-core-2.cisco.com ([171.71.177.254]) by ietf-mx with esmtp (Exim 4.12) id 198h9W-000638-00 for cfrg@ietf.org; Thu, 24 Apr 2003 09:52:42 -0400 Received: from MCGREW-W2K.cisco.com (stealth-10-34-251-100.cisco.com [10.34.251.100]) by sj-core-2.cisco.com (8.12.6/8.12.6) with SMTP id h3ODqaIE008818; Thu, 24 Apr 2003 06:52:37 -0700 (PDT) Message-Id: <4.3.2.7.2.20030424063659.02fd3ef0@mira-sjcm-1.cisco.com> X-Sender: mcgrew@mira-sjcm-1.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 24 Apr 2003 06:52:35 -0700 To: John Viega From: David Mcgrew Subject: Re: [Cfrg] Authenticated encryption Cc: cfrg@ietf.org In-Reply-To: <7AB89324-6FB6-11D7-971F-000A959CFBBA@securesoftware.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: cfrg-admin@ietf.org Errors-To: cfrg-admin@ietf.org X-BeenThere: cfrg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Crypto Forum Research Group List-Post: List-Help: List-Subscribe: , John, At 10:52 PM 4/15/2003 -0400, John Viega wrote: >Nice work! I'd also like to point people to another new authenticated >encryption mode called CWC: > > http://www.ietf.org/internet-drafts/draft-irtf-cfrg-cwc-00.txt > >The main thing that CWC offers that other such modes don't is >that is that it is simultaneously patent-free, provably-secure and >parallelizable (meaning that it will be suitable for securing data over >10 gigabit/sec links). this is the great property of CWC. The inability to pipeline chained modes like CBC or CBC-MAC makes those modes cost significantly more in hardware at speeds like 10gbps. I'm not sure exactly what the speed limit for those modes are (and I'd be glad to hear from someone on the list with a hardware design background), but intuitively, I'd expect that an AES mode that can be pipelined can go ten times as fast as one that is chained, since I'd guess that a single AES round defines the length of the critical path in the AES computation. For others on the list who may wonder what CWC has that UST and TMMH don't (besides a more compact description :-), another good property of CWC is that its key size is small. This is especially important for hardware implementations, since the operation of fetching the correct decryption/authentication key can be a significant bottleneck in a high-speed system. David >We will be releasing the full version of our paper (including security >proofs) shortly. > >There are some minor issues we'll fix in the next version of the draft, >such as using bit lengths to refer to CWC instances, instead of octet >lengths (i.e., AES-CWC-256 instead of AES-CWC-32). > >John > >_______________________________________________ >Cfrg mailing list >Cfrg@ietf.org >https://www1.ietf.org/mailman/listinfo/cfrg _______________________________________________ Cfrg mailing list Cfrg@ietf.org https://www1.ietf.org/mailman/listinfo/cfrg From mailnull@www1.ietf.org Thu Apr 24 13:31:35 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24524 for ; Thu, 24 Apr 2003 13:31:35 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3OHYHE27914 for cfrg-archive@odin.ietf.org; Thu, 24 Apr 2003 13:34:17 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3OHYH827911 for ; Thu, 24 Apr 2003 13:34:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24511 for ; Thu, 24 Apr 2003 13:31:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 198kb4-0007Z4-00 for cfrg-web-archive@ietf.org; Thu, 24 Apr 2003 13:33:22 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 198kb4-0007Z0-00 for cfrg-web-archive@ietf.org; Thu, 24 Apr 2003 13:33:22 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3OHVe827813; Thu, 24 Apr 2003 13:31:40 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3OHUa827732 for ; Thu, 24 Apr 2003 13:30:36 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24407 for ; Thu, 24 Apr 2003 13:27:24 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 198kXW-0007Y0-00 for cfrg@ietf.org; Thu, 24 Apr 2003 13:29:42 -0400 Received: from [208.10.194.50] (helo=sjcxch01.hifn.com) by ietf-mx with esmtp (Exim 4.12) id 198kXW-0007Xw-00 for cfrg@ietf.org; Thu, 24 Apr 2003 13:29:42 -0400 Received: by SJCXCH01.hifn.com with Internet Mail Service (5.5.2653.19) id <1M1ZYS20>; Thu, 24 Apr 2003 10:30:53 -0700 Message-ID: <51C7002B020CD411824E009027C469F7F3FF8F@cldxch01.hifn.com> From: Doug Whiting To: "'David Mcgrew'" , John Viega Cc: cfrg@ietf.org Subject: RE: [Cfrg] Authenticated encryption Date: Thu, 24 Apr 2003 10:28:38 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: cfrg-admin@ietf.org Errors-To: cfrg-admin@ietf.org X-BeenThere: cfrg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Crypto Forum Research Group List-Post: List-Help: List-Subscribe: , On the hardware speed issue, you can actually go even faster (at the expense of more area) by building multiple, completely independent AES units for counter mode, or polynomial evaluators for CWC's polynomial MAC. That's what's so nice about parallelizable modes in hardware -- the algorithms themselves are simply not the bottleneck. Basically, what happens at very high speed, for CWC or anything else, is that the difficult part in hardware becomes simply "feeding" the engines. But, at 10 Gbps, almost anything you do will have this characteristic. You don't build 10G systems to save gates :-) By contrast, chained modes such as CBC cannot be paralellized regardless of the amount of hardware you throw at it. > -----Original Message----- > From: David Mcgrew [mailto:mcgrew@cisco.com] > Sent: Thursday, April 24, 2003 6:53 AM > To: John Viega > Cc: cfrg@ietf.org > Subject: Re: [Cfrg] Authenticated encryption > > > John, > > At 10:52 PM 4/15/2003 -0400, John Viega wrote: > >Nice work! I'd also like to point people to another new > authenticated > >encryption mode called CWC: > > > > > http://www.ietf.org/internet-drafts/draft-irtf-cfrg-cwc-00.txt > > > >The main thing that CWC offers that other such modes don't is > >that is that it is simultaneously patent-free, provably-secure and > >parallelizable (meaning that it will be suitable for > securing data over > >10 gigabit/sec links). > > this is the great property of CWC. The inability to pipeline > chained modes > like CBC or CBC-MAC makes those modes cost significantly more > in hardware > at speeds like 10gbps. I'm not sure exactly what the speed > limit for > those modes are (and I'd be glad to hear from someone on the > list with a > hardware design background), but intuitively, I'd expect that > an AES mode > that can be pipelined can go ten times as fast as one that is > chained, > since I'd guess that a single AES round defines the length of > the critical > path in the AES computation. > > For others on the list who may wonder what CWC has that UST > and TMMH don't > (besides a more compact description :-), another good > property of CWC is > that its key size is small. This is especially important for > hardware > implementations, since the operation of fetching the correct > decryption/authentication key can be a significant bottleneck in a > high-speed system. > > David > > > >We will be releasing the full version of our paper > (including security > >proofs) shortly. > > > >There are some minor issues we'll fix in the next version of > the draft, > >such as using bit lengths to refer to CWC instances, instead of octet > >lengths (i.e., AES-CWC-256 instead of AES-CWC-32). > > > >John > > > >_______________________________________________ > >Cfrg mailing list > >Cfrg@ietf.org > >https://www1.ietf.org/mailman/listinfo/cfrg > > _______________________________________________ > Cfrg mailing list > Cfrg@ietf.org > https://www1.ietf.org/mailman/listinfo/cfrg > _______________________________________________ Cfrg mailing list Cfrg@ietf.org https://www1.ietf.org/mailman/listinfo/cfrg From mailnull@www1.ietf.org Thu Apr 24 14:06:04 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25620 for ; Thu, 24 Apr 2003 14:06:04 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3OI8lf31296 for cfrg-archive@odin.ietf.org; Thu, 24 Apr 2003 14:08:47 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3OI8k831293 for ; Thu, 24 Apr 2003 14:08:46 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25593 for ; Thu, 24 Apr 2003 14:05:33 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 198l8R-0007nG-00 for cfrg-web-archive@ietf.org; Thu, 24 Apr 2003 14:07:51 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 198l8R-0007nD-00 for cfrg-web-archive@ietf.org; Thu, 24 Apr 2003 14:07:51 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3OI4A830263; Thu, 24 Apr 2003 14:04:10 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3OI3E830174 for ; Thu, 24 Apr 2003 14:03:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25349 for ; Thu, 24 Apr 2003 14:00:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 198l35-0007ke-00 for cfrg@ietf.org; Thu, 24 Apr 2003 14:02:19 -0400 Received: from h-135-207-24-16.research.att.com ([135.207.24.16] helo=linux.research.att.com) by ietf-mx with esmtp (Exim 4.12) id 198l35-0007k5-00 for cfrg@ietf.org; Thu, 24 Apr 2003 14:02:19 -0400 Received: from bigmail.research.att.com (bigmail.research.att.com [135.207.30.101]) by linux.research.att.com (8.12.8/8.12.8) with ESMTP id h3OI2llN006845; Thu, 24 Apr 2003 14:02:47 -0400 Received: from berkshire.research.att.com (sigaba.research.att.com [135.207.23.169]) by bigmail.research.att.com (8.11.6+Sun/8.11.6) with ESMTP id h3OI1qV09741; Thu, 24 Apr 2003 14:01:52 -0400 (EDT) Received: from research.att.com (localhost [127.0.0.1]) by berkshire.research.att.com (Postfix) with ESMTP id 43FE77B4D; Thu, 24 Apr 2003 14:01:52 -0400 (EDT) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: "Steven M. Bellovin" To: Doug Whiting Cc: "'David Mcgrew'" , John Viega , cfrg@ietf.org Subject: Re: [Cfrg] Authenticated encryption In-Reply-To: Your message of "Thu, 24 Apr 2003 10:28:38 PDT." <51C7002B020CD411824E009027C469F7F3FF8F@cldxch01.hifn.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 24 Apr 2003 14:01:52 -0400 Message-Id: <20030424180152.43FE77B4D@berkshire.research.att.com> Sender: cfrg-admin@ietf.org Errors-To: cfrg-admin@ietf.org X-BeenThere: cfrg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Crypto Forum Research Group List-Post: List-Help: List-Subscribe: , In message <51C7002B020CD411824E009027C469F7F3FF8F@cldxch01.hifn.com>, Doug Whi ting writes: >On the hardware speed issue, you can actually go even faster (at the expense >of more area) by building multiple, completely independent AES units for >counter mode, or polynomial evaluators for CWC's polynomial MAC. That's >what's so nice about parallelizable modes in hardware -- the algorithms >themselves are simply not the bottleneck. Basically, what happens at very >high speed, for CWC or anything else, is that the difficult part in hardware >becomes simply "feeding" the engines. But, at 10 Gbps, almost anything you >do will have this characteristic. You don't build 10G systems to save gates >:-) Right. The problem with counter mode is that (a) we don't have MACs that are correspondingly fast, and (b) counter mode desparately needs a MAC. That's why we need things like CWC. --Steve Bellovin, http://www.research.att.com/~smb (me) http://www.wilyhacker.com (2nd edition of "Firewalls" book) _______________________________________________ Cfrg mailing list Cfrg@ietf.org https://www1.ietf.org/mailman/listinfo/cfrg From mailnull@www1.ietf.org Thu Apr 24 16:31:56 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02142 for ; Thu, 24 Apr 2003 16:31:56 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3OKYgu08456 for cfrg-archive@odin.ietf.org; Thu, 24 Apr 2003 16:34:42 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3OKYg808453 for ; Thu, 24 Apr 2003 16:34:42 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02095 for ; Thu, 24 Apr 2003 16:31:26 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 198nPc-00014o-00 for cfrg-web-archive@ietf.org; Thu, 24 Apr 2003 16:33:44 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 198nPc-00014l-00 for cfrg-web-archive@ietf.org; Thu, 24 Apr 2003 16:33:44 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3OKWi808315; Thu, 24 Apr 2003 16:32:44 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3OKVv808271 for ; Thu, 24 Apr 2003 16:31:57 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01973 for ; Thu, 24 Apr 2003 16:28:41 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 198nMx-000133-00 for cfrg@ietf.org; Thu, 24 Apr 2003 16:30:59 -0400 Received: from lennon.multicasttech.com ([63.105.122.7] helo=multicasttech.com ident=root) by ietf-mx with esmtp (Exim 4.12) id 198nMx-000130-00 for cfrg@ietf.org; Thu, 24 Apr 2003 16:30:59 -0400 Received: from [68.100.8.94] (account marshall_eubanks HELO multicasttech.com) by multicasttech.com (CommuniGate Pro SMTP 3.4.8) with ESMTP id 1678400; Thu, 24 Apr 2003 16:31:25 -0400 Date: Thu, 24 Apr 2003 16:31:28 -0400 Subject: Re: [Cfrg] Authenticated encryption Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: cfrg@ietf.org To: John Viega From: Marshall Eubanks In-Reply-To: <7AB89324-6FB6-11D7-971F-000A959CFBBA@securesoftware.com> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) Content-Transfer-Encoding: 7bit Sender: cfrg-admin@ietf.org Errors-To: cfrg-admin@ietf.org X-BeenThere: cfrg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Crypto Forum Research Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Dear John; Do you know where I can get an on line version of the CWC reference : [CWC] Kohno, T., Viega, J. and Whiting, D. "A Carter-Wegman and Counter-Based Dual-Use Mode (CWC)". Manuscript, February, 2003. Or is this the shortly to appear paper you refer to ? Regards Marshall Eubanks On Tuesday, April 15, 2003, at 10:52 PM, John Viega wrote: > Nice work! I'd also like to point people to another new authenticated > encryption mode called CWC: > > http://www.ietf.org/internet-drafts/draft-irtf-cfrg-cwc-00.txt > > The main thing that CWC offers that other such modes don't is > that is that it is simultaneously patent-free, provably-secure and > parallelizable (meaning that it will be suitable for securing data over > 10 gigabit/sec links). > > We will be releasing the full version of our paper (including security > proofs) shortly. > > There are some minor issues we'll fix in the next version of the draft, > such as using bit lengths to refer to CWC instances, instead of octet > lengths (i.e., AES-CWC-256 instead of AES-CWC-32). > > John > > _______________________________________________ > Cfrg mailing list > Cfrg@ietf.org > https://www1.ietf.org/mailman/listinfo/cfrg > T.M. Eubanks Multicast Technologies, Inc. e-mail : tme@multicasttech.com http://www.multicasttech.com Test your network for multicast : http://www.multicasttech.com/mt/ _______________________________________________ Cfrg mailing list Cfrg@ietf.org https://www1.ietf.org/mailman/listinfo/cfrg From mailnull@www1.ietf.org Fri Apr 25 09:15:51 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07742 for ; Fri, 25 Apr 2003 09:15:51 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3PDIv724885 for cfrg-archive@odin.ietf.org; Fri, 25 Apr 2003 09:18:57 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3PDIv824882 for ; Fri, 25 Apr 2003 09:18:57 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07694 for ; Fri, 25 Apr 2003 09:15:20 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 199357-0000TQ-00 for cfrg-web-archive@ietf.org; Fri, 25 Apr 2003 09:17:37 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 199357-0000TM-00 for cfrg-web-archive@ietf.org; Fri, 25 Apr 2003 09:17:37 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3PDHp824785; Fri, 25 Apr 2003 09:17:51 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3OKqu810099 for ; Thu, 24 Apr 2003 16:52:56 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02704 for ; Thu, 24 Apr 2003 16:49:39 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 198nhG-0001C1-00 for cfrg@ietf.org; Thu, 24 Apr 2003 16:51:58 -0400 Received: from w168.z205158144.scl-ca.dsl.cnc.net ([205.158.144.168] helo=mail.securesoftware.com) by ietf-mx with esmtp (Exim 4.12) id 198nhF-0001Bw-00 for cfrg@ietf.org; Thu, 24 Apr 2003 16:51:57 -0400 Received: from securesoftware.com (pcp732336pcs.arlngt01.va.comcast.net [68.49.161.231]) by mail.securesoftware.com (Postfix) with ESMTP id 3609F1345CE; Thu, 24 Apr 2003 16:52:40 -0400 (EDT) Date: Thu, 24 Apr 2003 16:51:45 -0400 Subject: Re: [Cfrg] Authenticated encryption Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: cfrg@ietf.org To: Marshall Eubanks From: John Viega In-Reply-To: Message-Id: <8FADE95B-7696-11D7-AFE6-000A959CFBBA@securesoftware.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) Content-Transfer-Encoding: 7bit Sender: cfrg-admin@ietf.org Errors-To: cfrg-admin@ietf.org X-BeenThere: cfrg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Crypto Forum Research Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Indeed, this is the paper we're preparing. We have just a bit more cosmetic work to do, and should be making it available some time next week. John On Thursday, April 24, 2003, at 04:31 PM, Marshall Eubanks wrote: > Dear John; > > Do you know where I can get an on line version of the CWC reference : > > [CWC] Kohno, T., Viega, J. and Whiting, D. "A > Carter-Wegman > and Counter-Based Dual-Use Mode (CWC)". Manuscript, > February, 2003. > > Or is this the shortly to appear paper you refer to ? > > Regards > Marshall Eubanks > > On Tuesday, April 15, 2003, at 10:52 PM, John Viega wrote: > >> Nice work! I'd also like to point people to another new authenticated >> encryption mode called CWC: >> >> http://www.ietf.org/internet-drafts/draft-irtf-cfrg-cwc-00.txt >> >> The main thing that CWC offers that other such modes don't is >> that is that it is simultaneously patent-free, provably-secure and >> parallelizable (meaning that it will be suitable for securing data >> over >> 10 gigabit/sec links). >> >> We will be releasing the full version of our paper (including security >> proofs) shortly. >> >> There are some minor issues we'll fix in the next version of the >> draft, >> such as using bit lengths to refer to CWC instances, instead of octet >> lengths (i.e., AES-CWC-256 instead of AES-CWC-32). >> >> John >> >> _______________________________________________ >> Cfrg mailing list >> Cfrg@ietf.org >> https://www1.ietf.org/mailman/listinfo/cfrg >> > > T.M. Eubanks > Multicast Technologies, Inc. > e-mail : tme@multicasttech.com > http://www.multicasttech.com > > Test your network for multicast : > http://www.multicasttech.com/mt/ > _______________________________________________ Cfrg mailing list Cfrg@ietf.org https://www1.ietf.org/mailman/listinfo/cfrg From mailnull@www1.ietf.org Tue Apr 29 08:00:31 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13847 for ; Tue, 29 Apr 2003 08:00:31 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3TC5XL01046 for cfrg-archive@odin.ietf.org; Tue, 29 Apr 2003 08:05:33 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3TC5X801043 for ; Tue, 29 Apr 2003 08:05:33 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13811 for ; Tue, 29 Apr 2003 08:00:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19AToL-0001yh-00 for cfrg-web-archive@ietf.org; Tue, 29 Apr 2003 08:02:13 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19AToK-0001yd-00 for cfrg-web-archive@ietf.org; Tue, 29 Apr 2003 08:02:12 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3TC34800927; Tue, 29 Apr 2003 08:03:04 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3T4TW815527 for ; Tue, 29 Apr 2003 00:29:32 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA24552 for ; Tue, 29 Apr 2003 00:24:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19AMhC-0007fQ-00 for cfrg@ietf.org; Tue, 29 Apr 2003 00:26:22 -0400 Received: from vacuum.ics.mq.edu.au ([137.111.216.16]) by ietf-mx with esmtp (Exim 4.12) id 19AMhB-0007fN-00 for cfrg@ietf.org; Tue, 29 Apr 2003 00:26:21 -0400 Received: from vacuum.ics.mq.edu.au (vacuum.ics.mq.edu.au [137.111.216.16]) by vacuum.ics.mq.edu.au (8.11.6/8.11.7) with SMTP id h3T4QrT29690 for ; Tue, 29 Apr 2003 14:26:53 +1000 (EST) Received: from vacuum.ics.mq.edu.au ([137.111.216.16]) by vacuum.ics.mq.edu.au (SAVSMTP 3.0.0.44) with SMTP id M2003042914265216977 for ; Tue, 29 Apr 2003 14:26:52 +1000 Received: from vesuvius.ics.mq.edu.au (vesuvius.ics.mq.edu.au [137.111.240.11]) by vacuum.ics.mq.edu.au (8.11.6/8.11.7) with ESMTP id h3T4Qqx29687 for ; Tue, 29 Apr 2003 14:26:53 +1000 (EST) Received: from warramunga (warramunga.ics.mq.edu.au [137.111.220.158]) by vesuvius.ics.mq.edu.au (8.11.7/8.11.7) with SMTP id h3T4Qq824268 for ; Tue, 29 Apr 2003 15:26:52 +1100 (AEST) From: "Svein J. Knapskog" To: Date: Tue, 29 Apr 2003 14:29:06 +1000 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal X-MIME-Autoconverted: from 8bit to quoted-printable by vacuum.ics.mq.edu.au id h3T4Qqx29687 X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h3T4TW815528 Subject: [Cfrg] Nordic Workshop in ICT Security Sender: cfrg-admin@ietf.org Errors-To: cfrg-admin@ietf.org X-BeenThere: cfrg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Crypto Forum Research Group List-Post: List-Help: List-Subscribe: , X-MIME-Autoconverted: from 8bit to quoted-printable by www1.ietf.org id h3TC34800927 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h3TC5X801043 Content-Transfer-Encoding: 8bit Nordic Workshop on Secure IT Systems - NORDSEC (http://www.ce.chalmers.se/staff/jonsson/NORDSEC/nordsec_index.html) The NordSec workshops were started in 1996 with the aim of bringing together researchers and practitioners within computer security in the Nordic countries — thereby establishing a forum for discussions and co-operation between universities, industry and computer societies. The working language for the Conference is English This year's event is organized by Gjoevik University College, Gjoevik, Norway. It takes place on October 15 - 17 2003, i.e. the days following directly onto the ESORICS 2003 Conference, October 13-15 organized at the same venue. Call for paper is at: http://www2.hig.no/esorics2003//nordsec2003/?side=556 Contact: Program Committee Chair Svein J. Knapskog Professor, Department of telematics, NTNU,Norway svein.knapskog@item.ntnu.no _______________________________________________ Cfrg mailing list Cfrg@ietf.org https://www1.ietf.org/mailman/listinfo/cfrg From mailnull@www1.ietf.org Tue Apr 29 13:28:19 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02638 for ; Tue, 29 Apr 2003 13:28:19 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3THXRD02448 for cfrg-archive@odin.ietf.org; Tue, 29 Apr 2003 13:33:27 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3THXR802445 for ; Tue, 29 Apr 2003 13:33:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02606 for ; Tue, 29 Apr 2003 13:27:48 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19AYvY-0006RN-00 for cfrg-web-archive@ietf.org; Tue, 29 Apr 2003 13:30:00 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19AYvY-0006RK-00 for cfrg-web-archive@ietf.org; Tue, 29 Apr 2003 13:30:00 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3THSN801596; Tue, 29 Apr 2003 13:28:23 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3THRq801567 for ; Tue, 29 Apr 2003 13:27:52 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02447 for ; Tue, 29 Apr 2003 13:22:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19AYqA-0006PA-00 for cfrg@ietf.org; Tue, 29 Apr 2003 13:24:26 -0400 Received: from rwcrmhc53.attbi.com ([204.127.198.39]) by ietf-mx with esmtp (Exim 4.12) id 19AYq8-0006Oj-00 for cfrg@ietf.org; Tue, 29 Apr 2003 13:24:24 -0400 Received: from alten.attbi.com (12-232-7-235.client.attbi.com[12.232.7.235]) by rwcrmhc53.attbi.com (rwcrmhc53) with SMTP id <2003042917234005300f7ksue>; Tue, 29 Apr 2003 17:23:40 +0000 Message-Id: <5.2.0.9.0.20030429101444.035d8008@mail.attbi.com> X-Sender: alten@mail.attbi.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Tue, 29 Apr 2003 10:19:59 -0700 To: John Viega , Marshall Eubanks From: Alex Alten Subject: Re: [Cfrg] Authenticated encryption Cc: cfrg@ietf.org In-Reply-To: <8FADE95B-7696-11D7-AFE6-000A959CFBBA@securesoftware.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: cfrg-admin@ietf.org Errors-To: cfrg-admin@ietf.org X-BeenThere: cfrg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Crypto Forum Research Group List-Post: List-Help: List-Subscribe: , John, Doug, Tadayoshi, I've only had a chance to skim the I-D draft. Just a quick question about the hardware 10 Gbps performance. For the receiver can this be sustained if packets are dropped, corrupted or arrive out of order? If not, is it a bad hit requiring a resynchronization of some sort? Thanks, - Alex At 04:51 PM 4/24/2003 -0400, John Viega wrote: >Indeed, this is the paper we're preparing. We have just a bit more >cosmetic work to do, and should be making it available some time next week. > >John > >On Thursday, April 24, 2003, at 04:31 PM, Marshall Eubanks wrote: > >>Dear John; >> >>Do you know where I can get an on line version of the CWC reference : >> >> [CWC] Kohno, T., Viega, J. and Whiting, D. "A Carter-Wegman >> and Counter-Based Dual-Use Mode (CWC)". Manuscript, >> February, 2003. >> >>Or is this the shortly to appear paper you refer to ? >> >> Regards >> Marshall Eubanks >> >>On Tuesday, April 15, 2003, at 10:52 PM, John Viega wrote: >> >>>Nice work! I'd also like to point people to another new authenticated >>>encryption mode called CWC: >>> >>> http://www.ietf.org/internet-drafts/draft-irtf-cfrg-cwc-00.txt >>> >>>The main thing that CWC offers that other such modes don't is >>>that is that it is simultaneously patent-free, provably-secure and >>>parallelizable (meaning that it will be suitable for securing data over >>>10 gigabit/sec links). >>> >>>We will be releasing the full version of our paper (including security >>>proofs) shortly. >>> >>>There are some minor issues we'll fix in the next version of the draft, >>>such as using bit lengths to refer to CWC instances, instead of octet >>>lengths (i.e., AES-CWC-256 instead of AES-CWC-32). >>> >>>John >>> >>>_______________________________________________ >>>Cfrg mailing list >>>Cfrg@ietf.org >>>https://www1.ietf.org/mailman/listinfo/cfrg >> >>T.M. Eubanks >>Multicast Technologies, Inc. >>e-mail : tme@multicasttech.com >>http://www.multicasttech.com >> >>Test your network for multicast : >>http://www.multicasttech.com/mt/ > >_______________________________________________ >Cfrg mailing list >Cfrg@ietf.org >https://www1.ietf.org/mailman/listinfo/cfrg -- Alex Alten Alten@ATTBI.com _______________________________________________ Cfrg mailing list Cfrg@ietf.org https://www1.ietf.org/mailman/listinfo/cfrg From mailnull@www1.ietf.org Tue Apr 29 14:24:38 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04596 for ; Tue, 29 Apr 2003 14:24:38 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3TITmf08318 for cfrg-archive@odin.ietf.org; Tue, 29 Apr 2003 14:29:48 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3TITl808315 for ; Tue, 29 Apr 2003 14:29:47 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04590 for ; Tue, 29 Apr 2003 14:24:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19AZo4-0006sY-00 for cfrg-web-archive@ietf.org; Tue, 29 Apr 2003 14:26:20 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19AZo3-0006sV-00 for cfrg-web-archive@ietf.org; Tue, 29 Apr 2003 14:26:19 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3TISB808130; Tue, 29 Apr 2003 14:28:11 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3THlU804455 for ; Tue, 29 Apr 2003 13:47:30 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03187 for ; Tue, 29 Apr 2003 13:41:51 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19AZ99-0006X2-00 for cfrg@ietf.org; Tue, 29 Apr 2003 13:44:03 -0400 Received: from w168.z205158144.scl-ca.dsl.cnc.net ([205.158.144.168] helo=mail.securesoftware.com) by ietf-mx with esmtp (Exim 4.12) id 19AZ98-0006Wj-00 for cfrg@ietf.org; Tue, 29 Apr 2003 13:44:02 -0400 Received: from securesoftware.com (unknown [10.10.10.152]) by mail.securesoftware.com (Postfix) with ESMTP id BC6D8134510; Tue, 29 Apr 2003 13:44:17 -0400 (EDT) Date: Tue, 29 Apr 2003 13:43:47 -0400 Subject: Re: [Cfrg] Authenticated encryption Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: Marshall Eubanks , cfrg@ietf.org, Doug Whiting , Tadayoshi Kohno To: Alex Alten From: John Viega In-Reply-To: <5.2.0.9.0.20030429101444.035d8008@mail.attbi.com> Message-Id: <21616F7D-7A6A-11D7-97C5-000A959CFBBA@securesoftware.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) Content-Transfer-Encoding: 7bit Sender: cfrg-admin@ietf.org Errors-To: cfrg-admin@ietf.org X-BeenThere: cfrg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Crypto Forum Research Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit First, let me say that CWC is designed in such a way that there is no kind of order-dependent chaining on block levels. That is, inputs are treated in 96-bit atomic units. If you have, say, 3000 words come in during a single time slice, you can run 1000 parallel computations if you want to do so. In practice, that's not the way the world works, but it's at least theoretically possible to process as much data as you can handle in a single time slice about as fast as you can handle a single block. That is, CWC could scale to speeds faster to 10 gigabits per second in hardware if you throw more hardware at the problem. The tradeoffs are things like dye size and cost. In short, my answer is that you can (more or less) make CWC run as fast as you need it to run (there's a limit somewhere, of course). We don't do anything ourselves to handle dropped or out of order packets, etc. Those are problems that must be dealt with in the surrounding environment in which CWC is applied. But, there's no intrinsic issue with CWC that would keep you from designing around the problems you mention at the 10 gigabit/second level. John On Tuesday, April 29, 2003, at 01:19 PM, Alex Alten wrote: > John, Doug, Tadayoshi, > > I've only had a chance to skim the I-D draft. Just a quick question > about the > hardware 10 Gbps performance. For the receiver can this be sustained > if > packets are dropped, corrupted or arrive out of order? If not, is it > a bad hit > requiring a resynchronization of some sort? > > Thanks, > > - Alex > > At 04:51 PM 4/24/2003 -0400, John Viega wrote: >> Indeed, this is the paper we're preparing. We have just a bit more >> cosmetic work to do, and should be making it available some time next >> week. >> >> John >> >> On Thursday, April 24, 2003, at 04:31 PM, Marshall Eubanks wrote: >> >>> Dear John; >>> >>> Do you know where I can get an on line version of the CWC reference : >>> >>> [CWC] Kohno, T., Viega, J. and Whiting, D. "A >>> Carter-Wegman >>> and Counter-Based Dual-Use Mode (CWC)". >>> Manuscript, >>> February, 2003. >>> >>> Or is this the shortly to appear paper you refer to ? >>> >>> Regards >>> Marshall Eubanks >>> >>> On Tuesday, April 15, 2003, at 10:52 PM, John Viega wrote: >>> >>>> Nice work! I'd also like to point people to another new >>>> authenticated >>>> encryption mode called CWC: >>>> >>>> >>>> http://www.ietf.org/internet-drafts/draft-irtf-cfrg-cwc-00.txt >>>> >>>> The main thing that CWC offers that other such modes don't is >>>> that is that it is simultaneously patent-free, provably-secure and >>>> parallelizable (meaning that it will be suitable for securing data >>>> over >>>> 10 gigabit/sec links). >>>> >>>> We will be releasing the full version of our paper (including >>>> security >>>> proofs) shortly. >>>> >>>> There are some minor issues we'll fix in the next version of the >>>> draft, >>>> such as using bit lengths to refer to CWC instances, instead of >>>> octet >>>> lengths (i.e., AES-CWC-256 instead of AES-CWC-32). >>>> >>>> John >>>> >>>> _______________________________________________ >>>> Cfrg mailing list >>>> Cfrg@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/cfrg >>> >>> T.M. Eubanks >>> Multicast Technologies, Inc. >>> e-mail : tme@multicasttech.com >>> http://www.multicasttech.com >>> >>> Test your network for multicast : >>> http://www.multicasttech.com/mt/ >> >> _______________________________________________ >> Cfrg mailing list >> Cfrg@ietf.org >> https://www1.ietf.org/mailman/listinfo/cfrg > > -- > > Alex Alten > Alten@ATTBI.com > > > > _______________________________________________ > Cfrg mailing list > Cfrg@ietf.org > https://www1.ietf.org/mailman/listinfo/cfrg > _______________________________________________ Cfrg mailing list Cfrg@ietf.org https://www1.ietf.org/mailman/listinfo/cfrg