Tag Info

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 ...

0

In fact we can, it is not common, because when NIST did choose AES candidates, they limit block size to 128 bit, and key to 128, 192, or 256 bits. For me this limitation is pure artificial and created just to make some sort of standard approach. We won't speculate on reason they decide to do so. In PHP for example you can specify block size as 256 bit, so I ...

13

We can't implement "AES 512 key size" because AES is defined for key sizes $k\in\{128,192,256\}$ bits only; much like we can't make a bicycle with 3 wheels. I see no reason why we would want to define an AES variant with 512-bit key size (since AES-128 is safe enough for anything foreseeable most current applications except those that require huge security ...

1

In both options, if the adversary has a way to check either AES key, then a brute password guessing attack can be attempted, and BCrypt is the main line of defense against that. For constant effort, option 2 force to halve the cost parameter in BCrypt, and is thus twice more vulnerable to password guessing than option 1 is. BCrypt's output is described as ...

0

This is done by the server recording all public keys of all clients and presenting them (usually on demand per client). This allows a client to generate an AES key (or replay it) as a secret message to any other client without the server knowing what it is. An extra protocol layer is required where the server's exchange with the client is somehow signed (or ...

1

This is pretty common. The method of encryption is public information, so it is safe to leave in the clear. In your post you made no mention of authentication. This is something you absolutely must use, otherwise you have no way of knowing if your data has been modified and leaves you open to many attacks. Consider using HMAC with SHA-256, or a block ...

4

You could do a brute force attack where you simply try the keys with highest Hamming weight first (those with the most ones). I am not sure if you would call this attack practical but at least it would be much more likely to succeed quickly than brute force when the key is selected uniformly at random. Just consider the key of all ones, and assume we are ...

0

Given that you used a strong password to derive the AES encryption key: Yes you could securely store your RSA private key in encrypted form on a server. BUT, since there is no technical need to have your private key on the server, why would you risk it? Look at it that way: Suppose you have very sensible data (like private photos or so). Now you could ...

0

The reason we add salts to the key derivation process it to make the key hash image unique for a given password. Actually a salt is added to remove weakness when an attacker has a list of "most common password". Adding a salt make the attacker job harder, he has to rebuild the attack per every salt he finds, i.e.: per every ciphertext he gets. It is ...

-1

You should get the IV of CBC as the first ciphertext block. Wikipedia: CBC

0

(posting as an "answer" because it's a little to long to fit in the "comment" section) It sounds like you are trying to build a 256 bit block cipher, given a 128 bit cipher and 2 keys for that cipher. I'm gonna clarify one more time ... The way I intended this to work: the decryptor uses the second key to decrypt every even block of the full ...

3

There are two major problems with this method. The first problem is that Susan is likely to be able to recover significant amount of data from a series of such blocks. For example, if Susan knows $subkey_1$, then she could recover the value $subblock_1 \oplus subblock_2 \oplus subkey_2$; if a single block is encrypted with this key, she can't deduce ...

2

You have more than one question in your... question. user13741 already did answer the "is 2x AES-128 as secure as 1x AES-256?" part, so only a small summary: Plaintext is the message before it was encryptet, and ciphertext after it was encryptet. You can encrypt a known plaintext with all possible keys and save the result. Now you decrypt the ciphertext with ...

1

Encrypting once with a 256-bit key is stronger than encrypting twice with two 128-bit keys. This is because of the Meet in the middle Attack. Encrypting once with a 256-bit key gives you 256 bits of security. Encrypting twice with two 128-bit keys gives you 129 bits of security.

3

To answer your question, the cryptographic complexity will reduce by $2^{k-n}$ where $k$ is the key length and $n$ is the number of bits known. A slightly better scheme that doesn't use a cryptographic key sharing scheme can be as follows: Generate three random numbers $B_1$, $B_2$, $B_3$ with bit length equal to the size of your key $K_p$. Generate each ...

3

Just use Shamir's Secret sharing: wiki link It's designed by Adi Shamir, who is the "S" in RSA. It's fairly simple to use and there are no known weaknesses in it. While it doesn't split the data, splitting the key may work just as well (unless you absolutely must split the data.)

2

What they are trying to say that an effective way to multiply $a$ and $b$ in $GF(2^8)$ is to first check if either $a$ or $b$ are zero (if either are zero, the result of the multiplication is zero), and if neither are zero, then: $$a \otimes b = E( L(a) + L(b) \bmod 255 )$$ where $E$ and $L$ are lookups in the ETable, LTable given, and the addition is over ...

1

This question has nothing to do with AES; instead, it has to do with an encoding that someone picked for this example (and the fact that you have questions about it indicates that it wasn't a great choice by whoever came up with the example). The encoding is simple; we translate the letters 'A' through 'Z' to the integers 0 to 25, which is in hexidecimal ...

2

I believe this question is only answerable if $F_k$ is easily invertible. In other words, if you can compute $M=F^{-1}_k(F_k(M))$. Then a standard meet-in-the-middle attack applies. Given message $M$, ciphertext $C = E_k(M)$ for unknown $k \in \{0,1\}^{128}$, an efficiently-computable function $X$ such that $k = X(k_1, k_2)$ for some $k_1, k_2 \in ... 2 You misunderstand$(02) \cdot 10000100$; it is not integer multiplication (resulting in a 9 bit integer); instead, it is multiplication in$GF(2^8)$(which results in an element in$GF(2^8)$, which can be represented in 8 bits). AES uses a polynomial representation of$GF(2^8)$, using the polynomial$x^8 + x^4 + x^3 + x + 1\$; what this means is that ...

Top 50 recent answers are included