Intel Security processor + a question

Tyler Durden camera_lumina at hotmail.com
Fri Oct 18 16:40:55 PDT 2002


Well,I disagree about psuedo random number generation, sort of.
First, if I have PSR sequence of the known variety (ie, ANSI or ITU), and if 
it's mapped to some telecom standard (DS-1/3, OC-3/12/48/192), then my test 
set can and should be able to lock onto that sequence. This is true whether 
that telecom signal is raw PRBS, or if it has been mapped into the payload 
(you use different test sets).

In addition, PRBS have a very distinctive trace signature in the frequency 
domain. SO if I run my PRBS-mapped telecom signal into an O/E (if it's 
optical, for instance), and then into an Electrical Signal Analyzer, I'll be 
able to see if the characteristic Electrical Frequency spectrum matches that 
expected for, say PRBS-23.If it doesn't, I know something's up. If it does, 
it CAN of course be something else, but that signal does have the right 
amount of entropy.

With encrypted info who knows? I would think that testing if there's monkey 
business might boil down to algorithms--ie, if certain bit patterns happen 
too often, then something's wrong...






>From: "Major Variola (ret)" <mv at cdc.gov>
>To: "cypherpunks at lne.com" <cypherpunks at lne.com>
>Subject: Re: Intel Security processor + a question
>Date: Fri, 18 Oct 2002 14:33:15 -0700
>
> > From: "Tyler Durden" <camera_lumina at hotmail.com>
> > Subject: Re: Intel Security processor + a question
> >
> > OK...a follow up question (actually, really the same question in a
>diferent
> > form).
> >
> > Let's say I had a crypto chip or other encryption engine, the code of
>which
> > I could not see. Now what if someone had monkeyed with it so that
>(let's
> > say) the pool of prime numbers it drew from was actually a subset of
>the
> > real pool that should be available for encryption. Let's also say that
>
> > "somebody" knows this, and can search byte streams for known strings
>of
> > products of these primes. They can then break this cypherstream very
>easily.
>
>Or consider someone who sells a "RNG" but won't let you examine it
>physically...
>(you might have been sold a long-sequence PRNG, and without either 1.
>the algorithm & key
>or 2. physical inspection of the circuit YOU CAN'T TELL.  )
>
> > Now don't get hung up on the details of what I'm saying here...I don't
>know
> > if this particular example is possible or not.
>
>Of course.  If you can't disassemble the code, or chip, you're fucked,
>since you're trusting those who made and distributed the artifact.
>
>I'm just wondering iF it is
> > possible to tamper with crypto code (particularly as embedded on a
>chip) so
> > that it appears to all regular users not to have been tampered with,
>but
> > meanwhile it allows certain privileged users to access encrypted
>streams
> > fairly easily.
>
>if ( !strcmp("backdoor", password_str)) let_me_in();
>
>is readily written in RTL and a comparator is not many gates.
>
> > AND if this is possible, is there some way to examine the encrypted
>output
> > and then, say, search for unusual frequency traces of certain
>sequences, and
> > determine tha the code has been tampered with? Or are there ways to
>tamper
> > with good cryptocode in ways that can never be detected with actually
> > looking at the originating code?
>
>You can write clear code --in C or Verilog-- which does not permit much
>room for hidden functionality.   However if you can't examine inside the
>box, it is very very
>easy to design backdoors you will never find in a thousand years.


_________________________________________________________________
Protect your PC - get McAfee.com VirusScan Online 
http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963





More information about the cypherpunks-legacy mailing list