A Critique Of Lavabit by Moxie Marlinspike

Discussion in 'privacy technology' started by TheWindBringeth, Nov 5, 2013.

Thread Status:
Not open for further replies.
  1. S.B.

    S.B. Registered Member

    Joined:
    Jan 20, 2003
    Posts:
    150
    Despite what you wish to "pretend", this is what it is. Levison and Lavabit made claims of confidentiality and kept those claims. Levison's actions ensured that his "can't read" claims were kept.

    Hypothetical and speculative scenarios are perfectly fine and can be beneficial in proper circumstances. But this is a real situation, a real company and a real person. It's not hypothetical and it's not "pretend".

    __
     
    Last edited: Nov 10, 2013
  2. cb474

    cb474 Registered Member

    Joined:
    May 15, 2012
    Posts:
    351
    Yeah, I'm really on S.B.'s page pretty much here. If you've read any of my posts above, the problem with Marlinspike's critique is that the conceptual question of how a system could be technically designed is not as separable from the pratical real world situation of those systems being implimented in the real world by people, as Marlinspike would like to pretend. What an administrator can or cannot do technically is largely dependent on what they are or are not willing to do, regardless of the hypothetical possibilities.

    In addition, Marlinspike does seem to have misunderstood even the technical side of Lavabit. In Levinson's reponse, assuming I'm understanding all the details correctly, he explains that he really could not technically access his users stored emails, without their passwords. If he had modified the system in the way the government demanded, he could have accessed any new incoming or outgoing emails. But the stored, encrypted emails, really were inaccessible to him (and have nothing to do with the showdown with the government over the SSL keys). Of course, that's assuming that the Lavabit system actually did what Levinson said it does. But that problem is also true for any other method of encrypting email communications and there is no magical technical way around adminstrators and coders being people you have to ultimately trust, despite Marlinspike's suggestions to the contrary.

    At the end of the day, the battle for security and privacy doesn't just require technical solutions, it requires people and communities that you can trust. If you assume that every single other person and entity in the world is an adversary or potential adversary, then unless you're writing the code and building the hardware yourself, you've already lost the game. This is why people like Levinson and his ongoing court case are far more important than potshots from the peanut gallery, by Marlinspike, about a defunct system, that never claimed to be a substitute for fully encrypted PGP email or something like that. Levinson's system basically did what he said it did. If you read all the information on his website (of which there was a great deal and which I did years ago), I don't think there have been any suprises after that fact about what it was.

    And if you communicated directly with Levinson, as I did several years ago, he was very upfront about the advantages and potential risks of his system. The only thing he didn't get right, which he freely admits, is that he did not anticipate just how aggressive the government would be in going after his SSL keys with a secret court order.
     
    Last edited: Nov 10, 2013
  3. S.B.

    S.B. Registered Member

    Joined:
    Jan 20, 2003
    Posts:
    150
    I agree, and believe it should be obvious, that privacy and security require trust and trustworthiness.

    TrueCrypt documentation, and virtually all security documentation, make the explicit point that absolute security is simply not possible if any third parties are allowed access to one's system. It should be obvious that the same rule holds for a person's data; in particular, absolute security is not possible for that data if a third party, or a system not controlled by the data owner is allowed access to the data. It should be obvious that all internet transactions involve systems not controlled by the data owner.

    It is an utter illusion to assert that our data can be absolutely safe once we allow it to move outside of our own control.

    Without trust and trustworthiness, we are left with the stark choice of (i) communicating with no one, or (ii) resigning ourselves to the outcome that every communication we make will be archived somewhere and sooner or later will be made available to numerous other persons without our consent.

    __
     
  4. Rmus

    Rmus Exploit Analyst

    Joined:
    Mar 16, 2005
    Posts:
    4,020
    Location:
    California
    This statement could have been written 2000+ years ago!

    In the days of ancient Rome, couriers were used to relay messages back and forth between officials. Reading about espionage in Rome, we learn that infiltration into personal quarters was common, so that even a courier might turn out not be trusted.

    To use your observation, giving the message to a courier allowed it to move outside the person's own control.

    68 years ago in 1945, the The Armed Forces Security Agency and its successor NSA began the covert program (called Shamrock) which gave them access to the main telegraph agencies so as get copies of all incoming and outgoing telegrams. By some accounts, "At the height of Project SHAMROCK, 150,000 messages a month were printed and analyzed by NSA personnel." (from Wikipedia).

    Once you left the telegraph office, your message (telegram) was outside of your own control.

    So, nothing has really changed -- just the technology by which we communicate. I suppose it will always be a cat-and-mouse game: as new security measures are devised to keep our emails private, a new way to bypass/infiltrate will emerge.

    ----
    rich
     
  5. cb474

    cb474 Registered Member

    Joined:
    May 15, 2012
    Posts:
    351
    Rmus,

    I think in principle you're right. Nothing has really changed, it's just different technologies and different versions of similar problems.

    The irony is, because the law has been well established with regard to telegraph communications and by extension telephone communications, as well as with regular postal communications, those systems are in many ways more trustworthy and more private, despite being technologically vastly inferior.

    Obviously the technology for listening to someone's phone call and even more for opening someone's mail is trivial. And yet because there are strong legal precedents, the NSA cannot just collect and archive the content of every phone call and piece of mail, the way they can with internet based electronic communications, like email. Legally, I believe, when your email resides on someone elses server, it doesn't even belong to you after a period of six months. Legally, Google can just read your email, for marketing purposes.

    And yet, depsite the collection of phone metadata, there has been no evidence yet, that the NSA is archiving the content of all phone calls. And it is very restricted the ability of the government to open regular mail. But apparently the NSA intends (in Utah) to track and store all interent traffic.

    So here is a perfect example of how it is the law and the trustworthiness of systems that makes them private, despite being vastly inferior technologies, while the more sophisticated technologies, because of the lack of legal precedents, are almost a complete free for all. And this is why Levinson's stand and his legal case are so important (and I've seen legal scholars saying as much, that this case may well turn out to set the legal precedent about internet privacy for our time).

    I'm not saying, by the way, that there aren't lots of potential insecurities with phone calls and mail. Just trying to point out how technology alone is not the answer. Even crude technology can be better, when they have legal and social systems protecting them.
     
  6. TheWindBringeth

    TheWindBringeth Registered Member

    Joined:
    Feb 29, 2012
    Posts:
    2,171
    Marlinspike's commentary was fine. This "at some point you'll run into the trust problem unless you create everything yourself" point you keep bringing up has some merit but it isn't useful on its own. The specific context will determine the degree to which it applies. Consider the difference between:

    Scenario1: Uploading your plaintext files to an online storage provider that claims to encrypt them using the plaintext login password that you gave to them at signup and that you pass to them each time you use the service. Here, users (and researchers those users might rely upon for information) lack visibility. They can't tell what software is actually running on the server, how it is configured, whether it has actually encrypted the files as represented, etc. Here, users are fully vulnerable to the trust problem.

    Scenario2: Using an encryption program running on your own machine to encrypt your plaintext files (password A) and uploading the encrypted archive to a online storage provider (password B). Here, users (and researches) have some to possibly full visibility into the critical encryption/upload components. They can identify what specific software is running at any given time, and how it is configured. They can try to find the open source code for that software, check it out, and verify builds match. They can run hash checks to see if it is something others have been running without issue. They can perform AV scans. They can use HIPS and software firewalls to constrain the software to protect against unexpected behavior. They can examine the encrypted files. They can monitor their network traffic to verify what is/isn't being uploaded to servers. Here, users are far less vulnerable to the trust problem.

    That is not evident from his commentary. I think some have misunderstood what he was, and wasn't, saying.

    Passwords which he received at signup and again every time those users authenticated remember...

    He could have accessed incoming/outgoing emails by capturing network traffic and where necessary decrypting it using his server's SSL keys. No modification required. I'm not sure he could have decrypted all of it though. Edit2: Rereading his Ars Technica piece, I just noticed something I didn't recall when making the previous remark. Namely: "...I could not access or capture any of the plaintext e-mail content and surrender it because the only place user e-mails were available in their plaintext form was in memory or inside the SSL tunnel while traveling down the wire.". Perhaps stack changes, cipher suites, a soldered network connection, whatever combined to make sniffing not possible without "modification".

    Stored encrypted emails *were* technically accessible to him while the system was operating and users were authenticating. Accessibility only becomes a question when users are prevented from, or just stop, attempting to use the system.

    I don't know how he was hashing passwords for storage and at what rate he could try guessing a specific user's password and access stored encrypted emails that way. It might not have been impractical for him to try, say, top N000 passwords against a specific account. Hopefully it would be impractical for him to try that across his many user accounts. On the other hand, I would expect the government could have requested and received the encrypted emails for the account they were interested in, along with that user's encrypted private key, along with that user's saved hashed password, along with that user's hashing details, and then gone on to use more advanced equipment to guess the password and decrypt encrypted files.

    This actually does relate to the government requesting and receiving the server SSL keys. If the government captured traffic and saved it for later decryption attempts, it could decrypt at least some of that. Exposing emails and passwords going back to StartOfCaptureDate. Theoretically, the server might be storing emails going back further than StartOfCaptureDate. So there is a "get SSL keys... decrypt captured traffic... acquire some emails and the plaintext password... ask for encrypted emails and encrypted private key, or ask operator to... use plaintext password to decrypt even older emails" scenario.

    Marlinspike made no suggestions to the contrary, at least not in that blog post. He simply pointed out technical and representation problems that are very important for email system designers, operators, and users to keep in mind going forward.
     
    Last edited: Nov 12, 2013
  7. Rmus

    Rmus Exploit Analyst

    Joined:
    Mar 16, 2005
    Posts:
    4,020
    Location:
    California
    No one is forced to use Google. Anyone can set up a domain with your own email accounts.


    ----
    rich
     
  8. S.B.

    S.B. Registered Member

    Joined:
    Jan 20, 2003
    Posts:
    150
    @thewindbringith,

    You continue to speculate as to how you claim you believe Lavabit was set up. You give absolutely no substantiation of anything that you claim. Without proof and documentation your claims and speculations are nothing more than words brought by the wind. Your arguments prove nothing.

    On the other hand the government found it necessary to try to force Lavabit to actually change the structure of Lavabit including access procedures for Lavabit, so that the government could get the info you claim could have been easily accessed. It is quite obvious that the info could not be readily accessed without changing the actual structure of Lavabit.

    I am fully confident that Ladar Levison, founder of Lavabit, has a factually accurate understanding of how Lavabit was structured. He stands behind his claims with facts, and has kept his word at substantial personal cost. I trust his honesty and accuracy. He has earned that trust. In sum, there are lots of reasons to trust Levison's version of the facts.

    Your bare arguments on how you think Lavabit could have been accessed, changed, or whatever; are simply arguments. Your arguments aren't consistent with public facts that the government sought to impose changes on Lavabit to get information you claim was readily available.

    At any rate it is up to you to prove your claims.

    __
     
  9. TheWindBringeth

    TheWindBringeth Registered Member

    Joined:
    Feb 29, 2012
    Posts:
    2,171
    They are what I believe to be true, based on various things I have read and heard him say in interviews, based on mentally thinking through things with help from my background in software engineering and networking. That doesn't mean I'm not overlooking something and/or I'm not incorrect about something. If someone ever thinks so, please feel free to make a *meaningful* *technical* comment. Point out what, specifically, you disagree with and why and lets see if we can improve upon the discussion and understanding :)

    I don't think they are inconsistent with the publicly known facts or I wouldn't have said them. If the objective was to (be able to) target a *specific* account in a *fully reliable* way and that specific functionality didn't already exist, then I think some modification to the software would be the appropriate approach.
     
  10. S.B.

    S.B. Registered Member

    Joined:
    Jan 20, 2003
    Posts:
    150
    "Various things" you claim to have read and heard; (you cite absolutely nothing) and "mentally thinking through..." (aka, speculation).

    This is ridiculous. Lavabit was a complete and working service. It wasn't defined by "various things"; but rather by all of its software and parts. You don't get to select "various things" that you pick and choose, and then combine that with your speculation in this situation. Lavabit was a real, commercial service that existed for many years. The founder who does know the actual real system, and who is credible and trustworthy, stated that Marlinspike got his facts wrong.

    What you have is your own "pretend" version of a "Lavabit" you have defined for the sake of argument. You don't back up your claims with bothersome, time consuming, real, detailed, and complete research. Marlinspike, like you, apparently didn't bother spending his time to get the facts straight either.

    But you don't stop there. Then you add more speculation, again with absolutely no factual citation or basis, (If the objective was to (be able to) target a *specific* account in a *fully reliable* way and that specific functionality didn't already exist...) to create your subjective explanation of what the government did (since the actual and obvious "can't read" explanation doesn't fit with your fictional Lavabit).

    I'm not going to waste further time on your fiction.

    __
     
    Last edited: Nov 12, 2013
  11. cb474

    cb474 Registered Member

    Joined:
    May 15, 2012
    Posts:
    351
    I'm not sure in what sense you think Marlinspike's commentary was fine. It was fine, as I have repeatedly acknowledged, insofar as he makes a legitimate conceptual distinction between "can't read" and "won't read" technologies. It was not fine insofar as that distinction is meaningfully practicable in the real world. Marlinspike's commentary was also not fine insofar as he simply misunderstood some of the technical details of how Lavabit worked, regarding the encryption of messages stored on Lavabit's servers.

    I don't think you've really understood or read closely my posts above, regarding my "eventually you'll run into the trust problem somewhere" point. I specified that I was taking the point to an extreme to make a point. And I acknowledged repeatedly that that nature and justificaitons for trusting a system vary depending on the system. So your "the specific context will determine the degree to which it applies" point is just repeating what I already said myself about my own point. Some systems are more trustworthy than others. Some communities like open source are more trustworthy than others. The point at which the trust issue comes up will vary. So I don't disagree with you, but I already said that myself above several times.

    I do think people have a tendency to come up with technical ways to solve the trust issue, by just pushing it back to another level that they're not acknowledge.

    So in your two scenarios, first you outline a system in which one is entirely dependent on trusting the administrator of a cloud storage system to encrypt your files as they claim they will. Obviously that's placing a lot of faith in one person or worse, in a business with employees who come and go and who must be vetted, with all the potential pitfuls that entails.

    In the second scenario, you obviate the problem of trusting the administrator, by encrypting the file first on your own system with open source software. But now you are essentially placing your trust entirely in that piece of encryption software and the (open source) community that has supposedly verified the code. Is scenario two better in practice? Yes, in principle there are a lot of reasons to trust that system more (as, again, I already repeatedly pointed out myself). But unless you've verified the code yourself, essentially you are entirely placing your faith in unknown coders and the principle of open source. There are reasons for that, but it really is a pretty big act of faith in itself. Less of an act of faith than trusting a single unkown administrator of a single system? Definitely. But nonetheless it is no small act of faith.

    I think people get all caught up in the intricacies of the technology, of hashing and traffic monitoring and firewalls, all the things you mention, and more, and it blinds them to the real people who created all of these technologies, people you don't know, and to the community of people you don't know (and who don't know each other), who supposedly vetted the code (and who, even assuming they're trustworhty, are also fallible and in the real world often don't catch bugs, even for years). There are always people in the picture, providing the service or code, and basically we're all just trusting them, for one reason or another. Better reasons, worse reasons, but in all cases the element of trust is large, not small.
     
  12. lotuseclat79

    lotuseclat79 Registered Member

    Joined:
    Jun 16, 2005
    Posts:
    5,390
  13. TheWindBringeth

    TheWindBringeth Registered Member

    Joined:
    Feb 29, 2012
    Posts:
    2,171
    That can be debated, it wasn't a subject he commented on, and we don't know what his thoughts are on that subject. A related but other topic, you might say, and thus not a "problem with Marlinspike's critique" IMO.

    This again? The closest I've seen someone come to supporting this would be Mr. Levison's "Marlinspike is assuming..." and "Marlinspike claims that..." paragraphs at http://arstechnica.com/security/2013/11/op-ed-lavabits-founder-responds-to-cryptographers-criticism/, but neither of Mr. Levison's responses established that Marlinspike misunderstood something (a possibility we can't rule out, of course). The part that really matters, though, is that the responses didn't neutralized the points Marlinspike was making. User's had nothing more than a promise that data was being protected at rest and even if things were encrypted as described it was rather obviously, I think, within Mr. Levison's power to [through modifications] decrypt [permanently] their stored messages when they authenticated and passed their passwords to him. From that point of view, "The cryptography was nothing more than a lot of overhead and some shorthand for a promise not to peek." applies. Marlinspike didn't actually say "if an attacker gained access to a Lavabit server, they would be able to get users' e-mails in their unencrypted form by extracting the data from memory", but that is certainly a type of approach that would fall under his "An attacker who can get access to the server." scenario. It is interesting to know that Mr. Levison tried to address the in-memory issue, and he may have taken other precautions, but I think Marlinspike's point still stands. Given that the system, at least when operating, is exposed to what it needs to decrypt stored emails (not to mention access emails in flight) we would consider it to have a (*potential*, I would have said) vulnerability to an attacker who gains access to it.

    I recalled you having said something along the same lines, but included that anyway as a way to lead up to the examples... I wanted to illustrate how stark the differences can be. I read the rest of your message but I don't know what more to say on the subject. You either endeavor to mitigate the trust problem through checks/balances/visibility/monitoring or you pray.
     
  14. S.B.

    S.B. Registered Member

    Joined:
    Jan 20, 2003
    Posts:
    150
    @TheWindBringeth

    It has already been pointed out to you that any secure software or internet service can be made insecure via modification; and that "can't read" isn't the same thing as "can't be modified". Marlinspike's original contention was wrong.

    Time to move on.

    __
     
  15. TheWindBringeth

    TheWindBringeth Registered Member

    Joined:
    Feb 29, 2012
    Posts:
    2,171
    I know, someone who was playing "what would we say if we were defending Lavabit in court" tried that on me earlier in the thread. Given that this is a security/privacy forum where failure to recognize such weasel wording and hand waving can get large numbers of people burned, I hope that person stops it. Seriously.
     
    Last edited: Nov 13, 2013
  16. cb474

    cb474 Registered Member

    Joined:
    May 15, 2012
    Posts:
    351
    I don't think there is any (reasonable) debate that "can't read" is only theoretically practible in the real word if you write or verify the code yourself. Otherwise, you're just trusting someone else or some community, as I've repeatedly said. So yes, Marlinspike did not comment on the point I'm making. But what he did do is make an argument about "can't read" vs "won't read" as if it was a meaningful distinction. But given that it is a distinction that is only theoretical and not applicable in the real world, Marlinspike's whole point becomes irrelevant. As S.B. says, "can't read" really amounts to "won't modify," at which point in reality (which is the domain in which people actually use email) "can't read" is not in practice fundamentally different from "won't read." So it doesn't matter if Marlinspike commented on the point I've been making. His distinction is based an a assumption about what is possible in actual reality that is wrong. And that means my point speaks to the heart of Marlinspike's argument, it's not just some other side issue.

    So when Levinson says something about his system it's just an assertion? When Marlinspike or you say something about his system it's a fact? There's no point discussing the details of how Lavabit actually worked, if one approaches the debate this way.

    Anyway, when you say users of Lavabit had "nothing more than a promise" that their data was being protected, it really begs the question of my whole point which is that this is true of every possible email system that has been discussed here (again, unless you wrote it yourself, etc.). So I don't know why this is such an egregious accusation with Levinson and deemed irrelevant with other systems. It just seems like an odd bias against Levinson.

    The truth is any webmail system could have the password captured by the administrator. This is equally true of Countermail, that people in this forum respect, and no one is attacking along these lines. Countermail could change the java applet that loads when you enter the webmail system to capture people's passwords and no one would know. There is absolutely no way around this element of trust with a webmail system.

    The only way around it is to encrypt emails oneself, before sending them. In which case you're trusting the people who coded and vetted the encryption software. Etc., I wont' repeat myself.

    Marlinspike has essentially invented a distinction without a real difference in the real world where people actually do things.

    I guess this is where we disagree (although maybe we don't as much as it seems, I don't know). You seem to think that the trust problem can be mitigated to a degree that makes it much less significant than with a system like Lavabit. I don't think the trust problem can be mitigated. You can have systems for which there a much better reasons to trust them, than others. So the methods of checks, etc., that you mention, using open source software and doing the encryption onself, do rely on a system and (importantly) a community that has better reasons for trusting it, than a system created and maintained by just a single administrator. But trust hasn't gone away or been diminished as an issue, there are just better reasons to trust one system over the other.

    On the other hand, the idea that superior technological solutions get rid of the trust issue or limit it in highly significant ways, I think is bogus. There is a huge amount of trust required by either system. In fact, the advantage of one system over the other is more about how one establishes trust, than about the differences of the technology.

    This is why a technology as crude as regular postal mail is potentially more trustworthy than email, even encrypted email. Because of laws and social norms and politics, I have pretty good faith that my regular mail is not been opened, ever, without a warrant. And it is almost certainly not being opened, copied, and archived in perpetuity, on a mass scale of millions of people without a warrant. And yet, the technologically superior systems of email are being archived and read all the time. Even encrypted communication is being especially trageted and stored, en masse, for a future day when it might be possible to unencrypt it. There's no evidence that the most sophisticated encrypted communications have lead in general to more privacy and security. In fact, technology and in particular electronic communications, as a whole, seem to be leading us in the opposite direction, toward less privacy and security.

    What differentiates the systems is the laws, norms, and politics that apply to them. That's why Levinson's stand against the secret warrant and his court case, which may turn out to establish an important legal precedent defining the whole future of electronic communication, are far more important than Marlinspike's hypothetical arguments with no real world applicability. That is also why communities like open source are important, because they are mechanisms for establishing trust, not because they produce intrincisally superior technology, to say nothing of idealized "can't read" systems that aren't actually possible in practice.

    I guess, in short, I would say that I think there is an intrinsic, ever evolving, mutually reinforcing, and necessary relationship between modes of establishing trust and technology (as far as security and privacy are concerned), whereas I have the impression you think sophisticated technological solutions can largely "mitigate" the problem of trust (and honestly I think when people say "mitigate" in this way, they have mostly fooled themselves into thinking they have actually removed the problem of trust).
     
    Last edited: Nov 13, 2013
  17. S.B.

    S.B. Registered Member

    Joined:
    Jan 20, 2003
    Posts:
    150

    @TheWindBringeth

    The only poster in this thread who has tried to "weasel word" what they originally said is you. As Ladar Levison pointed out, Marlinspike said:
    "The ciphertext, key, and password are all stored on the [Lavabit] server..."

    Marlinspike was wrong. This is confirmed in the US Attorney's Brief, just filed in the Fourth Circuit Court of Appeals, found in the Wired link, a few posts prior to your most recent.

    By the way, Marlinspike also said:
    There is no way to ever prove or disprove whether any encryption was ever happening [on the Lavabit server] at all, and whether it was or not makes little difference.

    Marlinspike was obviously wrong in making this ridiculous statement, as is also confirmed in the US Government Brief.

    It is further confirmed in that same brief that the Government sought Levinson's SSL key because they otherwise could not get any email info from the Lavabit server (a fact that you denied just a few posts previously).

    Marlinspike was wrong. And you were wrong.

    Lavabit and Levison's "can't read" claims were accurate. Levison is taking a courageous stand to preserve Lavabit's "can't read" promise that has cost him a business he spent 10 years building. He is also subject to large monetary sanctions should he ultimately lose this case. He doesn't need further inaccurate attacks from you and Marlinspike.

    __
     
    Last edited: Nov 13, 2013
  18. TheWindBringeth

    TheWindBringeth Registered Member

    Joined:
    Feb 29, 2012
    Posts:
    2,171
    Marlinspike's full sentence was: "The ciphertext, key, and password are all stored on the server using a mechanism that is solely within the server’s control and which the client has no ability to verify". I noticed Mr. Levison did not dispute it. It would of course be somewhat difficult for server side decryption to occur if the pieces necessary to the decryption process weren't on the system when it needs to happen.

    I read it, and I disagree.

    LOL. Taken together with his preceding sentence, it was perfectly clear that he was referring to the encrypted storage and the ability of *clients* to tell whether emails were actually stored on the system in an encrypted form.

    In regards to the pen/trap order "to (1) capture all "non-content" dialing, routing, addressing, and signaling information sent to or from a specific account, and (2) record the date and time of the initiation and receipt of such transmissions, to record the duration of the transmissions, and record user log-in data from that specific account, all for a period of sixty days":

    "On July 13,2013, Mr. Levison sent an email to the prosecutors stating, in part: In light of the conference call on July 10th and after subsequently reviewing the requirements of the June 28th order I now believe it would be possible to capture the required data ourselves and provide it to the FBI. Specifically the information we'd collect is the login and subsequent logout date and time, the IP address used to connect to the subject email account and the following non-content headers (if present) from any future emails sent or received using the subject account. The headers I currently plan to collect are: To, Cc, From, Date, Reply-To, Sender, Received, Return-Path, Apparently-To and Alternate-Recipient. Note that additional header fields could be captured if provided in advance of my implementation effort.$2,000 in compensation would be required to cover the cost of the development time and equipment necessary to implement my solution. The data would then be collected manually and provided at the conclusion of the 60 day period required by the Order. I may be able to provide the collected data intermittently during the collection period but only as my schedule allows. If the FBI would like to receive the collected information more frequently I would require an additional $1,500 in compensation. The additional money would be needed to cover the costs associated with automating the log collection from different servers and uploading it to an FBI server via "scp" on a daily basis. The money would also cover the cost of adding the process to our automated monitoring system so that I would notified [sic] automatically if any problems appeared."

    Those familiar with email message formats will likely realize that if it was possible to grab those headers he could have handed over full emails.

    Direct link for those who are interested...
    Lavabit Government Reply Brief
    http://s3.documentcloud.org/documents/825107/lavabit-government-reply-brief.pdf
     
  19. S.B.

    S.B. Registered Member

    Joined:
    Jan 20, 2003
    Posts:
    150
    @TheWindBringeth

    More hot air is what TheWindBringeth.

    Marlinspike made numerous claims that were wrong and misleading. You now take the position that Mardlinspike meant something other than what he said. Ridiculous, as usual.

    Marlinspike attempted to discredit Levison and Lavabit by claiming that it couldn't be proven whether Lavabit ever even encrypted anything - a cheap shot now proven wrong. Information on the Lavabit server was indeed encrypted as the govt brief makes clear. That is now proven. Marlinspike also said that whether the info "was [encrypted] or not makes little difference" - another cheap shot now proven wrong, since as should be obvious even to you, if the info had not been encrypted, the government would now be in possession of same.

    You have made numerous claims that were wrong. You now add more. The portion of the brief that you quote has to do with Levison offering to modify the Lavabit set up, to capture and store data passing through the SSL tunnel at a future time. The Lavabit server was not set up to capture and store client info present in the SSL tunnel. Capturing that info from the SSL tunnel and storing same, was necessary, as explained in the brief, to allow access to encrypted info on the server.

    Marlinspike incorrectly claimed that the info was already present on the Lavabit server to support his incorrect claim that "can't read" was untrue. (According to Marlinspike, "The ciphertext, key, and password are all stored on the [Lavabit] server...") Marlinspike's claims are now proven untrue.

    Similarly Lavabit's "can't read" claim was true since modification of the Lavabit service and the Lavabit server was necessary to allow access to email information. The encrypted emails on the Lavabit server cannot be read by anyone, including the government, even today, since Levison shut down Lavabit and prevented the government from obtaining future information passing through the SSL tunnel.

    "Can't read" doesn't mean "Can't modify". Over and over it has been pointed out to you that any software or internet service can be modified. Yet you are apparently unable to face facts, and admit that you and Marlinspike were wrong.

    If the Lavabit server had been constructed so that administrators could read emails stored on the server, as claimed by Marlinspike, then the government would not have needed Levison's SSL key to access information passing through the SSL tunnel in the future, in order to access those emails. You can twist (or to use your words, "weasel word") the facts as much as you wish, but the Lavabit server was clearly set up to prevent anyone, including administrators, from reading the encrypted emails stored on the servers. Even the government was unable to access those emails.

    As to the software systems Marlinspike was trying to promote, I wouldn't touch them with a ten foot pole, much less entrust any of my data to them, in view of Marlinspike's lack of care and accuracy.

    __
     
    Last edited: Nov 14, 2013
  20. TheWindBringeth

    TheWindBringeth Registered Member

    Joined:
    Feb 29, 2012
    Posts:
    2,171
    I take the position that these two sentences:

    "The ciphertext, key, and password are all stored on the server using a mechanism that is solely within the server’s control and which the client has no ability to verify. There is no way to ever prove or disprove whether any encryption was ever happening at all, and whether it was or not makes little difference."

    were meant to be interpreted *together*. Read them together. He is saying the client/user has no way to see/verify how the ciphertext, keys, and password are being handled on the server... therefore... there is no way (for the client) to ever be sure the encryption was done correctly. From a *security* POV we want the client/user to be able to tell, whenever it wants, if the encryption is actually happening the way it should be. With a Lavabit type architecture, it can't. No matter who is running it.

    That was his pen/trap offer, and note "Lavabit also argues that the burdens imposed on it were unreasonable because Lavabit offered to implement the pen/trap itself, with its own software". So we'd consider it software changes to his system done in a way that those bits of information would be logged when the activity is associated with the subject account.

    That is what he asserted, which I think means he couldn't turn on debug output or run a local sniffer program to capture traffic and log it to a special file.

    Context first. Initially, it seems like the plan was to install a pen/trap that would only target future metadata lets say. Their device sounded flexible, and I think at one point they talked about him providing it with a live feed of some sort. However, he ended up offering to implement it the way he described. They didn't like his proposal and/or were tired of delays and/or simply wanted SSL keys. So "On July 16,2013, the district judge issued a search warrant to Lavabit for (1) "[a]ll information necessary to decrypt communications sent to or from the [target email account], including encryption keys and SSL keys" and (2) "[a]ll information necessary to decrypt data stored in or otherwise associated" with the targeted Lavabit account.". Note: I think this was the first explicit targeting of not only SSL keys but also stored data. On August 1, 2013 they installed the pen/trap device and it started gathering $whatever from the network but they didn't have the server SSL key(s) yet.

    They either had to have the system send them the data they wanted or capture traffic and decrypt the SSL via his server key. Due to circumstances and/or desire they ended up going the later way.

    This has to do with encrypted storage obviously. The user's password would be permanently stored on the system in some hashed form for authentication purposes. Ciphertext (encrypted emails) were stored on the system. It seems they were decrypted with the user's private key, which was stored on the system in encrypted form. To decrypt it, the user's password was needed. The user passed their password to the server when they authenticated to do their email. So yes, it seems all three of those things *are* "stored" on the system. However, the plaintext password should only be stored in memory and it should come and go as the user accesses email.

    We could say that Marlinspike's "can't read" claim is true from his POV and Lavabit's "can't read" claim is true from its POV. They are literally using different definitions of "can't read".

    From the security POV, it's only a question of whether something is possible and perhaps practical. It doesn't matter if it requires a modification or not.

    From the "legal cover" POV, it's only a question of whether you can claim the system doesn't support something. You'd want to be able to say that it requires modification. Note, however, that this claim may not make much of a difference to some legal authorities.

    Basically, but that assumes the government doesn't acquire access to them and have a means of decrypting some.

    Edit2: Later it came to me that my "Basically..." reply immediately above was based on my own assumption that encryption was actually being done, done in a way that has been described, and nothing else was going on that could put the emails at risk now. Particularly since Marlinspike points out to us how those are things we can't be sure of given the architecture (not without actually inspecting the system for ourselves), I thought it best to add this Edit2 and point this out. I don't think it worth bumping the thread for this.
     
    Last edited: Nov 15, 2013
  21. Countermail

    Countermail Registered Member

    Joined:
    Aug 7, 2009
    Posts:
    169
    Location:
    Sweden
    Sorry but that's not really true, we have two solutions for paranoid users.

    1. "Offline Login". Cross platform for Firefox and Safari, applet is included, never downloaded. https://countermail.com/data/offline_login.zip

    2. CounterMailPortable. For Windows. Applet is included, never downloaded.
    https://countermail.com/?p=portable

    Edit: If we put any backdoor in our applet, and it became publically known, our company would go bankcrupt. That's one benefit with being small. We can't afford such thing. While the other giants like Gmail,Hotmail, Apple can get away with it, because they have so many customers.

    Edit2: Our government have requested us to save passwords, but of course we refused, there are no laws in Sweden that can force us to do that. They accepted that.
     
    Last edited: Nov 14, 2013
  22. S.B.

    S.B. Registered Member

    Joined:
    Jan 20, 2003
    Posts:
    150
    Marlinspike claimed that it could not be proven whether Lavabit ever encrypted any data and that whether Lavabit did or didn't encrypt data would make little difference. Marlinspike was wrong on both counts. The data was encrypted. And despite Marlinspike's claim, the encryption made a huge difference since encryption prevented the government from accessing the data.

    Moreover, despite your unsubstantiated claims and word twisting, Marlinspike was wrong when he stated ("The ciphertext, key, and password are all stored on the [Lavabit] server..."). Levison stated that this was wrong. The key and password were temporarily accessed by secure memory but they were not stored on the server. The government sought the SSL key for the very reason that keys and passwords were not stored on the server.

    Marlinspike got the facts wrong. You have, and continue, to make numerous untrue claims that you cannot support no matter how you try to twist words and the facts. Lavabit's statement that their Administrators "can't read" the emails has been proven true.

    Your arguments cannot change the facts. I'll leave it at that.

    __
     
    Last edited: Nov 14, 2013
  23. cb474

    cb474 Registered Member

    Joined:
    May 15, 2012
    Posts:
    351
    With all due respect, I don't think that really gets one around the problem I was discussing. And I really do mean to convey all due respect, because I think that Countermail is a great service and I really appreciate you willingness to hang out in this forum and answer people's questions.

    Still, if I use the offline login client either independently or with CounterMailPortable, this is still software provided by Countermail that I just download from your website. I have to trust that there is no backdoor in it. So the element of trust remains, it has just been pushed from trusting the java applet that loads when one logs into the webmail client, to trusting the software I downloaded from Countermail that loads the Countermail login client locally instead of from the website (although that does increase the security in several ways and decrease the opportunities for Countermail to modify the login client, were it so inclined).

    Of course, I understand (and believe) that Countermail does not do such things and that if such an action were discovered it would ruin your business, so you have a huge motivation not to do something like this. And from everything I've learned about Countermail, I believe that as a service it is committed to its users privacy and creating a system where no one but the user has access to the content of their emails.

    Nonetheless this does not entirely eliminate the element of trust I've been discussing. It's just that I think there is good reason to trust Countermail (because of the information on the website, because of the apparent earnestness of those who run Countermail and willingness to answer questions in detail, because of the apparent technical expertise of those who run Countermail, because Countermail is in Sweden, and because other knowledgeable people in this forum and elsewhere respect Countermail).

    In any case, I did not mean in anyway to say anything negative about Countermail. I was trying to make a point about how we all trust on some level the systems and software we use, inevitably, and that it is how this trust is established that is as important as the technical capacities of the systems themselves. I brought up Countermail only because it is a system that I think people in this forum do respect and trust. And I really don't understand why Levinson, who has demonstrated so much respectability in how he has dealt with the U.S. government court orders, has been singled out for a problem that all providers of email services and secure communication software face (i.e. the inevitability of trusting them). Although I also freely acknowledge that the system Countermail has created goes much further, to ensure the security and privacy of its users, than what Levinson originally did with Lavabit (though Lavabit was also a good system, for what it was, and didn't claim to be anything more).
     
    Last edited: Nov 14, 2013
  24. PaulyDefran

    PaulyDefran Registered Member

    Joined:
    Dec 1, 2011
    Posts:
    1,163
    CM, thanks for those links...I really need to stay up to date with your news feed :D
     
  25. cb474

    cb474 Registered Member

    Joined:
    May 15, 2012
    Posts:
    351
    Yes, just to be clear, the offline login client is a great idea and I'm glad Countermail provides it. I don't mean to belittle in any way the usefulness of this idea. It's just another example of why Countermail provides a very good service that tries to think through all the angles.
     
Thread Status:
Not open for further replies.
  1. This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.