|
Email Comments, Questions and Miscellaneous Share your opinion of the email service you're using. Post general email questions and discussions that don't fit elsewhere. |
|
Thread Tools |
7 Mar 2015, 03:49 AM | #76 |
Senior Member
Join Date: Aug 2013
Location: Seattle
Posts: 115
|
I think there is a rather large implication that is not fully understood when removing the second password. Does this really come down to a person's comfortable level of security and privacy? Or, is keeping your account data protected with the second password "security theater"?
My understanding, please correct me: If the user retains the second password, the service provider has zero knowledge of user data stored at rest or transmitted between scryptmail.com and web browser. The exceptions are plain text emails received from external mail servers. How do those messages get encrypted into the user mailbox for zero knowledge after delivery? If the user removes the second password, the service provider must store the private decryption key somehow, thus zero knowledge is no longer true. Please explain? Perhaps both of those questions can be answered with simple data flow diagrams? A picture is worth a thousand words, right? |
7 Mar 2015, 05:13 AM | #77 |
Senior Member
Join Date: Nov 2014
Posts: 127
Representative of:
Scryptmail.com |
I wish my graphic skills as good as coding.
>If the user retains the second password, the service provider has zero knowledge of user data stored at rest or transmitted between scryptmail.com and web browser. The exceptions are plain text emails received from external mail servers. How do those messages get encrypted into the user mailbox for zero knowledge after delivery? -to best answer this question is worth to mention, that incoming emails are stored in DB in encrypted format using recipient public key. So having one or two passwords is not threat to the security of message, rather than RSA key strength. Zero knowledge is protected by utilizing 'seed message'. More detailes you can find in our blog: http://blog.scryptmail.com/2015/02/s...and-speed.html >If the user removes the second password, the service provider must store the private decryption key somehow, thus zero knowledge is no longer true. Please explain? - It's incorrect, system don't have to know your private key. What is really happened when you use two passwords: We hash first password to log user in the system - password fingerprint stored in DB. Second password(secret) have no fingerprint in system, and you have to type it to decrypt personall data after login. In case system get compromised, you can't learn anything about second password and unable to speedup brutefroce attack. On the other hand with single password, it stored in DB almost same way as described above, but the same password is used to decrypt your data. We have fingerprint of your encryption key, which potentially can leak some information and decrease an attack time. To make it harder for an attacker we derive keys for login and decrypting by using different rounds of PKCS, and even make it better, login part use dynamic rounds, that depends on your password. Which makes an attacker work much harder, because he can't use one rainbow table. Private decryption key are still derived using PKCS#5 of 4000 rounds. Details: http://blog.scryptmail.com/2015/01/s...ntication.html Ps. In my opinion, if you use strong >400 bit password, using two or one password approach will be almost identical and force attacker to look for another way to hack your email. As side effect of using single password KeePass storage won't be working, as you can't just make hash of your password anymore. We have to add feature of setting individual password for KeePass storage, which we haven't done yet. |
7 Mar 2015, 05:56 AM | #78 |
Senior Member
Join Date: Aug 2013
Location: Seattle
Posts: 115
|
Thank you, Sergei.
I see the Atom feed, but is there an email subscribe function to receive your blog updates? http://blog.scryptmail.com/ |
20 Mar 2015, 08:09 AM | #79 |
Senior Member
Join Date: Nov 2014
Posts: 127
Representative of:
Scryptmail.com |
To all our loyal users for who we built SCRYPTmail,
We just launched our Kickstarter campaign and welcome everyone to join in our effort to rise money for this project. https://www.kickstarter.com/projects...t-your-privacy We have received a great deal of positive feedback from you; however, with more people coming to us every day, we hit the point where we have to ask for your support. Now its time to upgrade our servers to make SCRYPTmail more stable and reliable. We appreciate your support and please share the link with your friends. Our next goal is to roll out virtual domain support, create smartphone apps and more! Thank you |
20 Mar 2015, 08:58 AM | #80 | |
Senior Member
Join Date: Aug 2013
Location: Seattle
Posts: 115
|
Quote:
|
|
20 Mar 2015, 07:44 PM | #81 |
Cornerstone of the Community
Join Date: Sep 2013
Posts: 536
|
Some criticism about scryptmail:
- You should create an "about" page in the kickstarter campaign, explaining who the founders are, what they do, etc. Also, I don't see a link to scryptmail.com anywhere in that page, which is very weird. - I seriously don't understand the point of limiting accounts by number of e-mails instead of size. One person can have 1000 e-mails with 1kb each and another person have 1000 e-mails with 50mb each. See the difference? It makes no sense to me, and I believe lots of people feel the same. |
21 Mar 2015, 02:52 AM | #82 | |
Senior Member
Join Date: Nov 2014
Posts: 127
Representative of:
Scryptmail.com |
Quote:
Link to website on right sidebar, but I agree we should make something more visible. Limiting email per box is topic where I can see we hurt the most. I don't know what to tell, besides all current browser encrypted services are built without being scalable in mind. If you bear with me for a moment, I can try to explain. First of all, you have two very separate entities, its your inbox and email itself. When you open inbox you should have ability to fetch all existing email in it very easy, for sorting by date or search ability. For example tutanota fetching all individual email separately to display in inbox, it may work fine when you have 500 emails, but 10000 will render service unusable or will force them to store a lot of metadata unencrypted so server can paginate result. In SCRYPTmail we created separate object which stores email metadata, and fetched when you open mailbox, but size is critical and around 1mb in size with 2000-3000 emails. As you can see we thought about scenario, other services will have to deal with it later. I.e offering Gb of mailbox for end to end encrypted email service almost the same as having unlimited domain hosting with $5 hosting service. With all being said above, I agree that we should make different message about mailbox limit, but I can't think of anything except giving false promises. I will appreciate if anyone can help us on that Last edited by scryptmail : 21 Mar 2015 at 04:12 AM. |
|
27 Mar 2015, 02:16 PM | #83 | |
Essential Contributor
Join Date: Aug 2012
Posts: 236
|
Quote:
|
|
27 Mar 2015, 02:41 PM | #84 |
Senior Member
Join Date: Nov 2014
Posts: 127
Representative of:
Scryptmail.com |
|
31 Mar 2015, 08:42 AM | #85 |
Senior Member
Join Date: Nov 2014
Posts: 127
Representative of:
Scryptmail.com |
|
10 Apr 2015, 12:57 AM | #86 | |
Junior Member
Join Date: Feb 2014
Posts: 26
|
I'm just discovering your service, looks pretty good and promising
Quote:
That is not clear for me. |
|
10 Apr 2015, 01:56 AM | #87 | |
Senior Member
Join Date: Nov 2014
Posts: 127
Representative of:
Scryptmail.com |
Quote:
There are rumors, that lavabit was ordered to handle their SSL private keys (http://en.wikipedia.org/wiki/Lavabit). According to the article they disclosed users information before. Giving out SSL key ultimately mean, FBI would be able to deploy MiTM attack and read all and any users communication, and lavabit decided to close their doors. So in my point of view there are 2 vectors: 1) Handle SSL key - which will allow to modify code on the fly and catch users password or weaken encryption algo. 2)Require access to database. With second scenario, I would disclose it without hesitation. In fact we build our database to be publicly available so we don't even have to have such requests. If we encrypt your data on your computer, database will have no value, as everything encrypted with AES-256 and/or using recipient public key. We did not make it public, just because there are email addresses, which is hashed by SHA512, but still can be guessed for spam purpose. In the first scenario we still better protected than lavabit, as any text being encrypted before going over SSL. Which will require attacker to change JavaScript code. Currently we don't have concrete solution for this problem, but possible solution would be to create standalone code allowing people to run it on local machine, and communicate with our server through API. With that being said, right now under option 2 we will give them data, for option 1 we will close our service or/and relocate it outside of USA. Last edited by scryptmail : 10 Apr 2015 at 02:03 AM. |
|
10 Apr 2015, 04:23 AM | #88 |
Junior Member
Join Date: Feb 2014
Posts: 26
|
Thanks for your prompt answer, that is much appreciated and sounds more clear for me.
Giving that, indeed if in option 1 and if "they" requests you data you can close the service which will be a very bad news for all users that are doing the right things but are impacted despite their good behavior or you will choose to relocate outside USA, ok clear. But then, why didn't you choose to locate your service outside this country directly at the very beginning of your project? What is your added value for you to stay here if you know there is a chance that you can leave with a very expensive cost (the more you wait...)? I don't know if my question is clear |
10 Apr 2015, 05:11 AM | #89 | |
Senior Member
Join Date: Nov 2014
Posts: 127
Representative of:
Scryptmail.com |
Quote:
Well, I want to believe being honest about risks will paid off in long run rather than build business by misrepresenting the real situation. I tried to explain it in my FAQ area (http://blog.scryptmail.com/2015/02/q.html) in Location. With new Snowden interview (https://www.youtube.com/watch?v=XEVlyP4_11M) he said any communication being sent over US border end up storing on one of NSA servers. Based on this fact, we clearly better set, because all our servers located in US, when other services captured by default. Having service in other country won't protect service from government of those country, which may want to intervene as well. Or make broader law (http://www.swissinfo.ch/eng/security...-ears/41300372) And if we decide to do so, we probably have to relocate too, as residing in US may be those leverage to tell us what to do. I hope it explains our decision. |
|
10 Apr 2015, 07:04 AM | #90 |
Junior Member
Join Date: Feb 2014
Posts: 26
|
It is clear. I'm more worried about the small chance you can close your business and then I can lose my emails (of a life) because of a country which doesn't share our values (which I can understand also).
Thanks for your explainations and your time. Your service seems very promising and the dev of new features are really quickly implemented which shows me that compared to the others providers I should give you a chance, and your presence here as a "human guy" and not a "support contact" shows me that you are not only doing support but also look at the customer feedbacks (curstomer oriented - listen your community) which is a very big plus in my view. I hope to receive an invitation, or I will try to participate to the project by a donation, let's see. Last edited by orelz : 10 Apr 2015 at 07:09 AM. |
Thread Tools | |
|
|