Using the same key for signing as for encryption gets vastly weaker security guarantees (i.e., Gap-DH for EC).There is no excuse for a new cryptosystem/deployment to do this.

- dlg
Y!-e2e

PS. Is messaging@ still forging 'From:' headers?

At Feb 11, 2015, 7:18:40 AM, Mike Hearn<'[email protected]'> wrote:
Are you using the same key for signing as for encryption with this
setup, or does your S/MIME cert somehow have a separate signing key from
an encryption key?

With the free Comodo certs you get one key. But sometimes for other setups you have two keys, one for signing and one for encryption.

I think the idea behind this is that the signing key has no copies and this policy can be enforced by the HSM firmware that generates it. Because, if you lose a signing key, you can just revoke it and generate a new one. The encryption key is generated in a different way that would allow for backups and copies to be made. Thus signing with the encryption key gives you lower assurance, because someone might have stolen it from a backup. But with the signing/"non repudiation" key, there are no backups anywhere and thus it's safer.

This can be enforced with key usage flags in the certificate.

My gut feeling is that this complexity causes more problems than it solves. Before the dreaded OS X Yosemite upgrade, my signing stick worked for encryption just fine. Post Yosemite now the OS seems to think it's only usable for signing. I suspect the key usage restrictions are somehow involved.
_______________________________________________
Messaging mailing list
[email protected]
https://moderncrypto.org/mailman/listinfo/messaging

Reply via email to