# Tag Info

0

Using Diffie-Hellman key agreement for generating a nonce should be safe as long as both key pairs are ephemeral, i.e. generated for each run of the key agreement protocol. Otherwise a man-in-the-middle can fool one of the parties in generating the same nonce over and over again. Ephemeral Diffie-Hellman is however overkill for generating a nonce, as the ...

0

It might be worth pointing out that the Boomerang attack by Alex Biryukov and Dmitry Khovratovich requires four keys. Some of the older related key attacks required $2^{35}$ keys, which makes the attack much harder in practice. But forcing a target to rekey four times is quite realistic.

1

What is the probability that both [Hu] = [Hmu] and [He] = [Hme]. In english, what is the chance that two different files can have identical hashes in both an unencrypted and encrypted form? Depends on whether they are "random" files or attacker controlled. MD5 is a 128-bit hash, so for two random files that differ the probability that they have the ...

3

AES is a block cipher which actually only "maps" (encrypt) a 128 bit block (plainblock) to a 128 bit block (cipherblock) and vice versa. This "mapping" is key dependent. To encrypt some data you normally apply an encryption mode like CBC, CTR, GCM etc. using e.g. AES as block cipher within this mode. These modes normally require an IV or Nonce. So, not ...

2

Like said in the comments, a 256-bit message is two blocks of AES, no matter the keysize. The main issue with ECB mode (i.e. using AES directly on 128-bit blocks) is that you leak whether two blocks are equal. When encrypting perfectly random data, that means there's a $2^{-128}$ chance the two parts of the key are equal, and the attacker knows that. The ...

0

I guess it doesn't matter. The "device secret" here doesn't need to be called secret IMHO. Its something like your public identity (like your email address, your github account, etc..), if its randomly chosen and has no relation to its corresponding key stored in the server then it shouldn't do any harm.

0

Will the presence of this "secret" (presuming it is the same in every message coming from that device, and in the same location within the message) cause repeating patterns in the ciphertext making some form of attack possible? As long as the AES mode uses an IV and the IV is different for each message, there will be no patterns in the ciphertext. ...

2

I would advise a different solution. You either generate a master-key (or key set) or derive one from a user password (e.g. via PBKDF2 or SCrypt). For each file to encrypt you generate a random key (file key) and nonce ad-hoc, and encrypt the file with that key, using an AEAD scheme. The random file key is encrypted with you master key and put at the ...

2

There are two ways to attack encryption that uses a derived key: You can attack the encryption algorithm. In the case of correctly used* 128-bit AES, that essentially amounts to a brute force attack on the 128-bit keyspace. This would succeed after on average $2^{127}$ tries (if it were practical). If you knew that two files had used the same password ...

2

You did make a mistake but only in that you are missing the addition of the final vector, you correctly replicated the equation from the paper. The problem is that the equation in the paper is only for the linear affine tranformation step of the s-box and does not include the non-linear inversion in $GF(2^{8})$, namely $a = y^{-1}$ where $y$ is the input ...

4

Your code is an attempt to implement the function $f$ which is a polynomial representation of the $\text{GF}(2)$ affine part of the S-box of the AES (usually referred to as $A$). Function $f$ is described on page 7 of the paper and your coefficients seems to be OK. Your code is mapping $\text a$ to $\text q$ such that $\text q=f(\text a)$. You're however ...

0

Merely stacking weak crypto (this is a very well-done weak crypto) inside strong crypto does not add any significant strength to the strong crypto. I've studied interleaving crypto, and there are some cases where interleaved weak crypto would significantly strenghten already strong crypto, but AES is too hard for me to interleave without breaking it. Now ...

1

I second the suggestion of a strong password based KDF, e.g. PBKDF2 or scrypt, which you use to derive the encryption key(s) from the user's password. Additionally, use authenticated encryption (e.g. either AES GCM or AES CTR + HMAC). If you can't open the encryption using the key derived from the password they enter, you know the password was wrong. No ...

2

First, using only a single SHA512 to hash the password is not enough. You should use something like bcrypt with a long salt to store user password "hashes". A simple SHA512 can be attacked quite powerful with a dictionary attack, just trying millions of possible passwords and calculating the SHA512 hash for that until one matches. Concerning the encryption ...

2

There are two possibilities here: AES is secure, in which case no one can open your encryption without knowing your keys, regardless of whether you layer anything else on top of AES. AES is not secure and someone knows how to break it. In that case the security of your encryption might only be as strong as the second layer of encryption. In neither case ...

3

Since there are only $16^6 \approx 16.8$ million keys, you can try them all and decrypt the message with each. In general you would have to know something about the plaintext to identify which of those decrypted candidates is the correct one. In this case it is known that the message is English ASCII, so the top bit of each plaintext byte will be 0. The ...

9

When using CTR Mode the AES is used to generate a kind of key stream which itself is the XORed to your plaintext. So AES is actually encrypting an incrementing counter. At the moment there is no known attack, that would yield E(N) if you do know E(N-1), where N is the aforementioned counter. So this should be safe. But be aware, as the plaintext is XORed ...

10

AES-256 has sustained 15 years of cryptanalysis, and it can be stated that no knowledge of some plaintext bytes would help to reveal the other bytes no matter what mode of operation (CBC, CTR, etc.) is used. AES-GCM is an authenticated encryption scheme that allows a key holder to detect any modification that has been done to the ciphertext. If you do not ...

1

Take a look at some of the open source implementations or at the reference code. I couldn't find the later ad-hoc but some open source variants should be perfect. I experienced similar problems. Unfortunately the byte ordering is not always that clear. As owlstead mentioned, take a look at the detailed test vectors from the NIST publication (FIPS-197, ...

7

All of your encryption rounds are incorrect, either due to incorrect round function or key schedule (or state alignment). Showing round 0 (round key addition before first round) will help show if the keys are being added correctly to the state. The key expansion is also very important, if that is not done correctly it will not work at all. I will assume ...

4

Before answering your questions: GCM is an authentication encryption mode of operation, it is composed by two separate functions: one for encryption (AES-CTR) and one for authentication (GMAC). It receives as input: a Key a unique IV Data to be processed only with authentication (associated data) Data to be processed by encryption and authentication It ...

6

First, the obvious advice is not to use this in practice. Rolling your own is fine for learning, but you should use standard primitives when you need actual security. E.g. one from SP 800-90A which poncho linked in comments. Now, some observations. I haven't read all your code, so I may misunderstand things. Is this a good way to whiten the data? Is ...

1

I don't think it's useful spending time on trying to understand that paper, but if you look at the screenshots and compare to their "character counts", you see that they are counting base64 characters and including the padding characters in the count. That means "88 characters" could be one IV + three blocks of AES output (512 bits in base 64 = 85.33 + 2.67 ...

3

Your description of how RFC 5959 works isn't quite right. It is not quite correct to state that RFC 5959 encrypts using AES in ECB mode. A correct statement is: if the plaintext is exactly 128 bits, then use ECB mode, otherwise use a non-trivial mode of operation found in RFC 3394. In the former case, ECB mode is fine, since it's just a single block of ...

3

If the protocol doesn't provide authentication, an attacker can probably mount replay attacks or make deterministic changes to messages. If the nonces in different blocks are not compared in any way, they can just take the ID block of a previous message and use it with a new one, to forge it being from that device. If nonces are required e.g. to be equal in ...

2

The affine transformation is defined as a degree 7 polynomial multiplication modulo $x^8 + 1$. In the format of the question, the terms are the right hand column, top to bottom. $A = x^7 + x^6 + x^5 + x^4 + 1$, and $B = x^7 + x^5 + x^2$. The inverse can be determined through several methods. Since there are only 254 valid polynomials (omitting 0 and 1), ...

Top 50 recent answers are included