On Tuesday 04 of December 2012 16:07:26 Nicholas Cole wrote: > On Tue, Dec 4, 2012 at 12:19 PM, Hubert Kario <h...@qbs.com.pl> wrote: > > On Monday 03 of December 2012 12:41:10 Hauke Laging wrote: > >> Hello, > >> > >> are there arguments for preferring either > >> > >> a) having one RSA subkey for decryption only and one for signing only > >> > >> or > >> > >> b) having only one RSA subkey for both decryption and signing? > >> > >> Do any problems arise with the smartcard if the same key shall do > >> different > >> tasks? > > > > Keys can become "used up" so it entirely depends on how often you use it. > > > > What I mean by that, is that any signing operation leaks some information > > about the key used for signing (generally far less than few tens of a > > bit). > > If you have signed tens of thousands of documents with it, an attacker can > > recover substantial portion of the key and speed up the key recovery. > > Do you have a reference for this?
I don't have one at hand and can't find one through quick googling. I'm not sure where I've got this info from, it may have been in Applied Cryptography. Basically anything I have to back this is the general recommendation for TSA used in SignServer: http://www.signserver.org/manual/complete.en.html#Limiting%20the%20number%20of%20signatures but unfortunately they don't provide any rationale for this either. Logically though, if you have a known function that takes two parameters, A and B. You know B, function's output and size of A, then provided enough pairs of B and output you theoretically can say something about A (as A is constant). Of course, this works only because RSA is reversible and you know A' -- the public part of key. The problem is defining "enough pairs", probably the 100000 I mentioned is quite conservative. On one hand, such a limit is hardly a problem for anybody but automatic systems (which can be easily configured to rotate keys), on the other hand, this attack was described as purely theoretical AFAICR. > I thought the major reason to use > separate signing/encryption keys was that if a user could be persuaded > to sign a chosen encrypted text with the same key, the decryption key > would be revealed. How do you propose an attacker could force me to sign data I already encrypted? In both cases (encryption, signature) I don't process the data itself but either its hash or random data used as key for symmetric cipher. I may be wrong here, but I'm quite sure such situation is simply impossible to happen with GPG or other standard protocols (S/MIME, PKCS) > http://security.stackexchange.com/questions/1806/why-should-one-not-use-the- > same-asymmetric-key-for-encryption-as-they-do-for-sig See CodesInChaos comment Regards, -- Hubert Kario QBS - Quality Business Software 02-656 Warszawa, ul. Ksawerów 30/85 tel. +48 (22) 646-61-51, 646-74-24 www.qbs.com.pl _______________________________________________ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users