Subject: [Cfrg] What crypto algorithm is referenced most in RFCs?

From: David McGrew <[email-masked]>
Date: Mon, 13 Jun 2011 07:04:14 -0700

Hi,

I updated the Internet Cryptography pages.  Some new features:

   * new I-Ds (non-expired 00 versions) are listed on a separate page <http://www.mindspring.com/~dmcgrew/ic/new.html 

   * statistics on the number of times each algorithm is referenced <http://www.mindspring.com/~dmcgrew/ic/statistics.html 

That last page can be used to answer the question in the subject  
line.  (Hint: it is not something most of us probably recommend  
anymore.)

regards,

David

---

From: Joachim Strömbergson <[email-masked]>
Date: Tue, 14 Jun 2011 08:16:13 +0200

Aloha!

On 2011:06:13 16:04, David McGrew wrote:
> That last page can be used to answer the question in the subject line. 
> (Hint: it is not something most of us probably recommend anymore.)

I was amazed that there were so many of those drafts that are in
standards track. Drafts in informational track describing uses of
insecure algorithms is imho ok, since they document a practice.
Similarly, RFCs are a done deal and if they are a standard RFC must be
replaced by newer RFCs to fix security issues.

But in 2011 writing a draft for standards track that includes known
insecure, broken algorithms?

Would it be fruitful to browse the list try and identify the most
pressing cases and try to convince the authors that they should mend
their ways?

- -- 
Med vänlig hälsning, Yours

Joachim Strömbergson - Alltid i harmonisk svängning.
========================================================================
Kryptoblog - IT-säkerhet på svenska
http://www.strombergson.com/kryptoblog
========================================================================

---

From: Sean Turner <[email-masked]>
Date: Tue, 14 Jun 2011 18:35:34 -0400

On 6/14/11 2:16 AM, Joachim Strömbergson wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Aloha!
>

Somebody has asked for draft that says don't use RC4.  I'm really busy 
but would gladly help deprecate RFC cipher suites in TLS. Unless of 
course, I'm totally wrong and we should keep them....

> pressing cases and try to convince the authors that they should mend

Actually, it would.

spt

> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.11 (Darwin)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAk32/K0ACgkQZoPr8HT30QF7lACfSUrUM2Ue5RDfK9CZ7379LaSS
> mn4AnRgV7Q37ZaUfwm4gzGdODQOMFwOa
> =vQLC
> -----END PGP SIGNATURE-----
> _______________________________________________
> Cfrg mailing list
> [email-masked]
> http://www.irtf.org/mailman/listinfo/cfrg

---

From: Brian Smith <[email-masked]>
Date: Tue, 14 Jun 2011 15:42:35 -0700 (PDT)

> course, I'm totally wrong and we should keep them....

I think you meant to write "deprecate RC4 cipher suites in TLS." 

What would be the justification used? I know of some weaknesses of RC4 but I haven't seen any indication that it is broken in TLS.

Cheers,
Brian

---

From: Sean Turner <[email-masked]>
Date: Tue, 14 Jun 2011 18:54:26 -0400

> What would be the justification used? I know of some weaknesses of RC4 but I haven't seen any indication that it is broken in TLS.

I did mean to write "deprecate RC4 cipher suites in TLS."  Honestly, it 
was bait ;)  I got this request and wanted to test the idea that we 
should investigate deprecating RC4.

spt

---

From: Jon Callas <[email-masked]>
Date: Tue, 14 Jun 2011 16:59:27 -0700

>> pressing cases and try to convince the authors that they should mend

I disagree. What would be helpful would be to identify *implementations* that should mend their ways. The map is not the territory. The RFCs are the maps; the implementations are the territories. If you change the map so that it represents an idealized reality, it's not the same thing as a fixed reality. I think reality is better than this survey of maps indicates.

