130
In the first decade of the 21st century, and counting, on a given $\text{year}$, no RSA key bigger than $(\text{year} - 2000) \cdot 32 + 512$ bits has been openly factored other than by exploitation of a flaw of the key generator (a pitfall observed in poorly implemented devices including Smart Cards). This linear estimate of academic factoring progress ...
42
The actual encryption algorithm is almost the same between all variants of AES. They all take a 128-bit block and apply a sequence of identical "rounds", each of which consists of some linear and non-linear shuffling steps. Between the rounds, a round key is applied (by XOR), also before the first and after the last round.
The differences are:
The longer ...
40
TL;DR: no longer unconditionally.
As of 25 September 2018, the Bitcoin miners hashed at an aggregate rate of $\approx60 \cdot10^{18}H/s$ according to this source, where one hash is two nested SHA-256; that is $\approx2^{91.6}$ SHA-256 per year. That's been bitcoin's "peak hash" so far.
Here is this data redrawn in SHA-256 per year with a $\log_2$ vertical ...
39
Those appear to be based on the complexity of the General Number Field Sieve, one of the fastest (if not the fastest) classical factoring algorithms. I confirmed this in Mathematica.
Here is the complexity for the GNFS (source):
$$\exp\left( \left(\sqrt[3]{\frac{64}{9}} + o(1)\right)(\ln n)^{\frac{1}{3}}(\ln \ln n)^{\frac{2}{3}}\right)$$
where $n$ is a ...
29
You might want to look at NIST SP800-57, section 5.2. As of 2011, new RSA keys generated by unclassified applications used by the U.S. Federal Government, should have a moduli of at least bit size 2048, equivalent to 112 bits of security. If you are not asking on behalf of the U.S. Federal Government, or a supplier of unclassified software applications to ...
23
First of all, I'm no expert in this area. Generally $n$ bit ECC seems to have a security level of about $n/2$, but I found some claims that it's lower for certain types of curves.
RFC4492 - Elliptic Curve Cryptography (ECC) Cipher Suites contains the following table:
for Transport Layer Security (TLS)
Symmetric | ECC | ...
22
Examining his claims about "Thundercloud":
You can use it with "any existing software, operating system, or device" (a massive amount of effort---by whom?)
Has its "own cryptographic language that is completely independent of any existing security technology" (this is a negative thing: abandoning the entire knowledge base of cryptography is incredibly ...
21
Computational cost of RSA with keys of length $n$ bits is roughly $O(n^2)$ for public key operations (encryption, signature verification), and $O(n^3)$ for private key operations (decryption, signature generation). So RSA with a million-bit key will be roughly one billion times slower than RSA with 1024-bit keys (for the private key operations); the latter ...
21
A block cipher is pretty much a substitution cipher. So let's look at a simple alphabetic substitution cipher. There are 26 different plaintexts and 26 different ciphertexts. The cipher is a permutation of these 26 values. But that does not mean there are 26 different permutations, it means that there are $26! \approx 2^{88.4}$ different permutations, which ...
21
Symmetric encryption and asymmetric encryption algorithms are built upon vastly different mathematical constructs.
In typical symmetric encryption algorithms, the key is quite literally just a random number in $\left[0 .. 2^n\right]$, where $n$ is the key length. The strength of the key is based upon its resistance to brute-force attacks, where an attacker ...
21
In summary:
Modern practice is to fix a small public exponent $e$ such as $e=2^{(2^4)}+1=65537$, then choose a public modulus $N$ of $\text{nlen}$ bits (the key size) with large random prime factors compatible with $e$, then compute the RSA private exponent $d$ from that. With near certainty, that $d$ will be at least $\text{nlen}/2$-bit. That can be used ...
19
In RSA, the bit size $n$ of the public modulus $N$ is often of the form $n=c\cdot2^k$ with $c$ a small odd integer. $c=1$ ($n=512$, $1024$, $2048$, $4096$.. bit) is most common, but $c=3$ ($n=768$, $1536$, $3072$.. bit) and $c=5$ ($n=1280$..) are common. One reason for this is simply to limit the number of possibilities, and similar progressions are found ...
19
A key size of 80 bits is the historical limit of infeasibility; that's what was used in the 1990s as a rule of thumb. That's the reason why Skipjack used an 80-bit key, and SHA-1 offers a 160-bit output. Various people have also estimated that a 1024-bit RSA, DH or DSA key offers an "80-bit equivalent" protection (see this site).
One of the most optimistic ...
18
You need to consider the weakest link property: a security system is never stronger than its weakest link. Since Argon2 is a password-based function, the weak link here is going to be the strength of your users' passwords. Choosing a longer output length doesn't help if the passwords' entropy is lower than that.
Think of it this way: if the hash function ...
16
512 bits (rounded down from the 664 bits or 200 digits in the patent) was recommended from its conception in 1974 and throughout the 1980s. Indeed, 463 bits was considered sufficient in the mid-1990s for the RSA-140 challenge. Whether key strengths as low as 100 digits (330 bits) were ever used in the early 1980s embedded systems is unclear; but probable ...
16
The only rule for the key is that it should at least contain 256 bits of randomness. If the key is smaller you may not get the full security of HMAC.
Preferably this should be condensed into 32 bytes. What you are talking about is probably the hexadecimal representation of those 32 bytes. If the key is too large it may affect performance and efficiency of ...
16
The input length of OAEP is directly specified in the standard:
M message to be encrypted, an octet string of length mLen,
where mLen <= k - 2hLen - 2
or simply mLen = k - 2 * hLen - 2 if we want to calculate the maximum message size.
Where:
k - length in octets of the RSA modulus n
hLen - output length in octets of hash function Hash
...
16
Despite similarities, it is really important to understand that passwords and cryptographic keys should not be carelessly conflated. Some important contrasts:
Passwords are normally selected by human beings according to their whims. Cryptographic keys are meant to be randomly generated by an algorithm.
Passwords are usually intended to be memorized by ...
15
That's not the same kind of key.
Symmetric keys are bunch of bits, such that any sequence of bits of the right size is a possible keys. Such keys are subject to brute force attacks, with cost $2^n$ for a $n$-bit key. 128 bits are way beyond that which is brute-forceable today (and tomorrow as well). If a block cipher is "perfect" then enumerating all ...
15
Actually, the problem is that the above quote uses the term "discrete log" in a way that's different from what you're thinking of.
When someone uses the term "discrete log", they can mean two things:
A discrete log in the group $Z^*_p$; that is, given $p$, $g$ and $g^x \bmod p$, recover $x$
A discrete log in some other group; that is, given a group $G$, a ...
14
Using powers of two is traditional. It also has a few implementation benefits for very constrained architectures: it saves a few instructions. This indirectly implies that some implementations are not able to process RSA keys whose size is not a multiple of 32 or 64, meaning that if you want maximum interoperability, you should not use other key sizes as ...
14
SHA-512 has both a larger internal state and a higher number of rounds than SHA-256 - which means that it provides a higher bit strength. Somewhat surprisingly it may also outperform SHA-256, as it uses 64 bit word size, which works best on 64 bit processors. You can see a good comparison table on Wikipedia
If less bits are required from SHA-512 then they ...
14
No, it doesn't help. It doesn't hurt either; as long as you don't repeat keys, the probability of success is always the same. That is, if there are $2^n$ possible keys, and you test $\lambda$ of them, the probability you hit the right one is always $\lambda / 2^{n}$.
A key generated by a high quality random number generator (or a good key derivation ...
13
First let's take care of your encoding related issues:
You can't simply say one byte equals one char. You need an encoding to transform between these, where the properties depend on that encoding.
When transforming between normal text and bytes, UTF-8 is a good choice. One character will correspond to a variable amount of bytes that way. You'd use this to ...
13
First of all, this is not legal advice. However, I've been in the unfortunate position where I've had to deal with this legal nightmare. The new agreement which regulates export of cryptography internationally is called the Wassenaar Arrangement. If your product is what is called a mass market product, i.e available for purchase to the general public without ...
13
The security level of an elliptic curve group is approximately $\log_2{0.886\sqrt{2^n}}$. You can use this to approximate the security level of a $n$-bit key, eg:
$\log_2{0.886\sqrt{2^{571}}} = 285.32537860389294$
The real computation (at least for curves over a finite field defined by a prime $p$) is $ \log_2{\sqrt{\pi/4}\sqrt{ℓ}} $, where $ℓ$ is the ...
13
I know that humans would find it impossible to maintain a 128 bit password -- however, I wonder if there is some technical reason why a 52 bit password would not be as weak as a 52-bit encryption key for that matter.
First, I would argue that 128 bits is not impossible to remember. My current password manager master password is almost 100 bits (6 words from ...
13
There isn't just one, because there are many different scenarios where you'd use such a function, where the attacker has lesser or greater powers, or variably stringent success goals—different attack models. For example:
Does the attacker know any plaintext/ciphertext pairs encrypted with the same key? (Known plaintext attack)
Is the attacker able to ...
12
The simplest answer would be to look at the keylength.com site, and if you don't trust that, to the linked papers, particularly by NIST and ECRYPT II. Note that those mainly agree with the Lenstra equations, so you could use those as well.
You may have additional restrictions and - if you are brave or stupid - relaxations depending on the use case. But at ...
12
I saw many people complainig about AES , twofish and serpent that these ciphers all could be crackable in the near future and even today with big datacenters .
This is a good example of why we should always ask for citations and explanations, rather then just accepting what people say at face value with no scrutiny. These claims are about as far from ...
Only top voted, non community-wiki answers of a minimum length are eligible
