0
$\begingroup$

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?

| improve this question | |
$\endgroup$
  • $\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 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 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 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 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 at 14:39
1
$\begingroup$

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.

| improve this answer | |
$\endgroup$
  • $\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 at 6:39

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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