Subject: SV: [Cfrg] Possible RFC: Data integrity combined with encryption

From: "Mads Rasmussen" <[email-masked]>
Date: Sun, 22 Sep 2002 15:04:30 -0300

> -----Oprindelig meddelelse-----
> Fra: Mok-Kong Shen [mailto:[email-masked]]
> Sendt: 20. september 2002 17:00
> Til: csjutla; [email-masked]
> Emne: Re: [Cfrg] Possible RFC: Data integrity combined with encryption
> 
> 
> 
> 
> csjutla wrote:

<snip>

> > Also see
> > www.nist.gov/aes/modes/proposedmodes (and look under my name).
> > 
> 
> Many thanks for the references.
> 
> Anton Stiglic mentioned that possibly all good schemes 
> known are patented. Is that true or could you name
> one that is free? Thanks.

To make amends for previous posting, let me give a overview of the
proprosed modes at NIST (refering to the link above).

2DEM = 2D-Encryption Mode - no patents exist according to authors

ABC = Accumulated Block Chaining - no patent information (I assume none
exist ??)

CCM = Counter with CBC Mac - no patents exist according to authors

CTR = Counter Mode Encryption - no patents exist according to authors

IACBC = Integrity Aware Parallelizable Mode - IBM have filed patent. If
method is adopted by NIST, a non-exclusive licence will be granted on a
non-discriminatory basis.

IGE = Infinite Garble Extension - no patent information

KFB = Key Feedback Mode - no patents exist according to authors

OCB = Offset Codebook - patent pending, licenced for commercial use
 
PCFB = Propagating Cipher Feedback - no patent information
 
PMAC = Parallelizable Message Authentication Code - patent pending,
licenced for commercial use

RMAC = Randomized MAC - no patent information

TMAC = Two-Key CBC MAC - no patents exist according to authors
 
XCBC(mac) = Extended Cipher Block Chaining MAC - no patent information
(due to specification, I would assume none exist - ??)
 
XCBC = eXtended Cipher Block Chaining Encryption - patent filed. If
method is adopted by NIST, a non-exclusive licence will be granted on a
non-discriminatory basis.
 
XECB(MAC) = eXtended Electronic Code Book MAC - patent filed. If method
is adopted by NIST, a non-exclusive licence will be granted on a
non-discriminatory basis.

Regards,

Mads Rasmussen
Open Communications Security
+55(11)3345-2525

_______________________________________________
Cfrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/cfrg

---

From: "Anton Stiglic" <[email-masked]>
Date: Mon, 23 Sep 2002 09:28:48 -0400

I would like to mention that there is a skunwork group working at
writing an Internet-Draft that proposes a key derivation function (KDF).
We believe that a standard for a key derivation function is useful, 
given the fact that almost every new project/design seems to invent
it's own KDF.  See the bottom of this e-mail for a list of different
KDF that have been proposed in the past.
Ideally, we would like to propose a construct who's security can 
be backed up by some theoretical results, but also we would like
it to be backwards compatible with different KDF that have already
been proposed (most of which have been designed in an ad-hoc way).

We want to design a KDF that is general, in the sense that it
can derive a key from any secret (a password, a Diffie-Hellman
secret, etc), and which can take different arguments (iteration count,
salt, diversifier, algorithm parameter, etc...).
We are concentrating on a Hash based mechanism for now.
So far, we are leaning towards a design that is backwards compatible
with PBKDF2 from PKCS#5, MGF1 (if you use a simple hash for the
PBKDF2 you can get MGF1) and also possibly with KDF2 from 
IEEE1363 (same as MGF1 on octet-strings, except that counter
starts at a different value), under some chosen parameters.
But we have to finish researching the litterature before we propose 
an official initial draft.

Our goal is to have a standard KDF that other people can refer to 
when designing new systems.

Here is a list of the literature we are looking at, followed is a list
of KDFs that have been defined here and there.  Note that the references
are about KDF involving hash (or HMAC, etc..) based hash functions.
We have another list of references for MACs based on symmetric
functions, but initially we are not looking into these.
If you know of some other reference regarding Hash based KDFs 
that you believe would be useful we are interested in hearing from you, 
so please send me an e-mail.

Thank you for you attention!

-------------------------------------

Bibliography

On the Security of Two MAC Algorithms, Preneel-vanOorshot

PKCS#5 - Password-BAsed Cryptography Standard

