I agree that OAEP is better and would be a better MTI. But that's been tried, and each time, current deployment considerations trumped it and specs choose pkcs#1v1.5.
I may well be wrong but I suspect someone putting in a bit of concerted work on coding will be needed before OAEP will get accepted, esp since the attacks are all million-message attacks so far. Or am I out of date in terms of which libraries now have OAEP in 'em? Lastly, while that is a worthwhile and good security thing to do, I think the linkage to pervasive monitoring isn't that strong, so maybe this'd be a better topic for the saag list? S On 11/20/2013 05:18 PM, Richard Barnes wrote: > That makes sense. Would you say the same in the signature domain, i.e., > PKCS#1 v1.5 -> PSS? > > > On Wed, Nov 20, 2013 at 12:07 PM, Russ Housley <[email protected]> wrote: > >> I do not know of any place where RSA-OAEP has been called out as the >> mandatory to implement algorithm, but there are many places where PKCS#1 >> v1.5 still enjoys this status. I suggest we make RSA-OAEP the mandatory to >> implement algorithm in our specifications. >> >> Russ >> >> >> On Nov 20, 2013, at 11:09 AM, Richard Barnes wrote: >> >> What are you proposing be done, besides supporting OAEP in new specs or >> back-porting it to old ones? In order to make people use OAEP, we would >> need to call in the protocol police. >> >> >> On Wed, Nov 20, 2013 at 10:49 AM, Russ Housley <[email protected]>wrote: >> >>> We have known for a ver long time that PKCS #1 Version 1.5 (see RFC 2313) >>> is vulnerable to adaptive chosen ciphertext attacks when applied for >>> encryption purposes. Exploitation reveals the result of a particular RSA >>> decryption, requires access to an oracle which will respond to a hundreds >>> of thousands of ciphertexts), which are constructed adaptively in response >>> to previously-received replies providing information on the successes or >>> failures of attempted decryption operations. As a result, the attack >>> appears significantly less feasible to perpetrate in store-and-forward >>> environments than for interactive ones. >>> >>> PKCS #1 Version 2.0 and Version 2.1 (see RFC 3447) include RSA-OAEP to >>> address this situation, but we have seen very little movement toward >>> RSA-OAEP. While we are reviewing algorithm choices in light of the >>> pervasive surveillance situation, I think we should take the time to >>> address known vulnerabilities like this one. If we don't, then we are >>> leaving an partially open door for a well funded attacker. >>> >>> Russ >>> _______________________________________________ >>> perpass mailing list >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/perpass >>> >> >> _______________________________________________ >> perpass mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/perpass >> >> >> >> _______________________________________________ >> perpass mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/perpass >> >> > > > > _______________________________________________ > perpass mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/perpass > _______________________________________________ perpass mailing list [email protected] https://www.ietf.org/mailman/listinfo/perpass
