Dave Townsend wrote:
Then I would just use the database and use extracting the key as a backup. That would also allow storing the keys in a token without any modification of your code.Hi Bob, thanks for all your help by the way, got me much further so far.Robert Relyea wrote:You really only want to store and retrieve the private keys if you you need to transport them (or back them up). Doing the latter needs to be handled carefully, and can be a source of errors in your protocol.This is fine for my uses I think. So long as the private key is somewhere safe that is backupable (the nss certificate database is fine by me) then thats all good.
No, there usually aren't very many keys. KeyID's are a unique handle to the private keys, nickname/labels aren't always set.A better way to handle it (if you absolutely must use bare keys), is store your private keys as persistant keys. You can use the KeyID and the slot the key is stored in to find the key again (PK11_FindKeyByID to find it PK11_GetLowLevelKeyIDForPrivatekey() to get the KeyID).I'm not totally sure I follow you. Let me just quickyl explain what I am wanting to present to the user. They should pretty much not have to worry about certificates or anything like that. All that matters is that they can create a public/private key pair and that my app can show them a list of what key pairs they have created before and then use them.I have this pretty much working but I think I've slightly hacked it. What I've done is assigned a nickname to the private key when it's created. That seems nice until I come to retrieve the key, it seems there isnt a way to retrieve a key by nickname instead I just have to enumerate all keys till I find the one with the nickname. This isn't so bad, there shouldn't be many keys but maybe I'm going about this the wrong way?
Certs are basically bindings of identity to a public key, so the cert has the user's identity (in the form of a Distinguished name), they public key, some house keeping (the identity of the CA that verified the cert, expiration, etc.), usually some optional information telling what the certificate is good for (signing, encryption, code signing, authentication, etc.), and a signature. Usually the user doesn't bother looking at the cert itself, the cert contains enough information to allow the software to process it and verify it's validity. They help with thing like validating a signature. With a certificate, I can validate a signature was signed by the identity specified in the certificate without having to trust a bare public keys. Most protocols that need to scale beyond 20 or 30 people need to use something like certificates.Usually NSS uses the certificate. There are functions to help you find the most appropriate certificate, and then from that certificate find the private key that is associated with it.I probably have the wrong view of certificates, but my understanding is that they have all sorts of other associated data about then, CN etc and more crucially expiries. Is this right or am I wrong? In which case I'd happily switch over to certificates if that helps me achieve my above goal.
One other final thing I'm stumbling over is key and hash types. I recognise the names RSA and DSA but is there a particular advantage of using one over the other?RSA and DSA have different performance characteristics, RSA has a fairly fast verification compared to signing. It's also more widely understood. At one time DSA was the only one of the two that were not patent encumbered.
And likewise when I'm signing my data should I hash it using MD5, SHA-1 or any of the other SHAs. I think I read somewhere that RSA keys should be used with MD5 hashes and DSA with SHA-1, is this right?I would always use at least SHA-1. DSA can only use exactly SHA-1. Both MD-5 and SHA-1 have been shown to be weak against collision attacks (attacks in which I can generate 2 different messages that hash to the same value), though they are still strong against preimage (trying to calculate a second message the hashes to the same value of a given message). If you're protocol depends on collision resistance, then you should think about using SHA-256 or greater. The only issue is there is still a fair amount of code that does not support the larger hash functions, so if you need to interoperate with that older code you will need to stick to SHA-1, otherwise I strongly encourage you to use the longer SHA algorithms.
bob
Dave _______________________________________________ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