RFC version of PKCS#5

MAC re-definition, post by Hugo to [email-masked]

Pseudorandom functions revisited:  The cascade constructiona and its
concrete security, Bellare-Canetti-Krawczyk

Random oracles are practical:  A paradigm for designing efficient
protocols

Secure Applications of Low-Entropy Keys, Kelsey-Schneir-Hall-Wagner

PKCS#1 - RSA Cryptography Standard 

TLS RFC2246 

SSL3 INTERNET-DRAFT 

IKE RFC2409 

IEEE1363 and IEEE1363a

SKIP 

A Proposal for an ISO standard for Public Key Encryption, Shoup

------------------------------------------------

List of different KDFs:

* MGF1, as described in PKCS1v2.0 and IEEE1363, is KDF1 in Shoup's
  proposal for ISO.

* PBKDF1, defined in PKCS#5v1.5 and v2.0 for backwards compatibility.

* PBKDF2, defined in PKCS#5v2.0

* KDF1 in IEEE1363

* KDF2 in IEEE1363a

* PRF in TLS used for key generation or validation

* KDF in SSL3

* KDF based on a PRF (suggested HMAC) in IKE 

* key seperation technique in SKIP

---

From: Bodo Moeller <[email-masked]>
Date: Mon, 23 Sep 2002 16:11:33 +0200

> starts at a different value), under some chosen parameters.

A problem with KDF1 and KDF2 (and probably certain other KDFs too) is
that they limit entropy to the hash size.  (For KDF2, which has a
variable output size, this could have been avoided.)  This is a
problem I noticed in draft-ietf-tls-ecc-01.txt -- it defines named
curves up to 571 bits for ECDH, but always uses KDF1 with SHA-1,
and this combination does not make a lot of sense.

I added a 'DISCUSSION POINT' on this when I joined in for
draft-ietf-tls-ecc-02.txt, but so far there has not been much
discussion except between the draft authors.  (My proposal is to
simply to omit the KDF1 step because TLS includes its own PRF anyway.
For backwards compatibility with existing implementations based on
draft-ietf-tls-ecc-12.txt, we can continue to use KDF1 with SHA-1 for
curves up to 288 bits and omit the KDF1 step for larger curves.)

-- 
Bodo Möller <[email-masked]>
PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html
* TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt
* Tel. +49-6151-16-6628, Fax +49-6151-16-6036
_______________________________________________
Cfrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/cfrg

---

From: Luigi Lo Iacono <[email-masked]>
Date: Mon, 23 Sep 2002 17:27:41 +0200

The SRTP ID also defines a KDF but I don't know if it corresponds to one 
of the functions mentioned in your list!?

-- 
Luigi Lo Iacono
-------------------------------------------------------
Institute for Data Communications Systems
University of Siegen, Germany
http://www.nue.et-inf.uni-siegen.de/
-------------------------------------------------------
PGP:    057E 2A17 47B2 4749  1D37 8A07 286E 2238
HTTP:   http://www.nue.et-inf.uni-siegen.de/~loiacono/
EMail:  mailto:[email-masked]
Phone:  +49 271 740-4354
Fax:    +49 271 740-2536
Mobile: +49 177 2442521
-------------------------------------------------------

---

From: Uri Blumenthal <[email-masked]>
Date: Mon, 23 Sep 2002 14:11:34 -0400

Bodo Moeller wrote:
> > with PBKDF2 from PKCS#5.........
> 
> variable output size, this could have been avoided.) 

We've been proposing a provably secure PRF for a while. I'm in  the
process of posting the revised draft of this crypto-hash based scheme.

It is suitable for key derivation (that was its purpose :-), and it
provides a [practically :-] unlimited amount of key bits.

Zulfikar, you probably recognize the approach. (:-)
_______________________________________________
Cfrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/cfrg

---

From: "David A. Mcgrew" <[email-masked]>
Date: Mon, 23 Sep 2002 12:17:48 -0700

Anton,

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of Luigi
> Lo Iacono
> Sent: Monday, September 23, 2002 8:28 AM
> To: Anton Stiglic; [email-masked]
> Subject: Re: [Cfrg] Work on KDF Internet-Draft
>
>

the SRTP KDF is based on counter mode AES, which is also the
mandatory-to-implement cipher for that protocol.

I agree that KDFs are a good topic for CFRG.  It would be healthy to have a
discussion on the security and operational requirements of KDFs.

David