Let me channel Jeff Schiller and point out that mandatory-to-implement does not imply mandatory-to-use, as well as that the purpose of a standard is interoperability. It is the implementations themselves where the rubber meets the road and bits are twiddled.

For example, let's assume a standard that was done in the late '90s, and consequently has MD5 and 3DES as its MUST algorithms and has since been updated with MAYs of AES and SHA2.

While it would be nice to update the standard's MUSTs, this is often problematic. On the other hand, as I said above, the purpose of a standard is interoperability. I'd jump down the throat of any implementation that's still using MD5 *because* there's no reason to just make the decision that you'll negotiate AES and SHA2 even unto the point of refusing to use MD5 at all. It's a reasonable implementer's prerogative.

Now let's look at the flip side of this. Let's wave a magic wand and make all the standards update themselves to reasonable parameters. I assert that the effect of this in the world of implementations will be within epsilon of zero. Any *reasonable* implementation is already using reasonable parameters, and the ones that haven't updated themselves aren't going to have a fire lit under their butt because RFC 31337 says so. Phrased another way, I don't think there's a single broken implementation that is broken because there are aged RFCs out there. The implementations are broken for one reason only -- the implementers don't care. (I also assert that any implementation that merely is no longer maintained proves me right on the don't-care front.)

Updating all those aged RFCs is a feel-good exercise that will have no effect on the real world. Any standard that people are using actively almost certainly has migrated away. The exception cases (and I'm sure they exist) are where the effort should be focused.

If you want to have a positive effect on the world with the minimum windmill-tilting, go find the RFCs that do not have reasonable extensions. Continuing my example, something that is using (e.g.) bare MD5 with no option for SHA2. Update that RFC to have SHA2 as a MAY, and then poke the implementers to migrate on their own. I can think of a few things I might pursue (CRAM-MD5 springs to mind), but focus your righteous anger on the implementations that are screwing up and then on the implementations that are doing something half-assed because the only option they have is to do something half-assed. Write the new RFC for them with something full-assed.

	Jon

---

From: Simon Josefsson <[email-masked]>
Date: Wed, 15 Jun 2011 09:31:33 +0200

Jon Callas <[email-masked]> writes:

> I disagree. What would be helpful would be to identify
> *implementations* that should mend their ways. The map is not the
> territory. The RFCs are the maps; the implementations are the
> territories. If you change the map so that it represents an idealized
> reality, it's not the same thing as a fixed reality. I think reality
> is better than this survey of maps indicates.

+1

Use of DES/RC2/MD4 is still not uncommon.

> If you want to have a positive effect on the world with the minimum
> windmill-tilting, go find the RFCs that do not have reasonable
> extensions. Continuing my example, something that is using (e.g.) bare
> MD5 with no option for SHA2. Update that RFC to have SHA2 as a MAY,
> and then poke the implementers to migrate on their own. I can think of
> a few things I might pursue (CRAM-MD5 springs to mind), but focus your
> righteous anger on the implementations that are screwing up and then
> on the implementations that are doing something half-assed because the
> only option they have is to do something half-assed. Write the new RFC
> for them with something full-assed.

For CRAM-MD5 to fall, I think you need to show that there are practical
attacks on HMAC-MD5.  As far as I recall this hasn't been done yet.

I'm more concerned with DIGEST-MD5.  I'm not sure significant number of
people in the crypto community bothers to study it.  However DIGEST-MD5
is widely implemented and used.

Fortunately, we have SCRAM to replace them both. :-)

/Simon

---

From: Joachim Strömbergson <[email-masked]>
Date: Wed, 15 Jun 2011 09:42:51 +0200

Aloha!

On 2011:06:15 1:59, Jon Callas wrote:
>>> Would it be fruitful to browse the list try and identify the
>>> most pressing cases and try to convince the authors that they
>>> should mend their ways?
> 
>> Actually, it would.
> 

Jon, I'm sorry for not being more clear. What I was implicitly referring
to was the lists of active drafts, not RFCs. I agree that for RFCs it is
more important to look at implementations.

