# Tag Info

0

The answer is simple. The recommandations of all experts in this case is to dissociate Keys used for Encryption from Keys used for MAC-ing. Then you have to use two different Keys.

3

The comments on the question are very good. That said, I'll try to address the question(s). What factors should I consider so that it does not become weaker? This is a very important concern that I am glad you have. One of the big strengths that standard ciphers have is that lots of really smart people have looked at them and have not been able to ...

1

If I'm not missing some important point here, that's rather trivial to calculate. As implicitly stated in your question, the attacker has two possible ways to brute-force the encryption key: either by brute-forcing the encryption key itself or by brute-forcing the user-entered password. Given the numbers of iterations of the key derivation function n, the ...

6

If you look at the algorithm description, you see that, at a high-level, the encryption algorithm looks like this: addRoundKey(0); for (int i = 1; i < rounds; i ++) { subBytes(); shiftRows(); mixColumns(); addRoundKey(i); } ...

1

There should be no need to reverse engineer AES as its algorithm is already publically available. The algorithm is supposed to be so good that even though its inner workings can be (and indeed are) publically known, it is still extremely difficult to break. I think the difficulty you may be running into is that the round keys are used in reverse order when ...

0

I understand the system as follows: data blocks are enciphered per AES-CTR, using key encryption_key, with an IV made by concatenating device_id and a counter held in Flash or EEPROM, incremented at each use; that enciphered data is integrity-protected by a 256-bit mac_tag computed using HMAC-SHA256 and mac_key. That's theoretically sound if device_id ...

1

AES is secure in such a way that you cannot find the key even if you know (part of) the plaintext. So it is not possible (feasible) to deduce the key based on the file prefix to decrypt the complete file. I suspect this is the attack that you anticipate. Like woliveirajr said, you can just use the existing filename with a suffix like .enc. What you need to ...

-5

We know, from Edward Snowden, that the NSA does, routinely monitor all traffic and can decrypt all standard encryption, such as SSL. So it is likely that they have methods to break AES. So, if you are concerned about industrial espionage, AES is unlikely to be your algorithm of choice - this is not just because of NSA or GCHQ spying, any third party ...

0

It is the encryption using the key $Y_i$ of the constructed message. The message consists of key $K_i$ XOR'ed (bit for bit) with the previous key $Y_i$, followed by ${nonce}_1$. where $K_i$ is the potential session key if the handshake is successful, '${nonce}_1$' is pseudo randomly generated nonce specific to one authentication session. ...

1

If you are encrypting one file to one file, simply save the correct extension. Example: open test.pdf, encrypt the content, and save as test1.pdf, or test1.pdf.enc (so that you know that the file is encrypted and any pdf won't try to open it when you double click). If you are encrypting more than one file together (and, in the end, you have one big chunk of ...

0

This is a common problem which most software doesn't handle, surprisingly. Yes, decrypting to the filesystem is problematic as you guessed. A better approach would be to split the file in "packets" and encrypt/authenticate each packet separately. However you will have to take care of many details (e.g. you can write only the first IV and implicitly ...

0

If you definitely can't use other libraries such as Bouncy Castle, your best option is probably to just add an HMAC authentication tag (it should be easy to write a MacInputStream/MacOutputStream to chain it into your existing pipeline). The primary reason is that the JDK 8 (at least up to 1.8.0_25) GCM implementation suffers from two problems that make it ...

0

If you don't allow changes, renames and overwrites then you could create an IV by hashing (e.g. with SHA-256) the unique location of the file. If you want to allow changes/renames/rewrites you could re-encrypt with an IV that also uses the time of the change, if that is unique and stored reliably. That is, if you want to keep the size of the files to the one ...

1

There is nothing in the GCM cipher that prevents it's use it in streaming mode. You should however not use the resulting plaintext during decryption for anything that requires security before you have verified the authentication tag. The authentication tag is not to prevent you from decrypting the ciphertext. It is there to provide for integrity and ...

3

AES CBC usually requires padding, such as PKCS#7 padding. This padding is 1 to 16 bytes, 16 being the block size of AES. The HMAC will add 256 / 8 = 32 bytes to the total. Usually you will need to store the randomized IV as well with ciphertext, to allow for reuse of the key, adding another 16 bytes (the block size again). So the total overhead will be about ...

Top 50 recent answers are included