# Tag Info

1

Functional encryption might fit your description; as far as I know it's still far from practical though.

0

No, it is not possible. The encryption step of CBC is $c_i = E(c_{i-1} \oplus p_i)$. When you double encrypt, the previous block ciphertext gets XORed with an independent block cipher output. The only place where something weird could happen is the beginning. If you assume that the (identical) IV $I$ is prepended to the ciphertext, as is common, you get ...

0

This illustrates the importance of getting the key order right with 3DES two-key keying option. With the correct order of $k_1$, $k_2$, $k_1$ you get something that should be impossible to attack with current resources, while with the incorrect order in the question it is feasible to attack. The outer two encryption layers can be joined into a single ...

1

I don't have enough space to expand on yyyyyyy's answer in a comment so I am making this an answer in and of itself. TruthSerum is correct, but it seems like an explanation is wanted, so here goes. Imagine you have a regular (all the sides have the same length, all the angles are the same) n-gon. That sounds complex, but trust me it isn't. A 4-gon is ...

3

So my question is, if they are the ones who encrypt this, then why can't they also decrypt it? Because it’s not them encrypting your message, it’s the App on your device… which is why it’s called End-To-End encryption. According to the security whitepaper (PDF), WhatsApp uses the Noise Protocol Framework which is based on the Signal protocol (formerly ...

2

