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 |
True, but not unsurmountable. Depends on the recipient. Additionally with public key encryption you are using the recipient's public key to encrypt. The real issue is determining who and what to monitor. On 08/13/2013 04:54 PM, John Abreau wrote: > 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 > <mailto: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 > <mailto: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 > <mailto: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 <mailto: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 <mailto: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 <mailto: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 <mailto:Discuss at blu.org> > http://lists.blu.org/mailman/listinfo/discuss > > > > > -- > John Abreau / Executive Director, Boston Linux & Unix > Email jabr at blu.org <mailto: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
BLU is a member of BostonUserGroups | |
We also thank MIT for the use of their facilities. |