Radicali wrote:I read an article not long ago about some of the latest encryptions. The eliptic curve had constants that couldnt be accounted for. The article suggested it looked like a back door. I'm rather novice, so i may not have understood the whole article, but it seemed pretty clear about that part.
An Elliptic Curve Asymmetric Backdoor in OpenSSL RSA Key Generation
Adam L. Young, Moti M. Yung
In this chapter we present an experimental implementation of an asymmetric backdoor in RSA key generation. The implementation is written in ANSI C. We codified what it means for an asymmetric backdoor to be secure (for the designer) in our definition of a secretly embedded trapdoor with universal protection (SETUP). The main properties of a SETUP are: (1) the complete code for the backdoor does not enable anyone except the designer to use the backdoor, and (2) the key pairs that are output by the backdoor RSA key generator appear to all probabilistic polynomial time algorithms like normal (no backdoor) RSA key pairs. We introduced the notion of a SETUP at Crypto '96 (15) and there has been significant advances in the area since then. This chapter and the corresponding appendix constitutes Fundamental Research in cryptovirology and expands on our elliptic curve backdoor in RSA key generation that we presented at the Selected Areas in Cryptography conference in 2005. In particular, the design employs several algorithmic improvements that enable the key generator to run faster. This chapter provides a walk-through of the experimental implementation. The backdoor is based on OpenSSL and the code for it appears in the appendix that is associated with this chapter. For over 10 years we have advocated that the industry change the way RSA keys are generated. We devised and presented heuristic methods that completely foil this entire class of backdoors in RSA key generation (15, 12). The approach in (12) is reminiscent of the NIST FIPS 186-2 DSA parameter generation method.
Please obtain the latest version directly from the ocial Cryptovirology Labs website at: http://www.cryptovirology.com | Published in 2006.
Pattern_Juggled wrote:That said, the NSA's backdoored, ECC-based random generator is known-bad and afaik isn't used by any credible crypto practitioners... although I remember a rumour it had been adopted by Microsoft at some point. Which does actually make sense - note inclusion of the word "credible," above.
Simultaneously, the N.S.A. has been deliberately weakening the international encryption standards adopted by developers. One goal in the agency’s 2013 budget request was to “influence policies, standards and specifications for commercial public key technologies,” the most common encryption method.
Cryptographers have long suspected that the agency planted vulnerabilities in a standard adopted in 2006 by the National Institute of Standards and Technology and later by the International Organization for Standardization, which has 163 countries as members.
Classified N.S.A. memos appear to confirm that the fatal weakness, discovered by two Microsoft cryptographers in 2007, was engineered by the agency. The N.S.A. wrote the standard and aggressively pushed it on the international group, privately calling the effort “a challenge in finesse.”
“Eventually, N.S.A. became the sole editor,” the memo says.
guest wrote:Bruce Schneier said just yesterday to avoid elliptic curve. Based on his review of recent leaks. Am I missing something?
How to remain secure against NSA surveillance
The NSA has huge capabilities – and if it wants in to your computer, it's in. With that in mind, here are five ways to stay safe
Bruce Schneier | theguardian.com | Thursday 5 September 2020 20.06 BST
Now that we have enough details about how the NSA eavesdrops on the internet, including today's disclosures of the NSA's deliberate weakening of cryptographic systems, we can finally start to figure out how to protect ourselves.
For the past two weeks, I have been working with the Guardian on NSA stories, and have read hundreds of top-secret NSA documents provided by whistleblower Edward Snowden. I wasn't part of today's story – it was in process well before I showed up – but everything I read confirms what the Guardian is reporting.
At this point, I feel I can provide some advice for keeping secure against such an adversary.
The primary way the NSA eavesdrops on internet communications is in the network. That's where their capabilities best scale. They have invested in enormous programs to automatically collect and analyze network traffic. Anything that requires them to attack individual endpoint computers is significantly more costly and risky for them, and they will do those things carefully and sparingly.
Leveraging its secret agreements with telecommunications companies – all the US and UK ones, and many other "partners" around the world – the NSA gets access to the communications trunks that move internet traffic. In cases where it doesn't have that sort of friendly access, it does its best to surreptitiously monitor communications channels: tapping undersea cables, intercepting satellite communications, and so on.
That's an enormous amount of data, and the NSA has equivalently enormous capabilities to quickly sift through it all, looking for interesting traffic. "Interesting" can be defined in many ways: by the source, the destination, the content, the individuals involved, and so on. This data is funneled into the vast NSA system for future analysis.
The NSA collects much more metadata about internet traffic: who is talking to whom, when, how much, and by what mode of communication. Metadata is a lot easier to store and analyze than content. It can be extremely personal to the individual, and is enormously valuable intelligence.
The Systems Intelligence Directorate is in charge of data collection, and the resources it devotes to this is staggering. I read status report after status report about these programs, discussing capabilities, operational details, planned upgrades, and so on. Each individual problem – recovering electronic signals from fiber, keeping up with the terabyte streams as they go by, filtering out the interesting stuff – has its own group dedicated to solving it. Its reach is global.
The NSA also attacks network devices directly: routers, switches, firewalls, etc. Most of these devices have surveillance capabilities already built in; the trick is to surreptitiously turn them on. This is an especially fruitful avenue of attack; routers are updated less frequently, tend not to have security software installed on them, and are generally ignored as a vulnerability.
The NSA also devotes considerable resources to attacking endpoint computers. This kind of thing is done by its TAO – Tailored Access Operations – group. TAO has a menu of exploits it can serve up against your computer – whether you're running Windows, Mac OS, Linux, iOS, or something else – and a variety of tricks to get them on to your computer. Your anti-virus software won't detect them, and you'd have trouble finding them even if you knew where to look. These are hacker tools designed by hackers with an essentially unlimited budget. What I took away from reading the Snowden documents was that if the NSA wants in to your computer, it's in. Period.
The NSA deals with any encrypted data it encounters more by subverting the underlying cryptography than by leveraging any secret mathematical breakthroughs. First, there's a lot of bad cryptography out there. If it finds an internet connection protected by MS-CHAP, for example, that's easy to break and recover the key. It exploits poorly chosen user passwords, using the same dictionary attacks hackers use in the unclassified world.
As was revealed today, the NSA also works with security product vendors to ensure that commercial encryption products are broken in secret ways that only it knows about. We know this has happened historically: CryptoAG and Lotus Notes are the most public examples, and there is evidence of a back door in Windows. A few people have told me some recent stories about their experiences, and I plan to write about them soon. Basically, the NSA asks companies to subtly change their products in undetectable ways: making the random number generator less random, leaking the key somehow, adding a common exponent to a public-key exchange protocol, and so on. If the back door is discovered, it's explained away as a mistake. And as we now know, the NSA has enjoyed enormous success from this program.
TAO also hacks into computers to recover long-term keys. So if you're running a VPN that uses a complex shared secret to protect your data and the NSA decides it cares, it might try to steal that secret. This kind of thing is only done against high-value targets.
How do you communicate securely against such an adversary? Snowden said it in an online Q&A soon after he made his first document public: "Encryption works. Properly implemented strong crypto systems are one of the few things that you can rely on."
I believe this is true, despite today's revelations and tantalizing hints of "groundbreaking cryptanalytic capabilities" made by James Clapper, the director of national intelligence in another top-secret document. Those capabilities involve deliberately weakening the cryptography.
Snowden's follow-on sentence is equally important: "Unfortunately, endpoint security is so terrifically weak that NSA can frequently find ways around it."
Endpoint means the software you're using, the computer you're using it on, and the local network you're using it in. If the NSA can modify the encryption algorithm or drop a Trojan on your computer, all the cryptography in the world doesn't matter at all. If you want to remain secure against the NSA, you need to do your best to ensure that the encryption can operate unimpeded.
With all this in mind, I have five pieces of advice:
1) Hide in the network. Implement hidden services. Use Tor to anonymize yourself. Yes, the NSA targets Tor users, but it's work for them. The less obvious you are, the safer you are.
2) Encrypt your communications. Use TLS. Use IPsec. Again, while it's true that the NSA targets encrypted connections – and it may have explicit exploits against these protocols – you're much better protected than if you communicate in the clear.
3) Assume that while your computer can be compromised, it would take work and risk on the part of the NSA – so it probably isn't. If you have something really important, use an air gap. Since I started working with the Snowden documents, I bought a new computer that has never been connected to the internet. If I want to transfer a file, I encrypt the file on the secure computer and walk it over to my internet computer, using a USB stick. To decrypt something, I reverse the process. This might not be bulletproof, but it's pretty good.
4) Be suspicious of commercial encryption software, especially from large vendors. My guess is that most encryption products from large US companies have NSA-friendly back doors, and many foreign ones probably do as well. It's prudent to assume that foreign products also have foreign-installed backdoors. Closed-source software is easier for the NSA to backdoor than open-source software. Systems relying on master secrets are vulnerable to the NSA, through either legal or more clandestine means.
5) Try to use public-domain encryption that has to be compatible with other implementations. For example, it's harder for the NSA to backdoor TLS than BitLocker, because any vendor's TLS has to be compatible with every other vendor's TLS, while BitLocker only has to be compatible with itself, giving the NSA a lot more freedom to make changes. And because BitLocker is proprietary, it's far less likely those changes will be discovered. Prefer symmetric cryptography over public-key cryptography. Prefer conventional discrete-log-based systems over elliptic-curve systems; the latter have constants that the NSA influences when they can.
Since I started working with Snowden's documents, I have been using GPG, Silent Circle, Tails, OTR, TrueCrypt, BleachBit, and a few other things I'm not going to write about. There's an undocumented encryption feature in my Password Safe program from the command line); I've been using that as well.
I understand that most of this is impossible for the typical internet user. Even I don't use all these tools for most everything I am working on. And I'm still primarily on Windows, unfortunately. Linux would be safer.
The NSA has turned the fabric of the internet into a vast surveillance platform, but they are not magical. They're limited by the same economic realities as the rest of us, and our best defense is to make surveillance of us as expensive as possible.
Trust the math. Encryption is your friend. Use it well, and do your best to ensure that nothing can compromise it. That's how you can remain secure even in the face of the NSA.
guest wrote:Bruce Schneier said just yesterday to avoid elliptic curve. Based on his review of recent leaks. Am I missing something?
Also I thought elliptic was propritary? (blackberry/rim)?
The production work, if I may summarize, seems to be moving along nicely. There's been some wrestling with the elliptic curve stuff to implement a flavour of TLS that's not useless... and that's a more involved process than it would first appear. Many kernel recompiles later, we're getting the hang of it - apparently.
You mentioned a custom kernal- have you moved to a libre setup, or are you still on CentOS? how do you handle blobs, drivers, hardware and such?
SafeCurves: choosing safe curves for elliptic-curve cryptography
There are several different standards covering selection of curves for use in elliptic-curve cryptography (ECC):
ANSI X9.62 (1999).
IEEE P1363 (2000).
SEC 2 (2000).
NIST FIPS 186-2 (2000).
ANSI X9.63 (2001).
NSA Suite B (2005).
ANSSI FRP256V1 (2011).
Each of these standards tries to ensure that the elliptic-curve discrete-logarithm problem (ECDLP) is difficult. ECDLP is the problem of finding an ECC user's secret key, given the user's public key.
Unfortunately, there is a gap between ECDLP difficulty and ECC security. None of these standards do a good job of ensuring ECC security. There are many attacks that break real-world ECC without solving ECDLP. The core problem is that if you implement the standard curves, chances are you're doing it wrong:
Your implementation produces incorrect results for some rare curve points.
Your implementation leaks secret data when the input isn't a curve point.
Your implementation leaks secret data through branch timing.
Your implementation leaks secret data through cache timing.
These problems are exploitable by real attackers, taking advantage of the gaps between ECDLP and real-world ECC:
ECDLP is non-interactive. Real-world ECC handles attacker-controlled input.
ECDLP reveals only nP. Real-world ECC also reveals timing (and, in some situations, much more side-channel information).
ECDLP always computes nP correctly. Real-world ECC has failure cases.
Secure implementations of the standard curves are theoretically possible but very hard.
Most of these attacks would have been ruled out by better choices of curves that allow simple implementations to be secure implementations. This is the primary motivation for SafeCurves. The SafeCurves criteria are designed to ensure ECC security, not just ECDLP security.
Other attacks would have been ruled out by better choices at higher levels of ECC protocols. For example, deterministic nonces were proposed in 1997, are integrated into modern signature mechanisms such as EdDSA, and would have prevented the 2010 Sony PlayStation ECDSA security disaster. However, this security issue does not interact with curve choices, so it is outside the scope of SafeCurves.
Error-prone cryptographic designs
Daniel J. Bernstein
University of Illinois at Chicago
Technische Universiteit Eindhoven
“The poor user is given enough rope with which
to hang himself—something a standard should not do.”
...commenting on nonce generation inside Digital Signature Algorithm (1991 proposal by NIST, 1992 credited to NSA, 1994 standardized by NIST)
marzametal wrote:The new reloaded Silk Road has switched from Tor to this - I2P
Users browsing this forum: No registered users and 3 guests