# Implementation of a decryption mixnet, and problems with the size of the key

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?

• 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. – Serpent27 Sep 7 '20 at 23:14
• In fact, it's often recommended to specifically avoid using a public-key cryptosystem to encrypt the actual message. – Serpent27 Sep 7 '20 at 23:16
• 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? – FairLight Sep 8 '20 at 14:17
• 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. – Serpent27 Sep 8 '20 at 14:36
• 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. – Serpent27 Sep 8 '20 at 14:39

• 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. – kelalaka Sep 8 '20 at 6:39