You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@santuario.apache.org by Bolcina Ivan <Iv...@snt.si> on 2010/01/05 13:18:51 UTC
FW:
Hi.
I have a encrypted xml.
I managed to decrypt xml with this key
Alias=|Tomaz 3 Grenko's Encryption Certificate|
is certificate=|CN=Tomaz 3 Grenko, O=TestCA, C=si
is private key=|true
key=RSAPrivateKey [size=2048 bits, type=Exchange, container=4|3|1|0|X8AQID1iQeev7AsBo6NoVQ==]
key.algorithm=RSA
key.format=null
but not with this.
Alias=|Tomaz 3 Grenko's Verification Certificate|
is certificate=|CN=Tomaz 3 Grenko, O=TestCA, C=si
is private key=|true
key=RSAPrivateKey [size=2048 bits, type=Signature, container=4|3|2|0|X8AQID1iQeev7AsBo6NoVQ==]
key.algorithm=RSA
key.format=null
I noticed that key type is different. Key is in both cases stored on smartcard, that is accessed via SUN MSCAPI provider.
Is it theoretically even possible to decrypt using second key?
Thanks in advance,
ivan
RE: FW:
Posted by Scott Cantor <ca...@osu.edu>.
Arshad Noor wrote on 2010-01-05:
> In the software that I write, Scott, I enforce this. From
> experience, I also know that browsers and S/MIME User Agents
> (Outlook, Thunderbird) also enforce this.
Those are applications. If they want to enforce it, that's fine, but it
doesn't belong in an XML Security library (for example).
> While I presume that cryptographic frameworks such as JCE,
> CAPI, CNG, etc. also enforce this, I do not make assumptions
> about the degree to which they enforce keyUsage bits.
The underlying crypto shouldn't be enforcing anything. X.509 is an
application construct, not a cryptographic component.
It's pointless to make somebody extract the key themselves and hand it to
the same code, and that's what they'll do if the certificate doesn't work as
a way of getting the key in.
-- Scott
RE: FW:
Posted by Bolcina Ivan <Iv...@snt.si>.
Hi.
I use Apache XML encryption.
I get key from SUN MS CAPI provider. It gets key from Windows Certificate store, which gets key from smartcard.
So I guess the smart card reject decryption. The actual exception I get is this:
org.apache.xml.security.encryption.XMLEncryptionException: No Key Encryption Key loaded and cannot determine using key resolvers
at org.apache.xml.security.encryption.XMLCipher.decryptToByteArray(XMLCipher.java:1483)
at org.apache.xml.security.encryption.XMLCipher.decryptElement(XMLCipher.java:1388)
at org.apache.xml.security.encryption.XMLCipher.doFinal(XMLCipher.java:825)
BR,ivan
-----Original Message-----
From: Arshad Noor [mailto:arshad.noor@strongauth.com]
Sent: Tuesday, January 05, 2010 4:06 PM
To: security-dev@xml.apache.org
Subject: Re: FW:
In the software that I write, Scott, I enforce this. From
experience, I also know that browsers and S/MIME User Agents
(Outlook, Thunderbird) also enforce this.
While I presume that cryptographic frameworks such as JCE,
CAPI, CNG, etc. also enforce this, I do not make assumptions
about the degree to which they enforce keyUsage bits. It
ensures that I don't get surprised later on. I presume the
developers of the applications I've listed above follow the
same rule.
Arshad Noor
StrongAuth, Inc.
Scott Cantor wrote:
> Arshad Noor wrote on 2010-01-05:
>> Not with well-behaved software that conform to PKIX standards.
>>
>> Signing keys are meant to only sign objects, while "Exchange"
>> keys are meant for encryption/decryption. That is the reason
>> why decryption works with the first, but not with the second.
>
> Out of curiosity, what layer of software is enforcing this? It certainly
> shouldn't be the core encryption/decryption code.
>
> -- Scott
>
>
Re: FW:
Posted by Arshad Noor <ar...@strongauth.com>.
In the software that I write, Scott, I enforce this. From
experience, I also know that browsers and S/MIME User Agents
(Outlook, Thunderbird) also enforce this.
While I presume that cryptographic frameworks such as JCE,
CAPI, CNG, etc. also enforce this, I do not make assumptions
about the degree to which they enforce keyUsage bits. It
ensures that I don't get surprised later on. I presume the
developers of the applications I've listed above follow the
same rule.
Arshad Noor
StrongAuth, Inc.
Scott Cantor wrote:
> Arshad Noor wrote on 2010-01-05:
>> Not with well-behaved software that conform to PKIX standards.
>>
>> Signing keys are meant to only sign objects, while "Exchange"
>> keys are meant for encryption/decryption. That is the reason
>> why decryption works with the first, but not with the second.
>
> Out of curiosity, what layer of software is enforcing this? It certainly
> shouldn't be the core encryption/decryption code.
>
> -- Scott
>
>
RE: FW:
Posted by Scott Cantor <ca...@osu.edu>.
Arshad Noor wrote on 2010-01-05:
> Not with well-behaved software that conform to PKIX standards.
>
> Signing keys are meant to only sign objects, while "Exchange"
> keys are meant for encryption/decryption. That is the reason
> why decryption works with the first, but not with the second.
Out of curiosity, what layer of software is enforcing this? It certainly
shouldn't be the core encryption/decryption code.
-- Scott
Re: FW:
Posted by Arshad Noor <ar...@strongauth.com>.
Not with well-behaved software that conform to PKIX standards.
Signing keys are meant to only sign objects, while "Exchange"
keys are meant for encryption/decryption. That is the reason
why decryption works with the first, but not with the second.
Arshad Noor
StrongAuth, Inc.
Bolcina Ivan wrote:
> Hi.
>
> I have a encrypted xml.
>
>
>
> I managed to decrypt xml with this key
>
> Alias=|Tomaz 3 Grenko's Encryption Certificate|
>
> is certificate=|CN=Tomaz 3 Grenko, O=TestCA, C=si
>
> is private key=|true
>
> key=RSAPrivateKey [size=2048 bits, type=*Exchange*,
> container=4|3|1|0|X8AQID1iQeev7AsBo6NoVQ==]
>
> key.algorithm=RSA
>
> key.format=null
>
>
>
> but not with this.
>
>
>
> Alias=|Tomaz 3 Grenko's Verification Certificate|
>
> is certificate=|CN=Tomaz 3 Grenko, O=TestCA, C=si
>
> is private key=|true
>
> key=RSAPrivateKey [size=2048 bits, type=*Signature*,
> container=4|3|2|0|X8AQID1iQeev7AsBo6NoVQ==]
>
> key.algorithm=RSA
>
> key.format=null
>
>
>
> I noticed that key type is different. Key is in both cases stored on
> smartcard, that is accessed via SUN MSCAPI provider.
>
>
>
> Is it theoretically even possible to decrypt using second key?
>
>
>
> Thanks in advance,
>
> ivan
>