But the drafts has not yet become the map. Fixing errors in the map to
be before it is printed isn't that better than waiting until it has been
printed and in use?

We basically have two different problems:
(1) Help implemementations to migrate from algorithms we don't trust
anymore to the algorithms we trust, algorithms specified in updated
versions of the map.

(2) Help map developers avoid specifying use of the bad algorithms so
that new implementations don't end up using bad algorithms in the first
place.

More understandable? And agreeable?

- --

---

From: Jon Callas <[email-masked]>
Date: Thu, 16 Jun 2011 10:10:43 -0700

> that new implementations don't end up using bad algorithms in the first

Absolutely!

These days it's very easy to pick a good set of building blocks. There are also plenty of things that are mostly okay, but you shouldn't use for new protocols. In the protocol process, it's relatively easy to make sure you're only using the good ones, and for anyone who isn't, we can point out what to do.

	Jon

---

From: Peter Gutmann <[email-masked]>
Date: Fri, 17 Jun 2011 21:34:33 +1200

Jon Callas <[email-masked]> writes:

>Phrased another way, I don't think there's a single broken implementation
>that is broken because there are aged RFCs out there. The implementations are
>broken for one reason only -- the implementers don't care.

Actually there's a subset of implementations where the implementers do care,
but the decisions-makers don't (I've run into this a number of times).  This
is why in the past I've called for RFCs to spell out otherwise common-sense
"don't do this" requirements, because the implementers may care but without an
official spec saying "if you do this you're being negligent" they can't get
any decision-makers to move on it.

>Updating all those aged RFCs is a feel-good exercise that will have no effect
>on the real world.

It will have an effect in at least some areas.

Peter.

---

From: David McGrew <[email-masked]>
Date: Fri, 17 Jun 2011 11:29:51 -0700

Hi Joachim,

+1 on the idea of making sure that current I-Ds that mention MD5 are  
aware   Probably this could be done by crafting a short paragraph  
saying something like "We noticed that your RFC references MD5; please  
be aware that it is not recommended for new protocols (see RFC6151).   
We suggest that your work not make use of MD5.  If it is necessary to  
use MD5 for compatibility with existing implementations, we ask that  
you cite RFC6151."   (Comments and wordsmithing welcome.)

The first of the current drafts that I looked at was draft-zorn-emu- 
team-02, and it includes TLS_RSA_WITH_RC4_128_MD5 as a SHOULD, and it  
doesn't cite 6151.   So I think the message would help.

David

On Jun 15, 2011, at 12:42 AM, Joachim Strömbergson wrote:

> = 
> = 
> ======================================================================
> = 
> = 
> ======================================================================
> iEYEARECAAYFAk34YnsACgkQZoPr8HT30QGNQgCfRC9Nm/5o1FcGfoTB+sdRQ2ch
> 728AoO2gDDaj9T5uV9VpHiTy2yfentZT
> =Uxo/

---

From: David McGrew <[email-masked]>
Date: Fri, 17 Jun 2011 11:40:50 -0700

On Jun 17, 2011, at 11:29 AM, David McGrew wrote:

> saying something like "We noticed that your RFC references MD5;

aargh, I meant "your I-D references MD5".

David

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 17 Jun 2011 20:14:34 +0100

Seems like a reasonable idea but defining the "we" that are noticing/sending this might be tricky. We don't want IETF WGs to start complaining about the IRTF CFRG crypto police. People can be touchy about stuff like that. I'm not sure how best that'd be done to be honest.

S

On 17 Jun 2011, at 19:40, David McGrew <[email-masked]> wrote:

>> +1 on the idea of making sure that current I-Ds that mention MD5 are aware   Probably this could be done by crafting a short paragraph saying something like "We noticed that your RFC references MD5;
>

---

