Russ Housley | 30 Apr 2013 20:06

Re: Hash substitution in PSS


>> This is aligned with PKCS#1.  Yes, it would be ideal for the whole
>> thing to be NULL if all of the values are DEFAULT, but that is not the
>> way PKCS#1 did it.
>> 
> [DB] Why would that be ideal?  NULL parameters usually mean the equivalent of absent parameters, not
DEFAULT parameters.
> 
> This does raise an orthogonal issue: what about historial implementations that do not support OPTIONAL
parameters (in AlgorithmIdentifier).  (((Chances are such an implementation would also not support
DEFAULT parameters?))).  Some RFCs specify that NULL-valued parameters have the same meaning as absent
parameters.   To address such implementations, RFC 4055 could be modified to take the same approach, with
an erratum.  (Also, NULL-value parameter do not count as present for the purposes of the actions to be
taken, etc.)
> 
> But maybe 4055 does not need to grandfather to such implementations, since it is all about some kind of
newfangled RSA-PSS that grandpa never heard of and would never bother with anyway, being happy with good
old PKCS#1v1.5.

I did not intend to pick the scab off the absent vs NULL discussion.  My point was that a shorthand for four
default values would have been desirable, but it is way too late.

Russ
Igoe, Kevin M. | 11 Apr 2013 19:41
Picon

Hash substitution in PSS

On 4 August Jim Schaad pointed out that the choice of hash algorithm in PSS is not authenticated and asked if
this was a security problem.

The good news is that if all of the hash algorithms in use are "secure", the only risk is the "birthday
problem", and the aVailability of more than one hash does not a priori result in a cheaper attack.

The bad news is that if one of the hashes is broken, so broken that an adversary has a non-trivial chance of
finding an "evil" message that has the same hash value as a benign message formed with a hash that is
"secure", they can substitute the evil message under the weak hash for the benign message under the strong
hash. Preventing this requires either that (1) the have a policy to reject all messages with the weak hash
or (2) the choice of hash algorithm be authenticated. Personally I trust a cryptographic authentication
over policy.
Richard Barnes | 6 Apr 2013 00:17

Re: What Algorithm information needs to be authenticated?

On Fri, Apr 5, 2013 at 6:02 PM, Ben Laurie <ben <at> links.org> wrote:

On 5 April 2013 23:00, Mike Jones <Michael.Jones <at> microsoft.com> wrote:
> Indeed, "all parameters should be protected" is the security posture taken in the current JOSE specifications.  Some want to change that.

OK. Why?


Is that "Why are all parameters protected?" or "Why do some people want to change that"?

--Richard 
_______________________________________________
Cfrg mailing list
Cfrg <at> irtf.org
http://www.irtf.org/mailman/listinfo/cfrg
Dan Brown | 5 Apr 2013 22:52

IETF's message authentication (1-pass) w/o signatures ...

Dear CFRG list:

 

Some IETF messaging protocols, including CMS (and perhaps JOSE) offer messaging protocols in which both the sender and the recipient have authenticated keys (public keys, shared symmetric keys, or passwords) and the message is authenticated (and possibly also encrypted), but not signed in the usual sense of a public-key signature.

 

Questions:

 

1. What benefits does this form of recipient-specific sender authentication have over signing?  In particular, is the main benefit adding non-malleability (integrity protection (***)) to encryption (*)?

 

2. What is the best cryptographic research defining formal security definitions for this kind of operation?

 

3. How do the current IETF designs fare under these cryptographic research goals?

 

4. Suppose a message has multiple recipients, one of whom is malicious.  Should a malicious recipient be allowed to manipulate the message?  Should a malicious recipient be allowed to generate a new "authenticated" message from the sender with a different recipient list, in particular, including only a single honest recipient (**)?  If these features are allowed, should it be called "authentication"?

 

I seek your answers, but provide my tentative answers:

 

1. Two benefits: (a) signatures have less plausible deniability, and (b) signatures have constant authentication cost per recipient, whereas recipient-specific authentication has a cost proportional to the number of recipients (which may be one way to resist spam).  A parallel (but not necessarily a benefit): TLS offers, optionally, client authentication without a client signature on every (or even any) message, which presumably has benefits.  So, the benefit is much greater than adding non-malleability (aka integrity protection).

 

2. I recall some work done on designated verifiers, but I think that is slightly different and trickier functionality.  My rather bad IACR eprint on deniable authentication does not qualify.

 

3. The security should be okay in the single recipient case, but it would hard to prove for most schemes.  The security of the current CMS methods are not so good in the multiple recipient case.

 

4. Probably not. Definitely not (because how would an honest recipient determine previous messages). Definitely not. (*)

 

