config.txt1006440006630000000000000755105646601413011535 037777703jissystem 1 0 # Sample config.txt file for PGP 2.6.2. # Blank lines are ignored, as is anything following a '#'. # Keywords are not case-sensitive. # Whatever appears in here can be overridden on the command line, # by specifying (for example) "+armor=on". # MyName is substring of default user ID for secret key to make signatures. # If not set, PGP will use the first key on your secret keyring (the last # key you created) if you don't specify the user with -u # MyName = "John Q. Public" # The language we will be using for displaying messages to the user. # # Available languages: # en = English (default), es = Spanish, fr = French, # de = German, it = Italian, br = Brazilian portuguese # # Languages not yet available: # esp = Esperanto, lv = Latvian, lt3 = Lithuanian, # ru = Russian, nl = Dutch, # fi = Finnish, # hu = Hungarian, no = Norwegian, pt = Portugese, # sv = Swedish, da = Danish, is = Icelandic, # zh = Chinese, ko = Korean, ar = Arabic, iw = Hebrew, # el = Greek, tr = Turkish, ja = Japanese # # Most of these codes are the ISO 639-1988 2-letter "Codes for # Representation of Names of Languages" # Language = en # Character set for displaying messages and for conversion of text files. # If you set this variable to cp850, ascii or alt_codes, PGP will do # character set conversions if TextMode = on or if you specify the -t # option when encrypting or signing a file. # # Available character sets: # latin1, cp850, alt_codes, koi8, ascii # # For MSDOS with a standard character set you should use cp850 to get # correct character translations. Russian character sets for MSDOS are # usually alt_codes. # # The default for CharSet is "noconv" which means no character conversion. # Note that noconv, latin1, and koi8 are all treated as equivalent. # # CharSet = cp850 # TMP is the directory name for PGP scratch files, usually a RAM disk. # TMP = "e:\" # Can be overridden by environment variable TMP # Pager is the file viewing program used for viewing messages with -m # If not set or set to "pgp", a built-in pager will be used. The pager set # in config.txt will override the environment variable PAGER. # Pager = "list" # ArmorLines is the maximum number of lines per packet when creating a # transport armored file. Set to 0 to disable splitting in parts. Armorlines = 720 # The following commented-out settings are *not* the defaults. # Uncomment (remove the leading "#" character) them to get the # non-default behaviour indicated. # Armor = on # Use -a flag for ASCII armor whenever applicable # TextMode = on # Attempt to use -t option where applicable clearsig = on # Use unarmored plaintext for unencrypted signed message # KeepBinary = on # Decrypt will not delete intermediate .pgp file # verbose = 2 # verbose diagnostic messages # verbose = 0 # be quiet # compress = off # off means suppress compression to aid debugging # showpass = on # Echo password when user types it # BakRing is the path to a backup copy of your secret keyring, usually # on floppy disk. Your secret keys will be compared with the backup copy # when doing a keyring check (pgp -kc) # BakRing = "a:\secring.pgp" # Number of completely trusted signatures needed to make a key valid. Completes_Needed = 1 # Number of marginally trusted signatures needed to make a key valid. Marginals_Needed = 2 # How many levels of introducers may introduce other introducers. Cert_Depth = 4 # TZFix is hours to add to time() to get GMT, for GMT timestamps. # Since MSDOS assumes local time is US Pacific time, and pre-corrects # Pacific time to GMT, make TZFix=0 for California, -1 for Colorado, # -2 for Chicago, -3 for NY, -8 for London, -9 for Amsterdam. # However, if your MSDOS environmental variable TZ is properly defined # for your timezone, you can leave TZFix=0. Unix systems probably # shouldn't need to worry about setting TZFix. # TZFix = 0 contrib/0407550006630000000000000000005650065021006650 5 0 1 0 contrib/langtool/0407550006630000000000000000005650064755010504 5 0 1 0 contrib/langtool/charconv.c1004440006630000000000000367505562520522013226 037777703401 1 0 #include static unsigned char intern2cp850[] = { /* ISO 8859-1 Latin Alphabet 1 (Latin-1) to IBM Code Page 850 */ 186, 205, 201, 187, 200, 188, 204, 185, 203, 202, 206, 223, 220, 219, 254, 242, 179, 196, 218, 191, 192, 217, 195, 180, 194, 193, 197, 176, 177, 178, 213, 159, 255, 173, 189, 156, 207, 190, 221, 245, 249, 184, 166, 174, 170, 240, 169, 238, 248, 241, 253, 252, 239, 230, 244, 250, 247, 251, 167, 175, 172, 171, 243, 168, 183, 181, 182, 199, 142, 143, 146, 128, 212, 144, 210, 211, 222, 214, 215, 216, 209, 165, 227, 224, 226, 229, 153, 158, 157, 235, 233, 234, 154, 237, 232, 225, 133, 160, 131, 198, 132, 134, 145, 135, 138, 130, 136, 137, 141, 161, 140, 139, 208, 164, 149, 162, 147, 228, 148, 246, 155, 151, 163, 150, 129, 236, 231, 152 }; static unsigned char cp8502intern[] = { /* IBM Code Page 850 to Latin-1 */ 199, 252, 233, 226, 228, 224, 229, 231, 234, 235, 232, 239, 238, 236, 196, 197, 201, 230, 198, 244, 246, 242, 251, 249, 255, 214, 220, 248, 163, 216, 215, 159, 225, 237, 243, 250, 241, 209, 170, 186, 191, 174, 172, 189, 188, 161, 171, 187, 155, 156, 157, 144, 151, 193, 194, 192, 169, 135, 128, 131, 133, 162, 165, 147, 148, 153, 152, 150, 145, 154, 227, 195, 132, 130, 137, 136, 134, 129, 138, 164, 240, 208, 202, 203, 200, 158, 205, 206, 207, 149, 146, 141, 140, 166, 204, 139, 211, 223, 212, 210, 245, 213, 181, 254, 222, 218, 219, 217, 253, 221, 175, 180, 173, 177, 143, 190, 182, 167, 247, 184, 176, 168, 183, 185, 179, 178, 142, 160 }; main(argc, argv) char **argv; { int c; if (argc < 2 || strcmp(argv[1], "int") && strcmp(argv[1], "ext")) { fprintf(stderr, "usage: convert [int|ext] [file]\n"); exit(1); } if (argc > 2) { if (freopen(argv[2], "r", stdin) == NULL) { perror(argv[2]); exit(1); } } if (strcmp(argv[1], "int")) while ((c = getchar()) != EOF) putchar(c & 0x80 ? intern2cp850[c&0x7f] : c); else while ((c = getchar()) != EOF) putchar(c & 0x80 ? cp8502intern[c&0x7f] : c); exit(0); } contrib/langtool/crc.c1004440006630000000000000662405562520522012167 037777703401 1 0 /************************************************************************/ /* CRC Routines. */ /* These CRC functions are derived from code in chapter 19 of the book "C Programmer's Guide to Serial Communications", by Joe Campbell. Generalized to any CRC width by Philip Zimmermann. */ #define byte unsigned char #define CRCBITS 24 /* may be 16, 24, or 32 */ /* #define crcword unsigned short */ /* if CRCBITS is 16 */ #define crcword unsigned long /* if CRCBITS is 24 or 32 */ /* #define maskcrc(crc) ((crcword)(crc)) */ /* if CRCBITS is 16 or 32 */ #define maskcrc(crc) ((crc) & 0xffffffL) /* if CRCBITS is 24 */ #define CRCHIBIT ((crcword) (1L<<(CRCBITS-1))) /* 0x8000 if CRCBITS is 16 */ #define CRCSHIFTS (CRCBITS-8) /* Notes on making a good 24-bit CRC-- The primitive irreducible polynomial of degree 23 over GF(2), 040435651 (octal), comes from Appendix C of "Error Correcting Codes, 2nd edition" by Peterson and Weldon, page 490. This polynomial was chosen for its uniform density of ones and zeros, which has better error detection properties than polynomials with a minimal number of nonzero terms. Multiplying this primitive degree-23 polynomial by the polynomial x+1 yields the additional property of detecting any odd number of bits in error, which means it adds parity. This approach was recommended by Neal Glover. To multiply the polynomial 040435651 by x+1, shift it left 1 bit and bitwise add (xor) the unshifted version back in. Dropping the unused upper bit (bit 24) produces a CRC-24 generator bitmask of 041446373 octal, or 0x864cfb hex. You can detect spurious leading zeros or framing errors in the message by initializing the CRC accumulator to some agreed-upon nonzero "random-like" value, but this is a bit nonstandard. */ #define CCITTCRC 0x1021 /* CCITT's 16-bit CRC generator polynomial */ #define PRZCRC 0x864cfbL /* PRZ's 24-bit CRC generator polynomial */ #define CRCINIT 0xB704CEL /* Init value for CRC accumulator */ crcword crctable[256]; /* Table for speeding up CRC's */ /* crchware simulates CRC hardware circuit. Generates true CRC directly, without requiring extra NULL bytes to be appended to the message. Returns new updated CRC accumulator. */ crcword crchware(byte ch, crcword poly, crcword accum) { int i; crcword data; data = ch; data <<= CRCSHIFTS; /* shift data to line up with MSB of accum */ i = 8; /* counts 8 bits of data */ do { /* if MSB of (data XOR accum) is TRUE, shift and subtract poly */ if ((data ^ accum) & CRCHIBIT) accum = (accum<<1) ^ poly; else accum <<= 1; data <<= 1; } while (--i); /* counts 8 bits of data */ return (maskcrc(accum)); } /* crchware */ /* mk_crctbl derives a CRC lookup table from the CRC polynomial. The table is used later by crcupdate function given below. mk_crctbl only needs to be called once at the dawn of time. */ void mk_crctbl(crcword poly) { int i; for (i=0; i<256; i++) crctable[i] = crchware((byte) i, poly, 0); } /* mk_crctbl */ /* crcupdate calculates a CRC using the fast table-lookup method. Returns new updated CRC accumulator. */ crcword crcupdate(byte data, register crcword accum) { byte combined_value; /* XOR the MSByte of the accum with the data byte */ combined_value = (accum >> CRCSHIFTS) ^ data; accum = (accum << 8) ^ crctable[combined_value]; return (maskcrc(accum)); } /* crcupdate */ /* Initialize the CRC table using our codes */ void init_crc() { mk_crctbl(PRZCRC); } r sets: # latin1, cp850, alt_codes, koi8, ascii # # For MSDOS with a standard character set you should usecontrib/langtool/getopt.c1004440006630000000000000417205562520522012716 037777703401 1 0 /* ** @(#)getopt.c 2.5 (smail) 9/15/87 */ /* * This is the AT&T public domain source for getopt(3). It is the code * which was given out at the 1985 UNIFORUM conference in Dallas. * * There is no manual page. That is because the one they gave out at * UNIFORUM was slightly different from the current System V Release 2 * manual page. The difference apparently involved a note about the * famous rules 5 and 6, recommending using white space between an * option and its first argument, and not grouping options that have * arguments. Getopt itself is currently lenient about both of these * things. White space is allowed, but not mandatory, and the last option * in a group can have an argument. That particular version of the man * page evidently has no official existence. The current SVR2 man page * reflects the actual behavor of this getopt. */ #include #include #include "getopt.h" /*LINTLIBRARY*/ #ifndef NULL #define NULL 0 #endif #define EOF (-1) #define ERR(str, chr) (opterr ? fprintf(stderr, "%s%s%c\n", argv[0], str, chr) : 0) int opterr = 1; int optind = 1; int optopt = 0; char *optarg = 0; int getopt(int argc, char **argv, char *opts) { static int sp = 1; register int c; register char *cp; if(sp == 1) { if(optind >= argc || (argv[optind][0] != '+' && argv[optind][0] != '-') || argv[optind][1] == '\0') return EOF; else if(strcmp(argv[optind], "--") == 0) { optind++; return EOF; } /* '+' for config options, '+' should not be in the opts list */ if (argv[optind][0] == '+') { optarg = argv[optind++] + 1; return '+'; } } optopt = c = argv[optind][sp]; if(c == ':' || (cp=strchr(opts, c)) == NULL) { ERR(": illegal option -- ", c); if(argv[optind][++sp] == '\0') { optind++; sp = 1; } return '\0'; } if(*++cp == ':') { if(argv[optind][sp+1] != '\0') optarg = &argv[optind++][sp+1]; else if(++optind >= argc) { ERR(": option requires an argument -- ", c); sp = 1; return '\0'; } else optarg = argv[optind++]; sp = 1; } else { if(argv[optind][++sp] == '\0') { sp = 1; optind++; } optarg = NULL; } return c; } 0000000000005650065021006650 5 0 1 0 contrib/langtool/getopt.h1004440006630000000000000014605562520524012722 037777703401 1 0 #ifndef UNIX /* avoid conflict with stdlib.h */ int getopt(int argc, char **argv, char *opts); #endif 04440006630000000000000367505562520522013226 037777703401 1 0 contrib/langtool/killdups.c1004440006630000000000000347105562520524013246 037777703401 1 0 /* * killdups.c * Remove duplicate quoted strings in a file * After each outputted quoted string, adds the PLACEHOLDER */ #include #include #include #if 0 #define PLACEHOLDER "No translation\n" #else #define PLACEHOLDER "" #endif struct strbuf { char *s; struct strbuf *l, *r; } *top; main () { char *str, *getstr(); while (str = getstr()) { if (!inlistadd (str)) { putstr (str); } } } char * getstr () { static char buf[4096]; char *bp; int c; int bslash; char *sbuf; bp = buf; while ((c = getchar()) != EOF && c != '"') ; if (c == EOF) return NULL; bslash = 0; while ((c = getchar()) != EOF) { if (bslash) { *bp++ = c; bslash = 0; } else { if (c == '"') break; if (c == '\\') bslash = 1; *bp++ = c; } if (bp - buf >= sizeof(buf)) { fprintf (stderr, "String too long\n"); exit (2); } } *bp++ = '\0'; sbuf = malloc (bp - buf); if (!sbuf) { fprintf (stderr, "Out of memory\n"); exit (1); } strcpy (sbuf, buf); return sbuf; } int putstr (s) char *s; { printf ("\"%s\"\n%s\n", s, PLACEHOLDER); } int inlistadd (s) char *s; { int delta; struct strbuf *list; if (top == NULL) { newentry (&top, s); return 0; } list = top; for ( ; ; ) { delta = strcmp (s, list->s); if (delta == 0) return 1; /* Already in list */ if (delta > 0) { if (list->r == NULL) { newentry (&list->r, s); return 0; } else list = list->r; } else { if (list->l == NULL) { newentry (&list->l, s); return 0; } else list = list->l; } } } int newentry (alist, s) struct strbuf **alist; char *s; { *alist = (struct strbuf *)malloc (sizeof(struct strbuf)); if (*alist == NULL) { fprintf (stderr, "Out of memory\n"); exit (3); } (*alist)->s = s; (*alist)->l = (*alist)->r = NULL; } 1 0 contrib/langtool/language.c1004440006630000000000003177205562662006013211 037777703401 1 0 /* * language.c - Foreign language translation for PGP * Finds foreign language "subtitles" for English phrases * in external foriegn language text file. */ #include #include #include #include #include "usuals.h" #ifndef LANGTOOL #include "fileio.h" #include "language.h" #include "pgp.h" #else #define MAX_PATH 255 boolean verbose; long fsize(); #endif char langfile[80] = "language.txt"; #define LANG_INDEXFILE "language.idx" #define STRBUFSIZE 2048 char language[16] = "en"; /* The language code, defaults to English */ static char *strbuf; static char lang[16]; /* readstr sets this to the language id of the msg it last read */ static int subtitles_available = 0; static int line = 0; static int errcount = 0; /* subtitles_available is used to determine if we know whether the special subtitles_file exists. subtitles_available has the following values: 0 = first time thru, we don't yet know if subtitles_file exists. 1 = we have already determined that subtitles_file exists. -1 = we have already determined that subtitles_file does not exist. */ static void error(char *); #define NEWLINE 0 #define COMMENT 1 #define INSTRING 2 #define ESCAPE 3 #define IDENT 4 #define DONE 5 #define ERROR 6 #define ERR1 7 /* Look for and return a quoted string from the file. * If nlabort is true, return failure if we find a blank line * before we find the opening quote. */ static char * readstr (FILE *f, char *buf, int nlabort) { int c, d; char *p = buf; int state = NEWLINE; int i = 0; while ((c = getc(f)) != EOF) { if (c == '\r') continue; /* line numbers are only incremented when creating index file */ if (line && c == '\n') ++line; switch (state) { case NEWLINE: switch(c) { case '#': state = COMMENT; break; case '"': state = INSTRING; break; case '\n': if (nlabort) { *buf = '\0'; return(buf); } default: if (i == 0 && isalnum(c)) { state = IDENT; lang[i++] = c; break; } if (!isspace(c)) { error("syntax error\n"); state = ERROR; } } break; case COMMENT: if (c == '\n') state = NEWLINE; break; case INSTRING: switch(c) { case '\\': state = ESCAPE; break; case '"': state = DONE; break; default: *p++ = c; } break; case ESCAPE: switch (c) { case 'n': *p++ = '\n'; break; case 'r': *p++ = '\r'; break; case 't': *p++ = '\t'; break; case 'e': *p++ = '\033'; break; case 'a': *p++ = '\007'; break; case '#': case '"': case '\\': *p++ = c; break; case '\n': break; case '0': case '1': case '2': case '3': case '4': case '5': case '6': case '7': /* ANSI C rules: up to 3 octal digits */ d = c - '0'; if ((c = getc(f)) >= '0' && c <= '7') { d = (d<<3) + (c-'0'); if ((c = getc(f)) >= '0' && c <= '7') d = (d<<3) + (c-'0'); else ungetc(c, f); } else { ungetc(c, f); } *p++ = d; break; default: error("illegal escape sequence: "); fprintf(stderr, "'\\%c'\n", c); break; } state = INSTRING; break; case IDENT: /* language identifier */ if (c == ':') { state = NEWLINE; break; } if (c == '\n' && strncmp(lang, "No translation", 14) == 0) { i = 0; state = NEWLINE; break; } lang[i++] = c; if (i == 15 || !isalnum(c) && !isspace(c)) { lang[i] = '\0'; error("bad language identifier\n"); state = ERROR; i = 0; } break; case DONE: if (c == '\n') { lang[i] = '\0'; *p = '\0'; return(buf); } if (!isspace(c)) { error("extra characters after '\"'\n"); state = ERROR; } break; case ERROR: if (c == '\n') state = ERR1; break; case ERR1: state = (c == '\n' ? NEWLINE : ERROR); break; } } if (state != NEWLINE) error("unexpected EOF\n"); return(NULL); } static struct indx_ent { word32 crc; long offset; } *indx_tbl = NULL; static int max_msgs = 0; static int nmsg = 0; static FILE *langf; static struct { long lang_fsize; /* size of language.txt */ char lang[16]; /* language identifier */ int nmsg; /* number of messages */ } indx_hdr; static int make_indexfile(char *); word32 crcupdate(byte, word32); void init_crc(); /* * uses 24-bit CRC function from armor.c */ static word32 message_crc(char *s) { word32 crc = 0; while (*s) crc = crcupdate(*s++, crc); return(crc); } /* * lookup file offset in indx_tbl */ static long lookup_offset(word32 crc) { int i; for (i = 0; i < nmsg; ++i) if (indx_tbl[i].crc == crc) return(indx_tbl[i].offset); return(-1); } #ifndef LANGTOOL static void init_lang(); /* * return foreign translation of s */ char * PSTR (char *s) { long filepos; if (subtitles_available == 0) init_lang(); if (subtitles_available < 0) return(s); filepos = lookup_offset(message_crc(s)); if (filepos == -1) { return(s); } else { fseek(langf, filepos, SEEK_SET); readstr(langf, strbuf, 1); } if (strbuf[0] == '\0') return(s); for (s = strbuf; *s; ++s) *s = EXT_C(*s); return(strbuf); } /* * initialize the index table: read it from language.idx or create * a new one and write it to the index file. A new index file is * created if the language set in config.pgp doesn't match the one * in language.idx or if the size of language.txt has changed. */ static void init_lang() { char indexfile[MAX_PATH]; char subtitles_file[MAX_PATH]; FILE *indexf; if (strcmp(language, "en") == 0) { subtitles_available = -1; return; /* use default messages */ } buildfilename (subtitles_file, langfile); if ((langf = fopen(subtitles_file, "rb")) == NULL) { subtitles_available = -1; return; } init_crc(); if ((strbuf = (char *) malloc(STRBUFSIZE)) == NULL) { fprintf(stderr, "Not enough memory for foreign subtitles\n"); fclose(langf); subtitles_available = -1; return; } buildfilename(indexfile, LANG_INDEXFILE); if ((indexf = fopen(indexfile, "rb")) != NULL) { if (fread(&indx_hdr, sizeof(indx_hdr), 1, indexf) == 1 && indx_hdr.lang_fsize == fsize(langf) && strcmp(indx_hdr.lang, language) == 0) { nmsg = indx_hdr.nmsg; indx_tbl = (struct indx_ent *) malloc(nmsg * sizeof(struct indx_ent)); if (indx_tbl == NULL) { fprintf(stderr, "Not enough memory for foreign subtitles\n"); fclose(indexf); fclose(langf); subtitles_available = -1; return; } if (fread(indx_tbl, sizeof(struct indx_ent), nmsg, indexf) != nmsg) { free(indx_tbl); /* create a new one */ indx_tbl = NULL; } } fclose(indexf); } if (indx_tbl == NULL && make_indexfile(indexfile) < 0) { fclose(langf); subtitles_available = -1; } else { subtitles_available = 1; } } #endif /* !LANGTOOL */ /* * build the index table in memory, and if indexfile is not NULL, * write it to this file */ static int make_indexfile(char *indexfile) { FILE *indexf; long filepos; int total_msgs = 0; char *res; rewind(langf); indx_hdr.lang_fsize = fsize(langf); strncpy(indx_hdr.lang, language, 15); init_crc(); line = 1; nmsg = 0; while (readstr(langf, strbuf, 0)) { if (nmsg == max_msgs) { if (max_msgs) { max_msgs *= 2; indx_tbl = (struct indx_ent *) realloc(indx_tbl, max_msgs * sizeof(struct indx_ent)); } else { max_msgs = 400; indx_tbl = (struct indx_ent *) malloc(max_msgs * sizeof(struct indx_ent)); } if (indx_tbl == NULL) { fprintf(stderr, "Not enough memory for foreign subtitles\n"); return(-1); } } ++total_msgs; indx_tbl[nmsg].crc = message_crc(strbuf); if (lookup_offset(indx_tbl[nmsg].crc) != -1) error("message CRC not unique.\n"); do { filepos = ftell(langf); res = readstr (langf, strbuf, 1); /* Abort if find newline first */ if (*language == '\0') /* use first language found */ strcpy(language, lang); } while (res && strbuf[0] != '\0' && strcmp(language, lang) != 0); if (res == NULL) break; if (strbuf[0] == '\0') /* No translation */ continue; indx_tbl[nmsg].offset = filepos; ++nmsg; do res = readstr (langf, strbuf, 1); /* Abort if find newline first */ while (res && strbuf[0] != '\0'); } line = 0; indx_hdr.nmsg = nmsg; if (verbose) fprintf(stderr, "%s: %d messages, %d translations for language \"%s\"\n", langfile, total_msgs, nmsg, language); if (nmsg == 0) { fprintf(stderr, "No translations available for language \"%s\"\n\n", language); return(-1); } if (indexfile) { if ((indexf = fopen(indexfile, "wb")) == NULL) fprintf(stderr, "Cannot create %s\n", indexfile); else { fwrite(&indx_hdr, 1, sizeof(indx_hdr), indexf); fwrite(indx_tbl, sizeof(struct indx_ent), nmsg, indexf); if (ferror(indexf) || fclose(indexf)) fprintf(stderr, "error writing %s\n", indexfile); } } return(0); } static void error(char *s) { ++errcount; if (langfile[0]) fprintf(stderr, "%s:", langfile); if (line) fprintf(stderr, "%d:", line); fprintf(stderr, " %s", s); } #ifdef LANGTOOL /* * language string tool for manipulating language files * link with CRC routines from armor.c */ #define CMD_EXTRACT 1 #define CMD_CHECK 2 #define CMD_MERGE 3 extern char *optarg; extern int optind; main(int argc, char **argv) { int opt, cmd = 0, rc = 0; char *langIDs[16]; char *outfile = NULL; init_crc(); if ((strbuf = (char *) malloc(STRBUFSIZE)) == NULL) { perror(argv[0]); exit(1); } while ((opt = getopt(argc, argv, "cxmo:")) != EOF) { switch (opt) { case 'c': cmd = CMD_CHECK; break; case 'x': cmd = CMD_EXTRACT; break; case 'm': cmd = CMD_MERGE; break; case 'o': outfile = optarg; break; default: usage(); } } argc -= optind; argv += optind; switch (cmd) { case CMD_EXTRACT: if (argc < 2) usage(); rc = extract(argv[0], outfile, &argv[1]); break; case CMD_MERGE: if (argc < 2) usage(); rc = merge(argv[0], argv[1], outfile, argv[2]); break; case CMD_CHECK: verbose = 1; if (argc == 0) checkfile("language.txt"); else while (--argc >= 0) checkfile(*argv++); break; default: usage(); } exit(rc); } usage() { fprintf(stderr, "usage: langtool -[x|c|m] [-o outputfile] ...\n\n\ To extract one or more languages from a merged file:\n\ langtool -x [-o outputfile] file langID...\n\n\ To check a language file for syntax errors:\n\ langtool -c file...\n\n\ To merge language \"lang\" from lang_file with source_file:\n\ langtool -m [-o outputfile] source_file lang_file [lang]\n"); exit(1); } merge(char *base_file, char *lang_file, char *outfile, char *langID) { FILE *fp, *outf; long fpos = 0, filepos; int newmsgs = 0; if ((langf = fopen(lang_file, "r")) == NULL) { perror(lang_file); return -1; } strcpy(langfile, lang_file); if (langID) strcpy(language, langID); else language[0] = '\0'; /* use first language found */ errcount = 0; make_indexfile(NULL); if (errcount) return -1; langfile[0] = '\0'; /* don't print filename in error msgs */ if ((fp = fopen(base_file, "r")) == NULL) { perror(base_file); return -1; } if (outfile == NULL) outf = stdout; else { if ((outf = fopen(outfile, "w")) == NULL) { perror(outfile); return(-1); } } while (readstr(fp, strbuf, 0)) { copypos(fp, outf, fpos); fpos = ftell(fp); filepos = lookup_offset(message_crc(strbuf)); if (filepos == -1) { fprintf(outf, "No translation\n"); ++newmsgs; } else { fseek(langf, filepos, SEEK_SET); readstr(langf, strbuf, 1); copypos(langf, outf, filepos); } while (readstr(fp, strbuf, 1)) if (*strbuf == '\0') break; } copypos(fp, outf, fpos); fflush(outf); if (ferror(outf)) { perror(outfile); return -1; } if (newmsgs) fprintf(stderr, "%d untranslated messages\n", newmsgs); return errcount; } extract(char *infile, char *outfile, char **langIDs) { FILE *fp, *outf; long fpos = 0; char **langID; if ((fp = fopen(infile, "r")) == NULL) { perror(infile); return -1; } if (outfile == NULL) { outf = stdout; } else { if ((outf = fopen(outfile, "w")) == NULL) { perror(outfile); fclose(fp); return(-1); } } while (readstr(fp, strbuf, 0)) { copypos(fp, outf, fpos); fpos = ftell(fp); while (readstr(fp, strbuf, 1)) { if (*strbuf == '\0') break; for (langID = langIDs; *langID; ++langID) { if (strcmp(lang, *langID) == 0) copypos(fp, outf, fpos); } fpos = ftell(fp); } } copypos(fp, outf, fpos); fflush(outf); if (ferror(outf)) { perror(outfile); return -1; } return 0; } checkfile(char *name) { if ((langf = fopen(name, "rb")) == NULL) { perror(name); return -1; } strcpy(langfile, name); language[0] = '\0'; /* count messages for first language */ errcount = 0; make_indexfile(NULL); fclose(langf); return errcount; } copypos(FILE *f, FILE *g, long pos) { long size; size = ftell(f) - pos; fseek(f, pos, SEEK_SET); copyfile(f, g, size); } copyfile(FILE *f, FILE *g, long n) { int c; while (--n >= 0 && (c = getc(f)) != EOF) putc(c, g); } long fsize(FILE *f) { long len, pos; pos = ftell(f); fseek(f, 0L, SEEK_END); len = ftell(f); fseek(f, pos, SEEK_SET); return len; } #endif /* LANGTOOL */ defaulcontrib/langtool/makefile1004440006630000000000000060005562520524012742 037777703401 1 0 # Makefile for language tools # # E= .exe CFLAGS= -O all: langtool$E charconv$E pickpstr$E killdups$E langtool$E: language.c crc.c $(CC) $(CFLAGS) -DLANGTOOL language.c crc.c -o $@ charconv$E: charconv.c $(CC) $(CFLAGS) charconv.c -o $@ pickpstr$E: pickpstr.c $(CC) $(CFLAGS) pickpstr.c -o $@ killdups$E: killdups.c $(CC) $(CFLAGS) killdups.c -o $@ langtool.c: usuals.h rn(NULL); } static struct indx_ent { word32 crc; long offset; } *indx_tbl = NULL; static int max_msgs = 0; static int nmsg contrib/langtool/pickpstr.c1004440006630000000000000204305562520524013250 037777703401 1 0 /* * pickpstr.c * Read a set of files. * Find all strings of the form PSTR("..."). * Output them, minus the enclosing PSTR( and ) to stdout. */ #include #define STR "LANG(\"" main (ac, av) char **av; { int copying, match, bslash; FILE *f; int c; if (ac < 2) { fprintf (stderr, "Usage: %s file [...]\n", av[0]); exit (1); } while (*++av) { if ((f = fopen (*av, "r")) == NULL) { fprintf (stderr, "Unable to open file %s, skipping\n"); continue; } match = 0; copying = 0; while ((c = getc(f)) != EOF) { if (!copying) { if (c == STR[match]) { if (++match == strlen(STR)) { copying = 1; match = 0; bslash = 0; putchar (c); } } else match = 0; } else { if (!bslash) { if (c == '"') { putchar (c); putchar ('\n'); putchar ('\n'); copying = 0; } else if (c == '\\') { bslash = 1; putchar (c); } else putchar (c); } else { putchar (c); bslash = 0; } } } fclose (f); } exit (0); } } buildfilename (subtitles_file, langfile); if ((langf = fopen(subtitles_file, "rb")) == NULL) { subtitles_available = -1; return; } init_crc(); if ((strbuf = (char *) malloc(STRBUFSIZE)) == NULL) { fprintf(stderr, "Not enough memory for foreign subtitles\n"); fclose(langf); subtitles_available = -1; return; } buildfilename(indexfile, LANG_INDEXFILE); if ((indexf = fopen(indexfile, "rb")) != NULL) { if (fread(&indx_hdr, sizeof(indx_hdr), 1, indexf)contrib/langtool/usuals.h1004440006630000000000000140705562520524012735 037777703401 1 0 /* usuals.h - The usual typedefs, etc. */ #ifndef USUALS /* Assures no redefinitions of usual types...*/ #define USUALS typedef unsigned char boolean; /* values are TRUE or FALSE */ typedef unsigned char byte; /* values are 0-255 */ typedef byte *byteptr; /* pointer to byte */ typedef char *string; /* pointer to ASCII character string */ typedef unsigned short word16; /* values are 0-65535 */ typedef unsigned long word32; /* values are 0-4294967295 */ #ifndef TRUE #define FALSE 0 #define TRUE (!FALSE) #endif /* if TRUE not already defined */ #ifndef min /* if min macro not already defined */ #define min(a,b) ( (a)<(b) ? (a) : (b) ) #define max(a,b) ( (a)>(b) ? (a) : (b) ) #endif /* if min macro not already defined */ #endif /* if USUALS not already defined */ tbl = (struct indx_ent *) malloc(max_msgs * sizeof(struct indx_ent)); } if (indx_tbl == NULL) { fprintf(stderr, "Not enough memory for foreign subtitles\n"); return(-1); } } ++total_msgs; indx_tbl[nmsg].crc = message_crcontrib/langtool/readme1006440006630000000000001132405643700736012436 037777703401 1 0 PGP Foreign Language Tools -------------------------- The "langtool" directory contains tools for manipulating foreign language translations for PGP's prompts and error messages. The makefile is for Unix; the tools don't build cleanly under MS-DOS, although a little hacking should fix that. One problem is that the code assumes getopt() is in the standard library, which it usually isn't with MS-DOS compilers, but you can steal getopt.c from the PGP source to fix that one. In any case, the programs are: pickpstr - this takes a list of filenames on the command line, searches them for LANG("...") constructs, and emits the "..." strings on standard output. This is used to extract the strings to be translated from the PGP source. The strings are found by searching for the 6-character LANG(" sequence. Any spaces cause the string to be missed. (the name comes from PSTR(), the macro that was replaced by LANG().) killdups - this copies the outout of pickpstr from stdin to stdout, stripping out duplicates. charconv - this converts between ISO Latin-1 and IBM PC code page 850 character sets. langtool - this is the big one, that merges various translation files, reporting which translations are missing, and so on. It can extract a translation, merge translations, or check translation files for errors. The following notes were written by Branko Lankester for PGP 2.3a. --------------------------------------------------------------------- PGP language tools. This is set of tools to maintain the PGP language files, with these tools you can find new messages in the PGP source code and add them to your language file. You can also merge multiple languages into one file and extract languages from a merged file. Two programs are needed to extract the PSTR messages from the PGP source code: "pickpstr" and "killdups", the batch file extract.bat will run these programs on the PGP source files in the right order (the order is important if you want to use diff to find differences). You must run extract.bat in the pgp src directory, this will create the file "pstrmsgs". I have included this file with these tools. To create an up-to-date language file with one or more translations you must use the "langtool" program with the merge (-m) option: langtool -m -o newfile.txt pstrmsgs language.txt language.txt is the old language file with your translations. If there is more than one language in this file you must specify the language identifier after the filename. The output file "newfile.txt" will contain all messages from "pstrmsgs" and the translations from "language.txt", new messages that are not present in language.txt will have the line: No translation instead of the translated message, so you can use the "find" command of your editor to find the untranslated messages by searching for this string. If you want to combine several languages into one file you can also use "langtool" with the -m option: langtool -m -o language.txt lang1.txt lang2.txt This will add the language in lang2.txt to the combined language file "lang1.txt", the merged output will be in "language.txt". If you want to add another language, run the same command again, but use the output file from the last command (language.txt) as first inputfile: langtool -m -o outfile.txt language.txt lang3.txt "langtool -m" will use all translations from the first inputfile, and one translation from the second input file. If the second file contains more than one language, you can specify the language you want after the last filename. You can also use langtool to extract one or more languages from a combined language file: langtool -x -o es-nl.txt language.txt es nl will extract the languages with identifiers "es" and "nl" from language.txt to the file "es-nl.txt" If you want to run a simple check on a language file (the same check that is done when pgp creates an index file), you can use the -c option: langtool -c language.txt This will print the number of messages, and the number of translations. A language file for distribution should be in the PGP internal character set: latin-1, for Russian it should be in KOI8. This means that if your system doesn't use a latin-1 or KOI8 character set you will have to convert the language file to this internal format before you add it to the distribution. You can use the "charconv" program to do this: charconv int language.in >language.txt will convert from cp850 to the latin-1 internal format. To convert from internal to external, use "charconv ext file_name". For conversion between Russian character sets you need a different program. Harry Bush has sent me such a program, I assume the Russian translators already have this program, but if someone needs it, I can send it to you. Branko ); copyfile(f, g, size); } copyfile(FILE *f, FILE *g, long n) { int c; while (--n >= 0 && (c = getc(f)) != EOF) putc(c, g); } long fsize(FILE *f) { long len, pos; pos = ftell(f); fseek(f, 0L, SEEK_END); len = ftell(f); fseek(f, pos, SEEK_SET); return len; } #endif /* LANGTOOL */ defaulcontrib/md5sum/0407550006630000000000000000005652314217010070 5 0 1 0 contrib/md5sum/md5sum.c1004440006630000000000001176605407327574012242 037777703401 1 0 /* * md5sum.c - Generate/check MD5 Message Digests * * Compile and link with md5.c. If you don't have getopt() in your library * also include getopt.c. For MSDOS you can also link with the wildcard * initialization function (wildargs.obj for Turbo C and setargv.obj for MSC) * so that you can use wildcards on the commandline. * * Written March 1993 by Branko Lankester * Modified June 1993 by Colin Plumb for altered md5.c. */ #include #include #include "md5.h" #ifdef UNIX #define FOPRTXT "r" #define FOPRBIN "r" #else #ifdef VMS #define FOPRTXT "r","ctx=stm" #define FOPRBIN "rb","ctx=stm" #else #define FOPRTXT "r" #define FOPRBIN "rb" #endif #endif extern char *optarg; extern int optind; void usage(); void print_digest(); int mdfile(FILE *fp, unsigned char *digest); int do_check(FILE *chkf); char *progname; int verbose = 0; int bin_mode = 0; void main(int argc, char **argv) { int opt, rc = 0; int check = 0; FILE *fp; unsigned char digest[16]; progname = *argv; while ((opt = getopt(argc, argv, "cbvp:h")) != EOF) { switch (opt) { case 'c': check = 1; break; case 'v': verbose = 1; break; case 'b': bin_mode = 1; break; default: usage(); } } argc -= optind; argv += optind; if (check) { switch (argc) { case 0: fp = stdin; break; case 1: if ((fp = fopen(*argv, FOPRTXT)) == NULL) { perror(*argv); exit(2); } break; default: usage(); } exit(do_check(fp)); } if (argc == 0) { if (mdfile(stdin, digest)) { fprintf(stderr, "%s: read error on stdin\n", progname); exit(2); } print_digest(digest); printf("\n"); exit(0); } for ( ; argc > 0; --argc, ++argv) { if (bin_mode) fp = fopen(*argv, FOPRBIN); else fp = fopen(*argv, FOPRTXT); if (fp == NULL) { perror(*argv); rc = 2; continue; } if (mdfile(fp, digest)) { fprintf(stderr, "%s: error reading %s\n", progname, *argv); rc = 2; } else { print_digest(digest); printf(" %c%s\n", bin_mode ? '*' : ' ', *argv); } fclose(fp); } exit(rc); } void usage() { fprintf(stderr, "usage: md5sum [-bv] [-c [file]] | [file...]\n"); fprintf(stderr, "Generates or checks MD5 Message Digests\n"); fprintf(stderr, " -c check message digests (default is generate)\n"); fprintf(stderr, " -v verbose, print file names when checking\n"); fprintf(stderr, " -b read files in binary mode\n"); fprintf(stderr, "The input for -c should be the list of message digests and file names\n"); fprintf(stderr, "that is printed on stdout by this program when it generates digests.\n"); exit(2); } int mdfile(FILE *fp, unsigned char *digest) { unsigned char buf[1024]; MD5_CTX ctx; int n; MD5Init(&ctx); while ((n = fread(buf, 1, sizeof(buf), fp)) > 0) MD5Update(&ctx, buf, n); MD5Final(digest, &ctx); if (ferror(fp)) return -1; return 0; } void print_digest(unsigned char *p) { int i; for (i = 0; i < 16; ++i) printf("%02x", *p++); } int hex_digit(int c) { if (c >= '0' && c <= '9') return c - '0'; if (c >= 'a' && c <= 'f') return c - 'a' + 10; return -1; } int get_md5_line(FILE *fp, unsigned char *digest, char *file) { char buf[1024]; int i, d1, d2, rc; char *p = buf; if (fgets(buf, sizeof(buf), fp) == NULL) return -1; for (i = 0; i < 16; ++i) { if ((d1 = hex_digit(*p++)) == -1) return 0; if ((d2 = hex_digit(*p++)) == -1) return 0; *digest++ = d1*16 + d2; } if (*p++ != ' ') return 0; /* * next char is an attribute char, space means text file * if it's a '*' the file should be checked in binary mode. */ if (*p == ' ') rc = 1; else if (*p == '*') rc = 2; else { fprintf(stderr, "%s: unrecognized line: %s", progname, buf); return 0; } ++p; i = strlen(p); if (i < 2 || i > 255) return 0; p[i-1] = '\0'; strcpy(file, p); return rc; } int do_check(FILE *chkf) { int rc, ex = 0, failed = 0, checked = 0; unsigned char chk_digest[16], file_digest[16]; char filename[256]; FILE *fp; int flen = 14; while ((rc = get_md5_line(chkf, chk_digest, filename)) >= 0) { if (rc == 0) /* not an md5 line */ continue; if (verbose) { if (strlen(filename) > flen) flen = strlen(filename); fprintf(stderr, "%-*s ", flen, filename); } if (bin_mode || rc == 2) fp = fopen(filename, FOPRBIN); else fp = fopen(filename, FOPRTXT); if (fp == NULL) { fprintf(stderr, "%s: can't open %s\n", progname, filename); ex = 2; continue; } if (mdfile(fp, file_digest)) { fprintf(stderr, "%s: error reading %s\n", progname, filename); ex = 2; fclose(fp); continue; } fclose(fp); if (memcmp(chk_digest, file_digest, 16) != 0) { if (verbose) fprintf(stderr, "FAILED\n"); else fprintf(stderr, "%s: MD5 check failed for '%s'\n", progname, filename); ++failed; } else if (verbose) fprintf(stderr, "OK\n"); ++checked; } if (verbose && failed) fprintf(stderr, "%s: %d of %d file(s) failed MD5 check\n", progname, failed, checked); if (!checked) { fprintf(stderr, "%s: no files checked\n", progname); return 3; } if (!ex && failed) ex = 1; return ex; } cates. chcontrib/md5sum/pgp262.md51004440006630000000000001540605652314235012276 037777703401 1 0 -----BEGIN PGP SIGNED MESSAGE----- b2518ad2566a9a4bce071936311d3c93 config.txt a206e6e80eca6664bef72cfc270acbec contrib/langtool/charconv.c 3d06eeff628daab00f897889a5ca4047 contrib/langtool/crc.c 57612e0d95bb179489e0f29f07ea53ac contrib/langtool/getopt.c 1c0ce69dfc364a017727cf894eae2de6 contrib/langtool/getopt.h 2031698e3ad7cdc8991c3057f011a3de contrib/langtool/killdups.c d5a3243a628150591f567aa034df2a1b contrib/langtool/language.c 44510de22a0e5c6ecda8e34ce6ac04a5 contrib/langtool/makefile df72de609b525b6ace414f8fd1d0eeaf contrib/langtool/pickpstr.c 6e03f664fedffeabe33f024e545dbdea contrib/langtool/usuals.h 0776942a56e6c2b8b8061df6edc46a8e contrib/langtool/readme ca1e0afd83f3cb31d4576e2a711dece7 contrib/md5sum/md5sum.c 92ad894d389fe17be525277c6bbd6cbb contrib/md5sum/readme fa01dc98a10f9f5ab33bf8cf0b95d7d8 contrib/readme 84366f50442cfe45bd8f04725231ac59 doc/blurb.txt 8141b9a63f872229efe865f5d0fcfeb3 doc/keyserv.doc 1bbff20917ce904dab1daec5caf262b3 doc/setup.doc ddb01e2e177da7175d1b49e9beaf8f84 doc/pgpdoc2.txt 7f95a3f516b6b649f9459e3ff095b99f doc/pgpdoc1.txt 6d5d7190622023884773b1fdd90bd7c7 doc/pgformat.doc 716cf54b6374917412b1c02c322d68ac doc/pgp.1 a8a93a79e6a92fb3eadd810296d6d243 doc/politic.doc 513de04d3e87df8c288ce2c062bbe526 doc/appnote.doc ffe25830d29457dcfad3499d86fd623b doc/changes.doc 76400c36d5dc58cad39b17a1257cb6cd es.hlp 06d90ef1c0d8bfbde0eeac634e31715d fr.hlp 4f57efea57e9d638c680fc09230a497f keys.asc bcec0f56b207846725fe7e4a612383ef language.txt b132d65b1775dabfb156f7065622cbaa mitlicen.txt fe8a99b000d421208c0b950b41aeaad7 pgp.hlp 85c19c09add0b21870dc589f9eee60a4 readme.doc ad4eaee00f51a3f61919f51b96124586 rsalicen.txt 96cd1d518af09bc575e2273b14540389 src/3b168000.s d1e71a740bcc3fcb9fd02bd1c903bcd5 src/68000.s c13bd2039e93080b6ee05c37f37bc2a4 src/68000_32.s 2876baab5bf32c0667e9912db78eec39 src/8086.asm 89a3c60a0f651be741251220eff1ad2e src/config.c 8aa3b0be027de0f5d60e51bf349a19ca src/armor.h ca96e382af89dc4d70d5606cd249955e src/ccc d630fd32b92fb6b668cfe8ce69772aad src/ccc.x28 3071ab0c9fbcab284fa9607f8ce97ebc src/charset.c d28b7d2526635c231182d2c82557d464 src/charset.h ee16e0370483a7be4b710367003ee54b src/makefile eb62350482feec7f3e58a29c619fb3d0 src/config.h d33d57870eba6d1875e8b284007129b4 src/crypto.c 5e2550ab2e1577ab6e9a0fb5d5d0e16f src/crypto.h 8ed1bb200abfe4a353f05605ba61ec98 src/descrip.mms 793dd9f0efc2c9554d056381027ba991 src/exitpgp.h 542536aa27597132b3d93b2a69722726 src/rsaglue2.c 0be3394ce90916cf33d33c0d09aee6dc src/fileio.h bca7a315a7b76dfe21e904a8bef4322c src/genprime.c a06c6946622b8b1bd98459b3726027ec src/genprime.h 41772566a0e81fde314c4ae84036adbc src/getopt.c 1e6e5eaea460bf7cd83575c6f2b45d55 src/getopt.h 9f16e34745c7cecd63c6367900d0210f src/global.h 52e477b1b8427adba1eeb47c7c8492b4 src/makefile.msc 1edf2d0cb1889e2139f0fe4ecd8098a7 src/idea.h 5f7f8f0c87914cb64825294c69334611 src/idea68k.s 98a13756e9f22cd71f49298adc310275 src/keyadd.h e08589f0d287f9865c1bf73beb3e0f0d src/keymaint.h f2f92ad53d30102e4f06c3ebd9e41426 src/keymgmt.c a81fd754d1f0344d859150c93eab9b04 src/random.c eed38d9c5b87c50055de29e54562c903 src/language.c 9f03e3dfee08a9c7762c6bc874e5e032 src/language.h b9afdaaa7b28504e0a54668022d87a78 src/lmul.h b6ea3d81d98ec4c1e18f868cccdbb399 src/mc68020.s e6b99301ce97d3ba06ae2850576e0120 src/md5.c c091b77fde09775ce399d8ca872ab772 src/md5.h 4f3f9ba7e87ae5870ef7c5e2003a7cae src/mdfile.c 25deba9b0e4dd840ae9c4f03be74a7c5 src/mdfile.h c0f85223f435137fc7afc83d9e64d47a src/more.c 03f5c013f7c31aba253399a8d6355485 src/more.h 24a2d52e1012886363dafd457fe1408f src/mpiio.c fcd3b9076b948a91072fc4905bf86fcc src/mpiio.h e1323f333dd3a5e28ab4f91d90b67e53 src/mpilib.c 51204bd183b86397d86e3a2350708104 src/mpilib.h 61ce8d29ae7f2b321eea91cb1c145d54 src/noise.c 99f0c0c0b2ff0a4e35acc62502684a3c src/noise.h 2f42e70818a2db0d43cd3169a4e29b4c src/sleep.c 9126a1f7d3a15d2d01a350ca9c067bdd src/pgp.def c184e89fd8370781029f9914acfa8e16 src/pgp.mak 4fa11d3f2501e73ff235f076cc9c2352 src/pgp.opt d01ff8c9b23cafe6cebc4397fbb3b7fc src/pgppwb.mak 75dea35217e3d025ced272b25978fc02 src/platform.h e117883c52586f6510df60e97f1ec3db src/r3000.c 4a9b2c19b856e28358912751e8c10ff8 src/r3000.s be8b773d05ee5c8c068e5a71c457d1b9 src/r3kd.s 94e30db76cd9448d692e84e2992916b5 src/random.h 595f234f458ae47d75e9c0879787b122 src/randpool.h 9e40a32bb001479197deee52edcebd9b src/rsagen.c e993fb955af6494340be1d08b6cff008 src/rsagen.h 6000e256c979a2804146ed753e0cd630 src/rsaglue.h 45cc55ba01e8cd1af3d1d58bd7a80272 src/stdlib.h 5e15c52746a5e8e8f5b7dfe828c18730 src/system.h 00e1529c820acc42ee7b613d3c80168e src/usuals.h 1b22d6267dd9878220057805286fb115 src/vax.mar d6fc03f7cb9768119ee38ae482964ee5 src/vaxcrtl.opt 535e0e50cd5aa9f98c0f34727997e3db src/zbits.c 275829c8a77842701ae09ac3114a851b src/zdeflate.c b3109aef0a37c2b60ae5d540eb3fd0d7 src/zip.c f2c2bb35d882e75365ca9cf4880eeb06 src/zfile_io.c f5acd1019fed4865e6bf1df1c78cac9f src/zglobals.c ec3ca2c24201c14333bff07b81e1e675 src/zinflate.c 4943922e45f89f99644b444b627c63bc src/zip.h f6fb43a0cbe1a2016c405323aa06b38f src/ziperr.h dcdf53f69c48e5ffd410d81a1c0689ba src/zipup.c 23618c8e13b25e917c0226d655c926e1 src/zipup.h 232d4e2ad877bb012db4611b9904f4a8 src/zmatch.asm 8d27bb0381e2aa8a96cf73e50172b87a src/zrevisio.h 3598e3720ba907f16900f717dbc94af1 src/ztailor.h 03fcba0224f5bc649a19333a9a7eb060 src/ztrees.c 42ef224622be81e1f4646a45f15edb0d src/zunzip.c 520e8dea23a53451082bfd1b6be4a7ed src/zunzip.h 64cc4fcdace405cecb5e410e34292efa src/80386.S 0452b98b1dc43cb527c5bf4acb7bd881 src/zmatch.S f9eff910628c418fa83057fd0e77cef7 src/memmove.c a2fec7c8e3975afd42f53223347089ea src/cdefs.h 4e7cff595f52e5282398705f0443ba6c src/passwd.c 353416cbdf477b4af9569d26501e9d57 src/fileio.c aac07c63fee3530fdfdc50f53cb5bd57 src/randpool.c adb6ddc88c7e39c9f7a7c3a58b0cf4c7 src/keymaint.c 8eac86eb9c69dfe5bf05422c701007bb src/pgp.c baa967f22bb7d2567ab493d09a6c09cb src/armor.c 77e26b14db7f77863cd84212feb55904 src/system.c 3909c5868b30174e78e4945347830eb2 src/rsaglue1.c 3c98d4cc6464f50b9971a8e90232dded src/keymgmt.h 7ab2899ad6bb9e80f27d49aca4f86540 src/keyadd.c d7ad89b79de52da68715fd50ad20529b src/pgp.h 61652be58a5e3ba50349ac33dc474a1b src/idea.c 60e9082a870c11d858448846ac1ed7a9 src/sparc.S 97bca154324e48423a3967539383e362 vmsbuild/000read.me 8897f8a9d020aea8d335970dd7d4cc94 vmsbuild/allbuild.com 37c88774f79fdb9085bbfba536df26e2 vmsbuild/pgp.opt 252d820ca1e904f7b41206174b01dbda vmsbuild/pgpbuild.com 9d26c6b2d48abbaf95c84dddc46031d7 vmsbuild/pgplink.com c4f0a9780664c0b6af20b591a9197af3 vmsbuild/rsabuild.com -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBLqmYmMUtR20Nv5BtAQFORgP/TMWJJ1FBuoOhKH1kh6STNjZ04oIxmxaF jUqklS1w3EVwMIPhdUlhUbF2RMN85w7QzyoaokF+R8mEJ0D+jay2AC4vwvB4WDYt T8jLRhdrdhYHJb1poEHeb/AQv/W5nKgi7j753uaYyWzDDpTpIQF8um9vcIcuxS+2 rapLVhVsgSg= =rjgu -----END PGP SIGNATURE----- print file names when checking\n"); fprintf(stderr, " -b read files in binary mode\n"); fprintf(stderr, "The input for -c should be the list of message digests and file names\n"); fprintf(stderr, "that is printed on stdout by this program whecontrib/md5sum/readme1004440006630000000000000563005643700736012032 037777703401 1 0 Instructions for the MD5SUM Utility ----------------------------------- This utility computes MD5 checksums of files, ignoring end-of-line conventions unless the -b (binary) flag is set. This utility can be used to check the integrity of any files. For this discussion, we'll be checking the files in the PGP source code release. For PGP version 2.6.2, the file containing all the MD5 message digests is called "pgp262.md5", but for other versions of PGP, the filename will change to reflect the new version number. The file "pgp262.md5" contains the signatures of all the files in the source. If you are in the source directory and run md5sum -c ../contrib/md5sum/pgp262.md5 you will get an error message if any files fail to match. If all files match, nothing will be printed. You need to borrow some files from the PGP sources to compile this utility (md5.c, md5.h, and possibly the getopt implementation); see the md5sum.c file for details. On some platforms, you may have to compile md5.c with the -DHIGHFIRST flag, or the MD5 sums will be wrong. The file pgp262.md5 is signed by jis@mit.edu, so you can be reasonably sure it's correct. It would be possible for a hard-working miscreant to fiddle with the distribution so all of this mutual checking would not show any errors, but it's not going to happen accidentally. And if you have a previous version of PGP that you trust, it's not going to happen at all. The only other thing that's needed is a detached PGP signature of the files md5sum.c, md5.c and md5.h, and anyone with a previous trusted version of PGP can be sure that no tampering has occurred anywhere, and that's here: md5sum.c: -----BEGIN PGP MESSAGE----- Version: 2.6.1 iQCVAwUBLmkvh8UtR20Nv5BtAQGt6AP/S41H9gw7rfifG7W6ZlMviV4VVeov1C54 wkS/rjG3+tCm2Gcixfcx7iPb6wIbg5IqWtjbuPd2xvpyLn8MrN3E4Llak7tOBVg7 insTxrqzjmSNCxVPe3X5+QqnOY7TlI6qIjhZ74Wb9gKiQxKn3f5yjKzJKvpv20a1 ngI7v5BADKQ= =Qi79 -----END PGP MESSAGE----- md5.c: -----BEGIN PGP MESSAGE----- Version: 2.6.1 iQCVAwUBLmkvv8UtR20Nv5BtAQE/jgQAooUL4iKAeg5alJKGvbFqmFlFz0dakkne HnX2dDihBHiapkZ/a2dMCMNbDuxWcUdS5/I4RQfhaLPis9WTeQr2d707c4x5+B4a QPSEAA3fZ0GwX+q8JkZ4XSD3NZbcGJRdudtnp8sYnVY3n7PkzUm6xK7ZcxFxmKTf lTh4Hf3EAaU= =mxp3 -----END PGP MESSAGE----- md5.h: -----BEGIN PGP MESSAGE----- Version: 2.6.1 iQCVAwUBLmkvz8UtR20Nv5BtAQHvaAQAq0SZeeArKo5rcRSv25tqa5zFLRDtbZgc dI8JD0st/Dfj8hZf9KWOBiPQbCD5K4U8SWTAJE4qfNkJGM6gf9hXixuZ/DaEzqQr ruXxx0/0/pbx48oVKy08kNL2W3/cguJXQjkK0VbqlYUjgy5zApwbkRgjXw3R1mkF 46A7P51mRLg= =DGCy -----END PGP MESSAGE----- These signatures were generated by Jeffrey I. Schiller . Jeff's key is supplied in the keys.asc file in the PGP distribution and is signed by various PGP developers including Phil Zimmermann, so you know that we are who we say we are, and if there are any trojan horses in the source, you know who put them there. Isn't security fun?) -- -Colin Revised by Jeffrey I. Schiller df2a1b contrib/langtool/language.c 44510de22a0e5c6ecda8e34ce6ac04a5 contrib/langtool/makefile df72de60contrib/readme1006440006630000000000000056705643700735010625 037777703401 1 0 This directory is distributed with the PGP source code release package. It contains subdirectories with tools and utilities related to PGP that have been contributed by PGP users. If you have created any programs that you think would be of interest to other PGP users, please send them in to pgp-bugs@mit.edu, and maybe we could put them into future PGP release packages. ac634e31715d fr.hlp 4f57efea57e9d638c680fc09230a497f keys.asc bcec0f56b207846725fe7e4a612383ef language.txt b132d65b1775dabfb156f70656doc/0407550006630000000000000000005652314025005760 5 0 1 0 doc/blurb.txt1004440006630000000000000131405651034124010375 037777703401 1 0 PGP (Pretty Good Privacy) ver 2.6.2 - RSA public-key encryption freeware for MSDOS, protects E-mail. Lets you communicate securely with people you've never met, with no secure channels needed for prior exchange of keys. Well featured and fast! Excellent user documentation. PGP has sophisticated key management, an RSA/conventional hybrid encryption scheme, message digests for digital signatures, data compression before encryption, and good ergonomic design. Source code is free. Filenames: pgp262.zip (executable and manuals), pgp262s.zip (sources) pgp262dc.zip (manuals) Keywords: PGP, Pretty Good Privacy, RSA, public key, encryption, privacy, authentication, signatures, email 8f868cccdbb399 src/mc68020.s e6b99301ce97d3ba06ae2850576e0120 src/md5.c c091b77fde09775ce399d8ca872ab772 src/md5.h 4f3f9ba7e87ae5870ef7c5e2003a7cae src/mdfile.c 25deba9b0e4dd840ae9c4f03be74a7c5 src/mdfile.h c0f85223f435137fc7afc83d9e64d47a src/more.c 03f5c013f7c31aba253399a8d6355485 src/more.h 24a2d5doc/keyserv.doc1004440006630000000000001011705570226124010711 037777703401 1 0 PGP Public Keyservers --------------------- There are PGP public key servers which allow one to exchange public keys running through the Internet and UUCP mail systems. The information below is OUT OF DATE, and the release of PGP 2.6 will cause a great deal of upheaval, especially in the U.S. The command reference is the most useful part. NOTE! This service is NOT supported in any way whatsoever by the schools or organizations on which these servers run. It is here only to help transfer keys between PGP users. It does NOT attempt to guarantee that a key is a valid key; use the signators on a key for that kind of security. This service can be discontinued at any time without prior notification. Each keyserver processes requests in the form of mail messages. The commands for the server are entered on the Subject: line. To: pgp-public-keys@pgp.mit.edu From: johndoe@some.site.edu Subject: help Sending your key to ONE server is enough. After it processes your key, it will forward your add request to other servers automagically. For example, to add your key to the keyserver, or to update your key if it is already there, send a message similar to the following to any server: To: pgp-public-keys@pgp.mit.edu From: johndoe@some.site.edu Subject: add -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.5 -----END PGP PUBLIC KEY BLOCK----- COMPROMISED KEYS: Create a Key Revocation Certificate (read the PGP docs on how to do that) and mail your key to the server once again, with the ADD command. Valid commands are: Command Message body contains ---------------------- ------------------------------------------------- ADD Your PGP public key (key to add is body of msg) INDEX List all PGP keys the server knows about (-kv) VERBOSE INDEX List all PGP keys, verbose format (-kvv) GET Get the whole public key ring GET userid Get just that one key MGET regexp Get all keys which match /regexp/ LAST days Get the keys updated in the last `days' days ------------------------------------------------------------------------ Examples for the MGET command: MGET michael Gets all keys which have "michael" in them MGET iastate All keys which contain "iastate" MGET F605A5|3A738B Those two keyid's As of 24-Apr-93, these sites are running this system: Internet sites: pgp-public-keys@pgp.mit.edu Derek Atkins warlord@MIT.EDU FTP: toxicwaste.mit.edu:/pub/keys/public-keys.pgp public-key-server@pgp.ai.mit.edu or pgp-public-keys@pgp.ai.mit.edu Brian LaMacchia public-key-server-request@martigny.ai.mit.edu http://www-swiss.ai.mit.edu/~bal/pks-toplev.html pgp-public-keys@pgp.iastate.edu Michael Graff explorer@iastate.edu FTP: pgp.iastate.edu:/usr/explorer/public-keys.pgp pgp-public-keys@demon.co.uk Mark Turner mark@demon.co.uk FTP: ftp.demon.co.uk:/pub/pgp/pubring.pgp (Updated daily) pgp-public-keys@fbihh.informatik.uni-hamburg.de Vesselin V. Bontchev bontchev@fbihh.informatik.uni-hamburg.de FTP: ftp.informatik.uni-hamburg.de:/pub/virus/misc/pubkring.pgp pgp-public-keys@pgp.ox.ac.uk Paul Leyland pcl@ox.ac.uk pgp-public-keys@dsi.unimi.it David Vincenzetti vince@dsi.unimi.it FTP: ghost.dsi.unimi.it:/pub/crypt/public-keys.pgp pgp-public-keys@kub.nl Teun Nijssen teun@kub.nl pgp-public-keys@ext221.sra.co.jp Hironobu Suzuki hironobu@sra.co.jp pgp-public-keys@sw.oz.au Jeremy Fitzhardinge jeremy@sw.oz.au pgp-public-keys@io.com Sysop: pgpkeys@wasabi.io.com FTP: wasabi.io.com:/pub/pgpkeys pgp-public-keys@kiae.su blaster@rd.relcom.msk.su UUCP site: pgp-public-keys@jpunix.com John Perry perry@jpunix.com Check the Usenet newsgroup alt.security.pgp for updates to this system and for new sites. the source. If you are in the source directory and run md5sum -c ../contrib/md5sum/pgp262.md5 you will get an error message if any files fail to match. If all files match, nothing will be printed. You need to borrow some files from the PGP sources to compile this utility (md5.c, md5.h, and possibly the getopt implementation); see the md5sum.c file for details. On some platforms, you may have to compile md5.c with the -Ddoc/setup.doc1004440006630000000000003701705652313753010377 037777703401 1 0 -----BEGIN PGP SIGNED MESSAGE----- Pretty Good Privacy Version 2.6.2 Installation Guide by Perry Metzger, Colin Plumb, Derek Atkins, Jeffrey I. Schiller and others How to Install PGP ================== The first question is, what platform are you on? The base PGP 2.6.2 distribution runs on several varieties of Unix, MS-DOS, OS/2 and VAX VMS (though we haven't compiled it ourselves there yet). Ports can be expected shortly to the Atari, Amiga, and possibly other systems. Naturally, installation instructions differ depending on your hardware. Separate instructions are provided here for MSDOS and Unix. See the section below for your system's particular installation instructions. If you do not have any of these systems, you will either have to port the sources to your machine or find someone who has already done so. ######################################################################## For MSDOS Installation ====================== PGP is distributed in a compressed archive format, which keeps all the relevant files grouped together, and also saves disk space and transmission time. The current version, 2.6.2, is archived with the ZIP utility, and the PGP executable binary release system is in a file named PGP262.ZIP. This contains the executable program, the user documentation, the RSAREF license, and a few keys and signatures. There is also a second file available containing the C and assembly source code, called PGP262S.ZIP. If you are a programmer, this may be of interest to you. This should be available from the same source from which you got PGP262.ZIP. If not, and you want it, see the Licensing and Distribution section of the PGP User's Guide. There is also an archive PGP262DC.ZIP, which is just the documentation, if you just want to see a description of PGP or have misplaced the manual. You will need PKUNZIP version 2.04g or later to uncompress and split the PGP262.ZIP archive file into individual files. PKUNZIP is shareware and is widely available on MSDOS machines. Each of the ZIP files is actually two nested zip files. Inside PGP262.ZIP is PGP262I.ZIP, which contains most of the files, and PGP262I.ASC, which is a PGP signature on PGP262I.ASC. If you have a previous version of PGP, you can use it to check the signature to see that the distribution has not been tampered with. Since a PGP signature protects every last bit in a file from change, a BBS adding an advertising blurb or recompressing the archive would cause PGP to report tampering. Thus, only the inner ZIP file is signed. Create a directory for the PGP files. For this description, let's use the directory C:\PGP26 as an example, but you should substitute your own disk and directory name if you use something different. Type these commands to make the new directory: c: md \pgp26 cd \pgp26 Uncompress the distribution file PGP262.ZIP to the directory. For this example, we will assume the file is on floppy drive A - if not, substitute your own file location. pkunzip -d a:pgp262 This will create the file PGP262I.ZIP and PGP262I.ASC. Unzip PGP262I.ZIP with the command: pkunzip -d pgp262i If you omit the -d flag, all the files in the doc subdirectory will be deposited in the pgp directory. This merely causes clutter. Keep the PGP262I.ZIP file around. Once you have PGP working you can use PGP262I.ASC to verify the digital signature on PGP262I.ZIP. It should come from Jeffrey I. Schiller (whose key is included in keys.asc). Setting the Environment ----------------------- Next, you can set an MSDOS "environment variable" to let PGP know where to find its special files, in case you use it from other than the default PGP directory. Use your favorite text editor to add the following lines to your AUTOEXEC.BAT file (usually on your C: drive): SET PGPPATH=C:\PGP26 SET PATH=C:\PGP26;%PATH% Substitute your own directory name if different from "C:\PGP26". The CONFIG.TXT file contains various user-defined preferences for PGP. For example, you can specify which of your secret keys to implicitly select for creating digital signatures. See the manual for details on how to fine-tune your PGP configuration file. The default values in that file are good enough to get you started. Another environmental variable you should set in MSDOS is "TZ", which tells MSDOS what time zone you are in, which helps PGP create GMT timestamps for its keys and signatures. If you properly define TZ in AUTOEXEC.BAT, then MSDOS gives you good GMT timestamps, and will handle daylight savings time adjustments for you. Here are some sample lines to insert into AUTOEXEC.BAT, depending on your time zone: For Los Angeles: SET TZ=PST8PDT For Denver: SET TZ=MST7MDT For Arizona: SET TZ=MST7 (Arizona never uses daylight savings time) For Chicago: SET TZ=CST6CDT For New York: SET TZ=EST5EDT For London: SET TZ=GMT0BST For Amsterdam: SET TZ=MET-1DST For Moscow: SET TZ=MSK-3MSD For Aukland: SET TZ=NZT-13 Now reboot your system to run AUTOEXEC.BAT, which will set up PGPPATH and TZ for you. Generating Your First Key ------------------------- One of the first things you will want to do to really use PGP (other than to test itself) is to generate your own key. This is described in more detail in the "RSA Key Generation" section of the PGP User's Guide. Remember that your key becomes something like your written signature or your bank card code number or even a house key - keep it secret and keep it secure! Use a long, unguessable pass phrase and remember it. Right after you generate a key, put it on your key rings and copy your secret keyring (SECRING.PGP) to a blank floppy and write protect the floppy. If you are a first-time user of PGP, it is a good idea to generate a short test key, with a short passphrase, to play around with PGP for a little bit and see how it works, or even more than one so you can pretend to be sending messages between two different people. Since you won't be guarding any secrets, this can be short and have a simple pass phrase. But when you generate your permanent key, that you intend to give to others so they can send secure messages to you, be much more careful. After you generate your own key pair, you can add a few more public keys to your key ring. A collection of sample public keys is provided with the release in the file KEYS.ASC. To add them to your public key ring, see the PGP User's Guide, in the section on adding keys to your key ring. Verifying the PGP distribution ------------------------------ Now that you have PGP up and running and have read in the KEYS.ASC file you can now verify the integrity of the original distribution. To do this type: pgp pgp262i.asc It will inform you that pgp262i.asc contains a signature but no text. It may then ask you to provide the name of the file that it applies to. Type in "pgp262i.zip", the internal ZIP file. PGP should tell you that it has a Good Signature from: Jeffrey I. Schiller It will also tell you that it doesn't "trust" my (jis@mit.edu) key. This is because PGP does not *know* that the enclosed key really belongs to me. Don't worry about this now. Read the section "How to Protect Public Keys from Tampering" in Volume 1 of the PGP manual. READ THE FINE MANUAL (RTFM) --------------------------- READ THE DOCUMENTATION. At least read Volume I of the PGP User's Guide. Cryptography software is easy to misuse, and if you don't use it properly much of the security you could gain by using it will be lost! You might also be unfamiliar with the concepts behind public key cryptography; the manual explains these ideas. Even if you are already familiar with public key cryptography, it is important that you understand the various security issues associated with using PGP. PGP may be an unpickable lock, but you have to install it in the door properly or it won't provide security. ######################################################################## For UNIX: You likely will have to compile PGP for your system; to do this, first make sure the unpacked files are in the correct unix textfile format (the files in pgp262s.zip are in MSDOS CRLF format, so for Unix you must unpack with "unzip -a"; the tar files pgp262s.tar.Z and pgp262s.tar.gz use normal Unix line feed conventions). You will need the RSAREF package written by RSA Data Security. It is included with the current PGP distribution from MIT. Use this version as it has been edited for the larger key sizes needed by PGP 2.6.2 as well as to improve performance. When you untar pgp262s.tar (either compression format) you will find that it contains 5 files. pgp262si.tar contains all non-binary files for PGP including all source code. This tar archive has been created assuming that you will untar it directly into your PGP 2.6.2 "build" directory. pgp262si.asc is a detached digital signature of pgp262si.tar (which you can verify after you have PGP operating, see the section above titled "Verifying the PGP Distribution"). rsaref.tar contains the source code for the RSAREF distribution. You should also untar it from your PGP "build" directory. All RSAREF software will automatically go into an "rsaref" subdirectory. cd to rsaref/install/unix and invoke the "make" command there to build the RSAREF software library. RSAREF tries to build with the GNU CC compiler by default. If you do not have the GCC compiler for your platform, you will have to run make with an option to use the normal CC compiler: make CC=cc If your native compiler does not understand prototypes, then this will fail as well, and you will have to set the PROTOTYPES to 0. You can do this by running make in this manner: make CC=cc PROTOTYPES=0 This will try to create an rsaref.a library in the current directory. One last problem you may have is the lack of a ranlib program on your platform. You can fix this by adding this to your make line: RANLIB=true After RSAREF is successfully built, cd to src (cd ../../../src from the RSAREF install/unix directory) and invoke "make" there. You will have to specify your machine platform (make without arguments will give you a list of choices). If you don't have an ANSI C compiler you will need the unproto package written by Wietse Venema. unproto was posted on comp.sources.misc and can be obtained from the various sites that archive this newsgroup (volume 23: v23i012 and v23i013) or ftp.win.tue.nl file: /pub/programming/unproto4.shar.Z Read the file README in the unproto distribution for instructions on how to use unproto. If your system doesn't have a target in the makefile you will have to edit the makefile, make sure you compile for the correct byte order for your system: define HIGHFIRST if your system is big-endian (eg. Motorola 68030). There are also some platform-specific parameters in the include file "platform.h". Some platforms may have to modify this file. If you successfully create a target rule for a new platform, please send the patches to pgp-bugs@mit.edu, so it can be added to the next release. Note: PGP requires the function memmove. Not all machines have this in the standard C library. There is an implementation of memmove included with this distribution. If you find that your platform requires memmove, but the makefile rule for your platform does not include memmove (look at the sun4gcc or sun386i rules for an example of how to include it), please send mail to pgp-bugs@mit.edu, so we can correct the problem. If you have any problems, bugs, patches, etc., please send mail to pgp-bugs@mit.edu! If all goes well, you will end up with an executable file called "pgp". Before you install pgp, run these tests: (do not create your real public key yet, this is just for testing pgp) - create a public/secret key pair (enter "test" as userid/password): pgp -kg - add the keys from the file "keys.asc" to the public keyring: pgp -ka keys.asc pgp will ask if you want to sign the keys you are adding, answer yes for at least one key. - do a keyring check: pgp -kc - encrypt pgpdoc1.txt: pgp -e pgpdoc1.txt test -o testfile.pgp - decrypt this file: pgp testfile.pgp this should produce the file "testfile" compare this file with pgpdoc1.txt If everything went well, install pgp in a bin directory. Place the documentation, pgpdoc1.txt and pgpdoc2.txt somewhere where you can reasonably read it. The software looks for it when running (especially generating keys), so someplace reasonably obvious would be good. "pgp -kg" will give you full details if it can't find the manuals. Place the man page (pgp.1) in an appropriate spot. If you don't know anything about how man pages work, you can make the man page look human readable yourself by typing "nroff -man pgp.1 >pgp.man" and reading "pgp.man". Create a subdirectory somewhere in your home directory hierarchy to hold your public and private key rings and anything else pgp might need (like the language.txt file). The default name PGP assumes is ~/.pgp. If you want to use a different name, you must set the environment variable "PGPPATH" to point to this place before you use the system. > IMPORTANT: This directory cannot be shared! It will contain your < > personal private keys! < If you are installing PGP for yourself, copy the files "language.txt", "config.txt", and the ".hlp" files from the distribution into this subdirectory. If you are installing PGP system-wide, the directory to use is /usr/local/lib/pgp for the config, language and help files. This can be changed in fileio.h when compiling. It's the value of PGP_SYSTEM_DIR. Tell PGP the character set and language you wish to use in the config.txt file. If you have a terminal that only displays 7-bit ASCII, use "charset=ascii" to display an approximation (accents are omitted) of extended characters. >> IMPORTANT: Please read the sections in the man page and manual << >> about vulnerabilities before using this software on a multi- << >> user machine! << Now, if you haven't done so yet, GO READ THE MANUAL. ######################################################################## For VMS: PGP/VMS Version 2.6.2 --------------------- ***THIS MAY OR MAY NOT WORK***. The pgp26/vmsbuild contains support files for building a VMS version of PGP 2.6.2. We at MIT have not tested this code out, but it should work without too much effort. See the file: vmsbuild/000read.me. In particular, PGP needs to be linked with the RSAREF library. David North has provided a build file "vmsbuild/rsabuild.com" that should help in building RSAREF. If you can figure out how to compile it, it SHOULD work. One change is that PGP can now look for support files in a system-wide directory. The default (PGP_SYSTEM_DIR, defined in fileio.h) is PGP$LIBRARY:, but you can change that if you like. -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBLqmXwsUtR20Nv5BtAQG+rQP+KBJzh22axMqNymQtN55iU+znyJwnaTge buI7mpZnjUAYBZvOHhxVtUg/5v4PgDISrDnTkne6EZdDNEH5nP9AB8YDOChourKg drUlhn7NsEyToqDF42rX53kq0kc8P7CWilQvTfti6i8bAGWLAN9dwdq0iwFxRz8I G8Cql4kIbhA= =0JzK -----END PGP SIGNATURE----- your key becomes something like your written signature or your bank card code number or even a house key - keep it secret and keep it secure! Use a long, unguessable pass phrase and remember it. Right after you generate a key, put it on your key rings and copy your secret keyring (SECRING.PGP) to a blank floppy and write protect the floppy. If you are a first-time user of PGP, it is a good idea to generate a short test key, with a short passphrase, to play around with PGP for a lidoc/pgpdoc2.txt1004440006630000000000040566605646601460010656 037777703401 1 0 Phil's Pretty Good Software Presents ======= PGP(tm) ======= Pretty Good(tm) Privacy Public Key Encryption for the Masses ------------------------- PGP(tm) User's Guide Volume II: Special Topics ------------------------- by Philip Zimmermann Revised 11 October 94 PGP Version 2.6.2 - 11 Oct 94 Software by Philip Zimmermann, and many others. Synopsis: PGP(tm) uses public-key encryption to protect E-mail and data files. Communicate securely with people you've never met, with no secure channels needed for prior exchange of keys. PGP is well featured and fast, with sophisticated key management, digital signatures, data compression, and good ergonomic design. Software and documentation (c) Copyright 1990-1994 Philip Zimmermann. All rights reserved. For information on PGP licensing, distribution, copyrights, patents, trademarks, liability limitations, and export controls, see the "Legal Issues" section. Distributed by the Massachusetts Institute of Technology. Contents ======== Quick Overview Special Topics Selecting Keys via Key ID Separating Signatures from Messages Decrypting the Message and Leaving the Signature on it Sending ASCII Text Files Across Different Machine Environments Using PGP as a Better Uuencode Leaving No Traces of Plaintext on the Disk Displaying Decrypted Plaintext on Your Screen Making a Message For Her Eyes Only Preserving the Original Plaintext Filename Editing Your User ID or Pass Phrase Editing the Trust Parameters for a Public Key Checking If Everything is OK on Your Public Key Ring Verifying a Public Key Over the Phone Handling Large Public Keyrings Using PGP as a Unix-style Filter Suppressing Unnecessary Questions: BATCHMODE Force "Yes" Answer to Confirmation Questions: FORCE PGP Returns Exit Status to the Shell Environmental Variable for Pass Phrase Setting Parameters in the PGP Configuration File TMP - Directory Pathname for Temporary Files LANGUAGE - Foreign Language Selector MYNAME - Default User ID for Making Signatures TEXTMODE - Assuming Plaintext is a Text File CHARSET - Specifies Local Character Set for Text Files ARMOR - Enable ASCII Armor Output ARMORLINES - Size of ASCII Armor Multipart Files KEEPBINARY - Keep Binary Ciphertext Files After Decrypting COMPRESS - Enable Compression COMPLETES_NEEDED - Number of Completely Trusted Introducers Needed MARGINALS_NEEDED - Number of Marginally Trusted Introducers Needed CERT_DEPTH - How Deep May Introducers Be Nested BAKRING - Filename for Backup Secret Keyring PUBRING - Filename for Your Public Keyring SECRING - Filename for Your Secret Keyring RANDSEED - Filename for Random Number Seed PAGER - Selects Shell Command to Display Plaintext Output SHOWPASS - Echo Pass Phrase to User TZFIX - Timezone Adjustment CLEARSIG - Enable Signed Messages to be Encapsulated as Clear Text VERBOSE - Quiet, Normal, or Verbose Messages INTERACTIVE - Ask for Confirmation for Key Adds NOMANUAL - Let PGP Generate Keys Without the Manual A Peek Under the Hood Random Numbers PGP's Conventional Encryption Algorithm Data Compression Message Digests and Digital Signatures Compatibility with Previous and Future Versions of PGP Vulnerabilities Compromised Pass Phrase and Secret Key Public Key Tampering "Not Quite Deleted" Files Viruses and Trojan Horses Physical Security Breach Tempest Attacks Exposure on Multi-user Systems Traffic Analysis Protecting Against Bogus Timestamps Cryptanalysis Legal Issues Trademarks, Copyrights, and Warranties Patent Rights on the Algorithms Freeware Status and Restrictions Restrictions on Commercial Use of PGP Other Licensing Restrictions Distribution Export Controls Philip Zimmermann's Legal Situation Other Sources of Information on PGP Where to Get a Commercial Version of PGP Reporting PGP Bugs Fan Mail, Updates, and News Computer-Related Political Groups Recommended Readings To Contact the Author Appendix A: Where to Get PGP Quick Overview ============== Pretty Good(tm) Privacy (PGP), from Phil's Pretty Good Software, is a high security cryptographic software application for MSDOS, Unix, VAX/VMS, and other computers. PGP combines the convenience of the Rivest-Shamir-Adleman (RSA) public key cryptosystem with the speed of conventional cryptography, message digests for digital signatures, data compression before encryption, good ergonomic design, and sophisticated key management. This volume II of the PGP User's Guide covers advanced topics about PGP that were not covered in the "PGP User's Guide, Volume I: Essential Topics". You should first read the Essential Topics volume, or this manual won't make much sense to you. Reading this Special Topics volume is optional, except for the legal issues section, which everyone should read. Special Topics =============== Selecting Keys via Key ID ------------------------- In all commands that let the user type a user ID or fragment of a user ID to select a key, the hexadecimal key ID may be used instead. Just use the key ID, with a prefix of "0x", in place of the user ID. For example: pgp -kv 0x67F7 This would display all keys that had 67F7 as part of their key IDs. This feature is particularly useful if you have two different keys from the same person, with the same user ID. You can unambiguously pick which key you want by specifying the key ID. Separating Signatures from Messages ----------------------------------- Normally, signature certificates are physically attached to the text they sign. This makes it convenient in simple cases to check signatures. It is desirable in some circumstances to have signature certificates stored separately from the messages they sign. It is possible to generate signature certificates that are detached from the text they sign. To do this, combine the 'b' (break) option with the 's' (sign) option. For example: pgp -sb letter.txt This example produces an isolated signature certificate in a file called "letter.sig". The contents of letter.txt are not appended to the signature certificate. After creating the signature certificate file (letter.sig in the above example), send it along with the original text file to the recipient. The recipient must have both files to check the signature integrity. When the recipient attempts to process the signature file, PGP notices that there is no text in the same file with the signature and prompts the user for the filename of the text. Only then can PGP properly check the signature integrity. If the recipient knows in advance that the signature is detached from the text file, she can specify both filenames on the command line: pgp letter.sig letter.txt or: pgp letter letter.txt PGP will not have to prompt for the text file name in this case. A detached signature certificate is useful if you want to keep the signature certificate in a separate certificate log. A detached signature of an executable program is also useful for detecting a subsequent virus infection. It is also useful if more than one party must sign a document such as a legal contract, without nesting signatures. Each person's signature is independent. If you receive a ciphertext file that has the signature certificate glued to the message, you can still pry the signature certificate away from the message during the decryption. You can do this with the -b option during decrypt, like so: pgp -b letter This decrypts the letter.pgp file and if there is a signature in it, PGP checks the signature and detaches it from the rest of the message, storing it in the file letter.sig. Decrypting the Message and Leaving the Signature on it ------------------------------------------------------ Usually, you want PGP to completely unravel a ciphertext file, decrypting it and checking the nested signature if there is one, peeling away the layers until you are left with only the original plaintext file. But sometimes you want to decrypt an encrypted file, and leave the inner signature still attached, so that you are left with a decrypted signed message. This may be useful if you want to send a copy of a signed document to a third party, perhaps re-enciphering it. For example, suppose you get a message signed by Charlie, encrypted to you. You want to decrypt it, and, leaving Charlie's signature on it, you want to send it to Alice, perhaps re-enciphering it with Alice's public key. No problem. PGP can handle that. To simply decrypt a message and leave the signature on it intact, type: pgp -d letter This decrypts letter.pgp, and if there is an inner signature, it is left intact with the decrypted plaintext in the output file. Now you can archive it, or maybe re-encrypt it and send it to someone else. Sending ASCII Text Files Across Different Machine Environments -------------------------------------------------------------- You may use PGP to encrypt any kind of plaintext file, binary 8-bit data or ASCII text. Probably the most common usage of PGP will be for E-mail, when the plaintext is ASCII text. ASCII text is sometimes represented differently on different machines. For example, on an MSDOS system, all lines of ASCII text are terminated with a carriage return followed by a linefeed. On a Unix system, all lines end with just a linefeed. On a Macintosh, all lines end with just a carriage return. This is a sad fact of life. Normal unencrypted ASCII text messages are often automatically translated to some common "canonical" form when they are transmitted from one machine to another. Canonical text has a carriage return and a linefeed at the end of each line of text. For example, the popular KERMIT communication protocol can convert text to canonical form when transmitting it to another system. This gets converted back to local text line terminators by the receiving KERMIT. This makes it easy to share text files across different systems. But encrypted text cannot be automatically converted by a communication protocol, because the plaintext is hidden by encipherment. To remedy this inconvenience, PGP lets you specify that the plaintext should be treated as ASCII text (not binary data) and should be converted to canonical text form before it gets encrypted. At the receiving end, the decrypted plaintext is automatically converted back to whatever text form is appropriate for the local environment. To make PGP assume the plaintext is text that should be converted to canonical text before encryption, just add the "t" option when encrypting or signing a message, like so: pgp -et message.txt her_userid This mode is automatically turned off if PGP detects that the plaintext file contains what it thinks is non-text binary data. If you need to use the -t option a lot, you can just turn on the TEXTMODE flag in the PGP configuration file. That's what I do. For PGP users that use non-English 8-bit character sets, when PGP converts text to canonical form, it may convert data from the local character set into the LATIN1 (ISO 8859-1 Latin Alphabet 1) character set, depending on the setting of the CHARSET parameter in the PGP configuration file. LATIN1 is a superset of ASCII, with extra characters added for many European languages. Using PGP as a Better Uuencode ------------------------------ A lot of people in the Unix world send binary data files through E-mail channels by using the Unix "uuencode" utility to convert the file into printable ASCII characters that can be sent via email. No encryption is involved, so neither the sender nor the recipient need any special keys. The uuencode format was designed for a similar purpose as PGP's radix-64 ASCII transport armor format described in the "Sending Ciphertext Through E-mail Channels: Radix-64 Format" section, but not as good. A different radix-64 character set is used. Uuencode has its problems, such as 1) several slightly incompatible character sets for different versions of uuencode in the MSDOS and Unix worlds, and 2) the data can be corrupted by some E-mail gateways that strip trailing blanks or do other modifications to the character set used by uuencode. PGP may be used in a manner that offers the same general features as uuencode, and then some. You can get PGP to just convert a file into PGP's radix-64 ASCII transport armor format, but you don't have to encrypt the file or sign it, so no keys are needed by either party. Simply use the -a option alone. For example: pgp -a filename This would produce a radix-64 armored file called "filename.asc". If you read the "Sending Ciphertext Through E-mail Channels: Radix-64 Format" section, you will see that PGP's approach offers several important advantages over the uuencode approach: * PGP will break big files up into chunks small enough to E-mail. * PGP will append a CRC error detection code to each chunk. * PGP will attempt to compress the data before converting it to radix-64 armor. * PGP's radix-64 character set is more resilient to E-mail character conversions than the one used by uuencode. * Textfiles can be converted by the sender to canonical text format, as explained in the "Sending ASCII Text Files Across Different Machine Environments" section. The recipient can restore the sender's original filename by unwrapping the message with PGP's -p option. You can use "pgp -a" in any situation in which you could have used uuencode, if the recipient also has PGP. PGP is a better uuencode than uuencode. Leaving No Traces of Plaintext on the Disk ------------------------------------------ After PGP makes a ciphertext file for you, you can have PGP automatically overwrite the plaintext file and delete it, leaving no trace of plaintext on the disk so that no one can recover it later using a disk block scanning utility. This is useful if the plaintext file contains sensitive information that you don't want to keep around. To wipe out the plaintext file after producing the ciphertext file, just add the "w" (wipe) option when encrypting or signing a message, like so: pgp -esw message.txt her_userid This example creates the ciphertext file "message.pgp", and the plaintext file "message.txt" is destroyed beyond recovery. Obviously, you should be careful with this option. Also note that this will not wipe out any fragments of plaintext that your word processor might have created on the disk while you were editing the message before running PGP. Most word processors create backup files, scratch files, or both. Also, it overwrites the file only once, which is enough to thwart conventional disk recovery efforts, but not enough to withstand a determined and sophisticated effort to recover the faint magnetic traces of the data using special disk recovery hardware. Displaying Decrypted Plaintext on Your Screen --------------------------------------------- To view the decrypted plaintext output on your screen (like the Unix-style "more" command), without writing it to a file, use the -m (more) option while decrypting: pgp -m ciphertextfile This displays the decrypted plaintext display on your screen one screenful at a time. Making a Message For Her Eyes Only ---------------------------------- To specify that the recipient's decrypted plaintext will be shown ONLY on her screen and will not be saved to disk, add the -m option: pgp -sem message.txt her_userid Later, when the recipient decrypts the ciphertext with her secret key and pass phrase, the plaintext will be displayed on her screen but will not be saved to disk. The text will be displayed as it would if she used the Unix "more" command, one screenful at a time. If she wants to read the message again, she will have to decrypt the ciphertext again. This feature is the safest way for you to prevent your sensitive message from being inadvertently left on the recipient's disk. This feature was added at the request of a user who wanted to send intimate messages to his lover, but was afraid she might accidentally leave the decrypted messages on her husband's computer. Note that this feature will not prevent a clever and determined person from finding a way to save the decrypted plaintext to disk-- it's to help prevent a casual user from doing it inadvertently. Preserving the Original Plaintext Filename ------------------------------------------ Normally, PGP names the decrypted plaintext output file with a name similar to the input ciphertext filename, but dropping the extension. Or, you can override that convention by specifying an output plaintext filename on the command line with the -o option. For most E-mail, this is a reasonable way to name the plaintext file, because you get to decide its name when you decipher it, and your typical E-mail messages often come from useless original plaintext filenames like "to_phil.txt". But when PGP encrypts a plaintext file, it always saves the original filename and attaches it to the plaintext before it compresses and encrypts the plaintext. Normally, this hidden original filename is discarded by PGP when it decrypts, but you can tell PGP you want to preserve the original plaintext filename and use it as the name of the decrypted plaintext output file. This is useful if PGP is used on files whose names are important to preserve. To recover the original plaintext filename while decrypting, add the -p option, like so: pgp -p ciphertextfile I usually don't use this option, because if I did, about half of my incoming E-mail would decrypt to the same plaintext filenames of "to_phil.txt" or "prz.txt". Editing Your User ID or Pass Phrase ----------------------------------- Sometimes you may need to change your pass phrase, perhaps because someone looked over your shoulder while you typed it in. Or you may need to change your user ID, because you got married and changed your name, or maybe you changed your E-mail address. Or maybe you want to add a second or third user ID to your key, because you may be known by more than one name or E-mail address or job title. PGP lets you attach more than one user ID to your key, any one of which may be used to look up your key on the key ring. To edit your own userid or pass phrase for your secret key: pgp -ke userid [keyring] PGP prompts you for a new user ID or a new pass phrase. If you edit your user ID, PGP actually adds a new user ID, without deleting the old one. If you want to delete an old user ID, you will have to do that in a separate operation. The optional [keyring] parameter, if specified, must be a public keyring, not a secret keyring. The userid field must be your own userid, which PGP knows is yours because it appears on both your public keyring and your secret keyring. Both keyrings will be updated, even though you only specified the public keyring. The -ke command works differently depending on whether you use it on a public or secret key. It can also be used to edit the trust parameters for a public key. Editing the Trust Parameters for a Public Key --------------------------------------------- Sometimes you need to alter the trust parameters for a public key on your public key ring. For a discussion on what these trust parameters mean, see the section "How Does PGP Keep Track of Which Keys are Valid?" in the Essential Topics volume of the PGP User's Guide. To edit the trust parameters for a public key: pgp -ke userid [keyring] The optional [keyring] parameter, if specified, must be a public keyring, not a secret keyring. Checking If Everything is OK on Your Public Key Ring ---------------------------------------------------- Normally, PGP automatically checks any new keys or signatures on your public key ring and updates all the trust parameters and validity scores. In theory, it keeps all the key validity status information up to date as material is added to or deleted from your public key ring. But perhaps you may want to explicitly force PGP to perform a comprehensive analysis of your public key ring, checking all the certifying signatures, checking the trust parameters, updating all the validity scores, and checking your own ultimately-trusted key against a backup copy on a write-protected floppy disk. It may be a good idea to do this hygienic maintenance periodically to make sure nothing is wrong with your public key ring. To force PGP to perform a full analysis of your public key ring, use the -kc (key ring check) command: pgp -kc You can also make PGP check all the signatures for just a single selected public key by: pgp -kc userid [keyring] For further information on how the backup copy of your own key is checked, see the description of the BAKRING parameter in the configuration file section of this manual. Verifying a Public Key Over the Phone ------------------------------------- If you get a public key from someone that is not certified by anyone you trust, how can you tell if it's really their key? The best way to verify an uncertified key is to verify it over some independent channel other than the one you received the key through. One convenient way to tell, if you know this person and would recognize them on the phone, is to call them and verify their key over the telephone. Rather than reading their whole tiresome (ASCII-armored) key to them over the phone, you can just read their key's "fingerprint" to them. To see this fingerprint, use the -kvc command: pgp -kvc userid [keyring] This will display the key with the 16-byte digest of the public key components. Read this 16-byte fingerprint to the key's owner on the phone, while she checks it against her own, using the same -kvc command at her end. You can both verify each other's keys this way, and then you can sign each other's keys with confidence. This is a safe and convenient way to get the key trust network started for your circle of friends. Note that sending a key fingerprint via E-mail is not the best way to verify the key, because E-mail can be intercepted and modified. It's best to use a different channel than the one that was used to send the key itself. A good combination is to send the key via E-mail, and the key fingerprint via a voice telephone conversation. Some people distribute their key fingerprint on their business cards, which looks really cool. For current versions of PGP, the key fingerprint is computed using the MD5 hash function. A future version of PGP will optionally use a new and different hash function, SHA, instead of MD5. If you don't know me, please don't call me to verify my key over the phone-- I get too many calls like that. Since every PGP user has a copy of my public key, no one could tamper with all the copies that are out there. The discrepancy would soon be noticed by someone who checked it from more than one source, and word would soon get out on the Internet. For those of you who want to verify my public key (included in the standard PGP release package), here are the particulars: UserID: "Philip R. Zimmermann " Key Size: 1024 bits; Creation date: 21 May 1993; KeyID: C7A966DD Key fingerprint: 9E 94 45 13 39 83 5F 70 7B E7 D8 ED C4 BE 5A A6 The information printed above conceivably could still be tampered with in the electronic distribution of the PGP User's Guide. But if you read this in the printed version of the manual, available in bookstores from MIT Press, it's a safe bet that it really is my own key's fingerprint. Handling Large Public Keyrings ------------------------------ PGP was originally designed for handling small personal keyrings for keeping all your friends on, like a personal rolodex. A couple hundred keys is a reasonable size for such a keyring. But as PGP has become more popular, people are now trying to add other large keyrings to their own keyring. Sometimes this involves adding thousands of keys to your keyring. PGP, in its present form, cannot perform this operation in a reasonable period of time, while you wait at your keyboard. Not for huge keyrings. You may want to add a huge "imported" keyring to your own keyring, because you are only interested in a few dozen keys on the bigger keyring you are bringing in. If that's all you want from the other keyring, it would be more efficient if you extract the few keys you need from the big foreign keyring, and then add just these few keys to your own keyring. Use the -kx command to extract them from the foreign keyring, specifying the keyring name on the command line. Then add these extracted keys to your own keyring. The real solution is to improve PGP to use advanced database techniques to manage large keyrings efficiently. We are working on this, and should have it done Real Soon Now. Until this happens, you will just have to use smaller keyrings, or be patient. Using PGP as a Unix-style Filter -------------------------------- Unix fans are accustomed to using Unix "pipes" to make two applications work together. The output of one application can be directly fed through a pipe to be read as input to another application. For this to work, the applications must be capable of reading the raw material from "standard input" and writing the finished output to "standard output". PGP can operate in this mode. If you don't understand what this means, then you probably don't need this feature. To use a Unix-style filter mode, reading from standard input and writing to standard output, add the -f option, like so: pgp -feast her_userid outputfile This feature makes it easier to make PGP work with electronic mail applications. When using PGP in filter mode to decrypt a ciphertext file, you may find it useful to use the PGPPASS environmental variable to hold the pass phrase, so that you won't be prompted for it. The PGPPASS feature is explained below. Suppressing Unnecessary Questions: BATCHMODE ---------------------------------------------- With the BATCHMODE flag enabled on the command line, PGP will not ask any unnecessary questions or prompt for alternate filenames. Here is an example of how to set this flag: pgp +batchmode cipherfile This is useful for running PGP non-interactively from Unix shell scripts or MSDOS batch files. Some key management commands still need user interaction even when BATCHMODE is on, so shell scripts may need to avoid them. BATCHMODE may also be enabled to check the validity of a signature on a file. If there was no signature on the file, the exit code is 1. If it had a signature that was good, the exit code is 0. Force "Yes" Answer to Confirmation Questions: FORCE ---------------------------------------------------- This command-line flag makes PGP assume "yes" for the user response to the confirmation request to overwrite an existing file, or when removing a key from the keyring via the -kr command. Here is an example of how to set this flag: pgp +force cipherfile or: pgp -kr +force Smith This feature is useful for running PGP non-interactively from a Unix shell script or MSDOS batch file. PGP Returns Exit Status to the Shell ------------------------------------ To facilitate running PGP in "batch" mode, such as from an MSDOS ".bat" file or from a Unix shell script, PGP returns an error exit status to the shell. An exit status code of zero means normal exit, while a nonzero exit status indicates some kind of error occurred. Different error exit conditions return different exit status codes to the shell. Environmental Variable for Pass Phrase -------------------------------------- Normally, PGP prompts the user to type a pass phrase whenever PGP needs a pass phrase to unlock a secret key. But it is possible to store the pass phrase in an environmental variable from your operating system's command shell. The environmental variable PGPPASS can be used to hold the pass phrase that PGP will attempt to use first. If the pass phrase stored in PGPPASS is incorrect, PGP recovers by prompting the user for the correct pass phrase. For example, on MSDOS, the shell command: SET PGPPASS=zaphod beeblebrox for president would eliminate the prompt for the pass phrase if the pass phrase were indeed "zaphod beeblebrox for president". This dangerous feature makes your life more convenient if you have to regularly deal with a large number of incoming messages addressed to your secret key, by eliminating the need for you to repeatedly type in your pass phrase every time you run PGP. I added this feature because of popular demand. However, this is a somewhat dangerous feature, because it keeps your precious pass phrase stored somewhere other than just in your brain. Even worse, if you are particularly reckless, it may even be stored on a disk on the same computer as your secret key. It would be particularly dangerous and stupid if you were to install this command in a batch or script file, such as the MSDOS AUTOEXEC.BAT file. Someone could come along on your lunch hour and steal both your secret key ring and the file containing your pass phrase. I can't emphasize the importance of this risk enough. If you are contemplating using this feature, be sure to read the sections "Exposure on Multi-user Systems" and "How to Protect Secret Keys from Disclosure" in this volume and in the Essential Topics volume of the PGP User's Guide. If you must use this feature, the safest way to do it would be to just manually type in the shell command to set PGPPASS every time you boot your machine to start using PGP, and then erase it or turn off your machine when you are done. And you should definitely never do it in an environment where someone else may have access to your machine. Someone could come along and simply ask your computer to display the contents of PGPPASS. Sometimes you want to pass the pass phrase into PGP from another application, such as an E-mail package. In some cases, it may not always be desirable to use the PGPPASS variable for that purpose. There is another way to pass your pass phrase into PGP from another application. Use the "-z" command line option. This option is designed primarily for invoking PGP from inside an E-mail package. The pass phrase follows the -z option on the command line. There are risks associated with using this approach, similar to those risks described above for using the PGPPASS variable. Setting Parameters in the PGP Configuration File ================================================ PGP has a number of user-settable parameters that can be defined in a special PGP configuration text file called "config.txt", in the directory pointed to by the shell environmental variable PGPPATH. Having a configuration file enables the user to define various flags and parameters for PGP without the burden of having to always define these parameters in the PGP command line. The filename "config.txt" has been in use for a long time by PGP, but some folks have pointed out that it may be at odds with naming conventions for configuration files for specific operating systems. Accordingly, PGP now tries to open this filename only after first trying to open the file ".pgprc" on Unix platforms, and "pgp.ini" on other platforms, in the same directory that PGP would look for "config.txt". Configuration parameters may be assigned integer values, character string values, or on/off values, depending on what kind of configuration parameter it is. A sample configuration file is provided with PGP, so you can see some examples. In the configuration file, blank lines are ignored, as is anything following the '#' comment character. Keywords are not case-sensitive. Here is a short sample fragment of a typical configuration file: # TMP is the directory for PGP scratch files, such as a RAM disk. TMP = "e:\" # Can be overridden by environment variable TMP. Armor = on # Use -a flag for ASCII armor whenever applicable. # CERT_DEPTH is how deeply introducers may introduce introducers. cert_depth = 3 If some configuration parameters are not defined in the configuration file, or if there is no configuration file, or if PGP can't find the configuration file, the values for the configuration parameters default to some reasonable value. Note that it is also possible to set these same configuration parameters directly from the PGP command line, by preceding the parameter setting with a "+" character. For example, the following two PGP commands produce the same effect: pgp -e +armor=on message.txt smith or: pgp -ea message.txt smith The following is a summary of the various parameters than may be defined in the configuration file. TMP - Directory Pathname for Temporary Files -------------------------------------------- Default setting: TMP = "" The configuration parameter TMP specifies what directory to use for PGP's temporary scratch files. The best place to put them is on a RAM disk, if you have one. That speeds things up quite a bit, and increases security somewhat. If TMP is undefined, the temporary files go in the current directory. If the shell environmental variable TMP is defined, PGP instead uses that to specify where the temporary files should go. LANGUAGE - Foreign Language Selector ------------------------------------ Default setting: LANGUAGE = "en" PGP displays various prompts, warning messages, and advisories to the user on the screen. For example, messages such as "File not found.", or "Please enter your pass phrase:". These messages are normally in English. But it is possible to get PGP to display its messages to the user in other languages, without having to modify the PGP executable program. A number of people in various countries have translated all of PGP's display messages, warnings, and prompts into their native languages. These hundreds of translated message strings have been placed in a special text file called "language.txt", distributed with the PGP release. The messages are stored in this file in English, Spanish, Dutch, German, French, Italian, Russian, Latvian, and Lithuanian. Other languages may be added later. The configuration parameter LANGUAGE specifies what language to display these messages in. LANGUAGE may be set to "en" for English, "es" for Spanish, "de" for German, "nl" for Dutch, "fr" for French, "it" for Italian, "ru" for Russian, "lt3" for Lithuanian, "lv" for Latvian, "esp" for Esperanto. For example, if this line appeared in the configuration file: LANGUAGE = "fr" PGP would select French as the language for its display messages. The default setting is English. When PGP needs to display a message to the user, it looks in the "language.txt" file for the equivalent message string in the selected foreign language and displays that translated message to the user. If PGP can't find the language string file, or if the selected language is not in the file, or if that one phrase is not translated into the selected language in the file, or if that phrase is missing entirely from the file, PGP displays the message in English. To conserve disk space, most foreign translations are not included in the standard PGP release package, but are available separately. MYNAME - Default User ID for Making Signatures ---------------------------------------------- Default setting: MYNAME = "" The configuration parameter MYNAME specifies the default user ID to use to select the secret key for making signatures. If MYNAME is not defined, the most recent secret key you installed on your secret key ring will be used. The user may also override this setting by specifying a user ID on the PGP command line with the -u option. TEXTMODE - Assuming Plaintext is a Text File -------------------------------------------- Default setting: TEXTMODE = off The configuration parameter TEXTMODE is equivalent to the -t command line option. If enabled, it causes PGP to assume the plaintext is a text file, not a binary file, and converts it to "canonical text" before encrypting it. Canonical text has a carriage return and a linefeed at the end of each line of text. This mode will be automatically turned off if PGP detects that the plaintext file contains what it thinks is non-text binary data. If you intend to use PGP primarily for E-mail purposes, you should turn TEXTMODE=ON. For VAX/VMS systems, the current version of PGP defaults TEXTMODE=ON. For further details, see the section "Sending ASCII Text Files Across Different Machine Environments". CHARSET - Specifies Local Character Set for Text Files ------------------------------------------------------ Default setting: CHARSET = NOCONV Because PGP must process messages in many non-English languages with non-ASCII character sets, you may have a need to tell PGP what local character set your machine uses. This determines what character conversions are performed when converting plaintext files to and from canonical text format. This is only a concern if you are in a non-English non-ASCII environment. The configuration parameter CHARSET selects the local character set. The choices are NOCONV (no conversion), LATIN1 (ISO 8859-1 Latin Alphabet 1), KOI8 (used by most Russian Unix systems), ALT_CODES (used by Russian MSDOS systems), ASCII, and CP850 (used by most western European languages on standard MSDOS PCs). LATIN1 is the internal representation used by PGP for canonical text, so if you select LATIN1, no conversion is done. Note also that PGP treats KOI8 as LATIN1, even though it is a completely different character set (Russian), because trying to convert KOI8 to either LATIN1 or CP850 would be futile anyway. This means that setting CHARSET to NOCONV, LATIN1, or KOI8 are all equivalent to PGP. If you use MSDOS and expect to send or receive traffic in western European languages, set CHARSET = "CP850". This will make PGP convert incoming canonical text messages from LATIN1 to CP850 after decryption. If you use the -t (textmode) option to convert to canonical text, PGP will convert your CP850 text to LATIN1 before encrypting it. For further details, see the section "Sending ASCII Text Files Across Different Machine Environments". ARMOR - Enable ASCII Armor Output --------------------------------- Default setting: ARMOR = off The configuration parameter ARMOR is equivalent to the -a command line option. If enabled, it causes PGP to emit ciphertext or keys in ASCII Radix-64 format suitable for transporting through E-mail channels. Output files are named with the ".asc" extension. If you intend to use PGP primarily for E-mail purposes, you should turn ARMOR=ON. For further details, see the section "Sending Ciphertext Through E-mail Channels: Radix-64 Format" in the Essential Topics volume. ARMORLINES - Size of ASCII Armor Multipart Files ------------------------------------------------ Default setting: ARMORLINES = 720 When PGP creates a very large ".asc" radix-64 file for sending ciphertext or keys through the E-mail, it breaks the file up into separate chunks small enough to send through Internet mail utilities. Normally, Internet mailers prohibit files larger than about 50000 bytes, which means that if we restrict the number of lines to about 720, we'll be well within the limit. The file chunks are named with suffixes ".as1", ".as2", ".as3", ... The configuration parameter ARMORLINES specifies the maximum number of lines to make each chunk in a multipart ".asc" file sequence. If you set it to zero, PGP will not break up the file into chunks. Fidonet E-mail files usually have an upper limit of about 32K bytes, so 450 lines would be appropriate for Fidonet environments. For further details, see the section "Sending Ciphertext Through E-mail Channels: Radix-64 Format" in the Essential Topics volume. KEEPBINARY - Keep Binary Ciphertext Files After Decrypting ---------------------------------------------------------- Default setting: KEEPBINARY = off When PGP reads a ".asc" file, it recognizes that the file is in radix-64 format and will convert it back to binary before processing as it normally does, producing as a by-product a ".pgp" ciphertext file in binary form. After further processing to decrypt the ".pgp" file, the final output file will be in normal plaintext form. You may want to delete the binary ".pgp" intermediate file, or you may want PGP to delete it for you automatically. You can still rerun PGP on the original ".asc" file. The configuration parameter KEEPBINARY enables or disables keeping the intermediate ".pgp" file during decryption. For further details, see the section "Sending Ciphertext Through E-mail Channels: Radix-64 Format" in the Essential Topics volume. COMPRESS - Enable Compression ----------------------------- Default setting: COMPRESS = on The configuration parameter COMPRESS enables or disables data compression before encryption. It is used mainly for debugging PGP. Normally, PGP attempts to compress the plaintext before it encrypts it. Generally, you should leave this alone and let PGP attempt to compress the plaintext. COMPLETES_NEEDED - Number of Completely Trusted Introducers Needed ------------------------------------------------------------------ Default setting: COMPLETES_NEEDED = 1 The configuration parameter COMPLETES_NEEDED specifies the minimum number of completely trusted introducers required to fully certify a public key on your public key ring. This gives you a way of tuning PGP's skepticism. For further details, see the section "How Does PGP Keep Track of Which Keys are Valid?" in the Essential Topics volume. MARGINALS_NEEDED - Number of Marginally Trusted Introducers Needed ------------------------------------------------------------------ Default setting: MARGINALS_NEEDED = 2 The configuration parameter MARGINALS_NEEDED specifies the minimum number of marginally trusted introducers required to fully certify a public key on your public key ring. This gives you a way of tuning PGP's skepticism. For further details, see the section "How Does PGP Keep Track of Which Keys are Valid?" in the Essential Topics volume. CERT_DEPTH - How Deep May Introducers Be Nested ----------------------------------------------- Default setting: CERT_DEPTH = 4 The configuration parameter CERT_DEPTH specifies how many levels deep you may nest introducers to certify other introducers to certify public keys on your public key ring. For example, If CERT_DEPTH is set to 1, there may only be one layer of introducers below your own ultimately-trusted key. If that were the case, you would be required to directly certify the public keys of all trusted introducers on your key ring. If you set CERT_DEPTH to 0, you could have no introducers at all, and you would have to directly certify each and every key on your public key ring in order to use it. The minimum CERT_DEPTH is 0, the maximum is 8. For further details, see the section "How Does PGP Keep Track of Which Keys are Valid?" in the Essential Topics volume. BAKRING - Filename for Backup Secret Keyring -------------------------------------------- Default setting: BAKRING = "" All of the key certification that PGP does on your public key ring ultimately depends on your own ultimately-trusted public key (or keys). To detect any tampering of your public key ring, PGP must check that your own key has not been tampered with. To do this, PGP must compare your public key against a backup copy of your secret key on some tamper-resistant media, such as a write-protected floppy disk. A secret key contains all the information that your public key has, plus some secret components. This means PGP can check your public key against a backup copy of your secret key. The configuration parameter BAKRING specifies what pathname to use for PGP's trusted backup copy of your secret key ring. On MSDOS, you could set it to "a:\secring.pgp" to point it at a write-protected backup copy of your secret key ring on your floppy drive. This check is performed only when you execute the PGP -kc option to check your whole public key ring. If BAKRING is not defined, PGP will not check your own key against any backup copy. For further details, see the sections "How to Protect Public Keys from Tampering" and "How Does PGP Keep Track of Which Keys are Valid?" in the Essential Topics volume. PUBRING - Filename for Your Public Keyring ------------------------------------------ Default setting: PUBRING = "$PGPPATH/pubring.pgp" You may want to keep your public keyring in a directory separate from your PGP configuration file in the directory specified by your $PGPPATH environmental variable. You may specify the full path and filename for your public keyring by setting the PUBRING parameter. For example, on an MSDOS system, you might want to keep your public keyring on a floppy disk by: PUBRING = "a:pubring.pgp" This feature is especially handy for specifying an alternative keyring on the command line. SECRING - Filename for Your Secret Keyring ------------------------------------------ Default setting: SECRING = "$PGPPATH/secring.pgp" You may want to keep your secret keyring in a directory separate from your PGP configuration file in the directory specified by your $PGPPATH environmental variable. This comes in handy for putting your secret keyring in a directory or device that is more protected than your public keyring. You may specify the full path and filename for your secret keyring by setting the SECRING parameter. For example, on an MSDOS system, you might want to keep your secret keyring on a floppy disk by: SECRING = "a:secring.pgp" RANDSEED - Filename for Random Number Seed ------------------------------------------ Default setting: RANDSEED = "$PGPPATH/randseed.bin" You may want to keep your random number seed file (for generation of session keys) in a directory separate from your PGP configuration file in the directory specified by your $PGPPATH environmental variable. This comes in handy for putting your random number seed file in a directory or device that is more protected than your public keyring. You may specify the full path and filename for your random seed file by setting the RANDSEED parameter. For example, on an MSDOS system, you might want to keep it on a floppy disk by: RANDSEED = "a:randseed.bin" PAGER - Selects Shell Command to Display Plaintext Output --------------------------------------------------------- Default setting: PAGER = "" PGP lets you view the decrypted plaintext output on your screen (like the Unix-style "more" command), without writing it to a file, if you use the -m (more) option while decrypting. This displays the decrypted plaintext display on your screen one screenful at a time. If you prefer to use a fancier page display utility, rather than PGP's built-in one, you can specify the name of a shell command that PGP will invoke to display your plaintext output file. The configuration parameter PAGER specifies the shell command to invoke to display the file. For example, on MSDOS systems, you might want to use the popular shareware program "list.com" to display your plaintext message. Assuming you have a copy of "list.com", you may set PAGER accordingly: PAGER = "list" However, if the sender specified that this file is for your eyes only, and may not be written to disk, PGP always uses its own built-in display function. For further details, see the section "Displaying Decrypted Plaintext on Your Screen". SHOWPASS - Echo Pass Phrase to User ----------------------------------- Default setting: SHOWPASS = off Normally, PGP does not let you see your pass phrase as you type it in. This makes it harder for someone to look over your shoulder while you type and learn your pass phrase. But some typing-impaired people have problems typing their pass phrase without seeing what they are typing, and they may be typing in the privacy of their own homes. So they asked if PGP can be configured to let them see what they type when they type in their pass phrase. The configuration parameter SHOWPASS enables PGP to echo your typing during pass phrase entry. TZFIX - Timezone Adjustment --------------------------- Default setting: TZFIX = 0 PGP provides timestamps for keys and signature certificates in Greenwich Mean Time (GMT), or Coordinated Universal Time (UTC), which means the same thing for our purposes. When PGP asks the system for the time of day, the system is supposed to provide it in GMT. But sometimes, because of improperly configured MSDOS systems, the system time is returned in US Pacific Standard Time time plus 8 hours. Sounds weird, doesn't it? Perhaps because of some sort of US west-coast jingoism, MSDOS presumes local time is US Pacific time, and pre-corrects Pacific time to GMT. This adversely affects the behavior of the internal MSDOS GMT time function that PGP calls. However, if your MSDOS environmental variable TZ is already properly defined for your timezone, this corrects the misconception MSDOS has that the whole world lives on the US west coast. The configuration parameter TZFIX specifies the number of hours to add to the system time function to get GMT, for GMT timestamps on keys and signatures. If the MSDOS environmental variable TZ is defined properly, you can leave TZFIX=0. Unix systems usually shouldn't need to worry about setting TZFIX at all. But if you are using some other obscure operating system that doesn't know about GMT, you may have to use TZFIX to adjust the system time to GMT. On MSDOS systems that do not have TZ defined in the environment, you should make TZFIX=0 for California, -1 for Colorado, -2 for Chicago, -3 for New York, -8 for London, -9 for Amsterdam. In the summer, TZFIX should be manually decremented from these values. What a mess. It would be much cleaner to set your MSDOS environmental variable TZ in your AUTOEXEC.BAT file, and not use the TZFIX correction. Then MSDOS gives you good GMT timestamps, and will handle daylight savings time adjustments for you. Here are some sample lines to insert into AUTOEXEC.BAT, depending on your time zone: For Los Angeles: SET TZ=PST8PDT For Denver: SET TZ=MST7MDT For Arizona: SET TZ=MST7 (Arizona never uses daylight savings time) For Chicago: SET TZ=CST6CDT For New York: SET TZ=EST5EDT For London: SET TZ=GMT0BST For Amsterdam: SET TZ=MET-1DST For Moscow: SET TZ=MSK-3MSD For Aukland: SET TZ=NZT-13 CLEARSIG - Enable Signed Messages to be Encapsulated as Clear Text ------------------------------------------------------------------ Default setting: CLEARSIG = on Normally, unencrypted PGP signed messages have a signature certificate prepended in binary form. Also, the signed message is compressed, rendering the message unreadable to casual human eyes, even though the message is not actually encrypted. To send this binary data through a 7-bit E-mail channel, radix-64 ASCII armor is applied (see the ARMOR parameter). Even if PGP didn't compress the message, the ASCII armor would still render the message unreadable to human eyes. The recipient must use PGP to strip the armor off and decompress it before reading the message. If the original plaintext message is in text (not binary) form, there is a way to send a signed message through an E-mail channel in such a way that the signed message is not compressed and the ASCII armor is applied only to the binary signature certificate, but not to the plaintext message. The CLEARSIG flag provides this useful feature, making it possible to generate a signed message that can be read with human eyes, without the aid of PGP. Of course, you still need PGP to actually check the signature. The CLEARSIG flag is preset to "on" beginning with PGP version 2.5. To enable the full CLEARSIG behavior, the ARMOR and TEXTMODE flags must also be turned on. Set ARMOR=ON (or use the -a option), and set TEXTMODE=ON (or use the -t option). If your config file has CLEARSIG turned off, you can turn it back on again directly on the command line, like so: pgp -sta +clearsig=on message.txt This message representation is analogous to the MIC-CLEAR message type used in Internet Privacy Enhanced Mail (PEM). It is important to note that since this method only applies ASCII armor to the binary signature certificate, and not to the message text itself, there is some risk that the unarmored message may suffer some accidental molestation while en route. This can happen if it passes through some E-mail gateway that performs character set conversions, or in some cases extra spaces may be added to or stripped from the ends of lines. If this occurs, the signature will fail to verify, which may give a false indication of intentional tampering. But since PEM lives under a similar vulnerability, it seems worth having this feature despite the risks. Beginning with PGP version 2.2, trailing blanks are ignored on each line in calculating the signature for text in CLEARSIG mode. VERBOSE - Quiet, Normal, or Verbose Messages -------------------------------------------- Default setting: VERBOSE = 1 VERBOSE may be set to 0, 1, or 2, depending on how much detail you want to see from PGP diagnostic messages. The settings are: 0 - Display messages only if there is a problem. Unix fans wanted this "quiet mode" setting. 1 - Normal default setting. Displays a reasonable amount of detail in diagnostic or advisory messages. 2 - Displays maximum information, usually to help diagnose problems in PGP. Not recommended for normal use. Besides, PGP doesn't have any problems, right? INTERACTIVE - Ask for Confirmation for Key Adds ----------------------------------------------- Default Setting: INTERACTIVE = off Enabling this mode will mean that if you add a key file containing multiple keys to your key ring, PGP will ask for confirmation for each key before adding it to your key ring. NOMANUAL - Let PGP Generate Keys Without the Manual --------------------------------------------------- Default Setting: NOMANUAL = off It is important that the freeware version of PGP not be distributed without the user documentation, which normally comes with it in the standard release package. This manual contains important information for using PGP, as well as important legal notices. But some people have distributed previous versions of PGP without the manual, causing a lot of problems for a lot of people who get it. To discourage the distribution of PGP without the required documentation, PGP has been changed to require the PGP User's Guide to be found somewhere on your computer (like in your PGP directory) before PGP will let you generate a key pair. However, some users like to use PGP on tiny palmtop computers with limited storage capacity, so they like to run PGP without the documentation present on their systems. To satisfy these users, PGP can be made to relax its requirement that the manual be present, by enabling the NOMANUAL flag on the command line during key generation, like so: pgp -kg +nomanual The NOMANUAL flag can only be set on the command line, not in the config file. Since you must read this manual to learn how to enable this simple override feature, I hope this will still be effective in discouraging the distribution of PGP without the manual. Some people may object to PGP insisting on finding the manual somewhere in the neighborhood to generate a key. They bristle against this seemingly authoritarian attitude. Some people have even modified PGP to defeat this feature, and redistributed their hotwired version to others. That creates problems for me. Before I added this feature, there were maimed versions of the PGP distribution package floating around that lacked the manual. One of them was uploaded to Compuserve, and was distributed to countless users who called me on the phone to ask me why such a complicated program had no manual. It spread out to BBS systems around the country. And a freeware distributor got hold of the package from Compuserve and enshrined it on CD-ROM, distributing thousands of copies without the manual. What a mess. A Peek Under the Hood ===================== Let's take a look at a few internal features of PGP. Random Numbers -------------- PGP uses a cryptographically strong pseudorandom number generator for creating temporary conventional session keys. The seed file for this is called "randseed.bin". It too can be kept in whatever directory is indicated by the PGPPATH environmental variable. If this random seed file does not exist, it is automatically created and seeded with truly random numbers derived from timing your keystroke latencies. This generator reseeds the disk file each time it is used by mixing in new key material partially derived with the time of day and other truly random sources. It uses the conventional encryption algorithm as an engine for the random number generator. The seed file contains both random seed material and random key material to key the conventional encryption engine for the random generator. This random seed file should be at least slightly protected from disclosure, to reduce the risk of an attacker deriving your next or previous session keys. The attacker would have a very hard time getting anything useful from capturing this random seed file, because the file is cryptographically laundered before and after each use. Nonetheless, it seems prudent to at least try to keep it from falling into the wrong hands. If you feel uneasy about trusting any algorithmically derived random number source however strong, keep in mind that you already trust the strength of the same conventional cipher to protect your messages. If it's strong enough for that, then it should be strong enough to use as a source of random numbers for temporary session keys. Note that PGP still uses truly random numbers from physical sources (mainly keyboard timings) to generate long-term public/secret key pairs. PGP's Conventional Encryption Algorithm --------------------------------------- As described earlier, PGP "bootstraps" into a conventional single-key encryption algorithm by using a public key algorithm to encipher the conventional session key and then switching to fast conventional cryptography. So let's talk about this conventional encryption algorithm. It isn't the DES. The Federal Data Encryption Standard (DES) used to be a good algorithm for most commercial applications. But the Government never did trust the DES to protect its own classified data, because the DES key length is only 56 bits, short enough for a brute force attack. Also, the full 16-round DES has been attacked with some success by Biham and Shamir using differential cryptanalysis, and by Matsui using linear cryptanalysis. The most devastating practical attack on the DES was described at the Crypto '93 conference, where Michael Wiener of Bell Northern Research presented a paper on how to crack the DES with a special machine. He has fully designed and tested a chip that guesses 50 million DES keys per second until it finds the right one. Although he has refrained from building the real chips so far, he can get these chips manufactured for $10.50 each, and can build 57000 of them into a special machine for $1 million that can try every DES key in 7 hours, averaging a solution in 3.5 hours. $1 million can be hidden in the budget of many companies. For $10 million, it takes 21 minutes to crack, and for $100 million, just two minutes. With any major government's budget for examining DES traffic, it can be cracked in seconds. This means that straight 56-bit DES is now effectively dead for purposes of serious data security applications. A possible successor to DES may be a variation known as "triple DES", which uses two DES keys to encrypt three times, achieving an effective key space of 112 bits. But this approach is three times slower than normal DES. A future version of PGP may support triple DES as an option. PGP does not use the DES as its conventional single-key algorithm to encrypt messages. Instead, PGP uses a different conventional single-key block encryption algorithm, called IDEA(tm). For the cryptographically curious, the IDEA cipher has a 64-bit block size for the plaintext and the ciphertext. It uses a key size of 128 bits. It is based on the design concept of "mixing operations from different algebraic groups". It runs much faster in software than the DES. Like the DES, it can be used in cipher feedback (CFB) and cipher block chaining (CBC) modes. PGP uses it in 64-bit CFB mode. The IPES/IDEA block cipher was developed at ETH in Zurich by James L. Massey and Xuejia Lai, and published in 1990. This is not a "home-grown" algorithm. Its designers have a distinguished reputation in the cryptologic community. Early published papers on the algorithm called it IPES (Improved Proposed Encryption Standard), but they later changed the name to IDEA (International Data Encryption Algorithm). So far, IDEA has resisted attack much better than other ciphers such as FEAL, REDOC-II, LOKI, Snefru and Khafre. And recent evidence suggests that IDEA is more resistant than the DES to Biham & Shamir's highly successful differential cryptanalysis attack. Biham and Shamir have been examining the IDEA cipher for weaknesses, without success. Academic cryptanalyst groups in Belgium, England, and Germany are also attempting to attack it, as well as the military services from several European countries. As this new cipher continues to attract attack efforts from the most formidable quarters of the cryptanalytic world, confidence in IDEA is growing with the passage of time. Every once in a while, I get a letter from someone who has just learned the awful truth that PGP does not use pure RSA to encrypt bulk data. They are concerned that the whole package is weakened if we use a hybrid public-key and conventional scheme just to speed things up. After all, a chain is only as strong as its weakest link. They demand an explanation for this apparent "compromise" in the strength of PGP. This may be because they have been caught up in the public's reverence and awe for the strength and mystique of RSA, mistakenly believing that RSA is intrinsically stronger than any conventional cipher. Well, it's not. People who work in factoring research say that the workload to exhaust all the possible 128-bit keys in the IDEA cipher would roughly equal the factoring workload to crack a 3100-bit RSA key, which is quite a bit bigger than the 1024-bit RSA key size that most people use for high security applications. Given this range of key sizes, and assuming there are no hidden weaknesses in the conventional cipher, the weak link in this hybrid approach is in the public key algorithm, not the conventional cipher. It is not ergonomically practical to use pure RSA with large keys to encrypt and decrypt long messages. A 1024-bit RSA key would decrypt messages about 4000 times slower than the IDEA cipher. Absolutely no one does it that way in the real world. Many people less experienced in cryptography do not realize that the attraction of public key cryptography is not because it is intrinsically stronger than a conventional cipher-- its appeal is because it helps you manage keys more conveniently. Not only is RSA too slow to use on bulk data, but it even has certain weaknesses that can be exploited in some special cases of particular kinds of messages that are fed to the RSA cipher, even for large keys. These special cases can be avoided by using the hybrid approach of using RSA to encrypt random session keys for a conventional cipher, like PGP does. So the bottom line is this: Using pure RSA on bulk data is the wrong approach, period. It's too slow, it's not stronger, and may even be weaker. If you find a software application that uses pure RSA on bulk data, it probably means the implementor does not understand these issues, which could imply he doesn't understand other important concepts of cryptography. Data Compression ---------------- PGP normally compresses the plaintext before encrypting it. It's too late to compress it after it has been encrypted; encrypted data is incompressible. Data compression saves modem transmission time and disk space and more importantly strengthens cryptographic security. Most cryptanalysis techniques exploit redundancies found in the plaintext to crack the cipher. Data compression reduces this redundancy in the plaintext, thereby greatly enhancing resistance to cryptanalysis. It takes extra time to compress the plaintext, but from a security point of view it seems worth it, at least in my cautious opinion. Files that are too short to compress or just don't compress well are not compressed by PGP. If you prefer, you can use PKZIP to compress the plaintext before encrypting it. PKZIP is a widely-available and effective MSDOS shareware compression utility from PKWare, Inc. Or you can use ZIP, a PKZIP-compatible freeware compression utility on Unix and other systems, available from Jean-Loup Gailly. There is some advantage in using PKZIP or ZIP in certain cases, because unlike PGP's built-in compression algorithm, PKZIP and ZIP have the nice feature of compressing multiple files into a single compressed file, which is reconstituted again into separate files when decompressed. PGP will not try to compress a plaintext file that has already been compressed. After decrypting, the recipient can decompress the plaintext with PKUNZIP. If the decrypted plaintext is a PKZIP compressed file, PGP automatically recognizes this and advises the recipient that the decrypted plaintext appears to be a PKZIP file. For the technically curious readers, the current version of PGP uses the freeware ZIP compression routines written by Jean-loup Gailly, Mark Adler, and Richard B. Wales. This ZIP software uses functionally-equivalent compression algorithms as those used by PKWare's new PKZIP 2.0. This ZIP compression software was selected for PGP mainly because of its free portable C source code availability, and because it has a really good compression ratio, and because it's fast. Peter Gutmann has also written a nice compression utility called HPACK, available for free from many Internet FTP sites. It encrypts the compressed archives, using PGP data formats and key rings. He wanted me to mention that here. Message Digests and Digital Signatures -------------------------------------- To create a digital signature, PGP encrypts with your secret key. But PGP doesn't actually encrypt your entire message with your secret key-- that would take too long. Instead, PGP encrypts a "message digest". The message digest is a compact (128 bit) "distillate" of your message, similar in concept to a checksum. You can also think of it as a "fingerprint" of the message. The message digest "represents" your message, such that if the message were altered in any way, a different message digest would be computed from it. This makes it possible to detect any changes made to the message by a forger. A message digest is computed using a cryptographically strong one-way hash function of the message. It would be computationally infeasible for an attacker to devise a substitute message that would produce an identical message digest. In that respect, a message digest is much better than a checksum, because it is easy to devise a different message that would produce the same checksum. But like a checksum, you can't derive the original message from its message digest. A message digest alone is not enough to authenticate a message. The message digest algorithm is publicly known, and does not require knowledge of any secret keys to calculate. If all we did was attach a message digest to a message, then a forger could alter a message and simply attach a new message digest calculated from the new altered message. To provide real authentication, the sender has to encrypt (sign) the message digest with his secret key. A message digest is calculated from the message by the sender. The sender's secret key is used to encrypt the message digest and an electronic timestamp, forming a digital signature, or signature certificate. The sender sends the digital signature along with the message. The receiver receives the message and the digital signature, and recovers the original message digest from the digital signature by decrypting it with the sender's public key. The receiver computes a new message digest from the message, and checks to see if it matches the one recovered from the digital signature. If it matches, then that proves the message was not altered, and it came from the sender who owns the public key used to check the signature. A potential forger would have to either produce an altered message that produces an identical message digest (which is infeasible), or he would have to create a new digital signature from a different message digest (also infeasible, without knowing the true sender's secret key). Digital signatures prove who sent the message, and that the message was not altered either by error or design. It also provides non-repudiation, which means the sender cannot easily disavow his signature on the message. Using message digests to form digital signatures has other advantages besides being faster than directly signing the entire actual message with the secret key. Using message digests allows signatures to be of a standard small fixed size, regardless of the size of the actual message. It also allows the software to check the message integrity automatically, in a manner similar to using checksums. And it allows signatures to be stored separately from messages, perhaps even in a public archive, without revealing sensitive information about the actual messages, because no one can derive any message content from a message digest. The message digest algorithm used here is the MD5 Message Digest Algorithm, placed in the public domain by RSA Data Security, Inc. MD5's designer, Ronald Rivest, writes this about MD5: "It is conjectured that the difficulty of coming up with two messages having the same message digest is on the order of 2^64 operations, and that the difficulty of coming up with any message having a given message digest is on the order of 2^128 operations. The MD5 algorithm has been carefully scrutinized for weaknesses. It is, however, a relatively new algorithm and further security analysis is of course justified, as is the case with any new proposal of this sort. The level of security provided by MD5 should be sufficient for implementing very high security hybrid digital signature schemes based on MD5 and the RSA public-key cryptosystem." Compatibility with Previous and Future Versions of PGP ====================================================== PGP version 2.6 can read anything produced by versions 2.3 through 2.7. However, because of a negotiated agreement between MIT and RSA Data Security, PGP 2.6 was programmed to change its behavior slightly on 1 September 1994, triggered by a built-in software timer. On that date, version 2.6 started producing a new and slightly different data format for messages, signatures and keys. PGP 2.6 will still be able to read and process messages, signatures, and keys produced under the old format, but it will generate the new format. This change is intended to discourage people from continuing to use the older (2.3a and earlier) versions of PGP, which Public Key Partners contends infringes its RSA patent (see the section on Legal Issues). ViaCrypt PGP (see the section Where to Get a Commercial Version of PGP), versions 2.4 and 2.7, avoids questions of infringement through Viacrypt's license arrangement with Public Key Partners. PGP 2.5 and 2.6 avoid questions of infringement by using the RSAREF(TM) Cryptographic Toolkit, under license from RSA Data Security, Inc. Outside the United States, the RSA patent is not in force, so PGP users there are free to use implementations of PGP that do not rely on RSAREF and its restrictions. See the notes on foreign versions in the Legal Issues section later in this manual. It seems likely that any versions of PGP prepared outside the US will accept the new format, whose detailed description is available from MIT. If everyone upgrades before September 1994, or soon thereafter, there will be little interoperability problems. This format change beginning with 2.6 is similar to the process that naturally happens when new features are added, causing older versions of PGP to be unable to read stuff from the newer PGP, while the newer version can still read the old stuff. The only difference is that this is a "legal upgrade", instead of a technical one. It's a worthwhile change, if it can achieve peace in our time. According to ViaCrypt, which sells a commercial version of PGP, ViaCrypt PGP will evolve to maintain interoperability with new freeware versions of PGP. There is a another change that effects interoperability with earlier versions of PGP. Unfortunately, due to data format limitations imposed by RSAREF, PGP 2.5 and 2.6 cannot interpret any messages or signatures made with PGP version 2.2 or earlier. Since we had no choice but to use the new data formats, because of the need to switch to RSAREF, we can't do anything about this problem. Beginning with version 2.4 (which was ViaCrypt's first version) through at least 2.6, PGP does not allow you to generate RSA keys bigger than 1024 bits. The upper limit was always intended to be 1024 bits -- there had to be some kind of upper limit, for performance and interoperability reasons. But because of a bug in earlier versions of PGP, it was possible to generate keys larger than 1024 bits. These larger keys caused interoperability problems between different older versions of PGP that used different arithmetic algorithms with different native word sizes. On some platforms, PGP choked on the larger keys. In addition to these older key size problems, the 1024-bit limit is now enforced by RSAREF. A 1024-bit key is very likely to be well out of reach of attacks by major governments. In a future version, PGP will support bigger keys. In general, there is compatibility from version 2.0 upwards through 2.4. Because new features are added, older versions may not always be able to handle some files created with newer versions. Because of massive changes to all the algorithms and data structures, PGP version 2.0 (and later) is not even slightly compatible with PGP version 1.0, which no one uses anymore anyway. Future versions of PGP may have to change the data formats for messages, signatures, keys and key rings, in order to provide important new features. We will endeavor to make future versions handle keys, signatures, and messages from this version, but this is not guaranteed. Future releases may provide conversion utilities to convert old keys, but you may have to dispose of old messages created with the old PGP. Also, this current version may not be able to read stuff produced from all future versions. Vulnerabilities =============== No data security system is impenetrable. PGP can be circumvented in a variety of ways. In any data security system, you have to ask yourself if the information you are trying to protect is more valuable to your attacker than the cost of the attack. This should lead you to protecting yourself from the cheapest attacks, while not worrying about the more expensive attacks. Some of the discussion that follows may seem unduly paranoid, but such an attitude is appropriate for a reasonable discussion of vulnerability issues. Compromised Pass Phrase and Secret Key -------------------------------------- Probably the simplest attack is if you leave your pass phrase for your secret key written down somewhere. If someone gets it and also gets your secret key file, they can read your messages and make signatures in your name. Don't use obvious passwords that can be easily guessed, such as the names of your kids or spouse. If you make your pass phrase a single word, it can be easily guessed by having a computer try all the words in the dictionary until it finds your password. That's why a pass phrase is so much better than a password. A more sophisticated attacker may have his computer scan a book of famous quotations to find your pass phrase. An easy to remember but hard to guess pass phrase can be easily constructed by some creatively nonsensical sayings or very obscure literary quotes. For further details, see the section "How to Protect Secret Keys from Disclosure" in the Essential Topics volume of the PGP User's Guide. Public Key Tampering -------------------- A major vulnerability exists if public keys are tampered with. This may be the most crucially important vulnerability of a public key cryptosystem, in part because most novices don't immediately recognize it. The importance of this vulnerability, and appropriate hygienic countermeasures, are detailed in the section "How to Protect Public Keys from Tampering" in the Essential Topics volume. To summarize: When you use someone's public key, make certain it has not been tampered with. A new public key from someone else should be trusted only if you got it directly from its owner, or if it has been signed by someone you trust. Make sure no one else can tamper with your own public key ring. Maintain physical control of both your public key ring and your secret key ring, preferably on your own personal computer rather than on a remote timesharing system. Keep a backup copy of both key rings. "Not Quite Deleted" Files ------------------------- Another potential security problem is caused by how most operating systems delete files. When you encrypt a file and then delete the original plaintext file, the operating system doesn't actually physically erase the data. It merely marks those disk blocks as deleted, allowing the space to be reused later. It's sort of like discarding sensitive paper documents in the paper recycling bin instead of the paper shredder. The disk blocks still contain the original sensitive data you wanted to erase, and will probably eventually be overwritten by new data at some point in the future. If an attacker reads these deleted disk blocks soon after they have been deallocated, he could recover your plaintext. In fact this could even happen accidentally, if for some reason something went wrong with the disk and some files were accidentally deleted or corrupted. A disk recovery program may be run to recover the damaged files, but this often means some previously deleted files are resurrected along with everything else. Your confidential files that you thought were gone forever could then reappear and be inspected by whomever is attempting to recover your damaged disk. Even while you are creating the original message with a word processor or text editor, the editor may be creating multiple temporary copies of your text on the disk, just because of its internal workings. These temporary copies of your text are deleted by the word processor when it's done, but these sensitive fragments are still on your disk somewhere. Let me tell you a true horror story. I had a friend, married with young children, who once had a brief and not very serious affair. She wrote a letter to her lover on her word processor, and deleted the letter after she sent it. Later, after the affair was over, the floppy disk got damaged somehow and she had to recover it because it contained other important documents. She asked her husband to salvage the disk, which seemed perfectly safe because she knew she had deleted the incriminating letter. Her husband ran a commercial disk recovery software package to salvage the files. It recovered the files alright, including the deleted letter. He read it, which set off a tragic chain of events. The only way to prevent the plaintext from reappearing is to somehow cause the deleted plaintext files to be overwritten. Unless you know for sure that all the deleted disk blocks will soon be reused, you must take positive steps to overwrite the plaintext file, and also any fragments of it on the disk left by your word processor. You can overwrite the original plaintext file after encryption by using the PGP -w (wipe) option. You can take care of any fragments of the plaintext left on the disk by using any of the disk utilities available that can overwrite all of the unused blocks on a disk. For example, the Norton Utilities for MSDOS can do this. Even if you overwrite the plaintext data on the disk, it may still be possible for a resourceful and determined attacker to recover the data. Faint magnetic traces of the original data remain on the disk after it has been overwritten. Special sophisticated disk recovery hardware can sometimes be used to recover the data. Viruses and Trojan Horses ------------------------- Another attack could involve a specially-tailored hostile computer virus or worm that might infect PGP or your operating system. This hypothetical virus could be designed to capture your pass phrase or secret key or deciphered messages, and covertly write the captured information to a file or send it through a network to the virus's owner. Or it might alter PGP's behavior so that signatures are not properly checked. This attack is cheaper than cryptanalytic attacks. Defending against this falls under the category of defending against viral infection generally. There are some moderately capable anti-viral products commercially available, and there are hygienic procedures to follow that can greatly reduce the chances of viral infection. A complete treatment of anti-viral and anti-worm countermeasures is beyond the scope of this document. PGP has no defenses against viruses, and assumes your own personal computer is a trustworthy execution environment. If such a virus or worm actually appeared, hopefully word would soon get around warning everyone. Another similar attack involves someone creating a clever imitation of PGP that behaves like PGP in most respects, but doesn't work the way it's supposed to. For example, it might be deliberately crippled to not check signatures properly, allowing bogus key certificates to be accepted. This "Trojan horse" version of PGP is not hard for an attacker to create, because PGP source code is widely available, so anyone could modify the source code and produce a lobotomized zombie imitation PGP that looks real but does the bidding of its diabolical master. This Trojan horse version of PGP could then be widely circulated, claiming to be from me. How insidious. You should make an effort to get your copy of PGP from a reliable source, whatever that means. Or perhaps from more than one independent source, and compare them with a file comparison utility. There are other ways to check PGP for tampering, using digital signatures. If someone you trust signs the executable version of PGP, vouching for the fact that it has not been infected or tampered with, you can be reasonably sure that you have a good copy. You could use an earlier trusted version of PGP to check the signature on a later suspect version of PGP. But this will not help at all if your operating system is infected, nor will it detect if your original copy of PGP.EXE has been maliciously altered in such a way as to compromise its own ability to check signatures. This test also assumes that you have a good trusted copy of the public key that you use to check the signature on the PGP executable. I recommend you not trust your copy of PGP unless it was originally distributed by MIT or ViaCrypt, or unless it comes with a digitally signed endorsement from me. Every new version comes with one or more digital signatures in the distribution package, signed by the originator of that release package. This is usually someone representing MIT or ViaCrypt, or whoever released that version. Check the signatures on the version that you get. I have actually seen several bogus versions of PGP distribution packages, even from apparantly reliable freeware distribution channels such as CD-ROM distributors and Compuserve. Always check the signature when you get a new version. Physical Security Breach ------------------------ A physical security breach may allow someone to physically acquire your plaintext files or printed messages. A determined opponent might accomplish this through burglary, trash-picking, unreasonable search and seizure, or bribery, blackmail or infiltration of your staff. Some of these attacks may be especially feasible against grassroots political organizations that depend on a largely volunteer staff. It has been widely reported in the press that the FBI's COINTELPRO program used burglary, infiltration, and illegal bugging against antiwar and civil rights groups. And look what happened at the Watergate Hotel. Don't be lulled into a false sense of security just because you have a cryptographic tool. Cryptographic techniques protect data only while it's encrypted-- direct physical security violations can still compromise plaintext data or written or spoken information. This kind of attack is cheaper than cryptanalytic attacks on PGP. Tempest Attacks --------------- Another kind of attack that has been used by well-equipped opponents involves the remote detection of the electromagnetic signals from your computer. This expensive and somewhat labor-intensive attack is probably still cheaper than direct cryptanalytic attacks. An appropriately instrumented van can park near your office and remotely pick up all of your keystrokes and messages displayed on your computer video screen. This would compromise all of your passwords, messages, etc. This attack can be thwarted by properly shielding all of your computer equipment and network cabling so that it does not emit these signals. This shielding technology is known as "Tempest", and is used by some Government agencies and defense contractors. There are hardware vendors who supply Tempest shielding commercially, although it may be subject to some kind of Government licensing. Now why do you suppose the Government would restrict access to Tempest shielding? Exposure on Multi-user Systems ------------------------------ PGP was originally designed for a single-user MSDOS machine under your direct physical control. I run PGP at home on my own PC, and unless someone breaks into my house or monitors my electromagnetic emissions, they probably can't see my plaintext files or secret keys. But now PGP also runs on multi-user systems such as Unix and VAX/VMS. On multi-user systems, there are much greater risks of your plaintext or keys or passwords being exposed. The Unix system administrator or a clever intruder can read your plaintext files, or perhaps even use special software to covertly monitor your keystrokes or read what's on your screen. On a Unix system, any other user can read your environment information remotely by simply using the Unix "ps" command. Similar problems exist for MSDOS machines connected on a local area network. The actual security risk is dependent on your particular situation. Some multi-user systems may be safe because all the users are trusted, or because they have system security measures that are safe enough to withstand the attacks available to the intruders, or because there just aren't any sufficiently interested intruders. Some Unix systems are safe because they are only used by one user-- there are even some notebook computers running Unix. It would be unreasonable to simply exclude PGP from running on all Unix systems. PGP is not designed to protect your data while it is in plaintext form on a compromised system. Nor can it prevent an intruder from using sophisticated measures to read your secret key while it is being used. You will just have to recognize these risks on multi-user systems, and adjust your expectations and behavior accordingly. Perhaps your situation is such that you should consider running PGP only on an isolated single-user system under your direct physical control. That's what I do, and that's what I recommend. Traffic Analysis ---------------- Even if the attacker cannot read the contents of your encrypted messages, he may be able to infer at least some useful information by observing where the messages come from and where they are going, the size of the messages, and the time of day the messages are sent. This is analogous to the attacker looking at your long distance phone bill to see who you called and when and for how long, even though the actual content of your calls is unknown to the attacker. This is called traffic analysis. PGP alone does not protect against traffic analysis. Solving this problem would require specialized communication protocols designed to reduce exposure to traffic analysis in your communication environment, possibly with some cryptographic assistance. Protecting Against Bogus Timestamps ----------------------------------- A somewhat obscure vulnerability of PGP involves dishonest users creating bogus timestamps on their own public key certificates and signatures. You can skip over this section if you are a casual user and aren't deeply into obscure public key protocols. There's nothing to stop a dishonest user from altering the date and time setting of his own system's clock, and generating his own public key certificates and signatures that appear to have been created at a different time. He can make it appear that he signed something earlier or later than he actually did, or that his public/secret key pair was created earlier or later. This may have some legal or financial benefit to him, for example by creating some kind of loophole that might allow him to repudiate a signature. I think this problem of falsified timestamps in digital signatures is no worse than it is already in handwritten signatures. Anyone may write a date next to their handwritten signature on a contract with any date they choose, yet no one seems to be alarmed over this state of affairs. In some cases, an "incorrect" date on a handwritten signature might not be associated with actual fraud. The timestamp might be when the signator asserts that he signed a document, or maybe when he wants the signature to go into effect. In situations where it is critical that a signature be trusted to have the actual correct date, people can simply use notaries to witness and date a handwritten signature. The analog to this in digital signatures is to get a trusted third party to sign a signature certificate, applying a trusted timestamp. No exotic or overly formal protocols are needed for this. Witnessed signatures have long been recognized as a legitimate way of determining when a document was signed. A trustworthy Certifying Authority or notary could create notarized signatures with a trustworthy timestamp. This would not necessarily require a centralized authority. Perhaps any trusted introducer or disinterested party could serve this function, the same way real notary publics do now. When a notary signs other people's signatures, it creates a signature certificate of a signature certificate. This would serve as a witness to the signature the same way real notaries now witness handwritten signatures. The notary could enter the detached signature certificate (without the actual whole document that was signed) into a special log controlled by the notary. Anyone can read this log. The notary's signature would have a trusted timestamp, which might have greater credibility or more legal significance than the timestamp in the original signature. There is a good treatment of this topic in Denning's 1983 article in IEEE Computer (see references). Future enhancements to PGP might have features to easily manage notarized signatures of signatures, with trusted timestamps. Cryptanalysis ------------- An expensive and formidable cryptanalytic attack could possibly be mounted by someone with vast supercomputer resources, such as a Government intelligence agency. They might crack your RSA key by using some new secret factoring breakthrough. Perhaps so, but it is noteworthy that the US Government trusts the RSA algorithm enough in some cases to use it to protect its own nuclear weapons, according to Ron Rivest. And civilian academia has been intensively attacking it without success since 1978. Perhaps the Government has some classified methods of cracking the IDEA(tm) conventional encryption algorithm used in PGP. This is every cryptographer's worst nightmare. There can be no absolute security guarantees in practical cryptographic implementations. Still, some optimism seems justified. The IDEA algorithm's designers are among the best cryptographers in Europe. It has had extensive security analysis and peer review from some of the best cryptanalysts in the unclassified world. It appears to have some design advantages over the DES in withstanding differential and linear cryptanalysis, which have both been used to crack the DES. Besides, even if this algorithm has some subtle unknown weaknesses, PGP compresses the plaintext before encryption, which should greatly reduce those weaknesses. The computational workload to crack it is likely to be much more expensive than the value of the message. If your situation justifies worrying about very formidable attacks of this caliber, then perhaps you should contact a data security consultant for some customized data security approaches tailored to your special needs. Boulder Software Engineering, whose address and phone are given at the end of this document, can provide such services. In summary, without good cryptographic protection of your data communications, it may have been practically effortless and perhaps even routine for an opponent to intercept your messages, especially those sent through a modem or E-mail system. If you use PGP and follow reasonable precautions, the attacker will have to expend far more effort and expense to violate your privacy. If you protect yourself against the simplest attacks, and you feel confident that your privacy is not going to be violated by a determined and highly resourceful attacker, then you'll probably be safe using PGP. PGP gives you Pretty Good Privacy. Legal Issues ============ Trademarks, Copyrights, and Warranties -------------------------------------- "PGP", "Pretty Good Privacy", "Phil's Pretty Good Software", and the "Pretty Good" label for computer software and hardware products are all trademarks of Philip R. Zimmermann. PGP is (c) Copyright Philip R. Zimmermann, 1990-1994. All rights reserved. The PGP User's Guide is also copyright Philip Zimmermann, 1990-1994. All rights reserved. These rights include but are not limited to any foreign language translations of the manual or the software, and all derivative works of both. MIT may have a copyright on the particular software distribution package that they distribute from the MIT FTP site. This copyright on the "compilation" of the distribution package in no way implies that MIT has a copyright on PGP itself, or its user documentation. The author assumes no liability for damages resulting from the use of this software, even if the damage results from defects in this software, and makes no representations concerning the merchantability of this software or its suitability for any specific purpose. It is provided "as is" without express or implied warranty of any kind. Because certain actions may delete files or render them unrecoverable, the author assumes no responsibility for the loss or modification of any data. Patent Rights on the Algorithms ------------------------------- The RSA public key cryptosystem was developed at MIT, which holds a patent on it (U.S. patent #4,405,829, issued 20 Sep 1983). A company in California called Public Key Partners (PKP) holds the exclusive commercial license to sell and sub-license the RSA public key cryptosystem. MIT distributes a freeware version of PGP under the terms of the RSAREF license from RSA Data Security, Inc. (RSADSI). At the time of this writing (September 1994), it appears that PKP may be breaking up soon, in which case the patents they hold may fall into other hands. The RSA patent may end up with RSADSI. Non-US users of earlier versions of PGP should note that the RSA patent does not apply outside the US, and at least at the time of this writing, the author is not aware of any RSA patent in any other country. Federal agencies may use the RSA algorithm, because the Government paid for the development of RSA with grants from the National Science Foundation and the Navy. But despite the fact of Government users having free access to the RSA algorithm, Government use of PGP has additional restrictions imposed by the agreement I have with ViaCrypt, as explained later. I wrote my PGP software from scratch, with my own independently developed implementation of the RSA algorithm. Before publishing PGP in 1991, I got a formal written legal opinion from a patent attorney with extensive experience in software patents. I'm convinced that publishing PGP the way I did does not violate patent law. Not only did PKP acquire the exclusive patent rights for the RSA cryptosystem, but they also acquired the exclusive rights to three other patents covering other public key schemes invented by others at Stanford University, also developed with federal funding. This one company claims to have a legal lock in the USA on nearly all practical public key cryptosystems. They even appear to be claiming patent rights on the very concept of public key cryptography, regardless of what clever new original algorithms are independently invented by others. I find such a comprehensive monopoly troubling, because I think public key cryptography is destined to become a crucial technology in the protection of our civil liberties and privacy in our increasingly connected society. At the very least, it places these vital tools at risk by affording to the Government a single pressure point of influence. Beginning with PGP version 2.5 (distributed by MIT, the holders of the original RSA patent), the freeware version of PGP uses the RSAREF subroutine library to perform its RSA calculations, under the RSAREF license, which allows noncommercial use in the USA. RSAREF is a subroutine package from RSA Data Security Inc, that implements the RSA algorithm. The RSAREF subroutines are used instead of PGP's original subroutines to implement the RSA functions in PGP. See the RSAREF license for terms and conditions of use of RSAREF applications. PGP 2.5 was released by MIT for a brief test period in May, 1994 before releasing 2.6. PGP 2.5 was released under the 16 March, 1994 RSAREF license, which is a perpetual license, so it may legally be used forever in the US. But it would be better for PGP's legal and political future for users in the United States to upgrade to version 2.6 or later to facilitate the demise of PGP 2.3a and earlier versions. Also, PGP 2.5 has bugs that are corrected in 2.6, and 2.5 will not read the new data format after September 1, 1994. (See the section on Compatibility with Previous and Future Versions of PGP.) The PGP 2.0 release was a joint effort of an international team of software engineers, implementing enhancements to the original PGP with design guidance from me. It was released by Branko Lankester in The Netherlands and Peter Gutmann in New Zealand, out of reach of US patent law. Although released only in Europe and New Zealand, it spontaneously spread to the USA without help from me or the PGP development team. The IDEA(tm) conventional block cipher used by PGP is covered by a patent in Europe, held by ETH and a Swiss company called Ascom-Tech AG. The US Patent number is 5,214,703, and the European patent number is EP 0 482 154 B1. IDEA(tm) is a trademark of Ascom-Tech AG. There is no license fee required for noncommercial use of IDEA. Commercial users of IDEA may obtain licensing details from Dieter Profos, Ascom Tech AG, Teleservices Section, Postfach 151, 4502 Solothurn, Switzerland, Tel +41 65 242885, Fax +41 65 235761. Ascom-Tech AG has granted permission for the freeware version PGP to use the IDEA cipher in non-commercial uses, everywhere. In the US and Canada, all commercial or Government users must obtain a licensed version from ViaCrypt, who has a license from Ascom-Tech for the IDEA cipher. Ascom-Tech has recently been changing its policies regarding the use of IDEA in PGP for commercial use outside the US, and that policy still seems to be in flux. They tell me that their current thinking is as follows: They will allow commercial users of PGP outside the US or Canada to use IDEA in PGP without paying royalties to Ascom-Tech, because it is not currently possible for commercial users to buy a licensed version of PGP outside the US or Canada. If the legal situation in the USA changes in the future, so that users outside the US or Canada can buy a licensed version of PGP (either from ViaCrypt, or from me, or from a foreign enterprise licensed by me), then Ascom-Tech will begin enforcing its patent licensing policies on commercial users who are in a position to buy a licensed version of PGP. To get a more up-to-date report on this, contact Ascom-Tech AG. The ZIP compression routines in PGP come from freeware source code, with the author's permission. I'm not aware of any patents on the compression algorithms used in the ZIP routines. Freeware Status and Restrictions -------------------------------- PGP is not shareware, it's freeware. Published as a community service. Giving PGP away for free will encourage far more people to use it, which will have a greater social impact. Feel free to disseminate the complete unmodified PGP release package as widely as possible, but be careful not to violate U.S. export controls if you live in the USA. Give it to all your friends. If you have access to any electronic Bulletin Board Systems, please upload the complete PGP executable object release package to as many BBS's as possible. You may also disseminate the source code release package. PGP's source code is published to assist public scrutiny of PGP to show that it has no hidden weaknesses or back doors, and to help people to find bugs and report them. Recompile it and port it to new target machines. Experiment with the code and learn from it. I place no restraints on your modifying the source code for your own use. However, do not distribute a modified version of PGP under the name "PGP" without first getting permission from me. Please respect this restriction. PGP's reputation for cryptographic integrity depends on maintaining strict quality control on PGP's cryptographic algorithms and protocols. Beyond that, ad hoc "improvements" to PGP can affect interoperability, which creates user confusion and compatability problems that could damage PGP's (and my own) reputation and undermine the good will earned by the PGP trademark. This has already started to happen, which is why I'm making a point of it here. This creates technical support headaches, and I get phone calls from confused users who run into problems either because they have a mutant strain of PGP, or are trying to process a key, signature, or message that came from an incompatible mutant strain of PGP. The source code to PGP was not published to help spawn these mutant strains. If you want to distribute a modified version of PGP, or use a modified version to send messages to other people, you should name the program in such a way that no one could mistake it for PGP. The messages, signatures, and keys it produces must also be labeled in such a way that no one could mistake them for material produced by PGP. If you feel you must modify your copy of PGP, and there is any chance that the modified version could escape into the environment, please contact me first to discuss some easy methods for how to prevent people from confusing your version with the standard PGP. Perhaps we'll even decide that your changes are appropriate for incorporating into the standard PGP release. Also, you should note that official executable versions of PGP are always released signed by the PGP developers, so you can verify their authenticity. If you find a corrupted copy of PGP, or notice one being distributed, please contact the people doing the distribution and suggest that they replace this with an authentic version. Some older versions of PGP were published under the terms of the General Public License (GPL), a license designed by the Free Software Foundation to protect the status of free software. Newer freeware versions of PGP are no longer published under the GPL. The RSAREF licensing terms are more stringent than those of the GPL. But even if a version of PGP is published without RSAREF, in a situation or place where the RSA patent does not apply, I still do not want the GPL to apply to PGP, for a variety of reasons, not the least of which is because the GPL is not optimal for protecting PGP from being republished with ad-hoc "improvements". Outside the United States, the RSA patent is not in force, so PGP users there are free to use implementations of PGP that do not rely on RSAREF and its restrictions. Canadians may use PGP without using RSAREF, and there are legal ways to export PGP to Canada. In Canada, where RSAREF is not needed, it is easy to modify and recompile the current PGP source code to perform the RSA calculations without using the RSAREF library, just as it was done in PGP 2.3a. In such a case, this modified PGP may be re-released under the identical licensing terms as the current official freeware PGP release, but without the RSAREF-specific restrictions. It may not be re-released under the GPL, as certain older versions were. And this manual must accompany it. That modified version of PGP may not be used in environments where RSAREF would be needed. Restrictions on Commercial Use of PGP ------------------------------------- The freeware version of PGP is for personal, non-commercial use. For commercial use in the USA or Canada, contact ViaCrypt in Phoenix, Arizona (phone 602 944-0773, or email viacrypt@acm.org). I made an agreement with ViaCrypt in the summer of 1993 to license the exclusive commercial rights to PGP, so that there would be a way for corporations to use PGP without risk of a patent infringement lawsuit from PKP. For PGP to succeed in the long term as a viable industry standard, the legal stigma associated with the RSA patent rights had to be resolved. ViaCrypt had already obtained a patent license from PKP to make, use, and sell products that practice the RSA patents. ViaCrypt offered a way out of the patent quagmire for PGP to penetrate the corporate environment. They could sell a fully-licensed version of PGP, but only if I licensed it to them under these terms. So we entered into an agreement to do that, opening the door for PGP's future in the commercial sector, which was necessary for PGP's long-term political future. Therefore, regardless of the complexities and partially overlapping restrictions from all the other terms and conditions imposed by the various patent and copyright licenses (RSA, RSAREF, and IDEA) from various third parties, an additional overriding restriction on PGP usage is imposed by my own agreement with ViaCrypt: The freeware version of PGP is only for personal, non-commercial use -- all other users in the USA and Canada must obtain a fully licensed version of PGP from ViaCrypt. The restrictions imposed by my agreement with ViaCrypt do not apply outside the USA or Canada. Finally, if you want to turn PGP into a commercial product and make money selling it, then we must agree on a way for me to also make money on it. If you use PGP in such a manner that you must pay patent royalties or any other software licensing fees to the patent holders for any cryptographic algorithms used by PGP, then we must agree on a way for me to also be paid in some manner. Buying PGP from ViaCrypt is one way to meet this requirement. Other Licensing Restrictions ---------------------------- Under no circumstances may PGP be distributed without the PGP documentation, including this PGP User's Guide. And, assuming this is an RSAREF version of PGP, the RSAREF license agreement must be kept with it. You must also keep the copyright, patent, and trademark notices on PGP and its documentation. The standard freeware PGP release is primarily distributed in electronic form, as a single compressed archive file, containing a collection of files in a "shrink-wrapped" package. This package should not be broken up and the components separately distributed -- in the interests of quality control, we want to make it difficult for users to obtain PGP without getting the full release package. Distribution ------------ In the USA, PGP is available for free from the Massachusetts Institute of Technology, under the restrictions described above. The primary release site for PGP is the Massachusetts Institute of Technology, at their FTP site "net-dist.mit.edu", in the /pub/PGP directory. You may obtain free copies or updates to PGP from this site, or any other Internet FTP site or BBS that PGP has spread to. Don't ask me for a copy directly from me, especially if you live outside the US or Canada. I recommend that you not use any modified version of PGP that comes from any other source, other than MIT, ViaCrypt, or me, unless it is accompanied by a signed endorsement from me personally. You can get the official release software from many other distribution sites "downstream" from MIT. Hopefully, all these other sites are adhering to US export controls. The PGP version 2.6.2 executable object release package for MSDOS contains the PGP executable software, documentation, RSAREF license, sample key rings including my own public key, and signatures for the software and this manual, all in one PKZIP compressed file called pgp262.zip. The PGP source release package for MSDOS contains all the C source files in one PKZIP compressed file called pgp262s.zip. The filename for the release package is derived from the version number of the release. Export Controls --------------- The U.S. Government has made it illegal in most cases to export good cryptographic technology, and that may include PGP. They regard this kind of software just like they regard munitions. This is determined not by legislation, but by administrative policies of the State Department, Defense Department and Commerce Department. The U.S. Government is using export restrictions as a means of suppressing both domestic and foreign availability of cryptographic technology. In particular, it is trying to suppress the emergence of an international standard for cryptographic protocols, until it can establish the Escrowed Encryption Standard (the Clipper chip) as the dominant standard. Any export restrictions on PGP are imposed by the US Government. This does not imply that I or MIT agree with these restrictions. We just comply with them. We do not impose additional licensing restrictions of our own on the use of PGP outside of the US, other than those restrictions that already apply inside the US. PGP may be subject to export controls. Anyone wishing to export it should first consult the State Department's Office of Defense Trade Controls. I will not export this software out of the US or Canada in cases when it is illegal to do so under US controls, and I urge other people not to export it on their own. If you live outside the US or Canada, I urge you not to violate US export laws by getting any version of PGP in a way that violates those laws. Since thousands of domestic users got the first version after its initial publication, it somehow leaked out of the US and spread itself widely abroad, like dandelion seeds blowing in the wind. Starting with PGP version 2.0 through version 2.3a, the release point of the software has been outside the US, on publicly-accessible computers in Europe. Each release was electronically sent back into the US and posted on publicly-accessible computers in the US by PGP privacy activists in foreign countries. There are some restrictions in the US regarding the import of munitions, but I'm not aware of any cases where this was ever enforced for importing cryptographic software into the US. I imagine that a legal action of that type would be quite a spectacle of controversy. ViaCrypt PGP is sold in the United States and Canada and is not for export. The following language was supplied by the US Government to ViaCrypt for inclusion in the ViaCrypt PGP documentation: "PGP is export restricted by the Office of Export Administration, United States Department of Commerce and the Offices of Defense Trade Controls and Munitions Control, United States Department of State. PGP cannot be exported or reexported, directly or indirectly, (a) without all export or reexport licenses and governmental approvals required by any applicable laws, or (b) in violation of any prohibition against the export or reexport of any part of PGP." The Government may take the position that the freeware PGP versions are also subject to those controls. The freeware PGP versions 2.5 and 2.6 were released through a posting on a controlled FTP site maintained by MIT. This site has restrictions and limitations which have been used on other FTP sites to comply with export control requirements with respect to other encryption software such as Kerberos and software from RSA Data Security, Inc. I urge you not to do anything which would weaken those controls or facilitate any improper export of PGP. Although PGP has become a worldwide de facto standard for E-mail encryption, and is widely available overseas, I still get calls from people outside the US who ask me if it is legal to use it in their own country, for versions that are already available there. Please don't contact me to ask me if it is legal to use PGP in your country if you live outside the US. That question is not up to me. I've got enough legal problems of my own with export control issues, without getting involved in giving you legal advice over my phone. It might even put me at some legal risk to simply answer a question like that for a foreigner. If this question concerns you, ask someone else, like a lawyer. You may have a need to use PGP in a commercial application outside the US or Canada. Unfortunately, at the time of this writing, there is no current commercial source for PGP outside the US or Canada. I am trying to find a US-legal way to make a commercially licensed version available abroad, but right now the US export restrictions make that difficult without putting me at legal risk. This situation may change. Some foreign governments impose serious penalties on anyone inside their country for merely using encrypted communications. In some countries they might even shoot you for that. But if you live in that kind of country, perhaps you need PGP even more. Philip Zimmermann's Legal Situation ----------------------------------- At the time of this writing, I am the target of a US Customs criminal investigation in the Northern District of California. A criminal investigation is not a civil lawsuit. Civil lawsuits do not involve prison terms. My defense attorney has been told by the Assistant US Attorney that the area of law of interest to the investigation has to do with the export controls on encryption software. The federal mandatory sentencing guidelines for this offense are 41 to 51 months in a federal prison. US Customs appears to be taking the position that electronic domestic publication of encryption software is the same as exporting it. The prosecutor has issued a number of federal grand jury subpoenas. It may be months before a decision is reached on whether to seek indictment. This situation may change at any time, so this description may be out of date by the time you read it. Watch the news for further developments. If I am indicted and this goes to trial, it will be a major test case. I have a legal defense fund set up for this case. So far, no other organization is doing the fundraising for me, so I am depending on people like you to contribute directly to this cause. If you care about the future of your civil liberties in the information age, then perhaps you will care about this case. The legal fees are expensive, the meter is running, and I need your help. The fund is run by my lead defense attorney, Phil Dubois, here in Boulder. Please send your contributions to: Philip L. Dubois, Lawyer 2305 Broadway Boulder, Colorado 80304 USA Phone (303) 444-3885 E-mail: dubois@csn.org You can also phone in your donation and put it on Mastercard or Visa. If you want to be really cool, you can use Internet E-mail to send in your contribution, encrypting your message with PGP so that no one can intercept your credit card number. Include in your E-mail message your Mastercard or Visa number, expiration date, name on the card, and amount of donation. Then sign it with your own key and encrypt it with Phil Dubois's public key (his key is included in the standard PGP distribution package, in the "keys.asc" file). Put a note on the subject line that this is a donation to my legal defense fund, so that Mr. Dubois will decrypt it promptly. Please don't send a lot of casual encrypted E-mail to him -- I'd rather he use his valuable time to work on my case. If you want to read some press stories to find out why this is an important case, see the following references: 1) William Bulkeley, "Cipher Probe", Wall Street Journal, Thursday 28 April 1994, front page. 2) John Cary, "Spy vs. Computer Nerd: The Fight Over Data Security", Business Week, 4 Oct 1993, page 43. 3) Jon Erickson, "Cryptography Fires Up the Feds", Dr. Dobb's Journal, December 1993, page 6. 4) John Markoff, "Federal Inquiry on Software Examines Privacy Programs", New York Times, Tuesday 21 Sep 1993, page C1. 5) Kurt Kleiner, "Punks and Privacy", Mother Jones Magazine, Jan/Feb 1994, page 17. 6) Steven Levy, "Battle of the Clipper Chip", New York Times Magazine, Sunday 12 Jun 1994, page 44. 7) Steven Levy, "Crypto Rebels", WIRED, May/Jun 1993, page 54. 8) John Markoff, "Cyberspace Under Lock and Key", New York Times, Sunday 13 Feb 1994. 9) Philip Elmer-DeWitt, "Who Should Keep the Keys", Time, 14 Mar 1994, page 90. There are a great many other articles on PGP from around the world. I'm keeping a scrapbook. Other Sources of Information on PGP =================================== Where to Get a Commercial Version of PGP ---------------------------------------- To get a fully licensed version of PGP for use in the USA or Canada, contact: ViaCrypt 9033 North 24th Avenue, Suite 7 Phoenix, Arizona 85021 USA Phone: (602) 944-0773, or (800) 536-2664 Fax: (602) 943-2601 E-mail: viacrypt@acm.org ViaCrypt has a version of PGP for MSDOS, and a number of Unix platforms. They also have a Windows shell version, and other versions are under development, including Macintosh. If you have a need to use PGP in a commercial or Government setting, and ViaCrypt has a version of PGP for your hardware platform, you should get ViaCrypt PGP. ViaCrypt has obtained all the necessary licenses from PKP, Ascom-Tech AG, and Philip Zimmermann to sell PGP for use in commercial or government environments. ViaCrypt PGP is every bit as secure as the freeware PGP, and is entirely compatible in both directions with the freeware version of PGP. ViaCrypt PGP is the perfect way to get a fully licensed version of PGP into your corporate environment. If you work in a large company and you are a fan of PGP, I urge you to try to persuade your company to buy lots of copies of PGP from ViaCrypt. Not just because that will earn royalties for me. If ViaCrypt can make PGP a commercial success, it will go a long way toward cementing PGP's political future as an unstoppable standard for E-mail encryption in the corporate world. The corporate world is where the money is, and that affects public policy like nothing else. And that includes Government policy to suppress strong cryptography. Reporting PGP Bugs ------------------ Bugs in PGP should be reported via E-mail to MIT, the official distribution site of PGP. The E-mail address for bug reports is pgp-bugs@mit.edu. MIT will forward a copy of your bug report to me. When you report bugs, be sure to specify what machine and operating system you are using and what version of PGP you have, and provide enough detail to reproduce the problem. It would also be a good idea to find out if you have the latest version of PGP, in case the bug has already been fixed. Also, it's a good idea to make sure it really is a bug before you report it. RTFM. Fan Mail, Updates, and News --------------------------- After all this work I have to admit I wouldn't mind getting some fan mail for PGP, to gauge its popularity. Let me know what you think about it and how many of your friends use it. Bug reports and suggestions for enhancing PGP are welcome, too. Perhaps a future PGP release will reflect your suggestions. This project has not been funded and the project has nearly eaten me alive. This means you usually won't get a reply to your mail, unless you only need a short written reply and you include a stamped self-addressed envelope. But I often do reply to E-mail. Please keep it in English, as my foreign language skills are weak. If you call and I'm not in, it's best to just try again later. I usually don't return long distance phone calls, unless you leave a message that I can call you collect, and even then I might not return your call. If you need any significant amount of my time, I am available on a paid consulting basis, and I always return those calls. The most inconvenient mail I get is for some well-intentioned person to send me a few dollars asking me for a copy of PGP. I don't send it to them because I'd rather avoid any legal problems with PKP. Or worse, sometimes these requests are from foreign countries, and I would be risking a violation of US cryptographic export control laws. Even if there were no legal hassles involved in sending PGP to them, they usually don't send enough money to make it worth my time. I'm just not set up as a low cost low volume mail order business. I can't just ignore the request and keep the money, because they probably regard the money as a fee for me to fulfill their request. If I return the money, I might have to get in my car and drive down to the post office and buy some postage stamps, because these requests rarely include a stamped self-addressed envelope. And I have to take the time to write a polite reply that I can't do it. If I postpone the reply and set the letter down on my desk, it might be buried within minutes and won't see the light of day again for months. Multiply these minor inconveniences by the number of requests I get, and you can see the problem. Isn't it enough that the software is free? It would be nicer if people could try to get PGP from any of the myriad other sources. If you don't have a modem, ask a friend to get it for you. If you can't find it yourself, I don't mind answering a quick phone call. If anyone wants to volunteer to improve PGP, please let me know. It could certainly use some more work. Some features were deferred to get it out the door. A number of PGP users have since donated their time to port PGP to Unix on Sun SPARCstations, to Ultrix, to VAX/VMS, to OS/2, to the Amiga, and to the Atari ST. Perhaps you can help port it to some new environments. But please let me know if you plan to port or add enhancements to PGP, to avoid duplication of effort, and to avoid starting with an obsolete version of the source code. Because so many foreign language translations of PGP have been produced, most of them are not distributed with the regular PGP release package because it would require too much disk space. Separate language translation "kits" are available from a number of independent sources, and are sometimes available separately from the same distribution centers that carry the regular PGP release software. These kits include translated versions of the file LANGUAGE.TXT, PGP.HLP, and the PGP User's Guide. If you want to produce a translation for your own native language, contact me first to get the latest information and standard guidelines, and to find out if it's been translated to your language already. To find out where to get a foreign language kit for your language, you might check on the Internet newsgroups, or get it from Mike Johnson (mpj@csn.org). If you have access to the Internet, watch for announcements of new releases of PGP on the Internet newsgroups "sci.crypt" and PGP's own newsgroup, "alt.security.pgp". If you want to know where to get PGP, MIT is the primary FTP distribution site (net-dist.mit.edu). Or ask Mike Johnson (mpj@csn.org) for a list of Internet FTP sites and BBS phone numbers. Computer-Related Political Groups --------------------------------- PGP is a very political piece of software. It seems appropriate to mention here some computer-related activist groups. Full details on these groups, and how to join them, is provided in a separate document file in the PGP release package. The Electronic Privacy Information Center (EPIC) is a public interest research center in Washington, DC. It was established in 1994 to focus public attention on emerging privacy issues relating to the National Information Infrastructure, such as the Clipper Chip, the Digital Telephony proposal, medical record privacy, and the sale of consumer data. EPIC is sponsored by the Fund for Constitutional Government and Computer Professionals for Social Responsibility. EPIC publishes the EPIC Alert and EPIC Reports, pursues Freedom of Information Act litigation, and conducts policy research on emerging privacy issues. For more information email info@epic.org, or write EPIC, 666 Pennsylvania Ave., SE, Suite 301, Washington, DC 20003. +1 202 544 9240 (tel), +1 202 547 5482 (fax). The Electronic Frontier Foundation (EFF) was founded in 1990 to assure freedom of expression in digital media, with a particular emphasis on applying the principles embodied in the US Constitution and the Bill of Rights to computer-based communication. They can be reached in Washington DC, at (202) 347-5400. Internet E-mail address: eff@eff.org. Computer Professionals For Social Responsibility (CPSR) empowers computer professionals and computer users to advocate for the responsible use of information technology and empowers all who use computer technology to participate in public policy debates on the impacts of computers on society. They can be reached at: (415) 322-3778 in Palo Alto, E-mail address cpsr@csli.stanford.edu. The League for Programming Freedom (LPF) is a grass-roots organization of professors, students, businessmen, programmers and users dedicated to bringing back the freedom to write programs. They regard patents on computer algorithms as harmful to the US software industry (and so do I!). They can be reached at (617) 433-7071. E-mail address: lpf@uunet.uu.net. For more details on these groups, see the accompanying document in the PGP release package. Recommended Readings -------------------- Introductory Readings 1) Bruce Schneier, "Applied Cryptography: Protocols, Algorithms, and Source Code in C", John Wiley & Sons, 1993 (This book is a watershed work on the subject.) 2) Dorothy Denning, "Cryptography and Data Security", Addison-Wesley, Reading, MA 1982 3) Dorothy Denning, "Protecting Public Keys and Signature Keys", IEEE Computer, Feb 1983 4) Martin E. Hellman, "The Mathematics of Public-Key Cryptography," Scientific American, Aug 1979 5) Steven Levy, "Crypto Rebels", WIRED, May/Jun 1993, page 54. (A "must-read" article on PGP and other related topics.) 6) Steven Levy, "Battle of the Clipper Chip", New York Times Magazine, Sunday 12 Jun 1994, page 44. (Great article, great photos.) 7) William Bulkeley, "Cipher Probe", Wall Street Journal, 28 April 1994, front page. (An article on PGP and Zimmermann.) Other Readings 8) Ronald Rivest, "The MD5 Message Digest Algorithm", MIT Laboratory for Computer Science, 1991 9) Xuejia Lai, "On the Design and Security of Block Ciphers", ETH Series on Information Processing (Ed. J. L. Massey), Vol. 1, Hartung-Gorre Verlag, Konstanz, Switzerland, 1992 10) Philip Zimmermann, "A Proposed Standard Format for RSA Cryptosystems", Advances in Computer Security, Vol III, edited by Rein Turn, Artech House, 1988 11) Paul Wallich, "Electronic Envelopes", Scientific American, Feb 1993, page 30. (An article on PGP) 12) William Stallings, "Pretty Good Privacy", BYTE, July 1994, page 193 13) Philip Zimmermann, "The Official PGP User's Guide", MIT Press, 1994 (in press) 14) Philip Zimmermann, "PGP Source Code and Internals", MIT Press, 1994 (in press) To Contact the Author --------------------- Philip Zimmermann may be reached at: Boulder Software Engineering 3021 Eleventh Street Boulder, Colorado 80304 USA Internet: prz@acm.org Phone (303) 541-0140 (voice) (10:00am - 7:00pm Mountain Time) Fax available, if you arrange it via voice line. Appendix A: Where to Get PGP ============================= The following describes how to get the freeware public key cryptographic software PGP (Pretty Good Privacy) from an anonymous FTP site on Internet, or from other sources. PGP has become a worldwide de facto standard for E-mail encryption. PGP has sophisticated key management, an RSA/conventional hybrid encryption scheme, message digests for digital signatures, data compression before encryption, and good ergonomic design. PGP is well featured and fast, and has excellent user documentation. Source code is free. The Massachusetts Institute of Technology is the distributor of PGP version 2.6, for distribution in the USA only. It is available from "net-dist.mit.edu," a controlled FTP site that has restrictions and limitations, similar to those used by RSA Data Security, Inc., to comply with export control requirements. The software resides in the directory /pub/PGP. A reminder: Set mode to binary or image when doing an FTP transfer. And when doing a kermit download to your PC, specify 8-bit binary mode at both ends. There are two compressed archive files in the standard release, with the file name derived from the release version number. For PGP version 2.6.2, you must get pgp262.zip which contains the MSDOS binary executable and the PGP User's Guide, and you can optionally get pgp262s.zip which contains all the source code. These files can be decompressed with the MSDOS shareware archive decompression utility PKUNZIP.EXE, version 1.10 or later. For Unix users who lack an implementation of UNZIP, the source code can also be found in the compressed tar file pgp262s.tar.Z. If you don't have any local BBS phone numbers handy, here is a BBS you might try. The Catacombs BBS, operated by Mike Johnson in Longmont, Colorado, has PGP available for download by people in the US or Canada only. The BBS phone number is 303-772-1062. Mike Johnson's voice phone number is 303 772-1773, and his E-mail address is mpj@csn.org. Mike also has PGP available on an Internet FTP site for users in the US or Canada only; the site name is csn.org, in directory /mpj/, and you must read the README.MPJ file to get it. To get a fully licensed version of PGP for use in the USA or Canada, contact ViaCrypt in Phoenix, Arizona. Their phone number is 602-944-0773. ViaCrypt has obtained all the necessary licenses from PKP, Ascom-Tech AG, and Philip Zimmermann to sell PGP for use in commercial or Government environments. ViaCrypt PGP is every bit as secure as the freeware PGP, and is entirely compatible in both directions with the freeware version of PGP. ViaCrypt PGP is the perfect way to get a fully licensed version of PGP into your corporate or Government environment. Here are a few people and their E-mail addresses or phone numbers you can contact in some countries to get information on local PGP availability for versions earlier than 2.5: Peter Gutmann Hugh Kennedy pgut1@cs.aukuni.ac.nz 70042.710@compuserve.com New Zealand Germany Branko Lankester Miguel Angel Gallardo branko@hacktic.nl gallardo@batman.fi.upm.es +31 2159 42242 (341) 474 38 09 The Netherlands Spain Hugh Miller Colin Plumb hmiller@lucpul.it.luc.edu colin@nyx.cs.du.edu (312) 508-2727 Toronto, Ontario, Canada USA Jean-loup Gailly jloup@chorus.fr France mps, because these requests rarely include a stamped self-addressed envelodoc/pgpdoc1.txt1004440006630000000000024372705646601445010656 037777703401 1 0 Phil's Pretty Good Software Presents ======= PGP(tm) ======= Pretty Good(tm) Privacy Public Key Encryption for the Masses -------------------------- PGP(tm) User's Guide Volume I: Essential Topics -------------------------- by Philip Zimmermann Revised 11 October 94 PGP Version 2.6.2 - 11 Oct 94 Software by Philip Zimmermann, and many others. Synopsis: PGP(tm) uses public-key encryption to protect E-mail and data files. Communicate securely with people you've never met, with no secure channels needed for prior exchange of keys. PGP is well featured and fast, with sophisticated key management, digital signatures, data compression, and good ergonomic design. Software and documentation (c) Copyright 1990-1994 Philip Zimmermann. All rights reserved. For information on PGP licensing, distribution, copyrights, patents, trademarks, liability limitations, and export controls, see the "Legal Issues" section in the "PGP User's Guide, Volume II: Special Topics". Distributed by the Massachusetts Institute of Technology. "Whatever you do will be insignificant, but it is very important that you do it." --Mahatma Gandhi Contents ======== Quick Overview Why Do You Need PGP? How it Works Installing PGP How to Use PGP To See a Usage Summary Encrypting a Message Encrypting a Message to Multiple Recipients Signing a Message Signing and then Encrypting Using Just Conventional Encryption Decrypting and Checking Signatures Managing Keys RSA Key Generation Adding a Key to Your Key Ring Removing a Key or User ID from Your Key Ring Extracting (copying) a Key from Your Key Ring Viewing the Contents of Your Key Ring How to Protect Public Keys from Tampering How Does PGP Keep Track of Which Keys are Valid? How to Protect Secret Keys from Disclosure Revoking a Public Key What If You Lose Your Secret Key? Advanced Topics Sending Ciphertext Through E-mail Channels: Radix-64 Format Environmental Variable for Path Name Setting Parameters in the PGP Configuration File Vulnerabilities Beware of Snake Oil Notice to Macintosh Users PGP Quick Reference Legal Issues Acknowledgments About the Author Quick Overview ============== Pretty Good(tm) Privacy (PGP), from Phil's Pretty Good Software, is a high security cryptographic software application for MSDOS, Unix, VAX/VMS, and other computers. PGP allows people to exchange files or messages with privacy, authentication, and convenience. Privacy means that only those intended to receive a message can read it. Authentication means that messages that appear to be from a particular person can only have originated from that person. Convenience means that privacy and authentication are provided without the hassles of managing keys associated with conventional cryptographic software. No secure channels are needed to exchange keys between users, which makes PGP much easier to use. This is because PGP is based on a powerful new technology called "public key" cryptography. PGP combines the convenience of the Rivest-Shamir-Adleman (RSA) public key cryptosystem with the speed of conventional cryptography, message digests for digital signatures, data compression before encryption, good ergonomic design, and sophisticated key management. And PGP performs the public-key functions faster than most other software implementations. PGP is public key cryptography for the masses. PGP does not provide any built-in modem communications capability. You must use a separate software product for that. This document, "Volume I: Essential Topics", only explains the essential concepts for using PGP, and should be read by all PGP users. "Volume II: Special Topics" covers the advanced features of PGP and other special topics, and may be read by more serious PGP users. Neither volume explains the underlying technology details of cryptographic algorithms and data structures. Why Do You Need PGP? ==================== It's personal. It's private. And it's no one's business but yours. You may be planning a political campaign, discussing your taxes, or having an illicit affair. Or you may be doing something that you feel shouldn't be illegal, but is. Whatever it is, you don't want your private electronic mail (E-mail) or confidential documents read by anyone else. There's nothing wrong with asserting your privacy. Privacy is as apple-pie as the Constitution. Perhaps you think your E-mail is legitimate enough that encryption is unwarranted. If you really are a law-abiding citizen with nothing to hide, then why don't you always send your paper mail on postcards? Why not submit to drug testing on demand? Why require a warrant for police searches of your house? Are you trying to hide something? You must be a subversive or a drug dealer if you hide your mail inside envelopes. Or maybe a paranoid nut. Do law-abiding citizens have any need to encrypt their E-mail? What if everyone believed that law-abiding citizens should use postcards for their mail? If some brave soul tried to assert his privacy by using an envelope for his mail, it would draw suspicion. Perhaps the authorities would open his mail to see what he's hiding. Fortunately, we don't live in that kind of world, because everyone protects most of their mail with envelopes. So no one draws suspicion by asserting their privacy with an envelope. There's safety in numbers. Analogously, it would be nice if everyone routinely used encryption for all their E-mail, innocent or not, so that no one drew suspicion by asserting their E-mail privacy with encryption. Think of it as a form of solidarity. Today, if the Government wants to violate the privacy of ordinary citizens, it has to expend a certain amount of expense and labor to intercept and steam open and read paper mail, and listen to and possibly transcribe spoken telephone conversation. This kind of labor-intensive monitoring is not practical on a large scale. This is only done in important cases when it seems worthwhile. More and more of our private communications are being routed through electronic channels. Electronic mail is gradually replacing conventional paper mail. E-mail messages are just too easy to intercept and scan for interesting keywords. This can be done easily, routinely, automatically, and undetectably on a grand scale. International cablegrams are already scanned this way on a large scale by the NSA. We are moving toward a future when the nation will be crisscrossed with high capacity fiber optic data networks linking together all our increasingly ubiquitous personal computers. E-mail will be the norm for everyone, not the novelty it is today. The Government will protect our E-mail with Government-designed encryption protocols. Probably most people will acquiesce to that. But perhaps some people will prefer their own protective measures. Senate Bill 266, a 1991 omnibus anti-crime bill, had an unsettling measure buried in it. If this non-binding resolution had become real law, it would have forced manufacturers of secure communications equipment to insert special "trap doors" in their products, so that the Government can read anyone's encrypted messages. It reads: "It is the sense of Congress that providers of electronic communications services and manufacturers of electronic communications service equipment shall insure that communications systems permit the Government to obtain the plain text contents of voice, data, and other communications when appropriately authorized by law." This measure was defeated after rigorous protest from civil libertarians and industry groups. In 1992, the FBI Digital Telephony wiretap proposal was introduced to Congress. It would require all manufacturers of communications equipment to build in special remote wiretap ports that would enable the FBI to remotely wiretap all forms of electronic communication from FBI offices. Although it never attracted any sponsors in Congress in 1992 because of citizen opposition, it was reintroduced in 1994. Most alarming of all is the White House's bold new encryption policy initiative, under development at NSA since the start of the Bush administration, and unveiled April 16th, 1993. The centerpiece of this initiative is a Government-built encryption device, called the "Clipper" chip, containing a new classified NSA encryption algorithm. The Government is encouraging private industry to design it into all their secure communication products, like secure phones, secure FAX, etc. AT&T is now putting the Clipper into their secure voice products. The catch: At the time of manufacture, each Clipper chip will be loaded with its own unique key, and the Government gets to keep a copy, placed in escrow. Not to worry, though-- the Government promises that they will use these keys to read your traffic only when duly authorized by law. Of course, to make Clipper completely effective, the next logical step would be to outlaw other forms of cryptography. If privacy is outlawed, only outlaws will have privacy. Intelligence agencies have access to good cryptographic technology. So do the big arms and drug traffickers. So do defense contractors, oil companies, and other corporate giants. But ordinary people and grassroots political organizations mostly have not had access to affordable "military grade" public-key cryptographic technology. Until now. PGP empowers people to take their privacy into their own hands. There's a growing social need for it. That's why I wrote it. How it Works ============ It would help if you were already familiar with the concept of cryptography in general and public key cryptography in particular. Nonetheless, here are a few introductory remarks about public key cryptography. First, some elementary terminology. Suppose I want to send you a message, but I don't want anyone but you to be able to read it. I can "encrypt", or "encipher" the message, which means I scramble it up in a hopelessly complicated way, rendering it unreadable to anyone except you, the intended recipient of the message. I supply a cryptographic "key" to encrypt the message, and you have to use the same key to decipher or "decrypt" it. At least that's how it works in conventional "single-key" cryptosystems. In conventional cryptosystems, such as the US Federal Data Encryption Standard (DES), a single key is used for both encryption and decryption. This means that a key must be initially transmitted via secure channels so that both parties can know it before encrypted messages can be sent over insecure channels. This may be inconvenient. If you have a secure channel for exchanging keys, then why do you need cryptography in the first place? In public key cryptosystems, everyone has two related complementary keys, a publicly revealed key and a secret key (also frequently called a private key). Each key unlocks the code that the other key makes. Knowing the public key does not help you deduce the corresponding secret key. The public key can be published and widely disseminated across a communications network. This protocol provides privacy without the need for the same kind of secure channels that a conventional cryptosystem requires. Anyone can use a recipient's public key to encrypt a message to that person, and that recipient uses her own corresponding secret key to decrypt that message. No one but the recipient can decrypt it, because no one else has access to that secret key. Not even the person who encrypted the message can decrypt it. Message authentication is also provided. The sender's own secret key can be used to encrypt a message, thereby "signing" it. This creates a digital signature of a message, which the recipient (or anyone else) can check by using the sender's public key to decrypt it. This proves that the sender was the true originator of the message, and that the message has not been subsequently altered by anyone else, because the sender alone possesses the secret key that made that signature. Forgery of a signed message is infeasible, and the sender cannot later disavow his signature. These two processes can be combined to provide both privacy and authentication by first signing a message with your own secret key, then encrypting the signed message with the recipient's public key. The recipient reverses these steps by first decrypting the message with her own secret key, then checking the enclosed signature with your public key. These steps are done automatically by the recipient's software. Because the public key encryption algorithm is much slower than conventional single-key encryption, encryption is better accomplished by using a high-quality fast conventional single-key encryption algorithm to encipher the message. This original unenciphered message is called "plaintext". In a process invisible to the user, a temporary random key, created just for this one "session", is used to conventionally encipher the plaintext file. Then the recipient's public key is used to encipher this temporary random conventional key. This public-key-enciphered conventional "session" key is sent along with the enciphered text (called "ciphertext") to the recipient. The recipient uses her own secret key to recover this temporary session key, and then uses that key to run the fast conventional single-key algorithm to decipher the large ciphertext message. Public keys are kept in individual "key certificates" that include the key owner's user ID (which is that person's name), a timestamp of when the key pair was generated, and the actual key material. Public key certificates contain the public key material, while secret key certificates contain the secret key material. Each secret key is also encrypted with its own password, in case it gets stolen. A key file, or "key ring" contains one or more of these key certificates. Public key rings contain public key certificates, and secret key rings contain secret key certificates. The keys are also internally referenced by a "key ID", which is an "abbreviation" of the public key (the least significant 64 bits of the large public key). When this key ID is displayed, only the lower 32 bits are shown for further brevity. While many keys may share the same user ID, for all practical purposes no two keys share the same key ID. PGP uses "message digests" to form signatures. A message digest is a 128-bit cryptographically strong one-way hash function of the message. It is somewhat analogous to a "checksum" or CRC error checking code, in that it compactly "represents" the message and is used to detect changes in the message. Unlike a CRC, however, it is computationally infeasible for an attacker to devise a substitute message that would produce an identical message digest. The message digest gets encrypted by the secret key to form a signature. Documents are signed by prefixing them with signature certificates, which contain the key ID of the key that was used to sign it, a secret-key-signed message digest of the document, and a timestamp of when the signature was made. The key ID is used by the receiver to look up the sender's public key to check the signature. The receiver's software automatically looks up the sender's public key and user ID in the receiver's public key ring. Encrypted files are prefixed by the key ID of the public key used to encrypt them. The receiver uses this key ID message prefix to look up the secret key needed to decrypt the message. The receiver's software automatically looks up the necessary secret decryption key in the receiver's secret key ring. These two types of key rings are the principal method of storing and managing public and secret keys. Rather than keep individual keys in separate key files, they are collected in key rings to facilitate the automatic lookup of keys either by key ID or by user ID. Each user keeps his own pair of key rings. An individual public key is temporarily kept in a separate file long enough to send to your friend who will then add it to her key ring. Installing PGP ============== The MSDOS PGP release package comes in a compressed archive file with a file named in this form: PGPxx.ZIP (each release version has a different number for the "xx" in the filename). For example, the release package for version 2.6 is called PGP26.ZIP. The archive can be decompressed with the MSDOS shareware decompression utility PKUNZIP, or the Unix utility "unzip". When the PGP release package is decompressed, several files emerge from it. One such file, called README.DOC, should always be read before installing PGP. This file contains late-breaking news on what's new in this release of PGP, as well as information on what's in all the other files included in the release. If you already have an earlier version of PGP, you should rename it or delete it, to avoid name conflicts with the new PGP. For full details on how to install PGP, see the separate PGP Installation Guide, in the file SETUP.DOC included with this release package. It fully describes how to set up the PGP directory and your AUTOEXEC.BAT file and how to use PKUNZIP to install it. We will just briefly summarize the installation instructions here, in case you are too impatient to read the more detailed installation manual right now. To install PGP on your MSDOS system, you have to copy the compressed archive PGPxx.ZIP file into a suitable directory on your hard disk (like C:\PGP), and decompress it with PKUNZIP. For best results, you should also modify your AUTOEXEC.BAT file, as described elsewhere in this manual, but you can do that later, after you've played with PGP a bit and read more of this manual. If you haven't run PGP before, the first step after installation (and reading this manual) is to make a pair of keys for yourself by running the PGP key generation command "pgp -kg". Read the "RSA Key Generation" section of the manual first. Installing on Unix and VAX/VMS is generally similar to installing on MSDOS, but you may have to compile the source code first. A Unix makefile is provided with the source release for this purpose. How to Use PGP ============== To See a Usage Summary ---------------------- To see a quick command usage summary for PGP, just type: pgp -h Encrypting a Message -------------------- To encrypt a plaintext file with the recipient's public key, type: pgp -e textfile her_userid This command produces a ciphertext file called textfile.pgp. A specific example is: pgp -e letter.txt Alice or: pgp -e letter.txt "Alice S" The first example searches your public key ring file "pubring.pgp" for any public key certificates that contain the string "Alice" anywhere in the user ID field. The second example would find any user IDs that contain "Alice S". You can't use spaces in the string on the command line unless you enclose the whole string in quotes. The search is not case-sensitive. If it finds a matching public key, it uses it to encrypt the plaintext file "letter.txt", producing a ciphertext file called "letter.pgp". PGP attempts to compress the plaintext before encrypting it, thereby greatly enhancing resistance to cryptanalysis. Thus the ciphertext file will likely be smaller than the plaintext file. If you want to send this encrypted message through E-mail channels, convert it into printable ASCII "radix-64" format by adding the -a option, as described later. Encrypting a Message to Multiple Recipients ------------------------------------------- If you want to send the same message to more than one person, you may specify encryption for several recipients, any of whom may decrypt the same ciphertext file. To specify multiple recipients, just add more user IDs to the command line, like so: pgp -e letter.txt Alice Bob Carol This would create a ciphertext file called letter.pgp that could be decrypted by Alice or Bob or Carol. Any number of recipients may be specified. Signing a Message ----------------- To sign a plaintext file with your secret key, type: pgp -s textfile [-u your_userid] Note that [brackets] denote an optional field, so don't actually type real brackets. This command produces a signed file called textfile.pgp. A specific example is: pgp -s letter.txt -u Bob This searches your secret key ring file "secring.pgp" for any secret key certificates that contain the string "Bob" anywhere in the user ID field. Your name is Bob, isn't it? The search is not case-sensitive. If it finds a matching secret key, it uses it to sign the plaintext file "letter.txt", producing a signature file called "letter.pgp". If you leave off the user ID field, the first key on your secret key ring is used as the default secret key for your signature. PGP attempts to compress the message after signing it. Thus the signed file will likely be smaller than the original file, which is useful for archival applications. However, this renders the file unreadable to the casual human observer, even if the original message was ordinary ASCII text. It would be nice if you could make a signed file that was still directly readable to a human. This would be particularly useful if you want to send a signed message as E-mail. For signing E-mail messages, where you most likely do want the result to be human-readable, it is probably most convenient to use the CLEARSIG feature, explained later. This allows the signature to be applied in printable form at the end of the text, and also disables compression of the text. This means the text is still human-readable by the recipient even if the recipient doesn't use PGP to check the signature. This is explained in detail in the section entitled "CLEARSIG - Enable Signed Messages to be Encapsulated as Clear Text", in the Special Topics volume. If you can't wait to read that section of the manual, you can see how an E-mail message signed this way would look, with this example: pgp -sta message.txt This would create a signed message in file "message.asc", comprised of the original text, still human-readable, appended with a printable ASCII signature certificate, ready to send through an E-mail system. This example assumes that you are using the normal settings for enabling the CLEARSIG flag in the config file. Signing and then Encrypting --------------------------- To sign a plaintext file with your secret key, and then encrypt it with the recipient's public key: pgp -es textfile her_userid [-u your_userid] Note that [brackets] denote an optional field, so don't actually type real brackets. This example produces a nested ciphertext file called textfile.pgp. Your secret key to create the signature is automatically looked up in your secret key ring via your_userid. Her public encryption key is automatically looked up in your public key ring via her_userid. If you leave off her user ID field from the command line, you will be prompted for it. If you leave off your own user ID field, the first key on your secret key ring is be used as the default secret key for your signature. Note that PGP attempts to compress the plaintext before encrypting it. If you want to send this encrypted message through E-mail channels, convert it into printable ASCII "radix-64" format by adding the -a option, as described later. Multiple recipients may be specified by adding more user IDs to the command line. Using Just Conventional Encryption ---------------------------------- Sometimes you just need to encrypt a file the old-fashioned way, with conventional single-key cryptography. This approach is useful for protecting archive files that will be stored but will not be sent to anyone else. Since the same person that encrypted the file will also decrypt the file, public key cryptography is not really necessary. To encrypt a plaintext file with just conventional cryptography, type: pgp -c textfile This example encrypts the plaintext file called textfile, producing a ciphertext file called textfile.pgp, without using public key cryptography, key rings, user IDs, or any of that stuff. It prompts you for a pass phrase to use as a conventional key to encipher the file. This pass phrase need not be (and, indeed, SHOULD not be) the same pass phrase that you use to protect your own secret key. Note that PGP attempts to compress the plaintext before encrypting it. PGP will not encrypt the same plaintext the same way twice, even if you used the same pass phrase every time. Decrypting and Checking Signatures ---------------------------------- To decrypt an encrypted file, or to check the signature integrity of a signed file: pgp ciphertextfile [-o plaintextfile] Note that [brackets] denote an optional field, so don't actually type real brackets. The ciphertext file name is assumed to have a default extension of ".pgp". The optional plaintext output file name specifies where to put processed plaintext output. If no name is specified, the ciphertext filename is used, with no extension. If a signature is nested inside of an encrypted file, it is automatically decrypted and the signature integrity is checked. The full user ID of the signer is displayed. Note that the "unwrapping" of the ciphertext file is completely automatic, regardless of whether the ciphertext file is just signed, just encrypted, or both. PGP uses the key ID prefix in the ciphertext file to automatically find the appropriate secret decryption key on your secret key ring. If there is a nested signature, PGP then uses the key ID prefix in the nested signature to automatically find the appropriate public key on your public key ring to check the signature. If all the right keys are already present on your key rings, no user intervention is required, except that you will be prompted for your password for your secret key if necessary. If the ciphertext file was conventionally encrypted without public key cryptography, PGP recognizes this and prompts you for the pass phrase to conventionally decrypt it. Managing Keys ============= Since the time of Julius Caesar, key management has always been the hardest part of cryptography. One of the principal distinguishing features of PGP is its sophisticated key management. RSA Key Generation ------------------ To generate your own unique public/secret key pair of a specified size, type: pgp -kg PGP shows you a menu of recommended key sizes (low commercial grade, high commercial grade, or "military" grade) and prompts you for what size key you want, up to more than a thousand bits. The bigger the key, the more security you get, but you pay a price in speed. It also asks for a user ID, which means your name. It's a good idea to use your full name as your user ID, because then there is less risk of other people using the wrong public key to encrypt messages to you. Spaces and punctuation are allowed in the user ID. It would help if you put your E-mail address in after your name, like so: Robert M. Smith If you don't have an E-mail address, use your phone number or some other unique information that would help ensure that your user ID is unique. PGP also asks for a "pass phrase" to protect your secret key in case it falls into the wrong hands. Nobody can use your secret key file without this pass phrase. The pass phrase is like a password, except that it can be a whole phrase or sentence with many words, spaces, punctuation, or anything else you want in it. Don't lose this pass phrase-- there's no way to recover it if you do lose it. This pass phrase will be needed later every time you use your secret key. The pass phrase is case-sensitive, and should not be too short or easy to guess. It is never displayed on the screen. Don't leave it written down anywhere where someone else can see it, and don't store it on your computer. If you don't want a pass phrase (You fool!), just press return (or enter) at the pass phrase prompt. The public/secret key pair is derived from large truly random numbers derived mainly from measuring the intervals between your keystrokes with a fast timer. The software will ask you to enter some random text to help it accumulate some random bits for the keys. When asked, you should provide some keystrokes that are reasonably random in their timing, and it wouldn't hurt to make the actual characters that you type irregular in content as well. Some of the randomness is derived from the unpredictability of the content of what you type. So don't just type repeated sequences of characters. Note that RSA key generation is a lengthy process. It may take a few seconds for a small key on a fast processor, or quite a few minutes for a large key on an old IBM PC/XT. PGP will visually indicate its progress during key generation. The generated key pair will be placed on your public and secret key rings. You can later use the -kx command option to extract (copy) your new public key from your public key ring and place it in a separate public key file suitable for distribution to your friends. The public key file can be sent to your friends for inclusion in their public key rings. Naturally, you keep your secret key file to yourself, and you should include it on your secret key ring. Each secret key on a key ring is individually protected with its own pass phrase. Never give your secret key to anyone else. For the same reason, don't make key pairs for your friends. Everyone should make their own key pair. Always keep physical control of your secret key, and don't risk exposing it by storing it on a remote timesharing computer. Keep it on your own personal computer. If PGP complains about not being able to find the PGP User's Guide on your computer, and refuses to generate a key pair without it, don't panic. Just read the explanation of the NOMANUAL parameter in the section "Setting Configuration Parameters" in the Special Topics volume of the PGP User's Guide. Adding a Key to Your Key Ring ----------------------------- Sometimes you will want to add to your keyring a key provided to you by someone else, in the form of a keyfile. To add a public or secret key file's contents to your public or secret key ring (note that [brackets] denote an optional field): pgp -ka keyfile [keyring] The keyfile extension defaults to ".pgp". The optional keyring file name defaults to "pubring.pgp" or "secring.pgp", depending on whether the keyfile contains a public or a secret key. You may specify a different key ring file name, with the extension defaulting to ".pgp". If the key is already on your key ring, PGP will not add it again. All of the keys in the keyfile are added to the keyring, except for duplicates. Later in the manual, we will explain the concept of certifying keys with signatures. If the key being added has attached signatures certifying it, the signatures are added with the key. If the key is already on your key ring, PGP just merges in any new certifying signatures for that key that you don't already have on your key ring. PGP was originally designed for handling small personal keyrings. If you want to handle really big keyrings, see the section on "Handling Large Public Keyrings" in the Special Topics volume. Removing a Key or User ID from Your Key Ring -------------------------------------------- To remove a key or a user ID from your public key ring: pgp -kr userid [keyring] This searches for the specified user ID in your key ring, and removes it if it finds a match. Remember that any fragment of the user ID will suffice for a match. The optional keyring file name is assumed to be literally "pubring.pgp". It can be omitted, or you can specify "secring.pgp" if you want to remove a secret key. You may specify a different key ring file name. The default key ring extension is ".pgp". If more than one user ID exists for this key, you will be asked if you want to remove only the user ID you specified, while leaving the key and its other user IDs intact. Extracting (copying) a Key from Your Key Ring --------------------------------------------- To extract (copy) a key from your public or secret key ring: pgp -kx userid keyfile [keyring] This non-destructively copies the key specified by the user ID from your public or secret key ring to the specified key file. This is particularly useful if you want to give a copy of your public key to someone else. If the key has any certifying signatures attached to it on your key ring, they are copied off along with the key. If you want the extracted key represented in printable ASCII characters suitable for email purposes, use the -kxa options. Viewing the Contents of Your Key Ring ------------------------------------- To view the contents of your public key ring: pgp -kv[v] [userid] [keyring] This lists any keys in the key ring that match the specified user ID substring. If you omit the user ID, all of the keys in the key ring are listed. The optional keyring file name is assumed to be "pubring.pgp". It can be omitted, or you can specify "secring.pgp" if you want to list secret keys. If you want to specify a different key ring file name, you can. The default key ring extension is ".pgp". Later in the manual, we will explain the concept of certifying keys with signatures. To see all the certifying signatures attached to each key, use the -kvv option: pgp -kvv [userid] [keyring] If you want to specify a particular key ring file name, but want to see all the keys in it, try this alternative approach: pgp keyfile With no command options specified, PGP lists all the keys in keyfile.pgp, and also attempts to add them to your key ring if they are not already on your key ring. How to Protect Public Keys from Tampering ----------------------------------------- In a public key cryptosystem, you don't have to protect public keys from exposure. In fact, it's better if they are widely disseminated. But it is important to protect public keys from tampering, to make sure that a public key really belongs to whom it appears to belong to. This may be the most important vulnerability of a public-key cryptosystem. Let's first look at a potential disaster, then at how to safely avoid it with PGP. Suppose you wanted to send a private message to Alice. You download Alice's public key certificate from an electronic bulletin board system (BBS). You encrypt your letter to Alice with this public key and send it to her through the BBS's E-mail facility. Unfortunately, unbeknownst to you or Alice, another user named Charlie has infiltrated the BBS and generated a public key of his own with Alice's user ID attached to it. He covertly substitutes his bogus key in place of Alice's real public key. You unwittingly use this bogus key belonging to Charlie instead of Alice's public key. All looks normal because this bogus key has Alice's user ID. Now Charlie can decipher the message intended for Alice because he has the matching secret key. He may even re-encrypt the deciphered message with Alice's real public key and send it on to her so that no one suspects any wrongdoing. Furthermore, he can even make apparently good signatures from Alice with this secret key because everyone will use the bogus public key to check Alice's signatures. The only way to prevent this disaster is to prevent anyone from tampering with public keys. If you got Alice's public key directly from Alice, this is no problem. But that may be difficult if Alice is a thousand miles away, or is currently unreachable. Perhaps you could get Alice's public key from a mutual trusted friend David who knows he has a good copy of Alice's public key. David could sign Alice's public key, vouching for the integrity of Alice's public key. David would create this signature with his own secret key. This would create a signed public key certificate, and would show that Alice's key had not been tampered with. This requires you have a known good copy of David's public key to check his signature. Perhaps David could provide Alice with a signed copy of your public key also. David is thus serving as an "introducer" between you and Alice. This signed public key certificate for Alice could be uploaded by David or Alice to the BBS, and you could download it later. You could then check the signature via David's public key and thus be assured that this is really Alice's public key. No impostor can fool you into accepting his own bogus key as Alice's because no one else can forge signatures made by David. A widely trusted person could even specialize in providing this service of "introducing" users to each other by providing signatures for their public key certificates. This trusted person could be regarded as a "key server", or as a "Certifying Authority". Any public key certificates bearing the key server's signature could be trusted as truly belonging to whom they appear to belong to. All users who wanted to participate would need a known good copy of just the key server's public key, so that the key server's signatures could be verified. A trusted centralized key server or Certifying Authority is especially appropriate for large impersonal centrally-controlled corporate or government institutions. Some institutional environments use hierarchies of Certifying Authorities. For more decentralized grassroots "guerrilla style" environments, allowing all users to act as a trusted introducers for their friends would probably work better than a centralized key server. PGP tends to emphasize this organic decentralized non-institutional approach. It better reflects the natural way humans interact on a personal social level, and allows people to better choose who they can trust for key management. This whole business of protecting public keys from tampering is the single most difficult problem in practical public key applications. It is the Achilles' heel of public key cryptography, and a lot of software complexity is tied up in solving this one problem. You should use a public key only after you are sure that it is a good public key that has not been tampered with, and actually belongs to the person it claims to. You can be sure of this if you got this public key certificate directly from its owner, or if it bears the signature of someone else that you trust, from whom you already have a good public key. Also, the user ID should have the full name of the key's owner, not just her first name. No matter how tempted you are-- and you will be tempted-- never, NEVER give in to expediency and trust a public key you downloaded from a bulletin board, unless it is signed by someone you trust. That uncertified public key could have been tampered with by anyone, maybe even by the system administrator of the bulletin board. If you are asked to sign someone else's public key certificate, make certain that it really belongs to that person named in the user ID of that public key certificate. This is because your signature on her public key certificate is a promise by you that this public key really belongs to her. Other people who trust you will accept her public key because it bears your signature. It may be ill-advised to rely on hearsay-- don't sign her public key unless you have independent firsthand knowledge that it really belongs to her. Preferably, you should sign it only if you got it directly from her. In order to sign a public key, you must be far more certain of that key's ownership than if you merely want to use that key to encrypt a message. To be convinced of a key's validity enough to use it, certifying signatures from trusted introducers should suffice. But to sign a key yourself, you should require your own independent firsthand knowledge of who owns that key. Perhaps you could call the key's owner on the phone and read the key file to her to get her to confirm that the key you have really is her key-- and make sure you really are talking to the right person. See the section called "Verifying a Public Key Over the Phone" in the Special Topics volume for further details. Bear in mind that your signature on a public key certificate does not vouch for the integrity of that person, but only vouches for the integrity (the ownership) of that person's public key. You aren't risking your credibility by signing the public key of a sociopath, if you were completely confident that the key really belonged to him. Other people would accept that key as belonging to him because you signed it (assuming they trust you), but they wouldn't trust that key's owner. Trusting a key is not the same as trusting the key's owner. Trust is not necessarily transferable; I have a friend who I trust not to lie. He's a gullible person who trusts the President not to lie. That doesn't mean I trust the President not to lie. This is just common sense. If I trust Alice's signature on a key, and Alice trusts Charlie's signature on a key, that does not imply that I have to trust Charlie's signature on a key. It would be a good idea to keep your own public key on hand with a collection of certifying signatures attached from a variety of "introducers", in the hopes that most people will trust at least one of the introducers who vouch for your own public key's validity. You could post your key with its attached collection of certifying signatures on various electronic bulletin boards. If you sign someone else's public key, return it to them with your signature so that they can add it to their own collection of credentials for their own public key. PGP keeps track of which keys on your public key ring are properly certified with signatures from introducers that you trust. All you have to do is tell PGP which people you trust as introducers, and certify their keys yourself with your own ultimately trusted key. PGP can take it from there, automatically validating any other keys that have been signed by your designated introducers. And of course you may directly sign more keys yourself. More on this later. Make sure no one else can tamper with your own public key ring. Checking a new signed public key certificate must ultimately depend on the integrity of the trusted public keys that are already on your own public key ring. Maintain physical control of your public key ring, preferably on your own personal computer rather than on a remote timesharing system, just as you would do for your secret key. This is to protect it from tampering, not from disclosure. Keep a trusted backup copy of your public key ring and your secret key ring on write-protected media. Since your own trusted public key is used as a final authority to directly or indirectly certify all the other keys on your key ring, it is the most important key to protect from tampering. To detect any tampering of your own ultimately-trusted public key, PGP can be set up to automatically compare your public key against a backup copy on write-protected media. For details, see the description of the "-kc" key ring check command in the Special Topics volume. PGP generally assumes you will maintain physical security over your system and your key rings, as well as your copy of PGP itself. If an intruder can tamper with your disk, then in theory he can tamper with PGP itself, rendering moot the safeguards PGP may have to detect tampering with keys. One somewhat complicated way to protect your own whole public key ring from tampering is to sign the whole ring with your own secret key. You could do this by making a detached signature certificate of the public key ring, by signing the ring with the "-sb" options (see the section called "Separating Signatures from Messages" in the PGP User's Guide, Special Topics volume). Unfortunately, you would still have to keep a separate trusted copy of your own public key around to check the signature you made. You couldn't rely on your own public key stored on your public key ring to check the signature you made for the whole ring, because that is part of what you're trying to check. How Does PGP Keep Track of Which Keys are Valid? ------------------------------------------------ Before you read this section, be sure to read the above section on "How to Protect Public Keys from Tampering". PGP keeps track of which keys on your public key ring are properly certified with signatures from introducers that you trust. All you have to do is tell PGP which people you trust as introducers, and certify their keys yourself with your own ultimately trusted key. PGP can take it from there, automatically validating any other keys that have been signed by your designated introducers. And of course you may directly sign more keys yourself. There are two entirely separate criteria PGP uses to judge a public key's usefulness-- don't get them confused: 1) Does the key actually belong to whom it appears to belong? In other words, has it been certified with a trusted signature? 2) Does it belong to someone you can trust to certify other keys? PGP can calculate the answer to the first question. To answer the second question, PGP must be explicitly told by you, the user. When you supply the answer to question 2, PGP can then calculate the answer to question 1 for other keys signed by the introducer you designated as trusted. Keys that have been certified by a trusted introducer are deemed valid by PGP. The keys belonging to trusted introducers must themselves be certified either by you or by other trusted introducers. PGP also allows for the possibility of you having several shades of trust for people to act as introducers. Your trust for a key's owner to act as an introducer does not just reflect your estimation of their personal integrity-- it should also reflect how competent you think they are at understanding key management and using good judgment in signing keys. You can designate a person to PGP as unknown, untrusted, marginally trusted, or completely trusted to certify other public keys. This trust information is stored on your key ring with their key, but when you tell PGP to copy a key off your key ring, PGP will not copy the trust information along with the key, because your private opinions on trust are regarded as confidential. When PGP is calculating the validity of a public key, it examines the trust level of all the attached certifying signatures. It computes a weighted score of validity-- two marginally trusted signatures are deemed as credible as one fully trusted signature. PGP's skepticism is adjustable-- for example, you may tune PGP to require two fully trusted signatures or three marginally trusted signatures to judge a key as valid. Your own key is "axiomatically" valid to PGP, needing no introducer's signature to prove its validity. PGP knows which public keys are yours, by looking for the corresponding secret keys on the secret key ring. PGP also assumes you ultimately trust yourself to certify other keys. As time goes on, you will accumulate keys from other people that you may want to designate as trusted introducers. Everyone else will each choose their own trusted introducers. And everyone will gradually accumulate and distribute with their key a collection of certifying signatures from other people, with the expectation that anyone receiving it will trust at least one or two of the signatures. This will cause the emergence of a decentralized fault-tolerant web of confidence for all public keys. This unique grass-roots approach contrasts sharply with Government standard public key management schemes, such as Internet Privacy Enhanced Mail (PEM), which are based on centralized control and mandatory centralized trust. The standard schemes rely on a hierarchy of Certifying Authorities who dictate who you must trust. PGP's decentralized probabilistic method for determining public key legitimacy is the centerpiece of its key management architecture. PGP lets you alone choose who you trust, putting you at the top of your own private certification pyramid. PGP is for people who prefer to pack their own parachutes. How to Protect Secret Keys from Disclosure ------------------------------------------ Protect your own secret key and your pass phrase carefully. Really, really carefully. If your secret key is ever compromised, you'd better get the word out quickly to all interested parties (good luck) before someone else uses it to make signatures in your name. For example, they could use it to sign bogus public key certificates, which could create problems for many people, especially if your signature is widely trusted. And of course, a compromise of your own secret key could expose all messages sent to you. To protect your secret key, you can start by always keeping physical control of your secret key. Keeping it on your personal computer at home is OK, or keep it in your notebook computer that you can carry with you. If you must use an office computer that you don't always have physical control of, then keep your public and secret key rings on a write-protected removable floppy disk, and don't leave it behind when you leave the office. It wouldn't be a good idea to allow your secret key to reside on a remote timesharing computer, such as a remote dial-in Unix system. Someone could eavesdrop on your modem line and capture your pass phrase, and then obtain your actual secret key from the remote system. You should only use your secret key on a machine that you have physical control over. Don't store your pass phrase anywhere on the computer that has your secret key file. Storing both the secret key and the pass phrase on the same computer is as dangerous as keeping your PIN in the same wallet as your Automatic Teller Machine bank card. You don't want somebody to get their hands on your disk containing both the pass phrase and the secret key file. It would be most secure if you just memorize your pass phrase and don't store it anywhere but your brain. If you feel you must write down your pass phrase, keep it well protected, perhaps even more well protected than the secret key file. And keep backup copies of your secret key ring-- remember, you have the only copy of your secret key, and losing it will render useless all the copies of your public key that you have spread throughout the world. The decentralized non-institutional approach PGP uses to manage public keys has its benefits, but unfortunately this also means we can't rely on a single centralized list of which keys have been compromised. This makes it a bit harder to contain the damage of a secret key compromise. You just have to spread the word and hope everyone hears about it. If the worst case happens-- your secret key and pass phrase are both compromised (hopefully you will find this out somehow)-- you will have to issue a "key compromise" certificate. This kind of certificate is used to warn other people to stop using your public key. You can use PGP to create such a certificate by using the "-kd" command. Then you must somehow send this compromise certificate to everyone else on the planet, or at least to all your friends and their friends, et cetera. Their own PGP software will install this key compromise certificate on their public key rings and will automatically prevent them from accidentally using your public key ever again. You can then generate a new secret/public key pair and publish the new public key. You could send out one package containing both your new public key and the key compromise certificate for your old key. Revoking a Public Key --------------------- Suppose your secret key and your pass phrase are somehow both compromised. You have to get the word out to the rest of the world, so that they will all stop using your public key. To do this, you will have to issue a "key compromise", or "key revocation" certificate to revoke your public key. To generate a certificate to revoke your own key, use the -kd command: pgp -kd your_userid This certificate bears your signature, made with the same key you are revoking. You should widely disseminate this key revocation certificate as soon as possible. Other people who receive it can add it to their public key rings, and their PGP software then automatically prevents them from accidentally using your old public key ever again. You can then generate a new secret/public key pair and publish the new public key. You may choose to revoke your key for some other reason than the compromise of a secret key. If so, you may still use the same mechanism to revoke it. What If You Lose Your Secret Key? --------------------------------- Normally, if you want to revoke your own secret key, you can use the "-kd" command to issue a revocation certificate, signed with your own secret key (see "Revoking a Public Key"). But what can you do if you lose your secret key, or if your secret key is destroyed? You can't revoke it yourself, because you must use your own secret key to revoke it, and you don't have it anymore. A future version of PGP will offer a more secure means of revoking keys in these circumstances, allowing trusted introducers to certify that a public key has been revoked. But for now, you will have to get the word out through whatever informal means you can, asking users to "disable" your public key on their own individual public key rings. Other users may disable your public key on their own public key rings by using the "-kd" command. If a user ID is specified that does not correspond to a secret key on the secret key ring, the -kd command will look for that user ID on the public key ring, and mark that public key as disabled. A disabled key may not be used to encrypt any messages, and may not be extracted from the key ring with the -kx command. It can still be used to check signatures, but a warning is displayed. And if the user tries to add the same key again to his key ring, it will not work because the disabled key is already on the key ring. These combined features will help curtail the further spread of a disabled key. If the specified public key is already disabled, the -kd command will ask if you want the key reenabled. Advanced Topics =============== Most of the "Advanced Topics" are covered in the "PGP User's Guide, Volume II: Special Topics". But here are a few topics that bear mentioning here. Sending Ciphertext Through E-mail Channels: Radix-64 Format ----------------------------------------------------------- Many electronic mail systems only allow messages made of ASCII text, not the 8-bit raw binary data that ciphertext is made of. To get around this problem, PGP supports ASCII radix-64 format for ciphertext messages, similar to the Internet Privacy-Enhanced Mail (PEM) format, as well as the Internet MIME format. This special format represents binary data by using only printable ASCII characters, so it is useful for transmitting binary encrypted data through 7-bit channels or for sending binary encrypted data as normal E-mail text. This format acts as a form of "transport armor", protecting it against corruption as it travels through intersystem gateways on Internet. PGP also appends a CRC to detect transmission errors. Radix-64 format converts the plaintext by expanding groups of 3 binary 8-bit bytes into 4 printable ASCII characters, so the file grows by about 33%. But this expansion isn't so bad when you consider that the file probably was compressed more than that by PGP before it was encrypted. To produce a ciphertext file in ASCII radix-64 format, just add the "a" option when encrypting or signing a message, like so: pgp -esa message.txt her_userid This example produces a ciphertext file called "message.asc" that contains data in a MIME-like ASCII radix-64 format. This file can be easily uploaded into a text editor through 7-bit channels for transmission as normal E-mail on Internet or any other E-mail network. Decrypting the radix-64 transport-armored message is no different than a normal decrypt. For example: pgp message PGP automatically looks for the ASCII file "message.asc" before it looks for the binary file "message.pgp". It recognizes that the file is in radix-64 format and converts it back to binary before processing as it normally does, producing as a by-product a ".pgp" ciphertext file in binary form. The final output file is in normal plaintext form, just as it was in the original file "message.txt". Most Internet E-mail facilities prohibit sending messages that are more than 50000 or 65000 bytes long. Longer messages must be broken into smaller chunks that can be mailed separately. If your encrypted message is very large, and you requested radix-64 format, PGP automatically breaks it up into chunks that are each small enough to send via E-mail. The chunks are put into files named with extensions ".as1", ".as2", ".as3", etc. The recipient must concatenate these separate files back together in their proper order into one big file before decrypting it. While decrypting, PGP ignores any extraneous text in mail headers that are not enclosed in the radix-64 message blocks. If you want to send a public key to someone else in radix-64 format, just add the -a option while extracting the key from your keyring. If you forgot to use the -a option when you made a ciphertext file or extracted a key, you may still directly convert the binary file into radix-64 format by simply using the -a option alone, without any encryption specified. PGP converts it to a ".asc" file. If you sign a plaintext file without encrypting it, PGP will normally compress it after signing it, rendering it unreadable to the casual human observer. This is a suitable way of storing signed files in archival applications. But if you want to send the signed message as E-mail, and the the original plaintext message is in text (not binary) form, there is a way to send it through an E-mail channel in such a way that the plaintext does not get compressed, and the ASCII armor is applied only to the binary signature certificate, but not to the plaintext message. This makes it possible for the recipient to read the signed message with human eyes, without the aid of PGP. Of course, PGP is still needed to actually check the signature. For further information on this feature, see the explanation of the CLEARSIG parameter in the section "Setting Configuration Parameters" in the Special Topics volume. Sometimes you may want to send a binary data file through an E-mail channel without encrypting or signing it with PGP. Some people use the Unix uuencode utility for that purpose. PGP can also be used for that purpose, by simply using the -a option alone, and it does a better job than the uuencode utility. For further details, see the section on "Using PGP as a Better Uuencode" in the Special Topics volume. Environmental Variable for Path Name ------------------------------------ PGP uses several special files for its purposes, such as your standard key ring files "pubring.pgp" and "secring.pgp", the random number seed file "randseed.bin", the PGP configuration file "config.txt" (or "pgp.ini", or ".pgprc"), and the foreign language string translation file "language.txt". These special files can be kept in any directory, by setting the environmental variable "PGPPATH" to the desired pathname. For example, on MSDOS, the shell command: SET PGPPATH=C:\PGP makes PGP assume that your public key ring filename is "C:\PGP\pubring.pgp". Assuming, of course, that this directory exists. Use your favorite text editor to modify your MSDOS AUTOEXEC.BAT file to automatically set up this variable whenever you start up your system. If PGPPATH remains undefined, these special files are assumed to be in the current directory. Setting Parameters in the PGP Configuration File ------------------------------------------------ PGP has a number of user-settable parameters that can be defined in a special PGP configuration text file called "config.txt", in the directory pointed to by the shell environmental variable PGPPATH. Having a configuration file enables the user to define various flags and parameters for PGP without the burden of having to always define these parameters in the PGP command line. In the interest of complying with local operating system file naming conventions, for Unix systems this configuration file may also be named ".pgprc", and on MSDOS systems it may also be named "pgp.ini". With these configuration parameters, for example, you can control where PGP stores its temporary scratch files, or you can select what foreign language PGP will use to display its diagnostics messages and user prompts, or you can adjust PGP's level of skepticism in determining a key's validity based on the number of certifying signatures it has. For more details on setting these configuration parameters, see the appropriate section of the PGP User's Guide, Special Topics volume. Vulnerabilities --------------- No data security system is impenetrable. PGP can be circumvented in a variety of ways. Potential vulnerabilities you should be aware of include compromising your pass phrase or secret key, public key tampering, files that you deleted but are still somewhere on the disk, viruses and Trojan horses, breaches in your physical security, electromagnetic emissions, exposure on multi-user systems, traffic analysis, and perhaps even direct cryptanalysis. For a detailed discussion of these issues, see the "Vulnerabilities" section in the PGP User's Guide, Special Topics volume. Beware of Snake Oil =================== When examining a cryptographic software package, the question always remains, why should you trust this product? Even if you examined the source code yourself, not everyone has the cryptographic experience to judge the security. Even if you are an experienced cryptographer, subtle weaknesses in the algorithms could still elude you. When I was in college in the early seventies, I devised what I believed was a brilliant encryption scheme. A simple pseudorandom number stream was added to the plaintext stream to create ciphertext. This would seemingly thwart any frequency analysis of the ciphertext, and would be uncrackable even to the most resourceful Government intelligence agencies. I felt so smug about my achievement. So cock-sure. Years later, I discovered this same scheme in several introductory cryptography texts and tutorial papers. How nice. Other cryptographers had thought of the same scheme. Unfortunately, the scheme was presented as a simple homework assignment on how to use elementary cryptanalytic techniques to trivially crack it. So much for my brilliant scheme. From this humbling experience I learned how easy it is to fall into a false sense of security when devising an encryption algorithm. Most people don't realize how fiendishly difficult it is to devise an encryption algorithm that can withstand a prolonged and determined attack by a resourceful opponent. Many mainstream software engineers have developed equally naive encryption schemes (often even the very same encryption scheme), and some of them have been incorporated into commercial encryption software packages and sold for good money to thousands of unsuspecting users. This is like selling automotive seat belts that look good and feel good, but snap open in even the slowest crash test. Depending on them may be worse than not wearing seat belts at all. No one suspects they are bad until a real crash. Depending on weak cryptographic software may cause you to unknowingly place sensitive information at risk. You might not otherwise have done so if you had no cryptographic software at all. Perhaps you may never even discover your data has been compromised. Sometimes commercial packages use the Federal Data Encryption Standard (DES), a fairly good conventional algorithm recommended by the Government for commercial use (but not for classified information, oddly enough-- hmmm). There are several "modes of operation" the DES can use, some of them better than others. The Government specifically recommends not using the weakest simplest mode for messages, the Electronic Codebook (ECB) mode. But they do recommend the stronger and more complex Cipher Feedback (CFB) or Cipher Block Chaining (CBC) modes. Unfortunately, most of the commercial encryption packages I've looked at use ECB mode. When I've talked to the authors of a number of these implementations, they say they've never heard of CBC or CFB modes, and didn't know anything about the weaknesses of ECB mode. The very fact that they haven't even learned enough cryptography to know these elementary concepts is not reassuring. And they sometimes manage their DES keys in inappropriate or insecure ways. Also, these same software packages often include a second faster encryption algorithm that can be used instead of the slower DES. The author of the package often thinks his proprietary faster algorithm is as secure as the DES, but after questioning him I usually discover that it's just a variation of my own brilliant scheme from college days. Or maybe he won't even reveal how his proprietary encryption scheme works, but assures me it's a brilliant scheme and I should trust it. I'm sure he believes that his algorithm is brilliant, but how can I know that without seeing it? In all fairness I must point out that in most cases these terribly weak products do not come from companies that specialize in cryptographic technology. Even the really good software packages, that use the DES in the correct modes of operation, still have problems. Standard DES uses a 56-bit key, which is too small by today's standards, and may now be easily broken by exhaustive key searches on special high-speed machines. The DES has reached the end of its useful life, and so has any software package that relies on it. There is a company called AccessData (87 East 600 South, Orem, Utah 84058, phone 1-800-658-5199) that sells a package for $185 that cracks the built-in encryption schemes used by WordPerfect, Lotus 1-2-3, MS Excel, Symphony, Quattro Pro, Paradox, and MS Word 2.0. It doesn't simply guess passwords-- it does real cryptanalysis. Some people buy it when they forget their password for their own files. Law enforcement agencies buy it too, so they can read files they seize. I talked to Eric Thompson, the author, and he said his program only takes a split second to crack them, but he put in some delay loops to slow it down so it doesn't look so easy to the customer. He also told me that the password encryption feature of PKZIP files can often be easily broken, and that his law enforcement customers already have that service regularly provided to them from another vendor. In some ways, cryptography is like pharmaceuticals. Its integrity may be absolutely crucial. Bad penicillin looks the same as good penicillin. You can tell if your spreadsheet software is wrong, but how do you tell if your cryptography package is weak? The ciphertext produced by a weak encryption algorithm looks as good as ciphertext produced by a strong encryption algorithm. There's a lot of snake oil out there. A lot of quack cures. Unlike the patent medicine hucksters of old, these software implementors usually don't even know their stuff is snake oil. They may be good software engineers, but they usually haven't even read any of the academic literature in cryptography. But they think they can write good cryptographic software. And why not? After all, it seems intuitively easy to do so. And their software seems to work okay. Anyone who thinks they have devised an unbreakable encryption scheme either is an incredibly rare genius or is naive and inexperienced. Unfortunately, I sometimes have to deal with would-be cryptographers who want to make "improvements" to PGP by adding encryption algorithms of their own design. I remember a conversation with Brian Snow, a highly placed senior cryptographer with the NSA. He said he would never trust an encryption algorithm designed by someone who had not "earned their bones" by first spending a lot of time cracking codes. That did make a lot of sense. I observed that practically no one in the commercial world of cryptography qualified under this criterion. "Yes", he said with a self assured smile, "And that makes our job at NSA so much easier." A chilling thought. I didn't qualify either. The Government has peddled snake oil too. After World War II, the US sold German Enigma ciphering machines to third world governments. But they didn't tell them that the Allies cracked the Enigma code during the war, a fact that remained classified for many years. Even today many Unix systems worldwide use the Enigma cipher for file encryption, in part because the Government has created legal obstacles against using better algorithms. They even tried to prevent the initial publication of the RSA algorithm in 1977. And they have squashed essentially all commercial efforts to develop effective secure telephones for the general public. The principal job of the US Government's National Security Agency is to gather intelligence, principally by covertly tapping into people's private communications (see James Bamford's book, "The Puzzle Palace"). The NSA has amassed considerable skill and resources for cracking codes. When people can't get good cryptography to protect themselves, it makes NSA's job much easier. NSA also has the responsibility of approving and recommending encryption algorithms. Some critics charge that this is a conflict of interest, like putting the fox in charge of guarding the hen house. NSA has been pushing a conventional encryption algorithm that they designed, and they won't tell anybody how it works because that's classified. They want others to trust it and use it. But any cryptographer can tell you that a well-designed encryption algorithm does not have to be classified to remain secure. Only the keys should need protection. How does anyone else really know if NSA's classified algorithm is secure? It's not that hard for NSA to design an encryption algorithm that only they can crack, if no one else can review the algorithm. Are they deliberately selling snake oil? There are three main factors that have undermined the quality of commercial cryptographic software in the US. The first is the virtually universal lack of competence of implementors of commercial encryption software (although this is starting to change since the publication of PGP). Every software engineer fancies himself a cryptographer, which has led to the proliferation of really bad crypto software. The second is the NSA deliberately and systematically suppressing all the good commercial encryption technology, by legal intimidation and economic pressure. Part of this pressure is brought to bear by stringent export controls on encryption software which, by the economics of software marketing, has the net effect of suppressing domestic encryption software. The other principle method of suppression comes from the granting all the software patents for all the public key encryption algorithms to a single company, affording a single choke point to suppress the spread of this technology. The net effect of all this is that before PGP was published, there was almost no highly secure general purpose encryption software available in the US. I'm not as certain about the security of PGP as I once was about my brilliant encryption software from college. If I were, that would be a bad sign. But I'm pretty sure that PGP does not contain any glaring weaknesses (although it may contain bugs). The crypto algorithms were developed by people at high levels of civilian cryptographic academia, and have been individually subject to extensive peer review. Source code is available to facilitate peer review of PGP and to help dispel the fears of some users. It's reasonably well researched, and has been years in the making. And I don't work for the NSA. I hope it doesn't require too large a "leap of faith" to trust the security of PGP. Notice to Macintosh Users ========================= PGP was originally developed for MSDOS and Unix machines. There is also an Apple Macintosh version of PGP. This manual is written for the MSDOS/Unix versions of PGP, which use a command-line interface for all the PGP functions. On the Mac, all the PGP functions are accessed through pull-down menus and dialog boxes. There is also on-line help on the Mac for how to use MacPGP, and there should be some Mac-specific user documentation included in the MacPGP release package, in addition to this manual. Almost all good Mac software applications are written from scratch for the Mac, not simply ported there from other operating systems. Unfortunately, the current Mac version of PGP was not designed for the Mac from scratch. It was ported from the MSDOS/Unix version to the Mac by Zbigniew Fiedorwicz. Since the MSDOS/Unix version of PGP was not designed for a GUI (graphical user interface), porting to the Mac was not an easy task, and many bugs still remain. An all-new version of PGP is under development, designed for easy adaptation to a GUI. A new Mac version will be developed from this new PGP source code. It will be more Mac-like, and more reliable. Despite the bugs in the current version of MacPGP, it is important to note that if Zbigniew had waited for this all-new version of PGP to be developed before he ported PGP to the Mac, the world would have been deprived of a Mac version of PGP for far too long. PGP Quick Reference =================== Here's a quick summary of PGP commands. To encrypt a plaintext file with the recipient's public key: pgp -e textfile her_userid To sign a plaintext file with your secret key: pgp -s textfile [-u your_userid] To sign a plaintext ASCII text file with your secret key, producing a signed plaintext message suitable for sending via E-mail: pgp -sta textfile [-u your_userid] To sign a plaintext file with your secret key, and then encrypt it with the recipient's public key: pgp -es textfile her_userid [-u your_userid] To encrypt a plaintext file with just conventional cryptography, type: pgp -c textfile To decrypt an encrypted file, or to check the signature integrity of a signed file: pgp ciphertextfile [-o plaintextfile] To encrypt a message for any number of multiple recipients: pgp -e textfile userid1 userid2 userid3 --- Key management commands: To generate your own unique public/secret key pair: pgp -kg To add a public or secret key file's contents to your public or secret key ring: pgp -ka keyfile [keyring] To extract (copy) a key from your public or secret key ring: pgp -kx userid keyfile [keyring] or: pgp -kxa userid keyfile [keyring] To view the contents of your public key ring: pgp -kv[v] [userid] [keyring] To view the "fingerprint" of a public key, to help verify it over the telephone with its owner: pgp -kvc [userid] [keyring] To view the contents and check the certifying signatures of your public key ring: pgp -kc [userid] [keyring] To edit the userid or pass phrase for your secret key: pgp -ke userid [keyring] To edit the trust parameters for a public key: pgp -ke userid [keyring] To remove a key or just a userid from your public key ring: pgp -kr userid [keyring] To sign and certify someone else's public key on your public key ring: pgp -ks her_userid [-u your_userid] [keyring] To remove selected signatures from a userid on a keyring: pgp -krs userid [keyring] To permanently revoke your own key, issuing a key compromise certificate: pgp -kd your_userid To disable or reenable a public key on your own public key ring: pgp -kd userid --- Esoteric commands: To decrypt a message and leave the signature on it intact: pgp -d ciphertextfile To create a signature certificate that is detached from the document: pgp -sb textfile [-u your_userid] To detach a signature certificate from a signed message: pgp -b ciphertextfile --- Command options that can be used in combination with other command options (sometimes even spelling interesting words!): To produce a ciphertext file in ASCII radix-64 format, just add the -a option when encrypting or signing a message or extracting a key: pgp -sea textfile her_userid or: pgp -kxa userid keyfile [keyring] To wipe out the plaintext file after producing the ciphertext file, just add the -w (wipe) option when encrypting or signing a message: pgp -sew message.txt her_userid To specify that a plaintext file contains ASCII text, not binary, and should be converted to recipient's local text line conventions, add the -t (text) option to other options: pgp -seat message.txt her_userid To view the decrypted plaintext output on your screen (like the Unix-style "more" command), without writing it to a file, use the -m (more) option while decrypting: pgp -m ciphertextfile To specify that the recipient's decrypted plaintext will be shown ONLY on her screen and cannot be saved to disk, add the -m option: pgp -steam message.txt her_userid To recover the original plaintext filename while decrypting, add the -p option: pgp -p ciphertextfile To use a Unix-style filter mode, reading from standard input and writing to standard output, add the -f option: pgp -feast her_userid outputfile Legal Issues ============ For detailed information on PGP(tm) licensing, distribution, copyrights, patents, trademarks, liability limitations, and export controls, see the "Legal Issues" section in the "PGP User's Guide, Volume II: Special Topics". PGP uses a public key algorithm claimed by U.S. patent #4,405,829. The exclusive licensing rights to this patent are held by a company called Public Key Partners (PKP), and you may be infringing the patent if you use PGP in the USA without a license. These issues are detailed in the Volume II manual, and in the RSAREF license that comes with the freeware version of PGP. PKP has licensed others to practice the patent, including a company known as ViaCrypt, in Phoenix, Arizona. ViaCrypt sells a fully licensed version of PGP. ViaCrypt may be reached at 602-944-0773. PGP is "guerrilla" freeware, and I don't mind if you distribute it widely. Just don't ask me to send you a copy. Instead, you can look for it yourself on many BBS systems and a number of Internet FTP sites. But before you distribute PGP, it is essential that you understand the U.S. export controls on encryption software. Acknowledgments ================ Formidable obstacles and powerful forces have been arrayed to stop PGP. Dedicated people are helping to overcome these obstacles. PGP has achieved notoriety as "underground software", and bringing PGP "above ground" as fully licensed freeware has required patience and persistence. I'd especially like to thank Hal Abelson, Jeff Schiller, Brian LaMacchia, and Derek Atkins at MIT for their determined efforts. I'd also like to thank Jim Bruce and David Litster in the MIT administration and Bob Prior and Terry Ehling at the MIT Press. And I'd like to thank my entire legal defense team, whose job is not over yet. I used to tell a lot of lawyer jokes, before I encountered so many positive examples of lawyers in my legal defense team, most of whom work pro bono. The development of PGP has turned into a remarkable social phenomenon, whose unique political appeal has inspired the collective efforts of an ever-growing number of volunteer programmers. Remember that children's story called "Stone Soup"? I'd like to thank the following people for their contributions to the creation of Pretty Good Privacy. Although I was the author of PGP version 1.0, major parts of later versions of PGP were implemented by an international collaborative effort involving a large number of contributors, under my design guidance. Branko Lankester, Hal Finney and Peter Gutmann all contributed a huge amount of time in adding features for PGP 2.0, and ported it to Unix variants. Hugh Kennedy ported it to VAX/VMS, Lutz Frank ported it to the Atari ST, and Cor Bosman and Colin Plumb ported it to the Commodore Amiga. Translation of PGP into foreign languages was done by Jean-loup Gailly in France, Armando Ramos in Spain, Felipe Rodriquez Svensson and Branko Lankester in The Netherlands, Miguel Angel Gallardo in Spain, Hugh Kennedy and Lutz Frank in Germany, David Vincenzetti in Italy, Harry Bush and Maris Gabalins in Latvia, Zygimantas Cepaitis in Lithuania, Peter Suchkow and Andrew Chernov in Russia, and Alexander Smishlajev in Esperantujo. Peter Gutmann offered to translate it into New Zealand English, but we finally decided PGP could get by with US English. Jean-loup Gailly, Mark Adler, and Richard B. Wales published the ZIP compression code, and granted permission for inclusion into PGP. The MD5 routines were developed and placed in the public domain by Ron Rivest. The IDEA(tm) cipher was developed by Xuejia Lai and James L. Massey at ETH in Zurich, and is used in PGP with permission from Ascom-Tech AG. Charlie Merritt originally taught me how to do decent multiprecision arithmetic for public key cryptography, and Jimmy Upton contributed a faster multiply/modulo algorithm. Thad Smith implemented an even faster modmult algorithm. Zhahai Stewart contributed a lot of useful ideas on PGP file formats and other stuff, including having more than one user ID for a key. I heard the idea of introducers from Whit Diffie. Kelly Goen did most of the work for the initial electronic publication of PGP 1.0. Various contributions of coding effort also came from Colin Plumb, Derek Atkins, and Castor Fu. Other contributions of effort, coding or otherwise, have come from Hugh Miller, Eric Hughes, Tim May, Stephan Neuhaus, and too many others for me to remember right now. Zbigniew Fiedorwicz did the first Macintosh port. Since the release of PGP 2.0, many other programmers have sent in patches and bug fixes and porting adjustments for other computers. There are too many to individually thank here. Just as in the "Stone Soup" story, it is getting harder to peer through the thick soup to see the stone at the bottom of the pot that I dropped in to start it all off. About the Author ================ Philip Zimmermann is a software engineer consultant with 19 years experience, specializing in embedded real-time systems, cryptography, authentication, and data communications. Experience includes design and implementation of authentication systems for financial information networks, network data security, key management protocols, embedded real-time multitasking executives, operating systems, and local area networks. Custom versions of cryptography and authentication products and public key implementations such as the NIST DSS are available from Zimmermann, as well as custom product development services. His consulting firm's address is: Boulder Software Engineering 3021 Eleventh Street Boulder, Colorado 80304 USA Phone: 303-541-0140 (10:00am - 7:00pm Mountain Time) Fax: arrange by phone Internet: prz@acm.org user interface), porting to the Mac was ndoc/pgformat.doc1004440006630000000000010724605567503340011056 037777703401 1 0 File Formats Used by PGP 2.6 (22 May 94) ======================================== ***Note: packets that contain a version byte of 2 will contain a version byte of 3 when using versions of PGP >= 2.6 after 9/1/94. This appendix describes the file formats used externally by Pretty Good Privacy (PGP), the RSA public key cryptography application. The intended audience includes software engineers trying to port PGP to other hardware environments or trying to implement other PGP- compatible cryptography products, or anyone else who is curious. [To be included: a description of ASCII armor. An ASCII armored file is just like a binary file described here, but with an extra layer of encoding added, framing lines, and a 24-bit CRC at the end.] Byte Order ---------- All integer data used by PGP is externally stored most significant byte (MSB) first, regardless of the byte order used internally by the host CPU architecture. This is for portability of messages and keys between hosts. This covers multiprecision RSA integers, bit count prefix fields, byte count prefix fields, checksums, key IDs, and timestamps. The MSB-first byte order for external packet representation was chosen only because many other crypto standards use it. Multiprecision Integers ----------------------- RSA arithmetic involves a lot of multiprecision integers, often having hundreds of bits of precision. PGP externally stores a multiprecision integer (MPI) with a 16-bit prefix that gives the number of significant bits in the integer that follows. The integer that follows this bitcount field is stored in the usual byte order, with the MSB padded with zero bits if the bitcount is not a multiple of 8. The bitcount always specifies the exact number of significant bits. For example, the integer value 5 would be stored as these three bytes: 00 03 05 An MPI with a value of zero is simply stored with the 16-bit bitcount prefix field containing a 0, with no value bytes following it. Key ID ------ Some packets use a "key ID" field. The key ID is the least significant 64 bits of the RSA public modulus that was involved in creating the packet. For all practical purposes it unique to each RSA public key. User ID ------- Some packets contain a "user ID", which is an ASCII string that contains the user's name. Unlike a C string, the user ID has a length byte at the beginning that has a byte count of the rest of the string. This length byte does not include itself in the count. Timestamp --------- Some packets contain a timestamp, which is a 32-bit unsigned integer of the number of seconds elapsed since 1970 Jan 1 00:00:00 GMT. This is the standard format used by Unix timestamps. It spans 136 years. Cipher Type Byte (CTB) ---------------------- Many of these data structures begin with a Cipher Type Byte (CTB), which specifies the type of data structure that follows it. The CTB bit fields have the following meaning (bit 0 is the LSB, bit 7 is the MSB): Bit 7: Always 1, which designates this as a CTB Bit 6: Reserved. Bits 5-2: CTB type field, specifies type of packet that follows 0001 - public-key-encrypted packet 0010 - secret-key-encrypted (signature) packet 0101 - Secret key certificate 0110 - Public key certificate 1000 - Compressed data packet 1001 - Conventional-Key-Encrypted data 1011 - Raw literal plaintext data, with filename and mode 1100 - Keyring trust packet 1101 - User ID packet, associated with public or secret key 1110 - Comment packet Other CTB packet types are unimplemented. Bits 1-0: Length-of-length field: 00 - 1 byte packet length field follows CTB 01 - 2 byte packet length field follows CTB 10 - 4 byte packet length field follows CTB 11 - no length field follows CTB, unknown packet length. The 8-, 16-, or 32-bit packet length field after the CTB gives the length in bytes of the rest of the packet, not counting the CTB and the packet length field. RSA public-key-encrypted packet ------------------------------- Offset Length Meaning 0 1 CTB for RSA public-key-encrypted packet 1 2 16-bit (or maybe 8-bit) length of packet 3 1 Version byte (=2). May affect rest of fields that follow. 4 8 64-bit Key ID 12 1 Algorithm byte for RSA (=1 for RSA). --Algorithm byte affects field definitions that follow. 13 ? RSA-encrypted integer, encrypted conventional key packet. (MPI with bitcount prefix) The conventionally-encrypted ciphertext packet begins right after the RSA public-key-encrypted packet that contains the conventional key. Signature packet ---------------- Offset Length Meaning 0 1 CTB for secret-key-encrypted (signed) packet 1 2 16-bit (or maybe 8-bit) length of packet 3 1 Version byte (=2). May affect rest of fields that follow. Version byte (=3) for >= PGP2.6 after 9/1/94 4 1 Length of following material that is implicitly included in MD calculation (=5). 5 1 Signature classification field (see below). Implicitly append this to message for MD calculation. 6 4 32-bit timestamp of when signature was made. Implicitly append this to message for MD calculation. 10 8 64-bit Key ID 18 1 Algorithm byte for public key scheme (RSA=0x01). --Algorithm byte affects field definitions that follow. 19 1 Algorithm byte for message digest (MD5=0x01). 20 2 First 2 bytes of the Message Digest inside the RSA-encrypted integer, to help us figure out if we used the right RSA key to check the signature. 22 ? RSA-encrypted integer, encrypted message digest (MPI with bitcount prefix). If the plaintext that was signed is included in the same file as the signature packet, it begins right after the RSA secret-key-signed packet that contains the message digest. The plaintext has a "literal" CTB prefix. The original idea had a variable length field following the length of following material byte, before the Key ID. In particular, the possibility of a 2-byte validity period was defined, although no previous version of PGP ever generated those bytes. Owing to the way the MD5 is computed for the signature, if that field is variable length, it is possible to generate two different messages with the same MD5 hash. One would be a file of length N, with a 7-byte following section consisting of a signature type byte, 4 bytes of timestamp, and 2 of validity period, while the other would be a file of length N+2, whose last two bytes would be the siganture type byte and the first byte of timestamp, and the last three bytes of timestamp and the validity period would instead be interpreted as a signature type byte and a timestmap. It should be emphasized that the messages are barely different and special circumstances must arise for this to be possible, so it is extremely unlilely that this would be exploitable, but it is a potential weakness. It has been plugged by allowing only the currently implemented 5-byte option. Validity periods will be added later with a different format. The signature classification field describes what kind of signature certificate this is. There are various hex values: 00 - Signature of a message or document, binary image. 01 - Signature of a message or document, canonical text. 10 - Key certification, generic. Only version of key certification supported by PGP 2.5. Material signed is public key pkt and User ID pkt. 11 - Key certification, persona. No attempt made at all to identify the user with a real name. Material signed is public key pkt and User ID pkt. 12 - Key certification, casual identification. Some casual attempt made to identify user with his name. Material signed is public key pkt and User ID pkt. 13 - Key certification, positive ID. Heavy-duty identification efforts, photo ID, direct contact with personal friend, etc. Material signed is public key pkt and User ID pkt. 20 - Key compromise. User signs his own compromise certificate. Independent of user ID associations. Material signed is public key pkt ONLY. 30 - Key/userid revocation. User can sign his own revocation to dissolve an association between a key and a user ID, or certifier may revoke his previous certification of this key/userid pair. Material signed is public key pkt and User ID pkt. 40 - Timestamping a signature certificate made by someone else. Can be used to apply trusted timestamp, and log it in notary's log. Signature of a signature. (Planned, not implemented.) When a signature is made to certify a key/UserID pair, it is computed across two packets-- the public key packet, and the separate User ID packet. See below. The packet headers (CTB and length fields) for the public key packet and the user ID packet are both omitted from the signature calculation for a key certification. A key compromise certificate may be issued by someone to revoke his own key when his secret key is known to be compromised. If that happens, a user would sign his own key compromise certificate with the very key that is being revoked. A key revoked by its own signature means that this key should never be used or trusted again, in any form, associated with any user ID. A key compromise certificate issued by the keyholder shall take precedence over any other key certifications made by anyone else for that key. A key compromise signed by someone other than the key holder is invalid. Note that a key compromise certificate just includes the key packet in its signature calculation, because it kills the whole key without regard to any userid associations. It isn't tied to any particular userid association. It should be inserted after the key packet, before the first userid packet. When a key compromise certificate is submitted to PGP, PGP will place it on the public keyring. A key compromise certificate is always accompanied in its travels by the public key and userIDs it affects. If the affected key is NOT already on the keyring, the compromise certificate (and its key and user ID) is merely added to the keyring anywhere. If the affected key IS already on the keyring, the compromise certificate is inserted after the affected key packet. This assumes that the actual key packet is identical to the one already on the key ring, so no duplicate key packet is needed. If a key has been revoked, PGP will not allow its use to encipher any messages, and if an incoming signature uses it, PGP will display a stern warning that this key has been revoked. NOTE: Key/userid revocation certificates ARE NOT SUPPORTED in this version of PGP. But if we ever get around to supporting them, here are some ideas on how they should work... A key/userid revocation certificate may be issued by someone to dissolve the association between his own key and a user ID. He would sign it with the very key that is being revoked. A key/userid revocation certificate issued by the keyholder shall take precedence over any other key certifications made by anyone else for that key/userid pair. Also, a third party certifier may revoke his own previous certification of this key/userid pair by issuing a key/userid revocation certificate. Such a revocation should not affect the certifications by other third parties for this same key/userid pair. When a key/userid revocation certificate is submitted to PGP, PGP will place it on the public keyring. A key/userid revocation certificate is always accompanied in its travels by the public key it affects (the key packet and user ID packet precedes the revocation certificate). If the affected key is NOT already on the keyring, the revocation certificate (and its key and user ID) is merely added to the keyring anywhere. If the affected key IS already on the keyring, the revocation certificate is integrated in with the key's other certificates as though it were just another key certification. This assumes that the actual key packet is identical to the one already on the key ring, so no duplicate key packet is needed. Message digest "packet" ----------------------- The Message digest has no CTB packet framing. It is stored packetless and naked, with padding, encrypted inside the MPI in the Signature packet. PGP versions 2.3 and later use a new format for encoding the message digest into the MPI in the signature packet, a format which is compatible with RFC1425 (formerly RFC1115). This format is accepted but not written by version 2.2. The older format used by versions 2.2 is acepted by versions up to 2.4, but the RSAREF code in 2.5 is not capable of parsing it. PGP versions 2.2 and earlier encode the MD into the MPI as follows: MSB . . . LSB 0 1 MD(16 bytes) 0 FF(n bytes) 1 Enough bytes of FF padding are added to make the length of this whole string equal to the number of bytes in the modulus. PGP versions 2.3 and later encode the MD into the MPI as follows: MSB . . . LSB 0 1 FF(n bytes) 0 ASN(18 bytes) MD(16 bytes) See RFC1423 for an explanation of the meaning of the ASN string. It is the following 18 byte long hex value: 3020300c06082a864886f70d020505000410 Enough bytes of FF padding are added to make the length of this whole string equal to the number of bytes in the modulus. All this mainly affects the rsa_private_encrypt() and rsa_public_decrypt() functions in rsaglue.c. There is no checksum included. The padding serves to verify that the correct RSA key was used. Conventional Data Encryption Key (DEK) "packet" ----------------------------------------------- The DEK has no CTB packet framing. The DEK is stored packetless and naked, with padding, encrypted inside the MPI in the RSA public-key-encrypted packet. PGP versions 2.3 and later use a new format for encoding the message digest into the MPI in the signature packet. (This format is not presently based on any RFCs due to the use of the IDEA encryption system.) This format is accepted but not written by version 2.2. The older format used by versions 2.2 and earlier is also accepted by versions up to 2.4, but the RSAREF code in 2.5 is unable to cope with it. PGP versions 2.2 and earlier encode the MD into the MPI as follows: MSB . . . LSB 0 1 DEK(16 bytes) CSUM(2 bytes) 0 RND(n bytes) 2 CSUM refers to a 16-bit checksum appended to the high end of the DEK. RND is a string of NONZERO pseudorandom bytes, enough to make the length of this whole string equal to the number of bytes in the modulus. PGP versions 2.3 and later encode the MD into the MPI as follows: MSB . . . LSB 0 2 RND(n bytes) 0 1 DEK(16 bytes) CSUM(2 bytes) CSUM refers to a 16-bit checksum appended to the high end of the DEK. RND is a string of NONZERO pseudorandom bytes, enough to make the length of this whole string equal to the number of bytes in the modulus. For both versions, the 16-bit checksum is computed on the rest of the bytes in the DEK key material, and does not include any other material in the calculation. In the above MSB-first representation, the checksum is also stored MSB-first. The checksum is there to help us determine if we used the right RSA secret key for decryption. All this mainly affects the rsa_public_encrypt() and rsa_private_decrypt() functions in rsaglue.c. Conventional Key Encrypted data packet -------------------------------------- Offset Length Meaning 0 1 CTB for Conventional-Key-Encrypted data packet 1 4 32-bit (or maybe 16-bit) length of packet 5 ? conventionally-encrypted data. plaintext has 64 bits of random data prepended, plus 16 bits prepended for "key check" purposes The decrypted ciphertext may contain a compressed data packet or a literal plaintext packet. After decrypting the conventionally-encrypted data, a special 8-byte random prefix and 2 "key check" bytes are revealed. The random prefix and key check prefix are inserted before encryption and discarded after decryption. This prefix group is visible after decrypting the ciphertext in the packet. The random prefix serves to start off the cipher feedback chaining process with 64 bits of random material. It may be discarded after decryption. The first 8 bytes is the random prefix material, followed by the 2-byte "key-check" prefix. The key-check prefix is composed of two identical copies of the last 2 random bytes in the random prefix, in the same order. During decryption, the 9th and 10th bytes of decrypted plaintext are checked to see if they match the 7th and 8th bytes, respectively. If these key-check bytes meet this criterion, then the conventional key is assumed to be correct. One unusual point about the way encryption is done. Using the IDEA cipher in CFB mode, the first 10 bytes are decrypted normally, but bytes 10 to 17, the first 8 bytes of the data proper, are encrypted using bytes 2 to 9 (the last 8 bytes of the key check prefix) as the IV. This is essentially using CFB-16 for one part of the encryption, while CFB-64 is used elsewhere. Compressed data packet ---------------------- Offset Length Meaning 0 1 CTB for Compressed data packet 1 1 Compression algorithm selector byte (1=ZIP) 2 ? compressed data The compressed data begins right after the algorithm selector byte. The compressed data may decompress into a raw literal plaintext data packet with its own CTB. Currently, compressed data packets are always the last ones in their enclosing object, and the decompressor knows when to stop, so the length field is omitted. The low two bits of the CTB are set to 11. This is the only case in PGP where this is currently done. Literal data packet, with filename and mode ------------------------------------------- Offset Length Meaning 0 1 CTB for raw literal data packet 1 4 32-bit (or maybe 16-bit) length of packet 5 1 mode byte, 'b'= binary or 't'= canonical text 6 ? filename, with leading string length byte ? 4 Timestamp of last-modified date, or 0, or right now ? ? raw literal plaintext data The timestamp may be have to be derived in a system dependent manner. ANSI C functions should be used to get it if available, otherwise store the current time in it. Or maybe store 0 if it's somehow not applicable. Whne calculating a signature on a literal packet, the signature calculation only includes the raw literal plaintext data that begins AFTER the header fields in the literal packet-- after the CTB, the length, the mode byte, the filename, and the timestamp. The reason for this is to guarantee that detached signatures are exactly the same as attached signatures prefixed to the message. Detached signatures are calculated on a separate file that has no packet encapsulation. Comment packet -------------- A comment packet is generally just skipped over by PGP, although it may be displayed to the user when processed. It can be put in a keyring, or anywhere else. Offset Length Meaning 0 1 CTB for Comment packet 1 1 8-bit length of packet 2 ? ASCII comment, size is as in preceding length byte Comment packets are currently not generated by PGP. Secret key certificate ---------------------- Offset Length Meaning 0 1 CTB for secret key certificate 1 2 16-bit (or maybe 8-bit) length of packet 3 1 Version byte (=2). May affect rest of fields that follow. Version byte (=3) for >= PGP2.6 after 9/1/94 4 4 Timestamp 8 2 Validity period, in number of DAYS (0 means forever) 10 1 Algorithm byte for RSA (=1 for RSA). --Algorithm byte affects field definitions that follow. ? ? MPI of RSA public modulus n ? ? MPI of RSA public encryption exponent e ? 1 Algorithm byte for cipher that protects following secret components (0=unencrypted, 1=IDEA cipher) ? 8 Cipher Feedback IV for cipher that protects secret components (not present if unencrypted) ? ? MPI of RSA secret decryption exponent d ? ? MPI of RSA secret factor p ? ? MPI of RSA secret factor q ? ? MPI of RSA secret multiplicative inverse u (All MPI's have bitcount prefixes) ? 2 16-bit checksum of all preceding secret component bytes All secret fields in the secret key certificate may be password- encrypted, including the checksum. The checksum is calculated from all of the bytes of the unenciphered secret components. The public fields are not encrypted. The encrypted fields are done in CFB mode, and the checksum is used to tell if the password was good. The CFB IV field is just encrypted random data, assuming the "true" IV was zero. NOTE: The secret key packet does not contain a User ID field. The User ID is enclosed in a separate packet that always follows the secret key packet on a keyring or in any other context. Public key certificate ---------------------- Offset Length Meaning 0 1 CTB for public key certificate 1 2 16-bit (or maybe 8-bit) length of packet 3 1 Version byte (=2). May affect rest of fields that follow. Version byte (=3) for >= PGP2.6 after 9/1/94 4 4 Timestamp of key creation 8 2 Validity period, in number of DAYS (0 means forever) 10 1 Algorithm byte for RSA (=1 for RSA). --Algorithm byte affects field definitions that follow. ? ? MPI of RSA public modulus n ? ? MPI of RSA public encryption exponent e (All MPI's have bitcount prefixes) NOTE: The public key packet does not contain a User ID field. The User ID is enclosed in a separate packet that always follows somewhere after the public key packet on a keyring or in any other context. The validity period is currently always set to 0. User ID packet -------------- Offset Length Meaning 0 1 CTB for User ID packet 1 1 8-bit length of packet 2 ? User ID string, size is as in preceding length byte The User ID packet follows a public key on a public key ring. It also follows a secret key on a secret key ring. When a key is certified by a signature, the signature covers both the public key packet and the User ID packet. The signature certificate thereby logically "binds" together the user ID with the key. The user ID packet is always associated with the most recently occurring public key on the key ring, regardless of whether there are other packet types appearing between the public key packet and the associated user ID packet. There may be more than one User ID packet after a public key packet. They all would be associated with the preceding public key packet. Keyring trust packet -------------------- The three different forms of this packet each come after: a public key packet, a user ID packet, or a signature packet on the public key ring. They exist only on a public key ring, and are never extracted with a key. Don't copy this separate trust byte packet from keyring, and do add it in back in when adding to keyring. The meaning of the keyring trust packet is context sensitive. The trust byte has three different definitions depending on whether it follows a key packet on the ring, or follows a user ID packet on the ring, or follows a signature on the ring. Offset Length Meaning 0 1 CTB for Keyring trust packet 1 1 8-bit length of packet (always 1 for now) 2 1 Trust flag byte, with context-sensitive bit definitions given below. For trust bytes that apply to the preceding key packet, the following bit definitions apply: Bits 0-2 - OWNERTRUST bits - Trust bits for this key owner. Values are: 000 - undefined, or uninitialized trust. 001 - unknown, we don't know the owner of this key. 010 - We usually do not trust this key owner to sign other keys. 011 - reserved 100 - reserved 101 - We usually do trust this key owner to sign other keys. 110 - We always trust this key owner to sign other keys. 111 - This key is also present in the secret keyring. Bits 3-4 - Reserved. Bit 5 - DISABLED bit - Means that this key is disabled, and should not be used. Bit 6 - Reserved Bit 7 - BUCKSTOP bit - Means this key also appears in secret key ring. Signifies the ultimately-trusted "keyring owner". "The buck stops here". This bit computed from looking at secret key ring. If this bit is set, then all the KEYLEGIT fields are set to maximum for all the user IDs for this key, and OWNERTRUST is also set to ultimate trust. For trust bytes that apply to the preceding user ID packet, the following bit definitions apply: Bit 0-1 - KEYLEGIT bits - Validity bits for this key. Set if we believe the preceding key is legitimately owned by who it appears to belong to, specified by the preceding user ID. Computed from various signature trust packets that follow. Also, always fully set if BUCKSTOP is set. To define the KEYLEGIT byte does not require that OWNERTRUST be nonzero, but OWNERTRUST nonzero does require that KEYLEGIT be fully set to maximum trust. 00 - unknown, undefined, or uninitialized trust. 01 - We do not trust this key's ownership. 10 - We have marginal confidence of this key's ownership. Totally useless for certifying other keys, but may be useful for checking message signatures with an advisory warning to the user. 11 - We completely trust this key's ownership. This requires either: - 1 ultimately trusted signature (a signature from yourself, SIGTRUST=111) - COMPLETES_NEEDED completely trusted signatures (SIGTRUST=110) - MARGINALS_NEEDED marginally trusted signatures (SIGTRUST=101) COMPLETES_NEEDED and MARGINALS_NEEDED are configurable constants. Bit 7 - WARNONLY bit - If the user wants to use a not fully validated key for encryption, he is asked if he really wants to use this key. If the user answers 'yes', the WARNONLY bit gets set, and the next time he uses this key, only a warning will be printed. This bit gets cleared during the maintenance pass. For a trust byte that applies to the preceding signature, the following bit definitions apply: Bits 0-2 - SIGTRUST bits - Trust bits for this signature. Value is copied directly from OWNERTRUST bits of signer: 000 - undefined, or uninitialized trust. 001 - unknown 010 - We do not trust this signature. 011 - reserved 100 - reserved 101 - We reasonably trust this signature. 110 - We completely trust this signature. 111 - ultimately trusted signature (from the owner of the ring) Bits 3-6 - Reserved. Bit 6 - CHECKED bit - This means that the key checking pass (pgp -kc, also invoked automatically whenever keys are added to the keyring) has tested this signature and found it good. If this bit is not set, the maintenance pass considers this signature untrustworthy. Bit 7 - CONTIG bit - Means this signature leads up a contiguous trusted certification path all the way back to the ultimately- trusted keyring owner, where the buck stops. This bit is derived from other trust packets. It is currently not used for anything in PGP. The OWNERTRUST bits are set by the user. PGP does not modify them. PGP computes the BUCKSTOP bit by checking to see if the key is on the secret key ring. If it is, it was created by this user, and thus controlled by him. All other trust is derived from the BUCKSTOP keys in a special maintenance pass over the keyring. Any good signature made by a given key has its SIGTRUST equal to the key's OWNERTRUST. Based on COMPLETES_NEEDED and MARGINALS_NEEDED, if enough trusted signatures are on a key/userID pair, the key/userid association is considered legitimate. To be precise, an ultimately trusted key has weight 1, a completely trusted key has weight 1/COMPLETES_NEEDED (or 0 if COMPLETES_NEEDED is 0), and a marginally trsuted key has weight 1/MARGINALS_NEEDED. Other trust values have weight 0. If the total weight of the signatures on a key/userid pair is 1 or more, the userid is considered legitimate. When a key has a legitimate userid, the user is asked to set the OWNERTRUST for the corresponding key. Ths idea is that the userid identifies someone the user knows, at least by reputation, so once it has been established who holds the secret key, that person's trustworthiness as an introducer can be established and assigned to the key. Once that is done, the key's signatures then have weight establishing other key/userid associations. There is a limit to the depth to which this can go. Keys on the secret keyring are at depth 0. Keys signed by those keys are at depth 1. Keys which are fully certified using only signatures from keys at depth 1 or less are at depth 2. Keys which are fully certified using only signatures from keys at depth 2 or less are at depth 3, and so on. If you know all of your trusted introducers personally, and have signed their keys, then you will never have a key at a depth of greater than 2. The maximum depth is limited my MAX_CERT_DPETH. It never gets very large in a well-connected "web of trust". This redundant and decentralized method of determining public key legitimacy is one of the principal strengths of PGP's key management architecture, as compared with PEM, when used in social structures that are not miltiary-style rigid hierarchies. The trust of a key owner (OWNERTRUST) does not just reflect our estimation of their personal integrity, it also reflects how competent we think they are at understanding key management and using good judgement in signing keys. The OWNERTRUST bits are not computed from anything -- it requires asking the user for his opinion. To define the OWNERTRUST bits for a key owner, ask: Would you always trust "Oliver North" to certify other public keys? (1=Yes, 2=No, 3=Usually, 4=I don't know) ? _ When a key is added to the key ring the trust bytes are initialized to zero (undefined). [--manual setting of SIGTRUST/OWNERTRUST not implemented] Normally, we derive the value of the SIGTRUST field by copying it directly from the signer key's OWNERTRUST field. Under special circumstances, if the user explicitly requests it with a special PGP command, we may let the user override the copied value for SIGTRUST by displaying an advisory to him and asking him for ratification, like so: This key is signed by "Oliver North", whom you usually trust to sign keys. Do you trust "Oliver North" to certify the key for "Daniel Ellsberg"? (1=Yes, 2=No, 3=Somewhat, 4=I don't know) ? _ Or: This key is signed by "Oliver North", whom you usually do not trust to sign keys. Do you trust "Oliver North" to certify the key for "Daniel Ellsberg"? (1=Yes, 2=No, 3=Somewhat, 4=I don't know) ? _ An "I don't know" response to this question would have the same effect as a response of "no". If we had no information about the trustworthiness of the signer (the OWNERTRUST field was uninitialized), we would leave the advisory note off. Certifying a public key is a serious matter, essentially promising to the world that you vouch for this key's ownership. But sometimes I just want to make a "working assumption" of trust for someone's public key, for my own purposes on my own keyring, without taking the serious step of actually certifying it for the rest of the world. In that case, we can use a special PGP keyring management command to manually set the KEYLEGIT field, without relying on it being computed during a maintenance pass. Later, if a maintenance pass discovers a KEYLEGIT bit set that would not have been otherwise computed as set by the maintenance pass logic, it alerts me and asks me to confirm that I really want it set. [--end of not implemented section] During routine use of the public keyring, we don't actually check the associated signatures certifying a public key. Rather, we always rely on trust bytes to tell us whether to trust the key in question. We depend on a separate checking pass (pgp -kc) to actually check the key signature certificates against the associated keys, and to set the trust bytes accordingly. This pass checks signatures, and if a signature fails to verify, obnoxiously alerts the user and drops it from the key ring. Then it tuns a maintenance pass to calculate the ring-wide effects of this. A failed signature should be exceedingly rare, and it may not even result in a KEYLEGIT field being downgraded. Having several signatures certifying each key should prevent damage from spreading too far from a failed certificate. But if dominoes do keep falling from this, it may indicate the discovery of an important elaborate attack. The maintenance pass is run every time the keyring changes, and operates in a top-of-pyramid-down manner as follows. If at any time during any of these steps the KEYLEGIT field goes from not fully set to fully set, and the OWNERTRUST bits are still undefined, the user is asked a question to define the OWNERTRUST bits. First, for all keys with BUCKSTOP set, check if they are really present in the secret keyring, if not, the BUCKSTOP bit is cleared. SIGTRUST and KEYLEGIT is initialized to zero for non-buckstop keys. The real maintenance pass is done in a recursive scan: Start with BUCKSTOP keys, find all userid/key pairs signed by a key and update the trust value of these signatures by copying the OWNERTRUST of the signer to the SIGTRUST of the signature. If this makes a key fully validated, start looking for signatures made by this key, and update the trust value for them. Repeat until everything has settled down. Public Key Ring Overall Structure ================================= A public key ring is comprised of a series of public key packets, keyring trust packets, user ID packets, and signature certificates. Here is an example of an ordered collection of packets on a ring: -------------------------------------------------------------------- Public key packet Keyring trust packet for preceding key User ID packet for preceding key Keyring trust packet for preceding user ID/key association Signature certificate to bind preceding User ID and key pkt Keyring trust packet for preceding signature certificate Signature certificate to bind preceding User ID and key pkt Keyring trust packet for preceding signature certificate Signature certificate to bind preceding User ID and key pkt Keyring trust packet for preceding signature certificate Public key packet Keyring trust packet for preceding key User ID packet for preceding key Keyring trust packet for preceding user ID/key association Signature certificate to bind preceding User ID and key pkt Keyring trust packet for preceding signature certificate User ID packet for preceding key Keyring trust packet for preceding user ID/key association Signature certificate to bind preceding User ID and key pkt Keyring trust packet for preceding signature certificate Signature certificate to bind preceding User ID and key pkt Keyring trust packet for preceding signature certificate Public key packet Keyring trust packet for preceding key Compromise certificate for preceding key User ID packet for preceding key Keyring trust packet for preceding user ID/key association Signature certificate to bind preceding User ID and key pkt Keyring trust packet for preceding signature certificate -------------------------------------------------------------------- trusted signatures (SIGTRUST=110) - MARGINALS_NEEDED marginally trusted signatures (SIGTRUST=101) COMPLETES_NEEDED and MARGINALS_NEEDED are configurable constants. Bit 7 - WARNONLY bit - If the user wants to use a not fully validated key for encryption, he is asked if he really wants to use this key. If the user answers 'doc/pgp.11004440006630000000000004744405567505051007424 037777703401 1 0 .TH PGP 1 "PGP Version 2.6" .\" NAME should be all caps, SECTION should be 1-8, maybe w/ subsection .\" other parms are allowed: see man(7), man(1) .SH NAME pgp \- Pretty Good Privacy encryption system .\" denote multiple entry points thus; makewhatis(8) will catch them .SH SYNOPSIS .B pgp \fR[\fIoptions\fR] \fIpgpfile .PP .B pgp \-e \fR[\fIoptions\fR] \fIfile user\fR .\|.\|. .PP .SH DESCRIPTION .B PGP (Pretty Good Privacy) is a public key encryption package to protect E-mail and data files. It lets you communicate securely with people you've never met, with no secure channels needed for prior exchange of keys. It's well featured and fast, with sophisticated key management, digital signatures, data compression, and good ergonomic design. If you really want to learn how to use it properly, it's best to read the full documentation that comes with the system, which is very complete. This is a "quick start" guide and reference manual; it is necessarily incomplete, and assumes you are already familiar with most of the basic concepts, including the concepts behind public key cryptography. .SS "Terminology" .B user id\fR: an ascii string used to identify a user. User IDs tend to look like "John Q. Public "; please try sticking to that format. When giving a user id to PGP, you may specify any unique (case-insensitive) substring. E.g. john, or jqp@xyz. .B pass phrase\fR: the secret string used to conventionally encipher your private key. It's important that this be kept secret. .B keyring\fR: a file containing a set of public or secret keys. Default names for public and secret rings are "pubring.pgp" and "secring.pgp" respectively. .B ascii armor\fR: the ascii radix 64 format PGP uses for transmitting messages over channels like E-Mail; similar in concept to uuencoding. .SS "Command summary" To see a quick command usage summary for PGP, just type: .br .B pgp -h To encrypt a plaintext file with the recipient's public key: .br .B pgp -e \fItextfile her_userid \fR... To sign a plaintext file with your secret key: .br .B pgp -s \fItextfile \fR[\fB-u \fIyour_userid\fR] To sign a plaintext file with your secret key, and then encrypt it with the recipient's public key: .br .B pgp -es \fItextfile her_userid \fR... [\fB-u \fIyour_userid\fR] To create a signature certificate that is detached from the document: .br .B pgp -sb \fItextfile \fR[\fB-u \fIyour_userid\fR] To encrypt a plaintext file with just conventional cryptography, type: .br .B pgp -c \fItextfile To decrypt an encrypted file, or to check the signature integrity of a signed file: .br .B pgp \fIciphertextfile \fR[\fB-o \fIplaintextfile\fR] To see a quick summary of PGP's key-management commands, just type: .br .B pgp -k To generate your own unique public/secret key pair: .br .B pgp -kg To add a public or secret key file's contents to your public or secret key ring: .br .B pgp -ka \fIkeyfile \fR[\fIkeyring\fR] To remove a key from your public key ring: .br .B pgp -kr \fIuserid \fR[\fIkeyring\fR] To extract (copy) a key from your public or secret key ring: .br .B pgp -kx\fR[\fBa\fR] \fIuserid keyfile \fR[\fIkeyring\fR] To view the contents of your public key ring: .br .B pgp -kv\fR[\fBv\fR] [\fIuserid\fR] [\fIkeyring\fR] To view the "fingerprint" of a public key, to help verify it over the telephone with its owner: .br .B pgp -kvc \fR[\fIuserid\fR] [\fIkeyring\fR] To view the contents and check the certifying signatures of your public key ring: .br .B pgp -kc \fR[\fIuserid\fR] [\fIkeyring\fR] To edit the pass phrase for or add a userid to your secret key: .br .B pgp -ke \fIuserid \fR[\fIkeyring\fR] To edit the trust parameters for a public key: .br .B pgp -ke \fIuserid \fR[\fIkeyring\fR] To remove a key or just a userid from your public key ring: .br .B pgp -kr \fIuserid \fR[\fIkeyring\fR] To sign and certify someone else's public key on your public key ring: .br .B pgp -ks \fIher_userid \fR[\fB-u \fIyour_userid\fR] [\fIkeyring\fR] To remove selected signatures from a userid on a keyring: .br .B pgp -krs \fIuserid \fR[\fIkeyring\fR] Command options that can be used in combination with other command options (sometimes even spelling interesting words): To produce a ciphertext file in ASCII radix-64 format, just add the -a option when encrypting or signing a message or extracting a key: .br .B pgp -sea \fItextfile her_userid .br .B pgp -kxa \fIuserid keyfile \fR[\fIkeyring\fR] To wipe out the plaintext file after producing the ciphertext file, just add the .B -w (wipe) option when encrypting or signing a message: .br .B pgp -sew \fImessage.txt her_userid To specify that a plaintext file contains ASCII text, not binary, and should be converted to recipient's local text line conventions, add the .B -t (text) option to other options: .br .B pgp -seat \fImessage.txt her_userid To view the decrypted plaintext output on your screen (like the Unix-style "more" command), without writing it to a file, use the .B -m (more) option while decrypting: .br .B pgp -m \fIciphertextfile To specify that the recipient's decrypted plaintext will be shown .B only on her screen and cannot be saved to disk, add the .B -m option: .br .B pgp -steam \fImessage.txt her_userid To recover the original plaintext filename while decrypting, add the .B -p option: .br .B pgp -p \fIciphertextfile To use a Unix-style filter mode, reading from standard input and writing to standard output, add the .B -f option: .br .B pgp -feast \fIher_userid \fB<\fIinputfile \fB>\fIoutputfile .SS "The Config File" PGP uses a configuration database that is stored in the file "config.txt"; please see the manual for complete details. Blank lines and lines beginning with "#" are comments. Options take string, numeric, or boolean values. The boolean values are "on" and "off". These options can also be specified on the command line, using a syntax such as .B +armor=on\fR. Keywords can be abbreviated to unique prefixes. Keywords are not case-sensitive. "=on" is assumed for boolean options if nothing is specified. Some highlights: .B MYNAME - Default User ID for .B Making Signatures Default setting: MYNAME = "" The configuration parameter MYNAME specifies the default user ID to use to select the secret key for making signatures. If MYNAME is not defined, the most recent secret key you installed on your secret key ring is used. The user may also override this setting by specifying a user ID on the PGP command line with the .B -u option. .B TEXTMODE - Assuming Plaintext is a .B Text File Default setting: TEXTMODE = off The configuration parameter TEXTMODE is equivalent to the .B -t command line option. If enabled, it causes PGP to assume the plaintext is a text file, not a binary file, and converts it to "canonical text" before encrypting it. Canonical text has a carriage return and a linefeed at the end of each line of text. This mode is automatically turned off if PGP detects that the plaintext file contains 8-bit binary data. Thus, it is safe to leave enabled at all times. .B ARMOR - Enable ASCII Armor Output Default setting: ARMOR = off The configuration parameter ARMOR is equivalent to the .B -a command line option. If enabled, it causes PGP to emit ciphertext or keys in ASCII Radix-64 format suitable for transporting through E-mail channels. Output files are named with the ".asc" extension. If you tend to use PGP mostly for E-mail, it may be a good idea to enable this parameter. .B ARMORLINES - Size of ASCII Armor Multipart Files Default setting: ARMORLINES = 720 For large ASCII armor files, PGP splits them into files named ".asc1", ".asc2", ".asc3", etc. so as not to choke mailers, which typically starts to happen around 50,000 bytes. This specifies the number of (64-byte) lines to place in each file. If set to 0, PGP will not split ASCII armor files. .B CLEARSIG - Enable Clear-Signed Output Default setting: CLEARSIG = on Normally, a signed and ASCII-armored PGP message is gibberish, even though the text is not encrypted. This prevents munging by mailers, but requires PGP to simply read the message. If CLEARSIG is enabled, then when signing and ASCII-armoring a text file, PGP uses a different format that includes the plaintext in human-readable form. Lines beginning with "-" are quoted with "\-\ ". To cope with some of the stupider mailers in the world, lines beginning with "From" are also quoted, and trailing whitespace on lines is stripped. PGP will remove the quoting if you use it to decrypt the message, but the trailing whitespace is not recovered. This is still useful enough to be enabled by default. .B ENCRYPTTOSELF - Add MYNAME to Recipients List Default setting: ENCRYPTTOSELF = off If this is emabled, MYNAME will be implcitly added to the list of recipients for any message you encrypt with a public key. Since in this case, MYNAME is looked up in the public keyring, it is important that it unambiguously specify the right key. .B LANGUAGE - Language To Use Default setting: LANGUAGE = en If you want to use a different language, and translations are in the language.txt file, setting this option will cause PGP's messages to appear in a different language. If a translation for a message is not available, it appears in english. If you look at the supplied language.txt file, the format should be obvious. .B CHARSET - Character Set Default setting: CHARSET = noconv PGP tries to translate all text-mode messages into the ISO Latin-1 alphabet, or the KOI-8 alphabet for cyrillic alphabets. This setting indicates the native character set, so PGP can do the translation. Options are noconv, latin1 or koi8, indicating that no translation should be done; cp850, indicating that IBM PC code page 850 mappings should be used; ascii, indicating that a minimal ASCII subset should be used; and alt_codes, indicating that the IBM PC alt codes should be used for the cyrillic alphabet. .B KEEPBINARY - Preserve Intermediate .pgp File Default setting: KEEPBINARY = off If KEEPBINARY is enabled, then PGP will produce a .pgp file in addition to a .asc file when ASCII armor is enabled. .B TMP - Temporary file directory Default setting: TMP = "" PGP produces temporary files while decrypting a message. This is the directory they are stored in. If not specified in the config file, the environment variable TMP is used, or the current directory. It helps security somewhat if this is not a publicly-readable directory. A local file system is also a good idea. .B COMPRESS - Compress Plaintext Before Encrypting Default setting: COMPRESS = on PGP usually compresses the plaintext before encrypting it, so it will have less to encrypt and the file you send will be smaller. It also makes cryptanalysis harder. This is usually only turned off for debugging purposes. .B PAGER - Select Shell Command to Display Pager Output Default setting: PAGER = "" If set, PGP uses this program to view files when the .B -m option is specified. By default, PGP uses a simple builtin pager. .B SHOWPASS - Echo Pass Phrase During Entry Default setting: SHOWPASS = off If someone is unable to type a long pass phrase reliably without seeing it, this can be turned on, at the cost of security. .B INTERACTIVE - Prompt Before Adding Each Key Default setting: INTERACTIVE = off By default, when given a file containing new keys, PGP asks if you would like to add them to your public key ring. Since adding keys does not imply that you trust them, adding more just wakes up space. If this option is set, PGP asks about each key in a key file. .B VERBOSE - Level of Detail Printed Default setting: VERBOSE = 1 When set to 0, PGP only prints messages that are necessary or indicate an error. When set to 2, PGP prints a significant amount of debugging information describing what it's doing. Values above 2 have no effect. .B PUBRING - Public Key Ring Location Default setting: PUBRING = $PGPPATH/pubring.pgp This is the path name to the public key ring to use. .B SECRING - Secret Key Ring Location Default setting: SECRING = $PGPPATH/secring.pgp This is the path name to the secret key ring to use. .B BAKRING - Backup Secret Key Ring Default setting: BAKRING = "" If this is set, when checking your key ring (\fBpgp -kc\fR), PGP will compare the normal secret key ring against the given backup copy, usually kept on write-protected removable media. This is to protect against wholesale modifications to your key rings in a spoofing attack. .B RANDSEED - Random Number Seed File Default setting: RANDSEED = $PGPPATH/randseed.bin This is the path to a random seed file which is part of PGP's random number generation algorithm, used to generate session keys. While PGP goes to great lengths to use every available source of randomness in generating session keys, this file is part of the process and protecting it from disclosure is desirable. .B COMMENT - ASCII Armor Comment Default setting: COMMENT = "" If set to a non-empty string, the value of this variable is printed in the header of ASCII armor files, preceded by "Comment: ". .B PKCS_COMPAT - PKCS compatibility Default setting: PKCS_COMPAT = 1 This flag is ignored by PGP 2.5; it is always taken as 1. If set to 1, PGP pads message digests and session keys inside RSA-encrypted integers according to RSA Data Security, Inc.'s Public-Key Cryptography Standards. If set to 0, earlier versions of PGP generated an old incompatible formats. Either was accepted. The RSAREF public-key encryption routines used by PGP 2.5 are unable to decode the old formats. There are still many areas of incompatibility with the PKCS; in future, higher values of this flag may enable more compatibility features. .SS "Key certification" PGP employs a system where users specify trusted users who may sign other people's public keys. It is important that you understand how this mechanism works; a full description is in the manual. .B Important\fR: The manual also describes how to generate and send a "key compromise" certificate that tells readers that your private key has been compromised. If your key has been compromised, please read the manual section on key compromise certificates and how to create them; the faster you send out a key compromise certificate, the smaller the window of opportunity for "bad guys" to send forged messages. .SS "Important Hints" PGP automatically tries compressing your input file; there is little point in precompressing input for transmission. PGP "ascii armor" is only needed on the outer transmitted message; as an example, if you are, say, sending a public key to someone else and you are for some reason signing it, simply armor the outer message; it's better to sign the binary form of the key. .SS "Foreign Languages" PGP is easily customized for foreign language help and error messages; it has been translated into a number of non-english languages. See the manual for details on the file "language.txt". .SH ENVIRONMENT PGP uses several special files for its purposes, such as your standard key ring files "pubring.pgp" and "secring.pgp", the random number seed file "randseed.bin", the PGP configuration file "config.txt", and the foreign language string translation file "language.txt". These special files can be kept in any directory, by setting the environment variable "PGPPATH" to the desired pathname. If PGPPATH remains undefined, these special files are assumed to be in the current directory. Normally, PGP prompts the user to type a pass phrase whenever PGP needs a pass phrase to unlock a secret key. But it is possible to store the pass phrase in an environment variable from your operating system's command shell. The environment variable PGPPASS can be used to hold the pass phrase that PGP attempts to use first. If the pass phrase stored in PGPPASS is incorrect, PGP recovers by prompting the user for the correct pass phrase. This dangerous feature makes your life more convenient if you have to regularly deal with a large number of incoming messages addressed to your secret key, by eliminating the need for you to repeatedly type in your pass phrase every time you run PGP. .B This is a very dangerous feature\fR; on UNIX it is trivial to read someone else's environment using the ps(1) command. If you are contemplating using this feature, be sure to read the sections "How to Protect Secret Keys from Disclosure" and "Exposure on Multi-user Systems" in the full PGP manual. If the environment variable PGPPASSFD is defined, it must have a numeric value, which PGP uses as a file descriptor number to read a pass phrase from. This is done before anything else, so it can be combined with an input file on standard input. This is mainly for use by shell scripts, since under Unix it is difficult to read the contents of other people's pipes. .SH "RETURN VALUE" PGP returns a 0 to the shell on success, and a nonzero error code on failure. See the source code for details on nonzero status return values. .SH FILES .br .nf .\" set tabstop to longest possible filename .ta \w'/usr/local/lib/pgp/language.txt'u *.pgp ciphertext, signature, or key file *.asc ascii armor file /usr/local/lib/config.txt system-wide configuration file $PGPPATH/config.txt per-user configuration file $PGPPATH/pubring.pgp public key ring $PGPPATH/secring.pgp secret key ring $PGPPATH/randseed.bin random number seed file /usr/local/lib/pgp/language.txt $PGPPATH/language.txt foreign language translation file /usr/local/lib/pgp/pgp.hlp $PGPPATH/pgp/pgp.hlp online help text file /usr/local/lib/pgp/pgpkey.hlp $PGPPATH/pgp/pgpkey.hlp online key-management help text file .SH NOTE The manual is really good, and it's really important in the long run that you read it. PGP may be an unpickable lock, but you have to put in in the door properly to keep out intruders. So read the manual and find out how! .SH CAVEATS It is impossible to overemphasize the importance of protecting your secret key. Anyone gaining access to it can forge messages from you or read mail addressed to you. Be very cautious in using PGP on any multi-user unix system. PGP is believed by its authors to be the most secure cryptographic software available to the public when used as directed, but then again everyone always claims their pet encryption system is secure. Read the section in the manual on "Trusting Snake Oil" and the section on "Vulnerabilities" for caveats. .SH DIAGNOSTICS Mostly self explanatory. .SH BUGS PGP was initially written for the PC, and behaves very PCish. In particular, its automagic file selection, file extensions, and the like all make it somewhat alien in the UNIX environment. This man page needs to be updated to reflect all the latest features. .SH AUTHORS Originally written by Philip R. Zimmermann. Later augmented by a cast of thousands. .SH "LEGAL RESTRICTIONS" For detailed information on PGP licensing, distribution, copyrights, patents, trademarks, liability limitations, and export controls, see the "Legal Issues" section in the "PGP User's Guide, Volume II: Special Topics". In particular, PGP is export restricted by the Offices of Defense Trade Controls and Munitions Control, U.S. Department of State, and shall not be exported or reexported from the United States, directly or indirectly, without obtaining a U.S. Department of State License. PGP uses a public key algorithm claimed by U.S. patent #4,405,829. The exclusive rights to this patent are held by a California company called Public Key Partners. This is explained in the PGP User's Guide, Volume II. PGP itself is freeware, but it inherits certain encumbrances from its use of RSAREF to perform public-key encryption. Another fully licensed commercial PGP is available from ViaCrypt, 2104 West Peoria Avenue, Phoenix, Arizona 85029, (602) 944-0773. ons are noconv, latin1 or koi8, indicating that no translation should be done; cp850, indicating that IBM PC code page 850 mappings should be used; ascii, indicating that a minimal ASCII subset should be used; and alt_codoc/politic.doc1004440006630000000000004250405562764276010711 037777703401 1 0 Computer-Related Political Groups ================================= This document is included in the PGP software release package. PGP is "Pretty Good Privacy", a public-key encryption program from Philip Zimmermann. PGP is a very political piece of software. It seems appropriate to mention here some computer-related activist groups that are concerned with issues such as impacts of computers on society, algorithm patents, etc. Here is some information on these groups, provided by each group. The Electronic Frontier Foundation (EFF) ---------------------------------------- Last Updated: 14 June 1993 The Electronic Frontier Foundation (EFF) was founded in July, 1990, to assure freedom of expression in digital media, with a particular emphasis on applying the principles embodied in the Constitution and the Bill of Rights to computer-based communication. From the beginning, EFF was determined to become an organization that would combine technical, legal and public policy expertise, and would apply these skills to the myriad issues and concerns that arise whenever a new communications medium is born. By remaining faithful to this initial vision, EFF has become an organized voice for the burgeoning community of nationally and inter- nationally networked computer users. We perform the multiple roles of guardian, advocate and innovator, to serve and protect the public interest in the information age. GOALS OF THE ELECTRONIC FRONTIER FOUNDATION, 1993 EFF's mission is to understand the opportunities and challenges of digital communications, in order to foster openness, individual freedom and community. We expect to carry out our mission through activities in the following areas: POLICY DEVELOPMENT AND ADVOCACY. EFF has been working to promote an open architecture for telecommunications by various means, including the Open Platform Initiative, the fight against the FBI's Digital Telephony wiretap proposal, and efforts to free robust encryption technologies from NSA control. FOSTERING COMMUNITY. Much of the work we have done has been directed at fostering a sense of community in the online world. Because we realize that we know far less about the conditions conducive to the formation of virtual communities than is necessary to be effective in creating them, we will devote a large portion of our R & D resources to developing better understanding in this area. LEGAL SERVICES. EFF was born to defend the rights of computer users against overzealous and uninformed law enforcement officials. This continues to be an important focus of EFF's work. We provide legal information to individuals who request it and support for attorneys who are litigating. We maintain print and online legal archives, disseminate this information, and make it available for downloading. Our board and staff are continuously engaged in writing and speaking about these issues. RESEARCH & DEVELOPMENT. We have started many projects over the years as their need became apparent. Going forward, EFF will allocate resources to investigate and initiate new projects. To ensure that our projects have the greatest impact and can reasonably be completed with the resources available, EFF will sharpen its selection and review process. MEMBERSHIP IN THE ELECTRONIC FRONTIER FOUNDATION If you support our goals and our work, you can show that support by becoming a member now. Members receive our bi-weekly electronic newsletter, EFFector Online (if you have an electronic address that can be reached through the Net), answers to your legal questions, special releases and other notices on our activities. (Because we believe that support should be freely given, you can receive these things even if you do not elect to become a member.) Your membership dues and other donations are fully tax deductible. OUR ADDRESSES Electronic Frontier Foundation 1001 G St., NW Suite 950 East Washington, DC 20001 +1 202 347 5400 +1 202 393 5509 FAX Internet: eff@eff.org MEMBERSHIP IN THE ELECTRONIC FRONTIER FOUNDATION ============================================================= Print out and mail to: Membership Coordinator Electronic Frontier Foundation 1001 G St., NW, Suite 950 East, Washington, DC 20001 I wish to become a member of EFF. I enclose: $_______ $20.00 (student or low income membership) $40.00 (regular membership) Name: Organization: Address: City or Town: State: Zip: Phone (optional): ( ) FAX (optional): ( ) Email address: I enclose a check [ ]. Please charge my membership in the amount of $________ to my Mastercard [ ] Visa [ ] American Express [ ] Number: Expiration date: Signature: ________________________________________________ Date: Our privacy policy: The Electronic Frontier Foundation will never sell any part of our membership list. We will, from time to time, share this list with other nonprofit organizations whose work we determine to be in line with our goals. However, you must explicitly grant us permission to share your name with these other groups. Member privacy is our default. I hereby grant permission to EFF to share my name with other nonprofit groups from time to time as it deems appropriate. [ ] Initials:___________________________ Computer Professionals for Social Responsibility ------------------------------------------------ CPSR empowers computer professionals and computer users to advocate for the responsible use of information technology and empowers all who use computer technology to participate in the public debate. As technical experts, CPSR members provide the public and policymakers with realistic assessments of the power, promise, and limitations of computer technology. As an organization of concerned citizens, CPSR directs public attention to critical choices concerning the applications of computing and how those choices affect society. By matching unimpeachable technical information with policy development savvy, CPSR uses minimum dollars to have maximum impact and encourages broad public participation in the shaping of technology policy. Every project we undertake is based on five principles: * We foster and support public discussion of and public responsibility for decisions involving the use of computers in systems critical to society. * We work to dispel popular myths about the infallibility of technological systems. * We challenge the assumption that technology alone can solve political and social problems. * We critically examine social and technical issues within the computer profession, nationally and internationally. * We encourage the use of computer technology to improve the quality of life. Founded in 1981 by a small group of computer scientists concerned about the use of computers in nuclear weapons systems, CPSR has grown into a national public-interest alliance of computer industry professionals dedicated to examining the impact of technology on society. Currently, CPSR has 21 chapters in the U.S. and affiliations with similar groups worldwide. In addition to our National Office in Palo Alto, CPSR maintains offices in Washington D.C. and Cambridge, Massachusetts. CPSR PROJECTS As computer technology becomes increasingly pervasive, the issues facing us become more complex. CPSR provides a forum where we can examine technology's impact on our lives, the lives of our fellow citizens, and on society as a whole. By sponsoring both national and local projects, CPSR serves as a catalyst for in-depth discussion and effective action in key areas: Civil Liberties and Privacy The 21st Century Project: Technology Policy and Human Needs Workplace Issues and Participatory Design Reliability and Risk In addition, CPSR's chapter-based projects and national working groups tackle issues ranging from the development of nanotechnology and virtual reality to computing and ethics to community computing to computers and education. HOW TO BECOME A MEMBER CPSR is a democratically organized grass roots alliance. Our accomplishments are the result of the member activism. Many CPSR members serve as national organizers Just fill out the membership form, enclose a check and mail it to CPSR, P.O. Box 717, Palo Alto, CA 94301. CPSR's cost to provide members with services is covered by the $75 dues. To keep CPSR membership open to a wide range of people, we offer dues levels of $20 and $50. MEMBERSHIP BENEFITS When you become a member of CPSR, you are joining a nationwide network of computer professionals who are committed to bringing social responsibility to all aspects of computer technology. CPSR sponsors, supports, and participates in conferences, roundtables and meetings on advanced issues in computing, local civic networks, cryptography, participatory design, and computers and social change. Every fall the CPSR Annual Meeting brings together the foremost representatives of the technology industry to explore current topics in seminars and panel discussions. Our conferences and chapter meetings provide important opportunities to meet other members and share ideas and expertise. OTHER MEMBERSHIP BENEFITS INCLUDE: * a quarterly newsletter which provides in-depth analysis of key issues in computing as well as updates on CPSR activities and action alerts, * an organized voice for socially responsible computing in Washington, * well-researched public testimony and public policy development, * invitations and discounts to CPSR events, * discounts on research papers, books, and educational videotapes, * on-line information and discussion of key issues in computing, * membership in a local CPSR chapter (where available) and notices of chapter meetings and activities, * participation in local and national working groups which allow you to have effective impact on the issues you care about, * information and referral about crucial issues in computing. ORGANIZATIONAL INFORMATION CPSR National Office P.O. Box 717 Palo Alto, CA 94301 415-322-3778 415-322-3798 (FAX) E-mail: cpsr@csli.stanford.edu CPSR Cambridge Office P.O. Box 962 Cambridge, MA 02142 617-625-6985 chapman@lcs.mit.edu CPSR Washington Office 666 Pennsylvania Ave SE, Suite 303 Washington, D.C. 20003 202-544-9240 202-547-5481 FAX rotenberg@washofc.cpsr.org Staff Managing Director, Evelyn Pine Assistant to the Director, Nikki Draper Cambridge Office Director, Gary Chapman Washington Office Director, Marc Rotenberg PRIVACY NOTICE: The CPSR membership database is never sold, rented, lent, exchanged, or used for anything other than official CPSR activity. CPSR may elect to send members mailings with information from other groups, but the mailings will always originate with CPSR. ====================== clip and mail ========================== CPSR MEMBERSHIP FORM Name _________________________________________________________ Address _________________________________________________________ _________________________________________________________ City/State/Zip __________________________________________________ Home phone ____________________ Work phone _____________________ Company _________________________________________________________ Type of work ____________________________________________________ E-mail address __________________________________________________ CPSR Chapter __ Acadiana __ Austin __ Berkeley __ Boston __ Chicago __ Denver/Boulder __ Los Angeles __ Madison __ Maine __ Milwaukee __ Minnesota __ New Haven __ New York __ Palo Alto __ Philadelphia __ Pittsburgh __ Portland __ San Diego __ Santa Cruz __ Seattle __ Washington, DC __ No chapter in my area CPSR Membership Categories __ $ 75 REGULAR MEMBER __ $ 50 Basic member __ $ 200 Supporting member __ $ 500 Sponsoring member __ $1000 Lifetime member __ $ 20 Student/low income member __ $ 50 Foreign subscriber __ $ 50 Library/institutional subscriber Additional tax-deductible contribution to support CPSR projects: __ $50 __ $75 __ $100 __ $250 __ $500 __ $1000 __ Other Total Enclosed: $ ________ Make check out to CPSR and mail to: CPSR P.O. Box 717 Palo Alto, CA 94301 -- The League for Programming Freedom ---------------------------------- Protect Your Freedom to Write Programs Join the League for Programming Freedom (Version of January 15, 1993) Ten years ago, programmers were allowed to write programs using all the techniques they knew, and providing whatever features they felt were useful. This is no longer the case. New monopolies, known as software patents and interface copyrights, have taken away our freedom of expression and our ability to do a good job. "Look and feel" lawsuits attempt to monopolize well-known command languages; some have succeeded. Copyrights on command languages enforce gratuitous incompatibility, close opportunities for competition, and stifle incremental improvements. Software patents are even more dangerous; they make every design decision in the development of a program carry a risk of a lawsuit, with draconian pretrial seizure. It is difficult and expensive to find out whether the techniques you consider using are patented; it is impossible to find out whether they will be patented in the future. The League for Programming Freedom is a grass-roots organization of professors, students, businessmen, programmers and users dedicated to bringing back the freedom to write programs. The League is not opposed to the legal system that Congress intended--copyright on individual programs. Our aim is to reverse the recent changes made by judges in response to special interests, often explicitly rejecting the public interest principles of the Constitution. The League works to abolish the new monopolies by publishing articles, talking with public officials, boycotting egregious offenders, and in the future may intervene in court cases. On May 24, 1989, the League picketed Lotus headquarters on account of their lawsuits, and then again on August 2, 1990. These marches stimulated widespread media coverage for the issue. We welcome suggestions for other activities, as well as help in carrying them out. Membership dues in the League are $42 per year for programmers, managers and professionals; $10.50 for students; $21 for others. Please give more if you can. The League's funds will be used for filing briefs; for printing handouts, buttons and signs; whatever will persuade the courts, the legislators, and the people. You may not get anything personally for your dues--except for the freedom to write programs. The League is a non-profit corporation, but not considered a tax-exempt charity. However, for those self-employed in software, the dues can be a business expense. The League needs both activist members and members who only pay their dues. We also greatly need additional corporate members; contact us for information. If you have any questions, please write to the League, phone (617) 433-7071, or send Internet mail to lpf@uunet.uu.net Jack Larsen, President Dean Anderson, Secretary Steve Sisak, Treasurer Jack Larsen can be contacted at (708) 698-1160; Fax (708) 698-6221. To join, please send a check and the following information to: League for Programming Freedom 1 Kendall Square #143 P.O.Box 9171 Cambridge, Massachusetts 02139 (Outside the US, please send a check in US dollars on a bank having a US correspondant bank, to save us check cashing fees.) Your name: The address for League mailings, a few each year; please indicate whether it is your home address or your work address: The company you work for, and your position: Your phone numbers (home, work or both): Your email address, so we can contact you for demonstrations or for writing letters. (If you don't want us to contact you for these things, please say so, but please give us your email address anyway so we can save paper and postage by sending you the newsletter by email.) Is there anything about you which would enable your endorsement of the LPF to impress the public? For example, if you are or have been a professor or an executive, or have written software that has a good reputation, please tell us. Would you like to help with LPF activities? The corporate charter of the League for Programming Freedom states: The purpose of the corporation is to engage in the following activities: 1. To determine the existence of, and warn the public about restrictions and monopolies on classes of computer programs where such monopolies prevent or restrict the right to develop certain types of computer programs. 2. To develop countermeasures and initiatives, in the public interest, effective to block or otherwise prevent or restrain such monopolistic activities including education, research, publications, public assembly, legislative testimony, and intervention in court proceedings involving public interest issues (as a friend of the court). 3. To engage in any business or other activity in service of and related to the foregoing paragraphs that lawfully may be carried on by a corporation organized under Chapter 180 of the Massachusetts General Laws. The officers and directors of the League will be elected annually by the members. By sponsoring both national and local projects, CPSR serves as a catalyst for in-depth discussion and effective action in key areas: Civil Liberties and Privacy The 21st Centudoc/appnote.doc1004440006630000000000001411705567065413010703 037777703401 1 0 PGP 2.6 Application Note: Integrating PGP with mailers Derek Atkins 22-May-94 This document will try to describe how to create an application around PGP version 2.6, in order to incorporate PGP into mailers and news readers. There are a number of changes in 2.6 which make it easier to write wrappers for PGP. In writing this, I may have inadvertantly left out some functionality, some mailers, or some machine types. I should warn readers now that I am a UNIX person, and that most of this document will probably be in UNIX terms. The first thing to remember is that PGP usually needs to have a controlling TTY in order to gather information, like the password, or for the user to answer questions, like to whether to add or sign keys. This is useful for text-based mail agents. In fact, it is most useful for agents which use files for messages, like MH. One way to use PGP is to just decrypt the message into a file and display that file. This can be a security risk, since wiping files off disk is not always successful, and by having the plain-text go to a file means more time for a possible attacker to get ahold of the plain-text of the message. A better way to accomplish this is to use filter_mode, which is the -f option. This tells PGP to read the message from stdin, and to put the output onto stdout. Unfortunately, in this manner, the signature information is output onto stderr, so you will either lose it, or it and all other PGP output will be put in the same stream with the message, but this depends on your piping ability. PGP tries to send all "interesting" data to standard out, and error messages to standard error. This lets you pick out the interesting information and discard the rest. This also means that you can use PGP in filter-mode as a back-end to some user interface, and obtain the data in the manner. But remember that the current implementation of PGP uses temporary files to store intermediate data, so you are still at a risk, although it is much less of a risk than just decrypting into a file. This works well when dealing with a command-line mailer, or a mailer that is run in a terminal. There are problems with this approach, however, if you do not have a TTY in which to get a password to decrypt or sign messages. It seems that there would not be a good way around this, but then again, PEM is going to have this same problem. (An example that I can think of is integrating with xmh). However, there is a way around this in some cases. PGP has numerous ways to accept the passphrase other than just promping for it. One way, which is not recommended, is to use the "-z" option to set the passphrase. Again, this is *NOT* recommended, since some operating systems will not allow the program to erase the process table, and someone can retreive the pass phrase from there via a "ps" listing of active processes. A similar way to get the pass phrase in is to use the PGPPASS environment variable. Again, this has the same problems as "-z" with regards to an attacker finding the passphrase in the OS kernel memory of the process table.. An example of this usage is: pgp -sat -z "This is my pass phrase" inputfile There is a better way of doing this in PGP 2.6, which is an environment variable called "PGPPASSFD". If this is set, it means that the FIRST thing PGP will do is read the pass phrase from this file descriptor. So, for example, one can set PGPPASSFD to "0" (zero), and then PGP will read the pass phrase from stdin as the first thing. This allows you to send the passphrase to PGP in a manner invisible to someone armed with the process listing. For example, an emacs utility could grab the block to be encrypted (or decrypted), ask the user for the pass phrase in the mini-buffer, and then do the equivalent of this shell script, using something like: (send-string PROCESS "PassPhrase") (send-region PROCESS (point-min) (point-max)) ---begin--- #!/bin/sh PGPPASSFD=0; export PGPPASSFD (echo "PassPhraseHere"; cat filename ) | pgp -feast recipient1 recipient2... ---end--- I must admit, this is a crude script, since it doesn't strip out stderr, which included the bannerlines and error messages, but that is not difficult to do out of band. This is an example perl script that demonstrates the use of PGPPASSFD: ---begin--- #!/usr/local/bin/perl # # perl example for PGPPASSFD, # encrypts stream with password 'test' # pipe(READER,WRITER); if (!fork) { close(WRITER); $ENV{'PGPPASSFD'}=fileno(READER); # the $^F (Ctrl-F) variable controls close-on-exec of files $=fileno(READER); exec "pgp -acf"; die "can't exec pgp\n"; } close(READER); syswrite(WRITER, "test\n", 5); close(WRITER); wait ---end--- Another feature of 2.6 which can be utilized in mailer scripts is the batchmode feature. This is used in the key-server software (see keyserv.doc), to allow a process to call PGP and have it perform without prompting the user for anything. It will take the default answer to most questions, which may not be what the user wants. This is switched by adding "+batchmode" to the command line. One more mailer I should mention, and this is probably the most important of all of them, is MIME compatibility. In order to use MIME, a user needs to create a proper entry for PGP. Unfortunately there is not yet a standard MIME content-type for PGP-MIME. However there is a recommended set of mailcap entries which would be useful for using metamail: application/pgp; pgp -f < %s | metamail; needsterminal; \ test=test %{encapsulation}=entity application/pgp; pgp %s; needsterminal I hope that this document has helped people understand some of the work being done to integrate PGP with mailers. There is some work going on already to integrate it even more. If you have a mailer for which there is no PGP handler, and you want to write one, please let me know, so that we don't duplicate work. In addition, if you have written a mailer application, and its not included here in the release, again let me know. A second contact for this is Colin Plumb . Have fun! -derek ches stimulated widespread media coverage for the issue. We welcome suggestions for other activities, as well as help in carrying them out. Membership dues in the League are $42 per year for programmers, managers and professionals; $10.50 for students; $21 for others. Please give more if you can. The League's funds will be used for filing briefs; for printing handouts, buttons and signs; whatever will persuade the courts, the doc/changes.doc1004440006630000000000005025305650053043010633 037777703401 1 0 [Note: This file now contains all the information that used to be in the newfor22.doc through newfor26.doc, starting with the most recent information first] Changes for PGP 2.6.2 - Some people reported a "bug" that you could stick an extra paragraph in the beginning of a clear-signed message and PGP would still report a good signature. PGP allows comment "headers" before ASCII-armor blocks (like the Version: header that's there for debugging purposes), terminated, as with e-mail and usenet messages, by a blank line. These headers are just window dressing; PGP ignores them. So this is actually a "feature"; the bug is that people think it's part of the signed message. There are a number of ways to fake the visual appearance of a blank line using common file-viewing utilities, a blank line is easy to miss even if you know about it, and headers are not presently used in clear-signed messages. So now headers are forbidden at the beginning of a clear-signed message. Also, PGP enforces an RFC-822-like syntax on header lines before ASCII armor. Note that in no case has PGP's output ever been compromised; the problem arises only if people see the "good signature" message but try to read the input directly to see what was signed. - Closed files properly in a number of error situations, which also helps PGP run under OS/2. (Contributed by John Frickson) - Improved OS/2 makefile target. - Added a few contributed makefile entries (hpux9, amix, encore, machten) - Fixed MAX_BIT_PRECISION to 2048. - Changed the +'s printed during prime generation (to indicate that a candidate prime just passed a Fermat test) to *'s, since some people's modems go into command mode when fed slow strings of +'s. - Added a copyright notice for RSAREF. - Updated the manual-checking error message to tell people that they can find a simple fix if they RTFM. Hopefully this will further encourage people to complain to whoever distributed PGP without the manual instead of just getting frustrated. - Fixed (at long last) PGP's table of file extensions to know that gzip is .gz, and not .z. (Which was the preferred form some time ago.) - Fixed a bug in key editing with the public and secret keyrings in different directories. The old code was assuming they were in the same directory, which used to be a safe assumption, but no more. - Fixed a problem with access() on VMS returning failure when fed a directory that exists. - Enlarged randseed.bin to hold more entropy, and arranged for it to be saved on each invocation of PGP so the entropy from keystrokes while not encrypting would be available for future use. See the comment in random.c for implementation details. - A problem checking separate signatures on files with upper-128 characters has been fixed. PGP was assuming that since MS-DOS uses CRLF line endings, files for signature testing are already in canonical test format. This is not true if upper-128 characters are in use. - Got rid of pkcs_compat as redundant. Changes to PGP 2.6.1 PGP 2.6.1 is a bugfix release of PGP 2.6. It fixes many bugs that have been reported by the PGP user community since the original release of PGP 2.6 back in May of 1994. The most notable bugs are the "xorbytes" bug that resulted in less randomness then full Shannon Entropy for all key bits. (Note: People who generated keys with PGP 2.6 do *not* need to generate new keys). Another bug that manifested itself as "DOS error 8" errors has also been fixed. It is also safe to edit your key userid with PGP 2.6.1 even if you store your passphrase in the PGPPASS variable. PGP 2.6.1 will now accept keys up to length 2,048 bits, however it will still only generate keys up to 1,024 bits. This is a phased upgrade approach to increasing PGP's keysize. Changes to PGP 2.6: This version of PGP uses a version of RSAREF provided to MIT by RSA Data Security for use in PGP. This version is legal within the U.S. See the enclosed RSAREF license for full details. Basically this is a non-commercial release. If you want to use it in a commercial or governmental setting, talk to ViaCrypt (2014 West Peoria Avenue, Phoenix, Arizona 85029, +1 602 944-0773). While PGP version 2.5 used RSAREF version 2.0, PGP 2.6 uses RSAREF version 1. This change was made in consultation with RSA Data Security, which is currently revising its version 2.0 distribution. The version of RSAREF included with this distribution is RSAREF version 1, not version 2.0. PGP 2.6 will read messages, signatures and keys created with versions of PGP post 2.2. (i.e., 2.3, 2.3a, 2.4 and 2.5). However after 9/1/94 Version 2.6 will create messages which contain a version number of "3" in signatues, messages and keys (see pgformat.doc for details). PGP2.6 will be able to read these signatures, messages and keys, but prior versions will not. Versions prior to 2.6 would not permit a new signature to be added to a key if there was an already existing signature from the same signer. Starting with version 2.6 newer signatures will override older ones *as long as the newer signature verifies*. This change is important because many keys have signatures on them that were created by PGP version 2.2 or earlier. These signatures can not be verified by PGP 2.5 or higher. Owners of keys with these obsolete signatures should attempt to gather new signatures and add them to their key. Significant changes were also made for version 2.5. Because version 2.6 is coming out very soon after 2.5 (which was only really a beta test version) readers are encouraged to read the file "newfor25.doc" as well as this file. Changes to PGP 2.5: ***** MOST IMPORTANT ***** This version of PGP uses RSAREF 2.0, so it's legal in the U.S.! The RSAREF license forbids you to (among other things; see the license for full details) "use the program to provide services to others for which you are compensated in any manner", but that still covers a lot of people. If you want to use it in a commercial or governmental setting, talk to ViaCrypt (2014 West Peoria Avenue, Phoenix, Arizona 85029, +1 602 944-0773). PGP 2.5 should always be distributed with a copy of the RSAREF 2.0 license of March 16, 1994 from RSA Data Security, Inc., so that all users will be aware of their obligations under the RSAREF license. Since the RSAREF license conflicts with the GNU General Public License that PGP was formerly distributed under, the GPL had to go. PGP is still freely distributable, though. (From a copyright point of view; export controls or some other legal hassle may apply.) *** IMPORTANT CHANGE: RSAREF 2.0 can understand only the pkcs_compat=1 formats for signatures and encrypted files. This has been the default since 2.3, so old files should not be too much of a problem, but old key signatures will encounter difficulties. This change will result in a hole being ripped in the "web of trust" as many old signatures are invalidated. Please check your key rings (pgp -kc) and re-issue any signatures that have been invalidated. PGP by default offers to remove such signatures. Even if you leave them in, they are not trusted. Another RSAREF limitation is that it cannot cope with keys longer than 1024 bits. PGP now prints a reasonably polite error message in such a case. OTHER CHANGES: The support files are thinner. The various contrib directory utilities have not been updated since 2.3a, and since the PGP developers know how annoying it is to have people using an ancient version and complaining about a bug in a program that was fixed a year ago, they have been omitted rather than annoy the contributors in this way. Also, the language translation file, language.txt, is incomplete. The strings that were in 2.3a are there, and some that could be updated without much knowledge of the language, but others that are new to 2.5 are untranslated. The format should be obvious and some tools for manipulating the language traslations are included in the contrib directory. Printed KeyIDs have been incresed to 32 bits, as there were enough keys out there that 24-bit keyIDs were no longer sufficiently unique. The previous 24-bit keyID is the LAST 6 digits of an 8-digit 32-bit keyID. For example, what was printed as A966DD now appears as C7A966DD. The config-file options pubring=, secring=, and randseed= have been added. Hopefully, the uses will be obvious. With these, you can keep keyrings anywhere you like. Of course, they can also be specified on the command line with +pubring= (or abbreviated to +pub=). If the line comment= appears in the config file, the line "Comment: " appears in ASCII armor output. Of course, you can also use this from the command line, e.g. to include a filename in the ASCII armor, do "pgp -eat +comment=filename filename recipient". PGP now enables clearsig by default. If you sign and ascii-armor a text file, and do not encrypt it, it is clearsigned unless you ask for this not to be done. The now enables textmode. Textmode detects non-text files and automatically turns itself off, so it's quite safe to leave on all the time. If you haven't got these defaults yourself, you might want to enable them. All prompts and progress messages are now printed to stderr, to make them easier to find and ensure they don't get confused with data on standard output such as pgp -m output. PGP now wipes temp files (and files wiped with pgp -w) with pseudo-random data in an attempt to force disk compressors to overwrite as much data as possible. On Unix, if the directory /usr/local/lib/pgp exists, it is searched fror help files, language translations, and the PGP documentation. On VMS, the equivalent is PGP$LIBRARY:. (This is PGP_SYSTEM_DIR, defined in fileio.h, if you need to change it for your site.) Also, it is searched for a default global config.txt. This file may be overridden by a local config.txt, and it may not set pubring, secring, randseed or myname (which should be strictly personal) The normal help files (pgp -h) are pgp.hlp or .hlp, such as fr.hlp. Now, there is a separate help file for pgp -k, called pgpkey.hlp, or key.hlp. No file is provided by default; PGP will use its one-page internal help by default, but you can create such a file at your site. On Unix systems, $PGPPATH defaults to $HOME/.pgp. PGP used to get confused if you had a keyring containing signatures from you, but not your public key. (PGP can't use the signatures in this case. Only signatures from keys in the keyring are counted.) PGP still can't use the signatures, but prints better warning messages. Also, adding a key on your secret key ring to your public keyring now asks if the key should be considered ultimately-trusted. Prviously, you had to run pgp -ke to force this check, which was non-obvious. Due to a few people distributing PGP without the manual (including one run of a few thousand CD-ROMs), and the resultant flood of phone calls from confused users, PGP now looks to make sure a manual is somewhere in the vicinity when running to discourage this sort of thing. (If you're getting this warning and need details on how to get rid of it, try pgp -kg.) On Unix, PGP now figures out the resolution of the system clock at run time for the purpose of computing the amount of entropy in keystroke timings. This means that on many Unix machines, less typing should be required to generate keys. (SunOS and Linux especially.) The small prime table used in generating keys has been enlarged, which should speed up key generation somewhat. There was a bug in PGP 2.3a (and, in fact in 2.4 and dating back to 1.0!) when generating primes 2 bits over a multiple of the unit size (16 bits on PC's, 32 bits on most larger computers), if the processor doesn't deal with expressions like "1<<32" by producing a result of 1. In practice, that corresponds to a key size of 64*x+4 bits. Code changes: At the request of Windows programmers, the PSTR() macro used to translate string has been renamed to LANG(). The random-number code has been *thoroughly* cleaned up. So has the IDEA code and the MD5 code. The MD5 code was developed from scratch and is available for public use. The Turbo C makefile was dropped in favour of a Borland C .prj file. You can use makefile.msc as a guide if you need one for a command-line Turbo C. Changes to PGP 2.4: - Fixed a bug with the -z option. If no passphrase was given, PGP used to crash. - When using -c, the IV is generated properly now, and the randseed.bin postwash is done. (This bug could have resulted in the same ciphertext being generated for the same plaintext, if the same passphrase is used.) - Memory allocated with halloc() is now freed with hfree() in ztrees.c and zdeflate.c. (MS-DOS only.) - The decompression code now detects end of input reliably, fixing a bug that used to have it produce infinite amounts of output on come corrputed input. Decompression has also been sped up. - PGP -m won't try to write its final output to the current directory. This makes it less efficent if you want to save the text to a file, but more secure if you don't. - Number of bits allowed when generating keys limited to 1024, in line with the limits in RSAREF and BSAFE. It used to be higher, but folks, if you think you need a key larger than that, do some research into the complexity of factoring. - Version number changed to pgp2.4 News for PGP 2.3a There was a bug in PGP's handling of clear-signed messages when lines were terminated with CR-LF pairs. This has been revamped. The previous limit on the length of lines in clear-signed messages has been eliminated. The randseed.bin file was not closed when read, which resulted in it not being rewritten with a new value under some operating systems. Fixed. Not all of the bytes in randseed.bin were being used, resulting in less randomness than desired when picking session keys. While it did not make the compromise of session keys likely, it was undesirable and has been fixed. PGP should now compile with less difficulty under OS/2. The Turbo C makefile was incorrect. Fixed. The VMS build files were out of date. Fixed. PGP was not accepting octal escapes in the language.txt file that did not begin with \0. \377 is now acceptable. The language.txt file got mangled in the middle somehow. Fixed. News for PGP 2.3 This PGP 2.3 release has several bug fixes over PGP 2.2, and a few new (although somewhat esoteric) features. Among them are: - An important bug: there was a bug with compression under MS-DOS which caused the wrong piece of memory to be freed, with results that ranged from none to undecodable messages to machine crashes. - When adding keys, PGP now properly closes all the files it opens, so you don't run out of file handles (MS-DOS) or file descriptors (UNIX). - Sometimes PGP would not properly ask the user to set trust parameters when keys were validated by adding new signatures. This has been fixed. - When PGP messages are sent through a MIME mail system, a conflict arises over the use of the '=' character. PGP can now decode ASCII armored messages which have been mangled by MIME's quoting mechanism. - PGP previously kept track of one pass phrase (from the PGPPASS environment variable, the file descriptor named by the PGPPASSFD environment variable, a -z option, or previous user prompts), and tried it if it needed a subsequent pass phrase. This caused bugs if you attempted something that required two pass phrases, such as pgp -sc (sign and conventionally encrypt). PGP now keeps track of any number of pass phrases, including multiple -z options, and uses them as necessary. Mostly, it just Does The Right Thing, but if you care, the exact algorithm is as follows: - There is a pool of private-key pass phrases that starts out with the contents of the PGPPASS environment variable (if any), and has every pass phrase that is successfully used to unlock a private key added to it. When a private key needs unlocking, every pass phrase in the pool is tried first. - There is a list of PGP pass phrases available for use by whatever needs one. This is initialized with the -z command-line options and the phrase read from the PGPPASSFD file descriptor. When a pass phrase is needed, it is taken from the front of that list. When a pass phrase is needed to unlock a secret key, every key on the list is tried, and if it "fits" and unlocks the secret key, it is moved to the key pass phrase pool. - If the above fails to produce a pass phrase, the user is prompted to supply one. Key generation (we need all the keystrokes we can get for random-number accumulation) and key signing (to make sure the user really means to do what they're doing) are exceptions; the user is always prompted for a pass phrase under those circumstances. New options: +pkcs_compat=n This defaults to 1, which tells PGP to generate encryption key and signature blocks in a format derived from the PKCS standards. This format is understood (but not generated) by PGP 2.2. If set to 0, the old format is generated, which may be needed for portability to PGP versions before 2.2. PGP is still incompatible with the PKCS standards in many ways, but in future, values of 2 or higher may be used to produce formats which are more compatible. Other notes: The MS-DOS executable was compiled with Borland C++ version 3.0, optimized for maximum speed, except that jump optimisation was turned off. If it is turned on, the Transform() function in md5.c is compiled incorrectly. The pgp.prj file that was used is included in the source distribution. Thanks to everyone who worked on PGP and sent in bug reports. Two who didn't make it into the manual are to Lindsay DuBois for a bit of last- minute translation, and Reptilian Research for support in developing PGP. And thanks to the Cypherpunks who managed to get PGP so much attention in Wired magazine recently. I hope you enjoy PGP! -Colin News for PGP 2.2 The main change since PGP 2.1 is a speedup in key management, and the ability to encrypt for more than one recipient. Apart from this there are some bugfixes and some new options to make it easier to use PGP from shell scripts or mailers. You can encrypt for more than one recipient by specifying additional userids on the command line eg: pgp -e plaintext Alice Bob Carol Some notes about the changes: - PGP doesn't do a keycheck on a keyfile before it is added anymore, this is to speed up merging a big keyfile with your public keyring which may already have most of the keys in the keyfile you are adding. After PGP has checked a signature it sets a flag in your public keyring to mark this signature as checked. Because PGP 2.1 didn't have these flags, PGP will check *all* signatures on your keyring the first time you add a key with PGP 2.2. After that PGP will only check new signatures. Also by using an older version than 2.2 on your keyring you will clear these flags again. New options: +interactive If you add a keyfile, PGP will ask for each new key if it should be added to your keyring. Options for use in shell scripts: +verbose=n The default is 1. With +verbose=0, PGP will only print an error message if something goes wrong. With +verbose=2, PGP will tell you what it's doing in detail suitable for debugging. +force Overwrite output file without asking, or with -kr: remove key without asking (only if it has just one userid). +batchmode With this option PGP won't ask any questions or prompt for alternate file names. Some of the key commands still need user interaction and can't be done from a shell script. You can also use this option to check if a file has a good signature. If the input file did not have a signature the exit code will be 1, if the file had a signature and if it checked OK the exit code will be 0. Note that if the input file has more than one armored messages, a good signature on one of these messages will make the exit code 0 (if there are no errors). These "long" options can be abbreviated as long as the abbreviation is unambiguous. "interactive" and "verbose" can also be set in config.txt; you can then turn these flags off on the command line with +option=. Some of the bug fixes: - Key lookup on keyID (eg 0x12AB) fixed for -ks/-krs. - Dearmoring of Macintosh type text files (CR only) now also works. o $HOME/.pgp. PGP used to get confused if you had a keyring containing signatures from you, but not your public key. (PGP can't use the signatures in this case. Only signatures from keys in the keyring are counted.) PGP still can't use the signatures, but prints better warning messages. Also, adding a key on your secret key ring to your es.hlp1004440006630000000000001024005562520572007103 037777703401 1 0 He aquí un rápido resumen de las órdenes para PGP v2.3... Para encriptar un fichero normal con la clave pública del destinatario: pgp -e fnormal identificador_des [otros identificadores] Para firmar un fichero normal con su clave secreta: pgp -s fnormal [-u su_identificador] Para firmar un fichero normal con su clave secreta y después encriptarlo con la clave pública del destinatario: pgp -es fnormal identificador_des [otros id.] [-u su_identificador] Para encriptar un fichero normal sólo con criptografía convencional, escriba: pgp -c fnormal Para desencriptar un fichero, o comprobar la integridad de la firma en un fichero firmado: pgp fcifrado [-o fnormal] Para desencriptar un fichero con armadura ASCII en varias partes: grabe todas las partes por orden en un fichero con extensión .asc y escriba: pgp farmadura [-o fnormal] --- Funciones para la gestión de claves: Para generar su propio par único de claves pública/secreta: pgp -kg Para añadir el contenido de un fichero de claves públicas o secretas al anillo correspondiente: pgp -ka fdclaves [anillo] Para extraer (copiar) una clave del anillo de claves públicas o secretas: pgp -kx identificador fdclaves [anillo] o: pgp -kxa identificador fdclaves [anillo] Para visualizar el contenido del anillo de claves públicas: pgp -kv[v] [identificador] [anillo] Para ver la "huella dactilar" de una clave pública, y poder verificarla por teléfono con su dueña: pgp -kvc [identificador] [anillo] Para visualizar el contenido y comprobar las firmas de certificación en el anillo de claves públicas: pgp -kc [identificador] [anillo] Para modificar el identificador o la frase de contraseña de la clave secreta: pgp -ke identificador [anillo] Para modificar los parámetros de confianza de una clave pública: pgp -ke identificador [anillo] Para suprimir una clave, o sólo un identificador, del anillo de claves públicas: pgp -kr identificador [anillo] Para firmar la clave pública de alguien en el anillo de claves públicas: pgp -ks identificador_des [-u su_identificador] [anillo] Para suprimir de un anillo ciertas firmas de un usuario: pgp -krs identificador [anillo] Para desactivar una clave pública, para que PGP no la utilice, o para reactivarla: pgp -kd identificador [anillo] Para revocar permanentemente su propia clave, emitiendo un certificado de compromiso de clave: pgp -kd su_identificador --- Ordenes esotéricas: Para desencriptar un mensaje y dejar su firma intacta: pgp -d fcifrado Para crear un certificado de firma separado del documento: pgp -sb ftexto [-u su_identificador] Para separar un certificado de firma del mensaje firmado: pgp -b fcifrado --- Opciones que pueden utilizarse en combinación con otras (formando a veces curiosas palabras): Para producir un fichero cifrado en formato ASCII radix-64, añada simplemente la opción -a cuando encripte o firme un mensaje, o cuando extraiga una clave: pgp -sea ftexto identificador_des o: pgp -kax identificador fdclave [anillo] Para eliminar automáticamente el fichero normal después de crear el fichero cifrado, añada simplemente la opción -w (wipe {limpiar}) cuando encripte o firme un mensaje: pgp -wes mensaje.txt identificador_des Para indicar que un fichero normal contiene texto ASCII, no binario, y que debe ajustarse a los convenios de línea del destinatario, añada la opción -t (texto) a las otras opciones: pgp -seta mensaje.txt identificador_des Para visualizar el texto desencriptado en la pantalla (como con la orden "more" {más} de Unix), sin grabarlo en un fichero, utilice la opción -m (more) al desencriptar: pgp -m fcifrado Para indicar que el texto desencriptado para el destinatario SOLO se puede mostrar en la pantalla de este, sin grabarse en el disco, añada la opción -m: pgp -metas mensaje.txt identificador_des Para recuperar el nombre original del fichero normal al desencriptar, añada la opción -p: pgp -p fcifrado Para utilizar en modo filtro, como en Unix, leyendo de la entrada estándar y escribiendo en la salida estándar, añada la opción -f: pgp -festa identificador_des fsalida s user prompts), and tried it if it needed a subsequent pass phrase. This caused bugs if you attempted something that required two pass phrases, such as pgp -sc (sign and conventionally encrypt). PGP now keeps track of any number of pass phrases, including multiple -z options, and uses them as necessary. Mostly, it just Does The Right Thfr.hlp1004440006630000000000001037705562520572007116 037777703401 1 0 Voici un résumé rapide des commandes de PGP... Pour chiffrer un fichier en clair avec la clé publique du destinataire, tapez: pgp -e fichier son_nom [autres noms] Pour signer un texte en clair avec votre clé secrète: pgp -s fichier [-u votre_nom] Pour signer un texte en clair avec votre clé secrète, puis le chiffrer avec la clé publique du destinataire, produisant un fichier .pgp: pgp -es fichier son_nom [aures noms] [-u votre_nom] Pour chiffrer de manière conventionelle seulement: pgp -c fichier Pour déchiffrer ou vérifier une signature pour un fichier chiffré (.pgp): pgp fichier_chiffré [-o fichier_en_clair] Pour déchiffrer un fichier avec une armure ASCII en plusieurs parties: sauvegarder toutes les parties dans l'ordre correct dans un ficher avec une extension .asc, puis tapez: pgp fichier_armure [-o fichier_en_clair] --- Fonctions de gestion des clés: Pour générer votre propre paire de clés publique/secrète: pgp -kg Pour ajouter le contenu d'un fichier de clés à votre fichier de clés public ou secret: pgp -ka fichier_de_clés [votre_fichier_de_clés] ou: pgp -kxa nom_d_utilisateur fichier_de_la_clé [fichier_de_clés] Pour retirer une clé de votre fichier de clés public ou secret: pgp -kr nom_d_utilisateur [fichier_de_clés] Pour extraire (copier) une clé de votre fichier de clés public ou secret: pgp -kx nom_d_utilisateur fichier_de_la_clé [fichier_de_clés] Pour visualiser le contenu de votre fichier de clés: pgp -kv[v] [nom_d_utilisateur] [ficher_de_clés] Pour visualiser l'empreinte d'une clé publique, afin de faciliter sa verification au téléphone avec son propriétaire: prp -kvc [nom_d_utilisateur] [ficher_de_clés] Pour vérifier les signatures sur votre fichier de clés publiques: pgp -kc [nom_d_utilisateur] [ficher_de_clés] Pour modifier le nom d'utilisateur ou le mot de passe pour votre clé secréte: pgp -ke nom_d_utilisateur [ficher_de_clés] Pour modifier les paramètres de confiance pour une clé publique: pgp -ke nom_d_utilisateur [ficher_de_clés] Pour signer la clé publique de quelqu'un d'autre sur votre fichier de clés publiques: pgp -ks son_nom [-u votre_nom] [fichier_de_clés] Pour enlever certaines signatures d'une personne sur un fichier de clés: pgp -krs son_nom [fichier_de_clés] Pour inactiver une clé publique afin que PGP ne l'utlise pas, ou pour la réactiver: pgp -kd son_nom [fichier_de_clés] Pour révoquer votre propre clé de façon permanente et émettre un certificat de compromission de clé: pgp -kd votre_nom [fichier_de_clés] --- Commandes ésotériques: Pour déchiffrer un message et laisser intacte la signature: pgp -d fichier_chiffré Pour créer un certificat de signature détaché du document: pgp -sb fichier_de_texte [-u votre_nom] Pour détacher un certificat de signature d'un message signé: pgp -b fichier_chiffré --- Options qui peuvent être utilisées en combinaison avec d'autres options: Pour produire un fichier chiffré en format ASCII base-64, ajouter l'option -a lors du chiffrement ou de la signature d'un message ou l'extraction d'une clé: pgp -sea fichier son_nom ou: pgp -kxa nom_d_utilisateur fichier_de_la_clé [fichier_de_clés] Pour effacer complètement le fichier en clair après avoir produit le fichier chiffré, ajoutez l'option -w lors du chiffrement ou de la signature d'un message: pgp -sew message.txt son_nom Pour spécifier qu'un fichier en clair contient du texte ASCII et non du binaire, et qu'il faut le convertir aux conventions locales de lignes de texte, ajouter l'option -t (texte) aux autres options: pgp -seat message.txt son_nom Pour voir le fichier dechiffré sur votre écran (comme la command "more" de style Unix), sans l'écrire dans un fichier, utilisez l'option -m (more) lors du déchiffrement: pgp -m ciphertextfile Pour specifier que le texte déchiffré du destinataire sera affiché SEULEMENT sur son écran et ne peut pas être sauvegardé sur disque, ajouter l'option -m: pgp -steam message.txt son_nom Pour récuperer le nom de fichier en clair originel lors du déchiffrement, ajouter l'option -p: pgp -p fichier_chiffré Pour utiliser un mode filtre au style Unix, lisant l'entrée standard et écrivant sur la sortie standard, ajouter l'option -f: pgp -feast son_nom < fichier_entrée > fichier_sortie rom you, but not your public key. (PGP can't use the signatures in this case. Only signatures from keys in the keyring are counted.) PGP still can't use the signatures, but prints better warning messages. Also, adding a key on your secret key ring to your keys.asc1004440006630000000000001325205632000372007425 037777703401 1 0 -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.6.1 mQCPAi5foXwAAAEEAKveIgaIckDkY8axVvUqiGr8cIisikCvtMZLHMKfiPpU4ryK Q73Or2Lq90UGyEgQ/xqk22BhdV29F/ak5tl0Uu5U+Uu4zSJwzf09IMD5Yffb7waJ uvG/hguDQsm2i6zH2FJCbOS/f7DYxmBc+gnxHUjl4nOGMfRTHsUtR20Nv5BtABEB AAG0IUplZmZyZXkgSS4gU2NoaWxsZXIgPGppc0BtaXQuZWR1PokAlQIFEC5f/Xxl eYS4x6lm3QEBih0D/3QVkk1dBQickZr4YoQu2a4gJrbeKr3n2PB/jJsJLk9wnYpQ TYBBVQej99hKJwKz1480YXqlQnAu3XdeT3KE3y5gNLuMgTTSxYloQrVoMfMNUmdR Jb6IWhdbaIjBMEIuoo/cyrM0HSHpSDXud4oLy8itGSQGU0odg10FZBPyydfjiQBu AgUQLmIlWjh0K1zBsGrxAQHE+wLECreKJ8/4jkmGaM2h3+FBs7gGqPaI2dHLOixE /fHIIKmsc+8Hz3LwBz18OlD0yjOOt3BnWinR04yGznBMvxxuAYBiOyKe4LT6U4OK 1MbjHDO+ved+ZRaUI8qJAFUCBRAuX6KVVQVm+k0MTuEBAaK7Af99N+xzv34Lrl2z kOq7T+XNQSWLY4KQGJallsBfOyGEWm71pLk0nkYfODCmPRwYcceZY3DjvhWMYcHU 4UjPgfbJmQBNAiquwMAAAAECALC76HwzAONUnaxlyj1TWJphHqDvZ5RB+EmFDJ7W SyEuj8tq0P8iZcRV5Ut1W9tQO7I07DtJJq/BVQVm+k0MTuEABRG0IUplZmZyZXkg SS4gU2NoaWxsZXIgPGppc0BtaXQuZWR1PokAVQIFEC4PFI1VBWb6TQxO4QEBLLAB /jj87kO4q1keDjr31TeW1WfgKdK74KJuPpGOc+LbHm2LMcwkFHOfqOnmGXhcfKoV Nsgn9pJ3b4O1HGStYqqO9p2JAG0CBRAuA8BpOHQrXMGwavEBAZHcAr9OSuky0Q7F vYRqwaEgJa1sZas57Vo0P1yodaBmnfZ30YKF7oE3SWkR4OKcYermcqVm7caUc3e/ 2hZD+adrHFKJ7+Tv4ll9mCX5GfhscE9BEjic1pEgflwviQCVAgUQLcsT6WV5hLjH qWbdAQFfLgP8DcWe3Qomntz36soV9XviJ6VF+9q+CFKnjG8KkVb/FMBX1MBSgU/1 BpuY+ByMUWCiJqt8VM9ewkfxyjzbuTO7jrt6Kx48PPEATHQ2jmG6AwzbZfL1jNYD sPpgEXw8oIFK6NxHtCRwjsyXNWGSWwHw5DHsSLIk3Pujumqc96PqQreZAI0CLJpN ugAAAQQAvcM6LPKBzEB7o7J9y4xmHZefJ+qYsoUMChfT8Unj53Z+vDzlO5dz+Tmp 8NaL4BAJ0lo1VPyOWDptLQcPnmAuhX5vpVnHMikdYqpedwD2K519mZGu3HgSzzaf ylMG3Fru9xA+EJd+N+X6U4ysgKRG4P/EH/1fX9dFtnsL4Ad4M40ABRG0IVBoaWxp cCBMLiBEdWJvaXMgPGR1Ym9pc0Bjc24ub3JnPokAlQIFECzDhPFleYS4x6lm3QEB PQ4D/0igIFksWkX2WFXX56kGLj2HKSId59F1DBseYtr2Q7SC56l2TIWLySoksSo8 RQitG2JlUeI4svCRNGsUdXur2UC4RMkwMgOJ95XU79MZWMyIgUYo6413MHLKJ2Op 2U8W09m0VvN9+L0GiZNvw7fGbZwGibHGqxXzZTccN0BdpjlfmQCNAi3L864AAAEE AKRe8j9QUqL4PDQSsliTKQ0yTkdLL8BFBm7c03RC9Ol5PP9Kj/RtnsdxFMTtW7wk MwTpY1jF23HR+x54LrOpi8ig6HEmiXVVWuNByRjSMgz8jvrnMM0/tIOCPAgNMxiA NUWqretPEWCZE9sLbylkJrrOd54ZKyXBTw/D7AL7u4qxAAURtCFDb2xpbiBQbHVt YiA8Y29saW5Abnl4LmNzLmR1LmVkdT6JAJUCBRAtyxCUZXmEuMepZt0BAeiyA/4t NXz6loqEwyMv65TMGtqxTlT5ocGNzyE8mkZXvbmoS0m7sdsdaVBvHfK8lrkQz/an rzAHJMBOaZ0V6T7aCLAK6GnjHoeanP8ZyhaXpc2e7EVut4ZihCpmq45uiA/1diwL XhC8OoHwKqZDT+uNnJLLdlAzrJiOaELAzXXeOvtMXokAlQIFEC3L+zgPw+wC+7uK sQEBDZkEAJYkHK5n02GXLwEEgFKpxQvWLqI2xz33rPDa0eT6+RYMDcr/1vzTqX7C wNpCuTaFTVNRbRznvwNTDcQXVsnyPg5yGdRIIMPnWuGfgSEP7vjm8zzvfdh5te4a g6jobCN1PVyqIIxIV5S8iPv632gm4vQboJiQ+4+53qoSWJ6BNDq9mQCNAiv8ZoAA AAEEAKc4d45hN5qFM79nWGLkrGWputWmtdxJk0BZEbi0kNRbJBC2p10ASImd//cC DwLR2alBUSt8O2WGik9PBZgthjMOenoDmzKiG8BkE9AFKonyxvD2lDnqbydXi+YQ mOTsWSw4jTTSb3cflhVkf8hVUVpMFQThafV0CmV5hLjHqWbdAAURtCJQaGlsaXAg Ui4gWmltbWVybWFubiA8cHJ6QGFjbS5vcmc+iQCVAgUQLmNph8UtR20Nv5BtAQE4 oQP+JfQPX1pK7xzBsFaWgq3pOKP1VS0JUlTkICKWtBlGzmH+nRgIW+gxQi/wm06A rYoZaxS7JEXaQyBnhfifqfo5aYndUyLOHttNebUhZdxHH3wna/MeSV6gdMwp1zRf vCJdBcl6XPITfgpXGlAdoxLKJmrAKXO3Lku3+0wLftMdMMWJAFUCBRAt5NU3VQVm +k0MTuEBASymAf4vSNwK14mEFbc3AlpfKDMM/gur8k2TZfs+DLnAY+y2UFnnwQyS b6aA/k9lMb+nHcPIWwxy4FA/7Fl+vFaB7XvXiQCVAgUQLcsZi2V5hLjHqWbdAQG5 MwP+JpON7uYDwHaFWzw8MzVnaeE53agwfAYkjh/LwftJBJU8dXcGVFmmQii7T+9s Rlj1vxaVSb1AQRNZkQyYpiAdlNsTOSQW2rTM2qB+y45Gh7brZz+ltih82syadiiT sre8gCiptRXomVFEnSijfL7wgyJ+Oc1kp+A2kaYkMIxOHwyZAGYCKsJc8AAAAQLF GlQ+izw4Q2hVZgSSlpmbhhcq7WSFdmL/7pR+o+qQxdcBJBfuCqKVGpMQwMzWx2r3 6fhVam9dkCS1g+ZlvdU4FsKYvcksoMZsJ7GOOpvrbKgwOHQrXMGwavEABRG0HkRl cmVrIEF0a2lucyA8d2FybG9yZEBNSVQuRURVPokAlQIFEC5jY//FLUdtDb+QbQEB qGkD/RmHigt5gwsVyKMuW1OjoW4O49qzp4bL51rmUc49R+3uWANnQB2O8QMaJB0A awh9GNysqUhNAHGOiVRl6A31P8L6I9vHq6Ld/PzKZ4bbLEu9yXf+d6rea+TOGos8 +OoX0BYtgME/RnqXjcikAqk9O3CyhT6VjwvRCTSYllK5p5+diQBVAgUQLc5bw1UF ZvpNDE7hAQHqOwH+MWWXHP2uAdtx6A2NeU3jzQo7qWUBRH7nH6fhTnZXGSrOUDaI q6vHIxbmW59v4Unf2/Xo/uHQzcD1E2x0dEaB2okAlQIFEC3LE1VleYS4x6lm3QEB NVID/AvJWCfuYIMhO6FP3vvUkcUzCRRpbuzaFvzzxaLg/y761SmhCX2+SY0FC2T+ Ifm4YEEkgoEsBbk2ADqLFQ8OC51c98PH8bdcbqkd+IfZKOgBRXOMd1dRrj735LHm WzH9krKDZvrD16DTWIKcemgQE8hbqXg1u7MjeTvKxtn2ZR2xmQCNAipswZkAAAEE AMrcqvIwyKcvxWjFbUIq7/hhzWTrpeThdIxJl7T6P1sX9U6axBhSa1qE8LxwzTZ7 /fhqaUlcZbrho5WODDqge325k7c2DCiIGxG+awndQR7a6X28/U05aQXQiMnS+IgD OLo6gCtGUFoLDoUob5AuljqHlOrQovmoIPTKAIGN5yLZAAURtCVCcmFua28gTGFu a2VzdGVyICA8YnJhbmtvQGhhY2t0aWMubmw+iQCVAgUQLcsTE2V5hLjHqWbdAQFl YwP+OvXEwiquFvhalOxWpHttWoz0qBkDNxTSVheGpQ2q3sr3P+9lkj9GcIPmrt8J /cHSIGt8RkI8bXgk315EKr4ZN2KtxjwKVU1qJdQFkF/mUyIn8b5NQNLERBQEgzUK KVz3P+q26elraAssXFClfqv5qgfknjrRf859B9L4AQmHSuyJAJUCBRAs29vt9MoA gY3nItkBAXiJA/9YnfRefE3rTmM3wXBYPh05Hk8G4GBndP6b2lwMl6b2MvYIWj+m IXsfWQp8Q8M72KveOfiwHciiOCJWHwuAcEsTXvXeq0TBBDSycCIbO7IbeJUgPgcZ 3sFsUFlJmgRYpBi7Ekg6Mke7vi3I6wo2AFt6Ghld8A49rsb7OIbcvoSlVJkAjQIq ezKiAAABBADWbUO71XAVqN9dlef3kGRtlsSA9gnOkoRCzVlo4hFvO792Ie/Y1p/c 5pz2YAyU+9C0beZHVWHwofAdUmdpF3iz2q+4viODLN2UbD2E7hoPjm3HLLjgiRCK y7lBjtEofLm0TU2mSuAZOR4zKaNcCRcRcSCYtAiJZA/6EarpnZl9RwAFEbQlUGV0 ZXIgR3V0bWFubiA8cGd1dDFAY3MuYXVrdW5pLmFjLm56PokAlQIFEC1Ud0JleYS4 x6lm3QEBMUUD/it8o2hsPRtN2yJzmMKsHyHaQuD+Yk30A9ZYGtf1Ae5ovL8LpzZC azqkn3G45al9nJHAw/Tg4jFXy66qAqw6bFHNlE9QXe1lnD1oEgsOvY5lXY5qJy3W 61JnGehwUwV26A5tcPhUUSpQ8F3VI+eZw1A1ia8wjU9wPdkCl1IHaGqymQCNAi4Y TcEAAAED+wW6b+oQQ+L67ocahdIs5HcQj8h+RjXne50SElSmlkmLnxZG1N+OO/Qz mmOkoiEnWTxkGDS90BPCN3yQ8KfiqsedYzFThb+C8J8M7zRNbIFwFPC5wl6g4EdN hDRVcZJIUinTzD7urOKZ4tg1WcPq4yN4ki6bBv8i4fiGKLV9Y6XFAAURtBlIYWwg QWJlbHNvbiA8aGFsQG1pdC5lZHU+iQCVAwUQLmgAUsUtR20Nv5BtAQF74wQAiTR0 LSRUgO0xr6c4OUxJz33Zs7rbfIj742uu4uHqCScaDafkNoHdl67r8sKR3i/RAQW/ FmEPL1e1uNegfRnFPxF7aCrjAfeQDiUpvW3f/s0LHHA3fzjov4+7GNW/WOA0mT2o nEMf3CD9WuWKu+MJ4p3xlrC5SATCv+mcxPs9CIqJAJUCBRAuN1ZiZXmEuMepZt0B AS0yA/9ofY0cYfNnbmGhJipl3wxGLtEsIQiiSuTt5GNhnOyJ04IcwYZ59SPGhYWv de0zcTDREHmU57HUAI2bWVEuMfDvjQVVjSAfAysjwBNzFB0nhf2wiZY72rk5+A0U EZmSAghMdxQvPqt5JM2LpnrhhHV5wcEGMHLCL8EFZfpLC/Qpew== =tFny -----END PGP PUBLIC KEY BLOCK----- armure ASCII en plusieurs parties: sauvegarder toutes les parties dans l'ordre correct dans un ficher avec une extension .asc, puis tapez: pgp fichier_armure [-o fichier_en_clair] --- Fonctions de gestion des clés: Pour générer votre propre paire de clés publique/secrète: pgp -kg Pour ajouter le contenu d'un fichier de clés à votrelanguage.txt1004440006630000000000020664705570230344010327 037777703401 1 0 # PARTIAL translation file for PGP 2.6 # This is the set of strings from PGP 2.6, merged with the # translation file from PGP 2.3a. Some strings have been # updated where the change is only in formatting or spacing, # but others need work. # The format should be obvious. It should serve as a good starting # point for anyone who wants to provide a full translation. # The untranslated strings are marked with "No translation". # ------------------------------------------------------------------ # Language: French # Character set: 7-bit ASCII, with digraphs # Converted to ISO Latin-1 by Colin Plumb # Date revised: June 1993 # Translator: Jean-loup Gailly # ------------------------------------------------------------------ # Language/Idioma: Castilian spanish/Castellano # Date/Fecha: June 1993 # Translator/Traductor: Armando Ramos # Address/Direcci¢n: Boix y Morer 9, Oficina 4 # E-28003-Madrid # Spain-Espa¤a/EC # Phone/Tel‚fono: 34-1-352-3090 # Fax: 34-1-535-2685 #------------------------------------------------------------------ "\nClear signature file: %s\n" es: "\nFichero normal con firma: %s\n" fr: "\nFichier de signature en clair: %s\n" "\nTransport armor file: %s\n" es: "\nFichero con armadura de transporte: %s\n" "\nClear signature file: %s\n" fr: "\nFichier de signature en clair: %s\n" es: "\nFichero normal con firma: %s\n" "\nTransport armor file: %s\n" fr: "\nfichier de transport armure: %s\n" es: "\nFichero con armadura de transporte: %s\n" "\nTransport armor files: " fr: "\nfichiers de transport armure: " es: "\nFicheros con armadura de transporte: " "ERROR: Bad ASCII armor checksum in section %d.\n" fr: "ERREUR: mauvaise v\351rification de l'armure ASCII dans la section %d.\n" es: "ERROR: Suma incorrecta de verificaci\363n en la armadura ASCII, secci\363n %d.\n" "Can't find section %d.\n" fr: "Section %d introuvable.\n" es: "No puede encontrarse la secci\363n %d.\n" "Badly formed section header, part %d.\n" fr: "En-t\352te de section mal form\351e, partie %d.\n" es: "Cabecera de secci\363n mal construida en la parte %d.\n" "Sections out of order, expected part %d" fr: "Sections en d\351sordre, partie %d attendue" es: "Las secciones est\341n desordenadas, se esperaba la parte %d" ", got part %d\n" fr: ", partie %d obtenue\n" es: ", encontrada la parte %d\n" "ERROR: Hit EOF in header of section %d.\n" fr: "ERREUR: find de fichier dans l'en-t\352te de la section %d.\n" es: "ERROR: Hay un EOF (fin de fichero) en la cabecera de la secci\363n %d.\n" "ERROR: Badly formed ASCII armor checksum, line %d.\n" fr: "ERREUR: Verification de l'armure ASCII mal form\351e, ligne %d.\n" es: "ERROR: Suma de verificaci\363n mal construida en la armadura ASCII, l\355nea %d.\n" "WARNING: No ASCII armor `END' line.\n" fr: "ATTENTION: Pas de ligne `END' dans l'armure ASCII.\n" es: "ADVERTENCIA: No hay l\355nea `END' en la armadura ASCII.\n" "ERROR: Bad ASCII armor character, line %d.\n" fr: "ERREUR: Mauvais charact\350re dans l'armure ASCII, ligne %d.\n" es: "ERROR: Car\341cter incorrecto en la armadura ASCII, l\355nea %d.\n" "ERROR: Bad ASCII armor line length %d on line %d.\n" fr: "ERREUR: Mauvais longueur de ligne %d dans l'armure ASCII, ligne %d.\n" es: "ERROR: Longitud incorrecta (%d) de l\355nea en la armadura ASCII, l\355nea %d.\n" "ERROR: Bad ASCII armor checksum" fr: "ERREUR de v\351rification dans l'armure ASCII" es: "ERROR: Suma incorrecta de verificaci\363n en la armadura ASCII" " in section %d" fr: " dans la section %d" es: " en la secci\363n %d" "Warning: Transport armor lacks a checksum.\n" fr: "Attention: l'armure de transport n'a pas de v\351rification.\n" es: "Aviso: La armadura de transporte no tiene suma de verificaci\363n.\n" "ERROR: Can't find file %s\n" fr: "ERREUR: Fichier %s introuvable\n" es: "ERROR: No se puede encontrar el fichero %s\n" "ERROR: No ASCII armor `BEGIN' line!\n" fr: "ERREUR: Pas de ligne `BEGIN' dans l'armure ASCII!\n" es: "ERROR: No hay l\355nea 'BEGIN' en la armadura ASCII\n" "\n\007Unable to write ciphertext output file '%s'.\n" fr: "\n\7Ecriture impossible dans le fichier de sortie chiffr\351 '%s'.\n" es: "\n\7No puede escribirse el fichero de salida cifrado '%s'.\n" "ERROR: ASCII armor decode input ended unexpectedly!\n" fr: "ERREUR: fin pr\351matur\351e du fichier armure ASCII!\n" es: "ERROR: La entrada con armadura ASCII termina antes de tiempo\n" "ERROR: Hit EOF in header.\n" fr: "ERREUR: fin de fichier dans l'en-t\352te.\n" es: "ERROR: Hay un EOF (fin de fichero) en la cabecera.\n" "Unsupported character set: '%s'\n" fr: "Table de caract\350res non support\351e: '%s'\n" es: "Conjunto de caracteres no admitido: '%s'\n" "\007\nWARNING: This key has been revoked by its owner,\n\ possibly because the secret key was compromised.\n" fr: "\7\nATTENTION: cette cl\351 a \351t\351 r\351voqu\351e par son propri\351taire,\n\ probablement parce que la cl\351 secr\350te a \351t\351 compromise.\n" es: "\7\nADVERTENCIA: Esta tecla ha sido revocada por su propietario,\n\ seguramente porque se ha visto comprometida la clave secreta.\n" "This could mean that this signature is a forgery.\n" fr: "Ceci peut signifier que cette signature est un faux.\n" es: "Puede significar que esta firma est\351 falsificada.\n" "You cannot use this revoked key.\n" fr: "Vous ne pouvez pas utiliser cette cl\351 r\351voqu\351e.\n" es: "No puede utilizar esta clave revocada.\n" "\007\nWARNING: Because this public key is not certified with a trusted\n\ signature, it is not known with high confidence that this public key\n\ actually belongs to: \"%s\".\n" fr: "\7\nATTENTION: Cette cl\351 publique n'est pas certifi\351e avec une\n\ signature fiable. Il n'est donc pas reconnu avec un haut degr\351 de confiance\n\ que cette signature appartient effectivement \340: \"%s\".\n" es: "\7\nAVISO: Esta clave p\372blica no est\341 certificada con una firma de confianza,\n\ por lo que no se sabe con seguridad si realmente pertenece a:\n\ \"%s\".\n" "\007\nWARNING: This public key is not trusted to actually belong to:\n\ \"%s\".\n" fr: "\7\nATTENTION: Cette cl\351 publique n'est pas reconnue comme\n\ appartenant \340: \"%s\".\n" es: "\7\nADVERTENCIA: No se sabe con seguridad si esta clave p\372blica pertenece\n\ realmente a: \"%s\".\n" "\007\nWARNING: Because this public key is not certified with enough trusted\n\ signatures, it is not known with high confidence that this public key\n\ actually belongs to: \"%s\".\n" fr: "\7\nATTENTION: puisque cette cl\351 publique n'est pas certifi\351e avec\n\ suffisament de signatures, il n'est pas connu avec un haut niveau de confiance\ \nque cette cl\351 appartient effectivement \340: \"%s\".\n" es: "\7\nADVERTENCIA: Esta clave no est\341 certificada con suficientes firmas\n\ fiables, por lo que no se sabe con seguridad si realmente pertenece a:\n\ \"%s\".\n" "But you previously approved using this public key anyway.\n" fr: "Mais vous avez d\351j\340 accept\351 l'usage de cette cl\351 publique.\n" es: "Ya ha permitido que se utilice esta clave p\372blica anteriormente.\n" "\nAre you sure you want to use this public key (y/N)? " fr: "\nEtes vous s\373r(e) de vouloir utiliser cette cl\351 publique (o/N)? " es: "\n\277Est\341 seguro/a de querer utilizar esta clave p\372blica (s/N)? " "\n\007Unsupported packet format - you need a newer version of PGP for this file.\n" No translation No translation "Preparing random session key..." fr: "Pr\351paration de la cl\351 al\351atoire..." es: "Preparando la clave para la sesi\363n aleatoria..." "\n\007Error: System clock/calendar is set wrong.\n" fr: "\n\7Erreur: L'horloge du syst\350me est incorrecte.\n" es: "\n\7Error: El reloj/calendario del sistema est\341 equivocado.\n" "Just a moment..." fr: "Un moment..." es: "Un momento..." "\a\nError: key is too large. RSA keys may be no longer than 1024 bits,\n\ due to limitations imposed by software provided by RSADSI.\n" No translation No translation "\n\007Can't open input plaintext file '%s'\n" fr: "\n\7Ouverture du fichier en clair '%s' impossible.\n" es: "\n\7No puede abrirse el fichero normal de entrada '%s'\n" "\n\007Can't open plaintext file '%s'\n" fr: "\n\7Ouverture du fichier en clair '%s' impossible\n" es: "\n\7No puede abrirse el fichero normal '%s'\n" "\n\007Can't create signature file '%s'\n" fr: "\n\7Cr\351ation du fichier de signature '%s' impossible\n" es: "\n\7No puede crearse el fichero de firma '%s'\n" "\n\007Can't open key ring file '%s'\n" fr: "\n\7Ouverture du fichier de cl\351 '%s' impossible\n" es: "\n\7No puede abrirse el anillo de claves '%s'\n" "This key has already been revoked.\n" fr: "Cette cl\351 a d\351j\340 \351t\351 r\351voqu\351e.\n" es: "Esta clave ya ha sido revocada.\n" "\n\007Can't create output file to update key ring.\n" fr: "\n\7Impossible de cr\351er le fichier de sortie pour modifier le\ \nfichier de cl\351s\n" es: "\n\7No puede crearse el fichero de salida para actualizar el anillo.\n" "\nKey compromise certificate created.\n" fr: "\nCertificat de compromission de cl\351 cr\351\351.\n" es: "\nCreado el certificado de compromiso de la clave.\n" "\nError: Key for signing userid '%s'\n\ does not appear in public keyring '%s'.\n\ Thus, a signature made with this key cannot be checked on this keyring.\n" No translation No translation "\nLooking for key for user '%s':\n" fr: "\nRecherche de la cl\351 pour l'utilisateur '%s':\n" es: "\nBuscando la clave de '%s':\n" "\n\007Key is already signed by user '%s'.\n" fr: "\n\7La cl\351 est d\351j\340 sign\351e par l'utilisateur '%s'.\n" es: "\n\7La clave ya ha sido firmada por el usuario '%s'.\n" "\n\nREAD CAREFULLY: Based on your own direct first-hand knowledge, are\n\ you absolutely certain that you are prepared to solemnly certify that\n\ the above public key actually belongs to the user specified by the\n\ above user ID (y/N)? " fr: "\n\nLIRE ATTENTIVEMENT: Selon votre propre connaissance directe,\n\ \352tes vous absoluement certain(e) d'\352tre pr\352t(e) \340 certifier\n\ solennellement que la cl\351 publique ci-dessus appartient effectivement \340\n\ la personne sp\351cifi\351e par le nom d'utilisateur ci-dessus (o/N)? " es: "\n\nLEA ATENTAMENTE: Bas\341ndose en su conocimiento directo, \277est\341 usted\n\ absolutamente seguro de estar preparado para certificar solemnemente que\n\ la clave p\372blica anterior pertenece realmente al usuario especificado por\n\ ese identificador (s/N)? " "\nKey signature certificate added.\n" fr: "\nCertificat de signature de cl\351 ajout\351.\n" es: "\nSe ha a\361adido el certificado de firma.\n" "\n\007Can't open ciphertext file '%s'\n" fr: "\n\7Ouverture du fichier chiffr\351 '%s' impossible\n" es: "\n\7No puede abrirse el fichero cifrado '%s'\n" "\nFile '%s' has signature, but with no text." fr: "\nLe fichier '%s' \340 une signature, mais pas de texte." es: "\nEl fichero '%s' tiene firma, pero no texto." "\nText is assumed to be in file '%s'.\n" fr: "\nLe texte est suppos\351 \352tre dans le fichier '%s'.\n" es: "\nSe asume que el texto est\341 en el fichero '%s'.\n" "\nPlease enter filename of material that signature applies to: " fr: "\nEntrez le nom du fichier auquel la signature s'applique: " es: "\nIntroduzca el nombre del texto al que se refiere la firma: " "\n\007Can't open file '%s'\n" fr: "\n\7Ouverture du fichier '%s' impossible\n" es: "\n\7No puede abrirse el fichero '%s'\n" "File type: '%c'\n" fr: "Type de fichier: '%c'\n" es: "\nTipo de fichero: '%c'\n" "Original plaintext file name was: '%s'\n" fr: "Le nom originel du fichier en clair \351tait: '%s'\n" es: "El nombre del fichero original de texto normal era: '%s'\n" "\n\007WARNING: Can't find the right public key-- can't check signature integrity.\n" fr: "\n\7ATTENTION: impossible de trouver la cl\351 publique ad\351quate et de\n\ v\351rifier l'integrit\351 de la signature.\n" es: "\n\7AVISO: No se encuentra la clave p\372blica adecuada para comprobar\n\ la integridad de la firma.\n" "\007\nUnrecognized message digest algorithm.\n\ This may require a newer version of PGP.\n\ Can't check signature integrity.\n" fr: "\7\nAlgorithme de groupe de messages non reconnu.\n\ Ceci peut n\351cessiter une nouvelle version de PGP.\n\ Impossible de v\351rifier l'int\351grit\351 de la signature.\n" es: "\7\nAlgoritmo no reconocido de resumen de mensaje.\n\ Puede necesitar una versi\363n m\341s reciente de PGP.\n\ No puede comprobarse la integridad de la firma.\n" "\a\nMalformed or obsolete signature. Can't check signature integrity.\n" No translation No translation "\a\nSigning key is too large. RSA keys may be no longer than 1024 bits,\n\ due to limitations imposed by software provided by RSADSI.\n\ Can't check signature integrity.\n" No translation No translation "\n\007Error: RSA-decrypted block is corrupted.\n\ This may be caused either by corrupted data or by using the wrong RSA key.\n" fr: "\n\7Erreur: le block dechiffr\351 par RSA est endommag\351.\n\ Ceci est peut \352tre caus\351 par des donn\351es endommag\351es our par\n\ l'utilisation d'une mauvaise cl\351 RSA.\n" es: "\n\7Error: El bloque desencriptado RSA est\341 da\361ado.\n\ Puede deberse a da\361o en los datos o a utilizar una clave RSA equivocada.\n" "\007\nWARNING: Bad signature, doesn't match file contents!\007\n" fr: "\7\nATTENTION: Mauvaise signature, ne correspond pas au contenu du \ fichier!\7\n" es: "\7\nAVISO: Firma incorrecta, no coincide con el contenido del fichero\7\n" "\nBad signature from user \"%s\".\n" fr: "\nMauvaise signature de l'utilisateur \"%s\".\n" es: "\nFirma incorrecta de \"%s\".\n" "Signature made %s\n" fr: "Signature faite le %s\n" es: "Firma hecha el %s\n" "\nPress ENTER to continue..." fr: "\nAppuyez sur la touche Retour ou Entr\351e pour continuer..." es: "\nPulse ENTER (retorno) para continuar..." "\nGood signature from user \"%s\".\n" fr: "\nBonne signature de l'utilisateur \"%s\".\n" es: "\nFirma correcta de \"%s\".\n" "\nSignature and text are separate. No output file produced. " fr: "\nLa signature et le texte sont s\351par\351s. Fichier de sortie non produit." es: "\nLa firma y el texto est\341n separados. No se produce fichero de salida. " "\n\007Can't create plaintext file '%s'\n" fr: "\n\7Creation du fichier en clair '%s' impossible.\n" es: "\n\7No puede crearse el fichero de texto normal '%s'\n" "\n\007Signature file '%s' already exists. Overwrite (y/N)? " fr: "\n\7Le fichier de signature '%s' existe d\351j\340. A \351craser (o/N)? " es: "\n\7El fichero de firma '%s' ya existe. \277Se sobreescribe (s/N)? " "\nWriting signature certificate to '%s'\n" fr: "\nEcriture du certificat de signature dans '%s'\n" es: "\nEscribiendo el certificado de firma para '%s'\n" "\n\007Error: Badly-formed or corrupted signature certificate.\n" fr: "\n\7Erreur: certificat de signature mal form\351 ou endommag\351\n" es: "\n\7Error: Certificado de firma incorrecto o da\361ado.\n" "File \"%s\" does not have a properly-formed signature.\n" fr: "Le fichier \"%s\" n'a pas une signature correctement form\351e.\n" es: "El fichero \"%s\" no tiene una firma construida correctamente.\n" "compressed. " fr: "comprim\351. " es: "comprimido. " "\n\007Can't create compressed file '%s'\n" fr: "\n\7Cr\351ation du fichier compress\351 '%s' impossible\n" es: "\n\7No puede crearse el fichero comprimido '%s'\n" "Compressing file..." fr: "Compression du fichier..." es: "Comprimiendo el fichero..." "\n\007Can't create ciphertext file '%s'\n" fr: "\n\7Cr\351ation du fichier chiffr\351 '%s' impossible.\n" es: "\n\7No puede crearse el fichero cifrado '%s'\n" "\nYou need a pass phrase to encrypt the file. " fr: "\nUn mot de passe est n\351cessaire pour chiffrer ce fichier. " es: "\nSe necesita una contrase\361a para encriptar el fichero. " "\n\007Cannot find the public key matching userid '%s'\n\ This user will not be able to decrypt this message.\n" fr: "\n\7Impossible de trouver la cl\351 publique pour l'utilisateur '%s'\n\ Cet utilisateur ne pourra pas d\351chiffrer ce message.\n" es: "\n\7No se puede encontrar la clave p\372blica del identificador '%s'\n\ Ese usuario no podr\341 descifrar el mensaje.\n" "Skipping userid %s\n" No translation No translation "\n\007'%s' is not a cipher file.\n" fr: "\n\7'%s' n'est pas un fichier chiffr\351.\n" es: "\n\7'%s' no es un fichero cifrado.\n" "\n\007Out of memory.\n" fr: "\n\7M\351moire insuffisante.\n" es: "\n\7No queda memoria.\n" "\nThis message can only be read by:\n" fr: "\nCe message ne peut \352tre lu que par:\n" es: "\nEste mensaje s\363lo puede ser le\355do por:\n" "\n\007You do not have the secret key needed to decrypt this file.\n" fr: "\n\7Vous n'avez pas la cl\351 secr\350te requise pour d\351chiffrer\ \nce fichier.\n" es: "\n\7Usted no tiene la clave secreta necesaria para descifrar este fichero.\n" "\n\007Error: Decrypted plaintext is corrupted.\n" fr: "\n\7Erreur: le fichier d\351chiffr\351 est endommag\351.\n" es: "\n\7Error: El texto normal desencriptado est\341 da\361ado.\n" "\nYou need a pass phrase to decrypt this file. " fr: "\nUn mot de passe est n\351cessaire pour d\351chiffrer ce fichier. " es: "\nSe necesita la contrase\361a para desencriptar este fichero. " "\n\007Error: Bad pass phrase.\n" fr: "\n\7Erreur: Mauvais mot de passe.\n" es: "\n\7Error: Contrase\361a incorrecta.\n" "Pass phrase appears good. " fr: "Le mot de passe semble correct. " es: "La frase parece correcta. " "Decompressing plaintext..." fr: "Decompression du texte en clair..." es: "Descomprimiendo el texto normal..." "\n\007Can't open compressed file '%s'\n" fr: "\n\7Ouverture du fichier compress\351 '%s' impossible.\n" es: "\n\7No puede abrirse el fichero comprimido '%s'\n" "\007\nUnrecognized compression algorithm.\n\ This may require a newer version of PGP.\n" fr: "\7\nAlgorithme de compression non reconnu.\n\ Ceci peut n\351cessiter une nouvelle version de PGP.\n" es: "\7\nAlgoritmo de compresi\363n no reconocido.\n\ Puede necesitar una nueva versi\363n de PGP.\n" "\n\007Can't create decompressed file '%s'\n" fr: "\n\7Cr\351ation du fichier d\351compress\351 '%s' impossible.\n" es: "\n\7No puede crearse el fichero descomprimido '%s'\n" "\n\007Decompression error. Probable corrupted input.\n" No translation No translation "done. " fr: "termin\351. " es: "hecho. " "y" fr: "o" es: "s" "n" fr: "n" es: "n" "\nShould '%s' be renamed to '%s' [Y/n]? " fr: "\nFaut il renommer '%s' en '%s' [O/n]? " es: "\n\277Se renombra '%s' como '%s' [S/n]? " "\nDisk full.\n" fr: "\nDisque plein.\n" es: "\nEl disco est\341 lleno.\n" "\nFile write error.\n" fr: "\nErreur d'\351criture sur fichier.\n" es: "\nError de escritura del fichero.\n" "\007Write error on stdout.\n" fr: "\7Erreur d'\351criture sur la sortie standard.\n" es: "\7Error de escritura en la salida est\341ndar (\"stdout\").\n" "\n\007Cannot create temporary file '%s'\n" fr: "\n\7Cr\351ation du fichier temporaire '%s' impossible\n" es: "\n\7No puede crearse el fichero temporal '%s'\n" "\n\007Output file '%s' already exists.\n" fr: "\n\7Le ficher de sortie '%s' existe d\351j\340.\n" es: "\n\7El fichero de salida '%s' ya existe.\n" "\n\007Output file '%s' already exists. Overwrite (y/N)? " fr: "\n\7Le fichier de sortie '%s' existe d\351j\340. A \351craser (o/N)? " es: "\n\7El fichero de salida '%s' ya existe. \277Se sobreescribe (s/N)? " "\nEnter new file name: " fr: "\nEntrez le nouveau nom de fichier: " es: "\nIntroduzca el nuevo nombre de fichero: " "Can't create output file '%s'\n" fr: "Cr\351ation du fichier '%s' impossible.\n" es: "No puede crearse el fichero '%s'\n" "New signature from keyID %s on userid \"%s\"\n" fr: "Nouvelle signature de la cl\351 %s sur l'utilisateur \"%s\"\n" es: "Nueva firma de la clave %s para el usuario \"%s\"\n" "New signature from %s\n" fr: "\nNouvelle signature de %s\n" es: "Nueva firma de %s\n" "on userid \"%s\"\n" fr: "pour le nom d'utilisateur \"%s\"\n" es: "en el identificador \"%s\"\n" "Key revocation certificate from \"%s\".\n" fr: "Certificat de r\351vocation de cl\351 de \"%s\".\n" es: "Certificado de revocaci\363n de clave de \"%s\".\n" "\n\007WARNING: File '%s' contains bad revocation certificate.\n" fr: "\n\7ATTENTION: the fichier '%s' contient de mauvais certificats\n\ de r\351vocation.\n" es: "\n\7AVISO: El fichero '%s' tiene un certificado de revocaci\363n incorrecto.\n" "New userid: \"%s\".\n" fr: "Nouveau nom d'utilisateur: \"%s\".\n" es: "Nuevo identificador: \"%s\".\n" "\nWill be added to the following key:\n" fr: "\nSera ajout\351(e) \340 la cl\351 suivante:\n" es: "\nSe a\361adir\341 a la clave siguiente:\n" "\nAdd this userid (y/N)? " fr: "\nAjouter ce nom d'utilisateur (o/N)? " es: "\n\277A\361adir este identificador (s/N)? " "\n\007Can't open key file '%s'\n" fr: "\n\7Ouverture du fichier de cl\351 '%s' impossible\n" es: "\n\7No puede abrirse el fichero de claves '%s'\n" "\nKey ring file '%s' cannot be created.\n" fr: "\nCr\351ation du fichier de cl\351s '%s' impossible.\n" es: "\nNo se puede crear el anillo de claves '%s'.\n" "\nLooking for new keys...\n" fr: "\nRecherche des nouvelles cl\351s...\n" es: "\nBuscando claves nuevas...\n" "\n\007Could not read key from file '%s'.\n" fr: "\n\7Lecture impossible de la cl\351 dans le fichier '%s'.\n" es: "\n\7No ha podido leerse la clave en el fichero '%s'.\n" "\n\007Warning: Key ID %s matches key ID of key already on \n\ key ring '%s', but the keys themselves differ.\n\ This is highly suspicious. This key will not be added to ring.\n\ Acknowledge by pressing return: " fr: "\n\7Attention: l'identificateur de cl\351 %s correspond \340 une cl\351\ \nd\351j\340 dans le fichier de cl\351s '%s', mais les cl\351s sont diff\351rentes.\ \nCeci est tr\350s suspect. Cette cl\351 ne sera pas ajout\351e au fichier de cl\351s.\ \nAppuyez sur la touche Retour ou Entr\351e: " es: "\n\7Advertencia: El identificador de clave %s coincide con otro \n\ en el anillo '%s', pero las claves son distintas.\n\ Es muy sospechoso. Esta clave no se incluir\341 en el anillo.\n\ Confirme pulsando retorno: " "\nDo you want to add this key to keyring '%s' (y/N)? " fr: "\nVoulez vous ajouter cette cl\351 au fichier de cl\351s '%s' (o/N)? " es: "\n\277Quiere a\361adir esta clave al anillo '%s' (s/N)? " "Key has been revoked.\n" fr: "La cl\351 a \351t\351 r\351voqu\351e.\n" es: "La clave ha sido revocada.\n" "\n\007Key file contains duplicate keys: cannot be added to keyring\n" fr: "\n\7Le fichier contient des cl\351s dupliqu\351es: impossible\n\ de l'ajouter au fichier de cl\351s\n" es: "\n\7El fichero contiene claves duplicadas: no puede a\361adirse al anillo\n" "No new keys or signatures in keyfile.\n" fr: "Pas de nouvelles cl\351s ou signatures dans le fichier de cl\351s.\n" es: "No hay nuevas claves ni nuevas firmas en el fichero.\n" "\nKeyfile contains:\n" fr: "\nLe fichier de cl\351s contient:\n" es: "\nEl fichero de claves contiene:\n" "%4d new key(s)\n" fr: "%4d nouvelle(s) cl\351(s)\n" es: "%4d nueva(s) clave(s)\n" "%4d new signatures(s)\n" fr: "%4d nouvelle(s) signatures(s)\n" es: "%4d nueva(s) firma(s)\n" "%4d new user ID(s)\n" fr: "%4d nouveau(x) nom(s) d'utilisateur\n" es: "%4d nuevo(s) identificador(es) de usuario\n" "%4d new revocation(s)\n" fr: "%4d nouvelle(s) r\351vocation(s)\n" es: "%4d nueva(s) revocacion(es)\n" "\nNo keys found in '%s'.\n" fr: "\nPas de cl\351s trouv\351es dans '%s'.\n" es: "\nNo se encuentran claves en '%s'.\n" "\nOne or more of the new keys are not fully certified.\n\ Do you want to certify any of these keys yourself (y/N)? " fr: "\nUne ou plusieurs des nouvelles cl\351s ne sont pas compl\350tement\ \ncertifi\351es. Voulez vous certifier ces cl\351s vous m\352me (o/N)? " es: "\nUna o m\341s de las claves nuevas no est\341n completamente certificadas.\n\ \277Quiere certificar alguna de ellas usted mismo (s/N)? " "\nDo you want to certify this key yourself (y/N)? " fr: "\nVoulez vous certifier cette cl\351 vous m\352me (o/N)? " es: "\n\277Quiere certificar esta clave usted mismo/a (s/N)? " "undefined" fr: "ind\351finie" es: "sin definir" "unknown" fr: "inconnu" es: "desconocida" "untrusted" fr: "non s\373r" es: "no fiable" "marginal" fr: "marginal" es: "relativa" "complete" fr: "compl\350te" es: "completa" "ultimate" fr: "ultime" es: "fundamental" "\nCan't open backup key ring file '%s'\n" fr: "\nImpossible d'ouvrir le fichier de cl\351 de sauvegarde '%s'\n" es: "\nNo se puede abrir la copia de seguridad del anillo '%s'\n" "\n%d \"trust parameter(s)\" need to be changed.\n" fr: "\n%d \"param\350tre(s) de confiance\" doi(ven)t \352tre chang\351(s).\n" es: "\n%d \"par\341metro(s) de confianza\" hay que cambiarlo(s).\n" "Continue with '%s' (Y/n)? " fr: "Continuer avec '%s' (O/n)? " es: "\277Sigue con '%s' (S/n)? " "\n%d \"trust parameter(s)\" changed.\n" fr: "\n%d \"param\350tre(s) de confiance\" chang\351(s).\n" es: "\nCambiados %d \"par\341metro(s) de confianza.\n" "Update public keyring '%s' (Y/n)? " fr: "Modifier le fichier de cl\351s publiques '%s' (O/n)? " es: "\277Actualizar el anillo de claves p\372blicas '%s' (S/n)? " "\nCan't open secret key ring file '%s'\n" fr: "\nOuverture du fichier de cl\351s secr\350tes '%s' impossible.\n" es: "\nNo se puede abrir el anillo de claves secretas '%s'\n" "\nPass 1: Looking for the \"ultimately-trusted\" keys...\n" fr: "\nPasse 1: Recherche des cl\351s \"de confiance ultime\"...\n" es: "\nProceso 1: B\372squeda de las claves \"fundamentalmente fiables\" ...\n" "\nPass 2: Tracing signature chains...\n" fr: "\nPasse 2: V\351rification des chaines de signatures...\n" es: "\nProceso 2: Seguimiento de las cadenas de firmas...\n" "Keyring contains duplicate key: %s\n" fr: "Le fichier de cl\351s contient des cl\351s dupliqu\351es: %s\n" es: "El anillo contiene una clave duplicada: %s\n" "No ultimately-trusted keys.\n" fr: "Pas de cl\351s de confiance ultime.\n" es: "No hay ninguna clave fundamentalmente fiable.\n" " KeyID Trust Validity User ID\n" fr: " Cl\351 Confiance Validit\351 Utilisateur\n" es: " Clave Confianza Validez Usuario\n" "\n\007Cannot read from secret keyring.\n" fr: "\n\7Lecture du fichier de cl\351s secr\350tes impossible.\n" es: "\n\7No puede leerse el anillo de claves secretas.\n" "\n\007WARNING: Public key for user ID: \"%s\"\n\ does not match the corresponding key in the secret keyring.\n" fr: "\n\7ATTENTION: la cl\351 publique pour l'utilisateur: \"%s\"\n\ ne correspond pas avec la cl\351 respective dans le fichier de cl\351s\ secr\350tes.\n" es: "\n\7AVISO: La clave p\372blica del identificador \"%s\"\n\ no coincide con la clave correspondiente en el anillo de claves secretas.\n" "This is a serious condition, indicating possible keyring tampering.\n" fr: "Ceci est une condition s\351rieuse, indiquant une possible manipulation\n\ du fichier de cl\351s.\n" es: "Es una situaci\363n seria, que indica una posible manipulaci\363n de anillos.\n" "\nKey for user ID \"%s\"\n\ also appears in the secret key ring." No translation No translation "\nUse this key as an ultimately-trusted introducer (y/N)? " fr: "\nUtiliser cette cl\351 comme introducteur de confiance ultime (o/N)? " es: "\n\277Se utiliza esta clave como referencia fundamentalmente fiable (s/N)? " "Public key for: \"%s\"\n\ is not present in the backup keyring '%s'.\n" fr: "La cl\351 publique pour: \"%s\"\n\ n'est pas pr\351sente dans le fichier de cl\351s de sauvegarde '%s'.\n" es: "La clave p\372blica de: \"%s\"\n\ no est\341 en la copia de seguridad del anillo '%s'.\n" "\n\007WARNING: Secret key for: \"%s\"\n\ does not match the key in the backup keyring '%s'.\n" fr: "\n\7ATTENTION: la cl\351 secr\350te pour: \"%s\"\n\ ne correspond pas avec la cl\351 dans le fichier de cl\351s de sauvegarde.\n" es: "\n\7AVISO: La clave secreta de: \"%s\"\n\ no coincide con la clave en la copia de seguridad del anillo '%s'.\n" "\nMake a determination in your own mind whether this key actually\n\ belongs to the person whom you think it belongs to, based on available\n\ evidence. If you think it does, then based on your estimate of\n\ that person's integrity and competence in key management, answer\n\ the following question:\n" fr: "\nDeterminez vous m\352me si cette cl\351 appartient vraiment \340 la personne\ \n\340 qui vous croyez qu'elle appartient, selon les informations disponibles.\ \nSi vous le croyez, alors selon votre estimation de l'int\351grit\351 de cette\ \npersonne et de sa comp\351tence dans la gestion de cl\351s, r\351pondez \340 la\ \nquestion suivante:\n" es: "\nDecida usted mismo si esta clave realmente pertenece, seg\372n la\n\ evidencia a su alcance, a la persona que usted cree. Si es as\355,\n\ conteste la siguiente pregunta, bas\341ndose en su estimaci\363n de la\n\ integridad de esa persona y de su conocimiento sobre gesti\363n de claves:\n" "\nWould you trust \"%s\"\n\ to act as an introducer and certify other people's public keys to you?\n\ (1=I don't know. 2=No. 3=Usually. 4=Yes, always.) ? " fr: "\nAuriez vous confiance en \"%s\"\n\ pour servir d'introducteur et certifier pour vous les cl\351s publiques d'autres\ \npersonnes? (1=Ne sais pas. 2=Non. 3=G\351n\351ralement. 4=Oui, toujours.) ? " es: "\n\277Confiar\355a en \"%s\"\n\ como referencia, y para certificar ante usted otras claves p\372blicas?\n\ (1=No s\351. 2=No. 3=Normalmente. 4=S\355, siempre.) ? " "This user is untrusted to certify other keys.\n" fr: "Cet utilisateur n'est pas de confiance pour certifier d'autres cl\351s.\n" es: "Este usuario no es fiable para certificar otras claves.\n" "This user is generally trusted to certify other keys.\n" fr: "Cet utilisateur est g\351n\351ralement de confiance pour certifier d'autres\ cl\351s.\n" es: "Este usuario es de relativa confianza para certificar otras claves.\n" "This user is completely trusted to certify other keys.\n" fr: "Cet utilisateur est de confiance totale pour certifier d'autres cl\351s.\n" es: "Este usuario es de completa confianza para certificar otras claves.\n" "This axiomatic key is ultimately trusted to certify other keys.\n" fr: "Cette cl\351 axiomatique est de confiance ultime pour certifier\n\ d'autres cl\351s\n" es: "Esta clave axiom\341tica es absolutamente fiable para certificar otras.\n" "This key/userID association is not certified.\n" fr: "Cette association cl\351/utilisateur n'est pas certifi\351e.\n" es: "Esta asociaci\363n clave/usuario no est\341 certificada.\n" "This key/userID association is marginally certified.\n" fr: "Cette association cl\351/utilisateur est marginalement certifi\351e.\n" es: "Esta asociaci\363n clave/usuario est\341 relativamente certificada.\n" "This key/userID association is fully certified.\n" fr: "Cette association cl\351/utilisateur est compl\350tement certifi\351e.\n" es: "Esta asociaci\363n clave/usuario est\341 completamente certificada.\n" " Questionable certification from:\n " fr: " Certificat de confiance douteux de:\n " es: " Certificaci\363n cuestionable de:\n " " Untrusted certification from:\n " fr: " Certificat non s\373r de:\n " es: " Certificaci\363n no fiable de:\n " " Generally trusted certification from:\n " fr: " Certificat de confiance relatif de:\n " es: " Certificaci\363n relativamente fiable de:\n " " Completely trusted certification from:\n " fr: " Certificat de confiance complet de:\n " es: " Certificaci\363n completamente fiable de:\n " " Axiomatically trusted certification from:\n " fr: " Certificat de confiance par axiome de:\n " es: " Certificaci\363n axiom\341ticamente fiable de:\n " "\nKey for user ID: %s\n" fr: "\nCl\351 pour le nom d'utilisateur: %s\n" es: "\nClave del usuario: %s\n" "%d-bit key, Key ID %s, created %s\n" fr: " Cl\351 de %d bits, identificateur de cl\351 %s, cr\351\351e le %s\n" es: " Clave de %d bits, con identificador %s, creada el %s\n" "Bad key format.\n" fr: "Mauvais format de cl\351\n" es: "Formato de clave incorrecto.\n" "Unrecognized version.\n" fr: "Version non reconnue.\n" es: "Versi\363n no reconocida.\n" "Key is disabled.\n" fr: "La cl\351 est inactiv\351e.\n" es: "La clave est\341 desactivada.\n" "Also known as: %s\n" fr: "Egalement connu(e) en tant que: %s\n" es: "Tambi\351n conocido/a como: %s\n" " Certified by: " fr: " Certifi\351e par: " es: " Certificado por: " "\n\007Unable to create key file '%s'.\n" fr: "\n\7Impossible de cr\351er le fichier de cl\351s '%s'.\n" es: "\n\7No puede crearse el fichero de claves '%s'.\n" "\n\007Keyring file '%s' does not exist. " fr: "\n\7Le fichier de cl\351s '%s' n'existe pas. " es: "\n\7El anillo '%s' no existe. " "\n\007Sorry, this key has been revoked by its owner.\n" fr: "\n\7D\351sol\351, cette cl\351 a \351t\351 r\351voqu\351e par son propri\351taire.\n" es: "\n\7Esa clave ha sido revocada por su propietario.\n" "\nKey for user ID \"%s\"\n\ has been revoked. You cannot use this key.\n" fr: "\nLa cl\351 pour l'utilisateur \"%s\"\n\ a \351t\351 r\351voqu\351e. Vous ne pouvez utiliser cette cl\351.\n" es: "\nLa clave del ID de usuario \"%s\"\n\ ha sido revocada. No puede utilizarla.\n" "\n\007Key matching expected Key ID %s not found in file '%s'.\n" fr: "\n\7Cl\351 correspondant \340 l'identificateur %s non trouv\351e\ \ndans le fichier '%s'.\n" es: "\n\7La comprobaci\363n esperaba un identificador de clave %s que\ \nno se encuentra en '%s'.\n" "\n\007Key matching userid '%s' not found in file '%s'.\n" fr: "\n\7Cl\351 correspondant \340 l'utilisateur '%s' introuvable\n\ dans le fichier '%s'.\n" es: "\n\7La clave correspondiente al usuario '%s'\n\ no se encuentra en el fichero '%s'.\n" "Enter secret key filename: " fr: "Entrez le nom du fichier de cl\351s secr\350tes: " es: "Introduzca el nombre del fichero de claves secretas: " "Enter public key filename: " fr: "Entrez le nom du fichier de cl\351s publiques: " es: "Introduzca el nombre del fichero de claves p\372blicas: " "\nYou need a pass phrase to unlock your RSA secret key. " fr: "\nVous devez avoir un mot de passe pour utiliser votre cl\351 secr\350te RSA." es: "\nSe necesita la contrase\361a para abrir la clave secreta RSA. " "\nKey for user ID \"%s\"\n" fr: "\nCl\351 pour l'utilisateur \"%s\"\n" es: "\nClave del identificador de usuario \"%s\"\n" "No passphrase; secret key unavailable.\n" No translation No translation "\nAdvisory warning: This RSA secret key is not protected by a passphrase.\n" fr: "\nAttention: cette cl\351 secr\350te RSA n'est pas prot\351g\351e par un mot \ de passe" es: "\nAdvertencia: Esta clave secreta RSA no tiene frase de contrase\361a.\n" "Pass phrase is good. " fr: "Le mot de passe est correct. " es: "La frase es correcta. " "\n\007Key file '%s' is not a secret key file.\n" fr: "\n\7Le fichier de cl\351 '%s' n'est pas un fichier de cl\351s secr\350tes.\n" es: "\n\7El fichero '%s' no tiene claves secretas.\n" "Key fingerprint =" fr: "Empreinte de la cl\351 =" es: "Huella dactilar de la clave =" "\nKey ring: '%s'" fr: "\nFichier de cl\351: '%s'" es: "\nAnillo de claves: '%s'" ", looking for user ID \"%s\"." fr: ", recherche du nom d'utilisateur \"%s\"." es: ", buscando el identificador \"%s\"." "\nType bits/keyID Date User ID\n" fr: "\nType bits/ident. Date Utilisateur\n" es: "\nTipo bits/idclave Fecha Usuario\n" "*** KEY REVOKED ***\n" fr: "*** CLE' REVOQUE ***\n" es: "*** CLAVE REVOCADA ***\n" "(Unknown signator, can't be checked)\n" fr: "(Signataire inconnu, ne peut \352tre v\351rifi\351)\n" es: "(Firmante desconocido, no puede comprobarse)\n" "1 matching key found.\n" No translation No translation "%d matching keys found.\n" No translation No translation "\nChecking signatures...\n" fr: "\nV\351rification des signatures...\n" es: "\nComprobando las firmas...\n" "(Unknown signator, can't be checked)" No translation No translation "(Key too long, can't be checked)" No translation No translation "(Malformed or obsolete signature format)" No translation No translation "(Unknown public-key algorithm)" No translation No translation "(Unknown hash algorithm)" No translation No translation "(Unknown signature packet version)" No translation No translation "(Malformed signature)" No translation No translation "(Corrupted signature packet)" No translation No translation "\007**** BAD SIGNATURE! ****" fr: "\7**** MAUVAISE SIGNATURE! ****" es: "\7**** FIRMA INCORRECTA ****" "Remove bad signatures (Y/n)? " fr: "Supprimer les mauvaises signatures (O/n)? " es: "\277Suprimir las firmas incorrectas (S/n)? " "\nRemoving signatures from userid '%s' in key ring '%s'\n" fr: "\nSuppression des signatures de l'utilisateur '%s'\n\ dans le fichier de cl\351s '%s'\n" es: "\nSuprimiendo las firmas del usuario '%s'\n\ del anillo de claves '%s'\n" "\n\007Key not found in key ring '%s'.\n" fr: "\n\7Cl\351 introuvable dans le fichier de cl\351s '%s'.\n" es: "\n\7No se ha encontrado la clave en el anillo '%s'.\n" "\nKey has no signatures to remove.\n" fr: "\nLa cl\351 n'a pas de signatures \340 supprimer.\n" es: "\nLa clave no tiene ninguna firma que borrar.\n" "\nKey has %d signature(s):\n" fr: "\nLa cl\351 a %d signature(s):\n" es: "\nLa clave tiene %d firma(s):\n" "Remove this signature (y/N)? " fr: "Suppression de cette signature (o/N)? " es: "\277Suprimir esta firma (s/N)? " "\nNo key signatures removed.\n" fr: "\nPas de supression de signature de cl\351.\n" es: "\nNo se ha suprimido ninguna firma.\n" "\n%d key signature(s) removed.\n" fr: "\n%d signature(s) de cl\351 supprim\351e(s).\n" es: "\nSuprimidas %d firma(s) de clave.\n" "\nRemoving from key ring: '%s'" fr: "\nSuppression du ficher de cl\351s: '%s'" es: "\nSuprimiendo del anillo: '%s'" ", userid \"%s\".\n" fr: ", utilisateur \"%s\".\n" es: ", identificador \"%s\".\n" "\nKey has more than one user ID.\n\ Do you want to remove the whole key (y/N)? " fr: "\nLa cl\351 a plus d'un nom d'utilisateur.\n\ Voulez vous supprimier toute la cl\351 (o/N)? " es: "\nLa clave tiene m\341s de un identificador de usuario.\n\ \277Quiere suprimirla por completo (s/N)? " "\nNo more user ID's\n" fr: "\nPlus de noms d'utilisateur\n" es: "\nNo hay m\341s identificadores de usuario\n" "Remove \"%s\" (y/N)? " fr: "Supprimer \"%s\" (o/N)? " es: "\277Suprimir \"%s\" (s/N)? " "\nAre you sure you want this key removed (y/N)? " fr: "\nEtes vous s\373r(e) de vouloir supprimer cette cl\351 (o/N)? " es: "\n\277Est\341 seguro/a de querer suprimir esta clave (s/N)? " "\nUser ID removed from key ring.\n" fr: "\nNom d'utilisateur supprim\351 du fichier de cl\351s.\n" es: "\nIdentificador suprimido del anillo.\n" "\nKey removed from key ring.\n" fr: "\nCl\351 supprim\351e du fichier de cl\351s.\n" es: "\nClave suprimida del anillo.\n" "\nKey or user ID is also present in secret keyring.\n\ Do you also want to remove it from the secret keyring (y/N)? " fr: "\nLa cl\351 ou le nom d'utilisateur est aussi dans le fichier de cl\351s\n\ secr\350tes. Voulez vous l'enlever du ficher de cl\351s secr\350tes (o/N)? " es: "\nEl identificador de usuario o de clave tambi\351n est\341 en el anillo\n\ de claves secretas. \277Quiere borrarlo tambi\351n de ah\355 (s/N)? " "\nExtracting from key ring: '%s'" fr: "\nExtraction du fichier de cl\351s: '%s'" es: "\nExtrayendo del anillo de claves: '%s'" "\nExtract the above key into which file? " fr: "\nExtraire la cl\351 ci-dessus dans quel fichier? " es: "\n\277En qu\351 fichero hay que extraer la clave anterior? " "Key ID %s is already included in key ring '%s'.\n" fr: "L'identificateur de cl\351 %s est d\351j\340 pr\351sent\ \ndans le fichier de cl\351s '%s'.\n" es: "El identificador de clave %s ya est\341 en el anillo '%s'.\n" "\nKey extracted to file '%s'.\n" fr: "\nCl\351 mise dans le fichier '%s'.\n" es: "\nClave extra\355da en el fichero '%s'.\n" "\nThis operation may not be performed on a secret keyring.\n\ Defaulting to public keyring." fr: "\nCette operation ne peut pas \352tre effectu\351e sur un fichier de cl\351s\n\ secr\350tes. Le fichier de cl\351s publiques sera utilis\351 \340 la place." es: "\nEsta operacion no se puede realizar sobre el anillo de claves secretas.\n\ Dando plazo al anillo de claves p\372blicas." "\nEditing userid \"%s\" in key ring: '%s'.\n" fr: "\nModification du nom d'utilsateur \"%s\"\n\ dans le fichier de cl\351: '%s'.\n" es: "\nModificaci\363n del identificador \"%s\"\n\ en el anillo: '%s'.\n" "\nCan't open public key ring file '%s'\n" fr: "\nOuverture du fichier de cl\351s publiques '%s' impossible.\n" es: "\nNo se puede abrir el anillo de claves p\372blicas '%s'\n" "\n\007File '%s' is not a public keyring.\n" fr: "\n\7Le fichier '%s' n'est pas un fichier de cl\351s publiques.\n" es: "\n\7El fichero '%s' no es un anillo de claves p\372blicas.\n" "\n\007This key has been revoked by its owner.\n" fr: "\n\7Cette cl\351 a \351t\351 r\351voqu\351e par son propri\351taire.\n" es: "\n\7Esta clave ha sido revocada por su propietario.\n" "\nNo secret key available. Editing public key trust parameter.\n" fr: "\nPas de cl\351 secr\350te disponible. Modification du param\350tre de\n\ confiance de la cl\351 publique.\n" es: "\nNo hay clave secreta disponible. Modificando el par\341metro de confianza\n\ de la clave p\372blica.\n" "Current trust for this key's owner is: %s\n" fr: "Le niveau de confiance courant pour le propri\351taire de\n\ cette cl\351 est: %s\n" es: "La confianza actual en el due\361o de esta clave es: %s\n" "Public key ring updated.\n" fr: "Fichier de cl\351s publiques modifi\351...\n" es: "Actualizado el anillo de claves p\372blicas.\n" "\nCurrent user ID: %s" fr: "\nNom d'utilisateur courant: %s" es: "\nIdentificador actual de usuario: %s" "\nDo you want to add a new user ID (y/N)? " No translation No translation "\nEnter the new user ID: " fr: "\nEntrez le nouveau nom d'utilisateur: " es: "\nIntroduzca el nuevo identificador: " "\nMake this user ID the primary user ID for this key (y/N)? " fr: "\nEtablir ce nom d'utilisateur comme nom principal pour cette cl\351 \ (o/N)? " es: "\n\277Se establece este identificador como el principal de esta clave (s/N)? " "\nDo you want to change your pass phrase (y/N)? " fr: "\nVoulez vous changer votre mot de passe (o/N)? " es: "\n\277Quiere cambiar la contrase\361a (s/N)? " "(No changes will be made.)\n" fr: "(Aucun changement ne sera effectu\351.)\n" es: "(No se realizar\341 ning\372n cambio.)\n" "\n\007Unable to update secret key ring.\n" fr: "\n\7Impossible de modifier le fichier de cl\351s secr\350tes.\n" es: "\n\7No puede actualizarse el anillo de claves secretas.\n" "\nSecret key ring updated...\n" fr: "\nFichier de cl\351s secr\350tes modifi\351...\n" es: "\nActualizado el anillo de claves secretas ...\n" "\n\007Unable to update public key ring.\n" fr: "\n\7Impossible de modifier le fichier de cl\351s publiques.\n" es: "\n\7No puede actualizarse el anillo de claves p\372blicas.\n" "(No need to update public key ring)\n" fr: "(Pas besoin de modifier le fichier de cl\351s publiques)\n" es: "(No hay que actualizar el anillo de claves p\372blicas)\n" "\nDo you want to permanently revoke your public key\n\ by issuing a secret key compromise certificate\n\ for \"%s\" (y/N)? " fr: "\nVoulez vous r\351voquer de fa\347on permanente votre cl\351 publique\n\ en \351mettant un certificat de compromission de cl\351 secr\350te\n\ pour \"%s\" (o/N)? " es: "\n\277Quiere revocar permanentemente su clave p\372blica\n\ emitiendo un certificado de compromiso de clave secreta\n\ para \"%s\" (s/N)? " "You can only disable keys on your public keyring.\n" fr: "Vous ne pouvez inactiver des cl\351s que sur votre fichier de cl\351s\ \npubliques.\n" es: "S\363lo puede desactivar claves en el anillo de claves p\372blicas.\n" "\nKey is already disabled.\n\ Do you want to enable this key again (y/N)? " fr: "\nLa cl\351 est d\351j\340 inactiv\351e.\n\ Voulez vous r\351activer cette cl\351 (o/N)? " es: "\nLa clave ya est\341 desactivada.\n\ \277Quiere activarla otra vez (s/N)? " "\nDisable this key (y/N)? " fr: "D\351sactiver cette cl\351 (o/N)? " es: "\n\277Desactivar esta clave (s/N)? " "Pick your RSA key size:\n\ 1) 512 bits- Low commercial grade, fast but less secure\n\ 2) 768 bits- High commercial grade, medium speed, good security\n\ 3) 1024 bits- \"Military\" grade, slow, highest security\n\ Choose 1, 2, or 3, or enter desired number of bits: " No translation No translation "Generating an RSA key with a %d-bit modulus.\n" fr: "Generation d'une cl\351 RSA avec un module de %d bits.\n" es: "Generando una clave RSA con m\363dulo de %d bits.\n" "\nYou need a user ID for your public key. The desired form for this\n\ user ID is your name, followed by your E-mail address enclosed in\n\ , if you have an E-mail address.\n\ For example: John Q. Smith <12345.6789@compuserve.com>\n\ Enter a user ID for your public key: \n" fr: "\nIl vous faut un nom d'utilisateur pour votre cl\351 publique. La forme\n\ d\351sir\351e pour ce nom d'utilisateur est votre nom, suivi de votre addresse\n\ de courrier \351lectronique entre , si vous en avez une.\n\ Par exemple: Jean Dupont \n\ Entrez un nom d'utilisateur pour votre cl\351 publique\n\ (votre nom): " es: "\nNecesitar\341 un identificador para su clave p\372blica. El formato requerido\n\ consiste en su nombre, seguido de su direcci\363n de correo electr\363nico,\n\ si tiene una, entre <\341ngulos>.\n\ Por ejemplo: Juan Espannol \n\ Introduzca un identificador de usuario para su clave p\372blica: \n" "\nYou need a pass phrase to protect your RSA secret key.\n\ Your pass phrase can be any sentence or phrase and may have many\n\ words, spaces, punctuation, or any other printable characters.\n" fr: "\nVous devez avoir un mot de passe pour prot\351ger votre cl\351 RSA \n\ secr\350te. Votre mot de passe peut \352tre n'importe quelle phrase ou portion\n\ de phrase et peut avoir plusieurs mots, espaces, caract\350res de ponctuation\n\ ou tout autre caract\350re imprimable.\n" es: "\nNecesita una frase de contrase\361a para proteger su clave secreta RSA.\n\ Puede ser cualquier expresi\363n formada por varias palabras, espacios,\n\ signos de puntuaci\363n o cualquier otro car\341cter imprimible.\n" "\nNote that key generation is a lengthy process.\n" fr: "\nNotez que la g\351n\351ration de cl\351 est une proc\351dure lente.\n" es: "\nTenga en cuenta que la generaci\363n de claves es un proceso lento.\n" "\n\007Keygen failed!\n" fr: "\n\7Generation de cl\351 non r\351ussie!\n" es: "\n\7Error en la generaci\363n de claves\n" "Key ID %s\n" fr: "identificateur de cl\351 %s\n" es: "Identificador de clave %s\n" "Display secret components (y/N)?" No translation No translation "\007Key generation completed.\n" fr: "\7G\351n\351ration de cl\351 termin\351e.\n" es: "\7Generaci\363n de claves finalizada.\n" "\n\007File '%s' is not a text file; cannot display.\n" fr: "\n\7Le fichier '%s' n'est pas un fichier de texte et ne peut \352tre \ visualis\351\n" es: "\n\7El fichero '%s' no es un fichero de texto; no puede mostrarse.\n" "\nDone...hit any key\r" fr: "\nTermin\351... appuyez sur n'importe quelle touche \r" es: "\nHecho...pulse cualquier tecla\r" "More -- %d%% -- Hit space for next screen, Enter for new line, 'Q' to quit --\r" fr: "Suite -- (%d%%) -- Espace: \351cran suivant, Entr\351e: nouvelle ligne, Q: quitter\r" es: "M\341s -- %d%% -- Espacio: siguiente pantalla, Enter: nueva l\355nea, 'Q': salir --\r" "\nEnter pass phrase: " fr: "\nEntrez votre mot de passe: " es: "\nIntroduzca la frase de contrase\361a: " "\nEnter same pass phrase again: " fr: "\nEntrez le m\352me mot de passe de nouveau: " es: "\nIntroduzca la misma frase otra vez: " "\n\007Error: Pass phrases were different. Try again." fr: "\n\7Erreur: Les mots de passe \351taient diff\351rents. Essayez encore." es: "\n\7Error: Las frases son diferentes. Pruebe otra vez." "2.5" fr: "2.5" es: "2.5" "\nStopped at user request\n" fr: "\nArr\352t par demande de l'utilisateur\n" es: "\nInterrumpido a petici\363n del usuario\n" "Pretty Good Privacy(tm) %s - Public-key encryption for the masses.\n" fr: "Pretty Good Privacy(tm) %s - Cryptographie \340 cl\351 publique pour tous.\n" es: "Pretty Good Privacy(tm) %s - Criptograf\355a de clave p\372blica para todos.\n" "(c) 1990-1994 Philip Zimmermann, Phil's Pretty Good Software. %s\n" fr: "(c) 1990-1994 Philip Zimmermann, Phil's Pretty Good Software. %s\n" es: "(c) 1990-1994 Philip Zimmermann, Phil's Pretty Good Software. %s\n" "NOTE: IT IS ILLEGAL TO EXPORT THIS SOFTWARE FROM THE USA.\n" No translation No translation "\007No configuration file found.\n" No translation No translation "\007WARNING: Environmental variable TZ is not defined, so GMT timestamps\n\ may be wrong. See the PGP User's Guide to properly define TZ\n\ in AUTOEXEC.BAT file.\n" fr: "\7ATTENTION: La variable d'environnement TZ n'est pas d\351finie, les\n\ temps GMT peuvent donc \352tres faux. Voir le guide de l'utilisateur PGP pour\n\ d\351finir correctement TZ dans le fichier AUTOEXEC.BAT.\n" es: "\7ADVERTENCIA: La variable TZ no est\341 definida en el entorno, por lo\n\ tanto los sellos de fecha GMT pueden estar equivocados. V\351ase la Gu\355a del\n\ Usuario de PGP para definir adecuadamente TZ en AUTOEXEC.BAT.\n" "\nWARNING: PGP User's Guide not found. You should not use PGP\n\ without first looking at the User's Guide.\n" No translation No translation "\nFile %s wiped and deleted. " fr: "\nFichier %s effac\351 et d\351truit. " es: "\nEl archivo %s ha sido borrado y destruido. " "\nFor details on licensing and distribution, see the PGP User's Guide.\ \nFor other cryptography products and custom development services, contact:\ \nPhilip Zimmermann, 3021 11th St, Boulder CO 80304 USA, phone +1 303 541-0140\n" fr: "\nConsulter le guide de l'utilisateur de PGP pour les d\351tails de\n\ license et de distribution. Pour d'autres produits de cryptographie\n\ et services de d\351veloppement personalis\351s, contacter: Philip Zimmermann,\n\ 3021 11th St, Boulder CO 80304 USA, t\351l\351phone (19) 1 303 541 0140\n" es: "\nInformaci\363n sobre licencia y distribuci\363n en la Gu\355a del Usuario de PGP.\ \nM\341s informaci\363n sobre otros productos y servicios criptogr\341ficos a medida:\ \nPhilip Zimmermann, 3021 11th St, Boulder CO 80304 USA, tel (1-303) 541-0140\n" "@translator@" fr: "\nTraduction fran\347aise de Jean-loup Gailly, jloup@chorus.fr\n" es: "\nTraducido al castellano por Armando Ramos \n" "\nFor a usage summary, type: pgp -h\n" fr: "\nPour un sommaire d'utilisation, tapez: pgp -h\n" es: "\nPara ver un resumen de las instrucciones, escriba: pgp -h\n" "\007File [%s] does not exist.\n" fr: "\7Le fichier [%s] n'existe pas.\n" es: "\7El fichero [%s] no existe.\n" "\007Invalid filename: [%s] too long\n" fr: "\7Nom de fichier invalide: [%s] trop long\n" es: "\7Nombre incorrecto de fichero: [%s] es demasiado largo\n" "\n\007Input file '%s' looks like it may have been created by PGP. " fr: "\n\7Le fichier d'entr\351e '%s' semble avoir \351t\351 cr\351\351 par PGP. " es: "\n\7El fichero de entrada '%s' parece haber sido creado por PGP. " "\nIs it safe to assume that it was created by PGP (y/N)? " fr: "\nEtes vous s\373r qu'il a \351t\351 cr\351\351 par PGP (o/N)? " es: "\n\277Puede asumirse con seguridad que lo ha creado PGP (s/N)? " "\n\007Warning: '%s' is not a pure text file.\nFile will be treated as binary data.\n" fr: "\n\7Attention: '%s' n'est pas un fichier de texte pur.\n\ Le fichier sera trait\351 comme des donn\351es binaires.\n" es: "\n\7Advertencia: '%s' no es un fichero de texto puro.\nSe tratar\341 como si fuese binario.\n" "\n\007Error: Only text files may be sent as display-only.\n" fr: "\n\7Erreur: seuls les fichiers de texte peuvent \352tre envoy\351s\n\ pour affichage exclusivement.\n" es: "\n\7Error: S\363lo los ficheros de texto pueden enviarse exclusivamente para mostrar.\n" "\nA secret key is required to make a signature. " fr: "\nUne cl\351 secr\350te est n\351cessaire pour faire une signature. " es: "\nSe necesita una clave secreta para generar la firma. " "\nYou specified no user ID to select your secret key,\n\ so the default user ID and key will be the most recently\n\ added key on your secret keyring.\n" fr: "\nVous n'avez pas sp\351cifi\351 de nom d'utilisateur pour s\351lectionner\n\ votre cl\351 secr\350te, donc le nom et la cl\351 par d\351faut seront ceux les\n\ plus r\351cemment ajout\351s \340 votre fichier de cl\351s secr\350tes.\n" es: "\nNo ha indicado ning\372n identificador para escoger la clave secreta,\n\ por lo tanto el identificador y la clave por omisi\363n ser\341n los \372ltimos\n\ a\361adidos al anillo.\n" "\007Signature error\n" fr: "\7Erreur de signature\n" es: "\7Error de firma\n" "\n\nRecipients' public key(s) will be used to encrypt. " fr: "\n\nLa ou les cl\351s publiques du destinataire seront utilis\351es\ pour chiffrer. " es: "\n\nSe utilizan las claves p\372blicas de los destinatarios para encriptar. " "\nA user ID is required to select the recipient's public key. " fr: "\nUn nom d'utilisateur est n\351cessaire pour s\351lectionner la cl\351\n\ publique du destinataire. " es: "\nSe necesita un identificador de usuario para encontrar la clave p\372blica\n\ del destinatario. " "\nEnter the recipient's user ID: " fr: "\nEntrez le nom d'utilisateur du destinataire: " es: "\nIntroduzca el identificador del destinatario: " "\007Encryption error\n" fr: "\7Erreur de chiffrage\n" es: "\7Error en encriptaci\363n\n" "\nCiphertext file: %s\n" fr: "\nFichier chiffr\351: %s\n" es: "\nFichero cifrado: %s\n" "\nSignature file: %s\n" fr: "\nFichier de signature: %s\n" es: "\nFichero de firma: %s\n" "\n\007Error: Transport armor stripping failed for file %s\n" fr: "\n\7Erreur dans la suppression de la protection de transport pour\n\ le fichier %s\n" es: "\n\7Error: No se ha podido quitar la armadura de transporte de %s\n" "Stripped transport armor from '%s', producing '%s'.\n" fr: "Protection de transport supprim\351e pour '%s', produisant '%s'.\n" es: "Quitada la armadura de transporte de '%s', produciendo '%s'.\n" "\nLooking for next packet in '%s'...\n" fr: "\nRecherche du prochain paquet dans '%s'...\n" es: "\nBuscando el siguiente paquete en '%s'...\n" "\nFile is encrypted. Secret key is required to read it. " fr: "\nLe fichier est chiffr\351. La cl\351 secr\350te est n\351cessaire pour le lire." es: "\nEl fichero est\341 encriptado. Para leerlo se necesita la clave secreta. " "\nThis file has a signature, which will be left in place.\n" fr: "\nCe fichier a une signature, qui sera gard\351e.\n" es: "\nEste fichero tiene firma, que se deja en su sitio.\n" "\nFile has signature. Public key is required to check signature. " fr: "\nLe fichier a une signature. La cl\351 publique est n\351cessaire pour la\n\ v\351rifier. " es: "\nEl fichero tiene firma. Se necesita la clave p\372blica para comprobarla. " "\nFile is conventionally encrypted. " fr: "\nLe fichier est chiffr\351 de mani\350re conventionnelle. " es: "\nEl fichero ha sido encriptado convencionalmente. " "\nFile contains key(s). Contents follow..." fr: "\nLe fichier contient une ou plusieurs cl\351s. Le contenu suit..." es: "\nEl fichero contiene una o m\341s claves. Se muestra a continuaci\363n ..." "\nDo you want to add this keyfile to keyring '%s' (y/N)? " fr: "\nVoulez vous ajouter ce fichier de cl\351 au fichier '%s' (o/N)? " es: "\n\277Quiere a\361adir este fichero de claves al anillo '%s' (s/N)? " "\007Keyring add error. " fr: "\7Erreur dans l'addition au fichier de cl\351s. " es: "\7Error al a\361adir en el anillo. " "\007\nError: '%s' is not a ciphertext, signature, or key file.\n" fr: "\7\nErreur: '%s' n'est pas un fichier chiffr\351, de signatures\ \nou de cl\351s.\n" es: "\7\nError: '%s' no es un texto cifrado, de firma ni de clave.\n" "\n\nThis message is marked \"For your eyes only\". Display now (Y/n)? " fr: "\n\nCe message est marqu\351 \"Pour vos yeux seulement\".\n\ Afficher maintenant (O/n)? " es: "\n\nEste mensaje est\341 marcado como \"S\363lo para sus ojos\". \277Mostrar ahora (S/n)? " "\n\nPlaintext message follows...\n" fr: "\n\nLe message en clair suit...\n" es: "\n\nMensaje en texto normal a continuaci\363n...\n" "Save this file permanently (y/N)? " fr: "Sauvegarde de ce fichier de mani\350re permanente (o/N)? " es: "\277Almacenar este fichero de forma permanente (s/N)? " "Enter filename to save file as: " fr: "Entrez le nom du fichier de sauvegarde: " es: "Introduzca el nombre para el fichero: " "\nPlaintext filename: %s" fr: "\nNom du fichier en clair: %s" es: "\nNombre del fichero normal: %s" "\nPlaintext file '%s' looks like it contains a public key." fr: "\nLe ficher en clair '%s' semble contenir une cl\351 publique." es: "\nEl fichero normal '%s' parece contener una clave p\372blica." "\nPlaintext file '%s' looks like a %s file." fr: "\nLe fichier en clair '%s' semble \352tre un fichier %s." es: "\nEl fichero normal '%s' parece un fichero %s." "\n\007Output file '%s' may contain more ciphertext or signature." fr: "\n\7Le fichier de sortie '%s' peut contenir d'autre texte chiffr\351\n\ ou signature." es: "\n\7El fichero de salida '%s' puede contener m\341s texto cifrado, o una firma." "\a\nError: PGP User's Guide not found.\n\ PGP looked for it in the following directories:\n" No translation No translation "and the doc subdirectory of each of the above. Please put a copy of\n\ both volumes of the User's Guide in one of these directories.\n\ \n\ Under NO CIRCUMSTANCES should PGP ever be distributed without the PGP\n\ User's Guide, which is included in the standard distribution package.\n\ If you got a copy of PGP without the manual, please inform whomever you\n\ got it from that this is an incomplete package that should not be\n\ distributed further.\n\ \n\ PGP will not generate a key without finding the User's Guide.\n\ \n" No translation No translation "\007Keygen error. " fr: "\7Erreur dans la g\351n\351ration de cl\351. " es: "\7Error en la generaci\363n de claves. " "\007Keyring check error.\n" fr: "\7Erreur dans la v\351rification du fichier de cl\351s.\n" es: "\7Error al comprobar el anillo.\n" "\007Maintenance pass error. " fr: "\7Erreur dans la passe de maintenance. " es: "\7Error en el proceso de mantenimiento. " "File '%s' is not a public keyring\n" fr: "Le fichier '%s' n'est pas un fichier de cl\351s publiques\n" es: "El fichero '%s' no es un anillo de claves p\372blicas\n" "\nA user ID is required to select the public key you want to sign. " fr: "\nUn nom d'utilisateur est n\351cessaire pour s\351lectionner la cl\351\n\ publique que vous voulez signer. " es: "\nSe necesita un identificador de usuario para elegir la clave p\372blica\n\ que quiera firmar. " "\nEnter the public key's user ID: " fr: "\nEntrez le nom d'utilisateur pour la cl\351 publique: " es: "\nIntroduzca el identificador de la clave p\372blica: " "\007Key signature error. " fr: "\7Erreur dans la signature de cl\351. " es: "\7Error en una firma de clave. " "\nA user ID is required to select the key you want to revoke or disable. " fr: "\nUn nom d'utilisateur est requis pour s\351lectionner la cl\351 que vous\ voulez r\351voquer ou inactiver. " es: "\nSe necesita un identificador de usuario para elegir la clave que quiere\n\ revocar o desactivar. " "\nEnter user ID: " fr: "\nEntrez le nom d'utilisateur: " es: "\nIntroduzca el identificador: " "\nA user ID is required to select the key you want to edit. " fr: "\nUn nom d'utilisateur est n\351cessaire pour s\351lectionner la cl\351 que\n\ vous voulez modifier. " es: "\nSe necesita el identificador de usuario para elegir la clave que\n\ quiera modificar. " "\nEnter the key's user ID: " fr: "\nEntrez le nom d'utilisateur pour la cl\351: " es: "\nIntroduzca el identificador de la clave: " "\007Keyring edit error. " fr: "\7Erreur dans la modification du fichier de cl\351s. " es: "\7Error en la modificaci\363n del anillo. " "\n\007Key file '%s' does not exist.\n" fr: "\n\7Le fichier de cl\351s '%s' n'existe pas.\n" es: "\n\7El fichero de claves '%s' no existe.\n" "\nA user ID is required to select the key you want to extract. " fr: "\nUn nom d'utilisateur est n\351cessaire pour s\351lectionner la cl\351 que\n\ vous voulez extraire. " es: "\nSe necesita el identificador de usuario para elegir la clave que\n\ quiera extraer. " "\007Keyring extract error. " fr: "\7Erreur dans l'extraction du fichier de cl\351s. " es: "\7Error al extraer del anillo. " "\nA user ID is required to select the public key you want to\n\ remove certifying signatures from. " fr: "\nUn nom d'utilisateur est n\351cessaire pour s\351lectionner la cl\351\ publique\n\ pour laquelle vous voulez supprimer des signatures de certification. " es: "\nSe necesita el identificador de usuario para elegir la clave p\372blica\n\ de la que suprimir firmas. " "\nA user ID is required to select the key you want to remove. " fr: "\nUn nom d'utilisateur est n\351cessaire pour s\351lectionner la cl\351 que\n\ vous voulez supprimer. " es: "\nSe necesita el identificador de usuario para elegir la clave que\n\ quiera suprimir . " "\007Key signature remove error. " fr: "\7Erreur dans la suppression de signature d'une cl\351. " es: "\7Error en la supresi\363n de la firma de una clave. " "\007Keyring remove error. " fr: "\7Erreur dans la suppression du fichier de cl\351s. " es: "\7Error al suprimir del anillo. " "\007Keyring view error. " fr: "\7Erreur dans la visualisation du fichier de cl\351s. " es: "\7Error al visualizar el anillo. " "For more detailed help, consult the PGP User's Guide.\n" fr: "Pour une aide plus d\351taill\351e, consultez le guide de l'utilisateur de PGP.\n" es: "Para obtener ayuda m\341s detallada, consulte la Gu\355a del Usuario de PGP.\n" "\nInvalid arguments.\n" fr: "\nArguments invalides.\n" es: "\nArgumentos no v\341lidos.\n" "\nUsage summary:\ \nTo encrypt a plaintext file with recipent's public key, type:\ \n pgp -e textfile her_userid [other userids] (produces textfile.pgp)\ \nTo sign a plaintext file with your secret key:\ \n pgp -s textfile [-u your_userid] (produces textfile.pgp)\ \nTo sign a plaintext file with your secret key, and then encrypt it\ \n with recipent's public key, producing a .pgp file:\ \n pgp -es textfile her_userid [other userids] [-u your_userid]\ \nTo encrypt with conventional encryption only:\ \n pgp -c textfile\ \nTo decrypt or check a signature for a ciphertext (.pgp) file:\ \n pgp ciphertextfile [plaintextfile]\ \nTo produce output in ASCII for email, add the -a option to other options.\ \nTo generate your own unique public/secret key pair: pgp -kg\ \nFor help on other key management functions, type: pgp -k\n" fr: "\nSommaire:\ \nPour chiffrer un fichier en clair avec la cl\351 publique du destinataire, \ tapez:\ \n pgp -e fichier son_nom [autres noms] (produit fichier.pgp)\ \nPour signer un texte en clair avec votre cl\351 secr\350te:\ \n pgp -s fichier [-u votre_nom] (produit fichier.pgp)\ \nPour signer un texte en clair avec votre cl\351 secr\350te, puis le chiffrer\ \n avec la cl\351 publique du destinataire, produisant un fichier .pgp:\ \n pgp -es fichier son_nom [autres noms] [-u votre_nom]\ \nPour chiffrer de mani\350re conventionelle seulement:\ \n pgp -c fichier\ \nPour d\351chiffrer ou v\351rifier une signature pour un fichier chiffr\351 (.pgp):\ \n pgp fichier_chiffr\351 [-o fichier_en_clair]\ \nPour produire une sortie en ASCII pour courrier \351lectronique, ajouter\ \nl'option -a aux autres options.\ \nPour g\351n\351rer votre propre paire de cl\351s publique/secr\350te:\ \n pgp -kg\ \nPour de l'aide sur les autres fonctions de gestion de cl\351, tapez: pgp -k\n" es: "\nResumen de las instrucciones:\ \nEncriptar fichero normal con la clave p\372blica del destinatario; escriba:\ \n pgp -e ftexto identificador_des (produce ftexto.pgp)\ \nFirmar un fichero de texto normal con su clave secreta:\ \n pgp -s ftexto [-u su_identificador] (produce ftexto.pgp)\ \nFirmar un fichero normal con su clave secreta y despu\351s encriptarlo\ \n con la clave p\372blica del destinatario, produciendo un fichero .pgp:\ \n pgp -es ftexto identificador_des [otros] [-u su_identificador]\ \nEncriptar s\363lo con cifrado convencional:\ \n pgp -c ftexto\ \nDesencriptar o comprobar la firma en un fichero cifrado (.pgp):\ \n pgp ftextocifrado [ftextonormal]\ \nProducir resultado en ASCII para correo electr\363nico: a\361adir la opci\363n -a.\ \nGenerar su propio par \372nico de claves p\372blica/secreta: pgp -kg\ \nAyuda sobre otras funciones de gesti\363n de claves; escriba: pgp -k\n" "\nKey management functions:\ \nTo generate your own unique public/secret key pair:\ \n pgp -kg\ \nTo add a key file's contents to your public or secret key ring:\ \n pgp -ka keyfile [keyring]\ \nTo remove a key or a user ID from your public or secret key ring:\ \n pgp -kr userid [keyring]\ \nTo edit your user ID or pass phrase:\ \n pgp -ke your_userid [keyring]\ \nTo extract (copy) a key from your public or secret key ring:\ \n pgp -kx userid keyfile [keyring]\ \nTo view the contents of your public key ring:\ \n pgp -kv[v] [userid] [keyring]\ \nTo check signatures on your public key ring:\ \n pgp -kc [userid] [keyring]\ \nTo sign someone else's public key on your public key ring:\ \n pgp -ks her_userid [-u your_userid] [keyring]\ \nTo remove selected signatures from a userid on a keyring:\ \n pgp -krs userid [keyring]\ \n" fr: "Fonctions de gestion des cl\351s:\ \nPour g\351n\351rer votre propre paire de cl\351s publique/secr\350te:\ \n pgp -kg\ \nPour ajouter le contenu d'un fichier de cl\351s \340 votre fichier de cl\351s\ \n public ou secret:\ \n pgp -ka fichier_de_cl\351s [votre_fichier_de_cl\351s]\ \nPour retirer une cl\351 de votre fichier de cl\351s public ou secret:\ \n pgp -kr nom_d_utilisateur [fichier_de_cl\351s]\ \nPour extraire (copier) une cl\351 de votre fichier de cl\351s public ou secret:\ \n pgp -kx nom_d_utilisateur fichier_de_la_cl\351 [fichier_de_cl\351s]\ \nPour visualiser le contenu de votre fichier de cl\351s:\ \n pgp -kv[v] [nom_d_utilisateur] [ficher_de_cl\351s]\ \nPour v\351rifier les signatures sur votre fichier de cl\351s publiques:\ \n pgp -kc [nom_d_utilisateur] [ficher_de_cl\351s]\ \nPour signer la cl\351 publique de quelqu'un d'autre sur votre fichier de\ \n cl\351s publiques:\ \n pgp -ks son_nom votre_nom [fichier_de_cl\351s]\ \nPour enlever certaines signatures d'une personne sur un fichier de cl\351s:\ \n pgp -krs son_nom [fichier_de_cl\351s]\n" es: "\nFunciones para la gesti\363n de claves:\ \nGenerar su propio par \372nico de claves p\372blica/secreta:\ \n pgp -kg\ \nA\361adir contenido de fichero de clave al anillo de claves p\372blicas o secretas:\ \n pgp -ka fdclaves [anillo]\ \nSuprimir una clave o ID de usuario del anillo de claves p\372blicas o secretas:\ \n pgp -kr idusuario [anillo]\ \nModificar su ID de usuario o su frase de contrase\361a:\ \n pgp -ke su_idusuario [anillo]\ \nExtraer (copiar) una clave del anillo de claves p\372blicas o secretas:\ \n pgp -kx idusuario fdclaves [anillo]\ \nVisualizar el contenido del anillo de claves p\372blicas:\ \n pgp -kv[v] [idusuario] [anillo]\ \nComprobar las firmas del anillo de claves p\372blicas:\ \n pgp -kc [idusuario] [anillo]\ \nFirmar la clave p\372blica de alguien en el anillo de claves p\372blicas:\ \n pgp -ks otro_idusuario [-u su_idusuario] [anillo]\ \nSuprimir ciertas firmas de un idusuario en un anillo:\ \n pgp -krs idusuario [anillo]\ \n" "\nWe need to generate %u random bits. This is done by measuring the\ \ntime intervals between your keystrokes. Please enter some random text\ \non your keyboard until you hear the beep:\n" fr: "\nNous devons g\351n\351rer %d bits al\351atoires. Ceci est fait en mesurant\ \nl'intervalle de temps entre les frappes de touches. Veuillez tapper du\ \ntexte al\351atoire sur votre clavier jusqu'\340 ce que vous entendiez le\ \nsignal sonore:\n" es: "\nNecesitamos generar %d bits aleatorios. Se hace midiendo los\ \nintervalos de tiempo entre sus pulsaciones de tecla. Introduzca\ \nalg\372n texto al azar en el teclado hasta que oiga un pitido:\n" "\007 -Enough, thank you.\n" fr: "\7 -Assez, merci.\n" es: "\7 -Es suficiente, gracias.\n" "Distributed by the Massachusetts Institute of Technology. Uses RSAREF 2.0.\n" No translation No translation "\nOut of memory\n" fr: "\nM\351moire insuffisante\n" es: "\nNo queda memoria\n" "\nCompression/decompression error\n" fr: "\nErreur de compression/decompression\n" es: "\nError en la compresi\363n/descompresi\363n\n" c key you want to sign. " fr: "\nUn nom d'utilisateur est n\351cessaire pour s\351lectionmitlicen.txt1004440006630000000000000475305570421671010347 037777703401 1 0 Compilation Copyright (c) 1994 by the Massachusetts Institute of Technology. All rights reserved. Permission to use, copy, modify, and distribute this compilation for any non-commercial purpose is hereby granted without fee, subject to the following license: 1. Any copy or modification of this compilation must include the above copyright notice and this license. 2. Software included in this compilation includes a feature that causes the format of messages generated by it to change on September 1, 1994. Modification to this software to disable this feature is not authorized and will make this license, and the license in the underlying software, null and void. 3. Users of the software included in this compilation agree to use their best efforts to provide MIT with any modifications containing improvements or extensions and hereby grant MIT a perpetual, royalty-free license to use and distribute such modifications under the terms of this license. Such modifications may be provided to MIT by email to pgp-bugs@mit.edu. 4. The software included in this compilation makes use of the RSAREF(TM) Cryptographic Toolkit, use and distribution of which are covered by the RSA Data Security, Inc., Program License Agreement included in this compilation. This compilation also contains materials copyrighted by Philip Zimmermann under terms also included in this compilation. (See the "Legal Issues" section of the PGP User's Guide, Volume 2.) Users must also agree to the terms of both of these licenses. 5. MIT makes no warranty or representation that the operation of the software in this compilation will be error-free, and MIT is under no obligation to provide any services, by way of maintenance, update, or otherwise. THE SOFTWARE AND ANY DOCUMENTATION ARE PROVIDED "AS IS" WITHOUT EXPRESS OR IMPLIED WARRANTY INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. IN NO EVENT WILL MIT OR ANY OTHER CONTRIBUTOR BE LIABLE FOR DIRECT, INCIDENTAL OR CONSEQUENTIAL DAMAGES, EVEN IF MIT HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. 6.Users will not use the name of the Massachusetts Institute of Technology nor any adaptation thereof in any publicity or advertising, without prior written consent from MIT in each case. 7. Export of this software from the United States may require a specific license from the United States Government. It is the responsibility of any person or organization contemplating export to obtain such a license before exporting. ll\351e, consultez lepgp.hlp1004440006630000000000000743305601132602007257 037777703401 1 0 Here's a quick summary of PGP v2.6 commands. To encrypt a plaintext file with the recipient's public key: pgp -e textfile her_userid To sign a plaintext file with your secret key: pgp -s textfile [-u your_userid] To sign a plaintext file with your secret key and have the output readable to people without running PGP first: pgp -sta textfile [-u your_userid] To sign a plaintext file with your secret key, and then encrypt it with the recipient's public key: pgp -es textfile her_userid [-u your_userid] To encrypt a plaintext file with just conventional cryptography, type: pgp -c textfile To decrypt an encrypted file, or to check the signature integrity of a signed file: pgp ciphertextfile [-o plaintextfile] To encrypt a message for any number of multiple recipients: pgp -e textfile userid1 userid2 userid3 --- Key management commands: To generate your own unique public/secret key pair: pgp -kg To add a public or secret key file's contents to your public or secret key ring: pgp -ka keyfile [keyring] To extract (copy) a key from your public or secret key ring: pgp -kx userid keyfile [keyring] or: pgp -kxa userid keyfile [keyring] To view the contents of your public key ring: pgp -kv[v] [userid] [keyring] To view the "fingerprint" of a public key, to help verify it over the telephone with its owner: pgp -kvc [userid] [keyring] To view the contents and check the certifying signatures of your public key ring: pgp -kc [userid] [keyring] To edit the userid or pass phrase for your secret key: pgp -ke userid [keyring] To edit the trust parameters for a public key: pgp -ke userid [keyring] To remove a key or just a userid from your public key ring: pgp -kr userid [keyring] To sign and certify someone else's public key on your public key ring: pgp -ks her_userid [-u your_userid] [keyring] To remove selected signatures from a userid on a keyring: pgp -krs userid [keyring] To permanently revoke your own key, issuing a key compromise certificate: pgp -kd your_userid To disable or reenable a public key on your own public key ring: pgp -kd userid --- Esoteric commands: To decrypt a message and leave the signature on it intact: pgp -d ciphertextfile To create a signature certificate that is detached from the document: pgp -sb textfile [-u your_userid] To detach a signature certificate from a signed message: pgp -b ciphertextfile --- Command options that can be used in combination with other command options (sometimes even spelling interesting words!): To produce a ciphertext file in ASCII radix-64 format, just add the -a option when encrypting or signing a message or extracting a key: pgp -sea textfile her_userid or: pgp -kxa userid keyfile [keyring] To wipe out the plaintext file after producing the ciphertext file, just add the -w (wipe) option when encrypting or signing a message: pgp -sew message.txt her_userid To specify that a plaintext file contains ASCII text, not binary, and should be converted to recipient's local text line conventions, add the -t (text) option to other options: pgp -seat message.txt her_userid To view the decrypted plaintext output on your screen (like the Unix-style "more" command), without writing it to a file, use the -m (more) option while decrypting: pgp -m ciphertextfile To specify that the recipient's decrypted plaintext will be shown ONLY on her screen and cannot be saved to disk, add the -m option: pgp -steam message.txt her_userid To recover the original plaintext filename while decrypting, add the -p option: pgp -p ciphertextfile To use a Unix-style filter mode, reading from standard input and writing to standard output, add the -f option: pgp -feast her_userid outputfile l\351s public ou secret:\ \n pgp -kx nom_d_utilisateur fichier_de_la_cl\351 [fichier_de_cl\351s]\ \nPour visualiser le contenu de votre fichier de cl\351s:\ \n pgp -kv[v] [nom_d_utilisateur] [ficher_de_cl\351s]\ \nPour v\35readme.doc1004440006630000000000001476005651040105007712 037777703401 1 0 Pretty Good Privacy version 2.6 - READ ME FIRST Notes by Perry Metzger Edited for 2.3a by Colin Plumb You are looking at the README file for PGP release 2.6.2. PGP, short for Pretty Good Privacy, is a public key encryption package; with it, you can secure messages you transmit against unauthorized reading and digitally sign them so that people receiving them can be sure they come from you. [Note: You will see references throughout this package to PGP release 2.6. Yet this release is 2.6.2. This isn't really a problem. PGP 2.6.2 is simply a bugfix release of PGP 2.6. All features in PGP 2.6 are also in PGP 2.6.2, just less buggy!] The files pgpdoc1.txt and pgpdoc2.txt contain documentation for the system. Before using PGP, PLEASE READ THE DOCUMENTATION. This tends to get neglected with most computer software, but cryptography software is easy to misuse, and if you don't use it properly much of the security you could gain by using it will be lost! Security is only as strong as the weakest link, and while the algorithms in PGP are some of the strongest known in the civilian world, there are things outside the program's control which can weaken your security as assuredly as forgetting to lock a vault door. Even if you are already familiar with public key cryptography, it is important that you understand the various security issues associated with using PGP. There are four archives in the PGP 2.6 release. You will usually only need one of them. They are: - pgp262.zip This is the MS-DOS executable release, which includes the executable, support files, and basic documentation. Note: This archive contains an inner zip file named PGP262I.ZIP. This internal zip file contains the actual PGP release. PGP262.ZIP contains it and PGP262I.ASC which is a detached signature generated by jis@mit.edu for PGP262I.ZIP. In this fashion you can verify that the release you received is authentic. Other signatures will be included in the future. - pgp262s.zip This is a source code release, which includes all the source code needed to compile PGP and examples of usage. This contains everything in pgp262.zip except the pgp.exe binary. It contains two internal ZIP files. PGP262SI.ZIP which contains the PGP source (and the .OBJ files for the two assembler modules so people without the assembler can still compile and link PGP) and RSAREF.ZIP which contains the RSAREF sources. There are also corresponding .ASC files so you can verify the integrity of the source release. - pgp262s.tar.gz This contains exactly the same files as pgp262s.zip, except that they use Unix rather than MS-DOS line end conventions. Note: It also contains a signature and two internal tar file so you can verify the integrity of the release you have. - pgp262s.tar.Z This is a UNIX compress version of pgp26src.tar.gz. - pgp262dc.zip This is the documentation for PGP only. This can be freely exported and is useful to tell people what PGP does. Note: It also contains a signature and an internal ZIP file so you can verify the integrity of the releaseyou have. While we welcome ports to other platforms, if you make your own archive for distribution, PLEASE INCLUDE THE MANUAL. It covers important security and legal issues which a new user must know. Assuming you have a code (non-documentation) release, the file SETUP.DOC contains information on how to install PGP on your system; this document is broken up into several sections, each dealing with a different operating system: PGP2.6 is known to run on MS-DOS and UNIX. It should also run on VMS and OS/2, but these have not been tested yet. Part of the information in SETUP.DOC might make more sense if you have already read the manuals. PGP2.6 is freeware; you are welcome to copy and distribute it provided that you do not export it from the U.S. and you follow the terms and conditions of the included RSAREF license. For details on what has changed since release 2.3a, doc/changes.doc. Release 2.4 was given to ViaCrypt only, and fixed a few minor bugs. MANIFEST for PGP 2.6.2 MSDOS executable release --------------------------------------------- Here is a list of files included in the PGP 2.6.2 MSDOS executable release file PGP262I.ZIP... CONFIG.TXT - User configuration parameter file for PGP ES.HLP - Online help file in Spanish FR.HLP - Online help file in French KEYS.ASC - Sample public keys you should add to your keyring LANGUAGE.TXT - Sample language file for French and Spanish MITLICEN.TXT - PGP 2.6 License from MIT PGP.EXE - PGP executable program PGP.HLP - Online help file for PGP README.DOC - This file you are reading RSALICEN.TXT - RSAREF license DOC\APPNOTE.DOC - Integrating PGP into Mailers (mostly UNIX oriented) DOC\BLURB.TXT - Brief description of PGP, for BBS indexes DOC\CHANGES.DOC - Changes since PGP 2.3 DOC\KEYSERV.DOC - Information (maybe out of date) on PGP Keyservers DOC\PGPDOC1.DOC - PGP User's Guide, Vol I: Essential Topics DOC\PGPDOC2.DOC - PGP User's Guide, Vol II: Special Topics DOC\POLITIC.DOC - Computer-related political groups DOC\SETUP.DOC - Installation guide For Clinical Paranoia Sufferers Only ------------------------------------ It is always possible that the PGP you have received has been tampered with in some way. This is a risk because PGP is used as a system to assure security, so those wishing to breach your security could likely do it by making sure that your copy of PGP has been tampered with. Of course, if you receive PGP in a binary distribution, it makes sense to check it for viruses, and if you receive PGP as source code, looking for signs of obvious tampering might be a good idea. However, it is very difficult to actually determine if the code has no subtle bugs that have been introduced and that the executable you are using has not been tampered with in any way. If you have a previous version of PGP which you already trust, the cryptographic signature on the executable will assure you that it has not been tampered with (with the possible exception of a "stealth virus" already existing on your system). If you are a really paranoid person, try getting a cryptographically signed copy of the software from someone you trust to have a good copy. It would also likely be good for you to pay special attention to the sections of the manual on "Vulnerabilities." You are going to read the manual, aren't you? public or secretrsalicen.txt1004440006630000000000001647305570264327010350 037777703401 1 0 RSA LABORATORIES PROGRAM LICENSE AGREEMENT January 5, 1993 RSA LABORATORIES, A DIVISION OF RSA DATA SECURITY, INC. ("RSA") GRANTS YOU A LICENSE AS FOLLOWS TO THE "RSAREF" PROGRAM: 1. LICENSE. RSA grants you a non-exclusive, non-transferable, perpetual (subject to the conditions of section 8) license for the "RSAREF" program (the "Program") and its associated documentation, subject to all of the following terms and conditions: a. to use the Program on any computer in your possession; b. to make copies of the Program for back-up purposes; c. to modify the Program in any manner for porting or performance improvement purposes (subject to Section 2) or to incorporate the Program into other computer programs for your own personal or internal use, provided that you provide RSA with a copy of any such modification or Application Program by electronic mail, and grant RSA a perpetual, royalty-free license to use and distribute such modifications and Application Programs on the terms set forth in this Agreement. d. to copy and distribute the Program and Application Programs in accordance with the limitations set forth in Section 2. "Application Programs" are programs which incorporate all or any portion of the Program in any form. The restrictions imposed on Application Programs in this Agreement shall not apply to any software which, through the mere aggregation on distribution media, is co-located or stored with the Program. 2. LIMITATIONS ON LICENSE. a. RSA owns the Program and its associated documentation and all copyrights therein. You may only use, copy, modify and distribute the Program as expressly provided for in this Agreement. You must reproduce and include this Agreement, RSA's copyright notices and disclaimer of warranty on any copy and its associated documentation. b. The Program and all Application Programs are to be used only for non-commercial purposes. However, media costs associated with the distribution of the Program or Application Programs may be recovered. c. The Program, if modified, must carry prominent notices stating that changes have been made, and the dates of any such changes. d. Prior permission from RSA is required for any modifications that access the Program through ways other than the published Program interface or for modifications to the Program interface. RSA will grant all reasonable requests for permission to make such modifications. 3. NO RSA OBLIGATION. You are solely responsible for all of your costs and expenses incurred in connection with the distribution of the Program or any Application Program hereunder, and RSA shall have no liability, obligation or responsibility therefor. RSA shall have no obligation to provide maintenance, support, upgrades or new releases to you or to any distributee of the Program or any Application Program. 4. NO WARRANTY OF PERFORMANCE. THE PROGRAM AND ITS ASSOCIATED DOCUMENTATION ARE LICENSED "AS IS" WITHOUT WARRANTY AS TO THEIR PERFORMANCE, MERCHANTABILITY OR FITNESS FOR ANY PARTICULAR PURPOSE. THE ENTIRE RISK AS TO THE RESULTS AND PERFORMANCE OF THE PROGRAM IS ASSUMED BY YOU AND YOUR DISTRIBUTEES. SHOULD THE PROGRAM PROVE DEFECTIVE, YOU AND YOUR DISTRIBUTEES (AND NOT RSA) ASSUME THE ENTIRE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION. 5. LIMITATION OF LIABILITY. EXCEPT AS EXPRESSLY PROVIDED FOR IN SECTION 6 HEREINUNDER, NEITHER RSA NOR ANY OTHER PERSON WHO HAS BEEN INVOLVED IN THE CREATION, PRODUCTION, OR DELIVERY OF THE PROGRAM SHALL BE LIABLE TO YOU OR TO ANY OTHER PERSON FOR ANY DIRECT, INCIDENTAL OR CONSEQUENTIAL DAMAGES, EVEN IF RSA HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. 6. PATENT INFRINGEMENT OBLIGATION. Subject to the limitations set forth below, RSA, at its own expense, shall: (i) defend, or at its option settle, any claim, suit or proceeding against you on the basis of infringement of any United States patent in the field of cryptography by the unmodified Program; and (ii) pay any final judgment or settlement entered against you on such issue in any such suit or proceeding defended by RSA. The obligations of RSA under this Section 6 are subject to: (i) RSA's having sole control of the defense of any such claim, suit or proceeding; (ii) your notifying RSA promptly in writing of each such claim, suit or proceeding and giving RSA authority to proceed as stated in this Section 6; and (iii) your giving RSA all information known to you relating to such claim, suit or proceeding and cooperating with RSA to defend any such claim, suit or proceeding. RSA shall have no obligation under this Section 6 with respect to any claim to the extent it is based upon (A) use of the Program as modified by any person other than RSA or use of any Application Program, where use of the unmodified Program would not constitute an infringement, or (B) use of the Program in a manner other than that permitted by this Agreement. THIS SECTION 6 SETS FORTH RSA'S ENTIRE OBLIGATION AND YOUR EXCLUSIVE REMEDIES CONCERNING CLAIMS FOR PROPRIETARY RIGHTS INFRINGEMENT. NOTE: Portions of the Program practice methods described in and subject to U.S. Patents Nos. 4,200,770, 4,218,582 and 4,405,829, and all foreign counterparts and equivalents, issued to Leland Stanford Jr. University and to Massachusetts Institute of Technology. Such patents are licensed to RSA by Public Key Partners of Sunnyvale, California, the holder of exclusive licensing rights. This Agreement does not grant or convey any interest whatsoever in such patents. 7. RSAREF is a non-commercial publication of cryptographic techniques. Portions of RSAREF have been published in the International Security Handbook and the August 1992 issue of Dr. Dobb's Journal. Privacy applications developed with RSAREF may be subject to export controls. If you are located in the United States and develop such applications, you are advised to consult with the State Department's Office of Defense Trade Controls. 8. TERM. The license granted hereunder is effective until terminated. You may terminate it at anytime by destroying the Program and its associated documentation. The termination of your license will not result in the termination of the licenses of any distributees who have received rights to the Program through you so long as they are in compliance with the provisions of this license. 9. GENERAL a. This Agreement shall be governed by the laws of the State of California. b. Address all correspondence regarding this license to RSA's electronic mail address , or to RSA Laboratories ATTN: RSAREF Administrator 100 Marine Parkway, Suite 500 Redwood City, CA 94065 executable release file PGP262I.ZIP... CONFIG.TXT - User configuration parameter file for PGP ES.HLP - Online help file in Spanish FR.HLP - Online help file in French KEYS.ASC - Sample pusrc/0407550006630000000000000000005652312561006005 5 0 1 0 src/3b168000.s1004440006630000000000001407105562661754007743 037777703401 1 0 # 3B1 Assembler - primitives for multi-precision math on the MC68010 # # Written by Rob Stampfli 19-Oct-92 for 3B1 # Assembler: 3B1 native assembler # # Note that the function P_SETP of the Intel primitives is not used. # `set_precision' has to be defined just like in `PORTABLE' mode. global global_precision global P_ADDC global P_SUBB global P_ROTL global P_SETP global P_SMUL text #boolean P_ADDC(unitptr r1, unitptr r2, boolean carry); # /* multiprecision add with carry r2 to r1, result in r1 */ #Parameters: A0.l: r1, A1.l: r2, D0.b: carry #Result: D0.b: new carry #Modifies: D0-D2/A0-A1 P_ADDC: mov.l 4(%sp),%a0 # fetch first argument: r1 mov.l 8(%sp),%a1 # fetch second argument: r2 mov.l 12(%sp),%d1 # fetch third argument: carry mov.l %d2,-(%sp) # save d2 -- not a Unix-PC scratch reg mov.w global_precision,%d2 # fetch # of 16 bit units mov.w %d2,%d0 # copy units lsl.w &1,%d0 # convert units to bytes (1 unit = 2 bytes) add.w %d0,%a0 # point r1 to 1 past least significant unit add.w %d0,%a1 # point r2 to 1 past least significant unit lsr.w &5,%d0 # conv bytes to (units/16); # times thru loop1 and.w &15,%d2 # = (units%16); # times thru loop2 lsr.b &1,%d1 # set X-bit as specified by carry arg bra adbf1 aloop1: #REPT 8 # 16 units per loop addx.l -(%a1),-(%a0) addx.l -(%a1),-(%a0) addx.l -(%a1),-(%a0) addx.l -(%a1),-(%a0) addx.l -(%a1),-(%a0) addx.l -(%a1),-(%a0) addx.l -(%a1),-(%a0) addx.l -(%a1),-(%a0) adbf1: dbf %d0,aloop1 bra adbf2 aloop2: addx.w -(%a1),-(%a0) adbf2: dbf %d2,aloop2 scs %d0 #set returned carry mov.l (%sp)+,%d2 # restore d2 rts #boolean P_SUBB(unitptr r1, unitptr r2, boolean borrow); # /* multiprecision subtract with borrow, r2 from r1, result in r1 */ #Parameters: A0.l: r1, A1.l: r2, D0.b: borrow #Result: D0.b: new borrow #Modifies: D0-D2/A0/A1 P_SUBB: mov.l 4(%sp),%a0 # fetch first argument: r1 mov.l 8(%sp),%a1 # fetch second argument: r2 mov.l 12(%sp),%d1 # fetch third argument: carry mov.l %d2,-(%sp) # save d2 -- not a Unix-PC scratch reg mov.w global_precision,%d2 # fetch # of 16 bit units mov.w %d2,%d0 # copy units lsl.w &1,%d0 # convert units to bytes (1 unit = 2 bytes) add.w %d0,%a0 # point r1 to 1 past least significant unit add.w %d0,%a1 # point r2 to 1 past least significant unit lsr.w &5,%d0 # conv bytes to (units/16); # times thru loop1 and.w &15,%d2 # = (units%16); # times thru loop2 lsr.b &1,%d1 # set X-bit as specified by carry arg bra bdbf1 bloop1: #REPT 8 # 16 units per loop subx.l -(%a1),-(%a0) subx.l -(%a1),-(%a0) subx.l -(%a1),-(%a0) subx.l -(%a1),-(%a0) subx.l -(%a1),-(%a0) subx.l -(%a1),-(%a0) subx.l -(%a1),-(%a0) subx.l -(%a1),-(%a0) bdbf1: dbf %d0,bloop1 bra bdbf2 bloop2: subx.w -(%a1),-(%a0) bdbf2: dbf %d2,bloop2 scs %d0 # set returned carry mov.l (%sp)+,%d2 # restore d2 rts #boolean P_ROTL(unitptr r1, boolean carry); # /* multiprecision rotate left 1 bit with carry, result in r1. */ #Parameters: A0.l: r1, D0.b: carry #Result: D0.b: new carry #Modifies: D0-D2/A0 P_ROTL: mov.l 4(%sp),%a0 # fetch first argument: r1 mov.l 8(%sp),%d1 # fetch second argument: carry mov.l %d2,-(%sp) # save d2 -- not a Unix-PC scratch reg mov.w global_precision,%d2 # fetch # of 16 bit units mov.w %d2,%d0 # copy units lsl.w &1,%d0 # convert units to bytes (1 unit = 2 bytes) add.w %d0,%a0 # point r1 to 1 past least significant unit lsr.w &5,%d0 # conv bytes to (units/16); # times thru loop1 and.w &15,%d2 # = (units%16); # times thru loop2 lsr.b &1,%d1 # set X-bit as specified by carry arg bra cdbf1 cloop1: #REPT 16 # note roxl.l not valid on 68010 roxl.w &1,-(%a0) roxl.w &1,-(%a0) roxl.w &1,-(%a0) roxl.w &1,-(%a0) roxl.w &1,-(%a0) roxl.w &1,-(%a0) roxl.w &1,-(%a0) roxl.w &1,-(%a0) roxl.w &1,-(%a0) roxl.w &1,-(%a0) roxl.w &1,-(%a0) roxl.w &1,-(%a0) roxl.w &1,-(%a0) roxl.w &1,-(%a0) roxl.w &1,-(%a0) roxl.w &1,-(%a0) cdbf1: dbf %d0,cloop1 bra cdbf2 cloop2: roxl.w &1,-(%a0) cdbf2: dbf %d2,cloop2 scs %d0 # set returned carry mov.l (%sp)+,%d2 # restore d2 rts #void P_SETP(short nbits); # /* sets working precision to specified number of bits. */ # /* only to minimize portation differences */ #Parameters: -- #Result: -- P_SETP: rts #void P_SMUL(MULTUNIT *prod, MULTUNIT *multiplicand, MULTUNIT multiplier) # /* multiprecision multiply */ #Parameters: A0.l: prod, A1.l: multiplicand, D0.w: multiplier #Modifies: D0-D4/A0-A1 #Result: -- #Note: prod and multiplicand have already been adjusted to point to LSB # prior to making the call. P_SMUL: mov.l 4(%sp),%a0 # fetch first argument: prod mov.l 8(%sp),%a1 # fetch second argument: multiplicand mov.l 12(%sp),%d0 # fetch third argument: multiplier mov.l %d2,-(%sp) # save d2 -- not a Unix-PC scratch reg mov.l %d3,-(%sp) # save d3 -- not a Unix-PC scratch reg mov.l %d4,-(%sp) # save d4 -- not a Unix-PC scratch reg clr.l %d2 # clear the carry register clr.l %d4 # clear upper half of temp reg for prod add.w &2,%a0 # position prod to 1 beyond LSB add.w &2,%a1 # position multiplicand to 1 beyond LSB mov.w global_precision,%d3 # fetch size of multiplicand bra ddbf1 dloop: mov.w -(%a1),%d1 # fetch multiplicand mulu.w %d0,%d1 # multiply by multiplier mov.w -(%a0),%d4 # fetch prod add.l %d4,%d1 # add in prod add.l %d2,%d1 # add in carry mov.w %d1,(%a0) # store result back to prod swap.w %d1 # fetch carry info (upper 16 bits of mult) mov.w %d1,%d2 # and move it into carry ddbf1: dbf %d3,dloop mov.w %d2,-(%a0) # store carry mov.l (%sp)+,%d4 mov.l (%sp)+,%d3 mov.l (%sp)+,%d2 rts bject to: (i) RSA's having sole control of the defense of any such claim, suit or proceeding; (ii) your notifying RSA promptly in writing of each such claim, suit or proceeding and giving RSA authority to proceed as stated in this Section 6; and (iii) your giving RSA all information known to you relating to such claim, suit or proceeding and cooperating with RSA to defend any such claim, suit or proceeding. Rsrc/68000.s1004440006630000000000000273205560777260007434 037777703401 1 0 ; This is the assembler source code for amiga 68000 ; It assumes Lattice-C is used. (v5.04 or higher) ; Written by S. Fishman SECTION text XREF _global_precision XDEF _P_ADDC ;make the linker know we're here _P_ADDC: link a6,#0 movem.l d4-d5/a0-a1,-(a7) move.l 8(a6),a0 move.l 12(a6),a1 move.l 16(a6),d4 sne d4 moveq.l #0,d5 move.w _global_precision,d5 asl.l #2,d5 add.l d5,a0 add.l d5,a1 asr.l #2,d5 sub.l #1,d5 asr.b #1,d4 add_loop: addx.l -(a1),-(a0) dbra d5,add_loop scs d0 ext.w d0 ext.l d0 movem.l (a7)+,d4-d5/a0-a1 unlk a6 ;get A6 & A7 back rts XDEF _P_SUBB _P_SUBB: link a6,#0 movem.l d4-d5/a0-a1,-(a7) move.l 8(a6),a0 move.l 12(a6),a1 move.l 16(a6),d4 sne d4 ;fix old borrow bits moveq.l #0,d5 move.w _global_precision,d5 asl.l #2,d5 add.l d5,a0 add.l d5,a1 asr.l #2,d5 sub.l #1,d5 asr.b #1,d4 sub_loop: subx.l -(a1),-(a0) ;come'n, let's do it !!! dbra d5,sub_loop scs d0 ext.w d0 ext.l d0 movem.l (a7)+,d4-d5/a0-a1 unlk a6 rts XDEF _P_ROTL _P_ROTL: link a6,#0 movem.l d4-d5/a0,-(a7) move.l 8(a6),a0 move.l 12(a6),d4 moveq.l #0,d5 move.w _global_precision,d5 asl.l #1,d5 sub.l #2,d5 asl (a0)+ scs d0 ext.w d0 ext.l d0 rotl_loop: asl (a0)+ bcc rotl_no_carry bset #0,-3(a0) rotl_no_carry: dbra d5,rotl_loop tst.l d4 beq rotl_no_old_carry bset #0,-1(a0) rotl_no_old_carry: movem.l (a7)+,d4-d5/a0 unlk a6 rts XDEF _P_SETP _P_SETP: rts END aws of the State of Californsrc/68000_32.s1004440006630000000000001341105560777260007734 037777703401 1 0 ;FPRIMS32.S - rsalib assembler primitives for MC680x0 ; (Pure-C/Atari ST version, 32-bit units) ; ;Written by Stephan Baucke 19-Oct-91 ;Assembler: Pure-PASM ; ;On systems with 68020 or higher it might be faster to use 32-Bit units ;instead of 16 Bits (I didn't yet test this, but there is no improvement ;on a plain 68000). ; ;Note that the function P_SETP of the Intel primitives is not needed here. ;`set_precision' has to be defined just like in `PORTABLE' mode in rsalib.h IMPORT global_precision EXPORT P_ADDC, P_SUBB, P_ROTL, P_SETP, P_SMUL TEXT ;boolean P_ADDC(unitptr r1, unitptr r2, boolean carry); ; /* multiprecision add with carry r2 to r1, result in r1 */ ;Parameters: A0.l: r1, A1.l: r2, D0.b: carry ;Result: D0.b: new carry ;Modifies: D0-D2/A0-A1 P_ADDC: move.b d0,d1 ;boolean carry sne d1 ;set bit 0 to carry move.w global_precision,d2 ;# of units move.w d2,d0 ;make copy lsl.w #2,d2 ;calc # of bytes (4 per unit) add.w d2,a0 ;point r1 to least significant unit add.w d2,a1 ;point r2 to least significant unit lsr.w #1,d2 ;divide back (now 2 * units) and.w #2*7,d2 ;yields 2 * (units % 8) neg.w d2 ;negative offset (for 2-Byte instructions) lsr.w #3,d0 ;units / 8 beq.s .onebyone ;skip loop if zero count subq.w #1,d0 ;one off (dbf counter) lsr.b d1 ;set X if carry .loop: REPT 8 ;8 units per run addx.l -(a1),-(a0) ENDM dbf d0,.loop jmp .base(pc,d2.w) ;do remaining units .onebyone: lsr.b d1 ;set X if carry jmp .base(pc,d2.w) ;do remaining units REPT 7 ;max 7 units remaining addx.l -(a1),-(a0) ;(2-byte instruction) ENDM .base: scs d0 ;set returned carry rts ;boolean P_SUBB(unitptr r1, unitptr r2, boolean borrow); ; /* multiprecision subtract with borrow, r2 from r1, result in r1 */ ;Parameters: A0.l: r1, A1.l: r2, D0.b: borrow ;Result: D0.b: new borrow ;Modifies: D0-D2/A0/A1 P_SUBB: move.b d0,d1 ;boolean carry sne d1 ;set bit 0 to carry move.w global_precision,d2 ;# of units move.w d2,d0 ;make copy lsl.w #2,d2 ;calc # of bytes (4 per unit) add.w d2,a0 ;point r1 to least significant unit add.w d2,a1 ;point r2 to least significant unit lsr.w #1,d2 ;divide back (now 2 * units) and.w #2*7,d2 ;yields 2 * (units % 8) neg.w d2 ;negative offset (for 2-byte instructions) lsr.w #3,d0 ;units / 8 beq.s .onebyone ;skip loop if zero count subq.w #1,d0 ;one off (dbf counter) lsr.b d1 ;set X if carry .loop: REPT 8 ;8 units per run subx.l -(a1),-(a0) ENDM dbf d0,.loop jmp .base(pc,d2.w) ;do remaining units .onebyone: lsr.b d1 ;set X if carry jmp .base(pc,d2.w) ;do remaining units REPT 7 ;max 7 units remaining subx.l -(a1),-(a0) ;(2-byte instruction) ENDM .base: scs d0 ;set returned carry rts ;boolean P_ROTL(unitptr r1, boolean carry); ; /* multiprecision rotate left 1 bit with carry, result in r1. */ ;Parameters: A0.l: r1, D0.b: carry ;Result: D0.b: new carry ;Modifies: D0-D2/A0 P_ROTL: move.b d0,d1 ;boolean carry sne d1 ;set bit 0 to carry move.w global_precision,d2 ;# of units move.w d2,d0 ;make copy lsl.w #2,d2 ;calc # of bytes (4 per unit) add.w d2,a0 ;point r1 to least significant unit and.w #4*7,d2 ;yields 4 * (units % 8) neg.w d2 ;negative offset (for 4-byte instructions) lsr.w #3,d0 ;units / 8 beq.s .onebyone ;skip loop if zero count subq.w #1,d0 ;one off (dbf counter) lsr.b d1 ;set X if carry .loop: REPT 8 ;8 units per run roxl.w -(a0) ;(roxl.l is not allowed on the 68000) roxl.w -(a0) ENDM dbf d0,.loop jmp .base(pc,d2.w) ;do remaining units .onebyone: lsr.b d1 ;set X if carry jmp .base(pc,d2.w) ;do remaining units REPT 7 ;max 7 units remaining roxl.w -(a0) ;(4 bytes instructions per unit) roxl.w -(a0) ENDM .base: scs d0 ;set returned carry rts ;void P_SETP(short nbits); ; /* sets working precision to specified number of bits. */ ; /* only to minimize portation differences */ ;Parameters: -- ;Result: -- P_SETP: rts ; ***NOT TESTED*** ; ;void P_SMUL(MULTUNIT *prod, MULTUNIT *multiplicand, MULTUNIT multiplier) ; /* multiprecision multiply */ ;Parameters: A0.l: prod, A1.l: multiplicand, D0.w: multiplier ;Modifies: D0-D3/A0-A1 ;Result: -- P_SMUL: move.w global_precision,d3 lsl.w #1,d3 subq.w #1,d3 clr.l d2 clr.l d1 .loop: move.w -(a1),d1 mulu.l d0,d1 add.l d2,d1 add.w d1,-(a0) scs d2 lsr.l #16,d1 add.w d1,d2 dbf d3,.loop move.w d2,(a0) rts END d, MULTUNIT multiplier) # /* multiprecision multiply */ #Parameters: A0.l: prod, A1.l: multiplicand, D0.w: multiplier #Modifies: D0-D4/A0-A1 #Result: -- #Note: prod and multiplicand have already been adjusted to point to LSB # prior to making src/8086.asm1004440006630000000000002777505560777260007720 037777703401 1 0 ; Assembly primitives for RSA multiprecision library ; ; Tested with Turbo Assembler 1.0 and masm 1.00 ; ; Written by Branko Lankester (lankeste@fwi.uva.nl) 10/10/91 ; ; Modified to add, rather than store carry bit to allow using a ; smaller precision for long division. ; define LDATA and LCODE as follows: ; model: small compact medium large ; LDATA 0 1 0 1 ; LCODE 0 0 1 1 LDATA equ 1 LCODE equ 1 ; Note: Only the large memory model has been implemented for P_SMULA, ; P_SETRECIP and P_QUO_DIGIT. IF LDATA DSTPTR equ es:[bx+si] ELSE DSTPTR equ [bx+si] ENDIF IF LCODE prec equ [bp+6] ; 1st arg r1 equ [bp+6] ; 1st arg IF LDATA r2 equ [bp+10] ; 2nd arg carry equ [bp+14] ; 3rd arg scarry equ [bp+10] ; carry for shift (arg 2) ELSE r2 equ [bp+8] carry equ [bp+10] scarry equ [bp+8] ENDIF ELSE ; small code model prec equ [bp+4] r1 equ [bp+4] IF LDATA r2 equ [bp+8] carry equ [bp+12] scarry equ [bp+8] ELSE r2 equ [bp+6] carry equ [bp+8] scarry equ [bp+6] ENDIF ENDIF IF NOT LCODE UPTON_TEXT = _TEXT ENDIF _TEXT segment byte public 'CODE' DGROUP group _DATA,_BSS assume cs:_TEXT,ds:DGROUP _TEXT ends _DATA segment word public 'DATA' _DATA ends _BSS segment word public 'BSS' prec16 dw ? ; precision / 16 (seems to be / 256?) unitprec dw ? ; precision / 16, really addp dw ? ; jump offset subp dw ? rotp dw ? mulp dw ? _BSS ends _TEXT segment byte public 'CODE' public _P_SETP public _P_ADDC public _P_SUBB public _P_MUSUBB public _P_ROTL IF LCODE fprims proc far ; dummy proc ELSE fprims proc near ENDIF ; ; ******************** set precision ******************** ; _P_SETP: push bp mov bp,sp mov ax, prec ; precision in bits add ax, 0fh mov cl,4 shr ax,cl ; prec. in units mov unitprec,ax push ax shr ax,cl mov prec16,ax ; precision / 16 pop ax and ax,0fh ; al = prec % 16 mov bx,ax mov cx,ax shl bx,1 ; multiply by 4 (=number of bytes shl bx,1 ; in instruction sequence) mov dx,bx IFE LDATA sub dx,ax ; small model only 3 for add/sub ENDIF mov ax,offset add_ref sub ax,dx mov addp,ax mov ax,offset sub_ref sub ax,dx mov subp,ax mov ax,offset rot_ref sub ax,bx mov rotp,ax mov ax,offset mul_ref shl bx,1 ; MULU macro is 17 bytes for large data shl bx,1 sub ax,bx sub ax,cx mov mulp,ax pop bp ret ; ; ******************** mpi add with carry ******************** ; ADDU macro n rept n lodsw adc DSTPTR,ax endm endm _P_ADDC: push bp mov bp,sp push si mov cx, prec16 mov dx, addp IF LDATA push ds lds si, dword ptr r2 les bx, dword ptr r1 ELSE mov si, r2 mov bx, r1 ENDIF sub bx, si ; calculate relative offset dec bx dec bx cld shr byte ptr carry,1 ; load carry jcxz add_units add_16u: ADDU 16 loop add_16u add_units: jmp dx ADDU 15 add_ref: rcl ax,1 ; return carry and ax,1 IF LDATA pop ds ENDIF pop si pop bp ret ; ; ******************** mpi subtract with borrow ******************** ; SUBU macro n rept n lodsw sbb DSTPTR,ax endm endm _P_MUSUBB: ; MULTUNIT is same size as unit _P_SUBB: push bp mov bp,sp push si mov cx, prec16 mov dx, subp IF LDATA push ds lds si, dword ptr r2 les bx, dword ptr r1 ELSE mov si, r2 mov bx, r1 ENDIF sub bx, si ; calculate relative offset dec bx dec bx cld shr byte ptr carry,1 jcxz sub_units sub_16u: SUBU 16 loop sub_16u sub_units: jmp dx SUBU 15 sub_ref: rcl ax,1 ; return carry and ax,1 IF LDATA pop ds ENDIF pop si pop bp ret ; ; ******************** mpi rotate left ******************** ; _P_ROTL: push bp mov bp,sp mov cx, prec16 mov dx, rotp IF LDATA push ds lds bx, dword ptr r1 ELSE mov bx, r1 ENDIF shr byte ptr scarry,1 jcxz rot_units rot_16u: i = 0 rept 16 rcl word ptr [bx + i],1 i = i + 2 endm lahf add bx,32 sahf loop rot_16u rot_units: jmp dx rept 15 rcl word ptr [bx],1 inc bx inc bx endm rot_ref: rcl ax,1 and ax,1 IF LDATA pop ds ENDIF pop bp ret fprims endp ; *************************************************************** ; P_SMULA (MULTUNIT *prod, MULTUNIT *multiplicand, MULTUNIT multiplier) ; mp_smul routine from Upton's modmult, converted to assembler ; ; Multiply the single-word multiplier times the multiprecision integer ; in multiplicand, accumulating result in prod. The resulting ; multiprecision prod will be 1 word longer than the multiplicand. ; multiplicand is unit_prec words long. We add into prod, so caller ; should zero it out first. ; ; NOTE: Unlike other functions in the multiprecision arithmetic ; library, both multiplicand and prod are pointing at the LSB, ; regardless of byte order of the machine. On an 80x86, this makes ; no difference. But if this assembly function is implemented ; on a 680x0, it becomes important. ; ; This version differs from P_SMUL by adding in, rather than storing, ; the final carry. This better supports use by Smith's modmult. ; *************************************************************** ; Variable assignments: ; multiplier = [bp+14] ; multiplicand = [ds:di] 32-bit pointer ; prod = [es:si] 32-bit pointer ; unit_prec = cx ; p = ax-dx ; carry = bx PUBLIC _P_SMULA MULU macro n rept n lodsw ;multiplicand mul bp ;multiplier, results (p) to AX/DX add ax,bx ;carry adc dx,0 add ax,WORD PTR es:[di] adc dx,0 mov bx,dx ;carry stosw endm endm _P_SMULA PROC FAR push bp mov bp,sp push di push si push ds mov cx,prec16 mov ax,mulp push ax sub bx,bx ;carry = 0, store in bx les di,DWORD PTR [bp+6] ;prod in es:di lds si,DWORD PTR [bp+10] ;multiplicand in ds:si cld mov bp,[bp+14] or cx,cx jnz mul_16u jmp mul_units mul_16u: MULU 16 dec cx jz mul_units jmp mul_16u mul_units: pop cx jmp cx MULU 15 mul_ref: add WORD PTR es:[di],bx ;add final carry pop ds pop si pop di pop bp ret _P_SMULA ENDP ; *************************************************************** ; void P_SETRECIP (MULTUNIT reciph, MULTUNIT recipl, short mshift) ; Specify reciprocal factors for use by P_QUO_DIGIT. ; ; This implementation is for 16-bit MULTUNIT. ; ; *************************************************************** DGROUP group _DATA,_BSS assume ds:DGROUP _BSS segment word public 'BSS' reciph dw ? ; recip msw recipl dw ? ; recip lsw mshift dw ? ; shift adjust _BSS ends PUBLIC _P_SETRECIP _P_SETRECIP PROC FAR push bp mov bp,sp mov ax,6[bp] ; reciph mov reciph,ax mov ax,8[bp] ; recipl mov recipl,ax mov ax,10[bp] ; mshift mov mshift,ax pop bp ret _P_SETRECIP endp ; *************************************************************** ; MULTUNIT quo_digit (MULTUNIT *dividend) ; Determine the next quotient digit. ; (routine for modmult, converted to assembler) ; ; This implementation is for 16-bit MULTUNIT. ; ; The following items have already been set by calling ; P_SETRECIP: ; reciph, recipl - reciprocal of divisor ; mshift - scaling factor ; ; The dividend parameter points to the most significant word ; of the dividend. ; ; *************************************************************** ; Register assignments: ; dx:ax = product ; cx:bx = temp long ; es:si = dividend pointer ; di = MS word of q0 ; bp = lsb factor ; ; Comments reference the C implementation variables. DGROUP group _DATA,_BSS assume ds:DGROUP PUBLIC _P_QUO_DIGIT _P_QUO_DIGIT PROC FAR push bp mov bp,sp push di push si les si,6[bp] ; dividend mov ax,es:[si-4] ; dividend[-2] not ax mul reciph add ax,reciph adc dx,0 mov bx,ax mov di,dx ; di:bx = q1 mov ax,es:[si-2] ; dividend[-1] not ax mul recipl inc dx ; dx:ax = q2 mov bp,dx and bp,di and bp,1 ; bp = lsb_factor add ax,bx adc di,dx rcr di,1 ; di = MS word of q0 mov ax,es:[si-2] ; dividend [-1] not ax mul reciph mov bx,ax mov cx,dx ; cx:bx = q1 mov ax,es:[si] ; dividend[0] not ax mul recipl ; dx:ax = q2 xor ax,bx and bp,ax ; lsb correction xor ax,bx ; restore ax add ax,bx adc dx,cx rcr dx,1 rcr ax,1 ; dx:ax = q add ax,di ; + scaled q0 adc dx,0 add ax,bp ; + lsb correction adc dx,0 ; q shl ax,1 rcl dx,1 rcl ax,1 rcl dx,1 rcl ax,1 and ax,3 mov cx,ax mov bx,dx ; bx:cx = q >> 14 mov ax,es:[si] ; dividend[0] not ax mul reciph shl ax,1 rcl dx,1 add ax,bx adc dx,cx ; q mov cx,mshift shr ax,cl mov bx,dx shr dx,cl neg cx add cx,16 shl bx,cl add ax,bx ; dx:ax = q >> mshift or dx,dx jz no_overflow mov ax,0ffffh no_overflow: pop si pop di pop bp ret _P_QUO_DIGIT ENDP _TEXT ends end src/config.c1004440006630000000000004036105652312463010174 037777703401 1 0 /* config.c - config file parser by Peter Gutmann Parses config file for PGP (c) Copyright 1990-1994 by Philip Zimmermann. All rights reserved. The author assumes no liability for damages resulting from the use of this software, even if the damage results from defects in this software. No warranty is expressed or implied. Note that while most PGP source modules bear Philip Zimmermann's copyright notice, many of them have been revised or entirely written by contributors who frequently failed to put their names in their code. Code that has been incorporated into PGP from other authors was either originally published in the public domain or is used with permission from the various authors. PGP is available for free to the public under certain restrictions. See the PGP User's Guide (included in the release package) for important information about licensing, patent restrictions on certain algorithms, trademarks, copyrights, and export controls. Modified 24 Jun 92 - HAJK Misc fixes for VAX C restrictions Updated by Peter Gutmann to only warn about unrecognized options, so future additions to the config file will give old versions a chance to still run. A number of code cleanups, too. */ #include #include #include #include #include #include "usuals.h" #include "fileio.h" #include "pgp.h" #include "config.h" #include "charset.h" /* Various maximum/minimum allowable settings for config options */ #define MIN_MARGINALS 1 #define MIN_COMPLETE 1 #define MAX_COMPLETE 4 #define MIN_CERT_DEPTH 0 #define MAX_CERT_DEPTH 8 /* Prototypes for local functions */ static int lookup( char *key, int keyLength, char *keyWords[], int range ); static int extractToken( char *buffer, int *endIndex, int *length ); static int getaString( char *buffer, int *endIndex ); static int getAssignment( char *buffer, int *endIndex, INPUT_TYPE settingType ); static void processAssignment( int intrinsicIndex ); /* The external config variables we can set here are referenced in pgp.h */ /* Return values */ #define ERROR -1 #define OK 0 /* The types of error we check for */ enum { NO_ERROR, ILLEGAL_CHAR_ERROR, LINELENGTH_ERROR }; #define CPM_EOF 0x1A /* ^Z = CPM EOF char */ #define MAX_ERRORS 3 /* Max.no.errors before we give up */ #define LINEBUF_SIZE 100 /* Size of input buffer */ static int line; /* The line on which an error occurred */ static int errCount; /* Total error count */ static boolean hasError; /* Whether this line has an error in it */ /* The settings parsed out by getAssignment() */ static char str[ LINEBUF_SIZE ]; static int value; static char *errtag; /* Prefix for printing error messages */ static char optstr[ 100 ]; /* Option being processed */ /* A .CFG file roughly follows the format used in the world-famous HPACK archiver and is as follows: - Leading spaces/tabs (whitespace) are ignored. - Lines with a '#' as the first non-whitespace character are treated as comment lines. - All other lines are treated as config options for the program. - Lines may be terminated by either linefeeds, carriage returns, or carriage return/linefeed pairs (the latter being the DOS default method of storing text files). - Config options have the form: