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'.
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?
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.)
participants (7)
-
drzaphod＠brewmeister.xstablu.com -
koontzd＠lrcs.loral.com -
m5＠vail.tivoli.com -
Matthew J Ghio -
rarachel＠prism.poly.edu -
tcmay＠netcom.com -
uri＠watson.ibm.com