Custom Search
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
John, And I hope someone tries it. We intentionally placed these points (note the use of plural) that are in the clear where they would be the most difficult to get at. Not because obscurity is security, but because the obscurity helps make the attack more expensive (to be successful). Also, it is a flip chip device (since V4), so you need to dig in from the back side, through the active layer, to get to the probe points (note plural again). Cutting through some working devices that might be required would break it. Finding the probe points will be loads of fun, too. Especially without schematics, or a layout. And the internal bus is not necessarily one bit wide (anywhere). So that will really challenge the attacker! In fact it is documented that a config frame is 1312 bits in V4. Yes, there are 1312 wires from a register in the config logic to every frame across the chip. I can see someone probing 1302, 1303, 1304 .... oops! Lost the key again! Of course, you might not need every decrypted single bit to then go back and break the encrypted bitstream. Maybe someone can answer how many decrypted bits you need to shorten the cracking of the encryption to a reasonable length of time... Of course the decryptor is all hard logic (just like an ASIC decryptor), so if one had a few 3DES, or 256AES ASIC layouts, and schematics, from other chips, they could probably make some educated guesses to identify where the core is, but where the signals are will take some ASIC reverse engineering. And, what is to say that the chip you are trying to crack doesn't have a design in it that is able to dump the keys (0 them, or even scramble them) if it detects that someone is tampering with it? Folks that are serious about security think about all these things all the time (because they do them, and have had them done to them by others). About this time, I think the attacker will be considering other methods of attack....which is all we needed to force them to do. Austin fpga_toys@yahoo.com wrote: > fpga_toys@yahoo.com wrote: > >>And maybe $100K for a >>similar design that is DES locked. > > > hmm ... someone asks just how would you attack an encrypted Virtex > part? > > There are two problems, first the key is on the chip being protected > with a battery, and second getting to the unencrypted bit stream that > passes through the chip at one or more parts. > > The key to attacking the chip would be to take one or more of the same > chip and peel it apart to locate it's basic design, looking for the > section of the chip where the 3DES engine is, the bit stream data path, > and the muxes which switch the bitstream. Then decide where the best > place to probe the clear text point is, and take a couple practice runs > on a practice chip. Probing is very likely to require a non-contact > solution if you can not easily reach a metalized trace with the clear > text bitstream on it. > > Then the fun part, stripping down a live part on a board with the > battery backup intact to preserve the key, and using the knowledge > gained on practice parts to uncover the probe point on the target > device, and getting it to reconfigure while you tap into the target > clear text bit stream. > > Hopefully you can get your hands on two or three such devices just in > case the first attempt has something very bad happen to the target > device. >Article: 102201
I'm working on a project that needs four write ports in a number of different register files. I'm already aware of time-multiplexing and partitioning. Generating a flop-based register file would take far too many resources. Are there any other methods of implementing multiple write ports on a single register file? Any nifty workarounds people have done? Any paper ideas?Article: 102202
sandeepbabel@gmail.com wrote: > In the simulation, the transmission line of the UART is at HIGH when > NOT transmitting anything, when I provide it with some data value and > a write signal, It transmits it and then goes back high again. When > the transmission is completed another signal called UART_RDY is > asserted and that indicates that I can load in the next data value. > > In the actual synthesised design, the TX line keeps transmitting some > random pattern over and over again, and is not held at HIGH state > when I power the chip on. In other words the UART_RDY signal is never > asserted, which implies that I cannot load data values from the PCI > bus, as it is always waiting for the UART_RDY signal to be asserted. I can't imagine the TX line state has anything to do with the UART_RDY signal - there shouldn't be any feedback required here. UART_RDY I would've thought depends only on the state machine of the transmitter, and when the last bit is clocked out of the transmit register, then UART_RDY is asserted. The fact that TX line isn't held high is a problem - and given the behaviour I'd suspect clocking problems? Have you checked the clock to the UART with the logic analyzer functionality of your synthesis tools? BTW what's the UART core doing when there's nothing to xmit? Is it holding TX high itself, or tri-stating and assuming you have a pullup? Is this your UART design BTW? Regards, -- Mark McDougall, Engineer Virtual Logic Pty Ltd, <http://www.vl.com.au> 21-25 King St, Rockdale, 2216 Ph: +612-9599-3255 Fax: +612-9599-3266Article: 102203
Subhasri krishnan wrote: > Hi all, > I use a test fixture to do post-translation simulation on my design. > Is there any way to increase the run time while modelsim is running? or > after it has finished running? Sometimes I need to extend it to just a > few more milliseconds but running it all over again takes about an hour > on my machine. >From the ModelSim (tcl shell) command line, type: run 10ms and it'll continue the simulation, from where it left off, for another 10 milliseconds. -aArticle: 102204
>...progressively harder by Moores law... Who needs Moore's Law for obscurity? The way most HDL is written would make any hacker turn pale. Even vendors' "model" code can be so bad you wouldn't want your name on it. In one example project, the code is claimed to be "...built such that both the software and hardware portions would be easy to understand...". On examination, the HDL is full of unexplained "magic" numbers and the comments gaze at each other through long-distance binoculars. As for unwinding the compiled versions of other people's creations, surely life is too short, unless that's the only job you can get. Me? I'd rather sign up at MacDonalds.Article: 102205
Sorry, my mistake. I should have known better--I just used a MAXII part in a design :) "Paul Leventis" <paul.leventis@gmail.com> wrote in message news:1147387024.723712.313290@q12g2000cwa.googlegroups.com... >H iRob, > > Just a quick correction -- our CPLD is MAX II, which is a follow on to > our MAX family of CPLDs (MAX7000 and MAX3000 series). Not to be > confused with MaxPlus II, which was the design software that preceded > Quartus. > > There's tons of info on these families available on our website > (www.altera.com). And you can download a free copy of Quartus II Web > Edition to try them out. > > Regards, > > Paul Leventis > Altera Corp. >Article: 102206
Austin Lesea wrote: > And I hope someone tries it. It would probably be fun to try as well, unfortunately I don't have access to a VLSI lab and prober :( But for a $100K bounty I might be temped to purchase the toys on eBay :) > Also, it is a flip chip device (since V4), so you need to dig in from > the back side, through the active layer, to get to the probe points > (note plural again). Cutting through some working devices that might be > required would break it. or getting very creative and drilling thru the BGA carrier, attaching wires to the standby battery bumps, and removing the carrier to get access to the process side of the die. While iteratively etching/slicing and scanning the die is a lot of work, over the last 25 years high resolution image/pattern recognition (with FPGA assist) has gotten better and faster. Attacking a 20M gate or larger device would have to be largely automated. FPGA's are at a disadvantage because they are highly regular, so one is mostly looking for the irregular blocks. If I had a contract to do it, it's probably map several die with an automated process first just to make sure the automated etching/slicing and scanning process yielded the proper mask design. Then work at automated reconstruction of your cell/transistor library, and then fold it back to a high level description to identify the odd logic blocks. Since the configuration and 3DES core are probably larger than any other support block, it's probably not that hard to issolate, unless somebody really tried hard to hide it in the middle of the FPGA array highly distributed in area. > Folks that are serious about security think about all these things all > the time (because they do them, and have had them done to them by others). I've done security stuff on and off over the years, but I'm not a hard core crypto guy. About 20 years ago one company wanted me to sign an NDA for the security projects, which was very draconian, so I refused. After the team was done, and the security project was shipping I broke it in about 3 hrs with a logic analyzer ... which I expected a much better challenge for a VERY expensive security consultants fee for providing the design. Since security is one of those things where people are much happier ignorant, I just let it ride rather than pissing a bunch of blisful exec's dreams away. There are a ton of horrible mistakes with security implementations ... my favorite is 802.112b WEP ... the security boys committee camel that was just a wet dream. > About this time, I think the attacker will be considering other methods > of attack....which is all we needed to force them to do. That is always the hope .... but making sure the security fence is the same height and durability all around the product is sometimes harder that one might first think.Article: 102207
Do you need the square root, or can you work with just the "sum of the squares" (perhaps scaled)? If this is used for thresholding (amplitude comparison), then the less-than/equal/greater-than relationship still holds. JTW "Marko S" <someone@microsoft.com> wrote in message news:44630af8$0$15782$14726298@news.sunsite.dk... > Thank you all. I will have a look at "Dijkstra's square root". I have 2000 > clock cycles at 40 Mhz to complete the calculation (It should be enough). > It is used for calculating the AM envelop after demodulating the signal > with a coherent detector > > > > You can se the principle of the detector at > http://www.cycom.co.uk/art1.html. > > > > > > "Symon" <symon_brewer@hotmail.com> wrote in message > news:4462fbb4$0$15793$14726298@news.sunsite.dk... >> "Michael Schöberl" <MSchoeberl@mailtonne.de> wrote in message >> news:4462f354$1@news.fhg.de... >>> Marko S schrieb: >>>> How do i calculate sqrt(a^2 + b^2) in synthesizable VHDL? >>>> The signals a and b are 32 bit signed fix point numbers >>>> (std_logic_vector (31 downto 0)). >>> >>> how accurate? how fast? latency? >>> >>> just for the sqrt(x) I once worked an idea to take len=ceil(log_2(x)) by >>> counting the length of x (leading 0s) ... >>> then you shift x>>(len/2) or something (+1?) ... this worked as a good >>> approximation and I added only one or two stages of a newton-raphson >>> >> Hi Marko, >> For square root, you could use modified Dijkstra's square root. >> >> http://lib.tkk.fi/Diss/2005/isbn9512275279/article3.pdf >> >> One clock per output bit. No multipliers. >> >> HTH, Syms. >> > >Article: 102208
MikeShepherd564@btinternet.com wrote: > >...progressively harder by Moores law... > > Who needs Moore's Law for obscurity? The way most HDL is written > would make any hacker turn pale. > > Even vendors' "model" code can be so bad you wouldn't want your name > on it. In one example project, the code is claimed to be "...built > such that both the software and hardware portions would be easy to > understand...". On examination, the HDL is full of unexplained > "magic" numbers and the comments gaze at each other through > long-distance binoculars. > I was going to add a related point but didn't think the post was going to go on. I could have said that a small amount of good or bad code produces alot of ASIC or FPGA final result with the myriad of synthesis and P/R settings, the same code could produce zillions of different chips to reverse engineer ie most of it is noise and very little is interesting anymore. When it was easy, the intent of the designer was often crystal clear and it was almost a pleasure to reverse and quite educational on a small scale, the layout was an exact reflection of the schematics and floor plan. The junior engineer looking at the masters work, but that was decades ago. Ofcourse before chip layouts were protected, many lazy semiconductor companies would blindly duplicate the works of leaders. Once automation set in, one is really looking up that tools rear end if one can see anything at all. > As for unwinding the compiled versions of other people's creations, > surely life is too short, unless that's the only job you can get. > It is, and I don't think anybody really does it anymore, it has to be far cheaper to just hire similarly skilled people and design to same spec. > Me? I'd rather sign up at MacDonalds. I'd rather die than do that. John JaksonArticle: 102209
MikeShepherd564@btinternet.com wrote: > As for unwinding the compiled versions of other people's creations, > surely life is too short, unless that's the only job you can get. Actually, doing traditional coding is far more boring ... after a few decades even what appears a very different projects is writing the same old algorithms over again. reverse engineering is more like jigsaw puzzles on steroids ... lot's of little pieces all the same "twisty windy little passages all the same". Learning to recognize algorithms, FSM's, etc allows you to abstract thru the clutter and rearrange the puzzle back into a clear picture without getting lost in the forest. Being able to see the adders, multipliers, fsm's, synchronizers and data paths as higher level objects allows you to cut thru the design more quickly and work with it at an abstract level more effectively. For example, when we bid the 386 controller project twenty years ago, it was one of those projects nobody else wanted, and I took it on a lark because it was interesting and I had a couple college kids working for me that had never done reverse engineering before. All the client needed was the communications protocol along with a clean room description of how to write a control server for the machine. I took it fixed price, for a month, with a "no delivery, no pay" clause (as I do a lot of high risk projects). The next week a $100K machine showed up at my door step, and we moved it into our office. I thought we were really going to have to dissassemble a dozen eproms of 386 asm and sort thru a hand coded assembly design. So I did that first, taking the proms off the board, and disassembling them. Then I connected the HP1650B to the processor bus, and started tracing control flow for major activities. By the second day I noticed a regularity in the code blocks which indicated a higher level structure, and sure enough it was forth pop code functions. It took another day to reconstruct the forth execution engine, and another day to reconstruct the forth sources that we needed. and a few more days to reconstruct the design and provide the clean room design documents. It took another week to track down all the constants and variables in the protocol and document them. They came and picked the machine back up, and we got paid for a couple weeks of very fun puzzle playing. Some people are challenged by deductive reasoning puzzles ... and others are clueless how to even get started. And even when shown, can never connect the dots.Article: 102210
Luke wrote: > I'm working on a project that needs four write ports in a number of > different register files. I'm already aware of time-multiplexing and > partitioning. Generating a flop-based register file would take far too > many resources. > > Are there any other methods of implementing multiple write ports on a > single register file? Any nifty workarounds people have done? Any > paper ideas? Google this group back a few weeks, the solution was presented in detail to the exact same same question. John JaksonArticle: 102211
fpga_t...@yahoo.com wrote: Anyone here that has taken a contract to convert a schematic design to VHDL/Verilog yet? same problemArticle: 102212
fpga_t...@yahoo.com wrote: > fpga_t...@yahoo.com wrote: > > Anyone here that has taken a contract to convert a schematic design to > VHDL/Verilog yet? > > same problem I was in a project that rescued from HP a late 70s nmos chip and had to bring into the mid 90s, all we got were the original mask tapes in a dead layout language (with notes) and the old test vector tapes. We had to write the layout decompiler to get the hierarchy and leaf cells and turn those into crude schematics. SInce those were nmos transistor level, it was only really possible to do so with a knowledge of nmos design with bootstrapping and mostly pass logic, something the new cmos kids wouldn't have known about. It was alot of fun and we did give HP back a new cmos Verilog source passing the same vectors so it should stay in production portable fashion as long as folks want arb waveform instrument boxes. At the time I never would have thought that I'd be doing nmos work again in the mid 90s. They also had a sin table in nmos rom but the std cell cmos had no rom, so got to replace that with an engine. The problem with all these projects is the contract fee, you never know whether your are going to lose your shirt on it or just survive another day. John JaksonArticle: 102213
Radarman- > We are still fighting to keep an old P3 system that went EOL years ago, > and that we are presumably paying penalties on, because it is the last > system with a working copy of several packages we need that are no > longer supported. It's kind of sad to see so many developers sharing > time on what has to be the oldest PC in the department. Yes I know this feeling. Our "4.1 machine" is a Win9x. Our "6.1 machine" is a slow WinXP that gets used mostly for testing and no one will admit to being it's caretaker. I think it's a Xilinx conspiracy to further promote FPGAs -- keep the key design engineers stuck using slow PCs so they fully realize the blazing potential of FPGA vs. Pentium. Haha! -JeffArticle: 102214
David- > Is that a licensing thing or a functionality thing? > > When I got my Spartan 3e starter kit a few days ago, I installed the > included ISE 8.1 under E:\Program Files\Xilinx . > > When I found out that some things Do Not Work in paths that have spaces > in them, I uninstalled it and re-installed it under > E:\ProgramFiles\Xilinx . > > Have I set myself up for a lifetime of pain until I get a new computer? No you're fine. I tell my engineers: back up the hard drive completely, try it once, and if you get lucky and *everything* works, then go ahead. But when the first thing fails, then restore the original drive, and keep the machine pristine. That's our lab rule, believe it or not. -JeffArticle: 102215
"srini" <g.shrinivasan@gmail.com> wrote: >I had a strange experience with the Synplify Pro 8.4. I used the >re-timing option thinking that it will help to improve the timing >performance of the design as they have claimed in their docs. But my >design's timing performance has gone down by about 5 Mz and I ended up >not meeting my timing constraints. Why is it so? Can anyone tell me >about this? Retiming works very well for some designs, and makes them run faster. Other designs retiming doesn't work with, for at least three reasons: 1) The resulting design may be larger, with more routing congestion, and thereby slower. This is most common and most noticeable when the part is fairly full. The timing failure may not be in the retimed paths, but may be elsewhere in the design. The best way to make a full design faster may be to make it smaller. A floorplan might help as well. 2) The resulting design may not pack as well. This is fairly hard to both diagnose and to visualize. It is somewhat like the first case, but from the inside out. If the retiming increases the routing delay by making the resulting design larger by more than it saves by making all paths have similar logic delays, then retiming will make the design slower. The timing failure may not be in the retimed paths, but may be elsewhere in the design. Again, making the design smaller may make it faster, and retiming does the reverse. 3) The retiming is done based on estimated routing delay. As an example, suppose the design had: FF -> lut -> lut -> FF --------------------------> FF 1 2 3 If the first two FFs can be close together on one corner of the part, and the last FF must be on the far corner of the part, then retiming that to: FF -> lut -> FF -> lut --------------------------> FF 1 2 3 will almost surely make it slower, as the critical path in the first case was between FF2 and FF3 because of physical placement, and adding the lut delay just makes it slower. The synthesis tool estimates based on "wireload models", and the estimated delays might look like this: FF -------------> lut -----> lut -----> FF ------> FF 1 2 3 As the synthesis tool has no knowledge where on the die these items are placed. The weakness of "wireload models" is a large part of the reason why "physical synthesis" can be useful, as someone has already commented, as a estimate of routing delays based on a realistic placement helps the synthesis, even if the placement isn't saved and reused. Retiming is a tool, and works well on many problems. Other problems require different tools. -- Phil HaysArticle: 102216
JJ wrote: > We had > to write the layout decompiler to get the hierarchy and leaf cells and > turn those into crude schematics. SInce those were nmos transistor > level, it was only really possible to do so with a knowledge of nmos > design with bootstrapping and mostly pass logic, something the new cmos > kids wouldn't have known about. You've hit on the two factors that separate failing teams from those that deliver. The vision to invest in automated tools, such as your layout decompiler, and specialized knowledge of the technology area. > The problem with all these projects is the contract fee, you never know > whether your are going to lose your shirt on it or just survive another > day. Fixed price contracting actually has some feedback rewards that way, you bid conservately enough after a few bumps not to lose your shirt again :) I find T&M far more risky, as the client is much too often to hold you to your initial time estimate, after increasing the requirements over the life of the project. With T&M you can not say no to design/requirements changes, and have less control over schedule expectations that result. One of the most stupid things is to take a high risk fixed price contract while you are hungy. Creates a lot of pressure that is counter productive in making reasonable decisions about the project. If you get into trouble, you are quickly very frustrated and HUNGRY. I normally bid them low ball based on best case with a very short time leash, and walk away if the project gets in trouble -- which is why the "no deliver, no pay" clause is critical. Out of several dozen of these contracts I've only walked away from one, and that was renegotiated a year later after several other teams had failed as well. I also had a year to sort out what went wrong and formulate a better attack on the project. I generally start those projects with a few 70-100hr weeks to bring them into perspective quickly ... the intense focus is for me worth several months of regular days, and very much needed to internally visualize the architecture of the problem early. After that, I've found these projects pay well, and generate follow on work well worth the initial risk.Article: 102217
Hello Mark,
Yes you are right, the UART_RDY depends on the state of the
transmission. What I meant to say was that when the transmission of the
data ends, TX goes high and UART_RDY is asserted. This is a design I
found on the web. It is originally from Quicklogic, but I modified it
so that it transmits 8 bit data and then another 8 bit data before the
state machine asserts the UART_RDY.
Below is the part of the code:
BEGIN
--// Paritycycle = 1 on next to last cycle, this means when tsr[1] gets
tag2.
paritycycle <= tsr(1) AND NOT (tag2 OR tag1 OR tsr(7) OR tsr(6) OR
tsr(5) OR tsr(4) OR tsr(3) OR tsr(2));
--// txdone = 1 when done shifting, this means when tx gets tag2.
txdone <= NOT (tag2 OR tag1 OR tsr(7) OR tsr(6) OR tsr(5) OR tsr(4) OR
tsr(3) OR tsr(2) OR tsr(1) OR tsr(0));
data_latch: PROCESS(write, data)
BEGIN
IF ( write = '0' ) THEN
data1 <= data(15 downto 8);
data2 <= data(7 downto 0);
END IF;
END PROCESS;
thr_write : PROCESS ( write, txdone)
variable count1 : std_logic;
BEGIN
IF (write'event AND write = '1' ) THEN
thr <= data1;
count1 := '1';
ELSIF (txdone'event AND ( txdone='1'))AND count1 = '1' THEN
thr <= data2;
count <= '1';
count1:= '0' ;
ElSE count <='0';
END IF;
END PROCESS;
shift_out : PROCESS (txclk, reset)
BEGIN
IF (reset = '1') THEN
tsr <= (OTHERS => '0');
tag2 <= '0';
tag1 <= '0';
txparity <= paritymode;
tx <= '1';
txrdy <= '0';
ELSIF txclk = '1' AND txclk'EVENT THEN
IF (txdone='1' AND txdatardy = '1' ) OR ( txdone ='1' AND
count = '1' )THEN
-- load_data1;
tsr <= thr;
tag2 <= '1';
tag1 <= '1';
txparity <= paritymode;
tx <= '0';
ELSE
-- shift_data;
tsr <= '0'&tsr(7 downto 1);
tsr(7) <= tag1;
tag1 <= tag2;
tag2 <= '0';
txparity <= txparity XOR tsr(0);
IF (txdone = '1') THEN
tx <= '1';
IF (txdone = '1' AND count = '0') THEN
txrdy <= '1';
end if;
ELSIF (paritycycle = '1') THEN
tx <= txparity;
txrdy <= '0';
ELSE
tx <= tsr(0);
txrdy <= '0';
END IF;
END IF;
END IF;
END PROCESS;
PROCESS (mclkx16, reset)
BEGIN
IF (reset='1') THEN
txdatardy <= '0';
write2 <= '1';
write1 <= '1';
txdone1 <= '1';
ELSIF mclkx16 = '1' AND mclkx16'EVENT THEN
IF (write1 = '1' AND write2 = '0') THEN
txdatardy <= '1';
ELSIF (txdone = '0' AND txdone1 = '1') THEN
txdatardy <= '0';
END IF;
write2 <= write1;
write1 <= write;
txdone1 <= txdone;
END IF;
END PROCESS;
Article: 102218Hi Mark, here is the link for the UART. http://www.ece.ualberta.ca/~elliott/ee552/studentAppNotes/1999f/UART/uart.html Thank you, SandeepArticle: 102219
fpga_toys@yahoo.com wrote: > Austin Lesea wrote: > >>And I hope someone tries it. > > > It would probably be fun to try as well, unfortunately I don't have > access to a VLSI lab and prober :( > > But for a $100K bounty I might be temped to purchase the toys on eBay > :) Nah, that wouldn't work - Austin would just claim they were counterfeit/grey market chips and therefore unsupported/somehow easier to crack.... ;) -jgArticle: 102220
I created a small tutorial about JTAG. See http://www.fpga4fun.com/JTAG.html I'd be happy to hear about mistakes/suggestions. Thanks.Article: 102221
Jim Granville wrote: > Nah, that wouldn't work - Austin would just claim they were > counterfeit/grey market chips and therefore unsupported/somehow easier > to crack.... ;) > -jg ROTFL :)Article: 102222
how to implement a clock multiplier in spartan2 from ref clock. I have input clock of 25 mhz and need to generate 50 Mhz clock. Thanks AshishArticle: 102223
Austin Lesea wrote: > John, > > And I hope someone tries it. > > We intentionally placed these points (note the use of plural) that are > in the clear where they would be the most difficult to get at. > > Not because obscurity is security, but because the obscurity helps make > the attack more expensive (to be successful). > > Also, it is a flip chip device (since V4), so you need to dig in from > the back side, through the active layer, to get to the probe points > (note plural again). Cutting through some working devices that might be > required would break it. > > Finding the probe points will be loads of fun, too. Especially without > schematics, or a layout. And the internal bus is not necessarily one > bit wide (anywhere). So that will really challenge the attacker! > > In fact it is documented that a config frame is 1312 bits in V4. Yes, > there are 1312 wires from a register in the config logic to every frame > across the chip. I can see someone probing 1302, 1303, 1304 .... oops! > Lost the key again! > > Of course, you might not need every decrypted single bit to then go back > and break the encrypted bitstream. Maybe someone can answer how many > decrypted bits you need to shorten the cracking of the encryption to a > reasonable length of time... > > Of course the decryptor is all hard logic (just like an ASIC decryptor), > so if one had a few 3DES, or 256AES ASIC layouts, and schematics, from > other chips, they could probably make some educated guesses to identify > where the core is, but where the signals are will take some ASIC reverse > engineering. > > And, what is to say that the chip you are trying to crack doesn't have a > design in it that is able to dump the keys (0 them, or even scramble > them) if it detects that someone is tampering with it? > > Folks that are serious about security think about all these things all > the time (because they do them, and have had them done to them by others). > > About this time, I think the attacker will be considering other methods > of attack....which is all we needed to force them to do. > It sounds like rubber hose cryptoanalysis would be faster, cheaper, and more reliable, and it's easier to get hold of experienced staff. > Austin >Article: 102224
Hi, Ray. Thanks for your suggestions. What do you mean with the following two phrases? > Floating point trades accuracy for dynamic range. and > In the case > of OFDM, you have 64 point FFT, so at most you'll have a growth of 6 > bits in your data. Ciao, Franco
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z