On 11/28/2009 11:49 PM, Marc Kaeser wrote:
> Dear NSS gurus, what do you think, would it really be a bad idea to
> use the key from another token, but still use the internal token to
> encrypt? When SDR is called, I could check if the token I want to use
> also provides the encryption mechanism I need. If it doesn't, I could
> use the internal token, which should always be present anyway. So I
> could be able to save the key wherever I want, even if the token
> doesn't provide the algorithms I need. I don't know if it is legal in
> the view of NSS or PKCS11 to use 2 Tokens for the same operation.
NSS supports this. They higher level calls (create context, encrypt,
finialize context) moves keys around automatically. This only works,
however, if both of the following is true:
1) the source token doesn't support key extraction -- or -- the
target token doesn't support key injection (Softoken in FIPS mode, for
instance).
- and -
2) there isn't a key exchange method (like RSA) that can be
used to move the keys.
I find it weird that the TPM has a des key, but can't do des operations.
I would be particularly surprised if that des key was extractable (can
be copied out of the token). That seems to be a potential security issue
to me.
>
> I guess I can't just change the mechanism and use another one, I don't
> see all the dependencies, but maybe there would be an overflow
> somewhere, if the cyphered text exeeds a given length, if I use
> another symetric encryption algorithm.
>
> What do you think?
Oh, the key isn't a des key, that make more sense to me. I'd have to
check, but I thought the algorithm was carried in the SDR package (DER
encoded). If it's not, that is an oversight which will certainly cause
some problems here.
bob
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
