# Lifestyles & Discussion > Science & Technology >  NSA surveillance: A guide to staying secure - Bruce Schneier

## tangent4ronpaul

If you don't know who Bruce Schneier is and why you should trust his advice, look him up.

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
http://www.theguardian.com/world/201...e-surveillance



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.
(there are 872 comments, you might want to scan them...)

GPG:  http://www.gnupg.org/
Silent Circle: https://silentcircle.com/
Tails: https://tails.boum.org/
OTR: http://www.cypherpunks.ca/otr/
TrueCrypt: http://www.truecrypt.org/
BleachBit:  http://bleachbit.sourceforge.net/
PasswordSafe: https://www.schneier.com/passsafe.html

Q&A about the revelations:
http://www.theguardian.com/commentis...on-expert-chat

example:

Bruce's article giving advice on staying more private online included selecting certain encryption algorithms based on their mathmatical features etc -- what are some direct examples of the most 'safe' encryption techniques to use, key lengths etc?

How can Tor be any safer than VPN if both SSL/TLS and VPN methodologies have been exploited? Is the Tor routing process still a good security?

Ball: GCHQs phrasing of beating 30 then 300 VPNs suggest its done on a case-by-case basis, rather than a blanket capability. Its also worth noting that just because the NSA can, say, beat SSL in some (or many, or most) cases, it doesnt mean they can do it all the time, especially as they often seem to circumvent rather than directly beat security. Tor also has its onion methodology. I think Bruces take  that Tor makes tracing you harder, rather than impossible  seems a sensible one.

-t

----------


## tangent4ronpaul

Bruce, in an article yesterday you said that you used the Tails version of Linux for security purposes. Another Linux distribution built for security is Liberté Linux. Are there any reasons to prefer Tails over Liberté?

Answer:

    Schneier: I like Tails because it fits on a memory stick and gives me a relatively secure environment on any computer. I don't know Liberte, so I can's comment on it. In general, I don't have any inside knowledge about which applications have been compromised and which are secure. I'm making my best guesses based on what we all now know about the NSA's methods and economic realities.


From what I got the gist of this round of revelations is that cryptography has been weakened by human, political decisions: that of the government to make covert agreements with tech companies - by the way, are they voluntary on their part or not? - to collaborate with intelligence agencies, for example, and let them insert "secret vulnerabilities".

Of course there is a legal complication here - the companies say they are basically compelled to comply when required by law - but there seems to be a difference between mathematically defeating cryptography and circumventing it by covert partnerships.

So my question is: can we still trust cryptography per se? Is it still mathematically sound or does NSA spying provide us with a case to believe that it is «less secure than we thought», as in this paper by MIT http://web.mit.edu/newsoffice/2013/e...ght-0814.html?

Fabio Chiusi
https://twitter.com/fabiochiusi

Answer: 

    Schneier: I wrote about this explicitly here. I believe we still can trust cryptography. The problem is that there is so much between the mathematics of cryptography and the "encrypt" button on your computer, and all of that has been subverted.

http://www.theguardian.com/world/201...e-surveillance


My questions are:

1. Are the symmetric and/or asymmetric protocols (AES-256, RSA-2048+) fundamentally compromised? Or is it simply the implementation?

2. Are point to point VPN links between commercial OTS h/w such as SonicWALL therefore decryptable, even with PFS?

3. Are A/V vendors cooperating with NSA/GCHQ to ignore gov't malware in order to compromise endpoints? If so, would it makes sense to use A/V such as Kaspersky?

4. Mobile devices: Is it possible the h/w or s/w on Androids and iPhones is backdoored, rendering on-device encryption such as silent phone useless?

5. All-in-all, is it safe to assume that there exists no viable means of protecting traffic against NSA/GCHQ?

Answer: 

    Schneier: 1. I believe that the algorithms are not fundamentally compromised, only the implementations. I talk about this more here.

http://www.schneier.com/blog/archive..._crypto_1.html

    2. I don't know. I have no reason to believe that SonicWALL is secure.

    3. This is an interesting question. I actually believe that AV is less likely to be compromised, because there are different companies in mutually antagonistic countries competing with each other in the marketplace. While the U.S. might be able to convince Symantec to ignore its secret malware, they wouldn't be able to convince the Russian company Kaspersky to do the same. And likewise, Kaspersky might be convinced to ignore Russian malware but Symanetec would not. These differences are likely to show up in product comparisons, which gives both companies an incentive to be honest. But I don't know.

    4. I think it would be completely implausible for the NSA not to pursue both Android and iOS with the same fervor as the rest of the Internet.

    5. That's what I wrote about here

http://www.theguardian.com/world/201...e-surveillance

-t

----------


## VIDEODROME

Some of this seems over whelming.  Especially if you use internet resources outside you own network.  Such as Liberty Forest here.  So, I'm sure my email could be pulled from this site.  I'm not sure if a solution is to juggle multiple emails.  

In fact, what should a person be using for email?  


Otherwise, I'm using derivatives of Debian Linux at the moment.  

Also, I don't really have a smart phone.  I have a very average Flip Phone.  I suppose it has internet capability, but I have not data plan at the moment and the screen is way to small for that.  I do not Text either.

----------


## tangent4ronpaul

> Some of this seems over whelming.  Especially if you use internet resources outside you own network.  Such as Liberty Forest here.  So, I'm sure my email could be pulled from this site.  I'm not sure if a solution is to juggle multiple emails.  
> 
> In fact, what should a person be using for email?  
> 
> 
> Otherwise, I'm using derivatives of Debian Linux at the moment.  
> 
> Also, I don't really have a smart phone.  I have a very average Flip Phone.  I suppose it has internet capability, but I have not data plan at the moment and the screen is way to small for that.  I do not Text either.


A flip phone should be able to text, but won't have Internet capabilities.  You might want to be more worried about if it has a GPS chip.

As to e-mail providers, I wouldn't trust anything in the USA.  For other countries, consider their privacy laws and how friendly they are with the US.  Scandanavian countries and Germany are supposed to be good on privacy.  Not sure of others.

Here's a list of free e-mail providers, internationally.  Some sites won't be in English or offer an English option:

http://www.fepg.net/foreign.html

-t

----------


## american.swan

The congressional testimony was false, remember?  Now the liars are saying they can decrypt anything?  I think cypto still works, the weakest link is your phone or home computer and product backdoors.  That isn't KNOW information to some of us.  Anonymous knows that.  Find the Anonymous Guide to Security/Privacy online.  It's on Pastebin. 

There was a really good editorial I saw. If everyone thinks encryption doesn't work, everyone will stop using it.     properly implemented Encryption WORKS!!

----------


## tangent4ronpaul

> The congressional testimony was false, remember?  Now the liars are saying they can decrypt anything?  I think cypto still works, the weakest link is your phone or home computer and product backdoors.  That isn't KNOW information to some of us.  Anonymous knows that.  Find the Anonymous Guide to Security/Privacy online.  It's on Pastebin. 
> 
> There was a really good editorial I saw. If everyone thinks encryption doesn't work, everyone will stop using it.     properly implemented Encryption WORKS!!


Anonymous  the uber-secret handbook
http://pastebin.com/a8sCYHep

Here's how to best secure your data now that the NSA can crack almost any encryption
http://www.pcworld.com/article/20482...ncryption.html

The latest Snowden-supplied bombshell shook the technology world to its core on Thursday: The NSA can crack many of the encryption technologies in place today, using a mixture of backdoors baked into software at the governments behest, a $250 million per year budget to encourage commercial software vendors to make its security exploitable, and sheer computer-cracking technological prowess. 
http://www.pcworld.com/article/20482...tml#tk.rss_all

To some extent, its not surprising to hear that the U.S. spy agency is doing spy agency stuff but, given the recent surveillance revelations and the fact that other countries likely have similar capabilities, the news is certainly worrying. To make matters worse, it came just a day after Pew reported that 90 percent of Internet users have taken steps to avoid surveillance in some way. 
http://www.pcworld.com/article/20409...-searches.html
http://www.pcworld.com/article/20431...for-years.html
http://www.pcworld.com/article/20448...-metadata.html
http://www.pcworld.com/article/20481...vey-finds.html

All is not lost, however. While the stunning reports failed to name exactly which companies and encryption technologies have been compromised by the NSA, you can minimize the chances that your encrypted communications will be cracked by the governmentor anyone else. Read on.
Embrace open source

Now that we know that corporationsor at least individuals in corporationshave worked with the NSA to build backdoors into encryption technology, privacy buffs should give commercial encryption technology (such as Microsofts BitLocker) the hairy eye. 

Youre better off using tools that employ open-source or public-domain encryption methods, as they need to work with every vendors software and, in the case of open-source encryption, can be scrutinized for potential security flaws.

