[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[HLL] Design considerations for 'harmless little box' and 'harmless little program'

Status: RO
Content-Length: 9263
Lines: 237

This document wants to the central text we use to tell others about our
harmless little project. It's a handy reference so that we don't have to
start from zero every time someone new comes aboard. It's my intention to
update this document every now and then.

This very first version is only a rough draft, so please send me your
comments, and I'll try to work them in the next version...

I need to know what y'all think of this...

I'll post some of my own comments on more current affairs after this mail 




History of the project:

A group of Germans has been working on a hardware device to do phone
[Germans, please give me some details on history of project]
Then at the Chaos Communication Congress 1997 they met with a bunch of
dutch people that had been thinking about something similar for some time.

Together they sat down and combined some of their ideas. This is roughly
what came out:

the harmless little project

0. Understanding this text

If you have little or no knowledge of cryptography or compression algorithms
this text will be hard to read, and the choices made herein will be
non-transparent to you. We suggest that you at least install and play with
PGP and the crypto telephony programs 'PGP-Phone' and 'SpeakFreely' for a
while and read their documentation before thinking too much about this

1. Project Goals

- Set a protocol standard cryptophony over normal phone lines. 
- Build a cheap hardware-only implementation of this standard
- Publish pc-board design and partslist, as well as sourcecode to the 
  firmware of this box. (And use freely available compilers and other tools)
- Set a standard for Internet cryptophony based on the same basic protocol
- Build software-only implementations that can:
  - talk to eachother over the Internet
  - Talk to eachother or to the harmless little box using a modem
  - run on many platforms
- Publish all sourcecode to this software
- Get this all out before it's too late

2. Design considerations  (early january 1998)

The 'harmless little' theme was chosen because we somehow feel that it will
prove more difficult to outlaw something if such causes headlines like
'Government wants to ban harmless little box' or 'man arrested for using
harmless little program'. ;-) (Calling the box/program/project 'Freedom of
Speech' would produce similar effects, and would maybe even make a better
political statement.)

Lowest-possible-cost considerations for the hardware-only implementation
will probably determine the minimum requirements for the protocol. This
minimum must offer at least some (3 to 5 ?) years of high-grade security
from a cryptographic point of view. Even though this may seem the wrong way
around, we'll discuss the design specs for the box and the software and then
discuss the specs for the protocol.

2.1 The Box  ('harmless little box')

Group discussions of capabilities of this box have led to the following
minimum specs:

- Small box, holding pref. one Euro-sized pc-board
- One 25 pin serial port for external modem (which should do at least 14.400)
- One button, to initiate crypto-link
- One red LED    (clear analog link)
- One green LED  (crypto digital link)
- 8 digit display
- As much processing power as is still cheap
- Phone jack (RJ11)
- One phone interface, capable of hook detect and audio in/out
- Line jack (RJ11)

In our view, this box would allow normal use of the atttached analog
telephone line through the phone jack until the button was pressed. At this
time, it would initiate a modem link using its attached modem (originate)
with the other side. If the box on the other side sees the carrier from the
remote modem, it would tell it's attached modem to go to answer mode.

At this point the two modems have disconnected the analog signal from our
harmless little box. Just to make sure no analog signal leaks to the
telephone circuit, the Box itself cuts the analog path to the phone jack as
well as soon as it receives a CONNECT from its modem.

Now the box does a Diffie-Hellman Key Exchange, with an 8 decimal digit
session key hash being displayed on the box. At this point the box starts
compressing the outgoing voice channel from the phone interface on the phone
jack using GSM compression and crypts it with Blowfish using the session key
established by the Diffie Hellman handshake. At the same time it decrypts
and uncompresses the incoming signal and outputs it to the telephone
interface attached to the phone jack.

Hanging up any one of the two telephones terminates the connection and
causes both modems to hang up. The party that has not yet hung up does not
get the analog path to it's modem restored until it has also hung up. (This
is to to avoid what we call the 'shouting-very-personal-things-to-someone-
at-a-party-just-as-the-very-loud-music-stops effect').

[Status as of jan 1998: the German group has picked a processor and is
working on hardware design. Please send me details so I can include these in
the next version of this status update]

2.1.1 Optional features for The Box

- 3-DES as an extra protocol if enough processing power is cheap enough
- Chipcard interface for optional key management system
- Extra serial port for computer so box can be used for secure datacomms
- More compression algorithms
- More crypto algorithms
- larger screen
- more buttons to choose algorithms and do key management functions

It's important however that any box speaks to the 'minimal box', doing just
Diffie-Hellman with 8 digit hash, blowfish and GSM codec.

2.2 The Software ('Harmless Little Program')

There are a few popular cryptophony programs available now. In our view they
all have severe disadvantages making them unsuitable to be or become the
standard that we feel is needed.

Very nice program, offers multiple codecs and crypto-algorithms, and does
Diffie-Hellman exchange, showing three words from a database as a hash.
However: PC-versionis unstable and development seems halted for over a year
now. Furthermore, the software is US-made and cannot legally be exported
outside the US.

Speak Freely
Stable, but no Diffie-Hellman, so PGP is needed to exchange keys.

Doesn't work over the Internet, only over modem-to-modem connections. No

Because of the shortcomings of existing software we decided that it would be
unwise to build a box to interoperate with any of these programs, but

instead develop a program that interoperates with our own box. Also: neither
of these programs was built with interoperability with a low-cost hardware
device in mind. 

Our program must:

- Talk to a modem and have the exact same minimal functionality the box
- Use standard audio device on platform for clear audio in/out
- Have controls for picking up line in both Orig and Answer mode
However it should also be able to communicate over the Internet and in this
case it should do a version of the same protocol over IP, incl. the
Diffie-Hellmann key exchange. It should also allow making connections to
<user>@<host> so that the host can either accept the connection if it's
running our software, or it could be running a small daemon that accepts
registrations from our software (on dynamic IP-addresses for instance) and
redirects the call to the appropriate IP-number). This way, users can choose
to register with any of the daemons out there, making this a scalable way to
make dynamic IP-numbers reachable.

The software should be written using very portable code so that it runs on
Windows, Mac and Linux at introduction. Source to all versions should be

2.3 The Protocol

The underlying protocol to all this should offer:

- A way to set up a link over async RS-232 or TCP-IP
- A way to describe capabilities and preferences for
   - Channel type        [default: Voice]
   - Key Exchange        [default: Diffie-Hellman]
   - Voice Compression   [default: GSM codec]
   - Encryption          [default: Blowfish]
   (Tricky: if the compression takes lots of cycles, there is less for the
   encryption and vv., so these capabilities should probably be described
   as a matrix)

- Implementation of at least the defaults for all of these

3. Setting the standard

We should strive to make the protocol the standard and write an Internet
RFC for the Internet relevant parts.

4. License

The GPL (Gnu Public License) has been suggested, but this offers little
possibility for third parties to use our work to build cheap commercial
implementations of this technology. We could consider doing this as
freeware on the condition that anyone can use what we did as a basis for
further development, as long as we get credit for it, and whatever they
build conforms to the standard.