1

I need to store encrypted information in a MySQL table. I would like to use the AES algorithm but I don't know if 4096 bit encryption is supported and if it is a good length to encrypt data like: credit card, email etc.

Matthew
  • 27,381
  • 7
  • 91
  • 103

2 Answers2

16

No, 4096 bit encryption is not good enough to encrypt your data. Becase of a few reasons.

  1. AES does not support 4096 bit encryption.
  2. Even if AES supported 4096 bit encryption, it would be far to slow (most likely). When 128 bit AES is plenty secure why would you want to slow your system down for such little added value?
  3. If you actually meant RSA instead of AES, the answer is maybe. 2048 bit RSA is more than sufficient and faster, so 4096 bit may be overkill. But, that said, why would you want to use public-key crypto to encrypt your database? Normally that would be a bad idea. Please post more details so we can determine the best recommendation.
mikeazo
  • 2,837
  • 16
  • 29
  • not to mention, RSA will be really slow, as in I'll have to wait a year for it to encrypt. (for a whole database) – ewanm89 Nov 24 '11 at 01:27
  • Your answer's lacking the the fact that he shouldn't store credit card information at all, and definitely not in a reversible form (encrypted). – Stef Heylen Dec 15 '15 at 15:11
  • @StefHeylen why not? Tons of companies store credit card info. I would prefer that they didn't, but legally (in the US at least) you can. – mikeazo Dec 15 '15 at 15:21
  • @mikeazo: yes, if they comply to the industry standards (PCI-DSS). Why would one encrypt credit card information rather than hashing it? There's no reason to have it in a reversible form is there? – Stef Heylen Dec 15 '15 at 15:24
  • Well.. There could be reasons but I don't believe they weight up against the risk. – Stef Heylen Dec 15 '15 at 15:25
  • 1
    @StefHeylen I agree. I wouldn't store it either. But, the fact of the matter is that tons of businesses do. Typically for convenience purposes (makes it easier for you to pay them and easier for them to charge you). I wouldn't even store hashes of a credit card number. That could lead to an off-line brute force attack. Credit card number entropy is low enough. – mikeazo Dec 15 '15 at 15:35
  • @StefHeylen You can't submit a purchase to a credit card processor using a hash! You have to store the actual number under reversible encryption if you're going to store it at all, unless you're using the CC# for something other than making purchases. Also, CC#s have far too little entropy to be meaningfully hashable (typically 12 digits, at most, are random); you can brute-force any hash of a number that size pretty quickly with a GPU unless you run them through a slow password-hashing / key derivation function, and at that point you really won't be able to buy anything with the output. – CBHacking Mar 13 '19 at 21:48
-1

Since quantum computing, with noisy qubits, can already crack a 760 bit number in several hours, 4096 might fall a lot faster than you can imagine. This has recently been published but a Chinese quantum research group. That is, just cause they're noisy doesn't mean they can't do the job.

oaksong
  • 1
  • 1