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 | Linux Links | Bling | About BLU

BLU Discuss list archive


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

[Discuss] KeePassX



If the individual in question encrypts only high-value messages, and
doesn't bother encrypting everything else, like grocery lists, birthday
greetings, and all their mundane day-to-day communication, then it's easy
for the NSA to target their high-value messages and get good results.

On the other hand, if the individual routinely encrypts *everything*, and
if the metadata does not clearly identify which messages are of interest,
then it becomes much harder.



On Tue, Aug 13, 2013 at 4:47 PM, Jerry Feldman <gaf at blu.org> wrote:

> Let's take the situation: NSA is watching you.
> They can intercept your email, crack your RSA or DSA key, and then they
> can discover the session keys. They are not interested in everybody's
> random encrypted emails, so if they focus on individuals who  interest
> them, the problem becomes smaller.
>
>
> On 08/13/2013 04:35 PM, John Abreau wrote:
>
>> If you're talking about the NSA breaking into each and every person's home
>> and copying their pgp keys off their desktop machine, that's an entirely
>> separate question from intercepting encrypted email traffic as it passes
>> across the Internet.
>>
>>
>>
>> On Tue, Aug 13, 2013 at 4:33 PM, John Abreau <jabr at blu.org> wrote:
>>
>>  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>
>>>> <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
>>>
>>>
>>
>>
>
> --
> Jerry Feldman <gaf at blu.org>
> Boston Linux and Unix
> PGP key id:3BC1EB90
> PGP Key fingerprint: 49E2 C52A FC5A A31F 8D66  C0AF 7CEA 30FC 3BC1 EB90
>
>
> ______________________________**_________________
> 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