# Tag Info

0

Typically things would go like this: A generates a random AES key and encrypts it with the public key. A encrypts the file contents using AES GCM and that key. Nonce can be random or even zero if the key is only used once. AAD can be empty unless something else needs to be authenticated with the file. A sends over the encrypted key, the nonce if any, and ...

0

They use a symmetric cipher on top of RSA or ECC because symmetric ciphers are more secure. However if they relied only on symmetric keys they would have to sync each key with a dedicated key server for every account on the network. That would be millions of keys being synced with Diffie-Hellmen at the same time. This would be a DDoS nightmare for traffic ...

0

As per definition, digital certificate is a security document that binds public key to some entity. That is, any X.509 certificate at least contains certificate owner's public key and information about the cert owner. In the case of web site SSL certificate, digital certificate contains web site's public key and information about the site. For CA ...

1

Now when i am validating the certificate do i need to trace back the whole chain to validate the certificate? Not each time, no. You can do some caching, if you like (since root CAs tend to be valid for many years). But I don't think performance gains will be worth the added complexity of the caching idea. Also: if you plan to honor the expiration ...

1

Of course, since the X509 is statically signed, you have to check the signature only once.

2

If Jeff has the public key and an encrypted message, why can't he guess the message, encrypt it with the public key, and see if he gets the encrypted message. Well, that particular attack is foiled by the RSA padding method. All RSA encryption padding methods include randomness in the padding (specifically to foil this attack). Whenever John encrypts ...

3

Generically, this certainly does not work. For example, with RSA, if you take the domain to be ${\mathbb Z}_N^*$ then it's a permutation so is clearly collision resistant but also completely useless. Then, if you take a larger domain, it's trivial to find a collision. For example, take any $x\in{\mathbb Z}_N^*$ and then take $x'=x + N$. It is clear that an ...

1

Your idea violates rule 1. With asymmetric key encryption, it is not difficult to find a message given the encrypted message, if you have the private key. Also, if you randomly generate a number and call it the public key for a hash function, this is diverging significantly from public private keypair generation, which generally relies on finding two ...

4

Provably secure cryptographic hash functions are often built using the same sort of operations as what are used in asymmetric crypto. The major problem with these constructions are that they are very inefficient. Also, a lot of these sorts of constructions have finite input domains. Thus, you have to figure out how to extend it to arbitrary length inputs. ...

2

Well, first of all you forgot one requirement: hashing should be a deterministic procedure (everyone should compute the same hash for the same input) and that one you do not meet with a secure public key encryption scheme. Now you could fix the used randomness to a fixed value. Then I assume you get an inefficient hash function that in theory fulfils all ...

1

What you are actually looking for, which is a way to reuse a one-time pad, is not possible. For OTP reuse to be in any way secure, you need an algorithm with enough "complexity" to be a secure cipher (where the "pad" is actually a key). For example, in the comments you raise the idea of including a random number and using the 8-bit CBC that Richie Frame and ...

1

Elements of finite fields don't really have a sign. But depending on context you can define a property that's different for $x$ and $-x$ (when $x$ is not $0$) and call that property sign. Some possible choices: A number is called a square (or Quadratic residue) if there is another number which produces it when squared. Since positive real numbers are ...

0

In finite fields there are is no distinction between positive and negative numbers. This implies that you also do not have positive or negative points in an elliptic curve over a finite field. But you can nevertheless distinguish the two points by looking at the least significant bit. For instance, this will be used by the point compression method.

1

Yes, the exponent can be any odd value greater than 1. We usually insist on prime values of $e$; why is this? Well, it does make generating key pairs a bit easier. When we generate an RSA key pair, standard practice is to pick a public exponent $e$, and then select primes $p$ and $q$ that work with that $e$. And, by work, I mean that $gcd(e, p-1) = 1$ ...

2

Note that the security notion targeted by MACs is not IND-CCA, but EUF-CMA (Existentially Unforgability against Chosen Message Attacks). You can read the formal definition on page 156 here: https://cseweb.ucsd.edu/~mihir/papers/gb.pdf. Suppose we have a MAC scheme $M =(\mathcal{K}, \mathsf{MAC}, \mathsf{VF})$ which is EUF-CMA secure. Let's create another ...

4

What you are asking is a straight application of Format Preserving Encryption, which builds ciphers which input and output are in a constrained format (generically: common to input and output, hence preserved). The FPE field has many articles with proven techniques; and proposed standards, including BPS and SP800-38G Draft. Note: the method tentatively ...

1

