Boston Linux & Unix (BLU) Home | Calendar | Mail Lists | List Archives | Desktop SIG | Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings
Linux Cafe | Meeting Notes | Blog | Linux Links | Bling | About BLU

BLU Discuss list archive


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Discuss] KeePassX



> But - and this is important -- once a given recipient's key is cracked
> it remains cracked forever.

Nope, sorry, each individual message has its own unique session key.
Cracking the session key on one particular message tells you nothing
about the session key on subsequent messages.



On Tue, Aug 13, 2013 at 4:07 PM, Richard Pieri <richard.pieri at gmail.com>wrote:

> Kent Borg wrote:
>
>> I'll accept your math, and it makes my point. You describe a facility
>> that can only brute-force a couple hundred 80-bit keys a year.  Which
>> means brute-forcing 80-bit keys is not something routine and cheap for
>> the NSA, not when they think they need a plaintext copy of *everything*.
>>
>
> Go back to PRISM. How did the NSA get all that traffic data? They asked
> for it, and the big providers handed it over. It stands to reason that the
> NSA has obtained SSL certificates from public CAs the same way. If so then
> the vast bulk of Internet traffic is already decrypted by the time it ends
> up on the NSA's storage servers. But even if this is not the case, SSL and
> TLS are vulnerable to chosen plain-text attacks (CRIME and BREACH). The
> protocols are vulnerable regardless of the keys or ciphers you use.
>
> This covers, what, 95% of the encrypted traffic on the Internet? Yes,
> there is a cost to running CRIME and BREACH attacks but it is a tiny cost
> compared to exhaustive search/brute force.
>
> Now, my noodling is based on some assumptions. One is that the NSA doesn't
> know about any weaknesses at all and therefore must brute force every key
> that isn't in the ~95% of automagically decrypted traffic. Another is that
> they're using off the shelf GPUs. I doubt that either of these is the case.
>
> Take a look at the current state of the art in Bitcoin mining. The fastest
> Bitcoin mining GPU manages 1.2 GH/s (billion hashes per second) at a cost
> of around $1000. Most lesser GPUs get around 0.3 GH/s. A Butterfly mining
> box with a cost of $1250 performs 25 GH/s, an improvement of 20 times that
> of the best GPU, and pushing 100 times the performance of lesser GPUs.
> ASICs offer a massive performance improvement for roughly the same cost.
>
> A 100 times performance improvement over my GPU noodling reduces the
> 32-hour crack time to just 19 minutes. If there is a weakness in the cipher
> that reduces analysis time by another order of magnitude? Your 80-bit key
> will be cracked in less than 115 seconds.
>
> This is based on the assumption that the NSA can do no better than the
> state of the art in Bitcoin mining. I figure they can do better than that
> so a 500 times performance improvement over the GPU solution may be a more
> realistic figure. If so then your 80-bit key can be cracked in ~24 seconds.
> If the NSA has ASIC boxes that are 1000 times faster than my GPU noodling?
> 11.5 seconds.
>
> More realistically, the NSA won't bother with brute forcing every key that
> they haven't gotten by asking. They'll use more sophisticated analysis, so
> maybe 3-5 seconds to break an 80-bit key? Maybe less? Depends on the cipher.
>
> Let's follow along with John's mailing list example: 20,000 messages going
> through BLU per day. Let's assume that every one of them is encrypted with
> an 80-bit key unique to each recipient. And let's use the 24 second figure
> just for the example. That's 5.5 days to handle one day's worth mail. Seems
> like a lot. But -- and this is important -- once a given recipient's key is
> cracked it remains cracked forever. New mail to that recipient does not
> need to be cracked, just decrypted with whatever keys are associated with
> the recipient. The 5.5 days cost is a one-time cost of doing business. A
> crack attempt won't have to be performed for any given recipient until that
> recipient's "master" key is changed.
>
> This is the biggest problem with the "encrypt everything to keep the NSA
> out" argument. If a key is compromised then anything encrypted with it
> might as well be clear-text as far as the compromising party is concerned.
>
> --
> Rich P.
>
> ______________________________**_________________
> Discuss mailing list
> Discuss at blu.org
> http://lists.blu.org/mailman/**listinfo/discuss<http://lists.blu.org/mailman/listinfo/discuss>
>



-- 
John Abreau / Executive Director, Boston Linux & Unix
Email jabr at blu.org / WWW http://www.abreau.net / PGP-Key-ID 0xD5C7B5D9
PGP-Key-Fingerprint 72 FB 39 4F 3C 3B D6 5B E0 C8 5A 6E F1 2C BE 99



BLU is a member of BostonUserGroups
BLU is a member of BostonUserGroups
We also thank MIT for the use of their facilities.

Valid HTML 4.01! Valid CSS!



Boston Linux & Unix / webmaster@blu.org