Crypto Forum Research Group ()

headers David McGrew | 6 Mar 2012 13:05

_______________________________________________
Cfrg mailing list
Cfrg <at> irtf.org
http://www.irtf.org/mailman/listinfo/cfrg

David McGrew <mcgrew <at> cisco.com> writes:

> Hi,
>
> the initial version of "Ciphers in Use in the Internet" is now
> available at
> <http://tools.ietf.org/html/draft-irtf-cfrg-cipher-catalog-00>.  Sean
> and I ask for your review, constructive criticism, and input.  Some
> parts of the draft need more detail and organization, but it should be
> in sound enough shape for review.
>
> If you have text to contribute, that would be appreciated, especially
> if you can supply citations for the more consequential statements.

Hi.  First an editorial issue, but one that affects readability
negatively: there appears to be many '!' and other characters inserted
at various points in the document.

Section 5.5 on Blowfish says "supports keys lengths 32,64,96,!, and 448"
however blowfish supports variable-length keys between 1 and 448 bits.
It also says 'IETF use includes None'.  Blowfish is mentioned in the
following list of RFCs.  I have not verified how many of them make any
normative use of the reference though.

rfc2367.txt rfc2407.txt rfc2409.txt rfc2440.txt rfc2451.txt rfc2628.txt
rfc2786.txt rfc2828.txt rfc3211.txt rfc3316.txt rfc4037.txt rfc4250.txt
rfc4251.txt rfc4253.txt rfc4301.txt rfc4306.txt rfc4344.txt rfc4718.txt
rfc4880.txt rfc4949.txt rfc5201.txt rfc5202.txt rfc5374.txt rfc5996.txt
rfc6020.txt rfc6071.txt rfc6476.txt

Section 6.3 on RC4 could say that RC4 has been claimed to be a
registered trademark, similar to what is said about RC2.

/Simon

On Feb 1, 2012, at 3:13 AM, zhou.sujing <at> zte.com.cn wrote:

> 
> Hi,all 
> 
> cfrg-bounces <at> irtf.org 写于 2012-01-07 17:03:25:
> 
> > 
> > 
> > On Wed, January 4, 2012 2:56 pm, Steven Bellovin wrote:
> > > Good point; let me think about it for -01.  An obvious solution is to send
> > > the hostname with the effective password.
> > 
> >   How is that different than using random salt then? If _something_ is
> > going to be sent shouldn't it be a uniformly random bitstring instead of
> > a hostname?
> > 
> >   A uniformly random bitstring would be more appropriate as a key to
> > HMAC than a highly structured string like a password too. Iterate
> > HMAC(salt, password | service-URI) instead of HMAC(password, service-URI). 
> 
> 
> 
> I think Dan's suggestion is reasonable, I checked the RFC 2104 and found the following section : 
> 
> "3. Keys 
> 
>    The key for HMAC can be of any length (keys longer than B bytes are 
>    first hashed using H).  However, less than L bytes is strongly 
>    discouraged as it would decrease the security strength of the 
>    function.  Keys longer than L bytes are acceptable but the extra 
>    length would not significantly increase the function strength. (A 
>    longer key may be advisable if the randomness of the key is 
>    considered weak.) 
> 
>    Keys need to be chosen at random (or using a cryptographically strong 
>    pseudo-random generator seeded with a random seed), and periodically 
>    refreshed.  (Current attacks do not indicate a specific recommended 
>    frequency for key changes as these attacks are practically 
>    infeasible.  However, periodic key refreshment is a fundamental 
>    security practice that helps against potential weaknesses of the 
>    function and keys, and limits the damage of an exposed key.)" 
> 
> 
> Since passwords are often not too long, and not so random, it is better 
> to hash it before using it as a key in a HMAC. 

Although hashing the password first certainly doesn't hurt, I read that
text as more related to brute force attacks against the key, rather than
to any limitation of the underlying function.  Hugo -- are you on this list?
Could you clarify?

		--Steve Bellovin, https://www.cs.columbia.edu/~smb

_______________________________________________
Cfrg mailing list
Cfrg <at> irtf.org
http://www.irtf.org/mailman/listinfo/cfrg

Just announced at the FSE 2012 rump session this week: a Workshop on Directions in Authenticated Ciphers
(DIAC), July 05 - 06, 2012.   

From <http://hyperelliptic.org/DIAC/>: "Users, starting with a shared secret key, need to protect
messages against espionage and against forgery. Dissatisfaction with the security and performance of
current approaches has led to calls for a new competition for authenticated ciphers. The purpose of this
workshop is to evaluate the state of the art in authenticated encryption and gather community input
regarding desired future directions."

