How can PrivateSky not see your data?
security.stackexchange.com
security.stackexchange.com
So, rather than allay fears about his service, I'm left feeling more skeptical about their claims.
I would love hear from people more versed in cryptographic key exchange protocols as to the basis for their claims.
And, seriously, a Michael Scott protocol?
I personally wasn't familiar with D-PKGs but his response allowed me to understand what they were pretty easily.
I'd worry about the extra attack vectors because of that - man in the middle, snooping browser extensions, etc (or even just strong-arming them into silently changing their javascript do no encryption)
To his credit, he writes about this as well:
> On a trust scale, is it better to use PGP or PrivateSky if you want to be 100% sure that no one can see your data? Answer: There is no question that [...] a system such as PGP is better [...]
> There is only one problem. PGP and the current state of the art are too damn hard for the general population at large to use. [...]
I use enigmail + thunderbird, and it's pretty simple to use. It's only difficult because the tools are immature. Sending a mail and seeing a "verified from foo@bar.com", or "can only be viewed by foo@bar.com" isn't difficult to understand.
The smartphone vendors are in a unique position where they could make this happen.
The hard part has always been key management. If a user doesn't have a properly managed web of trust, they have no real assurance of privacy or authenticity.
I think the people who are actually in a position to fix this problem are the social networks. Imagine if the act of joining Facebook caused a keypair to be generated by you, and friending someone brought their key into your web of trust with some sensible defaults.
Unfortunately Facebook has no incentive to build such a thing. But maybe something third party can leverage all those social connections to help users manage keys in a more natural way.
Can you elaborate?
There isn't anything inherently browser based about this.
I'm not a huge fan of browser based security (I know just enough appsec to be terrified).
If they had an API, it would be fun to do a secure mobile client for it (I trust iOS security way more than PC browsers..). There is less point when you have a client (just as easy to build some kind of key server with locally stored keys), but being able to send messages to future users is a nice trick.)
It looks like an interesting use of HSMs. I'm curious if they do real crypto in the HSM or just use it to protect a bootable VM. If it is just a VM, there are a lot more attacks possible.
Overall this is quite an impressive application, especially on the backend/server side. I wish more people used HSMs in a productive way (I've done some stuff with them in the past, and am working on related things now)
Nevertheless, someone asked a follow on question with these exact same points back on the thread; we have posted answers.
It also seems you are being a bit disingenuous. You've studied under Dan Boneh, the founder of our competitor. You know very well what these acronyms mean.
Also, who said this is only going to be "browser based"? Browser's are a good start though....
Yes, I have.
You would NEVER disclose your internal processes or architecture, that's nuts, it's like drawing out your whole attack surface for your adversary.
Though it might not be a bad idea, I wasn't actually intentionally suggesting that you open-source all your code and make your internal processes completely transparent. I was suggesting that you maybe add a section in your whitepaper detailing the possible attacks, and that you reconsider phrases in your marketing copy like: "Who can see your data with PrivateSky™? No one, not even us." I find it misleading.
Nevertheless, someone asked a follow on question with these exact same points back on the thread; we have posted answers.
In the stack exchange thread, you talk about what would be needed to compromise the SkyPin authentication process. But I don't see how this is sufficient. Suppose there is an XSS vulnerability on the browser-based inbox on your site. What stops an attacker from inserting a single line of Javascript that opens up a message of his choice in my inbox, decrypts the contents, and sends the contents to the attacker? Suppose that your SSL private key is compromised. What stops the attacker from eavesdropping on my connection to PrivateSky, stealing my session cookie, and using that session cookie to open up my inbox in his browser? Maybe you have some defenses against these attacks, but you don't seem to address them anywhere (at least that I can find).
It also seems you are being a bit disingenuous. You've studied under Dan Boneh, the founder of our competitor. You know very well what these acronyms mean.
The point was that there is a lot of heavy-handed crypto thrown around and not enough discussion of the actual weakest links in your system.
Also, who said this is only going to be "browser based"?
Definitely not me. The current offering is browser-based, and the currently advertised guarantee is that no one can read your data, not even your company.