From: Marshall Eubanks <[email-masked]>
Date: Sat, 18 Jun 2011 14:33:09 -0400

On Fri, Jun 17, 2011 at 3:14 PM, Stephen Farrell
<[email-masked]>wrote:

> Seems like a reasonable idea but defining the "we" that are
> noticing/sending this might be tricky. We don't want IETF WGs to start
> complaining about the IRTF CFRG crypto police. People can be touchy about
> stuff like that. I'm not sure how best that'd be done to be honest.
>
>
Write an I-D along the lines of "MD-5 considered dangerous" and get it
published.

Regards
Marshall

> aware   Probably this could be done by crafting a short paragraph saying
> something like "We noticed that your RFC references MD5;
> >

---

From: Stephen Farrell <[email-masked]>
Date: Sat, 18 Jun 2011 19:48:57 +0100

On 18 Jun 2011, at 19:33, Marshall Eubanks <[email-masked]> wrote:

> 
> 
> On Fri, Jun 17, 2011 at 3:14 PM, Stephen Farrell <[email-masked]> wrote:
> Write an I-D along the lines of "MD-5 considered dangerous" and get it published. 

RFC6151?
S

---

From: Marshall Eubanks <[email-masked]>
Date: Sat, 18 Jun 2011 15:09:21 -0400

On Sat, Jun 18, 2011 at 2:48 PM, Stephen Farrell
<[email-masked]>wrote:

> On Fri, Jun 17, 2011 at 3:14 PM, Stephen Farrell <<[email-masked]>
> [email-masked]> wrote:
>

I thought that there was something like this. Then quote this

   MD5 is no longer acceptable where collision resistance is required
   such as digital signatures.  It is not urgent to stop using MD5 in
   other ways, such as HMAC-MD5; however, since MD5 must not be used for
   digital signatures, new protocol designs should not employ HMAC-MD5.

and point out how the new I-D disagrees with it.

That's not being the Crypto police. After all, the IESG approved this RFC
and new use of MD5 should get pushback when an I-D gets to the IESG.
Pointing this out earlier is just saving people's time, and ADs generally
appreciate having their time saved.

Regards
Marshall

> S
>
>
> Regards
> Marshall
>
>
>
>
>> S
>>
>> On 17 Jun 2011, at 19:40, David McGrew < <[email-masked]>
>> [email-masked]> wrote:
>>
>> >
>> > <[email-masked]>[email-masked]
>> > <http://www.irtf.org/mailman/listinfo/cfrg>
>>  <[email-masked]>[email-masked]
>>  <http://www.irtf.org/mailman/listinfo/cfrg>

---

From: Stephen Farrell <[email-masked]>
Date: Sat, 18 Jun 2011 21:35:39 +0100

> appreciate having their time saved.

Sure, I'm all for it if its not perceived as adding bureaucracy.
Don't forget we already have up to 6 reviews etc. on stuff at
last-call time.

If someone has a way to generate a report identifying relevant
-00 and -01 drafts maybe, and someone else is willing to ping
authors and explain when they then say "so what" that might
be good.

I'd say a concrete proposal for what and how to do it, sent to
this list (and then probably saag) for sanity checking would
be good. So, who's stepping up to figure out details for such
a proposal?

S.

---

From: David McGrew <[email-masked]>
Date: Mon, 20 Jun 2011 08:23:47 -0700

Hi Stephen,

On Jun 18, 2011, at 1:35 PM, Stephen Farrell wrote:

>>> On 18 Jun 2011, at 19:33, Marshall Eubanks <[email-masked] 
>>> >
>>> wrote:
>>>
>>>
>>>
>>> On Fri, Jun 17, 2011 at 3:14 PM, Stephen Farrell <<[email-masked] 
>>> >