With that in mind, here are some tools worth checking out:

    Truecrypt for encrypting sensitive files, folders, and entire drives on your PC.
http://www.pcworld.com/article/24261...documents.html

GPG, an open-source implementation of the OpenPGP protocol used to encrypt email communications. Be sure to read up on why standard-compliant email messages can never truly be secure, though.
http://www.gnupg.org/
http://www.pcworld.com/article/25433...our_email.html
http://www.pcworld.com/article/20469...nd-secure.html

TAILS, a.k.a. The (Amnesic) Incognito Live System, a Linux distribution built with security and anonymity in mind. TAILS comes packed with numerous privacy and encryption tools baked in, including Tor, which allows you to browse the web (mostly) anonymously and access a Darknet of so-called Hidden Services that grant anonymity to both web servers and web browsers. Bruce Schneiera longtime security guru who has actually read the documents detailing the NSAs encryption-busting methodsrecommends using Tor and Hidden Services to thwart NSA surveillance. TAILS is meant to be used as a live CD, which means you can boot it from a disc or USB drive, and your data is wiped when you power off your system.
https://tails.boum.org/
http://www.pcworld.com/article/20263...anonymity.html
http://www.pcworld.com/article/20462...hable-web.html
http://www.theguardian.com/world/201...e-surveillance
http://www.pcworld.com/article/21948...ux_livecd.html

Off-the-record messaging, or OTR, a cryptographic protocol for encrypting and authenticating instant-messaging communications. The protocol uses AES and SHA-1 standards and comes baked into TAILS and is recommended by Schneier even in the wake of the NSA revelations. Heres a list of IM software that supports OTR.
http://www.cypherpunks.ca/otr/
http://www.cypherpunks.ca/otr/software.php

Proprietary encryption tools created overseas maymayalso be less likely to have installed NSA-friendly backdoors into their software. This morning, I received an email from Boxcryptor, the superb (and Germany-based) cloud-storage encryption tool, reassuring me that there is no way for the company to snoop on its customers, as it encrypts files using private RSA security keys stored only on users private PCs, then transmits the already-encrypted files using HTTPs. 
http://www.pcworld.com/article/20402...the-cloud.html

Going further

Beyond encryption, most of the advice in PCWorlds How to protect your PC from Prism surveillance still applies. Note, however, that the New York Times report on the NSAs crypto-cracking abilities suggest that VPN technology and the ever-popular SSL web protocol have been two encryption methods particularly targeted by the government. (Schneier suggests using TLS and IPsec whenever possible on the web-communication front.) 
http://www.pcworld.com/article/20410...rom-prism.html
http://www.nytimes.com/2013/09/06/us...nted=2&_r=2&hp
http://en.wikipedia.org/wiki/IPsec

Even so, using the tips in that article will make your browsing much more secure in general, not just the NSA or foreign governments.

Also check out PCWorlds guide to encrypting (almost) everything, which is chock full of handy-dandy encryption tips, though many rely on proprietarynot open-sourcetechnology. While closed-source solutions may not protect against The Man and his super-encryption-cracking eyes, theyll help keep everyone else out of your business. 
http://www.pcworld.com/article/20254...-anything.html

How to protect your PC from Prism surveillance
http://www.pcworld.com/article/20410...rom-prism.html

Avoid using popular Web services
Ditch your smartphone
Encryption, encryption, encryption
Subscribe to a VPN
Watch those hotspots
Obviously, block that malware
Tie it up together with a hard password knot

-t

----------


## tangent4ronpaul

BULLRUN Briefing Sheet From GCHQ
http://www.propublica.org/documents/...from-gchq.html

(extracts)
(uncorrected OCR follows...)

At SECRET STRAP1 COMINT AUSCANZUKUS EYES 

The fact that GCHQ has unspecified capabilities against network security
technologies eg *SSH, VPNs, lPSec.* NB capability does not
necessarily equate to capability.

At TOP SECRET STRAP1 COMINT AUSCANZUKUS EYES 

The fact that GCHQ or its Party partners has some capability against the
used in a class or type of network communications technology. For
exarnpie, *VPNs, lPSec, SSH, chat, VolP.*

GLOSSARY

(U) -- HTTP traffic secured inside an session, indicated by the
URL, commonly using TCP port 443

(U) IPSEC -- lPSec, or IP Security, is the Internet Engineering Task Force (IETF)
standard for layer 3 real--time communication security. lPSec allows two hosts (or two
gateways) to establish a secure connection, sometimes called a tunnel. All traffic is
protected at the network layer.

(U) SSH -- Secure Shell. A common protocol used for secure remote computer
access

(U) SSL - Secure Sockets Layer. Commonly used to provide secure network
communication. Widely used on the internet to provide secure web browsing,
webmail, instant messaging, electronic commerce, etc.

(U) TLS -- Transport Layer Security. The follow--on to SSL, and are
nearly identical.

(U) VolP -- Voice over Internet Protocol. A general term for the using IP networks to
make voice phone calls. The application iayer protocol can be standards-based 
H.323, SIP), or proprietary Skype).

(U) VPN -- Virtual Private Network. A private network that makes use of the public
telecommunications infrastructure, maintaining privacy via the use of a tunneling
protocol and security procedures that typicaliy include Common protocols
include IPSEC and PPTP.

=======
OK, lets talk about what seems to be secure.  Early on, Snoden talked about getting in contact with the Journalists securely.  He said he sent an initial message, presumably with a public key.  Then sent an encrypted message with encryption instructions and a password.  He said this was the risky part.  The implication is that there are some problems with public key/RSA based systems.  AES-256 is a symmetric encryption algorithm, meaning that the same password is used to encrypt and decrypt messages.  Wikileaks publishes it's insurence files in AES256, Miranda was found with 40GB of data encrypted using TrueCrypt which uses AES256 and according to tweeted UK court testimony, GCHQ is unable to break into any of the files except the one they have a password for.  Therefore, I think it's safe to assume that AES256 is a safe encryption algorithm, for now. (It has been noted, that that might depend on which libraries you use...)

As to VPN's, one outlet reported that GCHQ had broken or circumvented the encryption of 30 of them and hoped to have compromised 300 by 2015, so unless you are a card carrying member of AQ or the mob, you are probably safe for a few years...

Come on geeks - lets hear from you! - chime in!

-t

----------


## idiom

Now they can eavesdrop on anybody who isn't a terrorist.

This is a massive problem for America. Basically they have just announced that all of America's security has been deliberately compromised from the inside. Every commercial software or hardware encryption system is compromised until proven otherwise.

So instead of having to break AES you just have to break into the back-doors.

Not that it matter much. Anything really important isn't on any sort of network. And if you want access to it you need rubber hose cryptoanalysis.

However, little everyday things like internet banking are all vulnerable.

----------


## idiom

I think the best thing we could do as activists is to start calling all the places you do business with and ask them when they plan to replace American software and hardware with stuff that doesn't have security holes all the way through it. Tell them you are willing to move your business on the basis of privacy and security.

Banks.
Lawyers.
Hospitals.

The only thing that gets people moving is economic backlash.

----------


## presence

subscribed

----------


## CPUd

Here is the distrowatch page for tails:

http://distrowatch.com/table.php?distribution=tails

----------


## american.swan

Tangent, that's a very good pastebin, but NOT the one I was referencing. I think this was what I was looking for....http://pastebin.ru/1XpK7B66

----------


## XTreat

slightly overwhelming and I am far from a novice.

----------


## Working Poor

I am subscribing to this even though I don't  understand most of it.

----------


## tangent4ronpaul

http://www.mail-archive.com/cryptogr.../msg12411.html

Security fails on the Internet for three important reasons, that have
nothing to do with the IETF or the technology per-se (except for point
3).

 1.  There is little market for “the good stuff”. When people see that
     they have to provide a password to login, they figure they are
     safe... In general the consuming public cannot tell the
     difference between “good stuff” and snake oil. So when presented
     with a $100 “good” solution or a $10 bunch of snake oil, guess
     what gets bought.

 2.  Security is *hard*, it is a negative deliverable. You do not know
     when you have it, you only know when you have lost it (via
     compromise). It is therefore hard to show return on investment
     with security. It is hard to assign a value to something not
     happening.

 2a. Most people don’t really care until they have been personally
     bitten. A lot of people only purchase a burglar alarm after they
     have been burglarized. Although people are more security aware
     today, that is a relatively recent development.

 3.  As engineers we have totally and completely failed to deliver
     products that people can use. I point out e-mail encryption as a
     key example. With today’s solutions you need to understand PK and
     PKI at some level in order to use it. That is likely requiring a
     driver to understand the internal combustion engine before they
     can drive their car. The real world doesn’t work that way.

No government conspiracy required. We have seen the enemy and it is...

