[Fwd: lpked draft]

Sat Jan 11 22:47:02 2003

--------------030003070406020604070002
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Bellow is a draft for what may come to be a "portable GnuPG" for use
with removable medias. I am forwarding with the consent of Voremo (see
email address at the bottom of the message).

This subject has been thoughly discussed in these mailing lists, and
probably they are a good place to gather ideas/resources to this project.

[]'s
Gustavo

-------- Original Message --------
Subject: lpked draft
Date: Sat, 11 Jan 2003 19:25:51 +0000
From: voremo@SAFe-mail.net
To: gustavo.hlv@gmx.net

Hi Gustavo,

Thanks for the comments. Yes, please pass it on to
any mailing list you consider appropriate. If not 
too much trouble, please include the version that 
follows below; it contains minor text editing and 
error corrections.

I am looking for a small number of collaborators
that would extract (and, where necessary, modify)
components from GPG source tree. I can do provide
component interface specifications and integration
and "outer shell" programming. But, in contrast to
many open-source collaborative efforts, I first 
and foremost want to establish a firm, a-priory 
"functionality fence".

==================================================

=================================================
"lpked": ("Lean Public Key Encryptor/Decryptor")
=================================================

Introduction:
=============

GPG/PGP in its present state can not be used
unless it is "installed" on a computer. Installing
a program on the computer on which it is used is
in many instances impractical, impossible or
generates its own set of serious liabilities.

A simplified form of public-key encryptor
is thus proposed. It has reduced functionality;
most notably it does not attempt to incorporate
the "trust model". (Note: is a public-key
encryptor/decryptor that does not implement the
"trust model" useful at all? The answer to this
question is outside the scope of this document:
the proposed program will be for those that
already believe this to be the case).

The program is meant to be used ONLY by those
that have read the source, understood it,
recognized the security problems involved and
consider them acceptable. (Or, perhaps, for
those that have delegated the above to someone
they TRUST PERSONALLY).

What follows are the design parameters for
such a variant of GPG; one that might be
dubbed "drive-by-GPG".

Design parameters:
==================

It is extremely important that the program
can be built from its source with ABSOLUTE
MINIMUM of development tools and expertise,
on any 32-bit computer where C compiler is
available. Therefore, there will be only one
version, one file of clean, standard C code
(with NO IFDEFS whatsoever!). It can be compiled
using "gcc lpked.c -o lpked" or equivalent on
any 32-bit platform. Linking is static, int is
32 bits, endian-ness is dealt with at run-time.

All entropy is supplied by the operator
via key-strokes and timer, at run-time.

All user-interface is via "command-line".
The format of command line is designed so
as to make it somewhat practical to write
GUI front-ends, but the security of such
use is left unaddressed and is assumed to be
highly problematic.

Program runs clean; i.e., it NEVER writes
to any file that is not specified on its
command-line. It does not allocate dynamic
memory or interacts with the operating system
in any manner whatsoever, except for reading
the timer and console and file i/o. It is
assumed that in most common use-model both
the program and data will be residing on
removable media (USB flash "disk", floppy,
CD, or combination of these).

There is no attempt to implement the "trust
model" (message or key signing etc...). Each
public and private key is in its own, separate
file. Private key is encrypted using a symmetric
cipher.

The program performs encryption and decryption
of files; no assumption is made of how these
will be stored or communicated.

There is no attempt to implement any ancillary
function (ASCII encoding, encryption of files
using symmetric cipher etc.).

There is no choice of ciphers: Blowfish is
used for symmetric, Diffie-Hellman for public
and MD5 for hash.

Source code will be taken from the existing
GPG source tree whenever possible; program
will be distributed as A SINGLE C language
source file: lpked.c. That source will be
public domain, BSD and/or GNU licensed.

Pass-word/-phrase and entropy can be supplied
on the command line (to make possible simple
GUI front-ends); if not given on the command
line (normal modus operandi), program will
prompt the operator via keyboard/console.

Command line:
=============

Program is invoked by a standard-format
command line consisting of single-letter
"flags" introduced by "-", possibly followed
by "=" and the option value and one, two or
three file names. For example:

lpked -e bob.key msgbob.txt msgbob.xxx

(To encrypt a file we will pass on to Bob. See
below for full explanation and more examples.)

Flags:
======

Flags are "Function", "Data" and "Auxiliary".

Function flags have no ("=...") value
associated with them and they define the
function that the program is to perform.
Depending on the function, one or more data
flags and one, two or three file names may also
have to be given. Function flags are:

-g generate public/private key pair. Private key
   is placed in the first file, public in second.

-e using public key in first file encrypt the
   message in the second file and place the result
   into third file.

-d using private key in first file decrypt the
   message in the second file and place the result
   into third file.

-f generate a fingerprint of the first file and
   put it into the second file if given, write on
   console in hex-ASCII format otherwise.

