Re: clipper pin-compatible chip

>From: m5@vail.tivoli.com (Mike McNally)

>I don't think the idea proposed is to reverse-engineer the Clipper.
>Rather, the idea is that once you know the pin-out you can make an
>electrically-compatible (and, in important ways, software-compatible)
>replacement.

While the clipper chip and its CCEP brethern have chip specifications 
that imply that key is supplied as long as a read flag is in a certain
state.  The key for the clipper chip is 10 bytes of actual key plus
3 bytes of cryptographic check word (CCW), for a total of 13 bytes.

Operating in a system expecting a clipper chip potentially restricts
the keyspace.  Non-centrally selected keys use the clipper chip to
'fish' for the CCW, where it is re-fed.  The host system (to the 
clipper chip) is going to try and feed 10 bytes plush 3 bytes of
a constant.  Utilizing IDEA, the key is supposed to be 16 Bytes.

The point being that dropping an IDEA chip in is not 'plug and play'.

Actually, even if the clipper chip is limited to 10 bytes plus a 3 byte
checksum of sort, even if it's 10 bits it doesn't matter.

What you'd plug in the socket could have it's own CPU, and key
database, or even a plug in keypad of sorts to type in whatever key
you want.  You don't necessarily have to use the clipper requested
key.  A key of all 1's or 0's would be great, infact, it would be better
than great, it would be an indicator that the key is elsewhere, etc.

This plug in chip could have extra pins which don't plug into the
clipper chip socket, but rather go to another board layer which would
keep a database of encrypted keys and some way to access those keys with
a passphrase.

(I'm typing this in from work where all I have is some rather $#itty
term software, so please forgive my typos, etc.)

David Koontz  writes:
 > While the clipper chip and its CCEP brethern ...

I'm sure you're right; I don't mean to claim knowledge to anythign
like this level of detail.

 > Operating in a system expecting a clipper chip potentially restricts
 > the keyspace.

Indeed.

 > The point being that dropping an IDEA chip in is not 'plug and play'.

I believe this; my point was simply to clarify.  I interpreted Tim's
note as having to do with reverse-engineering Clipper, while the
original note seemed more along the "plug and play" lines.  Now that I
think about it, it's probably the case the Tim didn't misunderstand at
all, but was on a tack about how you'd pretty much have to completely
re-engineer the thing.  Or something.

Seems like it'd be easier to compete with Clipper by simply building
an alternative from the ground up.

--
| GOOD TIME FOR MOVIE - GOING ||| Mike McNally <m5@tivoli.com>       |
| TAKE TWA TO CAIRO.          ||| Tivoli Systems, Austin, TX:        |
|     (actual fortune cookie) ||| "Like A Little Bit of Semi-Heaven" |

Mike McNally writes:

>  > The point being that dropping an IDEA chip in is not 'plug and play'.
> 
> I believe this; my point was simply to clarify.  I interpreted Tim's
> note as having to do with reverse-engineering Clipper, while the
> original note seemed more along the "plug and play" lines.  Now that I
> think about it, it's probably the case the Tim didn't misunderstand at
> all, but was on a tack about how you'd pretty much have to completely
> re-engineer the thing.  Or something.

Good summary. I miss have missed the subtleties the original poster
(DrZaphod, as I recall) was making, about only a partial emulation. I
had assumed the idea was to defeat the Clipper proposal by
substituting a chip either not implementing all Clipper features
(notably, key escrow) or different in some other way.

"Socket compatible" is more than just matching up some voltages on
some pins, etc. The new chip must of course operate with the software
of the Clipperphone, or the jig is up and there's no point in even
dropping in a new chip! This was, as Mike correctly notes, the
starting point for my analysis.

If the new chip does not even work with the Clipper software, does not
behave like a real Clipper chip would, what's the point? Surely the
Clipperphones will not be bought and then modified because they are
"cheap." And if we do our job, they will not be _ubiquitous_ either.

Some of the plans underway for Soundblaster card-based voice
encryption (probably using CELP on a fast 486 machine, or faster) seem
more rewarding.

> Seems like it'd be easier to compete with Clipper by simply building
> an alternative from the ground up.

Yep.


--Tim May


-- 
..........................................................................
Timothy C. May         | Crypto Anarchy: encryption, digital money,  
tcmay@netcom.com       | anonymous networks, digital pseudonyms, zero
408-688-5409           | knowledge, reputations, information markets, 
W.A.S.T.E.: Aptos, CA  | black markets, collapse of governments.
Higher Power:2**859433 | Public Key: PGP and MailSafe available.

> Operating in a system expecting a clipper chip potentially restricts
> the keyspace.  Non-centrally selected keys use the clipper chip to
> 'fish' for the CCW, where it is re-fed.  The host system (to the 
> clipper chip) is going to try and feed 10 bytes plush 3 bytes of
> a constant.  Utilizing IDEA, the key is supposed to be 16 Bytes.
> 
> The point being that dropping an IDEA chip in is not 'plug and play'.

	Couldn't one compress the IDEA key to 10 bytes and 3?  The
hardware wouldn't notice and since you'd be using an IDEA chip on
both sides it could decompress and verify on the other end.

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
- DrZaphod                #Don't Come Any Closer Or I'll Encrypt!   -
- [AC/DC] / [DnA][HP]     #Xcitement thru Technology and Creativity -
- [drzaphod@brewmeister.xstablu.com] [MindPolice Censored This Bit] -
-         50 19 1C F3 5F 34 53 B7   B9 BB 7A 40 37 67 09 5B         -
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

DrZaphod says:
> > Operating in a system expecting a clipper chip potentially restricts
> > 'fish' for the CCW, where it is re-fed.  The host system (to the
> > clipper chip) is going to try and feed 10 bytes plush 3 bytes of
> > a constant.  Utilizing IDEA, the key is supposed to be 16 Bytes.
> > The point being that dropping an IDEA chip in is not 'plug and play'.
> 	Couldn't one compress the IDEA key to 10 bytes and 3?  The
> hardware wouldn't notice and since you'd be using an IDEA chip on
> both sides it could decompress and verify on the other end.

I think, that the original poster forgets the fact, that "Clipper"
isn't just the Skipjack encryption algorithm implementation. Thus
to compare Clipper to a chip that implements _only_ IDEA isn't
very helpful.

If one wants to imitate the Clipper - one will have to provide
_all_ of the external functions it performs, and it doesn't
matter at all, what encryption algorithm is implemented
deeply inside. Of course, if the "internal" key is
longer, than the "system standard" - you'd have
to expand those 80 bits, let's say via running
SHA over it...

There are problems, but this isn't one of them (:-).
--
Regards,
Uri         uri@watson.ibm.com      scifi!angmar!uri 	N2RIU
-----------
<Disclamer>


From owner-cypherpunks  Thu Jan 27 03:47:32 1994

drzaphod@brewmeister.xstablu.com wrote:

> 	Couldn't one compress the IDEA key to 10 bytes and 3?
> The hardware wouldn't notice and since you'd be using an
> IDEA chip on both sides it could decompress and verify on the
> other end.

Sure - but you're still restricting the keyspace to 10 bytes.
Why not just forget trying to fit it into the clipper system and build a
better encryptor from the beginning?