# Tag Info

0

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

1

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

2

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.

2

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

-1

It exists, but not in a usable form. Generate keys from oblique and unique references to unpopular trashy novels. They fade rather quickly. A machine attack can cover the whole space too fast though.

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

2

If flawed can someone please crack the message within the quotes as proof. "Hlont, iutgrcuxnewmova xn topdoqj akmy nthscuwros." Hello, congratulations on solving this encryption. Took < 1 second in Ruby. Basically it is far too easy to brute-force due to your very small key space, as explained in otus' answer. All I did was translate your decrypt ...

4

Assuming the digits of $\pi$ are pseudorandom (which hasn't been proven), you could construct a cipher from it. However: Your numbers are way too small to be secure. You seem to be adding a decimal digit to the letter, which means the ciphertext leaks more than half the bits: you know 'j' was one of 'a'...'j' originally. You only handle lower case letters ...

1

You need to know Key, IV, Padding and Operation Mode. Then you have to try all possible algorithms. Without that (most likely very secret) information (Key, IV, Padding and Operation Mode) this is even more complex and hard to achieve than a know-plaintext attack. To sum it up: its impossible. EDIT: As said, you can close the possibilities in. But you will ...

1

Here is the deal. You can do this pretty easily in SQL. Exactly how is off-topic on this site. I'd suggest one of the other SE sites. Maybe StackOverflow or DBA. That said, I am writing this as an answer for a reason. My reason is to persuade you to not do it. Here is why, it gives your customers a false sense of security. Your approach to doing the join ...

6

To make it easier for humans to read.

9

I try to provide a brief intro. ABE Attribute-based encryption (ABE) is a relatively recent approach that reconsiders the concept of public-key cryptography. In traditional public-key cryptography, a message is encrypted for a specific receiver using the receiver’s public-key. Identity-based cryptography and in particular identity-based encryption (IBE) ...

3

I don't think this scheme would make sense, either from a performance or a crypto-design perspective. From a crypto-design perspective, simply encrypting with a block cipher would be better. Encrypting with a block cipher, or other suitable symmetric-key encryption scheme, takes running time that is linear in the length of the data to be encrypted (not ...

5

The purpose of the reconstruction of the polynomial $P(x)$, is just to calculate the value of $P(0)$, which equals the shared secret value. If Lagrange polynomials are used, a trivial optimization which cuts the number of multiplication nearly in half is P(0) = (\prod_{i=0}^{n-1}{-x_i})\sum_{i=0}^{n-1}{{\frac{y_i}{-x_i (\prod_{j=0,j\neq ...

0

If you trust all the participants to behave (semi-)honestly, here is another scheme that can be used and is a bit simpler. The basic idea is: The $n$ participants jointly generate a random number $y$ from the desired range (e.g., $[0..x]$). They publish $y$ amongst themselves. Now they each have a chance to veto that choice of $y$. Each participant ...

1

Yes, this should be solvable and should be doable in a reasonable amount of computation time, using a pretty cool homomorphic cryptosystem. Here is one approach: the participants jointly pick a random number $y$, publicly commit to $y$, and then they all prove/check in zero knowledge that $y$ is different from their numbers. If it isn't, they go back to ...

Top 50 recent answers are included