Actually, I was not completly mistaken...
Only RSA PKCS#1 signs the digestInfo along with the hash.
ECDSA only uses the hash value. (I don't know what GOST does.)
This has been verified using NSS-3.12.7 with Thunderbird to
create smime signed e-mail. The message can be verified by
NSS, OpenSSL smi
Oops, I was mistaken in my previous note, the prefix is sent to be signed.
Thunderbird with NSS calling opensc-pkcs11 for RSA 2048 bit key:
1322: C_Sign
[in] hSession = 0xf1a2d160
[in] pData[ulDataLen] f24f9010 / 35
30213009 06052B0E 03021A05 0004145C 1362A567 70C3E95E 0B5881B8 5AA257BC
On 12/14/2010 5:29 AM, Martin Paljak wrote:
>
> On Dec 14, 2010, at 1:21 PM, Andre Zepezauer wrote:
>
>> On Tue, 2010-12-14 at 13:07 +0200, Martin Paljak wrote:
>>>
>>> Right now I guess that the stripping of input data, coming from an
>>> application (meaning that the calling application will e
> What could be the "ISO version" of SHA1 + PKCS#1 + RSA Stef was
> referencing to in the e-mail I referenced in this thread?
Maybe that one:
[1] http://www.alvestrand.no/objectid/1.2.840.113549.1.1.5.html
Assuming the following definition
ASN1-ENCODE ::= SEQUENCE {
algorithm OBJECT IDENTI
On Tue, 2010-12-14 at 13:29 +0200, Martin Paljak wrote:
> On Dec 14, 2010, at 1:21 PM, Andre Zepezauer wrote:
>
> > On Tue, 2010-12-14 at 13:07 +0200, Martin Paljak wrote:
> >>
> >> Right now I guess that the stripping of input data, coming from an
> >> application (meaning that the calling appl
On Dec 14, 2010, at 1:21 PM, Andre Zepezauer wrote:
> On Tue, 2010-12-14 at 13:07 +0200, Martin Paljak wrote:
>>
>> Right now I guess that the stripping of input data, coming from an
>> application (meaning that the calling application will expect the data to be
>> exactly the same when verify
On Tue, 2010-12-14 at 13:07 +0200, Martin Paljak wrote:
> Hello,
> On Dec 14, 2010, at 11:11 AM, Andre Zepezauer wrote:
> > to make a long story short, there is an (easy?) way to get ride of the
> > whole flag magic.
> >
> > It would require more attention on TokenInfo.SupportedAlgorithms and
> >
Hello,
On Dec 14, 2010, at 11:11 AM, Andre Zepezauer wrote:
> to make a long story short, there is an (easy?) way to get ride of the
> whole flag magic.
>
> It would require more attention on TokenInfo.SupportedAlgorithms and
> implementation of CKA_ALLOWED_MECHANISMS.
It is not implemented by Ope
Hello Martin,
to make a long story short, there is an (easy?) way to get ride of the
whole flag magic.
It would require more attention on TokenInfo.SupportedAlgorithms and
implementation of CKA_ALLOWED_MECHANISMS. That's it. When these to
mechanism are in place, things would still happen auto-mag
On 12/13/2010 1:01 PM, Martin Paljak wrote:
> Hi,
>
> On Dec 13, 2010, at 6:36 PM, Douglas E. Engert wrote:
>> On 12/13/2010 3:53 AM, Martin Paljak wrote:
>>> Hello,
>>>
>>> I'm somewhat confused by how OpenSC interprets the different algorithm
>>> flags in PKCS#11 [1] and in the generic libopens
Hi,
On Dec 13, 2010, at 6:36 PM, Douglas E. Engert wrote:
> On 12/13/2010 3:53 AM, Martin Paljak wrote:
>> Hello,
>>
>> I'm somewhat confused by how OpenSC interprets the different algorithm
>> flags in PKCS#11 [1] and in the generic libopensc PKCS#15 code[2].
>> Could somebody explain your view
On 12/13/2010 3:53 AM, Martin Paljak wrote:
> Hello,
>
> I'm somewhat confused by how OpenSC interprets the different algorithm
> flags in PKCS#11 [1] and in the generic libopensc PKCS#15 code[2].
> Could somebody explain your view or what I get wrong.
>
> - SC_ALGORITHM_RSA_RAW (CKM_RSA_X509) -
Hello,
I'm somewhat confused by how OpenSC interprets the different algorithm
flags in PKCS#11 [1] and in the generic libopensc PKCS#15 code[2].
Could somebody explain your view or what I get wrong.
- SC_ALGORITHM_RSA_RAW (CKM_RSA_X509) - card is capable of raw RSA,
meaning it is willing to take
13 matches
Mail list logo
