gpg "simplified"?
yyy
yyy at yyy.id.lv
Tue Jul 31 07:11:00 CEST 2012
On 2012.07.30. 15:51, peter.segment at wronghead.com wrote:
> I have been asked to help a small group of individuals
> (perhaps hundreds, not thousands) with secure data exchange
> (including, but not restricted to e-mail).
>
> Use of full gpg is way beyond their capabilities. I am
> wondering if anybody has heard of a simplified version
> of gpg; or failing that, I would like to hear any comments
> on the feasibility of a collaborative project to create
> such a variant, as I am convinced there would have to be
> a wider applicability of it.
>
> The following describes the requirements:
>
> 1) The program is CLI and operates on (i.e., it encrypts and
> decrypts) binary files. It has no connection with any mail
> client program or server or mail service and provides
> no key management functionality whatsoever.
gpg is a CLI program which encrypts and decrypts binary files,
by default it has no connection with any mail server or service
openssl smime tool does the same, and unlike gpg, has no key
management functionality (for encryption and decryption only)
(it does have size limits, it needs as much memory, as size
of file to be encrypted or decrypted)
> 2) Once encrypted with a (single!) recipients public key, the
> file consists of bytes indistinguishable from a random stream.
this probably will not be possible with standard openpgp (or smime)
> 3) The program can be run from removable media, i.e., it
> requires no installation and assumes no network access for
> either key exchange or in operation. There are binaries
> for all three major platforms (Win32, Linux and Mac OSX).
I have heard, that gpg 1.4 supports such operation, but
have not tested it myself. gpg2 certainly will not work.
openssl some times works, some times not.
(I have tested only on windows, there have been some dependencies
on system dlls).
> 4) Single key, public or private, resides in a single
> file. This file is encrypted with operator's public key
> and consists of bytes indistinguishable from a random byte
> stream.
this probably will not be possible with standard openpgp (or smime)
if private key is encrypted with it's public key, it becomes
inaccessible, because unencrypted private key is needed
to decrypt it.
> 5) Public key includes a textual description, but no
> unique identification other than the hash of the key.
>
gpg keys can be generated this way, x509 certs also
can be generated this way.
More information about the Gnupg-users
mailing list