# Tag Info

## New answers tagged encryption

1

The answer is: Why do the encrypted files always start with "Salted__" ("U2FsdGVkX1" in base64)? Isn't giving away information like this insecure? The encrypted files must always start with "Salted_" to interoperate with OpenSSL. OpenSSL expects this. The 8 bytes that spell "Salted_" are always immediately followed by another random 8 bytes of salt. ...

2

Regarding GCM mode and the uniqueness of the nonce, it should be noted that EAX mode and OCB mode also require unique nonces. One potential problem EAX mode has, which neither GCM or CCM have, is that it is hard to implement it in such way that you can guarantee that the probability of nonce collisions is zero; only that it is acceptably low. OCB mode has ...

5

This is a special case of the affine cipher where $m=26$. Let's encrypt a single letter using your $E$. Let it be m, say, which is at index 12. So, $$E(12) = (7 \cdot 12 + 10) \mod{26} = 16$$ Now if we try to use the $D$ in your question, we decrypt this as: $$D(16) = (7 \cdot 16 - 10) \mod{26} = 24$$ which is obviously not right. The issue is that your ...

1

AES is a family of three pairs of functions that use essentially the same mechanisms with different tuning parameters: AES-128 encryption and decryption, AES-192 encryption and decryption, and AES-256 encryption and decryption. Each of these functions takes an $n$-bit key (where $n$ is 128, 192 or 256 depending on whether the function is AES-128, AES-192 or ...

1

Important note: If you need something that provides some real security, it would be unwise to design it and implement it from basic building blocks like this. Instead, use software that has been built to a specification, thoroughly analyzed by experts, and thoroughly tested. If, on the other hand, you are interested in learning about cryptography, then read ...

1

AES is a block cipher, a cryptographic primitive. It has no involvement with key derivation or anything of that nature. The three standard key sizes are 128 bit, 192 bit, and 256 bit. How you get those keys is beyond the purview of AES, which is concerned only with encryption. As I said, it is a cryptographic primitive, meaning it is meant to be used in a ...

1

I assume that $m = pq$ (85) is the modulus, and the number you computed (64) is $\phi(m)$. Now we must choose the exponents ($i$ for public, $j$ for secret? , weird notation) in such a way that $ij = 1$ modulo $\phi(m)$. In fact we can work modulo 16 if we like, because that is the least common multiple of $p-1$ and $q-1$. So if we choose $i = 3$, we choose ...

2

I see three kinds of weaknesses here. The need for padding is not an implementation weakness but an algorithmic weakness. RSA is not an encryption algorithm nor a signature algorithm; RSA-OAEP and RSA-PSS are. It's easy to avoid algorithmic weaknesses: stick to approved algorithms, i.e. OAEP and PSS from PKCS#1 v2. If required for interoperability, you can ...

0

As @Reid mentioned, the HAC is a good starting point. I'd also use Google Scholar to search for papers containing RSA attacks, then follow papers that have many references. Asking about implementation attacks is an overly broad question. There have been a lot of attacks on systems that depend on RSA that have been successful, but most of those weren't ...

4

It depends on what you are using RSA for and how deep of an understanding you would like. A sort of general overview of RSA and potential attacks against textbook RSA is presented in the Handbook of Applied Cryptography, specifically chapter 8. (Note that the entire text is free online.) Chapters 11 and 12 also are useful to read, as they focus on specific ...

3

An RSA ciphertext won't reveal who it is encrypted to, but it might reveal some information about who it isn't. We'll assume that everyone has an RSA key of the same length (e.g. 2048 bits). Now, a public key consists of a large modulus N (and an exponent, that's not important for this discussion); a ciphertext consists of a value C between 0 and N-1. ...

0

You need to use Searchable Encryption techniques if Deterministic encryption is not for you . Is it possible to match encrypted documents using user-defined search terms?

1

