Re: [cryptography] Client TLS Certificates - why not?

2013-03-06 Thread Martin Paljak
On Wed, Mar 6, 2013 at 10:40 AM, James A. Donald wrote: > Can you implement your above design while hiding the keys in urls, rather > than inflicting them on the suffering user? There's a saying in Estonian, literally translated: "who wants to eat sausages is better off not knowing how sausages a

Re: [cryptography] Client TLS Certificates - why not?

2013-03-05 Thread Martin Paljak
On Tue, Mar 5, 2013 at 2:08 PM, ianG wrote: > This whole argument that certs aren't portable across devices is something > of a strawman. Companies deploy SSL certs across accelerators all the time, > so why not client certs? The reason is the assumptions that are designed to > stop you doing th

Re: [cryptography] Client TLS Certificates - why not?

2013-03-05 Thread Martin Paljak
Hello, On Mon, Mar 4, 2013 at 9:22 AM, wrote: > Can anyone enlighten me why client TLS certificates are used so rarely? It > used to be a hassle in the past, but now at least the major browsers offer > quite decent client cert support, and seeing how most people struggle with > passwords, I don'

Re: [cryptography] Key extraction from tokens (RSA SecurID, etc) via padding attacks on PKCS#1v1.5

2012-07-05 Thread Martin Paljak
Hello, On Tue, Jul 3, 2012 at 1:56 AM, Michael Nelson wrote: > If the target HSM notices that the encrypted blob is corrupted, then it will > give you an error message. This is a leak of information, but that's life. > Normally such a covert channel would at most help you to mount a brute for

Re: [cryptography] PKI in practice: is there a list of ("widely" deployed) client-certs-issuing CAs?

2012-05-01 Thread Martin Paljak
On Sat, Apr 28, 2012 at 05:25, ianG wrote: > Well, to the extent above.  My db has a table for all certs, and a table for > all users, with a join by cert identifiers between the two tables. I hope you actually bind the actual public key instead of any kind of identifiers? Or would that not be a

Re: [cryptography] airgaps in CAs

2011-12-08 Thread Martin Paljak
On 12/9/11 6:16 , Peter Gutmann wrote: > Arshad Noor writes: > >> Every private PKI we have setup since 1999 (more than a dozen, of which a >> few >> were for the largest companies in the world) has had the Root CA on a >> non-networked machine with commensurate controls to protect the CA. >

Re: [cryptography] fyi: Sovereign Keys: an EFF proposal for more secure TLS authentication

2011-11-26 Thread Martin Paljak
No, they had ecc and I saw no references to hash chains or trees. But that would be a right/interesting direction. On Nov 27, 2011 12:42 AM, "Adam Back" wrote: > I only skimmed the high level but I presume they would be using a merkle > hash-tree and time-stamp server or something like that so it

Re: [cryptography] -currently available- crypto cards with onboard key storage

2011-10-30 Thread Martin Paljak
On 10/28/11 4:57 , Werner Koch wrote: > On Fri, 28 Oct 2011 11:10, mar...@martinpaljak.net said: > >> PKCS#11 but also open source drivers (also free, in the sense of "free >> software" vs "open source software") is as good excuse to reject PKCS#11 > > In 99% percent of all cases Open Source and

Re: [cryptography] -currently available- crypto cards with onboard key storage

2011-10-28 Thread Martin Paljak
On 10/27/11 3:02 , Werner Koch wrote: > On Thu, 27 Oct 2011 11:15, mar...@martinpaljak.net said: > >> I don't know about PGP(.com), but GnuPG is picky about hardware key >> containers. Things like PKCS#11. > > For the records: That is simply not true. We only demand an open API > specification f

Re: [cryptography] -currently available- crypto cards with onboard key storage

2011-10-27 Thread Martin Paljak
Hello, On Wed, Oct 26, 2011 at 21:12, Thor Lancelot Simon wrote: > I find myself needing a crypto card, preferably PCIe, with onboard > key storage.  The application is PGP, I don't know about PGP(.com), but GnuPG is picky about hardware key containers. Things like PKCS#11. > As far as I know,