(*) I've been told that the purpose of the CMS "authentication" methods is actually only to provide non-malleable (aka integrity protection) -- but not in those exact words -- and that for true sender authentication, one should use signatures instead.  I’ve also been told that the term "authentication" only applies to whoever has the MAC key.  I translate this into an alternative answer to 4 which is not my own:

 

4'  Definitely yes. Probably yes. Yes.

 

(**) This seems possible for the current CMS methods.  My opinion is that benefits of recipient-specific authentication are sufficient to take some countermeasures against this possibility.

 

(***) I now see, after writing most of this, that JOSE includes signatures under the term "integrity protection", which seems to conflict with how I (and I think others too) have used this term use to describe the non-malleability property of PKE.  I really think that the terminology should be resolved.

 

Best regards,

 

Daniel Brown

Research In Motion Limited

 

 

 

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.
_______________________________________________
Cfrg mailing list
Cfrg <at> irtf.org
http://www.irtf.org/mailman/listinfo/cfrg
Paterson, Kenny | 5 Apr 2013 19:41
Picon
Favicon

Re: IETF's secure messaging v public-key encryption

Dan,

Under item 3 on your list, there is a nice paper 
by Nigel Smart at SCN 2004. This gives 
security models and constructions for
multi-recipient KEMs, basically what you 
are after.

There is related work on
randomness reuse in public key encryption
(probably referenced in Nigel's paper).

Broadcast encryption is yet another related
(yet distinct) topic.   

Can you provide pointers to the cms/Jose
schemes you are interested in analysing?

Regards,

Kenny

Sent from my iPhone

On 5 Apr 2013, at 16:48, "Dan Brown" <dbrown <at> certicom.com> wrote:

Dear CFRG list:

 

Some IETF protocols, including CMS (and perhaps JOSE), offer schemes that are essentially public-key encryption: they protect a conveyed message from an unauthenticated (cryptographically anonymous) sender (**) to a recipient with a public key, with the wrinkle that they also permit multiple recipients (sharing a common "wrapped" key).

 

Although the sender has no authenticated key, the sender still applies a MAC to the message.  This application of a MAC has been called "authenticated" (with respect to whoever has the MAC key) in some places. It has also been called "integrity-protection" in other places.

 

Past versions of CMS message encryption did not apply the MAC. Consequently, the integrity of an encrypted message was not protected.

 

It seems that the purpose of the MACing corresponds closely to the cryptographers’ notion of "non-malleability" (NM) goal public-key encryption schemes.  (If I recall correctly, NM-CCA2 has been proven equivalent to IND-CCA2.)

 

Questions:

 

1) Do the existing and proposed IETF public-key message encryption methods meet the cryptographer's benchmark of IND-CCA2 security? How important is that to meet these goals?  Can (or have) these cryptographer’s security goals be proven for the specific CMS methods?

 

2) What is the best terminology to use in IETF?  How important is terminology?  Should the existing IETF terminology be amended?

 

3) What is the right formal definition when multiple recipients are involved?

 

I seek your answers, but here are my tentative answers:

 

1) The current proposals provide IND-CCA2.  It would be very hard to prove this (*).  It is important to provide at least IND-CCA1 security, but CCA2 is never really necessary.

 

2) "Non-malleability" is the best terminology for many general users, at least from my experience. Standard terminology is important, for mutual understanding, and accident avoidance.  The term "authenticated" should either removed when the sender does not use an authenticated key, or else change the term to "recipient-authenticated" (compare TLS and server authentication versus client authentication...).

 

3) The security definitions should be nearly the same for multiple recipients (which share a common symmetric key).

 

(*) Shoup [ISO 18033-2] introduced the KEM-DEM approach to hybrid PKE schemes, which may be highly useful for describing, and proving things about, the CMS methods.  I vaguely recall some research done in this area.

 

(**) In a separate message, I will discuss schemes in which the sender can also be authenticated by means of an authenticated key (but does not sign).

 

Best regards,

 

Daniel Brown

Research In Motion Limited

 

 

<image001.gif>

 

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.
_______________________________________________
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
internet-drafts | 4 Apr 2013 22:52
Picon
Favicon

I-D Action: draft-irtf-cfrg-ocb-01.txt


A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Crypto Forum Research Group Working Group of the IETF.

	Title           : The OCB Authenticated-Encryption Algorithm
	Author(s)       : Ted Krovetz
                          Phillip Rogaway
	Filename        : draft-irtf-cfrg-ocb-01.txt
	Pages           : 17
	Date            : 2013-04-04

Abstract:
   This document specifies OCB, a shared-key blockcipher-based
   encryption scheme that provides privacy and authenticity for
   plaintexts and authenticity for associated data.  This document is a
   product of the Crypto Forum Research Group (CFRG).

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-irtf-cfrg-ocb

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-irtf-cfrg-ocb-01

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-irtf-cfrg-ocb-01

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/
Igoe, Kevin M. | 4 Apr 2013 18:12
Picon

