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