I have a battle-tested black box crypto library which was developed by industry recognized experts. This box keeps your private key in a hardware backed, tamper proof storage. It only does one thing. Takes an 8 digit all ascii chars as input, encrypts it using RSA and returns the ciphertex. Extreme measures are taken to prevent known side channel attacks and the encrypted information has no monetary value. No-one has any motivation to attack this system. And I am just a developer. Dont know anything about asymmetric cryptography. And for some reason I want to encrypt my name using this magic box, repeatedly. Over and over again.

If this was AES, I would use an IV. Not that I know what an IV is but people on the internet says it is good to add some randomness.

Now, I just wonder, theoretically, does adding a timestamp to my name before encryption improves the security of my cipher?

Original question:

I am supposed to encrypt a user's ID with user's public key. For encryption, I have a blackbox crypto library. The library is assumed to be safe and secure, I have no control on it. I just select RSA or EC, give it the plaintext ID and it gives me the cipher-text. I will be encrypting a user ID each time a user logs in and the ID never changes. Would it make my implementation any safer if I append some random data or a time stamp to the ID before each encryption?

  • 2
    encrypt with private key Private keys don't encrypt things!!
    – user163495
    Mar 12, 2021 at 10:10
  • @MechMK1 Well, i guess that's why i am not allowed to play with the blackbox library :) I changed it to public key. So back to the question, would it make my implementation any safer?
    – b4da
    Mar 12, 2021 at 17:31
  • Why are you encrypting the ID? That is generally considered to be public.
    – MikeSchem
    Mar 12, 2021 at 18:52
  • 1
    Note a clear question. How will the user generate their private key, they will keep them secure, and why do you keep the userID encrypted with the user's public key? Also, in cryptography devil in details. How can you be sure that the black box cryptography library is secure in your usage way?
    – kelalaka
    Mar 12, 2021 at 20:33
  • 1
    Normally, RSA encryption must be executed with proper padding like PKCS#1v1.5 or OAEP. I cannot say which is used or none of them here. Both are probabilistic encryption, so that encryption of the same data can't be the same up to some bounds. For example, PKCS#1v1.5 can randomize if modulus has n-byte and the data has d bytes then n-d-3 bytes are randomized. Can we access the technical docs?
    – kelalaka
    Mar 12, 2021 at 21:58

2 Answers 2


The seminal work of Shafi Goldwasser and Silvio Micali, Probabilistic Encryption, 1984, change the way we consider security. We no longer use/prefer/recommend non-probabilistic encryptions.

For the security of the RSA encryption padding is required and there are two different paddings is definded PKCS#1v1.5 and OAEP padding, both can be found in rfc8017

Since you have PKCS#1v1.5, let's talk about here a little;

PKCS#1v1.5 uses the following format

00 || BT || PS || 00 || D

BT is the block type
PS is the padding string
D is the data

|0x00|0x02|Random non-zero bytes|0x00|data|

  • The first byte (also called octet) zero 0x00 guarantees that the message size < modulus size in an integer value.

  • The next byte (block type) 0x02 indicates the PKCS#1v.5 padding.

  • The non-zero random bytes (padding string) guarantees that when the same message is encrypted again under the same public-key ( actually public key is a pair (n,e) ) will be different, if each encryption, a new random value must be used. And this is in the standard.

    Of course, we have the birthday bound here. Let assume that one uses the 2048 RSA modulus then it has 256 bytes. If the data has 8 bytes then we have 256-8-3 = 245 bytes for the non-zero random bytes. Then you need to encrypt the same message around sqrt(255^255) to have the same encrypted result with 50% probability. The collision is negligible.

    The size of this non-zero random byte cannot be less than 8 bytes. So we say, PKCS#5v.14 has at least 11 bytes of overhead.

  • The next 0x00 is the delimiter.

  • The last part data is your data

Note 1: I would like to note that the incorrect implementation of PKCS#1v1.5 resulted in many attacks. OAEP is easier to implement and both have the security proof ( we have waited very long for PKCS#1v1.5)

Note 2: When RSA is used without padding we call it Text-Book RSA.


No, as long as the encryption you use is secure, this won't really add substantial security.

  • Can you add some context or justification? Mar 12, 2021 at 20:48

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .