<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">2014/1/2 Nathan of Guardian <span dir="ltr"><<a href="mailto:nathan@guardianproject.info" target="_blank">nathan@guardianproject.info</a>></span><br>
I was thinking about how to pre-key'ing work could be<br>
implemented in a more generic way, that would not be tied to a specific<br>
server or app.<br>
<br>
Would it be possible using either an XMPP file transfer mechanism, or<br>
something like our OTRDATA protocol, to send a number of pre-keys to a<br>
contact, say at the time of an existing chat? </div><div class="gmail_quote"> </div><div class="gmail_quote"> </div><div class="gmail_quote">Dear Nathan, dear Ian,</div><div class="gmail_quote"> </div><div class="gmail_quote">
1.) this reminds of the Rosetta CryptoPad doing this: here you send a key shared in the past, and can generate at any time new ciphertext to be sent over XMPP or any other Messenger or Email. The key must be surveilled in the past and as well the private key must be screwed up. So this is unlikely. Due to the hashes and salts the same plaintext generates each time a new ciphertext. What would be the benefits, to have the D/H Key exchange not in each session? see a seceenshot here:</div>
<div class="gmail_quote"><a href="http://goldbug.sourceforge.net/img/screenshot_rosetta.png">http://goldbug.sourceforge.net/img/screenshot_rosetta.png</a></div><div class="gmail_quote"> </div><div class="gmail_quote">2) you want pre shared keys? a bunch of? and want to use the XMPP data sharing protocol? this reminded of the StarBeam File Transfer which is done as well with pre-shared keys, the keys are sort of a magnet due to the Magnet-URi standard and looks like this. The thing is, you can choose one or several magnets to have access to the transfer (message or data file). I would rather extend your request to have not only pre-shared keys, but to use one or more keys for one transfer, so it is much more difficult to break not only one key, but severals.</div>
<div class="gmail_quote"> </div><div class="gmail_quote">magnet:?ct=aes256&ek=qhp5TUo2fRqzQ3+Vryhrjx+yMTGkGY4k&ht=sha512&mk=8ks/krZad5n/CPDhxTkn9tNIPfmQeCj/5CkOMxzjzG5ISx9HiLRmAYvLcmd1ncOTp6k2C4a5KjetZMIW9voGokwxgsHoqL+CwITo/hBmNyCNB+SHqRQ15/b3BXYQo0YAETDy7KJZXcviyVD33auGX4Hh3u6e9x8tIJnrZOKTVez80AA0WWPSCQZd1Nf8Istl1VHcf46tlBLwy0coopGCnzKQohH+8UeX2mfjKyzEv9M8352C+XjdwfJHe2lBv8gkwZM84ie/1YPryWhWQFQHIEYlpEtB8/v86AKDfuTRxfxUD4rTB5AELsscSqsTf/WEnD/Vl/p2WJhPEa3P7eBAaD71mzA8OZv0URsVj11piFchMoOdgCRJtxlI0nNDKDeRLRw9+1I0C3or6eAhW5lTDmLvynft/8xrvC9hsLdT6Va5QorR7N+/zwJGsbHkSoMmiFaNrqB8JoO5XqBJIetYzEYl6nkCAJT8DUMuKRFHGvk/SzaGjX5vwszSeuYdg0ti&xt=urn:starbeam</div>
<div class="gmail_quote"> </div><div class="gmail_quote"> </div><div class="gmail_quote">3.) As far as it is known, OTR uses perfect forward secrecy (PFS) per session, right?. Why not introducing that with each message? That would be instant forward secrecy (IFS). E.g. within an SSL session you can renew the end to end e.g. AES keys for each message. That has been called the MELODICA feature. You can read up about IFS and MELODICA in the whitepaper: <a href="http://downloads.sourceforge.net/project/goldbug/goldbug-im_0.8._RELEASE/GoldBug_%20Secure_Instant_Messenger_Manual_08.pdf?r=http%3A%2F%2Fsourceforge.net%2Fprojects%2Fgoldbug%2Ffiles%2Fgoldbug-im_0.8._RELEASE%2F&ts=1388738025&use_mirror=switch">http://downloads.sourceforge.net/project/goldbug/goldbug-im_0.8._RELEASE/GoldBug_%20Secure_Instant_Messenger_Manual_08.pdf?r=http%3A%2F%2Fsourceforge.net%2Fprojects%2Fgoldbug%2Ffiles%2Fgoldbug-im_0.8._RELEASE%2F&ts=1388738025&use_mirror=switch</a></div>
<div class="gmail_quote">MELODICA allows to renew the end to end session key whenever this button is pressed, even within a session.</div><div class="gmail_quote"> </div><div class="gmail_quote">Dunno if some ideas can be helpful with your featurerequest and the protocol for OTR could be extending ideas for these standards, e.g. when extenting the Rosetta Cryptopad with an XMPP client, then you need not to copy /paste the ciphertext into/out of the tool. Besindes the convenience, to have one addressbook in general in the cryptopad rather than having keys in each application and having these RSA keys shared in the past, imagine extending the tool to an easy to use function with adding an XMPP client: would that offer more or less security than sessionbased PFS ? I think your request is, that PRESENCE must be defined new (as it seems to be risky) and key sharing might be more secure, if it is done in the past? Was that your intent? both ideas use RSA I think? and the differnece is, that OTR exchnages the keys at the same time within the same session. It is a good idea to think about doing this in a different channel in the past, right?, or, if done in the same session in the same channel, then to let the user beeing able to renew the keys, whenever he thinks? Comments for more Flexibility and more Security?</div>
<div class="gmail_quote"> </div><div class="gmail_quote">Is session based key exchange insecure? Imagine just that: RSA might put a fingerprint into the ciphertext. If then a pipe is surveilled, the message might not be deciphered in the first atempt, but the messages might be watched due to the fingerprint and it is clear in any way, which two IPs are talking (even if the IP change in another session and the internet routes them to a differnet knot). For that we have to secure the key exchange and keep even the public key exchnaged in private (e,g. in a personal contact over USB stick). Is the sessionbased D/H key exchange really the standard which should not be questioned (and OTR can relay on without alternative ways)?</div>
<div class="gmail_quote"> </div><div class="gmail_quote">Regards R.</div></div></div>