The BV scheme presented in the article works for plaintext messages in $GF(2)$ (that is $m$ $\in$ $\{0,1\}$) but can be extended to support encrypting messages that are in $GF(t)$ where $t$ is prime with the modulus $Z_q$. This means that if you want to encrypt a message in $\{0,1\}^n$ you have to do it for each bit separately in $GF(2)$ (or in $GF(t)$ and ...

2

The exponent and the totient of the modulus should be coprime. (i.e. $\gcd(\varphi(p\cdot q),e)=1$) The easiest way to reduce the chances of them sharing factors is to make the exponent prime. There is a tiny chance that the totient of the modulus will have the exponent as a factor, making them not coprime, but it's a simple check for $\varphi(p\cdot ... 1 It isn't. First of all, RSA is nowadays usually only used for authentication when used in TLS. And authentication is performed using signature generation, not encryption. Sometimes this is called e.g. SHA-256 with RSA encryption but that's a kind of misnomer. Starting with TLS 1.3, RSA encryption will not be used at all anymore. But mainly the client ... 3 Verilog is Turing complete, so you can implement any algorithm in Verilog, if you really want to. 2 Diffusion is a requirement for a secure cipher, but it is not by itself sufficient. So even if a certain number of rounds has "full diffusion", it does not mean that the number of rounds is enough. In the case of Treyfer, the decryption direction requires five more rounds for full diffusion, but the suggested number of rounds is much higher at 32. (Even that ... 0 In general you can't constrain what an attacker can do. If a chosen ciphertext attack or a meet in the middle attack is mounted bad properties of the decryption become relevant. 0 If you encrypt the private say with a 8-char password, the strength of your solution will be not 32 bytes (256 bits), but merely 8 bytes (32 bits). The comment of "user4982" above is correct. Doing your encryption process more complicated does NOT make it more secure. The strength depends only on the length of the secret. In your case it will be the ... 2 It’s tested against many of the test-vectors (key varying, plaintext varying, Monte Carlo), which is the only contract it needs to fulfil... I've got some speed/timing information now: 128 bit, key setup 0.37ms 128 bit, ECB, encryption 0.58ms / block (27.5kB/s) 128 bit, ECB, decryption 0.77ms / block (20.5kB/s) 192 bit, key setup 0.41ms 192 bit, ECB, ... 6 SIV is a mode specially designed for this purpose. SIV-AES would be a good choice, but it has the same issues as AES-wrap; not many implementations. If you use a GCM you should make sure that the IV is unique (if your plaintext is ever not random you would otherwise be in problems). As for the password based key derivation function: yes, PBKDF2 is good, ... 4 There is a simpler way: implement a stream cipher using the hash function, and use that to encrypt the plaintext. Probably the most used stream mode is counter (CTR) mode, which is normally defined for block ciphers. CTR mode works equally well with a PRF (MAC) as with a PRP (block cipher). It only uses the function as a one-way function; with a block ... 0 A full solution is impossible. If the third party is able to verify the validity of tokens, they can brute force through the 10-20 bit token space and generate all valid tokens. So the third party cannot both be able to validate and not be able to forge. The below solution achieves one of the two. Tie each secret key$k_i$to an identifier$i$. Generate ... 2 You are effectively using symmetric encryption. The crypto_box function uses elliptic curve Diffie–Hellman on Curve25519. With a given input private key and public key it always generates the same symmetric key, which is then used for authenticated encryption. By using the private and public key from the same key pair you are generating the point$a^2G$, ... 2 I see 2 options that fit the requirement (small, verifiable within some limit). Because the sizes are small, the probability of the collision of a random value showing linked is high, larger values will obviously help. Option 1 is to have a random value, and encrypt or hash it, then truncate the result and concatenate to the original value. The size of the ... 2 It is no security leak to use the sender's public and private key with that function rather than the receiver's public and the sender's private key. The reason for this is that you're the only person who can decipher the message afterwards. To understand this you need to understand how the keys are used. The inputted secret key is used to sign the ... 1 Create a public/private key pair. Generate a random value and sign it with the private key. Call that the random token. 2 What you're describing sounds a lot like mental poker. That is, your Alice has a number of messages ("cards") that she wants to shuffle and deal to the other players, in such a way that she can prove to the other players that she does not know who got which cards. Various protocols have been proposed for mental poker; see the linked Wikipedia article for ... 9 You really don't want to use ChaCha20 alone in (nearly) any situation. What ChaCha20 does for you is to prevent attackers from (passively) reading your data, which is good. But ChaCha is a so-called stream cipher which works by XOR'ing a pseudorandom pad with the message (your file at rest). However it is for this very way of working that ChaCha doesn't ... 1 Be very aware that "FIPS 140-2 Compliance" is misleading, and usually irrelevant. To be compliant just means that your software uses a FIPS 140-2 Certified cryptographic module, and getting your software certified costs anywhere from$20-200k and takes 6-18 months. Just because your system passes the self-tests and statistical checks mandated by the standard ...

4

For encryption or decryption of data that is encrypted on the fly, you can do that. For data you store you obviously have to use the same decryption, so if you encrypt a huge file using AES, you have to decrypt it using AES, even when on battery power. First thing: If there is hardware support for AES, AES will be faster and using less power almost certain. ...

3

The best solution depends on the details of your application, but I have one comment and one suggestion. First the comment: You say you have AES hardware available. I don't know the details of your platform, but this hardware is likely to be much more efficient in time/power than a software implementation of any reasonable encryption algorithm. You need ...

0

Aside from being pedantic and telling you that you can choose arbitrarily large $d$ in some congruence class, you can always achieve $d\equiv -1 \bmod \phi(pq)$ by choosing $e$ to be the same. So in the interval $[1,\phi(pq)]$ the largest $d$ could be is $\phi(pq)-1$.

3

As you said you are OK with a little bit less security in the more performant algorithm, I suggest Speck for that. It was developed by the NSA, so although some might worry about a backdoor (I personally doubt there is one though I would not know the difference if there were), it probably also means that ordinary people will not break it easily if at all. ...

7

Yes, AES-128 is intended to be the standard block cipher for building a secure and efficient symmetric cryptosystem using some block cipher operating mode, like CTR for encryption or GCM for authenticated encryption; efficiency can be particularly good when there is hardware support for AES and GCM. There might be better choices in the case at hand, like ...

1

I'll be answering the question as in its body, which does not match the title (double encryption implicitly refers to using the same block cipher for each encryption, when the question is explicitly about two block ciphers). With only the hypothesis that $A$ and $B$ are secure block ciphers sharing block size and key size, we can't conclude that the ...

2

The RAR5 archive format encrypts file data using AES in CBC mode, and generates a 256-bit key using PBDKF2-HMAC-SHA256 (32768 iterations default?). If an attacker is able to view many files encrypted this way all with the same key, the attack is to recover the key from the ciphertext. This is not an easy task, even if the IV was reused. In WinRAR, the IV ...

2

I'm assuming that you mean any time the file changes, it is re-encrypted with PGP. Here is a description of how PGP encryption works: Whenever you change the file and re-encrypt with PGP, a new, independent session key is chosen. So what you end up with is a (potentially only slightly) modified file, being encrypted with a brand new session key. All ...

3

No, there isn't. There are too many different systems out there to make a generic tool.

4

If $d$ is a valid RSA decryption exponent, then so is $d \pm k \lambda(pq)$ for any integer $k$. As a corollary, we may always choose the decryption exponent to lie in the range $0 < d < \lambda(pq)$. In fact, there's generally no reason to choose the decryption outside that range: a larger exponent would just make decryption slower, while using a ...

2

Like Ilmari Karonen wrote, you can ensure that nonces picked by two senders do not collide by reserving one bit (like the lowest) to differentiate them. If you use random nonces this is not required, since the probability that a random nonce collides depends only on the total number of nonces generated, not who generates them. In fact, reserving a bit would ...

4

Yes, if the client and the server use the same key to encrypt their messages (instead of having separate keys for client-to-server and server-to-client communication), then you need to ensure that they cannot ever use the same nonce. One way to do that would be to, say, let the client use only even nonce values, and let the server use only odd nonce values. ...

0

If $a_i = c$ for all $i$, then clearly $a_{\pi(i)} = c$ for all $i$ as well, regardless of the permutation $\pi$. Thus, you can choose your two messages $a$ and $b$ such that, say, $a_i = 0$ and $b_i = 1$ for all $i$. This will then also be true for their encryptions under any permutation cipher, allowing you to trivially distinguish the encrypted messages ...

1

Modern computers are quite fast, and modern cryptographic algorithms are quite efficient. Most computers benchmark hardware accelerated AES in CTR mode well above 1GB/s, which would be a fraction of a millisecond for a 100KiB file. Since the standard system timer generally runs at 1ms intervals, the entire encryption operation ([file data] XOR [AES] XOR ...

6

If $m_b$ has size $n_b$ bits, then there are $2^{n_b}$ possible messages $m_b$; and they MUST be all "possible" in the eyes of outsiders (including Carol). Similarly, there are $2^{n_c}$ possible messages $m_c$. Thus, there are $2^{n_b}\times 2^{n_c} = 2^{n_b+n_c}$ possible inputs to your problem. If you have a system that can encrypt all such inputs into a ...

6

In the first part of this answer, I consider the problem of decryption using leaked keys of a protocol not intended for that, which was my original reading of the question. I'll ignore that dominant industry practice is to use random symmetric session keys, leaving little opportunity to "hold a couple of secret keys" without knowing to what session they ...

Top 50 recent answers are included