Tag Info

5

The pseudocode has a serious issue: changing the value of nonce2 in an otherwise valid cryptogram is not detected, and results in invalid deciphered plaintext. That would be fixed by encrypt(password, string): nonce1 := generate_random_nonce() nonce2 := generate_random_nonce() key := derive_key(nonce1, password) encrypted := nonce2 || cipher(nonce2, ...

4

The term "plaintext" in cryptography does not imply that the input is actual text. Traditionally, the plaintext was often actual text, but the term just refers to the input (other than the key) to the encryption algorithm. Plaintext can be a sequence of letters, like in many classical ciphers; it can be an analog telephone signal; it can be an image or map; ...

4

Although there are already many answers here, I wanted to strongly advocate AGAINST MAC-then-encrypt. I fully agree with Thomas' first half of the answer, but completely disagree with the second half. The ciphertext is the ENTIRE ciphertext (including IV etc.), and this is what must be MACed. This is granted. However, if you MAC-then-encrypt in the ...

4

They're both broken under known plaintext attack, where attacker knows two (plaintext, ciphertext) pairs, $(m_1,c_1)$ and $(m_2,c_2)$: $E'_1(k_1,k_2) := k_1 \oplus E(k_2,m)$ $E'_1(k1,m_1) \oplus E'_1(k1,m_2)=E(k1,m_1) \oplus E(k1,m_2)$ The attacker simply computes $E(k1,m_1) \oplus E(k1,m_2)$ for every possible value of $k_1$ and compares it with $c_1 ... 3 I would propose a rather different scheme. encrypt(password, string): nonce := generate_random_nonce() secret := pbkdf(nonce, password) mackey := kbkdf(secret, 'mackey') enckey := kbkdf(secret, 'enckey') iv := kbkdf(secret, 'iv') encrypted := cipher(iv, enckey, string) return (nonce || encrypted || mac(mackey, encrypted)) Note that I've ... 3 This is only a problem if there is very little knowledge about the plaintext. If the plaintext is fully random, you have no distinguisher and you can therefore not detect if you hit the jackpot. If you do have information about the plaintext then it doesn't take a lot of information to see if you have the correct key. And usually there is a lot of ... 3 Among several aspects of the question, I'll cover only protection against replay of commands. A common technique (among several) is to have commands tied to a nonce, that somewhat is accepted only once by the slave device receiving the command. The nonce is included in the input of a MAC or public-key signature algorithm that protects the integrity of the ... 3 You're right in that there's little chance you can break the logarithm in a well-chosen 512 bit group (using a home computer, in reasonable time — as pointed out by SEJPM, it is possible investing some time and a good amount of money). However, in your case, the parameters are bad: The order of$(\mathbb Z/p\mathbb Z)^\ast$, that is$p-1$, is a smooth ... 3 No, because an adversary can pick an arbitrary plaintext, encrypt it using your public key, and then compute whether his plaintext is "less than" or "greater than" the plaintext corresponding to the ciphertext he wants to decrypt. He can do this intelligently several times to "home in" on your ciphertext's corresponding plaintext using binary search, ... 2 It seems to me that you could prefix the Defcon level with a 15 byte counter and then encrypt it using a single block ECB (also known as AES used as a block cipher). Decryption will give you the counter to validate and the Defcon level. For a slightly tricker to implement scheme use a 7 byte counter and an 8 byte AES-CMAC, and encrypt that. This does expand ... 2 On encrypting the same plain text, I get two different outputs. This is in fact a design goal of encryption systems: an adversary who sees two ciphertexts should not be able to tell whether they're equal — that would be an information leak. Even encryption systems that would otherwise be secure use an initialization vector or other similar unique value ... 2 Am I correct in assuming the above? No you are not. You are showing textbook/raw RSA, which is little more than modular exponentiation. To be secure RSA has to use padding methods. Without padding, RSA would indeed generate the same ciphertext each time. This alone would break the security requirements of a cipher. There are many other attacks on ... 2 My advice would be to use a stream cipher. First of all, it is easy to implement, because you won't have to think about dividing into blocks, padding, etc.. Secondly, the idea of stream ciphers is very easy: you generate a pseudorandom sequence of bits out of the private key. Then you XOR this sequence with a plaintext. You will only have to code the ... 2 How can a computer leverage that tiny extra probability to crack a secret key? The answer to that depends on what type of key it is, how it's being used, etc. Certainly, the bias would make a brute-force attack easier, but you probably wouldn't need to worry about that, regardless. Your professor, though, is trying to answer a different question. He ... 2 Your scheme turns AES into a one way function. As you already found out from the comments this scheme doesn't preclude collisions. There is a good reason why hash functions have a larger output size than the block size of most block ciphers as the birthday problem is applicable for this newly build PRF and normal hash functions. The chance of a collision is ... 2 I unfortunately don't have enough reputation to comment, forgive the answer that is a link to another answer. Your question is explained well in this answer: http://crypto.stackexchange.com/a/12706/17884 2 The following is the main contributor reply: The latest released version of CryptDB no longer supports the LIKE operation. Feel free to contribute to CryptDB and extend it to support this operation. You can find an older implementation (disabled) in the code, which we did not have the chance to port to the latest system. 2 "RSA/ECB/PKCS1Padding" - as you already found out - is not really implementing ECB. For instance Bouncy Castle also has "RSA/None/PKCS1Padding" to mean the same thing. ECB is used for block cipher modes of operation, and RSA is not a block cipher. For block ciphers ECB makes some kind of sense; it basically means performing the block cipher operation for ... 1 It's probably better to use a KBKDF as that doesn't need a key as input. You can use the KDF as key check value or KCV. If you use a block cipher based KBKDF from NIST SP 800-108 then you could reuse the AES algorithm to calculate the KCV. You could however also make it easy for yourself and use a SHA-1 or SHA-2 over the key as KCV. Note that the PKCS#11 ... 1 It is secure. The IV only needs to be indistinguishable from random to an attacker, and it is as long as the salt is random. There is one remark: if you extract more key + iv bytes than the hash function in PBKDF2 returns then the PBKDF2 function is executed twice. An attacker however only has to find the key, not the IV, so an attacker doesn't have to do ... 1 The speed of individual algorithms strongly depends on their implementation. This goes for both hashing algorithms as well as encryption algorithms. This quickly becomes clear if you take a look at efforts like “eBACS: ECRYPT Benchmarking of Cryptographic Systems” and the results presented. Also, you should not ignore that some algorithms have specifically ... 1 Perhaps you are referring to a polymorphic virus? This is a virus which consists of a decryption program along with the actual virus code which is encrypted. When the virus runs and subsequently spreads, it re-encrypts itself with a different key, thereby appearing to be different each time it propagates. 1 Cryptdb doesn't support LIKE queries. You can try using in and not in queries. It supports update, in and not in queries but not like. 1 The meet-in-the-middle attack still applies; instead of attack effort 257 DES invocations, you just increased it by 256 extra DES block encryptions, i.e. up to about 257.6 in total: a mere +50% increase. On the other hand, you also made the overall block cipher (your two-key triple encryption) 50% more expensive to use, so the overall security has not ... 1 First, let's try to undestand how decrypt works. Here I present you a slightly modified, more readable version of the same code, with no functional change: size_t decrypt(unsigned char *buffer, size_t buflen) { size_t opos = 0; int seed = 7; for (size_t ipos = 0; ipos < buflen; ++ipos) { int temp = buffer[ipos]; This first ... 1 For completeness / posterity / future inquisitors, this is the response I got when I asked on the mailing list. I have also included it below because links sometimes break. No, you're not missing anything. This requirement is not, algorithmically, necessary. When you're decrypting with the symmetric key available, rsyncrypto uses the public key ... 1 Hash the original text, store the hash along with other auxiliary data. Check decrypted text against the hash. This will check the overall integrety of the process, not just the use of the correct key. 1 Usually a cryptographic transformation can mean anything. It is just a cryptographic function whose output is based on the input,$K$and$R$in this case. You could have a$MAC(K, R)$where the transformation is a message authentication code or MAC for instance. A MAC also takes a key and a message, but its purpose is rather different. So$K\{R\}\$ is a ...

1

if you want to use a password, SRP is probably a good choice. alternatively, you could use ECDHE with ECDSA or RSA keys. you should also use a MAC of some sort if you're using CBC (and encrypt then MAC). GCM or OCB would be much better choices.

1

This is a perfect job for a Key Based Key Derivation Function or KBKDF. Generate two keys from the input (salt and password). One is stored directly in front of the ciphertext and one is used as encryption key. Because the KBKDF is based on PRF it cannot be reverted, so the keys are not related as far as an attacker is concerned. Currently the best KDF is ...

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