Tag Info

Hot answers tagged

20

It's meaningless nonsense. I would be inclined to avoid spending any money with these people. If you scroll down on this page, you'll find a table labelled key size vs. time to crack, according to which their $2 \times 256$ bit encryption takes $3.31 \times 10^{112}$ years to crack, making it (apparently) superior to ordinary $256$-bit encryption (which can ...


5

At a high level, the major flaw is that you are rolling your own crypto protocol. You should strongly consider using a standardized protocol like DTLS. Some specific problems: Symmetric key distribution is left unspecified. Keys must be changed occasionally to thwart distinguishers. No way to recover from symmetric key compromise. Your message ...


4

Would this help preventing brute force attacks? It would slow down an attacker and prevent them from trying as many password guesses. E.g. if you used 1000 rounds like in RFC 2898, you would reduce the number of guesses by a factor of 1000. Assuming you count dictionary attacks under brute force attacks, such attacks would definitely not be completely ...


4

If we take some randomly generated key of AES-128 and we change any random 1 byte of that 16 byte key, will this make huge difference in the AES cipher text generated over same input string? Yes. The outputs with different keys differ greatly. If you pick two random keys the outputs must look completely uncorrelated, or an attacker could gain an ...


4

I'll answer in order: Output size = input size That's correct, GCM uses CTR internally. It encrypts a counter value for each block, but it only uses as many bits as required from the last block. CTR turns the block cipher into a stream cipher. IV of any size For GCM a 12 byte IV is strongly suggested as other IV lengths will require additional ...


4

The simple answer is no, even if one can choose "the original unencrypted (cleartext) file".


3

The "interesting" part of your encryption is here: Therefore, I prepend a block at the beginning of my packet. Its content goes as follows: First four bytes: current timestamp in seconds Next 12 bytes: zeros I compute the sha256 hash of the message (32 bytes) I xor the timestamp + zeros block with the first half of the hash I xor the ...


2

I'm not an expert yet, but this is how I remember it. DPA or differential power analysis is a side-channel attack on hardware implementations of cryptographic algorithm. All electronic circuits consume different amount of power depending on the activity of individual transistors. For example, more transistors may switch when adding the hexadecimal bytes A7 ...


2

AddRoundKey. That step takes 16 bytes from the expanded key schedule, and exclusive-or's ("adds" in $GF(256)$ terminology) it to the intermediate block state.


2

The keyword you are looking for is related-key attack, where exactly this kind of different input keys (without the restriction to 1 byte) is used to break the cipher. (Wiki) Related crypto-SE topic: Related-key attacks on AES A related-key attack on AES has been analyzed by Biryukov and Khovratovich Also worth a look: Security section of Wikpedia for a ...


1

How the cipher key is scheduled if it is less than 128 bit (for AES 128), or less than 192 bit (for AES 192) or less than 256 (for AES 256)? That is undefined; the AES specification does not address that possibility. The AES 128 algorithm assumes that you give it 128 bits of key (and tells you exactly what to do with that key); it says nothing about ...


1

GCM is sometimes called a 1.5 pass AEAD cipher, where the CTR encryption counts for 1 and the GMAC counts for 0.5. So you would indeed expect it to be faster than encryption + CMAC and HMAC with regards to the amount of CPU instructions. That is: as long as the encryption is using AES for both solutions. GCM requires a 128 bit block cipher while CMAC and ...


1

As far as I understood the method of creating the 128 bit counter in the NIST documents is more or less kept open. There are some hints of deriving the counter, but NIST is essentially saying that anything is secure as long as the counter is unique. Using a starting value of 128 bits is certainly feasible and often required. Java providers - for instance - ...


1

I think it is now valid to answer this question as this course is likely to be over. First observer how CTR-mode works: $C_1=E_K(IV)\oplus P_1$ As you can see, there's a linear relation between the plaintext and the ciphertext. You now use $C_1$ (observed) and $P_1$ (known). You want to make $C'_1$ decrypt to $P_1'$. To obtain this you first construct ...


1

To expand on what kasperd says in a comment. This sort of thing should be handled in the protocol. This would typically be done by adding message authentication code (MAC) in the traditional encrypt-then-mac paradigm or using authenticated encryption. So then instead of doing if (client.aeskey != server.aeskey), print Error, you would be doing if ...


1

There's no practical difference between zero IV and any other constant IV here. With some older ciphers that have a small enough keyspace (or weaknesses that allow reducing it) you could have a rainbow table for the encryption of the zero vector which might make zero IV a weaker choice in some cases, but that would be impossible for AES with its 128-256 bit ...


1

Concatenating two copies of your message is unnecessary and is equivalent to padding out your 64 bit message to the full 128 bits with zeros from a security standpoint (which happens automatically in the encryption process). Would they be able to securely authenticate the message? I assume you mean Authenticated Encryption. The simple answer is no. ...


1

Reusing an IV once opens you up to someone finding the XOR of those two plaintext, seriously compromising their confidentiality. Moreover, with GCM, a single IV reuse leaks significant information about the key used for authentication; if there are even a few pairs of reused IVs (not even one IV used many times; a few IVs each of which are used twice is ...


1

KDFs like PBKDF2 are a work multiplier but they can't get blood from a stone. A PBKDF2 using 10,000 rounds "slows" the attacker down by requiring each "guess" to take 10,000 hashes instead of 1. The problem is that passwords like the ones you described are so weak a 10,000x increase in cracking time is like going from 1 ms to 10 seconds. It really isn't ...


1

To do EEA on a finite-field, you can't perform the operations using the operations in the ring of the integers (and they're not precisely the same operations in the field either, as you're working with bit vectors, not field elements). In particular: When you do "addition", you need to perform the addition as done in even characteristic fields (that is, ...



Only top voted, non community-wiki answers of a minimum length are eligible