Lavabit LLC - Dallas TX and Colo4, LLC - St Louis MO.
(Insert your own joke here about Americans not caring about mass surveillance...)
/*
Count down until any date script-
By JavaScript Kit (www.javascriptkit.com)
Over 200+ free scripts here!
Modified by Robert M. Kuhnhenn, D.O.
on 5/30/2006 to count down to a specific date AND time,
and on 1/10/2010 to include time zone offset.
*/
var today=new Date();
var todayy=today.getYear();
if (todayy < 1000) {
todayy+=1900; }
There's no need for this (anymore). You're already allowed to disclose (coarsely) the number of NSL you've received[1].
[1]: https://www.justice.gov/iso/opa/resources/366201412716018407...
> You can't force someone to say something in the US can you?
Unclear. The EFF believes you can't be compelled to lie, however you should consult an attorney with details of the specifics.
This always sounded fishy to me. When a NSL is served, they order you to keep silent about it, so you can't tell e.g. your own CISO. But if the CISO comes and asks, you're not ordered to lie and say you haven't received one? So if the CISO just asks you every morning, the NSL's order of keeping silent is defeated? I can't believe the courts and the executive that support NSLs in the first place would allow such a loophole.
Secondly, the FBI can serve an NSL to the CEO, a separate one to the CISO, and so on down the chain to the tech people whose job would be to fulfill the order. They can choose to serve one or some or all of these orders, and they can order some served people to cooperate and others to keep silent or lie to one another. It's not feasible to expect all of these people, some of whom are not officers of the company, to consult lawyers.
Something important to understand is that non-disclosure is not an automatic feature of the NSL, but that disclosure binds the parties to the terms in the NSL.
[1]: https://vault.fbi.gov/National%20Security%20Letters%20%28NSL...
> Secondly, the FBI can serve an NSL to the CEO, a separate one to the CISO, and so on down the chain to the tech people whose job would be to fulfill the order
Yes, they can, however that's not what happens. The general council may advise the CEO to disclose certain requirements or aspects of the NSL to the CISO or to other parties for the purposes of complying with the NSL. They will almost certainly not recommend disclosing or distributing the NSL "down the chain to the tech people".
I meant they might target the tech people directly from the start - or someone who isn't a C-level executive, anyway - if they think the CxOs would go to a lawyer and the lower level people would just comply.
The point being made upthread is that there is no black and white guidance, there is no secret NSL Guide Book for attornies.
The FBI does in fact has some guidance that your attorney will be able to locate[1]
[1]: https://vault.fbi.gov/National%20Security%20Letters%20%28NSL...
Here is how I am parsing it:
The Office of the Attorney General proposes two options:
1. Separate category reports for NSL, FISA content, and FISA non-content requests and customers affected.
2. A single report for all NSL and FISA requests, and a report for customers affected.
If you want to distinguish between the different kind of request (category 1) then you can report in blocks of 1,000, while if you don't, you can report in blocks of 250.
Maybe a heterogenous bunch if them so you'd have to crack all of them to get all messages.
You could periodically reset them in case they still get infected.
You could add a transparant proxy that specifically looks for odd, repeated requests, to detect re-infectations.
You'd set up alerts for attempts at communication/scanning from those servers, to detect virusses trying to move laterally between the different instances, and/or isolate them from eachother on the network layer.
You could have a separare hardware device that scans the memory of these servers to detect tampering.
It could also try to detect "plaintextness" and abort as soon as it detects that, so you only have the beginning of the message in memory.
This doesn't help when the ISP is recording (and it probably is), but it makes it very hard to retrieve the data from inside the email datacenter.
Yeah, well, who is your adversary?
I assume NSA and GCHQ by default just log all SMTP traffic. Especially the ones to services like these.
If your adversary is someone sniffing your unencrypted WiFi connection, they'll have your unencrypted e-mail like this one as well.
If your adversary is network and sysadmins who run your SMTP server then all bets are off. I think the danger lies, just like within Tor, that there's a mole in such a team who does harm while being undetected.
If you're protecting against the local authorities ensuring to get a remote, secure connection with a country who isn't playing along with your local authorities is key. Which is why Putin wants Russians to use local services.
Just have them rebuild themselves from ROM after each processed mail :)
There's no way to stop a user's contacts sending plaintext emails for all the ISP's/intelligence agencies to see, but you can make sure you touch them as little as possible when they do arrive (see GP) and discourage those contacts from doing it again by not delivering/returning error codes.
Unless you drop SMTP altogether. I think Riot with E2E is looking pretty good, but it's not been hardened at all.
Then don't put your users at risk by using SMTP.
>The techniques I mentioned are to reduce the risk of these (partial) plaintexts being captured, but should be paired with a refusal to deliver.
Techniques you mentioned are nothing more than pointless showmanship, which you'll cease as soon as the government asks you to.
>There's no way to stop a user's contacts sending plaintext emails for all the ISP's/intelligence agencies to see
Which is why you shouldn't put them in a situation where they will inevitably do so.
>Unless you drop SMTP altogether.
If you're going to launch a service that advertises secure communications, you have to. Otherwise you're just endangering your users, just like lavabit did.
We're not talking hypotheticals here. Lavabit already fucked over their users trying to pull silliness like this.
You can't rely on your ability to block them either, or you'll end up just like lavabit did.
They could also setup a P2P delivery & backup system so that it's not guaranteed they have the data. If all the data is encrypted, it's not really an issue to distribute everything (but then again we'd be talking AES512 or better for something crazy like that).
"We can't implement "AES 512 key size" because AES is defined for key sizes k∈{128,192,256} bits only; much like we can't make a bicycle with 3 wheels."
[0] http://crypto.stackexchange.com/questions/20253/why-we-cant-...
Otherwise you're just trusting that you've not been served backdoored JS by order of an NSL.
Also, if you have a way to break AES512 I know some people who'd pay a killing to get that information. No litterally there's people who'd kill for that.
They could encrypt with two(or more) 256bits keys, but I think just 256bits key is enough for at least next 5years.
I think also everyone is pretty sure quantum computing won't break AES, but maybe there's some weakness in the S/P boxes that quantum computers can exploit, who knows. That's the fun in crypto, you can't prove that anything other than OTP is unbreakable.
Well, depending on the theory the universe isn't even supposed to have any net sum, but regardless: even at the Landauer limit (at room temperature; it scales linearly to absolute temp) it would take an awful lot of energy to do the computation non-reversibly, about:
2**256 * 256 * 2.5 zJ
~ 8e+58 J
And any computer built so far is still far, far away from the Landauer limit.
There is also Bremermann's limit which is an intrinsic limit on the processing speed per mass. Eg. a machine that traverses a 256 bit key space in 15 years with one one bit operation per traversed key must weight at least ~1.8e+21 grams, which would be quite a chunk of machinery.
This just goes to show that brute-forcing 256 bits is simply not going to happen with any civilization that isn't able to harness the power of at least one star.
That doesn't say anything about cryptanalysis, though. I think with an algorithm like AES, which has been analysed a great many times, that it's becoming less likely that there is a cryptanalytic breakthrough. It might be the case that AES will remain secure throughout the information age.
This proof is present in Schneier's "Applied Cryptography" if someone wants source.
Maybe I'm misunderstanding something, but I don't understand how anyone could trust Lavabit to either stick around or actually be private and/or secure.