OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

pkcs11 message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: RE: [pkcs11] Proposal for recommendation/best practice on protection against Padded Oracle attacks

Hi Mike,


The article you are (I think) referring to is an improvement to the attack, and the mitigation against the improvement is to disallow support for v1.5.  If we recommended only to use v2 with OAEP, it would not be enough.  That is why the recommendation is to both move to v2 and to disallow v1.5.  While you may intend to follow the “should be used with one padding scheme” if the PKCS11 implementation allows for both padding schemes to be used, you are still vulnerable (the attacker won’t be as nice).


I have no preference in where it should go, so the usage guide is fine with me.






From: pkcs11@lists.oasis-open.org [mailto:pkcs11@lists.oasis-open.org] On Behalf Of Michael StJohns
Sent: Wednesday, June 26, 2013 3:24 PM
To: pkcs11@lists.oasis-open.org
Subject: Re: [pkcs11] Proposal for recommendation/best practice on protection against Padded Oracle attacks


On 6/26/2013 10:48 AM, Duane, Chris wrote:

Hi Oscar,


The recommendation to use OAEP (optimal asymmetric encryption padding), as the name implies, is referring to a padding scheme for encryption.  Essentially the attack in question is a side channel attack against the padding, and moving to v2 with OAEP itself is not sufficient unless you also disable support for 1.5.





Hi Chris -

So to answer Oscar's question - this is for encryption only.

I found an article that suggests that even OAEP is susceptible to side channel attacks against padding.

The more general guidance - and this is in line with NIST's FIPS 140-2 stuff - is that a given RSA key pair should only be used for either signature/verify or encrypt/decrypt and not both; and that it should be used with one and only one padding scheme.

That sounds like a usage guide thing to me rather than putting it into the mandatory enforcement by token category.

Later, Mike

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]