Does anyone know if bitfury's design stores the SHA-256 constants in BRAMs or has them spread over through the SLICEs?
Just guessing, but he probably daisy-chains the hashers in each clock region, runs them one step out-of-phase with each other, and has a single bram feed them k-values which get passed along from one hasher to the next, bucket-brigade style. My very first design -- which was bit-serial (really bad idea!) -- worked that way.
CONFIRM. Exactly how this is done... Why to install multiple K RAM, if you can install only few one per whole chip ? ;-)
There's actually several possibilities - one possibility that bitstream reads Device DNA code (it's serial number),
The DNA register is just a shift register; it's trivial to swap it out for an SRL32 in fpga_editor.
I've thought that it is different to convert .bit to .ncd .... But as you given me following links it seems to be trivial...
By the way,
these guys have documented the bitstream format and made tools that turn
.bit files back into
.ncd files -- even (completely illegible)
.v files in some cases.
-1 for Xilinx... it means that their bitstream non-disclosure protection basically make burden on normal developers, but not defies hackers / ip thieves, because they would have time and money to invest into reverse-engineering tools.
It is bad that chip manufacturer implemented AES only, because if they would implement in silicon some public-private key infrastructure with Xilinx certificate - it would be much simpler.
I don't think Xilinx wants the liability that comes with being a certificate authority -- especially one whose certificates can't be revoked because they're burned into millions of dollars worth of silicon. You can bootstrap similar schemes yourself on Virtex-6 and above; see section 6 of
this paper.
Just downloaded it... But if .bit -> .ncd could be converted - it will be not difficult to decode keys from chip. OR - EXTREMELY complex self-modifying bitstream should be made for protection alone... So costs would be not justified for this SHA256 thing protection alone... I've implemented some time ago meta-translators for x86 code protection, generating morphed code & executable difficult for analysis, and with FPGA it would be even more complex.
Even with e-fuse it is less protection compared to SRAM + battery for AES key.
I wouldn't trust them if I were you. It's
completely trivial to extract the AES key from Xilinx devices,
even Spartan-6. Even battery-backed ram. Only one power-on is required, and the equipment isn't expensive (if you rent it it's downright cheap). They didn't fix this problem until Virtex-6.
So in -7 series they will make logic that consumes _same_ power not depending on their internal key, so correlation will not be possible ? Have they at least aware of such bug ?
About remote activation - it is pretty possible thing.
Quite prescient of you -- stay tuned. But I'm not sure how well this would work for you -- with a highly-rolled design it's easy for an attacker to tell the difference between countermeasure circuits and the actual hashers -- just look for the pattern and chop out anything irregular. Once you've got it down to a few hundred slices it's easy to figure out where the inputs and outputs are and what they mean. Replicate that block, stitch it back together and the game's over.
On the other hand, you guys make your own hardware -- that's a big advantage when it comes to anti-piracy measures. You might be better off looking into ways to leverage that, like a tamper-proof housing around the spartan that erases the bitstream if breached and extra circuits to thwart power-analysis attacks. People are also less likely to try to reverse engineer your work if they have to take apart and possibly damage a box they've paid $100,000 for!
[/quote]
I'll wait for your release, anyway you have my question in your thread.... And I may reconsider initial licensing offer, as I still have no binding on that of course. As I still have about 200 Gh/s power, and if it would become 240 Gh/s - that would be nice benefit. And it is substantial benefit, as I can get board for say
$700 without VAT with 6 spartan6 on it - if it would be 1.8 Gh/s this means $0.38 per Mh/s
if it would be 2.2 Gh/s this means $0.32 per Mh/s.
So looking again on these numbers and having troubles with protection of bitstream, all of these devices can be "on hold" in some datacenter say in Iceland in name of their owners, but without ability to get them in hardware or get access without our consent/permission to equipment until IP released open-source. And open-source release I believe should be done at least for educational purposes, when we'll be ready to roll out best 28nm technology. Say this could be beneficial for DMC initiative. Also _existing_ hashing power (200 GH/s) can be good backing that equipment would be actually deployed, as my investors trust me with this.
So the coupon for 1 Mh/s with say 1 year hardware redemption possibility if you get enough for single board + shipment can be sold for about $0.60 + cost of equipment maintenance, insurance, etc - that would be fair price. And seems to be more fair play than "perpetual bonds" without significant backing, where bond issuer can go defunct half the road etc.
And also looking @ GLBSE it seems to be very risky, I suppose that some legal framework needed for this, to protect rights of buyers. Just putting reputation against such venture would be not enough I think. As investing into mining not with 4-6 month break even point would scare off investors if they would feel that fighting for their rights could cost more and without returning their assets than invested funds.
One of the ways could be - implementing specialized legal-based framework for hashing power trading. For example domain names are sold - sold legally and without any problems... And people not worry owning domain name worth say $10'000'000 etc. The same should be with equipment probably for mining, as this could help dramatically to secure investments into IP alone. Into ASIC for example as well. As when it would come to invest say $5 M into ASIC production, and there will be right engineers to proceed - it would be still great problem that "good fellow who organized all of that" would not just take part of these money and run away.