# Tag Info

14

Both of the other answers tackle the question of encryption in a particular format, but I would argue that neither of them is necessarily a good fit for your use case. You want to be able to generate 20 character codes that a server will be able to verify. A symmetric MAC is sufficient for this use case, if you don't need the codes to contain any secret ...

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

7

Mathematically speaking, there is no upper bound on the private exponent in RSA: assuming $d$ is a valid private exponent, then the valid exponents are the set of $d'=d+k\cdot\lambda(p\cdot q)$ with $k\in\mathbb Z$, where $\lambda(p\cdot q)=\operatorname{lcm}(p-1,q-1)$ since $p$ and $q$ are distinct primes; this set is unbounded. If you compute $d$ as an ...

7

What you are asking is a straight application for 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. Specifically, it looks like ...

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

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

6

No, you generally cannot swap the public and private keys. Your public key consists of a public exponent and a modulus. The modulus should be known to the person doing the encryption. The public exponent - in general - is a relatively small prime such as 3 or 65537 (Fourth number of Fermat). So given the modulus all an attacker has to do is guess the public ...

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

You should use AES. If you have the AES-NI instruction (which most modern chips have), then this performs very fast. For most applications today, AES-128 is certainly sufficient. However, I want to stress that it's not just the algorithm, it's also the mode of operation. You should use GCM. If you use OpenSSL then with AES-128-GCM you'll get speeds of about ...

4

I am assuming that you wish to consider this for standard encryption tasks, and I am going to ignore the specific reference to AES and talk about general block ciphers (pseudorandom permutations). The answer is that small block sizes are very problematic. In particular, they break when used for encryption of any reasonable amount of information. I will ...

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

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

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

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

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

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

3

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

3

Given a scenario, e.g. my Dropbox was hacked, and the hacker has access to my EncFS encrypted texts, and probably the history of it as well. Is that what was mentioned as "two or more snapshots" and "different times"? Whether it applies depends on how the storage system would work. As far as I can tell, EncFS itself has no backup/versioning capability. ...

3

The answer is yes. There is no problem with sending the IV in the clear. So, this is fine. Likewise, the salt is not there to add entropy so this is also fine. Having said that, I understand from the code that the application is not using a uniformly distributed (and so high entropy) key. This is a problem and very bad, since it is easy to carry out a ...

3

For a block cipher A block cipher is a PRP, a Pseudo Random Permutation. That is: given a key it generates a permutation of all possible plaintext blocks to all possible ciphertext blocks. So there is a bijection between each plaintext block and each ciphertext block, i.e. each possible plaintext block is assigned its own ciphertext block. So there is a 1: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. ...

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

3

Verilog is Turing complete, so you can implement any algorithm in Verilog, if you really want to.

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

2

Enciphering data using AES and moving that to a card without effective security is not enough to solve some very real security issues; including most preeminently the possibility of returning a prepaid card to its original state, re-crediting it after use (an adversary can copy the original enciphered data, and save it for future use when the genuine card ...

2

Based on the clarifications in the comments, what you are looking for is a block cipher over 100 bits. This will enable you to Base32 encode into a 20 byte string, and to decrypt as well. Note that encrypting directly with a block cipher is in general not secure. However, I assume that with promo codes you will always encrypt a unique plaintext. If this ...

2

Also, if I give people the private key, and I keep the public key safe, am I right in believing that it's possible to generate a new public key just using the private key itself? Correct. The private key contains the modulus, one or more of the primes, the private exponent and often some other relevant things. The public key is just the modulus and the ...

2

The schemas from the relevant Wikipedia page really explain it all: As you see in the decryption schema, the IV is used for a single XOR that yields the first plaintext block; it is obvious that the IV impacts only that block. When encrypting, though, modifying the IV alters the first ciphertext block, then the second ciphertext block, and so on. The ...

2

The scenario you're facing is well-known in cryptography. You can't afford expanding the message at all (maybe by some IV). So you can't get strong authentication but have to rely on what is called poor man's authentication, you rely on tampering causing random messages. Please note that all of the following modes are somewhat block-based, meaning you'd ...

Only top voted, non community-wiki answers of a minimum length are eligible