This feels like a silly question, but a cursory look around the internet hasn't exactly helped.

I'm implementing 1-out-of-2 oblivious transfer using DH key exchange in Python. I have successfully performed DH to get the symmetric key on both sides as well as the derived keys needed for the OT protocol. Strangely, I'm not sure how to apply the key to my message to actually 'encrypt' it!?

Is it multiplication, modular multiplication? I'm so sorry for what feels like a bad question, but I'm not seeing it.

I'm implementing the simple OT protocol at the bottom of the box on page 1 of this paper for reference. Thanks, in advance, for your time and help.

  • Why do you think they mean anything other than regular encryption like AES-CTR+HMAC or AES-CTR+GMAC, with the keys and IV/nonce generated using a KDF from the shared secret?
    – Z.T.
    Nov 4, 2016 at 1:48
  • Why do you think I think they mean anything other than regular encryption? I don't. I'm just wondering if it's ok to proceed with any symmetric key algorithm after the successful key exchange happens. Based on what you you said, it definitely sounds like any symmetric algorithm will work at this point. Thanks.
    – jkovba
    Nov 4, 2016 at 11:12

2 Answers 2


OK, absolutely mandatory first comment: DO NOT ROLL YOUR OWN ENCRYPTION PROTOCOL OR WRITE YOUR OWN CRYPTOGRAPHY IMPLEMENTATION. Just don't. Ever. It doesn't matter how great a programmer you are; if you don't have a lot of knowledge and practice with crypto and a group of similarly skilled-and-experienced peer reviewers, you will screw something up. Crypto is extremely difficult to get right, full of edge cases, counter-intuitive requirements, and unexpected side-channels... and if you fail to account for even a single one of them, you'll weaken your scheme, quite possibly to the level of complete compromise.


OK, I'm not familiar with the scheme described in that paper. Given that, the below stuff - for use with normal DH exchange, not this curious new thing - may not be appropriate. However, The question you asked, "How to Perform Encryption after Diffie Hellman Key Exchange", is answered below... except, of course, that the true answer is "you don't, you use a library that handles that for you."

Ok, with that out of the way... once you've got the symmetric key out of the DH exchange, use it in a symmetric cryptographic cipher! There are lots to choose from, but the most common is probably AES, using either a 128-bit or 256-bit key, in CBC mode, with PKCS7 padding, using a strong randomly-generated IV, and with an HMAC of the ciphertext for integrity. If your shared key is the wrong length for the cipher, you can run it through a function such as SHA-256 to produce a key suitable for 256-bit AES.

You can send the IV and the HMAC in the clear; they are useless to an attacker without the key and the intended recipient needs to know them. The recipient takes the ciphertext, re-computes the HMAC and verifies that it matches, then uses the supplied IV and the shared symmetric key to decrypt the message using the same AES cipher in CBC mode.

I cannot emphasize strongly enough how essential it is that you do NOT attempt to do this as anything but a curiosity. Do not publish this code. Do not incorporate it in anything you might ever publish. Do not build anything else on top of it. Do not trust anything sent via this system. Do not assume it has any meaningful security characteristics. Ideally, don't even stick it in your GitHub or whatever... but if you must, include a comment at the top very clearly disclaiming the suitability of the code to be used for anything whatsoever.

There are steps I've elided over or left overly vague. There's at least a dozen ways you could screw up even just the parts I've told you about, never mind all the other things you have to do. There's a bunch of stuff I suspect you've already done wrong in your key exchange. There are a bunch of things that I'm sure I don't even know are wrong, but that you're doing wrong.

I've been in InfoSec professionally for eight years, with an interest in crypto that goes back four years earlier than that, and at this point when I review homegrown crypto code I can give two meaningful answers: "It's broken" and "It's probably broken". I don't know enough to even tentatively state that something home-grown is not broken, and that will probably be true for the rest of my career unless I decide to devote a decade of my life to this specific area of security. Crypto is hard!

There exist libraries, written by people who know more about crypto than practically anybody else alive today, that will do pretty much any cryptographic task you ask of them. There are protocols, designed by similarly-experienced people and implemented with great expertise in those libraries, that turn cryptographic primitives (like DH key exchange) into a useful cryptosystem. Even so, bugs and weaknesses in those libraries are found all the time... but at least they're fixed quickly. You will NOT do any better yourself.

  • 3
    The only reasonably useful information, and the only information directly pertinent to what I asked for, is this: "once you've got the symmetric key out of the DH exchange, use it in a symmetric cryptographic cipher!".
    – jkovba
    Nov 4, 2016 at 11:20

I'm unfamiliar with the OT paper you linked. But from what I've seen, you shouldn't use the DH shared secret directly as your Symmetric Key.

The reason is if you ever want to rotate your keys, or generate additional keys, you would then have to do DH again -- which has a relatively higher CPU cost.

Alternatively, use the shared secret as the starting point, or seed value, for generating additional keys. Even something as simple as having both parties generate a random number, and combine them with the shared secret to generate your final, actual Symmetric Key. This combination can be done with any simple cryptographic hashing algorithm or Pseudo Random Number Generator (PRNG). Throw a timestamp in there and you guarantee unique keys each session (presuming multiple keys aren't generated in the same second).

Then, in the future, if you need more keys, you simply generate new random numbers -- which is relatively much easier to do than completing a new DH exchange.

Use DH to simply answer the "Key Exchange Problem" question. Use another mechanism to then actually derive session keys.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .