[OTR-users] Question about the authenticated key exchange

Tue Oct 30 05:35:43 EDT 2012

  The explanation makes me believe, that you do not need OTR for this.
  What you're trying to do is something more like Enigmail.

  First point: when encrypting a file you do not use public/private
pairs. This is because asymmetric encryption/decryption is slow, and
asymmetric keys are vulnerable to specific attacks that use many
encrypted parcels. Instead you encrypt the content with a symmetric
one-time key, and then encrypt that key with the asymmetric key-pairs
of the intended recipients. Then you store the encrypted contents and
the encrypted key together. G/PG/P have containers for that.
  Well... Group sharing is a bit of a burden. You need to either
encrypt the encryption key with the personal keys of every member, or
create a key-pair for the group, distribute the key to every member of
the group (by encrypting it to that person), and then use that key to
encrypt the encryption key of the content.
  The first method does not allow for a member to join later (all
previous content has to be resent to the new member), and may lead to
data bloat (every content contains the encryption key encrypted for
every member of the group).
  The second method allows for late joins (just send the public part
to the new member), and does not lead to bloat (only one encrypted
key), but leads to trust issues, since every member will have multiple
keys, it also does not allow short-lived groups. The trust problem may
be mitigated by key signing: the group owner signs the group-send key.

  The second method has an additional security concern: once a public
key is compromised the whole content is compromised retroactively. I
am not sure though, that the first method will not be compromised in
the same way. I am also not sure if it's fixable at all... If one node
is compromised the content could be leaked unencrypted.

  OTR has a somewhat different idea: forward secrecy and plausible
deniability (is this word real?). That is done by providing secrecy of
the conversation for a small period of time (as long as the
conversation takes place). Afterwards the members publish one half of
the key (the one that they used to send messages with). In your case
there is no real boundary for the «conversation», and publishing parts
of the keys will not enhance security, while deniability is probably
not a perk you're looking for.

  For method 1:
  I look up the public keys for every member of the OTR mailing list.
I encrypt every message to the OTR list with a symmetric key, then
encrypt the symmetric key with the public keys of all members in the
OTR mailing list. Then I send the whole combination to the mailing
list. Every member uses their private key to decrypt the symmetric
key, and then decrypt the content.

  For method 2:
  Consider this key structure:
  <Lachezar Dobrev> (Asymmetric)
   |-> <Lachezar Dobrev @ OTR>      (Asymmetric)
   '-> <Lachezar Dobrev @ Enigmail> (Asymmetric)

  Both lower keys are signed by my main key. The people on both OTR
and Enigmail mailing lists have trusted my main key. I send the public
<Lachezar Dobrev @OTR> key encrypted to every member of the OTR group.
Then I encrypt every message to the OTR group using a symmetric key,
and encrypt the symmetric key with my private <Lachezar Dobrev @ OTR>
key. Then I send both to the mailing list. Every member uses the
public key I sent them earlier to decrypt the symmetric key, and then
decrypt the message. I don't like this method very much.

  I suppose there is a third method: encrypt the content with a
symmetric key, and publish only the encrypted content. Then send a
personal message (using an alternate channel) to every member you want
(immediately, or upon request) containing the symmetric key (encrypted
with the recipient's public key).

  Well... There is no win-win situation.

  There may be other schemes.

  Holding the key-pairs at the server is bad. Even if the user has
extremely good password, at some point the person's key will have to
be held in memory unencrypted. Encryption and decryption should happen
at the user's end, ideally the private key of the user will be on a
secure device (smart-card for instance). There are solutions to this
for all modern browsers.

  P.S. The message expands on my personal views of encryption, and
does not necessarily represent anyone else's views. In particular this
may not be in conjunction with the OTR Project members' or Enigmail
Project members' opinions.

  P.S. The techniques described in this message may have flaws, since
I am not a security expert. Please feel free to correct me.

  P.S. This may be (more or less) Off-Topic, for which I apologise in advance.

2012/10/30 Viktor Stanchev <me at viktorstanchev.com>:
> Okay, maybe my questions will make more sense if I explain what I'm doing,
> so let me try that and maybe you would have some suggestions about what
> features I can provide without inconveniencing users.
>
> My plan is to build a social network where users encrypt everything they
> share with a limited audience in a way that the server can't read it. Users
> need to be able to send messages to multiple recipients (including
> themselves) when they share something like a photo. Anything stored on the
> server would be encrypted with someone's public key, so the server will
> never know the contents of any of the data. Sure, they can keep track of who
> is talking to whom, but I think if I'm careful I can add deniability by
> allowing users to send messages without authenticating to the server as a
> specific user. This opens up the possibility of spam, but I'll worry about
> that later.
>
> My plan is to assign everyone a key pair and store it on the server,
> protecting the private key with a password. (Yes, I know it can be attacked
> offline by the server. It will be up to the user to choose an appropriate
> password.) Each user will add friends by basically sending themselves an
> encrypted message containing their public keys. After a friend is added, I
> plan to give them the ability to use SMP/manual verification to authenticate
> the public key stored for their friend.
>
> In many cases the users will not be both online at the time the messages are
> sent, but ideally, they will have previously verified each other's public
> keys.
>
> As I'm writing this, I'm becoming more convinced that GPG + SMP might be
> more suitable for what I'm doing. Maybe I can use OTR just for chat and skip
> the verification of public keys because I've already done that when the
> friend was added. I guess I still need AKE, just not SMP.
>
> Is there anything I can do to add deniability to an asynchronous
> conversation?
>
> - Viktor
>
> On Sun, Oct 28, 2012 at 4:27 PM, Ian Goldberg <ian at cypherpunks.ca> wrote:
>>
>> On Sun, Oct 28, 2012 at 03:25:01PM -0700, Viktor Stanchev wrote:
>> > Hi,
>> >
>> > I'm trying to understand why an Authenticated Key Exchange protocol is
>> > used
>> > in OTR instead of just exchanging public keys in plaintext. Where can I
>> > read more about AKE?
>>
>> The public keys in OTR are indeed just exchanged in plaintext.  But the
>> AKE then uses those public keys to securely establish session keys.
>> This allows for forward secrecy and deniability.
>>
>> > I'm building a cyrpto based system that uses the socialist millionaire
>> > protocol to verify public keys, but I don't need a session at the time
>> > of
>> > the authentication. Users will be sending each other messages later on
>> > and
>> > I don't think I'll be using perfect forward secrecy because the messages
>> > are not chat messages.
>>
>> What kind of messages are they?  Does it matter if they can be read by
>> an adversary next week, next month, or next year?
>>
>> What do you mean by "later on"?  There's a long time between the
>> "authenticate public key" step and when the encrypted messages are
>> actually sent?  Will you have bidirectional communication at the time
>> messages are sent, or just one-way?
>>
>> > What do you guys think? Should I skip the AKE?
>>
>> If you can do the AKE right before sending the messages, that's best.
>> If you can't, you'll probably also lose deniability.  If you really
>> don't need deniability or forward secrecy, then you may as well just use
>> gpg.  You can still verify the GPG public keys with SMP if you like.
>>
>>    - Ian
>> _______________________________________________
>> OTR-users mailing list
>> OTR-users at lists.cypherpunks.ca
>> http://lists.cypherpunks.ca/mailman/listinfo/otr-users
>
>
>
> _______________________________________________
> OTR-users mailing list
> OTR-users at lists.cypherpunks.ca
> http://lists.cypherpunks.ca/mailman/listinfo/otr-users
>