Hot answers tagged

36

1 - How feasible is it that the chip's manufacturer can predict the output of this PRNG when it passed tests from the people applying the use of this RdRand instruction in kernels? A strong stream cipher's output is random and unpredictable to anyone not knowing the key. See where this is heading? Just because something looks random doesn't mean it's ...


16

There are two important differences between AES-128 and AES-256: AES-128 has 10 rounds, AES-256 has 14 The key expansion process (that is, how they generate subkeys) is different If your AES-128 encryption hardware just takes a plaintext block and a 128 bit key, and produces a ciphertext block, well, no, there's not much you can do. In this case, the ...


14

A Smart Card is small portable physical device, typically flat and in the format of a traditional credit card (sometime much smaller: an example is the SIM card in a mobile phone), embedding: An Integrated Circuit with memory providing permanent data retention; that's using EEPROM, Flash, or FRAM in most of today's Smart Cards. Temporary coupling means ...


13

Have you heard of the strange story of Dual_EC_DRBG? A random number generator suggested and endorsed by the government that exhibits some very suspicious properties. http://www.schneier.com/blog/archives/2007/11/the_strange_sto.html From that article: This is how it works: There are a bunch of constants -- fixed numbers -- in the standard used to ...


11

Would it be useful for companies who need to keep their data safe? No, a one-time-pad is only useful in very rare circumstances. The main issue is key-management. You can only use each pad once, it's as large as the data you want to encrypt, and you need to get it to all parties in a secure way. The direct competition of a one-time-pad is a stream ...


11

A pure algorithmic approach does exist, however it only provides a fuzzy bound. It is related to the proof of work / client puzzles I described in this answer. The signer will sign the message using a normal digital signature, and use the message and signature to instantiate a "cryptographic puzzle." A cryptographic puzzle is a moderately hard function ...


11

1 - How feasible is it that the chip's manufacturer can predict the output of this PRNG when it passed tests from the people applying the use of this RdRand instruction in kernels? As nightcracker correctly stated, any strong cryptographic PRNG will produce a stream of numbers that pass statistical tests. However, the manufacturer has some constraints: ...


11

Hardware implementations are common, and likely to become more common as security needs increase, rather than less common. One place they're used is in the digital signature of messages, such as messages going to/coming from a Smart Card used for banking. Those are tiny, slow, limited processors, and a hardware implementation has the potential to improve ...


11

Let me begin by saying that if you have a hardware source of randomness, you don't need to be stingy with it. 1) Does modulo affect the quality of randomness, faking in some way the distribution of values? Yes, it does. Or at any rate, it can --- see my answer to (3) below for more details. (I'm assuming by "quality of randomness", you specifically mean ...


9

I am the designer of the random number generator that is behind the Intel RdRand instruction. How feasible is it that the chip's manufacturer can predict the output of this PRNG when it passed tests from the people applying the use of this RdRand instruction in kernels? It isn't. We cannot. It passes the tests because it is a cryptographically ...


8

A video camera can obtain entropy, but only at a fairly low rate and only if allowed to see "unusual" scenes… like someone making funny faces, unusual movements, etc. Of course, this only works in a room with no video bugs. Theoretical explanations… Depending on your knowledge-range, the following sources may be able to explain ways webcams can be used ...


8

Your doubts are absolutely valid. Disguising the algorithm is not a valid argument for security. It also contradicts to Kerckhoffs Law. It (the algorithm) should not require secrecy, and it should not be a problem if it falls into enemy hands; Designing cryptographic algorithms (ciphers, hashfunctions, ...) is a long and complicated process. In ...


8

It depends how the “AES-128 encryption hardware units” you mention are actually defined. I've already encountered processors that allow to independently compute AES operations such as $\texttt{SubBytes}$ and $\texttt{MixColumns}$ – which are the same regardless the key size involved (128 or 256 bits). In that case: yes, it can speed up the calculation for ...


7

A quick web search for "randcam" showed me this german page “Zufallszahlen aus der Webcam”, which translates to “random numbers from the web cam”. (All other hits on the first Google result page are about an unrelated Pistonless rotary engine). This page is about a program available from the same site, which tries to gather entropy from a web cam and ...


7

I think this question is setting up a false dichotomy. It's not that a researcher has an opinion as to whether they prefer software or hardware implementations. The choice of implementation depends on the requirements of the specific cryptosystem you're building. For example, if you're designing a system to encrypt voice traffic on a mobile phone network, ...


