Jon Callas | 2 Jul 00:27 2011

Re: SRTP with SHA2?


On Jun 30, 2011, at 10:40 AM, Severns-Williams, Christine E (Christine) wrote:

Hi All,

  I’m not sure this is really the right mail list for this question.  But I see SHA2 being added to many security protocols (IPsec, TLS, etc) and discussion of other algorithms fading such as MD5.

 

I know SRTP supports AES-CM (128, 192, 256), AES-f8, and there is a draft for AES-CCM and AES-GCM (128 and 256).

 

Has anyone considered or is looking at using/adding SHA2 to the SRTP protocol?     Just curious.

 

I know the digest size is larger but it could still be truncated. 


You could, but there's no real need, and a number of reasons not to.

SRTP uses HMAC-SHA1 for integrity, and even provides for truncated integrity. If you believe that 80 bits of security is enough and that lots of times 32 bits is fine, then SHA256 is overkill. HMACs don't have the weaknesses that a straight hash does. You don't gain anything by using a truncated SHA256, security-wise.

(The truncated integrity is reasonable in many applications, particularly those where the payload is simply media. If the media has other integrity checks in it, even better. Suppose, for example, that the total payload was audio on the X codec, and if the X codec gets thrown into a bogus state, it will discard the packet. In this case, not only does the codec supply secondary authentication, but should a bad packet actually be inserted into the media stream, the only effect of that is an audio glitch. Almost certainly that glitch will just be a blip of noise.)

However, SHA256 is slower than SHA1, and since you're using it in an HMAC, you're having to do two hashes. That's big, from a performance point of view.

In many environments, the lion's share of the crypto cost for SRTP is that SHA1 HMAC. It is often over 2/3 of the total cost. Switching to SHA256 could bring the integrity cost to 80% or more of the total crypto cost, as well as driving it up, not down.

The real need for SRTP is to find an integrity check that's faster. That's something that ZRTP (RFC 6189) does. (Full disclosure: I'm a ZRTP co-author.) Some ZRTP implementations found that 75% of the cost of the crypto was that HMAC. So ZRTP provides the option to use the one-pass MAC feature of the Skein-512 hash function, which is one of the SHA3 finalists. (Full disclosure: I'm a Skein co-author, as well.) Not only is Skein-512 faster than SHA1, often running at 2/3 the speed of SHA1, but the one-pass MAC means you're only doing one hash, not two. That means that a Skein-MAC has only 1/3 the cost of HMAC-SHA1! It also has at least as good security as SHA256, so you get both better security and better performance.

(In the name of the algorithm, the -512 refers to the internal state size of Skein, not the output size. All three variants of Skein (256, 512, 1024) can have any length output. When you might want whatever internal state size is a long discussion that I could bore you at great length on. I believe that Skein-512 is adequate for any reasonable use.)

Jon


_______________________________________________
Cfrg mailing list
Cfrg <at> irtf.org
http://www.irtf.org/mailman/listinfo/cfrg
Sean Turner | 6 Jul 19:13 2011

Fwd: I-D Action: draft-kutylowski-mrsa-algorithm-00.txt

This might be of interest to some on the list.

spt

-------- Original Message --------
Subject: I-D Action: draft-kutylowski-mrsa-algorithm-00.txt
Date: Wed, 06 Jul 2011 08:08:42 -0700
From: internet-drafts <at> ietf.org
Reply-To: internet-drafts <at> ietf.org
To: i-d-announce <at> ietf.org

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.

	Title           : Mediated RSA cryptography specification for additive 
private key splitting (mRSAA)
	Author(s)       : Miroslaw Kutylowski
                           Przemyslaw Kubiak
                           Michal Tabor
                           Daniel Wachnik
	Filename        : draft-kutylowski-mrsa-algorithm-00.txt
	Pages           : 58
	Date            : 2011-07-06

    This document describes recommendations for the implementation of
    public key cryptography based on the mediated RSA algorithm. The
    Mediated RSA algorithm bases on fragmentation of a private key. As a
    result the signature process consists from multiple stages. The
    verification process is the same as in the case of RSA algorithm
    [RFC 3447].

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

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-kutylowski-mrsa-algorithm-00.txt
_______________________________________________
I-D-Announce mailing list
I-D-Announce <at> ietf.org
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
David McGrew | 12 Jul 23:34 2011
Picon

Fwd: Special Publication 800-56C

Hello,