Dragonfly

I’d look to put out a Last Call on Dan Harkin’s Dragonfly,
            draft-irtf-cfrg-dragonfly-01.
The design looks mature, it addresses a real need, and no one has
raised any issues.  Feel free to speak up and share your insights
with the mailing list.
 
 
----------------+--------------------------------------------------
Kevin M. Igoe   | "We can't solve problems by using the same kind
kmigoe <at> nsa.gov  | of thinking we used when we created them."
                |              - Albert Einstein -
----------------+--------------------------------------------------
 
 
 
_______________________________________________
Cfrg mailing list
Cfrg <at> irtf.org
http://www.irtf.org/mailman/listinfo/cfrg
Jim Schaad | 4 Apr 2013 08:25

What Algorithm information needs to be authenticated?

Request for Information

The JOSE working group is having an internal argument about the need to
protect the various header information in an encrypted or signed message.
The quick question is which algorithm information and algorithm parameters
need to be included in integrity portion of the signature or encryption
operation in order to protect those parameters.

There are a couple of theoretical attacks that can be launched against
various algorithms that then require protection an example of such a
parameter is the IV for the AES-CBC/HMAC algorithm that has been proposed.
In this case the IV is protected by the algorithm itself and therefore does
not need to be externally protected by the JOSE data structures.

In RFC 6211, there is a new CMS attribute that was defined for protection of
the signature algorithm as I felt there was a potential attack that could be
exploited.

Looking at the RSA v1.5 signature algorithm, one cannot change the hash
algorithm as the hash algorithm is encoded as part of the padding for the
signature

Looking at the RSA PSS signature, there is the possibility that a hash
algorithm of the same length could be substituted unless external
restrictions are applied.  Thus one could potentially substitute a
RIPEMD-160 hash on the content for a SHA-1 hash.   As long as the hashes
match and there is no externally applied restriction that the hash algorithm
used to build the PSS internals is same as the content hash then it would
verify.  It is unclear if there is an attack that involves multiple hash
algorithms that is better than a birthday attack on a single algorithm as I
don't know if this has ever been studied.

CMS also defined an attribute that can be included in the signature
computation for specifying a certificate that is to be used in the
validation of the signature on the CMS object.  I.e. where to get the public
key and the base restrictions for that are imposed on that public key by the
certificate issuer.

Questions that we would like to see discussed:

1.  For signature operations, what parameters related to the signature
algorithm and what parameters related to a key need to be protected by the
signature operation to prevent real and theoretical attacks on JOSE signed
structures.   We would like to get the real and theoretical attacks
separated with a weight on the theoretical attacks for the potential to
become real.

2.  For MAC operations, what parameters related to the MAC algorithm and
what parameters related to the key need to be protected by the MAC operation
to prevent real and theoretical attacks on a JOSE MAC structure.

3.  For key management operations (how the content encryption key is given
to the recipient), what parameters related to the algorithms need to be
protected as part of the AEAD algorithm.

4.  For content encryption, what parameter related to the AEAD algorithm
need to be protected by the AEAD algorithm (and are not already protected)
need to be included.  Is there any benefit in double protecting parameters
such as the IV in case a new AEAD algorithm does not directly protect that
value.

Looking at the key to be protected, we don't care if the recipient cannot
find the correct key or misinterprets what the key identifier is.  What we
want to make sure is that an attacker would be unable to change the
recipients interpretation of what key is to be used and still get a
successful validation.

Jim Schaad
JOSE Co-Chair
John Bradley | 2 Apr 2013 17:59

Re: GCM nonce reuse question

Jim,

I don't think Mike was proposing that as a solution, but rather an attempt to characterize the issue.

Yes changing the nonce per recipient would cause the cypher text produced by GCM to change per recipient and need to be repeated, making it an array of JWE effectively, and not really anyones idea of encrypting to multiple recipients.

In a later email I asked David if we have the same or similar issue with his AES-CBC+HMAC. 

Perhaps and I think it is too early to go there, perhaps not all encryption algorithms are equally well suited to using with multiple recipients.

John B.

On 2013-04-02, at 12:48 PM, "Jim Schaad" <jimsch <at> augustcellars.com> wrote:

Mike,

 
I will note that this is not going to be considered an acceptable solution for the JOSE group.  You don’t really want to increase the size of the message by n*base64 encoding where in is the number of recipients.

 
Jim

 
 
From: Mike Jones [mailto:Michael.Jones <at> microsoft.com] 
Sent: Monday, April 01, 2013 5:55 PM
To: David McGrew (mcgrew); Jim Schaad
Cc: cfrg <at> irtf.org; John Bradley
Subject: RE: GCM nonce reuse question

 

