If someone has the encrypted key data, they can feed that data anywhere they wish. In that case, they can feed it into processing systems that do not enforce rate-limiting. Thus, there is no way to do what Dave Paxton suggests in any case.
-Kyle H On September 5, 2014 12:51:04 PM PST, flgirl799901 <flgirl799...@gmail.com> wrote: >I most certainly did NOT hack into anything. I thank you so much for >your response, but deplore your rudeness > > >Sent via the Samsung GALAXY S® 5, an AT&T 4G LTE smartphone > > >-------- Original message -------- >From: dave paxton <dpax...@me.com> >Date:09/05/2014 3:33 PM (GMT-05:00) >To: openssl-users@openssl.org >Cc: >Subject: Re: Certificate pass phrase brute force... > >That is easy. Just restrict the number of different passwords per day. >Any account. Thus the old school brute force idea passes out the >window. Most of what you are looking at it a signing issue. Basically >one person does a transaction and the the other person verifies it. >They do the DSA and thus they are the same person as they should be. >That is the idea anyway. As far as accounts go that hold those keys >then you have the few problems. Did the client get hacked or you? Who >can hack the account like our recent icloud picture issue. All of this >is lazy programming. It is really a matter of how certain you are of >the client and how you want to make sure they are who they are. No >biggie. Dave. > > >On 9/5/2014 1:03 PM, flgirl799901 wrote: >How do I unsubscribe from all of this? > > >Sent via the Samsung GALAXY S® 5, an AT&T 4G LTE smartphone > > >-------- Original message -------- >From: Gregory Sloop <gr...@sloop.net> >Date:09/05/2014 1:36 PM (GMT-05:00) >To: openssl-users@openssl.org >Cc: >Subject: Certificate pass phrase brute force... > >General question: > >I've done a number of searches and can't find a lot about the subject. >[I've searched the list archives too...at least as best I could.] > >In several cases, the most obvious being OpenVPN, I use client >certificates generated by openssl, with a pass-phrase [password]. This >means that if I ever have someone misplace the certificate, it can't be >used without the password. [And I have little control about what users >do with such things - they download and install software they >shouldn't; They have unknown users use their machines; They get their >machines/phones/tablets stolen etc.] > >However, if someone loses control of the certificate, I need to >consider the safety of the certificate. [And I have to assume I'll >never know they lost control of it either.] Assume users are practicing >reasonable security and it's unlikely an attacker will obtain the >pass-phrase when they obtain the certificate. [A hard/bad thing >to assume, I realize.] > >So, I've seen reports of Elcomsoft's tool to attempt ~6K passwords a >second against a certificate file. Let's assume two orders of magnitude >better performance for a fairly determined attacker, and we're at 600K >passwords per second. Three gets us 6M a second. > >But even at 6M a sec, a non dictionary guessable pass-phrase of 10 >characters will require ~380 years to break - which isn't too >bad, IMO. [Assume a 52 character set. This obviously gets complicated >since the pass-phase probably isn't completely random etc...but >lets assume a theoretical 52 character random set.] > >But since I can't find any reputable source for this kind of >data, I'm questioning the assumptions above. > >Can anyone give me some pointers at a reputable attempt at quantifying >this? [The brute-force-ability and the speed at which it might be >accomplished.] >Does anyone have a policy about loss of certificates and >regeneration/revocation along with the underlying reasoning they're >willing to share? > >Or, perhaps I completely misunderstand what's going on, and I'd be glad >to be corrected. [Gently is always nice.] > >TIA >-Greg > > > > > >-- >Dave Paxton >dpax...@me.com >208 570 9755 >skype: dpaxton -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
