I need to re read Kaliski's paper from CT-RSA 2002 On Hash Function Firewalls in Signature Schemes to see how difficult is difficult. http://bookzz.org/book/2302665/6f0670
This is not exactly a new issue. I can see other ISEG discussions over the years on this and related topics. There seems to be a padding consideration for PSS that also acts as a mitigation to prevent the recipient from interpreting the hash to be shorter than was sent. Having the correct security considerations will help implementers. The paper above is referenced by a number of RFC, but I see some people did not consider the mitigation effective as the other uses of PSS do not tie the MGF to the signing hash as we did in JWA. I am just getting on a flight, and will have a look at it tomorrow. John B. On Sep 21, 2014, at 9:31 PM, Richard Barnes <[email protected]> wrote: > > > On Sun, Sep 21, 2014 at 8:59 PM, John Bradley <[email protected]> wrote: > Also with PSS the attack is largely mitigated if the mask function uses the > same hash as the message. http://tools.ietf.org/html/rfc3447#page-29 > > JWA sec 3.5 requires SHA2 MGF functions for SHA2 message hashes with the > equivalent length. > > If the same is done when SHA3 is added then I think PSS is not as susceptible > to a substitution attack as it might look on the surface. > > Certainly, having to change the MGF makes things much harder for the > attacker. However, in principle an attacker with a sufficiently broken hash > algorithm could compute a preimage for the message *and* the MGF. As RFC > 3447 says: > > "it will be difficult for an opponent to substitute a different hash function" > > ... using "difficult" in the sense of "way harder than if we hadn't", not in > the sense of "just as hard as forging the signature". > > --Richard > > > > Sorry I just remembers that there was that mitigation for PSS. > > John B. > > On Sep 21, 2014, at 8:47 PM, John Bradley <[email protected]> wrote: > >> I like the general direction. >> >> One question, wouldn't the recipient of a PSS signature detect the >> substitution of SHA-284 with SHA-256 due to the different key length. >> >> I was under the perhaps mistaken impression that the key lengths needed to >> be the same and just the alg different eg SHA3 and SHA2 keys of the same >> length. >> >> If that is the case we probably have not defined any algs currently that may >> be subject to this. That is not to say that we shouldn't warn people as new >> algs are defined. >> >> John B. >> >> >> On Sep 21, 2014, at 8:32 PM, Richard Barnes <[email protected]> wrote: >> >>> I think I may have erred by trying to write a treatise on which algorithms >>> are vulnerable :) Here's some updated text, trying to be more concise. >>> >>> Jim: Your points about SHA-256 vs. SHA-512/256 and SHA-256 vs. SHA-3 don't >>> really apply, since JOSE hasn't defined algorithm identifiers for >>> SHA-512/256 or SHA-3. >>> >>> """ >>> # Signature Algorithm Protection >>> >>> In some usages of JWS, there is a risk of algorithm substitution attacks, >>> in which an attacker can use an existing signature value with a different >>> signature algorithm to make it appear that a signer has signed something >>> that he actually has not. These attacks have been discussed in detail in >>> the context of CMS {{RFC 6211}}. The risk arises when all of the following >>> are true: >>> >>> >>> * Verifiers of a signature support multiple algorithms of different >>> strengths >>> >>> * Given an existing signature, an attacker can find another payload that >>> produces the same signature value with a weaker algorithm >>> >>> * In particular, the payload crafted by the attacker is valid in a given >>> application-layer context >>> >>> For example, suppose a verifier is willing to accept both "PS256" and >>> "PS384" as "alg" values, and a signer creates a signature using "PS256". >>> If the attacker can craft a payload that results in the same signature with >>> SHA-256 as the signature with SHA-384 of the legitimate payload, then the >>> "PS256" signature over the bogus payload will be the same as the "PS384" >>> signature over the legitimate payload. >>> >>> There are several ways for an application using JOSE to mitigate algorithm >>> substitution attacks >>> >>> The simplest mitigation is to not accept signatures using vulnerable >>> algorithms: Algorithm substitution attacks do not arise for all signature >>> algorithms. The only algorithms defined in JWA >>> {{I-D.ietf-jose-json-web-algorithms}} that may be vulnerable to algorithm >>> substitution attacks is RSA-PSS ("PS256", etc.). An implementation that >>> does not support RSA-PSS is not vulnerable to algorithm substitution >>> attacks. (Obviously, if other algorithms are added, then they may >>> introduce new risks.) >>> >>> In addition, substitution attacks are only feasible if an attacker can >>> compute pre-images for the weakest hash function accepted by the recipient. >>> All JOSE algorithms use SHA-2 hashes, for which there are no known >>> pre-image attacks as of this writing. Until there begin to be attacks >>> against SHA-2 hashes, even a JOSE implementation that supports PSS is safe >>> from substitution attacks. >>> >>> Without restricting algorithms, there are also mitigations at the JOSE and >>> application layer: At the level of JOSE, an application could require that >>> the "alg" parameter be carried in the protected header. (This is the >>> approach taken by RFC 6211.) The application could also include a field >>> reflecting the algorithm in the application payload, and require that it be >>> matched with the "alg" parameter during verification. (This is the approach >>> taken by PKIX {{RFC5280}}.) >>> >>> Of these mitigations, the only sure solution is the first, not to accept >>> vulnerable algorithms. Signing over the "alg" parameter (directly or >>> indirectly) only makes the attacker's work more difficult, by requiring >>> that the bogus payload also contain bogus information about the signing >>> algorithm. They do not prevent attack by a sufficiently powerful attacker. >>> """ >> > >
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
