[OTR-dev] Pre-keying via OTR or XMPP

Randolph rdohm321 at gmail.com
Fri Jan 3 03:54:48 EST 2014


2014/1/2 Nathan of Guardian <nathan at guardianproject.info>
I was thinking about how to pre-key'ing work could be
implemented in a more generic way, that would not be tied to a specific
server or app.

Would it be possible using either an XMPP file transfer mechanism, or
something like our OTRDATA protocol, to send a number of pre-keys to a
contact, say at the time of an existing chat?


Dear Nathan, dear Ian,

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:
http://goldbug.sourceforge.net/img/screenshot_rosetta.png

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.

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


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:
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
MELODICA allows to renew the end to end session key whenever this button is
pressed, even within a session.

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?

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)?

Regards R.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cypherpunks.ca/pipermail/otr-dev/attachments/20140103/187d25d2/attachment.html>


More information about the OTR-dev mailing list