Tag Info

New answers tagged

0

If your IV is predictable this is as (in)secure as assuming that you have a zero vector IV. And a zero vector IV allows you to perform a so-called Adaptive Chosen Plaintext Attack (ACPA). Why? Assume that you have a encryption mechanism that works in CBC mode. This means, that on the first iteration the $IV$ is XORed with your input message (which is ...


1

In short: does storing these encrypted files in an encrypted partition/folder create the same potential weaknesses as cascade encryption? If not, what of encrypting a .tar of encrypted documents? An encrypted file inside an encrypted container is a cascade of ciphers, almost by definition. Is that a problem? Not really. A cascade of ciphers shouldn't ...


1

Your parameters that you provide are incomplete (in what group are you working?). Anyways, lets assume that you work in $\mathbb{Z}_p^*$, your have a generator $g$ and your public key is $y=g^x$. Then, if two ciphertexts share the same randomness $k$, they will look like $(c_1,c_2)=(g^k,m\cdot y^k)$ and $(c_1',c_2')=(g^k,m'\cdot y^k)$ for your two messages ...


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


2

It'll be the same situation that NY City suffered some days ago: when you have little variability on your data, i.e., they have a fixed-small size, it'll always be fast to brute force. You don't say how long your number is, so I'll assume it can range from 0 - 10,000,000,000 (so, a unique number for each human being on Earth today, plus some spare). You ...


3

The problem is almost exactly the same as in password based key derivation, so you could use a similar solution. Derive a master secret from your password and a unique salt using e.g. PBKDF2 or scrypt: $S_m = PBKDF(p, s)$. Derive a site-specific secret from the master using e.g. HKDF and the site URL: $S_u = HKDF(S_m, u)$. Turn the site secret into a ...


3

If the plaintext format is indeed as you describe, then you're out of luck: the insertion of the newlines and the consequent shifting of the plaintext records is enough to disrupt any structure in the ciphertext. If the plaintext were longer, say, 8 records, then it could work, but with just 7 records there's no way to switch the first and last record ...


-4

Well, DES is weak and since you can guess a plaintext you can use a rainbow table to crack the key and then of course decrypt and re-encrypt the message. Apart from that I don't think you can re-order the blocks to change the first and last line, if you really want to do this specific operation.


4

The reference for this is NIST SP800-38A, especially its appendix B. Basically we consider the IV a binary value of the width of the block cipher (64-bit for DES, 128-bit for AES), and add 1 to that, except for one detail: there is no carry at some application-specified rank, defining the maximum number of blocks that can be enciphered with a single IV; if ...


3

In CTR, you can use any operation which has a full cycle through the space of the IV with the counter. You could use the plus operator like the example: $69dda8455c7dd4254bf353b773304eec + 1 = 69dda8455c7dd4254bf353b773304eed$ To calculate the next value, just again add 1. You could also use a increasing counter and xor it with the original IV: ...


1

Its of course doable. Please be referred to this paper for more details.


3

Well, 32 bits is somewhat short, so one could just try ciphertexts. However, there is a much better attack. Choose M0 arbitrarily, let P be the CBC padding for Headers || CRC || M0, and choose M1 so that CRC( M0 || P || M1 ) = CRC(M0). Submit M0 || P || M1 to be encrypted, truncate the ciphertext to the length of encryptions of M0, and then output the ...


5

Yes, there are several ways in which Mallory could pretend to be Amy. One obvious way, which doesn't even involve Amy herself in any way, would be for Mallory to perform steps 1 and 2 of the protocol normally, as if he were Amy. Then, given Betty's nonce $n_b$, Mallory can start a second, parallel instance of the protocol, again pretending to be Amy, and ...


3

Yes, because Mallory can use Amy and Betty to get any encrypted nonce; Amy and Betty are oracles for Mallory. She just has to send the nonce she has to encrypt to either one of them and they perform the task for her (in another "authentication attempt", using step 1 & 2). Usually you protect against this kind of situation by performing an encryption ...


2

Your idea is no stronger than simply having a common shared password $P_1$ from which the symmetric encryption key is derived. If Alice encrypts a message with Bob's hashed password, even if someone knows the shared password, only Bob can decrypt the message You assumed the hash of Bob's password – $H(B_1)$ – is public, so if Eve knows both it and the ...


0

It is my understanding that a pre-agreed astronomical noise source with a protocol presenting a few sync bytes would do the job. Nobody records enough astronomical noise with telescopes to have a good chance of having recording your source. However: if somebody happened to record it that day, you're sunk.


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


1

In general, you cannot, because padding makes sure the plaintext can always be recovered, so any valid padding method produces equally valid plaintext. For instance, suppose the last (decrypted) block is, in hexadecimal notation: 01:02:03:04:05:06:07:08:09:0A:0B:0C:0D:FF:00:00 The "natural" interpretation is that the padding method here might be "add an ...


3

GMAC is quite simply GCM mode where all data is supplied as AAD (or additional authenticated data), or as NIST SP 800-38D puts it: If the GCM input is restricted to data that is not to be encrypted, the resulting specialization of GCM, called GMAC, is simply an authentication mode on the input data. If you don't have access to a cryptographic provider ...


0

It doesn't work without further restrictions. For simplification, let's assume Alice encrypts a bunch of files but doesn't have to send all of them to Bob. She can still decide to re-order the files or leave out some. Then she can encode the secret shared key between Alice and Bob in the least significant bits of the ciphertexts without changing the files. ...


0

What you want is a protocol where Alice sends a message to Bob without being able to control any ciphertext bits. This would be possible if either The message and encryption are completely deterministic and give Alice no freedom to choose between two ciphertexts, or Alice is unable to predict the ciphertext without sending a message. The first could be ...


3

The basic flaw is the same as indentified in this answer I linked in comments: If you know the plaintext for block $i$, you can derive the key for that block and then derive the rest of the keystream from that key. Thus, an attacker can simply make guesses on the message until they find one that allows them to decrypt the rest of the message. A better ...


2

Here is my take on your algorithm. I'll try to perform the known plaintext attack. Knowing the plaintext allows to recover the keystream (passphrase) by simply XORing it. This in turn reveals the value of hash(hash(text) XOR hash(password)) -- simply the first hash block, and the value of hash(text) is known (by virtue of KPA plus it is leaked by your ...


2

Depends on your security requirements. Basically it is OK to create a (slow!) stream cipher using a secure hash method, given that the password has a large enough security margin. But your code has at least the following issues: you leak enough information in the first block to regenerate the key stream from a known plaintext (thanks otus); you have to ...


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


2

This is a bit contrived, because you have given the correct answer to your test: WHATANICEDAYTODAY was the plain text and the key is crypto. However, it shows one way to attack a short Vigenère cipher, where you have a message only a few times longer than the key. I made the following assumptions: Plain text was a short English text The key was a ...


2

For breaking a Vigenere cipher by frequency analysis the length of the cipher text alone is not the crucial part. What really matters is the proportion cipher_text_len/key_len, as this indicates how many characters of the clear text are encoded by the same character of the key. For the example you provided this proportion is below 3. Frequency analysis ...


2

What you are looking to do can be done, but if you expect it to just work, you are mistaken. Performing the calculation of the inverse here is the easy part, the hard part is the choice of affine transform polynomial and vector, as incorrect choice will lead to an insecure s-box. Multiplicative Inverse The most simple method of calculating the inverse is ...


2

If the message is shorter than the key, then the Vigenere cipher is essentially the one-time pad, which is unbreakable for a random key. If the key is not random, then you may get some information on the plaintext.


1

Put another way, you can say that the key is whatever information the recipient possesses which allows him to decrypt the message, and which must be kept secret from everybody else. Thus, "algorithm" and "key" are not mutually exclusive: if knowledge of the algorithm allows one to decrypt a message, then the algorithm is the key.


2

Picking up what has been said in the comments: to simplify: symmetric ciphers are like mathematical operations with 2 operands and 1 result. There is The plaintext message $m$ and $k$ as the key and they result in the ciphertext $c$. In your example, the algorithm can be cut down to a addition and modulo: $c = (m + k) \mod k_{max}$ And of course there is ...


1

In practice, one can use openssl to extract the information: $ cat pubkey.txt -----BEGIN PUBLIC KEY----- MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCqGKukO1De7zhZj6+H0qtjTkVxwTCpvKe4eCZ0 FPqri0cb2JZfXJ/DgYSF6vUpwmJG8wVQZKjeGcjDOL5UlsuusFncCzWBQ7RKNUSesmQRMSGkVb1/ 3j+skZ6UtW+5u09lHNsj6tQ51s1SPrCBkedbNf0Tp0GbMJDyR4e9T04ZZwIDAQAB -----END PUBLIC KEY----- $ openssl ...


1

RSA key formats are defined in at least RFC 3447 and RFC 5280. The format is based on ASN.1 and includes more than just the raw modulus and exponent. If you decode the base 64 encoded ASN.1, you will find some wrapping (like an object identifier) as well as an internal ASN.1 bitstring, which decodes as: ( ...


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


2

I've found an answer to my question, I'm going to post it because it can be useful to someone out there. The point is that, if we assume that $\mbox{Prob}[\mbox{Priv}_{\mathcal{A},\Pi}^{\mbox{eav}}(n)=1]\leq 1/2+negl(n)$, then $\mbox{Prob}[\mbox{Priv}_{\mathcal{A},\Pi}^{\mbox{eav}}(n)=0]\leq 1/2+negl(n)$ too (if this were not to happen, then we could create ...



Top 50 recent answers are included