NSA-proof encryption exists. Why doesn’t anyone use it?
washingtonpost.com
washingtonpost.com
Yup. Except it's not that easy.
Let's say that you're using OTR to provide very strong end-to-end encryption for a conversation between yourself and a buddy, Bob. Maybe he's in a hostile area, and you're worried that if his government sniffs his traffic, that he could be executed for speaking to Americans.
Data in transit that is intercepted, if configured correctly, is almost certainly safe. No one will be able to immediately decrypt it because of the strong encryption.
So are you safe?
Probably not. The next step that government would take would be to raid your friend Bob's apartment, arrest him, and take his hard disk. His OTR key (and, if using Pidgin, account credentials in plaintext if stored) is plainly available on the disk. You now have the private key.
But what if he used Truecrypt or PGP full-disk encryption? His data would be safe from decryption then, right?
Sort of. If they're trying to break the actual encryption, they'd likely be unable to do so. Unfortunately, the weak point for Truecrypt disks or volumes isn't the crypto... it's the passphrase. The passphrase can be brute-forced significantly more easily than breaking the encryption itself. Furthermore, as xkcd so accurately pointed out, a hostile government will throw you in prison (or, worse, hit you repeatedly with a wrench) until you divulge your passphrase and data.
Encryption is great, and I encourage everyone to use reliably strong crypto. Will that keep your data safe from the criminals that stole your work laptop? Absolutely. Will it keep your data safe from the NSA? You're kidding yourself.
They can use "hitting the suspect with a wrench" cryptanalysis on a solo victim, but not on a crowd.
However, according to https://en.wikipedia.org/wiki/Perfect_forward_secrecy OTR does provide "perfect forward secrecy as well as deniable encryption". Doesn't that provide some protection against rubber-hose cryptanalysis?
Which means, if they're jailing you until you do decrypt the messages, you get jailed indefinitely. Contempt of court has very few limits in some circumstances, even compared to being imprisoned after being convicted of a crime:
Maybe, but they wouldn't be waiting for you to do something for them. They would understand that there was nothing you could do to help them decrypt the messages. i.e. your encryption worked.
That's what I'm wondering, though. Would they believe you? Would they believe the documentation?
Keyloggers are a problem, so keep the laptop in a nice safe when you're out.
The way I see it, that's not the greatest danger right now. Instead, we should be worried about the government being able to passively spy on everyone at the same time, by indiscriminately siphoning and analyzing data.
The article is in response to a dragnet surveillance program, where everyone's communications are watched and presumably datamined. It's very easy to do this, because nothing is encrypted, and everyone uses services that expose metadata (like who is IM'ing who).
Your comment is entirely true. However, it presents an adversary that doesn't want dragnet, but targeted surveillance. It assumes that Bob will be immediately arrested if his communications become encrypted.
This is not the threat model that we're faced with now. Let's say you and Bob communicate using accounts you've made on random XMPP servers using Tor, and all the messages are encrypted with OTR. Both servers are in the US, and the NSA's metadata database shows E83Gxw@jabber.org sending lots of ciphertext to PAnd9B@jabber.org.
This is "NSA-proof" in that the NSA would not know to link PAnd9B@jabber.org with you using their existing systems. They would have to drastically escalate the cost of their surveillance program with respect to you and Bob to figure out what you're talking about. Unless you really are a political dissident, conspiracy theorist who accidentally discovered the UN's black helicopter program, or radical Islamist, you are now out of the surveillance dragnet.
That is to say, unless the threat model changes, using privacy-enhancing technology will keep your data safe from PRISM and similar dragnet programs.
Your description of secure communication (Tor, anonymous XMPP, etc.) is totally accurate and a great explanation for those who may not be quite as familiar with security and OPSEC.
Unfortunately, with great enough amounts of metadata and computing power, this could theoretically be correlated as well. DNS requests or Tor connections correlated with encrypted messages timed between two individuals seems like it would be too hard to make meaningful, but it's not impossible. There's precedence for this when the FBI suspected Jeremy Hammond of being a certain identity on IRC, and correlated his sign-ons with connections to Tor.
You're absolutely, 100% correct, though, that this data (even correlated), must be part of some sort of targeted surveillance. I wasn't trying to counter the dragnet argument as much as provide clarity on what these security measures would or would not do.
Thanks for providing even more clarity in the areas I didn't address :)
With a total record of the entire Internet (global passive adversary), you could definitely defeat anything using Tor, but I wonder if you could make it significantly harder still by randomly generating XMPP accounts every time. There's a potentially infinite space, and you can do XMPP registration in-band.
Of course, you could also just run XMPP servers locally as chat endpoints, and never have subpoena-able records. These could be Tor hidden services, which would give you the added bonus of global reachability. I think this eliminates most correlation attacks you could do; all you'd see on Alice and Bob's endpoints would be Tor circuits.
All this will make for a really interesting Wire reboot, if/when that happens.
Tor won't help at all if all of the long-distance network traffic in the country is being mirrored (as it has been in the USA for most of a decade).
Corollary: The NSA knows exactly who runs The Silk Road. Stopping drug trafficking is obviously not as high a priority to them as not letting potentially kinetic adversaries know that Tor provides no anonymity to someone who can (and does) monitor _all_ network traffic.
Besides , in such an example the government would have to be suspecting bob already on some other grounds. In the case of a despotic regime they probably already have him in prison.
Doesn't brute forcing this depend on the strength of the passphrase? For large enough N, if neither can be done in the next N years, does it really matter if it's significantly easier? Isn't there a non-negligible likelihood that in the next N years we'll figure out ways to break stronger forms of encryption but we won't figure out how to brute force strong passphrases efficiently?
Not true, actually. OTR provides perfect forward secrecy. Gaining access to the private key does not give you access to previous conversations.
http://www.forbes.com/sites/andygreenberg/2013/03/13/cryptog...
Not to detract from the point of your post, but for anyone interested, that's what TrueCrypt's 'plausible deniability' feature [1] is for. It can be used to create a hidden volume on your hard drive with a different password from your main volume, so if you're ever forced to give up the disk passphrase by a government agency or anyone else, you can give them the password to the hidden volume, and (in theory) you'll appear to be fully cooperating. It is impossible (short of cracking the main volume passphrase through brute force) to prove, given only the passphrase to the hidden volume, that the main volume exists. Ideally, you'd probably want to put something "embarrassing" but legal on the hidden volume (e.g., gay porn), to make the "plausible deniability" for using full disk encryption more "plausible".
The DEFINING FEATURE of OTR is that of forward secrecy; key compromise does not permit retroactive decryption.
Otherwise, we could just use TLS. (Technically, we could now, just enforcing the EDH modes.)
This whole idea that no we can't do it, is defeatist. We can and we should do it, and then we should do more. As much as we can to make it as hard as possible. And if the government still wants to do shit, then let them. That's their prerogative.
My father told me when he was young, he visited Oak Ridge National Labs on a trip, and while there, they told him they had satellites that could read the print on a newspaper. At the time, it wasn't classified information; it was just something that nobody knew. Approximately 15-20 years later, satellites with that capability became well-known. This indicates to me that top secret technology is probably somewhere around 15-20 years ahead of what the general public knows about. This may be less true today than it was back then since nowadays the equipment and factories to develop state-of-the-art technology run in the billions of dollars.
Where I'm going with this: is it reasonable to assume that "future technology" 20 years from now could crack AES-256 or PGP? If so, it seems reasonable to me that the NSA could already crack today's encryption for high-priority data. Add that to the fact that they tend to hire the very best experts in the field (mathematicians and cryptographers) and it doesn't seem entirely unreasonable to me that their decryption technologies are pretty good. Of course, I'm not talking about better technology in a brute-force sense; it would still be impossible to crack 256-bit encryption. I'm talking about algorithmic weaknesses.
But then again, I have only a basic knowledge of cryptography. Would any experts like to comment?
Could you clarify what you mean by this?
And yeah, I should have been more clear in my original question; I was lumping mathematical advances under "technology".
In radioastronomy, there are arrays of dishes that use this technique. There are good pictures in the Wikipedia article. [0]
One military implementation was a connected three-satellite constellation, built by the US Navy for scanning the surface of the world's oceans. [1]
But those tools work in (relatively) long wavelengths.
I have never heard of free-flight multi-aperature interferometry that works in optical or near-optical wavelengths.
.
[0] "Very-long-baseline interferometry" https://en.wikipedia.org/wiki/Very-long-baseline_interferome...
[0] "How VLBI Works" https://en.wikipedia.org/wiki/Very-long-baseline_interferome...
[1] "White Cloud | PARCAE | NOSS" https://en.wikipedia.org/wiki/Naval_Ocean_Surveillance_Syste...
Keep in mind that there are a lot of people that track satellites, even spy satellites, as a hobby. I haven't heard of anyone discovering two or more satellites orbiting in the sort of tight formation you would expect would be required for this.
Pretty much. The same effect that causes stars to twinkle limits the resolution of space-based spy satellites imagery of the ground.
Ok, so even if you select a key length of something very large which depends not only on bytes of the key but also the encryption algorithm as well. For a 4096 bit key that would be 1.0443888814131525066917527107166e+1233 combinations, assuming someone tried to brute force this at 100000 checks per second (a low estimate) it would take roughly 1.655867708988382335571652572800330388413185326368886003... × 10^1220 years to crack on average assuming the birthday paradox.
2^4096 / 2 / 100000 / 60 / 60 / 24 / 365
So that's a freaking long time to keep that data secure. Even radically scaling up the brute force attack across the entire world would be akin to boiling the oceans. (Not going to do out the cpu/watt/check number calculation to determine how much energy it would actually take compared to boiling the oceans...)
So are you safe? No because starting in WWII very smart mathematicians were finding ways to crack the algorithms and find patterns and holes in the encryption solutions that made the search space orders of magnitude smaller. So the best thing we can do is select well attacked, well researched but still secure systems, use a good key length and pray (I am not a religious man).
Edit: If you wish to be truly paranoid (don't recommend it), most of the important crypto research has been done by state organizations, this is how AES was selected from a group of submitted designs to NIST. Conversely there are few still secure and well researched algorithms besides AES out there, (Elliptic Curve basically, but those designs are under patents so not widely available etc)
Edit 2: Also wikipedia is a great starting point for understanding, but is not always complete. Still haven't seen it probably explain initialization vector or nounces before.
Oh and one last thing http://xkcd.com/538/
See
https://en.wikipedia.org/wiki/Key_size
https://en.wikipedia.org/wiki/Brute-force_search
https://blogs.oracle.com/dcb/entry/zfs_boils_the_ocean_consu...
https://en.wikipedia.org/wiki/World_War_II_cryptography
It is very possible that government based research on crypto cracking is several years ahead of the rest of the world, but the attitude to these systems around the time of the dot com bubble was switching from security through obscurity to working in the open. The reason is the research cuts both ways, the US relies on AES as much as you or I. If there is a problem with it, they would be burned as well.
Yes, but the government also has other (non-public) algorithms/ciphers/etc. that are used internally.
Those patents are quite questionable anyway: https://en.wikipedia.org/wiki/ECC_patents
Err, maybe in optics at the time, but you can't just generalize like this. You can't consistently be ahead of everything all the time. More than likely the NSA suffers under Moore's law like everyone else.
This means that the NSA understood differential cryptanalysis 22 years before non-NSA researchers did. Their ability to brute force is meaningless if they have techniques to obviate it's necessity.
It might be easy to find out. Just check when the NSA cancelled their newspaper subscriptions.
There are a few related issues here, and so the answer is a bit complicated.
The only evidence for the security of AES is heuristic, based on testing the output of the cipher to check for properties that secure block ciphers should have. Some new attack strategy could completely undermine AES. Similarly, PGP relies on block ciphers and hash functions that are based on such evidence.
On the other hand, public key cryptography has proofs of security under certain assumptions about the complexity of certain problems. A proof that P != NP is necessary to prove that PKE is secure, but it is not sufficient on its own and we do not even have that much.
Now, assuming that (a) the heuristic evidence for AES and various hash functions is a reliable indicator of security and (b) that the assumptions are computation complexity are correct, then both AES and PGP can be used essentially indefinitely. The reason is that your key size can continue to increase -- for AES, you can iterate the cipher (e.g. "triple AES"), and for PGP you can keep making your keys larger (16384-bit ElGamal?), and you will always be able to stay ahead of your opponent. There are issues with this approach, of course -- it would take a lot of computing power to actually use 16384-bit ElGamal, and eventually it would become impractical, which is why there is so much interest in elliptic curve crypto (which allows shorter keys to be used for the same level of security).
So the answer is, "Yes, from one perspective, No from the other."
This is physically impossible, for the reasons given by marssaxman below; specifically, the resolution of an imaging system is limited by diffraction. In order to read a newspaper from orbit, you would need a ridiculously large aperture. Furthermore, you've certainly seen declassified Cold War satellite and aerial (U-2) imagery. You know what it looks like. Do you seriously believe they had something else that could read newspapers?
The answer: We don't know. Interestingly, back in the early 90s they were maybe 15ish years ahead of us. Decisions they made back then weren't understood until the 2000s. However, the gap may have been closed somewhat as of late. The public found flaws in SHA-1 (an algorithm by the NSA) in the 2000s that we believe the NSA didn't actually know about yet.
A general note on cryptography security margins (not really an answer, sorry, just some thoughts): The margins are designed to take into account future advances in technology. The community chooses the problems with the most conservative, best understood parameters, and that seem to be the least-likely to experience a break-through. As well, it tends to pick things with margins like "40+ years", meaning that even if we continue to improve our attacks and computing power at the same rate we have been, it is generally expected that it'll take at least 40 years before we're good enough to break it. (Obviously the experts turn out to be wrong sometimes.)
The community thinks very long term and tries to avoid ever picking anything that is very possible to be broken in just 20 years. It takes (in rough terms) at least 5 just to get through the review process and get the algorithm into standards, another 5 to get it into wide-spread usage, and another 5 to transition away from it. So a very popular crypto algorithm probably needs at least 15 years from its introduction run its life cycle, assuming theres no lull of happiness where it's just existing as a secure, commonly used standard. So there's little point in introducing any algorithm that is anything but a very low likelihood of being broken in 20, because it would spend only a fraction of it's lifespan serving as a widely-used, secure standard.
Last point: Breaks tend to be slow, and big breaks are usually smelled very far in advance. When we're 10 or so years out from a big break, we have a good chance of knowing it and we can start to transition away. Someone 20 years ahead of us may very well only find big breaks just before we start to migrate away from the algorithm.
Due to that, we might optimistically (optimism has no place in crypto, I know ;-)) think that an adversary 20 years ahead of us has relatively minimal advantage.
I'm not sure I agree that user-friendly cryptography is "intrinsically difficult." It doesn't seem like it would be hard for email clients and even the Gmail frontend to pop up a message saying, "Your email is insecure. To let people send you private messages securely, set up your 'public key' now. It's easy." Then a short wizard would walk users through the process and automatically append the public key to all outgoing messages.
On the other side, if you were going to send a message to a friend, the email client would check if that person has published a public key and then ask, "The recipient allows secure messages. Would you like us to send this message securely?"
Google and Microsoft and other large companies are no strangers to implementing a feature and using their size and clout to quickly make it a de facto standard. The real reason we don't have easy end-user cryptography is that these companies would lose access to mine your data and provide new services on top of that (and the article mentions this too.)
And there's the rub. "What do you mean, I can't ever see my data again? Why can't you reset my password?"
We know that true security means only the user has the key. But users don't all want that responsibility.
The catch there is that IBE requires a centralized, trusted key-issuing service where you need to enroll to receive your message. If that's compromised, then game over.
http://www.argreenhouse.com/society/wcan06/wcan06s4p3.pdf
Of course, you would need to be judicious about which group of key issuers you are willing to trust, but this method will at least reduce the risk. The other nice thing about this is that even if some key issuing service is compromised, the sender can force the receiver to switch services (compare to the TLS model, where dropping a CA is basically a coordination game problem).
Yes, someone will inevitably lose both. You just need to ensure that that is a rare event, and that there are alternative systems in place (i.e. that losing access to one system does not prevent people from living their lives).
As for using js for public key encryption, I've implemented it for a client and didn't have much trouble. There are libraries that workaround the usual problems. What have you seen out there that would cause a problem?
That said, couldn't this be mitigated by having a strong passphrase on the private key? How hard is the wrapper to attack?
Also, couldn't security researchers easily monitor the packets on this process and sound the alarm should they find that the js served up by Google or Microsoft suddenly starts sending private keys to the server?
As for your second question, there are techniques that perform static and dynamic analysis on javascript to try and detect illegal flows or taint propagation (without having to resort to monitoring the outbound network traffic). See [1] and [2] if you're interested in that topic.
[1] http://static.usenix.org/event/sec10/tech/full_papers/Bandha... [2] http://publik.tuwien.ac.at/files/pub-inf_5310.pdf
Securely in the Browser, and not directly accessible by js, just like a TMP chip or a smartcard. Could that be a solution?
Of course, that introduces a new problem: securely backing up the private key.
Jeremy Kun recently wrote a good article summarizing some recent advances in encryption that make your statement somewhat less-than-entirely-accurate (scan for "differential privacy"):
http://jeremykun.com/2013/06/10/why-theoretical-computer-sci...
And, all you have done is make damn sure they keep your metadata records. Somewhere I read that sending encrypted email is an automatic flag, in the same category as using words that incite violence.
So to truly make it effective, encrypted email has to be the norm, not the exception.
There are OSs that won't give root access to the NSA, encryption that the NSA won't be able to read and cloud services that the NSA won't be able to access even with cooperation of the CEO. Why none of them are widely used?
And I don't accept the answer on the article as suficient. Yes, a few things are harder when you want any level of security, but not all. There are plenty of applications where security just won't disturb you (like VoIP), and plent of places that put security above all other concerns and should care about this (like non-US military). Yet, nearly nobody chooses the secure path.
While that is an influencer, the reality is a bit more complex. That social drive we've been going through for the last ~5 years means that developers focus on customer value. Also, while there's little new after Snowdens' leak - other than absolute proof - there's not been much demand, and hence incentive to make things secure.
Seriously, how many HN users have spent hours complaining about privacy on here but still don't encrypt their own email? This isn't to excuse anything illegal the US gov't might be doing, but if it matters as much to people as they say you'd think they'd have at least taken some immediate action.
I would think that most HN users would be willing to encrypt their email, but know they can't convince their friends/family/etc to do so. Encryption takes two to tango.
When not even the researchers who run a top-tier cryptography conference are bothering, you know that it is not just about non-technical folks being clueless.
Let me explain some of my travails trying to use PGP with Thunderbird:
The install of T-Bird wasn't too bad
The install of OpenPGP was not easy but I managed it. The instructions on the site were not all that clear and for an out-of-date version, but YouTube helped out a lot. My mom, the business owners, or a computer science teacher at Central High School simply do not have time to do this. This could be streamlined.
The making of keys and storing of data was totally obtuse, fortunately, the wizard guided me through a lot of it. This could be streamlined.
Now sending a message is where it gets tough. OpenPGP says that I have to use [shift]+"left-click" on the Write button in T-bird to make sure the html won't be used so the PGP message will de-crypted correctly. This is non-sense. Why is this happening?
Ok now assuming I have a plain text email I have to hit [ctrl]+[shift]+[s] and [ctrl]+[shift]+[e] to sign and encrypt. BS. This needs to be better. Just a pop-up and type in the pass-phrase (brilliant wording, btw, phrase makes this so clear it has to be many words long my mom can understand this).
Ok now my buddy can't read it because I did not send him a public key? What the hell are those? Why do I care? I thought I put in my pass-phrase? Didn't he? What is going on?
I sort this out, I find the public key and send it over. Now he can read it. But wait I have another buddy that I have to do this with. Where were those options in the menus again?
There needs to be a button that remembers if I sent the public key to them, sends it if I did not, and then automatically tells their email client that I don't have theirs and gets theirs with permission from them.
Awww, fuck it... the NSA can probably crack this anyway.
And how you exchange public keys matters a great deal -- if you just send them over email, you haven't actually achieved any meaningful security.
So yes. The entire process is a usability nightmare.
It's a thunderbird plugin and its pretty good
Not many people use crypto because in general it's hard to set up and hard to use. A webapp is accessible and easy to use and provide reasonable security.
I know there's a prevailing view against doing crypto in Javascript, and I've gone the extra steps to address the negatives. At the end I think the benefits of doing javascript on the browser outweigh the negatives. See https://boxuptext.com/faq#benefits
Using GPG/PGP for example (which IMO is the best solution) is nice. It has a good, convenient design. The clients, UI, etc are terrible. Theyre extremely inconvenient. That can be fixed. This needs some time and a little dedication. Nobody will pay for a product that has proper, easy, fast PGP support across the board. Nobody. Since it's not a trivial task, and the benefits are "only" privacy, it didn't happen yet. If anything, people re-code their own, incompatible and generally lesser version of PGP, because they will get financial gain, or popularity from it (patching GPG doesn't give you as much popularity as making your own, you see.. and we're quite ego-driven / NIH-happy)
So, here we are. And I'm to blame too, I haven't worked on this either. I'm secretly hoping things like PRISM will actually help making this move forward.
Add to this a keyserver for automatically discovering public keys of contacts and you have a "good" solution between interested parties, without compromising recoverability of the majority of your messages.
You could do the same for Gtalk/Hangouts chats with OTR.
* The vast majority of internet users don't have the domain knowledge needed to use strong encryption effectively. A classic example with e-mail is using a prominent phrase from the plain text of the message body in the (unencrypted) subject field.
* Any cryptography scheme is vulnerable to social engineering, attacks on the trust networks used to exchange keys, etc. Avoiding these requires a nontrivial and ongoing amount of effort even for expert users.
* Encryption complicates archival and search of content even for its author.
* Any service that would help users with the above would be legally obligated to provide information to authorities anyway.
I don't trust SSL, for various reasons of implementation and many, many questions about weak links in the PKI chain, etc.
But I rely on SSH. I'd like very much to see some kind of assurance that this is a reasonable thing to rely on...
I disagree. Recently there have been breakthroughs in homomorphic encryption. From Wikipedia [1]:
"...any circuit can be homomorphically evaluated, effectively allowing the construction of programs which may be run on encryptions of their inputs to produce an encryption of their output. Since such a program never decrypts its input, it can be run by an untrusted party without revealing its inputs and internal state."
While currently known constructions with the right mathematical properties are kind of slow, I'm sure that a lot of people are now interested and in the future we'll eventually be able to do it at practical speeds (especially with the help of future computers that are faster, and/or have more cores, and/or have dedicated coprocessors hard-wired for homomorphic encryption computations, like recent x86 chips have hardware accelerated AES [2]).
If this happens, websites will be able to implement features, like search, that rely on manipulation of user data, without having access to that data themselves.
> [Certain] features depend on Facebook’s servers having access to a person’s private data
Today this is true, at least for people who aren't on the cutting edge of research in this field. But it might not be true tomorrow, if homomorphic encryption ever becomes practical (both in terms of fast algorithms, and in terms of frameworks/libraries which make it easy for developers to use).
Off-topic remark: Homomorphic encryption will also impact the economics of cloud computing, since you'll be able to use CPU cycles provided by others without the security concerns of disclosing the unencrypted confidential data you want them to manipulate.
[1] http://en.wikipedia.org/wiki/Homomorphic_encryption#Fully_ho...
The problem is not one of operations; the problem is one of law. Google (and others) have been forced under federal law to provide the plaintext to the government, or have their individual persons face jail time.
This is not a technological problem, and there are no technological solutions.
Um... what? Can't the user just reset his/her password, instead of a website emailing him/her the old password?...
The FIRST question is: Is it really a solution?
The answer to that: NO, see: https://news.ycombinator.com/item?id=5879308
The only feasible thing against AES 128 right now would be if a flaw was discovered. This is also why it doesn't matter whether you use 128, 192, 256, or higher. If one is flawed, they all are. The reason we even have higher than 128 is simply because the government loves excessive amounts of redundancy. It lets them sleep easier at night, even if it's completely unnecessary.
Competitions are held in which anyone can submit their own algorithm as a possible contender. Like a beauty pageant, the entries are narrowed down over a few rounds until just a few are left. Eventually, one algorithm is chosen and declared the winner!
The whole process is done in the open and, similar to RFCs, anyone who wishes to may provide feedback.
The SHA-3 competition took roughly five years. You can read about the whole process on the NIST's web site:
http://csrc.nist.gov/groups/ST/hash/sha-3/index.html
Numbers about total world computing power (most of it probably stuck in GPUs doing windows animations and playing Call of Duty) bandied about are in the Ne18ish ops/sec range, age of the universe is in the 4e17 range.
And I have a great deal of margin by treating a 'decrypt and verify' operation as a 'basic operation' and using a completely preposterous time period like the age of the universe instead of say, 10,000 years. Nobody is brute-forcing 128 bit keys anytime soon, that's a pretty basic mathematical and physical given. But if you're particularly paranoid, you can just as easily use 256 bit keys - nobody is brute-forcing those until we hit the singularity and become a galaxy-encompassing brain. Even then it might give us a serious, millennia-long headache.
The fact that someone can beat a key out of you is not what is usually meant by 'brute forcing' a key, in a cryptographic context.