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)" <[EMAIL PROTECTED]>
To: "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>
Subject: Re: Intel Security processor + a question
Date: Fri, 18 Oct 2002 14:33:15 -0700

> From: "Tyler Durden" <[EMAIL PROTECTED]>
> 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

Reply via email to