I have a set of scripts for producing the list of relevant drafts  
(containing more AWK programming than I would prefer to admit to ;-)   
It would probably be good to provide more detailed information about  
the 00 I-Ds, such as the crypto algorithm(s) that they reference.  In  
the case of MD5, it would be good to know which I-Ds mention MD5 but  
don't mention RFC6151.  I am happy to contribute this as an "official"  
RG contribution if people feel that is important (I'm not sure why it  
would be, but if it makes process easier I can generate a doc or a  
webpage with the IETF Trust copyright notice).

There are about 120 00-version drafts that reference crypto  
currently.  Most of those are doing the right thing, and won't require  
much if any work from crypto-reviewers.   This suggests that the  
"steady state" workload of having CFRG review the uses of crypto in  
new I-Ds will be manageable, if we can get a couple of volunteers.   
There are also 170 current I-Ds that mention MD5, which suggests that  
the short-term workload will be higher than the steady state  
workload.  If anyone is interested, please send a note either to the  
list, or to Stephen, Sean, and me.

I think the best way to operate would be find some volunteers to go  
through the I-Ds that mention MD5, and send out a notification to  
authors where needed.  If there are cases in which the actual security  
properties are not clear, those should be brought back to the RG for  
discussion.  If this seems fruitful, we can apply the process to -00 I- 
Ds going forward.

Looking ahead a bit, it seems like it would be valuable for the RG to  
produce a document describing the crypto algorithms that are in use  
and providing guidance.  I think it would be healthy to have a  
discussion in CFRG on the guidance, and this document could be  
something that we point to.

David

>>>> saying

---

From: Marshall Eubanks <[email-masked]>
Date: Mon, 20 Jun 2011 11:33:52 -0400

On Mon, Jun 20, 2011 at 11:23 AM, David McGrew <[email-masked]> wrote:

>>> <[email-masked]>**wrote:
>>>
>>>
>>>>
> (containing more AWK programming than I would prefer to admit to ;-)  It
> would probably be good to provide more detailed information about the 00
> I-Ds, such as the crypto algorithm(s) that they reference.  In the case of
> MD5, it would be good to know which I-Ds mention MD5 but don't mention
> RFC6151.  I am happy to contribute this as an "official" RG contribution if
> people feel that is important (I'm not sure why it would be, but if it makes
> process easier I can generate a doc or a webpage with the IETF Trust
> copyright notice).
>
> There are about 120 00-version drafts that reference crypto currently.
>  Most of those are doing the right thing, and won't require much if any work
> from crypto-reviewers.   This suggests that the "steady state" workload of
> having CFRG review the uses of crypto in new I-Ds will be manageable, if we
> can get a couple of volunteers.  There are also 170 current I-Ds that
> mention MD5, which suggests that the short-term workload will be higher than
> the steady state workload.  If anyone is interested, please send a note
> either to the list, or to Stephen, Sean, and me.
>
> I think the best way to operate would be find some volunteers to go through
> the I-Ds that mention MD5, and send out a notification to authors where
> needed.  If there are cases in which the actual security properties are not
> clear, those should be brought back to the RG for discussion.  If this seems
> fruitful, we can apply the process to -00 I-Ds going forward.
>
>
If you are going to do that, what about DES and rfc4772 ? If you're going to
be looking...

Marshall

> produce a document describing the crypto algorithms that are in use and
> providing guidance.  I think it would be healthy to have a discussion in
> CFRG on the guidance, and this document could be something that we point to.
>
> David
>
>
>
>> S.
>>
>>
>>
>>> Regards
>>> Marshall
>>>
>>>
>>>  S
>>>>
>>>>
>>>> Regards
>>>> Marshall
>>>>
>>>>
>>>>
>>>>
>>>>  S
>>>>>
>>>>>> ______________________________**_________________
>>>>>> Cfrg mailing list
>>>>>> <http://www.irtf.org/mailman/**listinfo/cfrg<http://www.irtf.org/mailman/listinfo/cfrg>
>>>>>> >
>>>>>>
>>>>> http://www.irtf.org/mailman/**listinfo/cfrg<http://www.irtf.org/mailman/listinfo/cfrg>
>>>>> ______________________________**_________________
>>>>> Cfrg mailing list
>>>>> <http://www.irtf.org/mailman/**listinfo/cfrg<http://www.irtf.org/mailman/listinfo/cfrg>
>>>>> >
>>>>> http://www.irtf.org/mailman/**listinfo/cfrg<http://www.irtf.org/mailman/listinfo/cfrg>
>>>>>
>>>>>
>>>>
>>>>
>>>  ______________________________**_________________
>> Cfrg mailing list
>> [email-masked]
>> http://www.irtf.org/mailman/**listinfo/cfrg<http://www.irtf.org/mailman/listinfo/cfrg>
>>
>
>