Scheme is not IND-CPA for any message longer than one block. I'll include a image of CBC mode below for reference (Source: Wikipedia). Suppose instead of block cipher encryption we have plaintext xor-ed with the key as you propose. You'll note that for message block 1, $M_1$, the ciphertext block $C_1 = M_1 \oplus IV \oplus Key$. Similarly $C_2 = M_2 ... 1 I haven't looked at watsapp specifically, this is a general answer on the practicalities of this. It's possible to have end to end encryption where the private key never leaves the client. If the provider doesn't have the private key then they can't decrypt the traffic. There are two problems though. Can alice and bob trust the client to do what it says ... 0 The EFF Secure Messaging Score Card uses a checkmark system to rate different communications products. WhatsApp gets only 6 of 7 checkmarks. It gets an X in the "Is the code open to independent review?" category. 1 Since the client is not open source, you cannot verify their statement. That is, it could very well be encrypted but in a way that would allow either WhatsApp or another third party to break the security. To verify that it does encrypt data, you could use tools like WireShark to see whether text messages are sent in plain or encoded/encrypted. Bottom line: ... 1 In a sense, I don't think it matters. It's probably realistic for average users who aren't under direct investigation by a government for high-level drug-, terrorism-, or leak-related offenses. If you have reason to suspect you may fall under one of those categories, it's in your best interest not to trust that WhatsApp isn't capable or can't be compelled ... 2 If you ask about the protocol itself, as a theoretical construct, then it is safe. In theory it indeed provides all the feature that it promises. And now for the "but..." part. When you use a protocol to communicate, you are actually using one implementation of the protocol. The implementation tries to do exactly what the protocol says. However you can ... 2 I would not consider your case to be a cascading encryption. The reason why is the fact you need multiple interventions before getting access to your file. Here is what I would consider a cascading encryption (let's go crazy) : $$E(k_1,k_2,k_3,m) = \text{KEYAK}(k_1,\text{NORX}(k_2,\text{AES}(k_3,m)))$$ which you would decipher with : ... 0 You can try Playfair Cipher and find implementation here. 4 No, it is not possible to semi-reliably "decrypt" an encrypted message by using the statistical distribution of symbols, if some modern encryption scheme is used, and its secret/private key does not leak. Modern encryption is practically immune to known distribution or other characteristic in the plaintext. The goal of modern encryption, that it reaches in ... 3 There are some works both theoretical and practical that they do solve your problem efficiently and in a secure way. By efficiently i mean the search efficiency is linear on the size of the searched substring. This is achieved by using auxiliary data structures known as suffix tree. Chase and Shen follow this approach, by encrypting the suffix tree with ... 3 I am afraid you are a little early: searchable encryption is quite a new field in cryptography, and I am not sure there exists any good implementation yet. However, answers to this question suggest cryptdb Also, I do not think the Rabin-Karp Algorithm is easily transposable to searchable encryption. I believe it has many optimisations, which could conflict ... -1 $$2360221=1117 \times 2113$$ $$\phi(2360221)=2356992$$ $$d\equiv e^{-1} \equiv 942797 \pmod{2356992}$$ $$C \equiv M^e \equiv 1637411 \pmod{2360221}$$ 0 Filecoder.Q ransomware used one of three encryption algorithms: XOR ,Tiny Encryption Algorithm(TEA) and AES,but this ransomware does not encrypt beginning of the files so in your picture beginning of original and locked file are equal.if this ransomware uses XOR Algorithm then you can decrypt locked file with XORing original file and locked file(key ... 1 This depends on the level of authenticity you want to provide with your system. A lot of public petition systems do not enforce authenticity of petitioners at all. Basically, anyone can submit a petition in behalf of their neighbor, for example, simply by introducing relatively public info about them (name, address, ID number, etc). In this case, public-key ... 0 A solution from the top of my head: Bob will end the server$(Enc(m), h(m))$where$h$is a collision resistant hash. Now, Bob will interact with the server and provide a zero-knowledge proof that$m$is the same one in$Enc(m)$and$h(m)$. We note that this verification is in NP (the certificate for the verification is the key used to encrypt$m$). ... 2 I'll assume R is secret, and is the key; and the ciphertext is given as a list of values x in decimal, as in the example given x = 0.559425856. This is totally insecure: even without knowledge of R, it is trivial to reduce candidate plaintext letters to almost nothing, just by knowing the corresponding x. e.g. if we assume R is an integer in range ... 0 If Bob attaches a digital signature to the encrypted message, and the server knows Bob's public key for the digital signature, The server would know that it is Bob who sent the message. For decrypting the message, if an algorithm such as aes or des is used, the user is able to decrypt the message with any key, although the decrypted message will probably be ... 4 Basically, this part of the paper aims at proving that, as long as the approximate GCD problem is hard, the DGHV scheme is "secure". So, as it is standard in reduction proofs, you go and prove the contrapositive: you show that if there exists an adversary$\mathcal{A}$that is able to break the DGHV scheme, then there exist an adversary$\mathcal{B}$that ... 0 The security - assuming you can validate the correctness of$K$- is 56 bits (not even counting any attacks on DES itself, assuming to test all keys). This is because you can brute force$K_{BT}$without even looking at$K_{AT}$in your particular scheme. 2 key triple DES on the other hand would at least offer over 80 bit security. So this scheme is ... 2 You should read this article about Security of DGHV Encryption. Oracle machine is an abstract machine used to study decision problems. It can be visualized as a Turing machine with a black box, called an oracle, which is able to decide certain decision problems in a single operation. The problem can be of any complexity class. Even undecidable problems, ... 1 Yes, GPG (a.k.a. PGP) or S/MIME. For additional security, you may also want to use a PGP smartcard and generate your encryption keys in the PGP smartcard. This way, even you don't know your own private key and can't accidentally leak your private key. The only way to leak private key with PGP smartcard is if you lose your card or if there's a vulnerability ... 5 Well, that's simple:$2^{64}/2^{30}$is indeed correct. And since$2^{64}/2^{30} = 2^{64 - 30} = 2^{34}$then that would be the answer. A simple recalculation would give you approximately 545 years. As you can see, 64 bits is pretty much on the border of being cracked by general computers. Brute force basically scales linearly with the amount of keys. ... 0 If we suppose the world where this is interesting again, where say AES and kind has fallen to a currently unknown attack, then even so Red has to be stupid to fall for it. We shall consider two cases of defense: In case A, almost all ciphers can be strengthened by weaving in another cipher with its own key. The cipher doesn't have to be all that strong of ... 0 Add the two numbers, and keep only the lower 4 digits. To reverse, add 10000 then subtract the second number and keep only the lower 4 digits again. Works like a charm. 1 We solved this problem in just 9 hours 37 minutes. Here is how to do it. Tools you need: sudo apt-get install cryptsetup sudo apt-get install dh-autoreconf sudo apt-get install libcryptsetup-dev 1 - Dump the encryption header of your device using cryptsetup toolset, here /dev/sda1 was our device yours could change: sudo cryptsetup luksHeaderBackup ... 1 It would be impossible i think. But if you consider evolving the encrypion system such as changing pair like : "he","el","ll","lo","o" it would be way to easy to decrypt. 6 In my own knowledge, encrypted data can't be decrypted without knowing the key, but BitLocker breaks it. That description indicates you might have misunderstood something there. Bitlocker does not break anything* as Microsoft BitLocker uses recovery keys (read again: “keys”), not code! The related code for recovery is pretty similar to the usual ... 1 To my current knowledge, the content of a Zip 2.0 file is likely safe for a week, assuming the password has large entropy (>95 bits; 16 random characters among uppercase, lowercase and digits qualify, and will work with most pkzip-2-crypto-compatible unarchivers); with 64 bits, I would not bet the house against a determined adversary with a large FPGA (or ... 0 The PKZIP legacy encryption is a stream cipher with a 96-bit state. From this answer about the possibility of brute forcing an encrypted archive Baring hypothesis change or progress in some of the above, it is inconceivable that the original file data can be recovered from the archive using anything remotely comparable to the computing effort that a GPU ... 8 The "hard part" about GCM implementation is resistance to side-channel attacks, especially cached-based. GCM is the combination of AES-CTR, and a custom MAC that relies on multiplications in a binary field (GF(2128)). Efficient implementation of that operation classically uses tables, which can lead to cache-timing attacks because the accessed table slots ... 2 There are different arguments going on and there is some context guessing involved on part. The argument to stay using CTR+HMAC seems to be, basically: Never change a running system (without the need to). The security of CTR+HMAC is fine per se. If you have a good, working implementation and the computatational complexity is not biting you, you ... 1 I just stumbled on http://www.tomshardware.com/reviews/password-recovery-gpu,2945-5.html. Although it's a bit old, it does give me some perspective. It mentions ~30 million password tries per second on a Zip 2.0 file. So if someone had a that can perform 10 times as much tries per second, they would need (6^5)^5 / 300 000 000 = ~94767626766 seconds = ~3000 ... 0 While an eight digit search space is easily iterated, the default settings for LUKS/cryptsetup use a password hash that takes 1s to compute (PBKDF2-SHA1 with iterations chosen to reach that time). That means a brute force of eight digits would take$10^8/60/60/24$days or over three years on that hardware. If you assume a GPU is ten times as fast, you will ... 0 I would explore the GPU option before spending money on specialized hardware. I have done something similar using CUDA where I was doing many ECC operations in parallel. The GPU was about 30x - 50x faster than the CPU. You could probably hash the data on the CPU and then use the GPU for the RSA exponentiation. 0 [Copy of my answer in another community:] In the RC6 specification (see de.wikipedia.org/wiki/RC6) S[*] designates an array of 2r+4 round keys, whose size in bits you can choose in the range [0,2000]. It is not an array of 2r+4 elements (each a word of 4 bytes). 1 The "XOR cipher" described does not encrypt more than the first block, even if you do not reuse keys. The subsequent blocks can be "decrypted" by the attacker simply by undoing the XOR – there is no secret involved. Decrypting the first block and finding the key does require more than one message. It is a case of the many-time pad and can be solved either ... 3 I will give you the simplified answer. The public key encryption does not prevent adversery from computing private key from public key. It just makes it very very very hard. The algorithms use math that allows simple private->public calculation, but public->private has no good mathematical "shortcuts". It would take adversery more time to calculate this, ... 5 No, A is not true. Suppose that$G_1$is a secure PRG and$G_2(s) = G_1(s) \oplus 1$, obviously$G_2 \neq G_1$and$G_2$is a secure PRG. You can see that$G(s) = G_1(s) \oplus G_2(s) = G_1(s) \oplus G_1(s) \oplus 1 = 1$which is obviously not a secure PRG. Now you have a hint. You should think the rest of the problems. 4 Does such an entity exist? No, not really. There isn't any organizations who's in the business of doing public cryptanalysis, and there certainly aren't any organizations that are sufficiently trusted for the cryptographical community to say "we know algorithm X is secure - organization Y said so". Let's go through the likely suspects: NSA (and ... 2 No, you're not weakening your data in that case. You could even use ECB in to encrypt random data. Symmetric key wrapping often just uses ECB. But beware that it depends on how many bytes you encrypt. You may want to make sure all bytes are random (if you know the plaintext size in advance). Think about encrypting a single random byte and filling the rest ... 4 If the value$x$is in the set$\{0, 1, 2, .., p-1\}$, which is the "natural" set of residues moduli$p$, then, you just have to check if$x$is greater than$\frac{p}{2}$and if so, subtract$p$. If$x$does not belong to$\{0, 1, 2, .., p-1\}$, then you can first do the usual modular reduction to transform$x$in a element of this set and then, do the ... 0 Expand the key using a pseudo random generator and then add each digit mod 10 together, similar to Vigenère cipher and OTP. 0 For a prime number p, the cardinality of finite field Fp is #$F_p\;= \;p$, and$F_p=\{0,1,\cdots,p-1\}$. To define positive and negative number in$F_p$by convention negative elements are those with most significant bit msb=1. Then with this convention, there are$\frac{p-1}{2}$negative numbers and$\frac{p+1}{2}$positive numbers!$F_p=[-\frac{p-1}{2}, ...

3

In general you want to treat primitives like block ciphers as black boxes. You first analyze and try to break the block cipher. Once it is proven to operate correctly you can use it as primitive for a block cipher mode of operation. The mode of operation can then be proven to be secure assuming that the block cipher primitive operates well. If you don't ...

14

Your punctuation is slightly off: What's in a name? A rose by any other name would smell as sweet. It's a reference to Romeo and Juliet

Top 50 recent answers are included