This is a research effort, and not a standards effort.  

David

HI All, 

here is the agenda for the meeting next week.   Same as posted on the IETF site, but with the addition of Rene's talk.

David and Kevin

Introduction and Welcome (5 minutes)
CFRG status (5 minutes)
Hash-based passwords (15 minutes, Steve Bellovin)
Password Authenticated Key Exchange (25 minutes, Dan Harkins)
   5 minutes for PAKE discussion
Ciphers in Use on the Internet (10 minutes, Sean Shen)
OCBv3 (20 minutes, Rogaway)
Elliptic curve considerations (20 minutes, Rene Struik)
CFRG review of IETF uses of crypto (10 minutes, discussion)

1120-1330 Afternoon Sessions I and II, Room 212/213

<http://datatracker.ietf.org/meeting/agenda/>

Dear all,

The following is the draft of the HTTP PAKE application I mentioned in
the meeting:

http://tools.ietf.org/html/draft-oiwa-http-mutualauth-10

This is the core document of the proposal.

http://tools.ietf.org/html/draft-oiwa-http-mutualauth-algo-01

This is the companion draft defining one specific crypt scheme:

http://tools.ietf.org/html/draft-oiwa-http-auth-extension-00

This is another companion draft, defining non-crypto extensions
which is needed to accommodate current Form-based applications
to HTTP authentication.

Please also refer
https://www.rcis.aist.go.jp/special/MutualAuth/index-en.html
for implementations, UI considerations, past presentations in IETF and more.

Cheers,

Yutaka

--

-- 
Yutaka OIWA, Ph.D.                                       Research Scientist
                           Research Center for Information Security (RCIS)
   National Institute of Advanced Industrial Science and Technology (AIST)
                     Mail addresses: <y.oiwa <at> aist.go.jp>, <yutaka <at> oiwa.jp>
OpenPGP: id[440546B5] fp[7C9F 723A 7559 3246 229D  3139 8677 9BD2 4405 46B5]

4	May 2013
58	April 2013
42	March 2013
36	February 2013
8	January 2013
16	December 2012
20	November 2012
12	October 2012
20	September 2012
15	August 2012
15	July 2012
36	June 2012
26	May 2012
4	April 2012
6	March 2012
23	February 2012
14	January 2012
3	December 2011
17	November 2011
3	October 2011
8	August 2011
34	July 2011
34	June 2011
23	April 2011
3	February 2011
2	January 2011
4	November 2010
12	October 2010
11	August 2010
7	July 2010
91	June 2010
18	May 2010
16	April 2010
21	March 2010
3	February 2010
3	January 2010
15	December 2009
2	November 2009
37	October 2009
2	September 2009
6	August 2009
8	July 2009
6	June 2009
2	May 2009
19	April 2009
8	March 2009
6	February 2009
114	January 2009
76	December 2008
10	November 2008
1	October 2008
1	September 2008
2	August 2008
4	June 2008
5	May 2008
3	April 2008
4	February 2008
17	January 2008
2	December 2007
7	November 2007
9	October 2007
2	September 2007
4	August 2007
8	July 2007
3	June 2007
13	May 2007
6	April 2007
1	March 2007
1	February 2007
48	January 2007
15	October 2006
39	September 2006
41	August 2006
26	July 2006
2	April 2006
37	March 2006
7	February 2006
1	January 2006
2	December 2005
6	November 2005
235	October 2005
38	September 2005
12	August 2005
22	June 2005
2	May 2005
6	April 2005
89	March 2005
1	February 2005
11	January 2005
1	December 2004
39	November 2004
9	October 2004
34	September 2004
74	August 2004
2	July 2004
1	June 2004
7	May 2004
32	April 2004

Fwd: New Version Notification for draft-irtf-cfrg-cipher-catalog-00.txt

Re: Fwd: New Version Notification for draft-irtf-cfrg-cipher-catalog-00.txt

Re: [saag] New draft: Hashed Password Exchange

Workshop on Directions in Authenticated Ciphers (DIAC)

agenda for meeting at IETF 83

HTTP Mutual Authentication information

Mon	Tue	Wed	Thu	Fri	Sat	Sun

			1	2	3	4
5	6	7	8	9	10	11
12	13	14	15	16	17	18
19	20	21	22	23	24	25
26	27	28	29	30	31