---

From: Joachim Strömbergson <[email-masked]>
Date: Mon, 20 Jun 2011 18:30:08 +0200

Aloha!

On 2011:06:20 17:23, David McGrew wrote:
> Most of those are doing the right thing, and won't require much if any
> work from crypto-reviewers.   This suggests that the "steady state"
> workload of having CFRG review the uses of crypto in new I-Ds will be
> manageable, if we can get a couple of volunteers.  There are also 170
> current I-Ds that mention MD5, which suggests that the short-term
> workload will be higher than the steady state workload.  If anyone is
> interested, please send a note either to the list, or to Stephen, Sean,
> and me.

Since I'm the one who brought this up I guess I should also step up to
the plank. ;-) Count me in.

- --

---

From: Marshall Eubanks <[email-masked]>
Date: Mon, 20 Jun 2011 13:18:32 -0400

2011/6/20 Joachim Strömbergson <[email-masked]>

> the plank. ;-) Count me in.

I will volunteer too.

Marshall

> iEYEARECAAYFAk3/dZAACgkQZoPr8HT30QG3oQCfSj3ndD8lAU5xMnTBZ1QcxfgJ
> G5wAmwYUyKck3zZXhy8DdIWathWLJi+u
> =pfjM

---

From: David McGrew <[email-masked]>
Date: Mon, 20 Jun 2011 10:35:07 -0700

On Jun 20, 2011, at 8:33 AM, Marshall Eubanks wrote:

> On 18 Jun 2011, at 19:33, Marshall Eubanks  
> <[email-masked]>
> wrote:
>
>
>
> (containing more AWK programming than I would prefer to admit  
> to ;-)  It would probably be good to provide more detailed  
> information about the 00 I-Ds, such as the crypto algorithm(s) that  
> they reference.  In the case of MD5, it would be good to know which  
> I-Ds mention MD5 but don't mention RFC6151.  I am happy to  
> contribute this as an "official" RG contribution if people feel that  
> is important (I'm not sure why it would be, but if it makes process  
> easier I can generate a doc or a webpage with the IETF Trust  
> copyright notice).
>
> currently.  Most of those are doing the right thing, and won't  
> require much if any work from crypto-reviewers.   This suggests that  
> the "steady state" workload of having CFRG review the uses of crypto  
> in new I-Ds will be manageable, if we can get a couple of  
> volunteers.  There are also 170 current I-Ds that mention MD5, which  
> suggests that the short-term workload will be higher than the steady  
> state workload.  If anyone is interested, please send a note either  
> to the list, or to Stephen, Sean, and me.
>
> authors where needed.  If there are cases in which the actual  
> security properties are not clear, those should be brought back to  
> the RG for discussion.  If this seems fruitful, we can apply the  
> process to -00 I-Ds going forward.
>
>
> If you are going to do that, what about DES and rfc4772 ? If you're  
> going to be looking...
>
> Marshall

good point.

David

---

From: Marshall Eubanks <[email-masked]>
Date: Mon, 20 Jun 2011 13:38:41 -0400

On Mon, Jun 20, 2011 at 1:35 PM, David McGrew <[email-masked]> wrote:

