Stop Calling It “Military-Grade Encryption”
blog.signata.net
blog.signata.net
> I actually do a double-take when a company says "Military-Grade", as I start to question how well they know cryptography, and if they may have picked an inferior algorithm thinking it's safe.
"Military grade" might sound good to marketing people, but to everyone that's actually involved in digital security, it sounds like it's made by people who have no idea what they're doing.
Another phrase like that is "patented technology" or "patent-pending". Maybe it sounds good to some people, but to to engineers it's a big red flag.
Neither are snake oil (unless used in a fraudulent manner..), and can generally be interpreted as the product in question is objectively innovative.
If you want security, use something which is old and well tested.
Stereotype incoming: This might be a cultural thing too. Military grade sounds like something that would play well to the American ear, whereas these guys are British.
Nobody calls a truck engine "military grade" because it's hard to maintain and only works on artisan made nitromethane, a "military grade" truck engine has to be maintained by an ADHD kid who got mediocre grades in shop class and run on whatever counts as "fuel" in the country the truck is passing through.
Passwords for example, are a bad idea, so we want to design a system that doesn't have those. The password step being mindlessly replicated is a bad idea in large part because passwords are themselves a bad idea, if the instructions involved a system that randomly generated session keys the same mindless replication would ensure all recruits used randomly generated session keys - which would be safe.
"So you've got armed guards ready to shoot anyone who messed with it?"
The harder problem is guaranteed delivery, which is impossible using only technology. You might email that order to the General in charge, and if he's out on a toke and doesn't read it within 5 minutes forward the order to his 2IC. And if the 2IC is on the john your only recourse is to forward the message to the nearest permanently staffed guaranteed action point (GAP). The GAP will send out one or more despatch riders to hunt the recipients down in meat space and deliver the message.
In any other scenario the same security best practices apply as in the commercial world, albeit with much more money.
Edited for spelling.
Is this the militarys mitigation of the two generals problem?
Yes, there are differences in quality possible with aluminium, as there are with most materials, but to make "aircraft grade" a main selling point for your sunglasses case is snake oil marketing nonsense.
So there actually exists "aircraft grade" aluminum. It's not a quality thing so much as a question of physical properties.
But in reality as the article points out AES, RSA and others are all used in military and all are military grade, but all have one or the other drawback if not used carefully. This kind of advertising is generally misleading.
Hopefully if someone challenge such claims in court will be nice. But I believe it will be hard to prove if the statement itself is untrue, its just that it is created with a spirit to deceive or conflate the meaning.
https://www.schneier.com/blog/archives/2019/07/attorney_gene...
Posted on July 24, 2019 by Bruce Schneier on Security> Yesterday, Attorney General William Barr gave a major speech on encryption policy -- what is commonly known as "going dark." Speaking at Fordham University in New York, he admitted that adding backdoors decreases security but that it is worth it.
https://news.ycombinator.com/item?id=19916938
In 1998, the EFF and John Gilmore published the book about "Deep Crack" called "Cracking DES: Secrets of Encryption Research, Wiretap Politics, and Chip Design". But at the time, it would have been illegal to publish the code on a web site, or include a CDROM with the book publishing the "Deep Crack" DES cracker source code and VHDL in digital form.
https://en.wikipedia.org/wiki/EFF_DES_cracker
https://www.foo.be/docs/eff-des-cracker/book/crackingdessecr...
>"We would like to publish this book in the same form, but we can't yet, until our court case succeeds in having this research censorship law overturned. Publishing a paper book's exact same information electronically is seriously illegal in the United States, if it contains cryptographic software. Even communicating it privately to a friend or colleague, who happens to not live in the United States, is considered by the government to be illegal in electronic form."
So to get around the export control laws that prohibited international distribution of DES source code on digital media like CDROMS, but not in written books (thanks to the First Amendment and the Paper Publishing Exception), they developed a system for printing the code and data on paper with checksums, with scripts for scanning, calibrating, validating and correcting the text.
[...]
The exposition about US export control policies and the solution for working around them that they developed for the book was quite interesting -- I love John Gilmore's attitude, which still rings true today: "All too often, convincing Congress to violate the Constitution is like convincing a cat to follow a squeaking can opener, but that doesn't excuse the agencies for doing it."
https://dl.packetstormsecurity.net/cracked/des/cracking-des....
[...]
The US Department of Commerce has officially stated that publishing a World Wide Web page containing links to foreign locations which contain cryptographic software "is not an export that is subject to the Export Administration Regulations (EAR)."* This makes sense to us--a quick reductio ad absurdum shows that to make a ban on links effective, they would also have to ban the mere mention of foreign Universal Resource Locators. URLs are simple strings of characters, like http://www.eff.org; it's unlikely that any American court would uphold a ban on the mere naming of a location where some piece of information can be found.
Therefore, the Electronic Frontier Foundation is free to publish links to where electronic copies of this book might exist in free countries. If we ever find out about such an overseas electronic version, we will publish such a link to it from the page at http://www.eff.org/pub/Privacy/Crypto_misc/DESCracker/ .
* In the letter at http://samsara.law.cwru.edu/comp_law/jvd/pdj-bxa-gjs070397.h... , which is part of Professor Peter Junger's First Amendment lawsuit over the crypto export control regulations.
While I despise the term as well, this seems like an exaggeration. It's simply marketing, nothing else. Developers implementing security aren't also making sales decks.
Sure, it's entirely possible that the product itself is absolutely solid. It would be a bit silly to rule a product out on this basis alone. But when evaluating a product, it's fair to "do a double-take" when seeing language like this.
It’s just marketing wank. The majority of marketing is like that, to be honest.
Everyone is trying to over sell everything in every which way.
It’s wholly unremarkable that advertising drivel is completely out of key.
Military projects I've worked on, none of the known algorithms were in use. However, those are not available for commercial use whatsoever.
The author is right about one thing though, since if it is available in the commercial world, it is better off be called as "Industry Standard Encryption".
What do they use? I expected that us military would be 99% FIPS. (Other military could be GOST, I guess)
In that sense, I would expect it to be much more stronger than financial grade or consumer grade encryption system where adversaries are less stronger.
Certain attacks like supply chain attacks (factory, transport etc of hardware components) or special access attacks (Certificate authorities, BGP, DNS, ISPs etc) or social attacks (patsy or spy with MICE/RASCLS) that nation state actors can pull off which others cannot (without prohibitively significant effort or negative consequences).
So, usually if someone says military grade, I would look at it as being resistant to even these threats.
Of course, it is always about the system holistically and not just the AES, RSA, SHA-2 etc algorithms.
I don't think this particular hill is one to die on - the public have a perception that the military are amazing at using the latest and greatest technology, so the marketing teams will always continue to use it. Fighting it will be about as effective as fighting clickbait.
Instead, let it guide your own choices. Any sign like this that shows the marketing team wrote the Security Policy page is one where you should absolutely start questioning if they know what they're doing.
To our definition of "Standard" this means up to scratch and implemented correctly to specification - to the normal folk this is probably interpreted as "regular" or "basic-tier".
I'm a very important and aspirational small shipping/accountancy/dog-walking firm. I don't want that potato-tier regular encryption - I deserve super-duper fabtastic encryption like the banks have.
Maybe we should call it Fabtastic Encryption 12.0 (people like numbers after their software).
> MD5 is thoroughly useless as a hashing algorithm[...] but it was used by the military and banks in the past, so it's technically "Military-Grade"
If it was used by the Industry in the past wouldn't the same hold true for Industry Standard Encryption?
Edit: quote formatting
Out of topic, my phone case - Spigen provide military grade protection too. :)
By far the most likely cause of an error like this (in which the browser clearly connected but didn't like the offered certificates) is that an intercepting proxy aka a MITM or middlebox is between your browser and the remote site and it fucked up.
Things that are intercepting proxies (some of which you might have classified wrongly as something else)
* Most 3rd party AV "solutions" or "endpoint protection" on your machine itself
* WAFs
* Any kind of "Next generation firewall"
* Government or ISP "filters"
All these products are pretty bad, and most are worse than useless. Recommendations to get one or more of them for "security" are probably this era's "Rotate passwords every 30 days" in terms of the actual security behaviour that results as distinct from what the policy proponent imagines will happen.
I think marketing in general could learn something from that. Screen out ridiculous claims that have no basis on the viability on the product, and force people to focus on product and deviances from industry "standard".
For example, your transport layer might be using the same ciphers and key length as a military installation, but if Maureen in accounts can log in from home with the username and password she's used on every site since 2002 and access 400,000 customer details, and download them to an unencrypted file on a personal computer... You're not meeting GDPR obligations, let alone military or banking standards.
... And by tangential extension, I think non-developers might be surprised just how many companies still have absolutely zero effective access control to data. No storage encryption. No plans to warehouse or delete old data. Just records in a database (or shared spreadsheet) where a username and password, and sometimes just network access, will give you PII for every customer in the last 20 years.
[1]: https://ec.europa.eu/food/safety/labelling_nutrition/claims/...
I suspect this is a one-off, but please do reach out to us if you still have issues, I've already passed this along to the team to fast-track support if you do send us an email.
Untrusted why? Dig into the browser's cert details to find out. In Chrome devtools (ctrl+shift+i), select the security tab.
The other person who mentioned an SSL error said chrome said untrusted authority. It's a cloudflare-issued cert, dated Tuesday 00:00, so there shouldn't be any issues unless you've disabled the Baltimore Cybertrust root which backs cloudflare's intermediate cert. Or unless there was a transient error with the cert cloudflare was serving. Like maybe they were serving a bad cert, but only at one of their POPs? While theoretically possible, it doesn't make sense that they'd have any untrusted certs around anywhere.
depth=2 C = IE, O = Baltimore, OU = CyberTrust, CN = Baltimore CyberTrust Root verify return:1
depth=1 C = US, ST = CA, L = San Francisco, O = "CloudFlare, Inc.", CN = CloudFlare Inc ECC CA-2 verify return:1