gmane.ietf.irtf.cfrg

Internet Drafts on J-PAKE and Schnorr signature

Feng Hao — 2013-05-21T19:33:43

Hi,

I just submitted two internet drafts for J-PAKE and Schnorr signature. The latter is a building block for the former, but I separated it out as the technique could be generally useful to other applications as well. 

I appreciate any comments or suggestions.

Regards,
Feng

Filename: draft-hao-jpake
Revision: 00
Title: J-PAKE: Password Authenticated Key Exchange by Juggling
Creation date: 2013-05-21
Group: Individual Submission
Number of pages: 10
URL:             http://www.ietf.org/internet-drafts/draft-hao-jpake-00.txt
Status:          http://datatracker.ietf.org/doc/draft-hao-jpake
Htmlized:        http://tools.ietf.org/html/draft-hao-jpake-00

Abstract:
   This document specifies a Password Authenticated Key Exchange by
   Juggling (J-PAKE) protocol.  This protocol allows the establishment
   of a secure end-to-end communication channel between two remote
   parties over an insecure network solely based on a shared password,
   without requiring a Public Key Infrastructure (PKI) or any trust

Fwd: Last Call: (Additional Diffie-Hellman Tests for IKEv2) to Proposed Standard

Paul Hoffman — 2013-05-06T15:05:15

This is another opportunity for the CFRG folks to review this document before it becomes a standard. Please send any comments to the IETF mailing list, the IPsecME WG mailing list. Even simple comments of support or reasoned opposition are welcome.

Begin forwarded message:

Re: Hash substitution in PSS

Manger, James H — 2013-05-01T00:44:31

Surely a shorthand for RSASSA-PSS-params that use the 4 default values is precisely what the use of DEFAULT in its ASN.1 definition provides.

The DER-encoding of RSSASA-PSS-params that use SHA-1, MGF1 with SHA-1, a 20-byte salt, and the 0xBC trailer byte is:

  30 00

Those 2 bytes are just as short as the DER-encoding of NULL (05 00).

--
James Manger

Re: Hash substitution in PSS

Russ Housley — 2013-04-30T18:06:16


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

Re: Hash substitution in PSS

Dan Brown — 2013-04-30T17:38:58

This part of the thread has diverged from crypto.  It should probably go on the PKIX mailing list instead.  It mainly concerns interpreting ASN.1, not whether particular actions have security benefits.  For now, I respond below, just trying to establish what PKIX says about PSS hash algorithm identification in certificates (and then CFRG can discuss its merits).

[DB] RFC 3280 says "   An algorithm identifier is defined by the following ASN.1 structure:

   AlgorithmIdentifier  ::=  SEQUENCE  {
        algorithm               OBJECT IDENTIFIER,
        parameters              ANY DEFINED BY algorithm OPTIONAL  }"

and "   SubjectPublicKeyInfo  ::=  SEQUENCE  {
        algorithm            AlgorithmIdentifier,
        subjectPublicKey     BIT STRING  }"

so, the optionality of the parameters for the algorithm associated with a key inside a cert is also present in the ASN.1 definition, not just the text.  The text in 5756 simply says that parameters remain optional.

DEFAULT does not mean OPTIONAL in meaning,

Re: Hash substitution in PSS

Russ Housley — 2013-04-30T17:11:40

Peter:


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.

Russ

Re: Hash substitution in PSS

Peter Gutmann — 2013-04-30T16:43:50


I think the problem is with RFC 4055, it should have either made the entire
sequence optional if all-defaults are used or otherwise constrained it so that
at least one element must be present (making it non-optional).  At the moment
the sequence (via its ASN.1 definition) is non-optional but every parameter is
optional.  OTOH the text then makes it optional, except when it's not.  It's a
bit of a mess (uh, sorry Jim :-), I can see implementers arguing over whose
interpretation is correct...

Peter.

Re: Hash substitution in PSS

Dan Brown — 2013-04-29T19:27:41

[DB] RFC 5756 says "When the id-RSASSA-PSS object identifier
   appears in the TBSCertificate subjectPublicKeyInfo algorithm field of
   EE certificates, then the parameters field MAY include the RSASSA-
   PSS-params structure." 

RFC 4055 says "RSASSA-PSS-params  ::=  SEQUENCE  {
         hashAlgorithm      [0] HashAlgorithm DEFAULT
                                   sha1Identifier,
         maskGenAlgorithm   [1] MaskGenAlgorithm DEFAULT
                                   mgf1SHA1Identifier,
         saltLength         [2] INTEGER DEFAULT 20,
         trailerField       [3] INTEGER DEFAULT 1  }"

So, I agree with you that there is no requirement to identify RSA-PSS hash algs, but I disagree that it is precluded: because the way I read 5756 says that it is optional, not precluded.  What am I missing?