>> through the I-Ds that mention MD5, and send out a notification to authors
>> where needed.  If there are cases in which the actual security properties
>> are not clear, those should be brought back to the RG for discussion.  If
>> this seems fruitful, we can apply the process to -00 I-Ds going forward.
>>
>>
> If you are going to do that, what about DES and rfc4772 ? If you're going
> to be looking...
>
> Marshall
>
>
> good point.
>
> David
>

On this topic, has triple DES been deprecated yet ? I wouldn't feel
comfortable recommending it for something new, but I don't think it's
been shown the door yet.

Regards
Marshall

---

From: Jon Callas <[email-masked]>
Date: Mon, 20 Jun 2011 10:51:40 -0700

On Jun 20, 2011, at 10:38 AM, Marshall Eubanks wrote:

> On this topic, has triple DES been deprecated yet ? I wouldn't feel comfortable recommending it for something new, but I don't think it's been shown the door yet.

No. 112-bit crypto of all sorts (another example is 2K RSA keys) is still acceptable.

I agree with you, I wouldn't use 3DES for anything new. But the major reason to avoid it isn't key size, it's block size. You should avoid anything with a smaller block than 128 bits.

	Jon

---

From: David McGrew <[email-masked]>
Date: Mon, 20 Jun 2011 11:11:07 -0700

Hi Jon,

On Jun 20, 2011, at 10:51 AM, Jon Callas wrote:

>> comfortable recommending it for something new, but I don't think  
>> it's been shown the door yet.
>
> I agree with you, I wouldn't use 3DES for anything new. But the  
> major reason to avoid it isn't key size, it's block size. You should  
> avoid anything with a smaller block than 128 bits.

+1.   This is a highly relevant security factor, especially for higher  
data rates.  This comment applies also to IDEA, CAST-128, GOST  
28147-89, Blowfish, and most uses of RC5.

To quantify this, I believe that a 128-bit block cipher can process  
2^32 times as much data as a 64-bit block cipher, while having the  
same level of security in the indistinguishability model, assuming  
that neither cipher can be distinguished from a random permutation.

David

> Version: PGP Universal 2.10.0 (Build 554)
> Charset: us-ascii
>
> wj8DBQFN/4itsTedWZOD3gYRAtDaAKD+P4sz4cpvr7/s/JeWv6rI31+8uACgzrsX
> H8E9kdTTiJXQPyMYxhZw3I0=
> =5wHj

---

From: Thomas Pornin <[email-masked]>
Date: Mon, 20 Jun 2011 14:19:01 -0400

> that neither cipher can be distinguished from a random permutation.

Actually is 2^32 times as many blocks, but since 128-bit blocks are
twice larger than 64-bit blocks, this translates to 2^33 times as much
data.

	--Thomas Pornin

---

From: David McGrew <[email-masked]>
Date: Tue, 21 Jun 2011 13:15:01 -0700

Joachim, Marshall, many thanks for volunteering.   How about we  
discuss offline how to divide up the work?  (I'm willing to put in  
some time too.)

David

On Jun 20, 2011, at 10:18 AM, Marshall Eubanks wrote:

> currently.

---

From: Marshall Eubanks <[email-masked]>
Date: Tue, 21 Jun 2011 16:38:59 -0400

On Tue, Jun 21, 2011 at 4:15 PM, David McGrew <[email-masked]> wrote:

> Joachim, Marshall, many thanks for volunteering.   How about we discuss
> offline how to divide up the work?  (I'm willing to put in some time too.)
>
>
You want set up a webex or skype session?

I am free this Thursday at 10:00 AM EDT.

Marshall

---

From: David McGrew <[email-masked]>
Date: Tue, 21 Jun 2011 13:49:28 -0700

> I am free this Thursday at 10:00 AM EDT.

that works for me.  How about you, Joachim?

David

>> =====================================================================
>> =====================================================================