Encryption - Symmetric Encryption RRS feed

  • Question

  • I need to encrypt user ids and other keys so that end user could not easily tamper it and make a request. I want fast and reliable encryption algorithm.

    I am using RijndaelManaged algorithm to encrypt small piece of data. The seed of which is defined on web.config on connectionString section and is encrypted. 

    My problem is if I encrypt say for e.g., 7245 I always get constant encrypted data something like this VD2KoCzA%2fuljLxbhE%2fv5yf%2fPoJKBSpzomjj6HwZzi4aLJ%2fUWERFsQcMepH2so1KD no matter how may time I call .

    I need encryption that adds randomness on the text generated. I added date time and/or guid and packaged encrypted data. Now 1st run -> ANqvyv0a3YTUsb%2buKWBQGkoBylptatQ6W7FqIec1umS6OLV5Njrn8Pil%2b77Py1RX 2nd run-> ANqvyv0a3YTUsb%2buKWBQGkoBylptatQ6W7FqIec1umT58UZJ6I9PCvloxga9vTp%2b only last few part has changed.

    I want slow encryption algorithm that generates unique data each time I call it, and not somewhat obvious. I know I can change the seed each time I encrypt data and use the same key to decrypt this is not my option as my seed is not changing it's the data that may change.

    So I if encrypt "help me" I may get VD2KoCzA%2fuljLxbhE%2fv5yf%2fPoJKBSpzomjj6HwZzi4aLJ%2fU and on next call it may be ANqvyv0a3YTUsb%2buKWBQGkoBylptatQ6W7FqIec1umS6OLV5N  see they are different and not obvious. It's okay if the lengthh of these two matches.

    Tuesday, April 15, 2014 9:06 PM


  • Most symmetric encryption methods are block-based. If you want to add some salt to it, check the .BlockSize property and add the salt at the back of each block.

    Say if the block size is 256 bytes, split the data you want to encrypt to 224 byte blocks, then append 32 bytes of random data after each block. When decrypting it, after each 224 bytes being read, discard 32 bytes because it's garbage.

    P.S.: Actually if you'll write both encryptor and decryptor yourself, there's no restriction on where to add the junk data. I personally advise adding it in the front rather than back because those brute force decryptors usually checks whether the first few bytes are in ASCII char range to determine whether "the try" is successful.

    Wednesday, April 16, 2014 1:22 AM