-t

----------


## tangent4ronpaul

https://www.schneier.com/blog/archiv...a_is_brea.html

Selected excerpts from Schneier's replies to readers questions on his article on protecting yourself from the NSA:

Remember this: The math is good, but math has no agency. Code has agency, and the code has been subverted. 

Bruce Schneier  September 5, 2013 4:07 PM

"On the crypto bits in your guardian piece, I found especially interesting that you suggest classic discrete log crypto over ecc. I want to ask if you could elaborate more on that."

I no longer trust the constants. I believe the NSA has manipulated them through their relationships with industry.

Bruce Schneier  September 5, 2013 4:09 PM

"Why then do you and others take such care to not really be open and share all of the Snowden documents?"

I believe the Guardian and Greenwald have both written about this.

It's not my show; I am not in charge of what gets released.

Bruce Schneier  September 5, 2013 4:10 PM

"Please expand on the undocumented command line option in Password safe. Security by obscurity doesn't work."

I added it in an early version.

There's no obscurity. It's Blowfish -- you can verify the implementation with any other implementation.

Bruce Schneier  September 5, 2013 4:14 PM

"From the Guardian report: 'It shows the agency worked covertly to get its own version of a draft security standard issued by the US National Institute of Standards and Technology approved for worldwide use in 2006.' Which standard is that?"

I don't know. DUAL_EC_DRBG, perhaps?

https://www.schneier.com/essay-198.html



Bruce Schneier  September 5, 2013 4:18 PM

"I would be really interested to know if RSA or DSA are preferable where there is a choice. RSA is most likely a more interesting target, on the other hand, DSA fails horribly if you ever use a key on a system with a broken PRNG. Since PRNGs are obviously a prime target for subverison, my gut feeling would be not to touch DSA with a 10-foot pole."

In general, I don't think there is a difference. Cryptanalytic advances against one transfer to the other.



Bruce Schneier  September 5, 2013 4:35 PM

"Could the NSA be intercepting downloads of open-source encryption software and silently replacing these with their own versions?"

Yes, I believe so.

Bruce Schneier  September 5, 2013 4:37 PM

"What's the likelihood that an open-source security product (perhaps something like SELinux, which NSA contributed much of the code for...) contains vulnerabilities that are subtle enough to withstand non-expert scrutiny?"

Less likely than a closed source product.

All we're doing here is playing the odds.



Bruce Schneier  September 5, 2013 4:59 PM

"You encourage us to prefer older discrete log systems over elliptic curve systems. I know about the dual ec prng vulnerability. But what about P-521 and that family of NIST curves? Are these magic numbers a legitimate cause of concern?"

I personally am concerned about any constant whose origins I don't personally trust.



Bruce Schneier  September 5, 2013 5:03 PM

"ahh... but what exactly is not broken? how far can we trust the maths?"

I don't know. This is what I think:

https://www.schneier.com/essay-446.html



Bruce Schneier  September 5, 2013 7:30 PM

"I see you're still comfortable working with Truecrypt. Is it too much to ask if you're using the pre-compiled executable available for download, or only if your comfort level attaches only to a version you've compiled yourself?"

I don't compile.

Basically, I'm just playing the odds here. I think TrueCrypt is less likely to be backdoored than either PGP Disk (what I was previously using) or BitLocker.

Bruce Schneier  September 5, 2013 7:32 PM

"You recommended to 'Prefer symmetric cryptography over public-key cryptography.' Can you elaborate on why?"

It is more likely that the NSA has some fundamental mathematical advance in breaking public-key algorithms than symmetric algorithms.

Bruce Schneier  September 5, 2013 7:34 PM

"Using OTP with other encryption methods probably won't make the security any worse, especially when there is reason to suspect that some of those other encryption methods might be broken."

One-time pads are worse than symmetric algorithms. Don't let the theoretical security fool you.

https://www.schneier.com/crypto-gram-0210.html#7



Bruce Schneier  September 6, 2013 5:12 AM

"In your opinion, would you describe signed and encrypted email using CA-issued 2048-bit certs for broken or are they still secure enough?"

I would assume that the CA is either colluding with the NSA, or that NSA hackers have broke into the CA and stolen the master private key.

I don't know about 2048-bit RSA, but when I made a new key recently I chose 4096 bits -- just to be safe.



Bruce Schneier  September 6, 2013 5:15 AM

"My question is, is this realistic? Can it be realistically assumed that NSA has the capability to go through a trillion guesses per second? Or was Ed Snowden perhaps exaggerating to ensure that Laura selects a really strong password?"

I have no special knowledge, but it seems like an exaggeration to me.



Bruce Schneier  September 6, 2013 5:27 AM

"'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.' I initially felt that maybe you knew something from looking at the documents that would have backed this up. Reading your responses above though, it seems that you do not know which algorithms are safe."

Correct. I have no special knowledge about any specific algorithms.

Bruce Schneier  September 6, 2013 5:28 AM

"Ok, on to the big question. Is AES safe?"

I am trusting it.



Bruce Schneier  September 6, 2013 5:29 AM

"In describing your own practice, you mention that you don't use all the security tools all the time, and that you use a machine with an air gap for highly sensitive material. I wonder how this squares with the notion of trying to improve everyone's security by getting as many people as possible to encrypt as much as possible."

Good security is too annoying to do all the time. Life is compromise, and it's no different in security.



Bruce Schneier  September 6, 2013 7:02 AM

"However I found your tacit endorsement of Silent Circle a little out of character for you."

As I keep saying, I'm playing the odds. I don't know what is strong and what has been compromised. I only know what sorts of attacks the NSA tends to prefer, and what sorts of targets are more vulnerable to those attacks.

I know some of the people behind Silent Circle very well. And I don't have anything better for my iPhone.

Bruce Schneier  September 6, 2013 7:03 AM

"It doesn't look like there was any information about AES though in these documents. Bruce says he trusts it. That's enough for me. Then I trust it too "

Clearly I need to write an essay about how to figure out what to trust in a world where you can't trust anything.



Bruce Schneier  September 6, 2013 10:12 AM

"Honest question Bruce. I know nothing of your politics, but are you not a little concerned about this? Are you not a little concerned that so many media organizations have access to 50,000+ highly classified documents? How secure are those documents, at this point?"

Yes. I'm concerned with it. Their opsec is worlds different than the NSA's.

Part of the problem is that everyone is guessing what is really worth protecting. "Will publishing the article on this cause someone who is now using it to switch to another method? Is that someone bad and planning actions that could harm Americans?"

Those with the documents are doing their best to make reasonable judgements. If the government was more open to a meta-discussion on what should or should not be made public, then there might be ways to better protect the important things. But by reflexively pushing back and refusing to engage at all, they lose that chance.

The underlying problem is overclassification, and a "secrecy above all" mindset.



Bruce Schneier  September 6, 2013 10:25 AM

"I do not even want to guess how many colleagues of Snowden have sold their knowledge to criminals, spies, and commercial parties? And how many of these back-doors are circulating among criminals?"

Yes. The fact that the NSA still has no idea what Snowden took, and would not have known he took anything at all if he didn't go public, strongly implies that he is not the first.



Bruce Schneier  September 7, 2013 9:53 AM

"Regarding the command line options in Password Safe, what are the command line arguments?"

pwsafe [-e|-d] filename

That's how you get to the undocumented encryption feature. A dialog box will prompt you for the password. (Yes, we know that asking for the password twice for decryption makes no sense.)

Bruce Schneier  September 7, 2013 9:55 AM

"Who are the companies? Which companies implemented back doors for NSA as stated in the leaked documents?"

I do not know.

Bruce Schneier  September 7, 2013 9:58 AM

"Bruce, you say you've seen a lot of the Snowden documents, and presumably that means you have or had full unredacted copies of them, and you've alluded to controversies over how much to release. What leads *you* not to release those documents you have/had in full? Why not give others a chance to pore over the details and glean things you might have missed about how to improve security? Is it simply that you feel bound by an agreement with the Guardian and/or Greenwald? If so, are you pushing back on the terms of that agreement or questioning its justification? Or do you believe, for example, that unredacted releases might jeopardize Snowden himself or his ability to release further newsworthy information?"

These are not my documents to release. I was allowed to see them under a set of rules, and I agreed to abide by those rules. The reporters who are working with these documents are putting themselves in considerable personal danger -- the UK has much more onerous laws about this than the US -- and I will not make things worse for them by publishing anything on my own. Nor will I make things worse for Snowden, or our ability to publish further.

-t

----------


## tangent4ronpaul

