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. > """ > > > >
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
