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,233
  • 7
  • 87
  • 101
  • 3
    That depends on if you use it correctly. –  Nov 22 '11 at 20:17
  • 3
    4096 bit AES? Are you sure you're not talking about RSA? AES 256 is probably the "comparable" key size for AES and as an algorithm my understanding is that it's very secure. – Ben Brocka Nov 22 '11 at 20:20
  • 1
    I've heard 1,048,576 bit is pretty good. –  Nov 22 '11 at 20:20
  • 23
    The fact that you are asking this question tells me you should definitely **not** be in the business of storing credit card information. If you are going to store credit card information you'll need [PCI compliance](https://www.pcisecuritystandards.org/security_standards/documents.php?document=pci_dss_v2-0#pci_dss_v2-0) and that's not exactly trivial. – Null Nov 22 '11 at 20:21
  • @Blender at least until the AES-4,194,304 spec comes out – Ben Brocka Nov 22 '11 at 20:36
  • 4
    You also might like to read [what is the difference between 128, 192 and 256 bit AES in practical terms](http://crypto.stackexchange.com/questions/20). –  Nov 23 '11 at 09:22
  • Read [What does “key with length of x bits” mean?](http://security.stackexchange.com/q/8912), then read [AES for key encryption](http://security.stackexchange.com/q/5692), then read [mysql AES_ENCRYPT key length](http://security.stackexchange.com/q/4863) – Gilles 'SO- stop being evil' Nov 23 '11 at 17:54
  • 7
    Do not store credit card information. – Ramhound Nov 28 '11 at 17:04

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,827
  • 12
  • 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](https://security.stackexchange.com/questions/52852/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