I think that the context matters. In the case of an external consultant being asked to sign an NDA (whether prematurely or otherwise), Eric S Raymond presents some compelling arguments on why and how NOT to sign them.
http://esr.ibiblio.org/?p=2394
The core is written entirely in synthesisable Verilog RTL. Synthesises to about 700+ Slices at around 150MHz on a Spartan6. (minus h/w division and modulo)
Neat! I'll check it out tonight. HW division and mod are going to be difficult-ish: I was thinking that either I could use a DSP block or, failing that, bump up the clock frequency of the LUTs used for div/mod until the 16div16 operation can appear to occur in 3 main CPU cycles. I'd love to contribute whatever I can to the project - I mostly work with Lattice stuff but I guess it couldn't hurt to give Xilinx's tools a try^^ Thanks!
Swimming (and drowning) at the software-hardware boundary.
We are currently looking to fill several full-time engineering positions.
If you are looking for a place to experience an alternate work culture within Malaysia, feel free to apply. At AESTE, you will be given the opportunity to impact the world in unexpected ways.
May I ask how welcoming Malaysian companies are to the idea of hiring foreigners?
I currently don't live in Malaysia but spent many years there in university and I do think about going back once in a while but I'm not so sure if it would be easy for a non-local to get a job there.
Any thoughts on the matter as someone living there?
As I understand it, all that was required was for them to use the same random number /twice/. Let's say you're Sony and you sign a patch, release it, realise there is a minor fix, and release within 2hours... maybe in your rush you failed to regenerate the random seed?
Or, my initial thoughts, someone inside Sony did this maliciously?
If your build process requires you to manually generate a random number and copy and paste it in, you need to try harder. If you work for a bank handling payments, you should be fired and never allowed to work in software again.
EDIT: that last bit about banks is OT, sorry about that, I've been watching the chip and pin hacking talk from CCC and got confused.
Personally, I don't think the domain matters. If a developer is required to provide security, either to protect a secret, maintain personal or company profits, or protect customer finances, and that developer fails by "int rand() {return 4;}", that developer should never work with technology again.
I agree. It is unlikely that the release manager would have been expected to generate a random number. I'd have expected, possibly, a pre-generated list of random numbers, maybe 1000 or so, so a duplicate is not unlikely, and cannot happen maliciously.
I find it most likely that the build process code was flawed. This sort of code is, in my experience, not written by your most talented developer (unless one of your top developers has a build fetish). All too often you only find deficiencies in the build/release process the month of release, when you have the least time to fix them.
If the whole project is about signing code packages to prevent the platform being hacked, you would've thought the key generation would be considered a critical part of the application code, rather than a detail of the build process. Even if the code necessarily exists in the build script. The build script is the project in this case.
If a developer has ever even thought about generating a list of 1000 random numbers to pick from at a later date, then they shouldn't be developing production code.
Yeah. You don't generate a list. You have make automatically dd 16 bytes from /dev/random, pipe it through hexdump, and then use that as your seed. You don't even have to check for dupes. There are 3.4 * 10^38 possible keys; You will not pick the same one twice.
That way, you can't even accidentally reuse a seed in development, or leak that list of the previously used seeds. When something compromises the system, and you don't need it any more, it should be destroyed.
You are probably more likely to spontaneously rearrange your constituent atoms into cheese or something than to generate the same random 16 bytes twice, assuming a new number needs to be generated only once for each package of code signed. If there was one needed for each packet on a network or something it might be different.
In any case, this risk is orders of magnitude lower than the risk of someone leaking your list of past numbers, especially when they're this valuable.
Even worse, if you are using a list to eliminate the possibility of repeats then you aren't generating a perfect random distribution any more. The possibility of repeated numbers, however small, is explicitly allowed.
maybe in your rush you failed to regenerate the random seed?
Or, my initial thoughts, someone inside Sony did this maliciously?
As always, the human factor is the real weakness. (Key management by users and coders.) There are similar problems with RSA signatures on related numbers or selecting keys for IDEA block cipher and RC4 stream cipher, just to name a few. If you use crypto tools incorrectly, you actually put yourself in a somewhat weaker position than if you hadn't even tried. What you've essentially done is create "security theater" for the bad guys to dupe the unsuspecting with.
