I am reviewing the code for a product our team developed where credit card information is stored in a local database in the event of no internet connection and came across the encryption methods. The developer who wrote this portion of our code encrypted AES over RABBIT over AES. I have seen implementations with AES over AES(same concept i suppose as TrippleDES) but never seen or researched stacking block over stream and if the results from this are going to be consistant(without data corruption) and secure which i would assume stacking encryptions with different keys can never be less secure than a one time encryption.

EDIT: To add the performance of this is not horrible. it takes 0.012 seconds to encrypt and decrypt credit card data.

  • If the keys are uncorrelated and the cipher algorithms don't cancel each other out, then it is at least as secure as the most secure cipher in use. But to figure out of it is MORE secure, you'll need a bit more analysis of exactly how the ciphers are layered. Cipher modes, order, etc...
    – Natanael
    Commented Nov 1, 2015 at 9:18

3 Answers 3


Encryption using rather different algorithms is probably not less secure than encryption with just one algorithm. There's a meet in the middle attack possible which may influence the security to be about the strength of AES + a single iteration of RABBIT though.

AES-256 is (thought to be) so secure that it will likely not be cracked even if quantum computers become a possibility. So basically you are only protecting yourself against significant breaks of AES. In that sense this kind of scheme only protects the part of the protocol that is most likely to be secure in the first place.

Cryptographic errors are easy to make. In that sense the more complicated the protocol the more likely it is that it is in error somewhere. If there is an error then the security of the layered encryption can easily be negated.


You probably won't see any research like that since generally you don't use stream ciphers for the same purpose as block ciphers.

Generally, a stream cipher should never be used to encrypt multiple messages with the same key, so if you're encrypting each card under the same key then you're making a this mistake. This is why stream ciphers are not used to encrypt things stored in a database.

However, in this case since it's sandwiched between two AES block ciphers then it's probably not vulnerable to a multiple message attack. You're gaining security from AES here and so the stream cipher probably adds little.

There are many mistakes that can be made even with AES block ciphers, so it's more important to understand the cipher mode used e.g. CBC or ECB and how keys are managed.

AES 128 and 256 are considered secure, so their correct use will give you a secure system. Mixing things up like this is making your system more complicated and giving scope to make more mistakes, so I wouldn't do it.

  • Thanks. Last week we switched to 1 aes pass. All of are keys are 1 time use and the keys themselves are encrypted using a RSA public key and can only be decrypted by the remote server holding the private key. Our engineers purpose behind this was apparently so that the originating terminal would have to remove the 1st layer the local server removed the second layer then the remote server removed the 3rd layer. We decided against this however due to the possibility of data corruption.
    – PC3TJ
    Commented Nov 9, 2015 at 3:25

There are no stream ciphers that are now considered secure. Don't use them anymore ever.

Double encryption is of dubious value and may lower security. For example, DES encryption uses a 48 bit key. 3DES uses a 144 bit key which is actually three 48 bit keys, applied as ENC->DEC->ENC rather than the less secure ENC->ENC->ENC. My point is that your engineer is not a cryptographer and is jamming recipes together without fundamentals or analysis or reason.

So, drop the stream cipher, it is bad, only applies to data in motion (never at rest) and isn't adding value here. Drop the second encryption, it isn't making it stronger. Think about it. If someone steals the data, does the second (or third) pass really make it stronger? The thief will be looking for the key(s) to decrypt. If you want to store the data for future transport in a non-recoverable method, there are better ways than that.

Instead, generate a one time key, encrypt with the strongest AES you can use, then encrypt the one time key with an RSA public key. Later, use another program, process or, for the paranoid, computer to decrypt the credit card data with the RSA private key to recover all of the AES keys. For a slightly less paranoid version, use one AES key for all credit cards per 1-4 hours.

This last method will be much more secure than the one you describe.

And, for everyone's sake, please encourage people to not roll their own fancy encryption methods.

  • We did drop this to a single AES encryption. And all of our data that is encrypted is always encrypted with a 1 time cryptographically secure random key then encrypted with a public key issued by our remote servers prior to being stored. The real reason the tripple encryption was in place after talking with the engineer who left us for work elsewhere was that 3 different computers held the keys to decrypt the message. So the originating terminal removed the first layer, the local server removed the second layer then the 3layer was removed by the remote server by using its private and aes key
    – PC3TJ
    Commented Nov 9, 2015 at 3:20
  • After he explained his reasoning it made sense however we did away with it due to the fear of increased potential of data corruption.
    – PC3TJ
    Commented Nov 9, 2015 at 3:21
  • I don't think data corruption could be an issue any more than it would be with plaintext credit card data. However, extra work of dubious value is certainly ripe for removal. Sounds like you solved the problem and with sensible cryptographic methods. Nice. Commented Nov 9, 2015 at 3:25

You must log in to answer this question.

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