a document that may be of interest to you: second draft of NIST's "Recommendation for Key Derivation through Extraction-then-Expansion", which is compatible with RFC 5869 "HMAC-based Extract-and-Expand Key Derivation Function (HKDF)", which was discussed on this list a couple of years back.  Comments period ends on August 11.  http://csrc.nist.gov/news_events/index.html#july12

David

Begin forwarded message:

From: NIST Computer Security Resource Center <csrc.nist <at> service.govdelivery.com>
Date: July 12, 2011 2:25:06 PM PDT
Subject: NIST Released 2 Draft Special Publications: 800-126 Rev. 2 and Special Publication 800-56C
Reply-To: NIST Computer Security Resource Center <csrc.nist <at> service.govdelivery.com>

Today, NIST Computer Security Division released 2 Draft Special Publications.  See below for the details.  Each draft will have 2 URLs - one will take you to the full announcement on the CSRC News page and the second URL will take you to the same announcement on the CSRC Drafts page.  The announcement and link are the same announcement for each draft.

Draft #1: Second Draft Special Publication 800-56C, Recommendation for Key Derivation through Extraction-then-Expansion

CSRC News page for this Draft document:
http://csrc.nist.gov/news_events/index.html#july12
- OR -
CSRC Drafts page for this Draft document:
http://csrc.nist.gov/publications/PubsDrafts.html#SP-800-56-C


_______________________________________________
Cfrg mailing list
Cfrg <at> irtf.org
http://www.irtf.org/mailman/listinfo/cfrg
Ted Krovetz | 13 Jul 18:42 2011
Picon

Request For Comments: OCB Internet-Draft

I have just submitted an internet-draft for OCB to the IETF.

  http://datatracker.ietf.org/doc/draft-krovetz-ocb

I'd appreciate any comments you may have on how to make the draft better.

OCB is a blockcipher-based authenticated-encryption scheme. It is significantly faster than any other
blockcipher-based AE scheme that I am aware of. On Intel's current Sandy Bridge processors it encrypts
and authenticates 4K messages at 0.9 cpu cycles per byte of message, and processes a weighted mix of
message lengths at 1.3 cpb (5% 44B, 15% 552B, 20% 576B, 60% 1500B).

OCB has undegone refinements over the years to allow authentication of associated data and improved
performance. This is the second (and last) revision. It was presented at FSE this year

  http://www.cs.ucdavis.edu/~rogaway/papers/ae.pdf

Associated notes and performace data are at

  http://www.cs.ucdavis.edu/~rogaway/ocb/performance

We intend to convert the internet-draft into an RFC and also submit OCB to the NIST blockcipher
modes-of-operation project.

There are several patents that may apply to OCB. We are in the process of trying to get all parties to pool
their patents and liberalize their use.

Thank you,
Ted Krovetz
Peter Gutmann | 14 Jul 05:48 2011
Picon
Picon
Picon

Re: Request For Comments: OCB Internet-Draft

Ted Krovetz <ted <at> krovetz.net> writes:

>I have just submitted an internet-draft for OCB to the IETF.

OCB is a nice mode, I've always wanted to use it, but:

>There are several patents that may apply to OCB. We are in the process of
>trying to get all parties to pool their patents and liberalize their use.

without the ability to use it without encumbrance I'll stick with CBC+HMAC or
GCM.  I know you can use OCB under the GPL but that's too much of a hassle to
try and sort out for each user, it'd have to be completely unencumbered to
make it useful.

