I've been studying decryption mixnets, in the context of e-voting and stealth networks. Let's describe it in a very simplified way. The concept is pretty simple. A message M is forwarded through several servers, A,B,C. The user encrypts the message with the public key of C, then encrypts that output with B's key, and then encrypts it with A's key. Each server removes a layer, and the last server knows the plaintext.

My two questions are...

How is it possible to implement this in software? I'm using Python, and every single library uses padding. After two or three layers of encription, the output is so, so large. For security purposes, asymmetric encryption needs a random padding. But I think that this case needs just one layer of random padding, at the beginning (C layer), instead of adding PKCS in every layer. Is there a library implementing mixnets, or a low-level module that allows you to encrypt with RSA or ECC without padding?

And, what about the lengths? Public-key encryption has a length limitation for the plaintext, depending on the size of the key. How does this apply to mixnets? Is the only solution to this problem a hybrid scheme, encrypting a symmetric key?

  • $\begingroup$ Public-key cryptosystems in this context are almost never used to encrypt the actual message. Their job is key negotiation and proving the identity of the recipient. $\endgroup$
    – Serpent27
    Sep 7, 2020 at 23:14
  • $\begingroup$ In fact, it's often recommended to specifically avoid using a public-key cryptosystem to encrypt the actual message. $\endgroup$
    – Serpent27
    Sep 7, 2020 at 23:16
  • $\begingroup$ I've seen this, and how hybrid methods are used even for untraceable pruposes like this, thanks. However... what do you mean, @Serpent27 ? Besides the length limitation, is it safer to encrypt a short message with a hybrid system, rather than encrypting it directly with the public-key, with OEAP-PKCS for example? $\endgroup$
    – FairLight
    Sep 8, 2020 at 14:17
  • $\begingroup$ Public-key cryptosystems I would warn you not to encrypt the message at all with the public-key algorithm. Public-key is really only meant as key negotiation, without the "negotiation" part; and to sign hashes of messages. Anything else is out-of-scope for a public-key algorithm, and can lead to unanticipated issues. $\endgroup$
    – Serpent27
    Sep 8, 2020 at 14:36
  • $\begingroup$ Also, by encrypting only the key you can solve the padding issue simply by pretending the other bits don't exist - if I have a 128-bit symmetric key to share but 2048 bits to fill, the decryptor knows to only take the first 128 bits of output. The rest can be filled with zeroes, the link to a cat picture, or ideally random data to act as an nonce; nonces are good to use, even where they're unneeded. $\endgroup$
    – Serpent27
    Sep 8, 2020 at 14:39

1 Answer 1


With RSA and ECC you generally don't encrypt the actual message. When signing, you sign a hash of the message; and when encrypting you encrypt a symmetric-key that can be used to decrypt the message. The message itself is encrypted using either a block cipher, or a stream cipher, depending on what was chosen in the design. As such, with a block cipher, once the message is padded once it's already as long as it's gonna get, and with a stream cipher no padding is needed at all.

Also, it should be noted that ECC-based public-key algorithms operate a lot more like a block cipher than RSA does. With RSA you would need padding at every layer, but with ECC you only need to pad once.

  • $\begingroup$ ElGamal ECC uses mapping messages to points and this is problematic. Menezes–Vanstone ECC works on $F_p^*\times F_p^*$. Either RSA or ECC encryption is a waste of resources. $\endgroup$
    – kelalaka
    Sep 8, 2020 at 6:39

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.