Subject: I-D ACTION:draft-ietf-openpgp-camellia-00.txt

From: [email-masked]
Date: Thu, 08 Nov 2007 17:15:01 -0500

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the An Open Specification for Pretty Good Privacy Working Group of the IETF.

	Title		: The Camellia Cipher in OpenPGP
	Author(s)	: D. Shaw
	Filename	: draft-ietf-openpgp-camellia-00.txt
	Pages		: 5
	Date		: 2007-11-8
	
   This document presents the necessary information to use the Camellia
   symmetric cipher in the OpenPGP protocol.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-openpgp-camellia-00.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then 
"get draft-ietf-openpgp-camellia-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-openpgp-camellia-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: David Shaw <[email-masked]>
Date: Mon, 26 Nov 2007 17:51:52 -0500

> http://www.ietf.org/internet-drafts/draft-ietf-openpgp-camellia-00.txt

If folks could comment on this draft, I'd appreciate it.

There may well be nothing to say (the draft is not particularly
complex or controversial), in which case a "looks sane to me" comment
would be appreciated.  It's hard to tell the difference between
silence because there are no objections and silence because there is
no interest.

David

---

From: Jon Callas <[email-masked]>
Date: Mon, 26 Nov 2007 15:25:48 -0800

> silence because there are no objections and silence because there is

It looks sane to me. However, while RFC3713 specifies clearly that  
Camillia has a 128-bit block, I think you should too. Because of the  
eccentricities of what we do with CFB, block size is very important.  
I think it's wise to point out that has the same block size as AES  
and Twofish. It's just another sentence.

One last question is why only 256-bit keys? Why not 128 and 256 (I  
don't see the point of 192-bit keys, myself)? There are many good  
answers to the question. For example, if Rijndael were not the AES  
and we were adding it in, a good answer would be that Rijndael-256 is  
only about 20% slower than Rijndael-128, and because of that, most  
people will use the 256-bit keys anyway; most Rijndael applications  
just go right to 256. Another answer, less good, is that we don't  
want to consume two cipher numbers. If there is a good technical  
reason, then it might also be good to put it in the draft, because  
people will wonder and presume that it's just because we only want to  
use one cipher number if you don't.

Your draft is nice and elegant and short, and so you can add in a few  
more explanatory sentences. It will make the developer's life easier.

	Jon

---

From: Werner Koch <[email-masked]>
Date: Tue, 27 Nov 2007 10:14:04 +0100

> answers to the question. For example, if Rijndael were not the AES  

An argument pro 128 bit is that you can do double as many independed
encryption with a given amount of random numbers.  This is an advantage
on small systems and those where entropy is a scarce resource.

Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Auschnahme regelt ein Bundeschgesetz.

---

From: Ian G <[email-masked]>
Date: Tue, 27 Nov 2007 17:33:09 +0100

> on small systems and those where entropy is a scarce resource.

To me, this doesn't argue for 128 bit keys.  You can achieve 
the same effect by taking 128 bits of randomness and adding 
128 0's on the end.

Same comments I think apply to Dani's email.

Unless there is a marked speed difference, I think it 
reasonable to specify 256 bit key ciphers and expand shorter 
keys out.

Jon mentioned that with AES, there is a 20% slow down from 
128 to 256, in AES not Camelia.  That to me suggests that, 
in principle, we only specify 256 bit keys, and drop the 128 
bit cipher (*).  If there is a speed issue, then likely 20% 
isn't going to solve it and there should be a "mobile 
profile" or proper "cipher suite".

iang

PS: (*) I am not arguing to drop 128 bit AES, just the 
principle of the thing.

---

From: Werner Koch <[email-masked]>
Date: Wed, 28 Nov 2007 11:31:19 +0100

On Tue, 27 Nov 2007 17:33, [email-masked] said:

> To me, this doesn't argue for 128 bit keys.  You can achieve the same
> effect by taking 128 bits of randomness and adding 128 0's on the end.

I just wonder whether Camellia been analyzed for such an "abuse" of the
key length.  It is common practise to use random session key or use a
KDF to have a uniform distribution of the key bits.

Salam-Shalom,

   Werner

---

From: Ian G <[email-masked]>
Date: Wed, 28 Nov 2007 12:17:15 +0100

> KDF to have a uniform distribution of the key bits.

Yes, use a key expansion function.  I didn't mean to 
literally tempt the gods.

What I am trying to do here is suggest ways to reduce the 
work for implementors and maintainers, and also reduce 
possibilities for confusion by users.

There is a view that OpenPGP is a fine way to experiment 
with lots of different algorithms and lengths and modes and 
colours.  I once had that view as a developer, and once even 
published a Java kit with lots of algorithms in it... 
because it was so much fun to do all these algorithms!

But it is a conceit.  The maintainer in me rejected that 
approach within a month, and the architect in me now says 
that there is only one true cipher suite:

http://iang.org/ssl/h1_the_one_true_cipher_suite.html

iang

---

From: David Shaw <[email-masked]>
Date: Wed, 28 Nov 2007 12:08:01 -0500

On Wed, Nov 28, 2007 at 12:17:15PM +0100, Ian G wrote:
> Yes, use a key expansion function.  I didn't mean to literally tempt the 
> gods.
>
> What I am trying to do here is suggest ways to reduce the work for 
> implementors and maintainers, and also reduce possibilities for confusion 
> by users.

I don't know that this is really reducing work all that much.
Camellia supports a 128-bit key.  If we want to have the equivalent of
a 128-bit key, why not just use what Camellia already provides?  Sure,
we could do some trickery with key expansion, but then we have to
specify it, code it, and explain to people for a long time why we did
it that way.

David

---

From: David Shaw <[email-masked]>
Date: Wed, 28 Nov 2007 12:13:00 -0500

> and Twofish. It's just another sentence.

Good point.  I'll put that in.

> don't see the point of 192-bit keys, myself)?

I did 256 mainly because that was what Hironobu SUZUKI mentioned when
he brought it up.  I figured that if the WG wanted 128-bit keys,
someone would bring it up.  And now someone has. :)

I agree with you about 192-bit keys.  They're neither here nor there.

Thanks for the comments!

David