7

As pointed in this comment, using a huge random key for a sound block cipher is an excellent defense to resist ASIC/GPU attacks. Each bit added doubles the effort required. If an adversary was able to build $10^{12}$ ASICs each capable of testing $10^{12}$ keys per second, odds of finding a 128-bit key by brute force running that for a decade are less than ...


7

A cryptographical algorithm can't be immune or not immune to side channel attacks; this is because a side channel attack attacks the implementation and not the actual algorithm. Any algorithm that uses secret data can be implemented in a way that has side channel attacks, and any algorithm can be implemented in a way that may be resistant (the hard-core ...


6

One-Time Pads only protect secrecy Encrypting with a one-time pad only protects the secrecy of the message. It does not protect the integrity of a message. An attacker can flip bits in the cipher-text and that will flip bits in the plain-text. To protect the integrity of the message you need some sort of Message Authentication Code (MAC). This can be done ...


6

First, take note of my answer to the question Estimating bits of entropy. A key phrase therein: You'll never be able to look at a bitstream without knowing the distribution and say "there are X bits of entropy here." The ent program doesn't know the distribution of the data it's looking at; instead it performs some statistical tests that any ...


6

While unfortunately that is not possible deterministically, if you have a small amount of "guaranteed trustworthy" randomness, you can use several untrusted RNGs together to generate an unlimited supply of good randomness (under some weak assumptions of non-signaling between the RNGs). This is called "randomness expansion" and I am not aware of any use in ...


5

As for goals, there are typically two that you would look to when implementing something on an FPGA: first, minimizing latency; second, maximizing throughput. To minimize latency, you would use the FPGA to perform a computation much faster than you could do on a CPU. An example here would be the DES cipher. DES is well suited for hardware and you can get ...


5

325 MB/s is already good, i.e. you will not get much more with another implementation. Also, SHA-1 is a sequential algorithm, so multiple cores or a GPU will not help you. Specialized hardware is probably your best bet to make SHA-1 faster. (Also, if SHA-1 is the bottleneck then you are able to move data around faster than that, which is impressive; ...


5

Often people build hardware that contains cryptographic algorithms, and they are worried about what happens if that hardware falls into the hands of an attacker. Historically, there have been several approaches to making it harder for the attacker, often used in some combination: Hardware and cryptographic algorithms specifically chosen or designed to ...


5

In two key 3DES two keys are equal so that key size is only 112 bits, compared to the 168 bits of full 3DES. The advantage is a smaller key size without a correspondingly large loss in security: both two and three key 3DES can be attacked in about $2^{112}$ time. With the encrypt-decrypt-encrypt construction it clearly must be the first and last key that ...


5

There are typically four different settings where you want to run your crypto. The Central Processing Unit (CPU). This may be a classic desktop or laptop CPU or the one of your embedded device. Its characteristic is that it usually has rather few computation cores ( < 20), but it can use the ones it has very fast and can execute arbitrary instructions ...


5

I have argued so 15 years ago, and not been proven wrong since. Basically, A5/1, with a $n$-bit state, offers a resistance of roughly $2n/3$ bits of security. With $n = 64$, the resistance is very low, thus amenable to not only direct breaking, but also all kinds of trade-offs. All the attacks published so far are dances around that resistance level of ...


4

For free software-based solutions on an x86_64, OpenSSL is the best around. Intel's IPP is purported to be 20% faster, and it's software-only, but it's not free (about 200USD, or 80USD for the academic version) and you have to fill out a form saying you're not from N. Korea, etc. There are hardware accelerators in the form of SSL cards/chips, but are ...


4

See section D.2.2 of FIPS 186-3. The modular reduction can be expressed as two additions and two subtractions of values which are assembled by concatenating selected 32-bit words of the 448-bit value which is to be reduced. Note that these additions and subtractions are modular, so you may have to mind some carries.


4

There can't be any mathematical "fact that prevents ... open-source software (...) and hardware", since one could just use F(k,counter) or F(k,rounded(time)) as the one-time password. There could be the physical fact that it would be too easy to physically extract the secret key from open-source hardware running open-source software. (In his answer, fgrieu ...


4

The best we can do today, in matter of token similar to SecurID (that is with the restriction that the authenticating value produced by the token is keyed-in by a human), is open-source software on the verifier side, provided that we accept that there is a secret key on that side or we have some communication link to the token able to transfer more data ...



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