(I'm not saying this out of some rabid anti-patent position but purely an 
anti-headache position, since there are unencumbered, if less efficient, 
alternatives available I'll go with those and avoid the hassle).

Peter.
Simon Josefsson | 14 Jul 10:00 2011

Re: Request For Comments: OCB Internet-Draft

Ted Krovetz <ted <at> krovetz.net> writes:

> I have just submitted an internet-draft for OCB to the IETF.
>
>   http://datatracker.ietf.org/doc/draft-krovetz-ocb
>
> I'd appreciate any comments you may have on how to make the draft better.

It would help if you explained (in the security considerations) what
happens if a nonce is repeated.  The question of failure modes of
authenticated encryption modes has come up in several different
contexts.  It turns out that different AEAD modes have different failure
properties.

In particular, you want to address whether repeat of a nonce leads to
immediate key disclosure, or whether the key can be found after some
computation faster than obvious attacks, or whether it can only lead to
recovery of the plaintext, and/or whether it depends on the plaintext as
well (e.g., something interesting happens if the plaintexts are related).

> There are several patents that may apply to OCB. We are in the process
> of trying to get all parties to pool their patents and liberalize
> their use.

Which patents?  According to the patent disclosure search, only these
have been disclosed:

https://datatracker.ietf.org/ipr/559/
https://datatracker.ietf.org/ipr/560/

If you are aware of other patents (or applications) that applies, it
would help if you send in a patent disclosure about it.

Thanks,
/Simon
Yaron Sheffer | 14 Jul 21:41 2011
Picon

Repeated one-time pad

Regarding "immediate key disclosure": is is well known that reuse of a 
stream cipher or a one-time pad with different plaintexts leads to 
immediate exposure of the plaintext (see e.g. 
http://en.wikipedia.org/wiki/One-time_pad#True_randomness). For a course 
I am teaching, I would appreciate pointers to the algorithms that are 
used for this cryptanalysis and/or source code that implements this attack.

Thanks,
     Yaron

Message: 2 Date: Thu, 14 Jul 2011 10:00:44 +0200 From: Simon Josefsson 
<simon <at> josefsson.org> To: Ted Krovetz <ted <at> krovetz.net> Cc: 
cfrg <at> irtf.org Subject: Re: [Cfrg] Request For Comments: OCB 
Internet-Draft Message-ID: <87ipr5gukz.fsf <at> latte.josefsson.org> 
Content-Type: text/plain Ted Krovetz <ted <at> krovetz.net> writes:
>> I have just submitted an internet-draft for OCB to the IETF.
>>
>>    http://datatracker.ietf.org/doc/draft-krovetz-ocb
>>
>> I'd appreciate any comments you may have on how to make the draft better.
> It would help if you explained (in the security considerations) what
> happens if a nonce is repeated.  The question of failure modes of
> authenticated encryption modes has come up in several different
> contexts.  It turns out that different AEAD modes have different failure
> properties.
>
> In particular, you want to address whether repeat of a nonce leads to
> immediate key disclosure, or whether the key can be found after some
> computation faster than obvious attacks, or whether it can only lead to
> recovery of the plaintext, and/or whether it depends on the plaintext as
> well (e.g., something interesting happens if the plaintexts are related).
>
Paterson, Kenny | 14 Jul 22:45 2011
Picon

Re: Repeated one-time pad

Hi Yaron,

The paper you want is by Mason et al. from CCS a few years back:

<at> inproceedings{DBLP:conf/ccs/MasonWES06,
author = {Joshua Mason and Kathryn Watkins and Jason Eisner and Adam Stubblefield}, title = {A natural language approach to automated cryptanalysis of two-time pads}, booktitle = {ACM Conference on Computer and Communications Security}, year = {2006}, pages = {235-244}, ee = {http://doi.acm.org/10.1145/1180405.1180435}, crossref = {DBLP:conf/ccs/2006usa}, bibsource = {DBLP, http://dblp.uni-trier.de} }

I had a masters student re-implement the algorithms in this paper last summer - they performed very well, but not quite as well as the authors indicated in their paper.

Cheers

Kenny


On 14 Jul 2011, at 20:41, Yaron Sheffer wrote:

Regarding "immediate key disclosure": is is well known that reuse of a stream cipher or a one-time pad with different plaintexts leads to immediate exposure of the plaintext (see e.g. http://en.wikipedia.org/wiki/One-time_pad#True_randomness). For a course I am teaching, I would appreciate pointers to the algorithms that are used for this cryptanalysis and/or source code that implements this attack.

Thanks,
   Yaron

Message: 2 Date: Thu, 14 Jul 2011 10:00:44 +0200 From: Simon Josefsson <simon <at> josefsson.org> To: Ted Krovetz <ted <at> krovetz.net> Cc: cfrg <at> irtf.org Subject: Re: [Cfrg] Request For Comments: OCB Internet-Draft Message-ID: <87ipr5gukz.fsf <at> latte.josefsson.org> Content-Type: text/plain Ted Krovetz <ted <at> krovetz.net> writes:
I have just submitted an internet-draft for OCB to the IETF.

  http://datatracker.ietf.org/doc/draft-krovetz-ocb

I'd appreciate any comments you may have on how to make the draft better.
It would help if you explained (in the security considerations) what
happens if a nonce is repeated.  The question of failure modes of
authenticated encryption modes has come up in several different
contexts.  It turns out that different AEAD modes have different failure
properties.

In particular, you want to address whether repeat of a nonce leads to
immediate key disclosure, or whether the key can be found after some
computation faster than obvious attacks, or whether it can only lead to
recovery of the plaintext, and/or whether it depends on the plaintext as
well (e.g., something interesting happens if the plaintexts are related).


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

_______________________________________________
Cfrg mailing list
Cfrg <at> irtf.org
http://www.irtf.org/mailman/listinfo/cfrg
Marshall Eubanks | 14 Jul 23:44 2011
Picon

Re: Repeated one-time pad



On Thu, Jul 14, 2011 at 3:41 PM, Yaron Sheffer <yaronf.ietf <at> gmail.com> wrote:
Regarding "immediate key disclosure": is is well known that reuse of a stream cipher or a one-time pad with different plaintexts leads to immediate exposure of the plaintext (see e.g. http://en.wikipedia.org/wiki/One-time_pad#True_randomness). For a course I am teaching, I would appreciate pointers to the algorithms that are used for this cryptanalysis and/or source code that implements this attack.

The attack is pretty simple and can be done by hand. 

If (as was common in the spy world) the one time pad was just XORed (or summed) with the plain text, XOR'ing two of cipher-texts with the same  "one-time" pad in the same phase yields an XOR  of the two underlying plain-texts, which lends itself to plaintext cribs and a "crab-like" attack (i.e., if you can guess one word in one plain-text, it will, when XORed with the XOR of the two cipher-texts, reveal part of the other plain-text, which, when extended, then will  reveal more of the first plain-text, and so on until both are decrypted. Even if the phase of the OTP isn't known (e.g., if there is filler text at the beginning), it should be easy to determine it using the index of coincidence (which should peak when the OTPs are aligned in phase).

This is (from my understanding) how the Venona break was done.

Sounds like a reasonable pen and paper exercise for your students for me. 

Now, what I have is always wondered is whether the non-randomness of the Russian OTPs used in their spy work was  enough to have a break without reuse of the OTPs. (These were prepared by typists instructed to type randomly, and so weren't entirely random, for example letters were almost never doubled and a left hand letter was generally followed by a right hand letter. Not a lot of non-randomness, but a little can go a long way...)

Regards
Marshall



 
Thanks,
   Yaron

Message: 2 Date: Thu, 14 Jul 2011 10:00:44 +0200 From: Simon Josefsson <simon <at> josefsson.org> To: Ted Krovetz <ted <at> krovetz.net> Cc: cfrg <at> irtf.org Subject: Re: [Cfrg] Request For Comments: OCB Internet-Draft Message-ID: <87ipr5gukz.fsf <at> latte.josefsson.org> Content-Type: text/plain Ted Krovetz <ted <at> krovetz.net> writes:
I have just submitted an internet-draft for OCB to the IETF.

  http://datatracker.ietf.org/doc/draft-krovetz-ocb

I'd appreciate any comments you may have on how to make the draft better.
It would help if you explained (in the security considerations) what
happens if a nonce is repeated.  The question of failure modes of
authenticated encryption modes has come up in several different
contexts.  It turns out that different AEAD modes have different failure
properties.

In particular, you want to address whether repeat of a nonce leads to
immediate key disclosure, or whether the key can be found after some
computation faster than obvious attacks, or whether it can only lead to
recovery of the plaintext, and/or whether it depends on the plaintext as
well (e.g., something interesting happens if the plaintexts are related).


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

_______________________________________________
Cfrg mailing list
Cfrg <at> irtf.org
http://www.irtf.org/mailman/listinfo/cfrg
Ted Krovetz | 15 Jul 02:35 2011
Picon

Re: Request For Comments: OCB Internet-Draft

> It would help if you explained (in the security considerations) what happens if a nonce is repeated.

Nice suggestion. Security is lost if nonces are reused during encryption. We've made this clearer in the ID
and have resubmitted it as draft-krovetz-ocb-02.

> If you are aware of other patents (or applications) that applies, it would help if you send in a patent
disclosure about it.

IBM and Virgil Gligor have AE patents which may or may not apply to OCB. What we are trying to establish with
them is a clear licensing picture for OCB, hopefully with many free usage scenarios. Phil will update the
IETF IPR soon.

Thanks,
Ted

Gmane