Tag Info

11

Post-quantum security: As you note, quantum attacks are not known to break lattice-based cryptosystems. But some other proposals like McEliece, as well as most symmetric primitives are not known to be poly-time breakable on a quantum computer. Security from worst case assumptions: In security proofs for cryptosystems we typically assume that some problem ...

8

It depends. Specifically, it depends on the type of cipher, and on the way it's used. For stream ciphers like RC4, and for block ciphers like AES in CTR and OFB modes, decryption is effectively identical to encryption, and thus takes the exact same time. (Minor exception: encryption may require generating a unique nonce / IV, which might take a small ...

8

"Cycles" are CPU instruction cycles. Cycles per byte roughly measures how many instructions, in a given instruction set, are needed to produce each byte of output. They're a reasonably-good relative measure of the performance of different algorithms. Generally, when you measure an algorithm's cycles per byte, you use carefully controlled conditions. You ...

6

From the diagram on CTR mode you can notice that there are no dependencies between any of the phases of the pipeline. If you have more than one block-size worth of data, you can process each block-size chunk completely independently of the others by calculating $\mathrm{ciphertext}_i = E(\mathrm{key}, \mathrm{nonce} \, || \, \mathrm{counter}_i) \oplus ... 6 ECDSA should in general create signatures faster than RSA for the same cryptographic strength if you just look at the mathematics. In the end the modular exponentiation is performed for smaller numbers. However, ECDSA depends on a random number generator, so ECDSA speeds may be slower if the random number generator blocks for any reason (and not using a good ... 6 Computations on elliptic curves are more efficient. Roughly speaking, when the base field has size$n$(for DH/ElGamal/DSA, the size in bits of the modulus$p$; for elliptic curves, the size of the field for point coordinates) and a "security level"$t$(e.g.$t = 80$for "80-bit security" as can be expected when using a 160-bit subgroup and a 160-bit hash ... 5 A "general computer" simply doesn't exist, test for yourself with this command: openssl speed rsa As an example here is the output on a Mac Pro 2007 withIntel Xeon 5130: Doing 512 bit private rsa's for 10s: 67450 512 bit private RSA's in 9.95s Doing 512 bit public rsa's for 10s: 961891 512 bit public RSA's in 9.94s Doing 1024 bit private rsa's for 10s: ... 5 Pretty much all modern encryption systems (including AES, in any standard mode) are data-agnostic: they are designed to encrypt any byte (or bit) stream regardless of its content, and their performance does not depend in any way on what the stream contains. Indeed, if this were not the case, that would open the encryption scheme to timing attacks — if ... 5 They measure it. Once upon a time, CPUs were simple enough that you really code compute the amount of time for a stretch of code by looking up the clocks per instruction in the manual, add them all together, and that'd be the total time. However, CPU manufacturers have added more and more optimizations and parallelism; this makes the CPUs run faster (for ... 4 I think that there is no chance of getting such an asymmetric cipher simply because you forgot about science. The security on todays asymmetric cryptography is mostly based on the assumption that some mathematical algorithms cannot be reversed (e.g. the discrete logarithm or integer factorization). If mathematics solves this problems then the algorithm is ... 4 Predicting speed by looking at the assembly is hard, especially since processors do all sorts of tricks which have memory (e.g. branch prediction). So yes, this is all about measuring. There is an art to it; for instance, you would rather repeatedly encrypt the same relatively small buffer (4 or 8 kB) so as to avoid cache effects. One method is to do the ... 4 Both curves have similar form and primes close to powers of two ($2^{192}-2^{64}-1$and$2^{224} - 2^{96} + 1$), so you wouldn't expect large differences in performance – all things equal, P-224 might be anywhere from 30% to 60% slower due to the computational scaling of curve operations. However, in practice different implementations will have different ... 4 In RSA encryption as practiced (that is, to encipher a message which is a short symmetric key), the message size after padding is fixed and equal to the modulus size. Thus the size of the message has no impact on performance. Calculating a modular inverse is performed only during key generation, that is seldom. Also, it has low cost compared to generating ... 3 In principle, it is theoretically possible to calculate the time it takes a machine to run some known algorithm. It used to be fairly commonplace, but there are apparently very few people who have ever done it -- the sorts of things that used to require isochronous code are now-a-days generally done in other ways. In practice, it's generally simpler and ... 3 The performance bottleneck with RSA is the modular exponentiation operation. On the other hand, if you are interested in public key encryption performance, perhaps RSA is not the correct tool. RSA is actually fairly fast during its encryption operation; however it is quite slow during the decryption. If you care about decryption performance, you may want ... 3 Generally, it depends on the architecture. If you have$n$processors available, the obvious way to parallelize CTR mode encryption is to distribute each chunk of$n$consecutive blocks among the processors, so that processor$0 \le i < n$computes: $$C_j = E_K(c_j) \oplus P_j, \quad j = i + kn, k = 0,1,2,\dotsc$$ where$c_j$is the$j$-th counter ... 3 Elliptic Curve Cryptography (ECC) is not known to be specifically more resistant to side channel attacks (of course the next question is more resistant than what). This paper reviews power analysis side-channel attacks against ECC and countermeasures. Given that ECC uses multiplication and many common implementations of the MUL instruction run in time ... 2$\displaystyle \text{cycles per byte} = \frac{\text{cycles per second}}{\text{bytes per second}} = \frac{2.1 ~ \text{GHz}}{4.3 ~ \text{MiB}} = \frac{2.1 \times 10^9}{4.3 \times 1024^2} \approx 466 ~ \text{cpb}$Of course this may be way off because processors are complex beasts these days, and may not work at their full potential all the time, and the ... 2 PLEASE NOTE: The code I link to below has not yet been reviewed by anyone with professional cryptography experience. I expect that it contains bugs, and it is definitely not production-ready. I am still learning about the JCA; there are parts of the code I have not finished, and there are parts that I will most likely go back and redo. That said, the tests ... 2 ... are secure for up to 30 years. Unfortunately, you didn't reference where this number comes from. Breaking asymmetric cryptosystems comes with various flavors: Scientific advances and new records, e.g. the factorization of RSA-768 in 2009 What intelligence agencies are capable of (it can be assumed to be a few years ahead of scientific advances, ... 2 As the commenters have said, it is impossible to answer without many more details about your particular implementation, but here is some background on Rijndael (pronounced 'rain-doll') that might help. Rijndael is the family of ciphers on which AES is based. AES is defined as Rijndael[1] with a block size of 128 bits and key lengths of 128, 192 and 256 bits. ... 2 You never need larger parameters for RSA. In the worst case ElGamal parameters and RSA parameters are equal size. But you can significantly reduce ElGamal parameters depending on the setting you are using for ElGamal. If you are working in$Z_p$for$p\$ beging prime, you work in a field of the same bitlength as required for RSA. But to obtain IND-CPA ...

2

RSA and ElGammal are about equally secure at the same modulus size (assuming, of course, intelligent parameter selection in both cases). For RSA (assuming you use good padding), the best known-attack is to factor the modulus with NFS. For ElGammal (assuming you use a subgroup with a large enough prime factor), the best known-attack is to compute the ...

1

The performance can be configuration specific, so beware that any outcome is specific to a machine. Take care that you test on the right configuration(s). The performance may also be specific to a certain input size. So test for specific amounts of data while keeping in mind that most hash methods operate on blocks (it doesn't make much sense to test 1 byte ...

1

AES is asymmetrical in this regard. It is down to the key schedule, which generates a sequence of round keys from an initial key. In a modern desktop environment, the round key sequence is simply generated before encryption/decryption starts, so the difference in speed is minimal. In a memory-constrained environment like a smartcard, this may not be ...

1

The performance of the hash depends on the environment it is used in. Keccak excels in ASIC type hardware designs, whereas Blake and Skein excel in x86 and x86-64 environments. MD5 is still quite fast in software, but newer algorithms take advantage of SIMD instructions on newer processors. There is also the question of performance on a per invocation ...

1

Are there performance, size, or power efficiencies from one curve to another? The larger the curve, the larger the keys and signatures, and likely the slower the computations. There are exceptions to the last one – curve parameters do affect how efficiently they can be implemented, so some curves with good parameters can be faster than slightly smaller ...

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