> On Mar 21, 2016, at 10:23 AM, Alfonso Coscione <alfo...@coscione.it> wrote: > > Hi OpenSSL Staff, > > sorry for disturb. > I'm an italian young engineer and I'm working on new software project > that wuold want to use yours openssl library to realize an > encryption/decryption protocol to use for downloading updates from a > server. > I try to find on web some informations, but i'm not able to understand > about the sizes. > I explain better. > I've to know, more exactly, how to calculate the dimension of an > encrypted text after an encryption with a private key with an RSA > protocol..
Well, with RSA, the input size and output size will match the size of your key. For example, if you have a 2048-bit RSA key, then the output and input sizes must be exactly 2048 bits. You can encrypt/decrypt multiple times, in order to get larger amounts of data, but that’s almost certainly not what you want to do. Instead, you should choose a symmetric cipher (e.g. AES) for encrypting your data. You can then encrypt the symmetric key with your RSA key (along with appropriate padding, since your symmetric key should be smaller than your RSA key — there’s lots of good advice on the 'net for choosing appropriate sizes for these). It next depends on the algorithm you chose. If a streaming cipher, the input and output sizes will be the same. If a block cipher (like AES), it depends then on which mode you choose for predicting the size of your encrypted output. If you chose CBC, e.g., the output size will be a multiple of the block size, either the size of your plaintext rounded up to the nearest multiple of block size, or the size of your plaintext + the block size. For AEAD modes, like GCM, the output size will match your input size, but you’ll also have an additional value to store. Then, on top of all that, you probably need to include the encrypted key, so the receiving end can decrypt. Finally, I would note that you probably want to include some kind of structure around all this. CMS might serve you very well. At the least, it’s a good, relatively easy starting point. > and so, also the dimension of a decrypted text after an > decryption with a public key. > I don't know if you can help me.. I would appreciate any help or > suggestion. It depends on how you decide to format your data, but when this information is critical, but not likely to tell an attacker anything useful, one would usually just store the size of the decrypted data, so the receiver can just read it directly. However, it’s often not critical to know the size before you start decrypting, and a successful decryption will not return any excess data (such as padding), so you can track the size as you decrypt, and know as soon as it’s finished. Just to be sure it’s clear, but you usually don’t want to encrypt data with the private key — doing so means that just anyone can decrypt it. You want to encrypt using the public key, so that only the person who has the private key can decrypt it. And if you’re doing some sort of update, this kind of encryption is probably a bad idea, unless you’re encrypting updates for each customer. Unless there’s something super-super-secret about the update, I’d recommend delivering the update via TLS, and only sign the data, so that each customer has the public key, and only you have the private key, and each customer can be certain the update came from you, not some malicious user or system (and if it is that secret, I’d consider delivering updates only in person, and you can just avoid any automation entirely :) ). When creating signatures, you do encrypt with the private key, but we don’t usually use that terminology, in order to avoid confusion. When signing data, you would typically route all the data through a hash method (e.g. SHA-256), and encrypt the resulting hash along with info about the hash method to get a valid signature. Again, you’d need some structure to indicate what data was signed, and what the signature is, and again, CMS would be a good starting point. I think once you’ve decided exactly what you’ll be doing and how, you’ll be able to predict your final sizes. TOM <snip> -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
