# Tag Info

10

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

8

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

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

6

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

5

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

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

4

Your question is pretty confusingly written, but let me try to make some sense of it. You say you receive 8 bits of input every cycle. You want to encrypt the input using AES, which operates on 128 bits at a time. This means that you need to buffer the input somehow (a shift register might be handy here) for 128 / 8 = 16 clock cycles, until you've ...

3

Don't think you've missed something. How do they keep these systems from being broken by someone just looking at the information in the smartcard that houses the key? Those systems have indeed been (and frequently are) broken via Hardware reverse-engineering. Therefore I would chime in with your "not secure". OTOH: decrypting AV signals isn't like ...

3

The access codes were recently leaked (by whom, I don't know). My Yubikey is listed and I can confirm that the access codes were necessary and sufficient to reprogram it. You can change or remove the access code as part of reprogramming too. The leak doesn't make the Yubikeys useless in the extremely unlikely event of Gox rising from the flames — no ...

3

Your hurdles are going to be commercial and political, such as patents and other forms of IP. Technically, there would be nothing from preventing you from building such a system. Open Source is a licensing model, not a technology. But think about the efforts that went into building the original SecurID token. You need a very low power microprocessor, a ...

3

I'm not a researcher in the field of cryptography. With that out of the way, the most obvious reasons I can think of are: Software is more universally deployable, increasing the target audience of some solution. With a hardware solution, potential customers may be forced to invest a huge amount of money to deploy it. A software solution is probably cheaper ...

2

Practicality: Using a bitcoin miner for cryptanalysis would at the very least require you to write very low-level custom code. Indeed, depending on the precise hardware/software split used by the miner, it might well require modifying the actual hardware to facilitate your cryptanalytic attack. Anyway, let's suppose someone could 'convert' one. What would ...

2

There are two ways I can see for the RNG to be cooked. (For the record, I don't see any reason at all to suspect this of Intel, but I also think prudent cryptographic design requires us to think through what would happen if our RNG were flawed or backdoored.) First, your RNG could not have enough entropy. That's what got the Netscape RNG many years ago, ...

2

I don't think there is a pure-cryptography solution to this. Suppose you built a chip, and it time-stamped whatever message you wanted, using an internal atomic clock. For the sake of argument, let's say that it's unhackable, and totally tamper-proof. Well, there's still a loophole. Put the chip on a spacecraft and speed it up to 99% the speed of light for ...

2

One technology that is required for such a token is the provisioning of the keys for the One-Time-Password (OTP)-based algorithm and then you have to also pick an OTP algorithm. I co-chaired the group in the IETF who standardized these protocols (at the time when the RSA patents expired). Here is a pointer to the group called KEYPROV: ...

1

NIST has a lot of information on testing random number generators at http://csrc.nist.gov/groups/ST/toolkit/rng/index.html that might be of value to you.

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