For -g ("generate"), -k, -s, -q or -r flags
(and data) may be given; otherwise the program
prompts the operator for key and/or random data.

For -e ("encrypt"), -r flag may be given or the
program will prompt the operator for random
keystrokes.

For -d ("decrypt), -k, -s or -q flags may be given
or the program will prompt the operator.

Data flags introduce the key, passphrase or random
data as follows:

-k=ssssss where "ssssss" is (optionally quote)
          key-string.

-s=wwwwww similar to the above, passphrase.

-z=ffffff where ffffff is 16 bytes of hex-formatted
          key data.

-x=ffffff where ffffff is 4-bytes hex-formated pointer
          to memory block with 16 bytes of key data.

-y=ffffff as above, pointing to a block of 4096
          random bytes.

In two of the above (-x=..., -y=...) it is assumed
that the memory pointer is provided by the GUI
"front-end" program that invoked lpked; it is the
responsibility of this invoking program to ensure
this memory can be read from, and that the clean-up
is performed afterwards.

Auxiliary flags are:

-h for console output of short usage/help "synopsis".

-p to pause for key-press after the program has been
   loaded but before it starts the execution. This
   enables replacing of removable medium (most likely,
   a floppy disk) on which program is resident with
   the one on which the data is resident.

-q to suppress any console output.

Files:
======

Files that the program operates on can be specified
ONLY on the command line. The program makes no
assumption of the paths, names or suffixes. File
integrity and authenticity is the responsibility
of the operator and NOT of the program. Files
are binary and cross-platform (i.e. when there
are 4-byte integers/words in files, specifications
are byte-order (little-endian) specific).

Public key file: first 2048 bytes are interpreted as
public key, rest is ignored.

Private key file: first 16 bytes are interpreted as
IV, followed by next 2048 bytes of encrypted private
key, rest is ignored.

Plaintext file: bytes. "User-community-agreed"
maximum size may apply.

Ciphertext file: First 16 bytes are an IV, second 16
bytes are a session key encrypted with recipient's
public key. Next is a number of 16-byte blocks of
encrypted data. Size of an optional partial block at
the end of the file specifies that the previous block
is the last data block and the number of data bytes
in it. (Ciphertext file MUST NOT contain ANY data
object that an intruder can use to confirm its
"creating application", use or origin).

Fingerprint file: 32 bytes of hex-ascii data.

Examples:
=========

lpked -e a:\fred.key a:\msgFred.txt a:\msgFred.xxx

Encrypt msgFred.txt message to msgFred.xxx
using (Fred's) public key in file fred.key.
The program will prompt the user for random bytes.
See below for more examples).

lpked -d a:\my.key a:\msgFred.xxx a:\msgFred.txt

Decrypt message (...xxx) using private key in
my.key and place output in msgFred.txt. Prompt
for key or passphrase used to decrypt private key.

lpked -g a:\mysecret.key a:\tom.key

Generate public/private key pair. Place private
key in mysecret.key and public in tom.key. Prompt
for random data and key or passphrase to encrypt
private key.

lpked -d -z=a802e71d027c382dae57e302817dfe14 my.key msg.xxx msg.txt

Decrypt message msg.xxx using my.key private key.
Private key decryption key is supplied in hex format
on the command line.

lpked -f anastasia.key

Write on the console the fingerprint of the public key
file anastasia.key

====================== end ===========================

All commnets are welcome. Please write to:

voremo@SAFe-mail.net

-- 
Gustavo Vasconcelos
OpenPGP Key ID: 0xFF006747

--------------030003070406020604070002
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <title></title>
</head>
<body>
Bellow is a draft for what may come to be a "portable GnuPG" for use
with removable medias. I am forwarding with the consent of Voremo (see
email address at the bottom of the message).<br>
<br>
This subject has been thoughly discussed in these mailing lists, and
probably they are a good place to gather ideas/resources to this
project.<br>
<br>
[]'s<br>
Gustavo<br>
<br>
-------- Original Message --------
<table cellpadding="0" cellspacing="0" border="0">
  <tbody>
    <tr>
      <th valign="baseline" align="right" nowrap="nowrap">Subject: </th>
      <td>lpked draft</td>
    </tr>
    <tr>
      <th valign="baseline" align="right" nowrap="nowrap">Date: </th>
      <td>Sat, 11 Jan 2003 19:25:51 +0000</td>
    </tr>
    <tr>
      <th valign="baseline" align="right" nowrap="nowrap">From: </th>
      <td><a class="moz-txt-link-abbreviated" href="mailto:voremo@SAFe-mail.net">voremo@SAFe-mail.net</a></td>
    </tr>
    <tr>
      <th valign="baseline" align="right" nowrap="nowrap">To: </th>
      <td><a class="moz-txt-link-abbreviated" href="mailto:gustavo.hlv@gmx.net">gustavo.hlv@gmx.net</a></td>
    </tr>
  </tbody>
</table>
<br>
<br>
<pre>Hi Gustavo,