For ECDSA: I agree that 5480 precludes placing hash restriction for ECDSA in a certificate.  I, as a 5480 co-author, only reluctantly agreed to this preclusion (based on some survey comments and interoperabil

Re: Hash substitution in PSS

Igoe, Kevin M. — 2013-04-29T17:58:54

Under the assumption that the two hash functions behave as independent random
functions, the birthday problem isn't affected if more than one hash functions is
allowed.  This falls apart if the two hash functions are related, say the same 
compression function used in each, but with different initial fills.

Re: Hash substitution in PSS

Jim Schaad — 2013-04-16T04:28:45

Dan,

I will note that almost none of the recommendations in this paper would
appear to have made it into practice and in fact are actively suppressed

There is no requirement in any standard that I have seen that says that the
hash function for the mask generation and that hash function for the body
compression match. 

There is no requirement that the set of hash algorithms for a PSS RSA key be
included in a certificate (in fact it is currently actively precluded from
happening).

While interesting in theory, I find the argument made for the creation of a
new weak hash function id to be one that would be difficult to get the
real-world to accept.  And note that without this extension of the attack
there is a strong defense imposed by RSA v1.5 signatures by having the
firewall present.

Finally, I know of no research that says that the birthday attack cannot be
improved by allowing multiple hash functions to be used in the RSA-PSS, DSA
or ECDSA cases where there is no hash firewall even in the presence of
a

Re: Hash substitution in PSS

Dan Brown — 2013-04-15T20:33:40

Hi Kevin,

Somehow, I missed Kaliski's paper from CT-RSA 2002 [even though it is a reference in PKCS #1 ver. 2.1!]: you may wish to consider Kaliski's argument why RSA-PSS does not need a hash firewall, and his general recommendations about algorithm authentication (via the infrastructure, not the message).  I think the Kaliski paper shows that the issue was considered carefully, and not just something that was forgotten and fell through the cracks.

Best regards,

Dan

PS  My view on the issue has not changed much.  Overall, it is somewhat different from Kaliski's, although our conclusions for PSS are similar.


---------------------------------------------------------------------
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 rece

Re: [jose] GCM nonce reuse question

Richard Barnes — 2013-04-15T15:25:56

On Sun, Apr 14, 2013 at 9:55 PM, Manger, James H <
James.H.Manger< at >team.telstra.com> wrote:


Hey James,

Thanks for this.  I agree that Option 3 is a valid possibility, but not a
desirable one.

Option 2b is an interesting possibility.  Effectively, you would be
including a hash of the JWE (sans key) under the key wrap integrity check,
binding the key to the JWE.   I would note that we're already talking about
adding the ability to bind attributes to wrapped keys (for WebCrypto).  In
light of that, the "JWE digest" could just be included as one of those
attributes.

At the same time, this attribute should be optional, since I think there
are use cases where the CMK is not entirely ephemeral.  For example, I
think the current XMPP e2e document uses it as a session key rather than an
individual message key, so you wouldn't want to limit the key to a single
JWE.

So I think that lands us back at Option 2, with one more reason to make JWE
key wrapping the same as general key wrapping
[draft-barnes-jose-key-wrapp

Re: [jose] GCM nonce reuse question

Manger, James H — 2013-04-15T01:55:34

I think there are more options for handling multiple recipients of AEAD-secured content:


Option 3: Put all per-recipient info into one header; keep this header under the AEAD integrity check; have one nonce.
  COST: All recipients need to be known (and their key exchange info created) before the AEAD algorithm is applied.
  COST: The JWE JSON header structure needs to be adjusted (eg to have an array of recipient info) so it is not backward compatible with current drafts.
  COST: Doesn't help use cases where one recipient forwards an AEAD-secured message on to a new recipient (eg an XMPP system receives a message secured for a user and re-secures it for a specific device of that user). Changing recipients requires reapplying the AEAD operations.
  COST: Each recipient needs to see key exchange info of all recipients (privacy impact?).
  POSSIBLE-BENEFIT: Recipients, key exchanges, parameters, and content is secured as a complete unit.
 

Option 2b: Remove per-recipient info from AEAD integrity c

Re: Hash substitution in PSS

Dan Brown — 2013-04-12T18:37:17

[DB] I am sure that we agree on many points, but I think we disagree on some specific points. I will try to be clearer.  I am open to correction.

I think a hash identifier in PSS does not help.  Do you agree?  

I stand by my argument for that position: which, recall, is that if hash substitution is a problem there will also be much bigger problem, except under very unrealistic scenarios.


[DB] Which is why I propose placing the policy in the certificate, so it is available as soon as the verifier needs it.


[DB] Your last sentence is why I think we still disagree. 

The "bigger problem" (that I alluded to above, and tried to express in a previous email) is that the attacker will not need to "hijack" any benign messages to feed evil messages to that "unpatched" verifier.  Instead, if the hash is weak, the attacker can feed evil messages to the verifier, without relying any benign messages.


[DB] Yes.  

E.g. if SHA-1 gets totally broken, then any relying party Bob who continues to use SHA-1, will accept

Re: Hash substitution in PSS

Igoe, Kevin M. — 2013-04-12T00:38:47

I believe we are in agreement. Any policy put in place by the signer to require use of the strong hash when signing is useless unless the verifier also has a policy to not accept messages signed using the weak hash. Like CRLs and patches, it takes a worrisomly long time for such changes to propogate to every verifier. During the chage over period the signer is vulnerable  to having one of their benign messages "hijacked" and an evil version fed to an "unpatched" verifier.

Having the policy be part of the cert sounds like a prudent precaution, but doesn't that implicitly require the policy to be authenticated to stop Eve from meddling with it?  I suppose the bottom line is that if a commonly used hash fails disasterously then even people who have not been using that hash are vulnerable. 

This seems to say designing a protocol that allows for the use of several different hashes actually increase everyones vulnerability. That certainly is counter intuitive. Of course the discussion above assumes a truly disas

Re: Hash substitution in PSS

Dan Brown — 2013-04-11T18:28:04

Doesn't the signer need to have a policy to avoid signing with a weak hash?

Otherwise, if Alice the signer does not have such a policy, then she could sign with a weak hash.  Then Eve the adversary, under your scenario (*), could take the hash value from any message that Alice signed, and find an evil message with the same hash, and fool Bob the verifier.  What am I missing?

It seems impossible to avoid having a good policy for the signer.  I agree that it would be fantastic to avoid such a policy on algorithms, via some algorithm. 

Surely, the verifier would be able to use the same policy as the signer.  Maybe this violates the principle of being "generous in what you receive", but how appropriate is that particular principle when verifying a signature?

Why not embed the signer's policy into the signer's certificate?  That would somewhat ease the burden on the verifier, and place responsibility for the policy upon the signer, where the burden probably belongs.

Best regards,

Dan

(*) Your scenario soun

Hash substitution in PSS

Igoe, Kevin M. — 2013-04-11T17:41:58

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.

Re: What Algorithm information needs to be authenticated?

Blumenthal, Uri - 0558 - MITLL — 2013-04-10T11:57:16

This question becomes: how much extra work do we have to do (including inconvenience and pitfalls we're creating for the implementers) to force the attacker walk an extra step, and how much (if at all) those extra steps matter (e.g., 2^56 vs 2*2^56?).

--
Regards,
Uri Blumenthal                            Voice: (781) 981-1638
Cyber Systems and Technology   Fax:   (781) 981-0186
MIT Lincoln Laboratory                Cell:  (339) 223-5363
244 Wood Street                        Email: <uri< at >ll.mit.edu>
Lexington, MA  02420-9185       

Web:  http://www.ll.mit.edu/CST/

 

MIT LL Root CA: 

 <https://www.ll.mit.edu/labcertificateauthority.html>


DSN:   478-5980 ask Lincoln ext.1638

----- Original Message -----
From: Ben Laurie [mailto:ben< at >links.org]
Sent: Wednesday, April 10, 2013 05:54 AM
To: Richard Barnes <rlb< at >ipv.sx>
Cc: Jim Schaad <ietf< at >augustcellars.com>; cfrg< at >irtf.org <cfrg< at >irtf.org>
Subject: Re: [Cfrg] What Algorithm information needs to be authenticated?

On 8 April 2013 21:26, Richard Barnes <rlb< at >ipv

Re: What Algorithm information needs to be authenticated?

Ben Laurie — 2013-04-10T09:54:09

It's not worse :-)

And, in fact, DES-2 actually _is_ better than DES-1.


I don't disagree with that. So, the problem signing parameters is
designed to solve is: algorithm becomes weak, algorithm specifier is
not authenticated, manipulation of specifier is therefore trivial,
authentication/content of the message is thus more easily faked.

Now, you're going to say that if the specifier is authenticated by the
broken algorithm, then it isn't authenticated anyway - and my response
is that the more stuff the attacker has to get to come out right, the
harder his job is.

Without knowing what the specific break is, its hard to say whether
this is going to matter in practice or not. But ... it seems unlikely
to make matters worse.

Re: What Algorithm information needs to be authenticated?

Richard Barnes — 2013-04-08T20:26:13



So it's better to do DES twice than just once, right [1]?  Or double-ROT13?
 :)

Seriously, if we're going to design cryptographic security mechanisms, we
should know what problem we're trying to solve.  It is easy in this space
to do more work for no benefit.

--Richard

[1] <http://en.wikipedia.org/wiki/Meet_in_the_middle_attack>
_______________________________________________
Cfrg mailing list
Cfrg< at >irtf.org
http://www.irtf.org/mailman/listinfo/cfrg

Re: What Algorithm information needs to be authenticated?

Richard Barnes — 2013-04-08T20:19:03



Assuming you don't care about being ciphertext-compatible with anything
else.  Not sure if that's a requirement, but it seems like it could be a
handy feature.





What you describe is precisely what JOSE does, and what creates the
complexity.  The parameters are Base64 encoded before inclusion in the AAD.
 The complexity is on the receiver end, when I have to decode the
base64-encoded parameters, but also keep the encoded version around for
inclusion as AAD.






That's not really a rebuttal.  The point is that the only reason to add
complexity is to achieve some security benefit.

The only benefit that has been proposed so far is John's observation about
RFC 6211, which makes more sense as an *optional* feature (see point 5),
since most algorithms have no need of it.





Let me expand a little on how integrity reduces efficiency.  In particular,
how integrity on per-recipient parameters reduces efficiency.

A JOSE encrypted object (in the current format) comprises a logical 5-tuple
(parameters, wrapp