0

I need to encrypt a high number of short messages (30-200b). The problem with usual algorithms, such as RSA, is that the size of the encrypted message tends to increase a lot, compared to symmetric encryption algorithms.

Ideally, this cryptosystem shoud accomplish:

  • Asymmetric
  • Size of the encrypted message must be at most 25% longer than the original
  • Should be fast encryption and decryption
  • It's not a problem if, after some work, some messages are decrypted
  • But private key must not be found so easily
  • It would ve good if it's a known algorithm with solid implementations in most common languages

The only solution I found until now is using RSA with short keys (64 bits), but I wonder what a better approach could be.

sinuhepop
  • 20,010
  • 17
  • 72
  • 107
  • 1
    Check out Curve25519 – samgak Aug 02 '16 at 02:21
  • @samgak I'll take a look! – sinuhepop Aug 02 '16 at 04:11
  • 2
    *"Size of the encrypted message must be at most 25% longer than the original"* - If you want to publish this then the ciphertexts will already be longer than that, because you will need to encode them with something like Base64, which has a blowup of 33%. This is true even if the encryption itself doesn't have any blowup. You can look at format-preserving encryption, but it is only symmetric AFAIK. – Artjom B. Aug 02 '16 at 05:05
  • @ArtjomB. True, I was thinking on the byte size increment only, not how it's represented on text. In fact, messages are JSON with only lower case letters, so I expect to reduce a similar amount due to only use a fraction of character space. Unfortunately, symmetric encryption is not an option for now. – sinuhepop Aug 02 '16 at 09:03
  • Do they need to be encrypted for the same user? In that case you could create a hybrid cryptosystem. There is no way that you can only expand a 30 byte message 30% without using hybrid encryption; you cannot perform asymmetric encryption and only have an overhead of 10 bytes. – Maarten Bodewes Aug 02 '16 at 19:25
  • 1
    I'm voting to close this question as off-topic because this is about [cryptography](https://crypto.stackexchange.com) without involving programming. – Maarten Bodewes Aug 03 '16 at 10:43
  • @MaartenBodewes: Different customers would generate web pages with some encrypted metadata in them, which my application should read (knowing keys of every customer). I prefer asymmetric in order to avoid risk of workers spreading shared key. – sinuhepop Aug 03 '16 at 12:47
  • @MaartenBodewes: I agree, I've cloned it (http://crypto.stackexchange.com/questions/38141/public-key-encryption-algorithm-for-short-messages), but I don't know if there is a way to merge it with these comments and responses . – sinuhepop Aug 03 '16 at 14:51

1 Answers1

2

If you need to securely transmit "a large number of short messages," then what I would recommend is that you send the messages through a VPN link, and to use digital certificates to secure that link. Public-key encryption techniques will be used during the initial handshake to negotiate a random symmetric "session key" for the subsequent transmission ... and, all of this(!) is "graciously and completely invisible" to the two applications that wish to talk. They simply back-and-forth unencrypted data from one IP-address to another, and, automagically, the transfer is actually securely encrypted.

From time to time, VPN re-negotiates a new session key.

Another reasonable alternative is TLS, the encryption technology behind https web sites.

In short: "secure the channel," using PKI techniques, so that you can then securely transfer data between the two parties without any further effort or complexity on their part.

Mike Robinson
  • 8,490
  • 5
  • 28
  • 41
  • In fact, I don't want to *transmit* those messages. Alice has to publish them in public media, such as a web page, and Bob has to decrypt them. – sinuhepop Aug 02 '16 at 04:10
  • In that case, I suggest that the added "payload" of key content in the files is simply a price to be paid for confidentiality. – Mike Robinson Aug 02 '16 at 13:15