Hi David,

 
In reading this thread and http://tools.ietf.org/html/draft-mcgrew-iv-gen-02, I believe that it’s OK, however if the usage is:

 
(Recipient #1 ciphertext, Recipient #1 authentication tag) = GCM(Key, Recipient #1 data, nonce #1, plain text)

(Recipient #2 ciphertext, Recipient #2 authentication tag) = GCM(Key, Recipient #2 data, nonce #2, plain text)

 
where nonce #1 and nonce #2 are guaranteed to be distinct?  Am I reading things correctly in that regard?

 
                                                                Thanks,

                                                                -- Mike

 
From: cfrg-bounces <at> irtf.org [mailto:cfrg-bounces <at> irtf.org] On Behalf Of David McGrew (mcgrew)
Sent: Thursday, March 28, 2013 4:15 AM
To: Jim Schaad
Cc: cfrg <at> irtf.org
Subject: Re: [Cfrg] GCM nonce reuse question

 

Hi Jim,

 
From: Jim Schaad <jimsch <at> augustcellars.com>
Date: Wednesday, March 27, 2013 6:43 PM
To: David McGrew <mcgrew <at> cisco.com>
Cc: "cfrg <at> irtf.org" <cfrg <at> irtf.org>
Subject: GCM nonce reuse question

 
David,

 

In doing a write up I became worried about a security property of the GCM encryption mode in the way that the JOSE group is currently using it.

 

There are known problems with not having a unique set of values for IVs and Key pairings.  Do these problems apply to having a different set of auxiliary data as well as the plain text?

 

 
Yes.  The security issues are summarized in http://tools.ietf.org/html/rfc5116#section-5.1.1  but apparently they are not described generally enough.   They should read "plaintext or associated data values".

 
Specifically the current way that GCM mode is being used in JOSE is

 

Recipient #1 authentication tag = GCM(Key, Recipient #1 data, nonce, plain text)

Recipient #2 authentication tag = GCM(Key, Recipient #2 data, nonce, plain text)

 

As the key, nonce and plain text are fixed it would produce the same encrypted text value but different authentication tags.

 

 
Can't do that.   Each invocation of the encryption operation needs a distinct nonce, unless all of the encryption operation inputs are identical.

 
Many thanks for calling this out, Jim.

 
David

 
Jim

 


Attachment (smime.p7s): application/pkcs7-signature, 4507 bytes
_______________________________________________
Cfrg mailing list
Cfrg <at> irtf.org
http://www.irtf.org/mailman/listinfo/cfrg
David McGrew (mcgrew | 28 Mar 2013 12:14
Picon
Favicon

Re: GCM nonce reuse question

Hi Jim,

From: Jim Schaad <jimsch <at> augustcellars.com>
Date: Wednesday, March 27, 2013 6:43 PM
To: David McGrew <mcgrew <at> cisco.com>
Cc: "cfrg <at> irtf.org" <cfrg <at> irtf.org>
Subject: GCM nonce reuse question

David,

 

In doing a write up I became worried about a security property of the GCM encryption mode in the way that the JOSE group is currently using it.

 

There are known problems with not having a unique set of values for IVs and Key pairings.  Do these problems apply to having a different set of auxiliary data as well as the plain text?

 


Yes.  The security issues are summarized in http://tools.ietf.org/html/rfc5116#section-5.1.1  but apparently they are not described generally enough.   They should read "plaintext or associated data values".

Specifically the current way that GCM mode is being used in JOSE is

 

Recipient #1 authentication tag = GCM(Key, Recipient #1 data, nonce, plain text)

Recipient #2 authentication tag = GCM(Key, Recipient #2 data, nonce, plain text)

 

As the key, nonce and plain text are fixed it would produce the same encrypted text value but different authentication tags.

 


Can't do that.   Each invocation of the encryption operation needs a distinct nonce, unless all of the encryption operation inputs are identical.

Many thanks for calling this out, Jim.

David

Jim

 

_______________________________________________
Cfrg mailing list
Cfrg <at> irtf.org
http://www.irtf.org/mailman/listinfo/cfrg
Laura Hitt | 22 Mar 2013 18:27

request for comments: ZSS Short Signature Scheme for SS and BN Curves

<my apologies if this was sent twice, I saw strange behavior on my end, so thought I’d try again.>

 

I have recently submitted (as an Individual) two I-Ds and would greatly appreciate any comments you are able to offer.  They pertain to the ZSS short signature scheme from bilinear pairings on supersingular elliptic curves and on Barreto-Naerhig elliptic curves.

 

http://www.ietf.org/internet-drafts/draft-irtf-cfrg-zss-00.txt

http://www.ietf.org/internet-drafts/draft-irtf-cfrg-zssbn-00.txt

 

Thank you!
Laura Hitt

 

 

 

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

Gmane