for what it’s worth: +1 to saag I’d like to see both OAEP and PSS be more widely adopted.
spt On Nov 20, 2013, at 12:25, Stephen Farrell <[email protected]> wrote: > > 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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ perpass mailing list [email protected] https://www.ietf.org/mailman/listinfo/perpass
