3

Say you just want to encrypt a number. For example, say the number could be any double. A double in C# and Java is 8 bytes.

If you were to encrypt a double using AES:

var cypherText = AES.Encrypt(123d); // 8 bytes

would that be trivial to crack? If not would it at least be significantly easier to crack than the cyphertext from a larger input:

var largeText = GetDeclarationOfIndependence(); // 6760 ascii characters, so 6760 bytes
var cypherText = AES.Encrypt(largeText);

closed as off-topic by AndrolGenhald, ThoriumBR, forest, Josef, Rory Alsop Sep 15 '18 at 18:43

  • This question does not appear to be about Information security within the scope defined in the help center.
If this question can be reworded to fit the rules in the help center, please edit the question.

  • 2
    Does the attacker have access to an encryption oracle? What mode is used? – AndrolGenhald Sep 11 '18 at 12:00
  • If I understand encryption oracle right it just means some additional information that can be used to help crack the cyphertext. If that understanding is correct then I'll say no, with the exception of having other cyphertexts (from a double input) encrypted with the same key. Any mode will do but I was planning on using CBC because it's the default in C#. docs.microsoft.com/en-us/dotnet/api/… – user875234 Sep 11 '18 at 12:17
  • 2
    You might get more detailed answer if you ask this question at crypto.stackexchange.com – Pilfility Sep 11 '18 at 12:21
  • 4
    Voting as off-topic since it was cross-posted to crypto.se. FYI cross-posting is discouraged, questions can be migrated when necessary. – AndrolGenhald Sep 11 '18 at 13:25
3

No, Unless...

It shouldn't be possible to "brute-force" possibilities unless you provide an oracle for an attacker to utilize.

An oracle in this case allows the attacker to feed as much chosen plaintext as they'd like into your encryptor, and receive encrypted output to check against.

If this is the case, you need to safeguard your data, preferably by setting an Initialization Vector for a block cipher mode like CBC or CTR (use GCM if possible), and making it so that the IV is chosen by the oracle (and not by the attacker).

Though you should really be doing this anyway.


I don't think the approach of padding your blocks with random data would be very effective in an attack against an oracle.

It could possibly mitigate an attack in the extreme edge case of only having 1 block of encrypted data, but it wouldn't be nearly as effective as just properly setting an Initialization Vector.


tl;dr No, unless there's an oracle for an attacker to exploit. If there is, make sure you're setting the initialization vector (oracle-side).

  • 1
    I may have recommended CTR in this answer, but it is worth noting decryption is the same as encryption in CTR mode. If an attacker is allowed to choose the IV with an oracle, then the encryption is completely broken. If you must provide an Oracle for some reason, don't ever allow the requester to set the IV. – Jesse Daniel Mitchell Sep 11 '18 at 17:36
  • Sorry if I'm a little ignorant here. I didn't realize how quickly this question would get advanced. It is an open source application so an attacker could easily start feeding data into it if they wanted to do some kind of analysis. I am using an IV, which is derived from the password that's used to encrypt/decrypt. ...Since the code is open source, and the IV is derived from the password have I inadvertently created an oracle for an attacker to exploit? I'm not asking for you to do an analysis or anything, but FYI this is my encryption class: – user875234 Sep 12 '18 at 11:44
  • The code being open source doesn't provide an oracle. Providing a network interface that allows someone to encrypt using your key (even w/o knowing it) does. If you don't allow someone to send data to you that you encrypt (using your key) and send back to them, you're fine. – Jesse Daniel Mitchell Sep 12 '18 at 15:47
  • 1
    Commenting on your code: Most of the logic in the class itself looks great, I'd tweak a few of the constants though. I'd increase the PBKDF2 iteration count to be much higher (like 100K). You might need to redesign your code to preserve this value in between decryptions. I'd also not derive the IV. Instead, make your 8 byte "salt" 16 bytes, and use it instead as your IV. (At the very least make your salt 16 bytes). Lastly, use PKCS7 padding. – Jesse Daniel Mitchell Sep 12 '18 at 15:48
0

Yes, if...

  1. You are stupid enough not to fill the remaining 64 bits of the block with random data
  2. The attacker knows that you're doing this (which is generally an assumption one should make according to Kerckhoff).

The reason is obvious: AES operates on 128-bit blocks (= 16 bytes), and if you fill in only 64 bits of payload (setting the remaining bits to zero or some other constant, or any such thing) then the number of possible outputs is only 264. Which is feasible to just brute-force (and pretty easy to identify, too, look for a result where half of the block is equal to PaddingValue).

Assigning an IV should do the trick. While a usual, "normal" IV actually doesn't solve the issue[1] , if you give it the right size (8 bytes) it just happens to fill the unused bits with random. Which is what you need to happen.


[1] If you prepend a full block as one normally would for an IV, then the block with the payload still only has 64 non-obvious bits, nothing changes, really

  • 1
    It's unclear to me how 0-padding 64 bits would allow brute-forcing it any easier, you'd still have to find the key. And I wouldn't call random padding an IV. – AndrolGenhald Sep 11 '18 at 14:44
  • @AndrolGenhald: I'm suggesting an IV because that is what the API happens to offer easily, and it should do the trick. I'm not aware of a random padding setting (though there might be some more or less obscure setting of PaddingValue, I wouldn't know). As for why zero-padding half the block makes an attack easier (well, "easy" is a funny word in this context, but certainly "easy" compared to having 128 unknown bits), I think that's rather obvious. – Damon Sep 11 '18 at 14:53
  • 2
    Obvious to you perhaps, I only see a weakness if the attacker has access to an encryption oracle. How does your brute-force work? And no, any reasonable API wouldn't allow you to use an 8 byte IV with a 16 byte block cipher. – AndrolGenhald Sep 11 '18 at 14:57

Not the answer you're looking for? Browse other questions tagged or ask your own question.