<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, Sep 18, 2015 at 6:58 AM, Edward Ned Harvey (bblisa4) <span dir="ltr"><<a href="mailto:bblisa4@nedharvey.com" target="_blank">bblisa4@nedharvey.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Everybody knows they shouldn't login to anything over http://<br>
We've all been trained to use https:// and ensure we have green checkmark security shields or whatever.<br>
Because thousands of random unknown employees maintaining the routers on the Internet could access the http traffic.<br>
<br>
When you login via HTTPS, to google, facebook, twitter, and thousands of other sites, there are still thousands of unknown employees maintaining the load balancers and web servers at the other end, who could access the traffic.<br>
<br>
It is a no-brainer. You should not send your password or encryption keys, even over https. You need to prove you know your secret without exposing it.<br>
</blockquote></div><br></div><div class="gmail_extra">So, ok, you've given me a couple assumptions: CBcrypt assumes that a provider may be organizationally good but may have malicious insiders. I think it's fair to say that you assuming that your adversary is a malicious system administrator. What are the adversary's goals? Just to get a password dump? Any other goals that you had in mind?</div><div class="gmail_extra"><br></div><div class="gmail_extra">Other thoughts: Does CBcrypt require that the client machine not be compromised? How about the confidentiality/integrity of the link when the public key component is first sent to the provider (yay MITMing with a different key)? It seems like you are putting a lot of trust into DNS, which isn't a very trustworthy service to begin with (but we all do that a lot today anyways; still worth noting)</div><div class="gmail_extra"><br></div><div class="gmail_extra">It may be worthwhile to look at how other people have written threat models for their systems and write something similar for CBcrypt. I wrote one for my Spyglass paper (not a cryptosystem but still one intending to make something more secure at the end of the day) that'll be at LISA this year, but you'll find them all over USENIX Security papers and other conferences. There are books on the subject as well, I hear <a href="http://www.amazon.com/Threat-Modeling-Designing-Adam-Shostack/dp/1118809998">http://www.amazon.com/Threat-Modeling-Designing-Adam-Shostack/dp/1118809998</a> is decent.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Papers aren't for every system IMO, but I think that having a paper that describes this rather than a video would be probably help. Writing a paper is is a lot of work, and certainly meaningful evaluation for defensive security work is difficult ("more secure" is hard to quantitatively measure today, sadly, but I know people trying to find a way!) but it would help lay out the details and help others evaluate your system in a more in depth way than "just looking at the block diagrams" -- you could even submit it to some sort of crypto conference and get some feedback that way too.</div><div class="gmail_extra"><br></div><div class="gmail_extra">-pc<br></div></div>