You can use a deterministic encryption scheme (which doesn't achieve perfect secrecy by its definition of encrypting two equal plaintexts into the same ciphertexts) as is defined for deduplication: You hash the ip address. $H(ip)$ You encrypt using the key $H(H(ip))$ Anyone now cannot see the ip address that he packet comes from but can determine if are ...

0

Comparing data sets can also be done using "order preserving Encryption" techniques

6

Perfect secrecy is achievable in a few cases, such as one-time pads, and, well, that's pretty much it. Most cryptographic protocols are vulnerable to an all-powerful, all-knowing attacker. If you do not put any restriction on what the attacker can do, then Guess the key. Profit. breaks almost any cryptography, as does Wave a magic wand. Profit. So at ...

2

As already mentioned by fgrieu in a comment, you seem to be mixing up the initialization vector for the cipher with the salt for the key derivation. They play similar roles — both are here to insure that different values of the IV/salt lead to different keys/ciphertext — but they are used in different ways and they have different security properties in this ...

7

There's no need for an IV when unique keys are used. When each key is used only to encipher a single message, it is safe (from a confidentiality standpoint) to use null IV for all messages. That's customary, for all common modes requiring an IV. It avoids the need to generate an IV, and transmit it, and (in the case of CBC) perform a XOR of the first block ...

1

Henno's explanation is only true of CBC mode. In CTR, the nonce for each block is generated entirely independently of the keystream. That said, the answer is bears stating clearly without complication from unncessary specifics: There is absolutely no requirement that an IV be kept secret. The IV may be (and frequently is) sent in the clear ...

3

If the requirement is being able to reconstruct a message of $1280=160\cdot 8$ bits from $3$ parts that are among a set of $2^6$ type-able characters (say $10$ digits, $26$ uppercase letters, $26$ lowercase letters, and $2$ other characters, as in Base64), then no cryptography is required. Simply: split the $1280$ bits of the message into $3$ nearly ...

2

Keeping the (initial) IV secret only adds security for the first block of your cipher text. The IV for the second block is by definition the first cipher text block, and so on. So if we would have the key but not the initial IV, we could decrypt the whole ciphertext except the first block. So it doesn't add much security, but it does add "management", as you ...

7

In practice, asymmetric algorithms like RSA are usually used for key transport. In other words, instead of a true message, they are used to encrypt a secret key for a symmetric cipher. That symmetric cipher key is used to encrypt the actual message, and that could be gigabytes, depending on the algorithm. Standards like TLS, PGP, and S/MIME use RSA in ...

0

The normal way to encrypt larger data blocks is to use a symmetric crypto algorithm to encrypt the actual data, and then encrypt the symmetric key using RSA.

0

RSA is typcially used for a Symmetric Key Exchange, so most cases dont need more bytes. You can,however repeat the encryption for each block of the message.

1

I have opted to generate a random IV but store this in the front of the encrypted file. I can then pull this and use it to recreate/generate the Rijndael key to decrypt the file. In testing this create a new and completely random Cipher Block each time.

0

Maybe not exactly what you want, but an interesting idea nonetheless: http://passwordmaker.org/ It makes a password for a website from the master password + the website URL, passing this through a hash function. It comes with autocomplete extensions for major browsers. This eliminates the need to store the passwords, since they can be generated on the fly. ...

2

I ended up with the following solution: For each email store two values: encrypted email and signature for the email. For encryption I used AES in CBC mode with random IV. For signing I used HMAC SHA256. The keys used for encryption and for signing are different. Later on I found the following link: docs.oracle.com. So looks like this is pretty standard ...

0

You asked several questions above. I will address one in specific that stands out to me, and that is your question about XORing the keys together. Your statement that they might both have the same character at the same location that would yield a null byte is disconcerting: passwords are not normally used directly as encryption keys. Mathematically, a ...

0

To simply decrypt the data, the keys that were used to encrypt it are all you need. However without the MAC keys you won't be able to verify the integrity of a message, so you won't be able to tell if the data you have decrypted is the same as what was sent (or even who sent it). If you're debugging on a trusted local network then that might not be too ...

2

This is a bilinear pairing used in cryptography. More precisely it's an evaluation of an appropriate pairing friendly elliptic curve equation.(1,2,3,4,5)

0

To begin with, some essential requirements are missing from your question at the time I write this, so I am going to assume: $User$ trusts $System$. $System$ trusts that $User$ will not pass $Key_{User}$ to any entity that $User$ does not trust to be $System$. This implies, in particular: $System$ is already authenticated to $User$, and $User$ ...

0

Hash the two keys, and use the result as your symmetric key for encryption. Example: compute the encryption key as $K = \text{SHA256}(\text{len}(k_1) || k_1 || k_2)$, where $k_1,k_2$ are the two key parts provided as input. Then, encrypt the message using key $K$ using a standard scheme (e.g., an authenticated encryption scheme like EAX or AES-GCM).

Top 50 recent answers are included