Clive Robinson  September 6, 2013 6:40 AM
@ Albert,
With regards,
Ok, on to the big question. Is AES safe?
The answer is "you known not what you ask" and because of that the reply of "Maybe, probably not and definatly not" is going to look odd at best :-)
I'm not trying to be either rude or pick on you or the many others who are asking the same question in their heads but out of fear/etc won't ask.
The problem is in part the way we use "AES" as a shorthand and assume that others will know which one of the mtriad of possible meanings we are using from the context of what we are saying.
AES is the standard that resulted from a competition to find a replacment for the previous US encryption standard DES.
At it's heart is a crypto-primative algorithm.
So the first of my three answers "maybe" applies to the algorithm. That is we beleive the algorithm is secure in the light of knowledge current in the open community at the time the algorithm was selected. But we also kknow by the same measure other algorithms submited were probably more secure and almost certainly still are. What we don't know is what is yet to be discovered in the way of breaking the algorithms or what the closed community of the NSA know but are not saying (we know they certainly rigged the competition process).
So onto my second answer of "probably not" any encryption algorithm is fairly usless on it's own as in effect a block cipher like the AES algorithm, is a glorified "substitution cipher" which used that way it can be increadably weak. Thus the algorithm is used inside other algorithms known as modes hence you see AES-CBC, AES-CTR where the mode type appears after the hyphen. Now most modes are designed for protecting data "on the move" as opposed to "data at rest" whilst some modes are good for the former they may be terrible for the latter. But within the mode algorithms are "magic numbers" and assumptions such as "nonces" or even other algorithms when having "tweakable algorithms". One such is XTS used in TrueCrypt and the algorithm is known to be brittle in use due to underlying assumptions which is why there are recomendations that people need to follow if the use is going to match the assumptions. This causes real world issues when using Flash drives for instance.
Which brings me onto my third answer of "definatly not" which relates to real world implimentations and use. The AES algorithm and the mode algorithms have to be turned into lists of instructions for the system they are to run on. In most cases this is a highlevel programing language that is compiled and run time linked into the OS which produces CPU level instructions called machine code. In turn the machine code is interpreted in the CPU into micro-code which drives the data through CPU latches around the various parts of the ALU and register files etc within the CPU. These parts of the CPU are in turn made of logic gates which have power consumption signitures and time delays and thes can and do open up side channels. I mentioned early that the NSA rigged the AES competition, that is they advised NIST on the selection criteria which ment that all the cadidates had to "post their code" they also had to meat certain criteria such as speed the number of gates used etc. These criteria lead the cadidates optomise their code as "efficient" as possible to each criteria. Now as the NSA GCHQ et al know very well the more efficient you make the implementaiton of crypto code the more side channels it has unless extream caution is observed. One thing we do know is that optomised for speed and minimized number of gates is an almost certain guarentee of side channels no matter how clever you are. Also the NSA knew that developers would not write their own code they would simply download and use the competition candidate code.
As was pointed out and demonstration code exploited implementations of AES were subject to timing attacks that could fully leak the key across a network connection due to "cache hits" on the Intel x86 platform from base level pentiums upwards within weeks of the winning candidate being anounced. Even today there are very side channel suseptable AES implementations in use infact the majority of those implementaitons on the likes of routers and switches are timing channel cursed as are most application level software implementations that are more than a year or so old...
It's why I tell people never to encrypt or decrypt data on a computer that is connected to an external network, do it just once and the key may well be compromised.
I hope that answers your question satisfactorly.
@ David Jao,
You say the seed is publeshed, but you forgot to mention that unless the standard uses a seed that is verifiably independent (say first hundred digits of Pi or some other well known constant that has been known for more than 100years) then it is just another unknown magic number irrespective of how many times it's been hashed.
Further we know that hash collisions can be computed much faster than "brute force" for one hash construct, and we also know that the NSA or other US agency knows atleast one other way to arive at collisions than the open community did when it poped up in some network malware. It would be foolish to think that they did not know short cuts to collisions for other hash constructs, simply because they alowed it's existance to become known.
@ Knuth,
Open source is in the open, you can't hide nsa bugs in it
Yes you can you only have to be marginaly smarter than those doing the code review. I've mentioned this several times in the past, and it's one of several reasons I think "code signing" has little if no real security value.
@ Dave,
I think you will find that microsofts software updates have already been compromised in the past.

Squyd  September 6, 2013 12:51 PM
@Bruce,
So, Bruce, it seems from much of what has been published about these recent revelations, and comments on this thread, we can summarize with the following observations and conclusions...
A. For users concerned about securing their computers against theft, TrueCrypt is likely the best choice (over PGP Whole Disk Encryption). TrueCrypt does NOT protect against network intrusion.
B. For encrypting backups and files uploaded to cloud services and email attachments, using a downloaded source code compiled by the end-user (where available) may offer more confidence than the pre-compiled installer. If the end-user can't or won't compile the source code himself, then use the pre-compiled installer, but realize that a backdoor (which may be discovered if it were in the source code) cannot be checked IF its in the installer.
C. Free, Open Source software such as GPG, TrueCrypt, may offer more confidence over PGP and PGP Whole Disk Encryption because its more likely that large companies are cooperating with the N.S.A., whereas the developers of free software have less to loose and therefore may be less likely to cooperate. This also applies to anti-spyware and anti-virus software, and password management software. PGP was recently re-branded "Symantec Encryption". Remember when Peter Norton sold Norton Anti-Virus to Symantec back in 1990? 
[NOTE: This also implies that free software developers can be more easily "disappeared" or otherwise harassed in other ways by an organization with a multi-billion dollar budget. Also, governments may be able to routinely, covertly substitute a compiled installer (supposedly compiled from a published sourcecode) with one in which it has inserted a backdoor.]
Such developers should also publish the hash of the installer which THEY compile themselves. If they refuse...
D. Symmetric/Conventional encryption keys with length (at least 24 characters) AND complexity (lower case, upper case, numbers, special characters) is preferable to Asymmetric (public-key encryption) keys, but if users MUST use public-keys make sure they are at least 4096 bits... with a passphrase of... wait for it... at least 24 characters with complexity.
E. TSL/SSL/SSH/HTTPS are probably compromised by the N.S.A. and any protection they offer is ONLY viable against small to medium B2B corporate espionage, and relatively inexperienced hackers; not by governments with multi-billion dollar budgets.
F. Any OS whose sourcecode is not available is likely to be from a very large company cooperating with a government to insert vulnerabilities and backdoors. OSs are expensive to produce and thus only a large company is able to produce (and market) such a product.
The solution here is to have a FREE OS which is built with security in mind by an opensource collaborative, which can EASILY (the key word is EASILY) be installed over the factory OS on a computer. However, it would take years to develop, and it would be VERY difficult to identify and catch any fellow contributor who was secretly working for a government to actually ADD vulnerabilities to the free OS.
G. As far as vulnerabilities and backdoors which were designed and installed at the hardware-level, its not likely that end-users can EASILY detect and eliminate them. I suppose that a diagnostic software program could be developed that would deep scan and test EVERY component of the hardware to detect behavioral capabilities and such, but ONLY if it was installed on a computer running the free OS and ONLY if that free OS did not itself have vulnerabilities could users be reasonably confident that the hardware was not performing odd, unknown actions behind the user's back. Until an end-user can build his own chips, disks, and all other components of a computer, and assemble them for less time effort and money than it takes to go to a big-box store or order it from the web, this is NOT something an end user can do very much about.
Thoughts, anyone?

