Hi all,<br><br>Sorry for not being clear about some things last time. Let me explain how I plan to solve some of the problems mentioned.<br><br>All encryption is done on the client side. I am not sending the private key to the server so it can do encryption for me. I'm saving it on the server so that I can download it on any device I want to use my account on. The private key is never decrypted on the server. I plan to use SRP (secure remote password protocol) to prove to the server that I have the password without sending it. I can make sure it's very difficult to brute force passwords by using a good and slow key derivation function.<div>
<br></div><div>I don't care that much about the safety of the admin or the ability of organizations to demand data from the admin per se. I would like to just not be required to trust the infrastructure over which I'm communicating. I want the server to be dumb and oblivious so there is no question about who has access to your data and so that the social network can't sell your data to third parties or snoop on your conversations arbitrarily. The admin can't know what his network is used for, so his safety is a side effect of my primary goal.</div>
<div><br></div><div>I'm aware that you don't encrypt the entire message with the public key.</div><div><br></div><div>I haven't decided how to deal with groups yet, but Lachezar's idea seems to make sense. The first method makes sense. The second method seems to use the public key as a private key. If you reverse the terminology it makes a bit more sense. I don't see what this offers over the first method. I guess the creator of the key pair is the only one who can send messages to the group, but isn't this equivalent to everyone using their own symmetric key and signing?</div>
<div><br></div><div>The third method is the same as the first, but uses a different channel to send the key. I think that might be a good idea in some cases. For example, I can take advantage of file hosting sites to upload large encrypted files and only use my social network to send the key. That doesn't compromise the security and it works great for the social network server :P</div>
<div><br></div><div>Anyway, does anyone have ideas about what the path of least resistance for doing this on Android is? I'm thinking of using the spongy castle library and any parts of the otr4j library that I might need. Using spongy castle might be a bit too low level, so I'm thinking about using some GPG library.</div>
<div><br></div><div>Comments, suggestions, ideas welcome.</div><div>
<br><div class="gmail_quote">On Tue, Oct 30, 2012 at 8:56 AM, Justin Ferguson <span dir="ltr"><<a href="mailto:jnferguson@gmail.com" target="_blank">jnferguson@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div><p>> The<br>
> only way for it to be secure is to <br>
> have the user store the private<br>
> keys on their own systems.</p>
</div><p>This.</p>
<p>Moreover why even leave the attack surface? I assume the intention is to evade warrants, NSLs, etc and less concern about the admin itself, so why even leave a bunch of private keys laying around for LEO? <br><br></p>
<p></p><div>> On Mon, Oct 29, 2012 at 11:44 PM, Viktor Stanchev <<a href="mailto:me@viktorstanchev.com" target="_blank">me@viktorstanchev.com</a>> wrote:<br>
> > My plan is to assign everyone a key pair and store it on the server,<br>
> > protecting the private key with a password. (Yes, I know it can be attacked<br>
> > offline by the server. It will be up to the user to choose an appropriate<br>
> > password.)<br></div><div>
> _______________________________________________<br>
> OTR-users mailing list<br>
> <a href="mailto:OTR-users@lists.cypherpunks.ca" target="_blank">OTR-users@lists.cypherpunks.ca</a><br>
> <a href="http://lists.cypherpunks.ca/mailman/listinfo/otr-users" target="_blank">http://lists.cypherpunks.ca/mailman/listinfo/otr-users</a><br>
</div><p></p>
</blockquote></div><br>
</div>