# Tag Info

2

XTS has been designed for disk encryption, where an attacker typically has access to the disk only a single time (when they steal/confiscate the device). When an attacker sees several ciphertexts encrypted using the same key, they can tell which blocks differ between the versions, but not the content of the blocks. Compare this with CTR mode, which leaks ...

5

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

1

Knowing the message $m_j$ should not help you to get $r_j$. In-fact, ElGamal is assumed to be CPA secure (assuming that DDH is hard). Meaning that even if we choose two different plaintexts and give them to alice and she is encrypting only one of them, we won't be able to know which one she encrypted. You can easily show that if you could retrieve $r_j$ ...

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 ... 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 ... 0 To setup HMAC, you need a key. This key should be derived from ASecKey, for example by using HKDF. As input for HKDF, you supply Salt (does not have to be secret) + ASecKey. Then you generate entropy with HKDF (e.g. extract PRK and expand it). Use this entropy to obtain HMAC key. Then you can attach HMAC output to your file. When receiver wants to decrypt ... 0 I'll answer your "detailed questions", I'm sure the "main security issues" will become obvious afterwards. How does asymmetric encryption work in bitmessage? The bitmessage wiki explains how the encryption takes place. I'll quickly explain the basics. For each message, generate a secure 128-bit IV. Generate a new message key by generating a new ECDH key ... 0 A special case of the relation you've found is called Fermat's little theorem. In a more "mathy" way this looks like:$i^Q\equiv 1 \pmod p$which will always hold for$Q=p-1$and for any$Q|p-1$. The use of this theorem is limited in cryptography, however the problem of determining$Q$, if only$i$and$p$are known, this problem is called "discrete ... 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 ... 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 ... 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 ... 0 If you can express your operation well using plain groups, go with normal elliptic curves. But the pairing adds additional mathematical structure, which enables new algorithms. Some examples: BLS signatures They're verifiably deterministic and small, 2x security level, instead of 3 to 4 times, with DSA/Schnorr/ElGamal signatures. These use the pairing ... 0 We really only need one plaintext-ciphertext pair, but the second can be used as a way to check candidate keys. Make a guess to the final subkey (ie guess all of them). Decrypt the final round of your ciphertext using your key. Store this result and the subkey you used. Repeat for all 2^16 candidates for the final subkey. Make a guess for the first three ... 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 ... 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. 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 ... 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 ... 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, ... 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 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, ... 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. -2 This is an addition to the answer of Maarten Bodewes. I have found RNCryptor, which is file encryption/decryption utility. IMHO, anyone who is trying to solve problems similar to mine (checking passwords, encrypting files) will benefit from studying algorithm and specification of encryption/decryption process of RNCryptor. Not sure what would cryptography ... 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 ... 0 There is multiple solutions that's more sophisticated than this one. But you could easy authenticate the user if you have a secret that both the server and the client knows. By using the HMAC protocol example: SHA256 ( SHA256 ( data_before_encryption ) + secret ) You create a hash of the the data you are sending before you encrypt it, and then you append ... 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 ... 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 LOL the NSA would have you believe that it is about uncrackable (256). 256 is used for web pages for goodness sake. The real data they care about is topped by at least 240000 bit encryption that is changed very frequently. Lets not forget the public stuff we have that we are appalled by, is what the government has been made far in advance. I done some ... 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 ... 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 The problem with this question is that the question is incomplete. It's like asking the question "should I use a hammer or a screw driver". Without knowing the underlying application and requirements it is impossible to properly answer this question (in fact, the answer may be "tape measure"). Still, ECB and CBC each have their strengths and weaknesses. ... 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 ... 0 An alternative: You talk about text files. If you want the encrypted file to also be a text file, rather than a byte, then you could consider the Vigenère cipher. With a long randomly generated key it can be reasonably secure. If the key is as long as the plaintext file and is only used once, then it becomes a form of One Time Pad. If you want byte-based ... 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 ... 0 A negligible function is one which decreases more rapidly than the inverse of any polynomial. A constant does not decrease at all, hence it is obviously non-negligible. 0 The Wikipedia Article on Post Quantum Cryptography has the following to say about symmetric algorithm quantum resistance: Symmetric Key Quantum Resistance Provided one uses sufficiently large key sizes, the symmetric key cryptographic systems like AES and SNOW 3G are already resistant to attack by a quantum computer.[20] Further, key management ... 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 ... 0 The time of AES encryption/decryption in any of the standard modes like CBC or CTR or GCM is polynomial (more precisely, linear) in the size of the message. Proof: One call to the AES encryption/decryption function takes some constant number of steps, which we can represent with the constant$c\$. For example, AES-128 makes one call to the key schedule to ...

0

why it should strictly be bijective instead of injective or surjective? Actually, it is injective and it is surjective; the term bijective just means that it satisfies both the properties of injectivity and surjectivity. Injective does not mean that there is a 'skip' (that's "not surjective"); instead, it states that no two different inputs give the ...

Top 50 recent answers are included