Nick P  September 6, 2013 3:47 PM
@ Wayne and Charlemagne
re password safe command line
I was curious too. A quick search turned up nothing from project web site so I downloaded the source code zip and looked in there. Here's some commands I found in the help folder (copied verbatim):
"Invoking Password Safe with no arguments will cause the application to prompt you for the combination of the last database that was opened, or for the combination of a new database if none was previously opened on your machine (e.g., the first time you use Password Safe). It is, however, possible to modify this by invoking Password Safe as follows:
pwsafe database
This will open the specified database file, instead of the last one opened. If just a filename is given, without a path, it will be searched for in the directory in which the application was invoked. Note that if the filename and/or path has spaces, it should be enclosed in double quotes.
pwsafe -r [database]
This will open the specified database in read-only mode. If a database is not specified, then the application will prompt the user for a database, which will be opened in read-only mode.
pwsafe -e filename
This will prompt the user for a passphrase, and encrypt the file with a key derived from the passphrase. Note: The file can be any file. The encrypted file will have the same name as the original file, with ".PSF" appended to it.
pwsafe -d filename
This will prompt the user for a passphrase, and decrypt the file with a key derived from the passphrase. Note: This will work only on files that were encrypted by invoking pwsafe with the '-e' option (see above).
pwsafe -c
This will start the application closed, that is, with no database, and without the initial opening dialog (To access a database, use the File menu).
pwsafe -s [database]
This will start the application "silently", that is, minimized and with no database (unless one is specified). When the application is restored, the user is presented with the opening dialog box (This option is meant for starting the application upon login, via a shortcut in the user's Startup folder). Note: This implicitly puts the application in the system tray.
pwsafe -m
This is the same as the '-c' option, with the addition that the application is started as minimized.
In addition, the following options are accepted and may be useful if you wish to share the same preferences across several machines, for example, when running Password Safe from a disk-on-key.
-u username
This will cause the application to read and write preferences under the specified username, instead of under the login name.
-h hostname
This will cause the application to read and write preferences under the specified hostname, instead of under the machine's name.
-g config_file
This will cause the specified file to be used for loading and storing preferences, instead of the default pwsafe.cfg. If just a filename is given, without a path, it will be searched for in the directory in which the application was invoked. Note that if the filename and/or path has spaces, it should be enclosed in double quotes.
Finally, there are some special command line flags beginning with "--". They are:
--novalidate
This will prevent Password Safe validating databases automatically when they are opened. Some validation is always required e.g. uniqueness of the entry's ID and the group/title/username combination.
--testdump
This allows testers to verify the mini-dump production when Password Safe has a problem to help developers resolve the isssue.
--cetreeview
A new feature allows two entries to be selected and compared either via the Edit menu or by right-clicking on either. Selecting more than one entry is natively supported in the List view but not in the Tree view. This flag enables "Compare Entries" in the Tree view via an extra dialog to select the "other" entry. Supporting multiple selction in the Tree view is under development. Once supported, this flag will be ignored."
END OF COPY/PASTE
I didn't do a source audit so there might be more commands. I would guess that "pwsafe -e filename" is the method Bruce referred to when he said he uses PWSafe to encrypt files. 

John Gilmore  September 6, 2013 5:35 PM
Regarding leaking information in nonstandard Ethernet packets:
*Tsutomu Shimomura*[1] built a patch for an old Sun operating system many years ago, which leaked information using the trailing bytes of short IP packets. At the time he was collaborating with NSA some of the time, so they undoubtedly know of this technique.
See, IP packets such as acknowledgements or TCP open packets are often shorter than the minimum length of Ethernet packets. IP packets can be as short as 20 bytes. When transmitted, the IP packet is padded out to the minimum Ethernet packet size of 64 bytes (46 bytes of payload).
That padding is supposed to be zeroes on transmission (see RFC 894), but under the standard Jon Postel rules of "Be conservative in what you send, and liberal in what you accept", recipients don't check to see if this padding is actually zeroes. So, subverted sending sites are free to put anything they want in there -- like passwords, private keys or random number seeds useful to NSA.
Now, you might expect that as soon as such a nonzero-padded Ethernet frame was received at an IP router, the frame itself would be discarded, and only the shorter IP packet contained within it would be forwarded on toward the destination. This would cause the loss of this information, since if the router isn't subverted, the new frame containing that IP packet would be padded with zeroes. For a large number of routers, this expectation would be wrong. High speed routers tend to route frames rather than IP packets; for example, the first packet to a destination sometimes causes a software lookup, then the hardware is configured to automatically forward the frame for each subsequent packet. Low speed software-based routers may reuse the received packet buffer for the transmitted packet. The padding bytes could be copied over by "accident" or by intent. In your own network, check it yourself by patching the padding values in your kernel's short packets, and seeing how far along your networks the padding persists (perhaps in your network it gets all the way to the destination of the IP packet).
For NSA's purposes the extra data only has to get as far as one of the places that NSA has subverted -- say, for example, AT&T -- where they can snarf up the secrets from the padding data.

[1] -t here.  Tsutomu Shimomura is a legend.  When I first caught wind of him, he was writing software for cell phone tower triangulation and signal interception for the NSA. (this was 20 years ago).  He also helped take down Kevin Mitnick.

https://en.wikipedia.org/wiki/Tsutomu_Shimomura

Author Bruce Sterling described his first meeting with Shimomura in the documentary Freedom Downtime:
 	It was in front of Congress, and I was testifying to a Congressional subcommittee. And here was this guy in sandals and, like, ragged-ass cutoffs, and the rest of us were done up in ties [...] giving our best sort of 'yes, we're in front of Congress' thing and Shimomura is there in this surfer gear.  Gilmore and some others I'm quoting are some pretty interesting cats too... /-t


unimportant  September 8, 2013 1:19 PM
@random832, Alan Kaminsky, Quartermain
Here is a little batch file which proved to me the identity of the disassembler listings of the self-compiled files with the original TrueCrypt binary files: http://pastebin.com/KYik91Wg


MarkH  September 8, 2013 2:47 PM
Regular readers of this blog will already know about this, but as a reminder, and for the benefit of anyone else concerned about confidentiality:
Software encryption provides no protection against an adversary able to physically access your computer while an encrypted drive is mounted (open), whether the computer is running or in hibernation.
The reason for this, is that while an encrypted drive is mounted, the encryption key is stored in the computer's RAM. Contrary to what you might expect, finding such a key is not difficult.
ElcomSoft sells a software package that extracts the keys from either a RAM dump, or a hibernation file on the disk. It works against the most popular disk encryption products, including TrueCrypt.
This vulnerability is not due to a design fault in these disk encryption systems -- it is a practical limitation of software disk encryption.
Practical protection measures against this:
(a) avoid hibernation with an encrypted drive mounted whenever the computer is vulnerable to physical access by an adversary
(b) ensure that all encrypted drives are dismounted whenever the computer is vulnerable to physical access by an adversary
Note that well-designed disk encryption software will "erase" the key from RAM when dismounting the drive. If you're not sure that the software does this, then you need a stronger condition:
(c) ensure that the computer has been powered off (NOT suspended) for at least several minutes at any time it is vulnerable to physical access by an adversary. If insufficient time has elapsed since power down, the adversary can recover RAM data.
NOTE: I haven't checked whether any particular encryption software erases the key on dismount. If you use TrueCrypt's key caching feature, you are obviously asking it to keep key information in RAM, making the encrypted drive(s) vulnerable at least until TrueCrypt is shut down.

-t

----------


## GunnyFreedom

So; are folks ready to be able to buy $700-$1200 NSA-Proof computers yet?



On different kinds of encryption;

The most guaranteed-safe encryption in the world is called the "One Time Pad" and to use it safely, you physically courier say 100 of them to your destination, and use them only once each, after 100 encrypted messages you have to physically courier another 100 over.  Using the same OTP more than once results in patterning, which can lead to breaking the code.

I have a methodology that removes the necessity for repeat couriers, and you only need the first courier with the first OTP.

Because an OTP is basically unbreakable, and if done right you can't even do a 'man in the middle' attack, you can eliminate the need for multiple curriers by using an OTP to send a set of OTP's.  There would be no patterning because OTP's are by nature purely random.  So the data being encrypted is already garbage, so no patterns can emerge that will lead to cracks.

Physically courier the first 366 OTP's to your destination, use them once a day (or better yet, once per message, but I would do once a day myself -- easier to serialize which codec is being used on what day so both ends agree, divide the OTP into 10 chunks and revolve them, so you may as well be using a new OTP for every message so far as a third party cracker is concerned) and then use the last OTP to transmit another 366 OTP's (meaning the last OTP should be 366 times longer than each of the other 365)

The only added danger from the always-courier method would be if the destination end was compromised, in which case the always-courier method isn't going to add much in the way of security anyway.  If a single message was cracked, they might be able to reverse engineer that section of the master OTP, but since that section was ONLY used to transmit that ONE OTP, it would only open up the one message they had already managed to crack anyway.

Using an OTP to transmit OTP's is a workaround from having to keep physically couriering new pads whenever your stack runs dry.  It's not as secure as the always-courier method, but it's only a hairs breadth less secure, given that the traditional multi-use OTP vulnerabilities such as emerging patterning will NOT emerge given that the encrypted data was already random bits anyway.

If I can get Discreet Digital off the ground, I already have the model for an NSA-Proof computer ready to build and sell.  I will spend the next 8-12 months with ridiculous experts to set up NSA-Proof networking and WAN traffic between NSA-Proof computers.  It will probably have some kind of OTP setup at the heart of it's critical traffic channel.

----------


## tangent4ronpaul

Gunny, not impressed with this post.

You need to do more research on OTP's.  Besides being a pain to use, the key word here is "random".  PRNG's in computers libraries are not "random".  As it turns out, what the gvmt used to use to generate OTP's, radioactive decay, turns out to not be so random either.

You are proposing physically sending a recipient a OTP that you will repeatedly use to transmit other OTP's.  And then use these OTP's to encrypt messages based on a 26 letter alphabet that has frequency patterns associated with each letter and letter placement in a word.  Bottom line: send 2 messages on OTP's transmitted this way and you are $#@!ed!  It does not work!

Your project sounds pretty good otherwise.

-t

----------


## GunnyFreedom

> Gunny, not impressed with this post.
> 
> You need to do more research on OTP's.  Besides being a pain to use, the key word here is "random".  PRNG's in computers libraries are not "random".  As it turns out, what the gvmt used to use to generate OTP's, radioactive decay, turns out to not be so random either.
> 
> You are proposing physically sending a recipient a OTP that you will repeatedly use to transmit other OTP's.  And then use these OTP's to encrypt messages based on a 26 letter alphabet that has frequency patterns associated with each letter and letter placement in a word.  Bottom line: send 2 messages on OTP's transmitted this way and you are $#@!ed!  It does not work!
> 
> Your project sounds pretty good otherwise.
> 
> -t


Lots of nope in that.  Too many assumptions that just don't match my plans.  

I will not use an OTP repeatedly, I was simply explaining why one COULD use an OTP repeatedly if the only thing they were transmitting was OTP's.  I would only use an OTP once, to transmit a stack of OTP's that themselves would be used for actual messages.  All of this being at least 512 bit encrypted _in addition_ to OTP.

As for an OTP generator, I still have 8 months after I START selling systems to come up with best-practice on that one, so I have not nailed down a source yet.  Since I won't need it until I start generating secure networks, I was considering the addition of a custom device that draws atmospheric RF noise like random.org, but connected to individual networks, or maybe something that captures cosmic rays.  Algorithms do not generate randomness.  I would also be addressing the entire unicode range, which is more like 110,000 rather than 26.  

The actual computers I've got nailed down.  I will start working on WAN data transmission once the systems start shipping.  I agree that OTP is a PITA, but while making a computer NSA-Proof is _relatively_ easy, passing traffic along a WAN that is NSA-Proof is not quite so easy.  However, If I can get Discreet Digital off the ground, and you have expertise in this area, you may be one of the ridiculous experts I consult to make it work.

----------


## idiom

Two things that are scary when you consider that they are likely true:




> Bruce Schneier • September 5, 2013 4:35 PM
> 
> "Could the NSA be intercepting downloads of open-source encryption software and silently replacing these with their own versions?"
> 
> Yes, I believe so.





> Bruce Schneier • September 6, 2013 10:25 AM
> 
> "I do not even want to guess how many colleagues of Snowden have sold their knowledge to criminals, spies, and commercial parties? And how many of these back-doors are circulating among criminals?"
> 
> Yes. The fact that the NSA still has no idea what Snowden took, and would not have known he took anything at all if he didn't go public, strongly implies that he is not the first.


I mean. Where do you begin.

Consider also, Stuxnet. It used a dozen zero days and had stolen CA's. That all lot of power to not be locked down properly. The idea of the next Stuxnet being stolen is 100% reason to defuns the NSA to about 10% of its size.

----------


## american.swan

> Lots of nope in that.  Too many assumptions that just don't match my plans.  
> 
> I will not use an OTP repeatedly, I was simply explaining why one COULD use an OTP repeatedly if the only thing they were transmitting was OTP's.  I would only use an OTP once, to transmit a stack of OTP's that themselves would be used for actual messages.  All of this being at least 512 bit encrypted _in addition_ to OTP.
> 
> As for an OTP generator, I still have 8 months after I START selling systems to come up with best-practice on that one, so I have not nailed down a source yet.  Since I won't need it until I start generating secure networks, I was considering the addition of a custom device that draws atmospheric RF noise like random.org, but connected to individual networks, or maybe something that captures cosmic rays.  Algorithms do not generate randomness.  I would also be addressing the entire unicode range, which is more like 110,000 rather than 26.  
> 
> The actual computers I've got nailed down.  I will start working on WAN data transmission once the systems start shipping.  I agree that OTP is a PITA, but while making a computer NSA-Proof is _relatively_ easy, passing traffic along a WAN that is NSA-Proof is not quite so easy.  However, If I can get Discreet Digital off the ground, and you have expertise in this area, you may be one of the ridiculous experts I consult to make it work.


Did you read the link in the post about OTPs?

----------


## CPUd

> Two things that are scary when you consider that they are likely true:
> 
> 
> 
> 
> 
> I mean. Where do you begin.
> 
> Consider also, Stuxnet. It used a dozen zero days and had stolen CA's. That all lot of power to not be locked down properly. The idea of the next Stuxnet being stolen is 100% reason to defuns the NSA to about 10% of its size.


If you are downloading manually, it is good practice to verify with md5sum, and most package managers do this also.  On debian-based systems, you can check them all like:
md5sum -c /var/lib/dpkg/info/*.md5sums

caveat: it is difficult, but not impossible to exploit a md5 collision

----------


## tangent4ronpaul

http://www.newyorker.com/online/blog...ncryption.html

Despite the scope of the N.S.A.’s program, and its apparent success against Internet-level encryption, strong encryption schemes do remain uncracked by the N.S.A, and they are “your best bet” for privacy, said Janke. Pretty Good Privacy, a common encryption program, if used with the latest algorithms, remains safe, he added, as does the encryption used in Z.R.T.P., which is used by Silent Circle’s voice and text products to encrypt communications. Janke believes in their security in large part because “it’s good enough for the government to approve it for their use.” Soghoian says that the “the kind of stuff we need is already available, it’s just not in our browsers and not with Google and Facebook.” (However, in response to the N.S.A. revelations, Google has fast-tracked its plan to encrypt data as it zips between its own data centers to prevent it from being subject to intelligence-agency prying.) Janke notes that on a local level, TrueCrypt, a hard-drive encryption program, along with Apple’s native hard-disk encryption tool both remain unbroken. Though Drake said he would only trust 2048-bit level encryption schemes and that he relies largely on open-source software, he would not reveal how he protects his own communications. “I just don’t want others to know how I protect myself,” he said. “I literally do not trust anything commercial.”

http://www.zrtp.org/

-t

----------


## CPUd

How to Explain Zero-Knowledge Protocols to Your Children:
http://pages.cs.wisc.edu/~mkowalcz/628.pdf

Same thing, but in more 'academic' terms:
http://crypto.cs.mcgill.ca/~crepeau/...IC02/GMR89.pdf

----------


## tangent4ronpaul

http://blogs.computerworlduk.com/ope...urce/index.htm

On the other hand, here's an example where the open source process doesn't seem to have helped much. The story starts with Red Hat's implementation of elliptic curve cryptography (ECC) in the widely-used OpenSSL package. Back in 2007, a Bugzilla ticket was opened about certain features that had been disabled because of possible patent issues. That's bad enough, but as Dietrich Schmitz discovered as he explored the Red Hat story, it turns out that it's not just Red Hat's implementation that has problems. A post by the Google engineer Mike Hearn explains:

today I learned (via Gregory Maxwell) that the process for selecting the "random" curve parameters [for ECC] appears on the surface to be completely implausible. The parameters are the output of SHA1, which should be good if the seed was selected in a reproducible manner. But they were not. The seeds are extremely large constants with no explanations of where they came from. That smells very strongly of something that might be hacked.

It gets better. It turns out that these constants are not only unexplainable but were actually generated by an employee of the NSA. And it turns out that the IEEE working group that worked on standards for ECC was actually holding its meetings on the NSA campus and its membership therefore had to be approved by the NSA as well.

-t

----------


## tangent4ronpaul

smartphones - full article
http://www.spiegel.de/international/...-a-921161.html

Points of compromise
http://www.mail-archive.com/cryptogr.../msg12476.html
http://www.mail-archive.com/cryptogr.../msg12523.html

A Few Thoughts on Cryptographic Engineering
http://blog.cryptographyengineering....09/on-nsa.html

Epic: A Chrome Based Privacy-Focused Web Browser
http://yro.slashdot.org/story/13/09/...ed-web-browser
http://epicbrowser.com/

So, You Want to Hide from the NSA? Your Guide to the Nearly Impossible
http://www.theatlanticwire.com/techn...ossible/66942/

Ways To Reduce The Chances Of Being Spied On By The NSA Or Anyone Else
http://www.forbes.com/sites/larrymag...r-anyone-else/


How To Disappear When Someone's Spying On You
http://www.npr.org/blogs/krulwich/20...omes-to-market

Freenet
http://sourceforge.net/projects/freenet/

I2P
http://www.i2p2.de/

Predictive Analytics
http://www.predictiveanalyticsworld....aud-detection/
http://fcw.com/articles/2013/06/12/n...ssessment.aspx
http://papers.ssrn.com/sol3/papers.c...act_id=2050001
http://www.nytimes.com/2012/02/19/ma...nted=all&_r=5&
http://www.digitaltrends.com/mobile/...teered-truths/

Six ways to protect yourself from the NSA and other eavesdroppers
http://www.zdnet.com/six-ways-to-pro...rs-7000016860/

-t

----------


## Uriah

Don't trust any email providers with physical ties to the United States.

From lavabit.com:




> My Fellow Users,
> 
> I have been forced to make a difficult decision: to become complicit in crimes against the American people or walk away from nearly ten years of hard work by shutting down Lavabit. After significant soul searching, I have decided to suspend operations. I wish that I could legally share with you the events that led to my decision. I cannot. I feel you deserve to know what’s going on--the first amendment is supposed to guarantee me the freedom to speak out in situations like this. Unfortunately, Congress has passed laws that say otherwise. As things currently stand, I cannot share my experiences over the last six weeks, even though I have twice made the appropriate requests.
> 
> What’s going to happen now? We’ve already started preparing the paperwork needed to continue to fight for the Constitution in the Fourth Circuit Court of Appeals. A favorable decision would allow me resurrect Lavabit as an American company.
> 
> This experience has taught me one very important lesson: without congressional action or a strong judicial precedent, I would _strongly_ recommend against anyone trusting their private data to a company with physical ties to the United States.
> 
> Sincerely,
> ...




https://lavabit.com/
http://silentcircle.wordpress.com/20...our-customers/

----------


## tangent4ronpaul

http://www.mail-archive.com/cryptogr.../msg12252.html

The actual documents - some of which the Times published with few redactions - 
are worthy of a close look, as they contain information beyond what the 
reporters decided to put into the main story.  For example, at 
http://www.nytimes.com/interactive/2...pagewanted=all,
 the following goal appears for FY 2013 appears:  "Complete enabling for 
[redacted] encryption chips used in Virtual Public Network and Web encryption 
devices".  The Times adds the following note:  "Large Internet companies use 
dedicated hardware to scramble traffic before it is sent. In 2013, the agency 
planned to be able to decode traffic that was encoded by one of these two 
encryption chips, either by working with the manufacturers of the chips to 
insert back doors or by exploiting a security flaw in the chips' design."  It's 
never been clear whether these kinds of notes are just guesses by the 
reporters, come from their own sources, or com
 e from Snowden himself.  The Washington Post got burned on one they wrote.  
But in this case, it's hard to come up with an alternative explanation.


Another interesting goal:  "Shape worldwide commercial cryptography marketplace 
to make it more tractable to advanced cryptanalytic capabilities being 
developed by NSA/CSS."  Elsewhere, "enabling access" and "exploiting systems of 
interest" and "inserting vulnerabilities".  These are all side-channel attacks. 
 I see no other reference to "cryptanalysis", so I would take this statement at 
face value:  NSA has techniques for doing cryptanalysis on certain 
algorithms/protocols out there, but not all, and they would like to steer 
public cryptography into whatever areas they have attacks against.  This makes 
any NSA recommendation *extremely* suspect.  As far as I can see, the bit push 
NSA is making these days is toward ECC with some particular curves.  Makes you 
wonder.  (I know for a fact that NSA has been interested in this area of 
mathematics for a *very* long time:  A mathematician I knew working in the area 
of algebraic curves (of which elliptic curves are an example) was re
 cruited by - and went to - NSA in about 1975.  I heard indirectly from him 
after he was at NSA, where he apparently joined an active community of people 
with related interests.  This is a decade before the first public suggestion 
that elliptic curves might be useful in cryptography.  (But maybe NSA was just 
doing a public service, advancing the mathematics of algebraic curves.)

NSA has two separate roles:  Protect American communications, and break into 
the communications of adversaries.  Just this one example shows that either (a) 
the latter part of the mission has come to dominate the former; or (b) the 
current definition of an adversary has become so broad as to include pretty 
much everyone.

Now, the NSA will say:  Only *we* can make use of these back doors.  But given 
the ease with which Snowden got access to so much information ... why should we 
believe they can keep such secrets?
                                                        -- Jerry

http://www.mail-archive.com/cryptogr.../msg12235.html

BULLRUN seems to be just an overarching name for several wide programs to obtain plaintext of passively encrypted internet communications by many different methods.


While there seem to be many non-cryptographic attacks included in the BULLRUN program, of particular interest is the cryptographic attack mentioned in the Snowden papers and also hinted at in earlier US congressional manouverings for NSA funding.


The most obvious target of attack is some widespread implementation of SSL/TLS, and while it might just be an attack against a reduced keyspace, eg password-guessing or RNG compromise, I wonder whether NSA have actually made a big cryptographic break against some cipher, and if so, against what?


Candidate ciphers are:

3DES
RC4
AES

and key establishment mechanisms:

RSA
DH
ECDH


I don't think a break in another cipher or KEM would be widespread enough to matter much. Assuming NSA (or possibly GCHQ) have made a big break:


I don't think it's against 3DES or RC4, though the latter is used a lot more than people imagine.


AES? Maybe, but a break in AES would be a very big deal. I don't know whether hiding that would be politically acceptable.


RSA? Well, maybe indeed. Break even a few dozen RSA keys per month, and you get a goodly proportion of all internet encrypted traffic. It's just another advance on factorisation.


If you can break RSA you can probably break DH as well.

ECDH? Again quite possible, especially against the curves in use - but perhaps a more widespread break against ECDH is possible as well. The math says that it can be done starting with a given curve (though we don't know how to do it), and you only need to do the hard part once per curve.





My money? RSA.


But even so, double encrypting with two different ciphers (and using two different KEMs) seems a lot more respectable now.


-- Peter Fairbrother

http://www.mail-archive.com/cryptogr.../msg12419.html

Given some of the things in the Snowden files, I think it has become the case
that one ought not trust any mass-produced crypto hardware.  It is clearly on
the agenda of the NSA to weaken the communications infrastructure of American
and other business, specifically at the level of chip manufacturers.  And
*chips are too much of a black-box for anyone to easily inspect and too much
subject to IP/Copyright issues for anyone who does to talk much about what
they find.  Seriously; microplaning, micrography, analysis, and then you get
sued if you talk about what you find?  It's a losing game.
*
Given good open-source software, an FPGA implementation would provide greater
assurance of security. An FPGA burn-in rig can be built by hand if necessary,
or at the very least manufactured in a way that is subject to visual inspection
(ie, on a one-layer circuit board with dead-simple 7400-series logic chips).
*It would be a bit of a throwback these days, but we're deep into whom-can-you-
trust territory at this point and going for lower tech is worth it if it means
tech that you can still inspect and verify.*

                                Bear

http://www.mail-archive.com/cryptogr.../msg12467.html

The most obvious implementation defects are bad RNGs and bad
protection against timing analysis.

One might also add side channels to leak information. Obvious side
channels for malevolent hardware are radio frequency interference (if
you can deploy listening equipment in the same colo this might be
quite a practical way to extract information) and timing channels
(not only in the sense of failure to protect against timing analysis
but also in the sense of using inter-event delays to encode
information like keys).

I think that in most applications power consumption side channels are
probably not that interesting (smart cards etc. being an exception)
but I'm prepared to be proven wrong.

Any other thoughts on how one could sabotage hardware? An exhaustive
list is interesting, if only because it gives us information on what
to look for in hardware that may have been tweaked at NSA request.

http://www.mail-archive.com/cryptogr.../msg12094.html

And, they told us so.  In the comments made by the NSA, they have very
> clearly stated that if there is evidence of a crime, they will keep the
> data.  The statement they made is a seismic shift;  the NSA is now a
> domestic & criminal intelligence agency.  I suspect the penny has not
> dropped on this shift as yet, but they have said it is so.
>

-t

----------


## tangent4ronpaul

https://www.schneier.com/blog/archives/2013/08/

Evading Internet Censorship

This research project by Brandon Wiley -- the tool is called "Dust" -- looks really interesting. Here's the description of his Defcon talk:

    Abstract: The greatest danger to free speech on the Internet today is filtering of traffic using protocol fingerprinting. Protocols such as SSL, Tor, BitTorrent, and VPNs are being summarily blocked, regardless of their legal and ethical uses. Fortunately, it is possible to bypass this filtering by reencoding traffic into a form which cannot be correctly fingerprinted by the filtering hardware. I will be presenting a tool called Dust which provides an engine for reencoding traffic into a variety of forms. By developing a good model of how filtering hardware differentiates traffic into different protocols, a profile can be created which allows Dust to reencode arbitrary traffic to bypass the filters.

    Dust is different than other approaches because it is not simply another obfuscated protocol. It is an engine which can encode traffic according to the given specifications. As the filters change their algorithms for protocol detection, rather than developing a new protocol, Dust can just be reconfigured to use different parameters. In fact, Dust can be automatically reconfigured using examples of what traffic is blocked and what traffic gets through. Using machine learning a new profile is created which will reencode traffic so that it resembles that which gets through and not that which is blocked. Dust has been created with the goal of defeating real filtering hardware currently deployed for the purpose of censoring free speech on the Internet. In this talk I will discuss how the real filtering hardware work and how to effectively defeat it.

EDITED TO ADD (9/11): Papers about Dust. Dust source code.

http://blanu.net/Dust.pdf
http://blanu.net/Dust-FOCI.pdf
http://github.com/blanu/Dust/

-t

----------


## tangent4ronpaul

Tools for breaking out of PRISM:
http://grothoff.org/christian/prism-gnunet-berlin.pdf

Ten ways you can avoid being caught in the PRISM net :
http://theconversation.com/ten-ways-...rism-net-15696

-t

----------


## tangent4ronpaul

Updated SSL/TLS Deployment Best Practices deprecates RC4
September 17, 2013
http://blog.ivanristic.com/2013/09/u...ecate-rc4.html

We are releasing an update to our SSL/TLS Deployment Best Practices document, which is our comprehensive guide to running secure servers. This is our third update since the first release in February 2012; our main goal is to keep the document up to date with the threats as they're evolving.

Since the beginning of the year we saw three major developments:

    In March, a group of security researchers demonstrated that RC4 is seriously broken. Although the attack is not yet very practical, we are now recommending that this cipher is phased out. In the previous versions of the guide we had recommended using RC4 to mitigate the BEAST attack server-side. Clearly, this is no longer possible. Although we think that the BEAST attack can still be a threat in some environments, disabling RC4 globally will take a long time and we believe that we need to start that process straight away.

http://blog.ivanristic.com/2013/03/r...-now-what.html

Last year, we learned about the CRIME attack, which uses information leakage stemming from compression before encryption. This year, CRIME evolved into TIME and BREACH, two attacks that go beyond attacking TLS compression (which is easy to disable without consequences) to attack the ubiquitous HTTP compression. Because they fall outside SSL/TLS, TIME and BREACH can only be addressed by making changes to application source code. For most, this approach will require a lot of work.

http://blog.ivanristic.com/2012/09/c...t-ssl-tls.html
http://blog.ivanristic.com/2013/08/d...ch-attack.html

Finally, this year we also learned some details about widespread surveillance programs worldwide. In particular, it came to light that server private key compromise is a commonly used approach to breaking secure communication. For this reason, we now recommend that all secure servers support Forward Secrecy. With this feature enabled, each connection uses separate encryption keys, which means that the encrypted data remains safe if the server private key is compromised.

http://arstechnica.com/security/2013...rypto-but-how/

In addition to addressing these major threat changes, we took the opportunity to include several incremental updates, for example to recommend that you retire 1024-bit keys, SSL 3, and 3DES. We also included a discussion about new technologies, such as ECDSA keys.

*Download SSL/TLS Deployment Best Practices v1.3 from the SSL Labs web site.*

https://www.ssllabs.com/projects/best-practices/

MY NEXT BOOK: If you like this blog post, you will love Bulletproof SSL/TLS and PKI. This book will contain everything you need to know about SSL/TLS and PKI for web application development and deployment, covering both theory and practice. An early release will be available soon.

https://www.feistyduck.com/books/bul...l-tls-and-pki/

*In the meantime, go download and read my OpenSSL Cookbook ebook. It's free.*

https://www.feistyduck.com/books/bul...l-tls-and-pki/

-t

----------


## tangent4ronpaul

ZPhone:
http://zfoneproject.com/prod_zfone.html

Decentral:  This is like community decentralized WiFi Meshnets
http://www.mercurynews.com/news/ci_2...urce=inthenews

-t

----------


## tangent4ronpaul

http://www.foxnews.com/politics/2013...s-report-says/

The documents Snowden provided indicated that the *NSA can augment the communications data with material from public, commercial and other sources, including bank codes, insurance information, Facebook profiles, passenger manifests, voter registration rolls and GPS location information, as well as property records and unspecified tax data*, the paper reported.

You might keep that in mind the next time you swipe your customer loyalty tag to get the 15 cent discount on a bag of pancake mix...

-t

----------


## tangent4ronpaul

Dup post, I'll keep this as a placeholder for now.

-t

----------


## tangent4ronpaul

Microsoft, Cisco: RC4 encryption considered harmful, avoid at all costs
Why not try this lovely AES-GCM, and don't forget to bin SHA-1, too
http://www.theregister.co.uk/2013/11...moves_off_rc4/

Microsoft has urged the Windows world to dump the once trusty but now distrusted RC4 encryption algorithm – and pick something stronger. Cisco has also told its customers to "avoid" the cipher.

RC4, developed in 1987, is a popular stream cipher that's often used in HTTPS connections to protect sensitive network traffic from eavesdroppers, among other uses.

Academics found flaws in the algorithm years ago, and top-secret documents leaked by ex-NSA contractor Edward Snowden this year suggest US and UK spies have developed "groundbreaking cryptanalysis capabilities", which ultimately allow the intelligence agencies to break RC4 encryption. Distrust of the cipher is therefore widespread but far from universal.

While some experts are sceptical US and UK spies can crack the algo at will, Jacob Appelbaum, a computer security researcher and leading Tor developer, bluntly warned earlier this month: "RC4 is broken in real-time by the ‪NSA‬ – stop using it." Ivan Ristic, director of engineering at computer security biz Qualys, added: "Even if there is no evidence, it’s prudent to assume RC4 is fully broken."

Now this week, Microsoft has gone public to "strongly encourage customers to evaluate, test and implement the options for disabling RC4 to increase the security of clients, servers and applications". Specifically, Redmond wants people to switch to crypto-protocol TLS 1.2 – as used in HTTPS, secure SMTP, VPNs and other tech – and use the strong cipher AES-GCM.

Networking giant Cisco has also, as of this month, downgraded RC4 from "legacy" to "avoid" in its recommendations for cryptographic algorithms.

While moving away from RC4 may seem like a no-brainer in the circumstances, the situation is a bit more complicated than that.

"The problem is stream ciphers like RC4 were one the primary defences used by many websites against the infamous BEAST and Lucky Thirteen attacks," explained Chester Wisniewski in a post on the Sophos Naked Security blog.

"Fortunately TLS 1.2 and AES-GCM are not vulnerable to these attacks and can now officially be considered mainstream," Wisniewski said, adding that the latest versions of web browsers Google Chrome, Firefox, Safari and Opera support TLS 1.2 and AES-GCM.

Windows 8.1 and Internet Explorer 11, both made available mid-October, default to TLS 1.2 and shun RC4. Microsoft has now provided a mechanism to disable the use of RC4 in Windows 7, 8, RT, Server 2008 R2 and Server 2012.

"With Microsoft on board, hopefully we can bid goodbye to old versions of SSL and TLS for good," Wisniewski concluded.

Redmond published advice, tools and more information in this extensive blog post. The software giant added:

In light of recent research into practical attacks on biases in the RC4 stream cipher, Microsoft is recommending that customers enable TLS1.2 in their services and take steps to retire and deprecate RC4 as used in their TLS implementations. Microsoft recommends TLS1.2 with AES-GCM as a more secure alternative which will provide similar performance.
The recommendation comes as a top Microsoft executive admitted that the Windows maker does not encrypt its data-centre links, a ripe target for the NSA and GCHQ.

Bake me a hash cake
In a related move, Microsoft also announced that beginning on January 1, 2016 Windows will no longer support the use of X.509 certificates issued using the aging SHA-1 hashing algorithm for SSL and software code signing:

Microsoft is recommending that customers and CAs stop using SHA-1 for cryptographic applications, including use in SSL/TLS and code signing. Microsoft Security Advisory 2880823 has been released along with the policy announcement that Microsoft will stop recognising the validity of SHA-1 based certificates after 2016.
The older MD5 hashing algorithm was considered weak for many years, but still supported by Windows because many certificate authorities were lax in updating and issued valid MD5 certificates long after the technology was declared flaky.

SHA-1, published in 1995, is significantly stronger than MD5, but Microsoft is withdrawing support for the technology before it is broken, using its market position to push change towards wider use of the newer SHA-2 set of functions: SHA-224, SHA-256, SHA-384 and SHA-512. Encryption experts welcomed the move.

"SHA-1 isn't broken yet in a practical sense, but the algorithm is barely hanging on and attacks will only get worse," wrote encryption guru Bruce Schneier. "Migrating away from SHA-1 is the smart thing to do." ®

How to disable:
http://blogs.technet.com/b/srd/archi...sable-rc4.aspx

Additional info:
https://www.schneier.com/blog/archiv...oft_retir.html
http://www.enisa.europa.eu/activitie...ameters-report

-t

----------

