Copied from http://www.amiga-stuff.com/text/archivers/HPACK.DOC
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Ver:0.79a0 HPACK - Multi-System Archiver 1 May 1993
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
The HPACK Multi-System Archiver is an archiver that was written to allow the
transfer of archived data to different systems. In the past archivers have
traditionally been available for single systems only, for example PKZIP(tm)
and LHARC for the IBM PC, Larc for the Amiga, StuffIt(tm) and Compactor for
the Macintosh, and tar and compress for UNIX systems (while these archivers
are available on other systems, their use is not widespread). It is
intended to make HPACK a more universal archiver by offering versions for
the following environments:
* Apple IIgs (planned)
* Archimedes
* Atari ST
* Commodore Amiga
* Microsoft Windows
* Macintosh
* MSDOS
* OS/2 (16 and 32-bit versions)
* OS/2 Presentation Manager (currently in development)
* Primos (planned)
* UNIX
* VMS (currently in development)
* Any other system which people offer to port it to
Currently Bavarian, Dutch, English, German, Italian, Polish, Spanish, and
Swiss German versions of HPACK using the ASCII, IBM PC, IBM Codepage 850,
IBM Codepage 869, ISO 8859-1 (Latin 1), ISO 8859-2 (Latin 2), ISO 8859-3
(Latin 3), ISO 8859-4 (Latin 4), Macintosh, Mazovia, and NeXTSTEP character
sets exist. Anyone wishing to take advantage of these features should read
the section "HPACK Internationalization" below.
Note: This documentation is intended mainly as an alternative to the proper
documentation which is in Postscript format. If possible the proper
documentation should be used.
Using HPACK
HPACK is run with the following command:
HPACK command [options] archive [filenames.....][@scriptfiles.....]
Allowed commands are:
[A] - Add files to an archive.
[X] - Extract files from an archive.
[V] - Display a directory of files inside an
[P] - View files within an archive.
[T] - Test the integrity of an archive.
[D] - Delete files from an archive.
[F] - Freshen files to an archive.
[R] - Replace files in an archive.
[U] - Update files to an archive.
Allowed options are:
-0 - Store files without attempting any compression.
-a - Store file attributes.
-b
- Specify a base pathname for all files.
-c
- Encryption options (conventional and public-key encryption).
-d
- Directory options (Mkdir, Rmdir, Mvdir, path options etc).
-e - Add/use error recovery information.
-f - Force file move into/out of an archive.
-i - Interactive mode (prompt for all actions).
-k - Overwrite existing archive.
-l
- Security options (data authentication)
-m - Create a multipart archive.
-o
- Overwrite on extraction options (All, None, Prompt, Smart).
-r - Recurse through subdirectories.
-s - Run in stealth mode.
-t - Touch files on extraction.
-u - Unified compression mode.
-v
- View files options (Files, Directories, All).
-w - Treat files as archive comments.
-x
- Text file translate options (see below).
+
- Extended options (usually system-specific, see below).
Commands, options, extended options, and archive and file names may be
given in upper or lower case (they are given in lowercase in the examples
which follow merely for consistency). Options may be lumped together or may
be given seperately preceded by the '-' delimiter. The option '--' may be
used to indicate that no more options are present on the command line,
following the standard Unix convention. Extended options must be given
seperately preceded by the '+' delimiter.
The default archive extension is '.HPK'. HPACK will always add this
extension (provided the underlying filesystem supports it), changing any
other given extension if necessary. Note that some quantum physics theories
suggest that when the user is not directly observing the HPACK archive, it
may cease to exist or will exist only in a vague and indeterminate state; in
this case the existence of the '.HPK' extension cannot be guaranteed.
The filenames field may consist of zero or more filenames, defaulting to all
files if no filenames are given (in other words archive all files in the
current directory, or dearchive/view all files in the archive). HPACK uses
UNIX-style wildcards (which are described in more detail below in the
section "HPACK Wildcards"), as well as UNIX-style pathnames in place of the
usual ones used by the systems' command interpreter, so that for example the
path:
/TEMP/WORK/FILES
is used instead of the MSDOS equivalent:
\TEMP\WORK\FILES
or the VMS equivalent:
[TEMP.WORK]FILES
or the Archimedes equivalent:
$.temp.work.files
If any additional components are needed, such as drives, network nodes, or
devices, these can be specified in the manner usual to the host command
interpreter. For example if the path in the above example were on drive A:
under MSDOS the pathname would be:
A:/TEMP/WORK/FILES
If the path in the above example were on the 'HOME' node, on device 'DISK1'
under VMS, the pathname would be:
HOME::DISK1:/TEMP/WORK/FILES
The scriptfiles are names of files preceded with an '@' character. When
HPACK encounters one of these it will treat the filename as a file
containing a list of files to process. Script files and normal filenames
may be freely mixed on the command line. See the section "HPACK Script
Files" below for more information.
HPACK Wildcards
When HPACK scans any filename that has been given to it, it will check for
the presence in the filename of any of the special characters:
* ? [ ] \
If one of these is detected, then the string of characters making up the
filename will be treated as being a pattern for a filename, rather than the
name of a specific file. These special characters have the following
meanings when used in a filename string:
* Matches zero or more characters
? Matches any one character
[...] Matches any of the enclosed range of characters '...' in turn. If
two characters appearing in the pattern in alphabetical order are
separated by a dash '-', then any character in the alphabetic range
between these two characters will be matched. This is a more
selective version of the '?' form.
[^...] As above, but this time matches anything *not* in the enclosed
range of characters '...'.
\ Treat the next character as a normal character rather than one of
the special characters. This can be used to override the usual
meaning of the '*', '?', '[]', and '\' characters. Note that the
Atari ST, MSDOS, and OS/2 version of HPACK use '#' instead of '\'
since the command interpreter uses '\' in its pathnames.
The case-sensitivity when handling filenames depends on the operating system
HPACK is being run under. On the Atari ST and under MSDOS and VMS,
filenames are converted to uppercase, but are not case-sensitive; on the
Amiga, Archimedes, Macintosh, and under OS/2, filenames are left as is, but
are also not case sensitive (so that "FileName" will match "Filename",
"FILENAME", and "filename"); and under Unix, filenames are left as is, and
are case sensitive, so that "makefile" and "Makefile" are treated as
seperate names.
These wildcards can be combined to create quite powerful expressions. For
example, to match any file not beginning with an 'a', 'b', 'c', or 'f', and
containing at least two characters, the required expression would be:
[^a-cf]?*
where the [^a-cf] would match anything but 'a', 'b', 'c', or 'f'; the '?'
would match the second character required, and the '*' would match any
remaining characters.
For example, if we have an archive whose contents are:
file1.txt file2.txt file3.txt file4.txt file5.txt
file6.txt file7.txt file8.txt file9.txt Index.txt
we could perform the following file matches on it:
Expression: Matches files:
* file1.txt file2.txt file3.txt file4.txt file5.txt
file6.txt file7.txt file8.txt file9.txt Index.txt
F* file1.txt file2.txt file3.txt file4.txt file5.txt
file6.txt file7.txt file8.txt file9.txt
*4* file4.txt
FILE?.TXT file1.txt file2.txt file3.txt file4.txt file5.txt
file6.txt file7.txt file8.txt file9.txt
FILE[1-4].TXT file1.txt file2.txt file3.txt file4.txt
FILE[^1-4].TXT file5.txt file6.txt file7.txt file8.txt file9.txt
FILE[1-46].TXT file1.txt file2.txt file3.txt file4.txt file6.txt
FILE[^13-5].TXT file2.txt file6.txt file7.txt file8.txt file9.txt
Finally, note that these wildcards may not perform quite like the standard
wildcards used by the system's command interpreter. For example under
GemDOS, MSDOS, and OS/2, to specify all files in a directory or archive, it
is not necessary to use the usual sequence of "*.*". Instead simply typing
"*" will match all the files in the archive (the DOS-like wildcards are in
fact a bit of a hack - for example "*abc.*" will (incorrectly) match "*.*").
The extended wildcards act as true wildcards, so that "FILE.*" will not
match "FILE" as it would under DOS, since there is a spurious "." in the DOS
wildcard matching. These extended wildcards can be useful when extracting
files which cannot normally be handled by the command interpreter from
archives, for example to extract the file "Filename with spaces in it" from
the archive ARCHIVE.HPK, you would type:
HPACK X ARCHIVE FILENAME?WITH?SPACES?IN?IT
where the '?' wildcard will match the spaces. Alternatively you can just
type:
HPACK X ARCHIVE FILENAME*
which will usually do the same thing with a lot less typing involved.
Another point is that these wildcards cannot be used to represent full
regular expressions (the idea behind HPACK was to create an archiver, not a
regular expression parser), so that, for example, '*?' will not work as an
expression, and that they can only be used inside pathnames when the path is
inside the archive (since the extended wildcards are built on top of the
usual operating system ones (if they exist) the resulting system would run
very slowly if they had to be simulated on an external filesystem).
Using wildcards for pathnames inside archives is perfectly legal. When
matching wildcards to pathnames, HPACK follows the standard convention of
matching the directory contents if the directory name is given, or matching
the directory itself when a wildcard matching it is given. Consider an
archive with a subdirectory DIR, with both the archive root directory and
the subdirectory containing files. Then the following wildcard matches
could occur:
'*' Match all files and directories in the root directory
'D?R' Match the directory DIR (and possibly other files) in the root
directory.
'DIR' Match the contents of directory DIR (equivalent to 'DIR/*')
'*/*' Match all files and directories (equivalent to using '*' with the
[-r]ecurse option).
Unlike most filesystems, HPACK has no notion of a 'current directory' within
an archive, so all pathnames must be given relative to the archive root
directory.
Finally, Unix users may have to quote the wildcard characters used to
prevent them being expanded by the shell if it is required that HPACK
handle wildcard expansion. One case in which this is necessary is when
recursively adding files in subdirectories which match a certain filespec to
an archive. The command:
HPACK A -R TEST *.H
will cause the shell to expand the *.H filespec to match all the files in
the current directory, and not match any files in subdirectories. In
contrast:
HPACK A -R TEST '*.H'
will cause HPACK to perform the wildcard expansion, and will correctly add
files in subdirectories. Some shells provide other ways to turn off their
wildcard expansion, for instance csh users can do the following:
set noglob
HPACK A -R TEST *.H
unset noglob
and ksh users can use:
set -o noglob
HPACK A -R TEST *.H
set +o noglob
HPACK Commands
[A] Add files to an archive. The archive given in the command-line is
opened, or created if it doesn't already exist, and is given the
extension '.HPK' if this is not explicitly specified. Then all files
given in the list of filenames are added to to it.
Example: To add all files in the current directory to the archive
ARCHIVE.HPK in the current directory:
HPACK A ARCHIVE
[X] Extract files from an archive. All files are extracted from the
archive given in the command line to the current directory. If the
file already exists and no overwrite options are given (these are
explained in the section "HPACK Options" below), you will be asked if
you wish to overwrite it:
File already exists - overwrite [y/n/a]
'Y' will replace the file with the file from the archive, 'N' will skip
the extraction of this file, and 'A' will process all files from this
point as if a 'Y' answer was given for each file. In some cases the
name of the file extracted will need to be translated to allow for the
naming conventions of different operating systems. In these cases the
original name will be printed, followed by the name it will be
extracted under.
On Apple systems data is divided into two sections in a file, a "data
fork" and a "resource fork". Under non-Apple operating systems only
the data fork will be extracted from an archive: the resource fork
(which only Apple systems can make any use of) will be skipped.
Example: To extract all files in ARCHIVE.HPK not beginning with an 'A'
to the current directory:
HPACK X ARCHIVE [^A]*
[V] Display a directory of files inside an archive. If no view options are
given (these are explained in the section "HPACK Options" below), a
listing in the following format is produced:
HPACK - The multi-system archiver Version 0.79a0 (shareware version)
For Amiga, Archimedes, Atari ST, Macintosh, MSDOS, OS/2, and UNIX
Copyright (c) Peter Gutmann 1989 - 1993. Release date: 1 Feb 1993
Archive is 'ARCHIVE.HPK'
System Length Size Ratio Date Time Name
------ ------- ------- ----- -------- -------- ------------------------
MSDOS 18537 6217 66% 04/05/90 11:32:48 README.TXT
Atari 8301 3169 74% 27/12/90 21:02:39 LZSS.EXE
UNIX 30061 9127 70% 24/11/89 16:52:57 compr.method.txt
OS/2 8481 3282 61% 22/12/90 08:58:52 Comp.test
Mac 0 0 0% 01/07/91 18:20:20 Fast LZ Decoder using B..
------ ------- ------- ----- -------------------------
65380 21795 67% Total of 5 files
Done
The archive used is displayed, followed by a list of all the files
within the archive. The fields for each file inside the archive are as
follows:
System: The system the file was archived under.
Length: The length of the file when unarchived.
Size: The size of the compressed file within the archive.
Ratio: The ratio of the compressed file to the uncompressed file.
Date: The creation date of the file within the archive.
Time: The creation time of the file within the archive.
Name: The name of the file within the archive. If the name is too
long to fit on the screen then a '..' is appended to indicate
this. In addition files may have a single character prepended
to them: an asterisk '*' before the name indicates that this
file has been encrypted, a dash '-' indicates that it includes
authentication information, and a hash '#' indicates that it
is both encrypted and includes authentication information.
Note that the name within the archive may not be the same as
the name given to the unarchived file since translation may be
necessary to allow for the naming conventions of different
operating systems.
Note also that in the example above the file originating on
the Macintosh has a length of zero bytes. This does not
necessarily mean the total data size is zero bytes, since
files originating on Apple systems have a second block of data
called a resource fork which contains code and other program
resources. These resources are only useful on Apple systems
and are not shown as part of the total file size on other
systems.
Finally the total length of all files within the archive, uncompressed
and compressed, the overall compression ratio for the archive, and the
number of files within the archive, is given. If any filespecs are
given, only files which match those filespecs will be displayed. This
is useful when you only want to extract certain files and would like to
see how much space they will use.
If more than one archive is viewed, a grand total of the size and
number of files in all the archives viewed is printed. The type of
information printed may be controlled by using the view options (which
are explained in the section "HPACK Options" below). The default is to
print all files and directories in the root directory of an archive.
If the root directory contains no files or directories matching the
given filenames and/or wildcards, the error message "No matching files
in archive" will be printed. To recursively display the contents of
all subdirectories, either the [-r]ecurse subdirectories option or the
wildcard string '*/*' should be used.
Example: To view the contents of any archives in the current directory
HPACK V *
[P] View files within an archive. This option will output the contents of
one or more files within an archive, with a prompt for more between
files. The output can be redirected in the standard manner, for
example:
HPACK P DATA CONTENTS.DOC | LPR
will send the file CONTENTS.DOC from within the archive DATA.HPK to the
printer, and:
HPACK P DATA DESCRIPTION.DOC | MORE
will display the file DESCRIPTION.DOC with page breaks on your screen.
Note that trying to display non-text files in this manner can be
interesting, if not terribly productive.
Example: To display the file README.TXT from within the archive
ARCHIVE.HPK:
HPACK P ARCHIVE README.TXT
[T] Test the integrity of an archive. HPACK will display the usual
messages about extracting data as it unpacks and tests the data, and if
it thinks the data has been corrupted it will issue the following
warning message:
Warning: File may be corrupted
Otherwise HPACK will display:
File tested OK
If, when all files have been tested, there were corrupted files, HPACK
will print the total number of corrupted files:
Warning: n files were corrupt
where n is the number of corrupted files.
Note that this test is also performed automatically on extracting a
file from an archive.
Example: To test the integrity of all MSDOS executable files in the
archive ARCHIVE.HPK:
HPACK T ARCHIVE *.COM *.EXE
[D] Delete files from an archive. All files given in the command-line are
deleted from the given archive.
I all files are deleted from an archive (leaving an empty archive),
HPACK will delete the archive as well.
Example: To delete all Pascal program files (a commendable move) from
the archive ARCHIVE.HPK:
HPACK D ARCHIVE *PAS
[F] Freshen files in an archive. The dates of all specified files in the
archive are compared with the dates of the same files on disk. If the
version on disk is more recent than the stored version, the stored
version is replaced by the version on disk. If all files in the
archive are uptodate, HPACK will display the message:
Archive is uptodate
and exit.
Example: To freshen all files in the archive ARCHIVE.HPK:
HPACK F ARCHIVE.HPK
[R] Replace files in an archive. All given files in the archive are
replaced by their counterparts on disk.
Example: To replace all the files which begin with the letters A-G in
the archive ARCHIVE.HPK with their couterparts on disk:
HPACK R ARCHIVE [A-G]*
[U] Update files to an archive. All specified files not already in the
archive are added to the archive, and all files already in the archive
are replaced if the version on disk is more recent than the version
already in the archive.
Example: To update the archive ARCHIVE.HPK with all files from the
directory B:/DATA/JUNK:
HPACK U ARCHIVE B:/DATA/JUNK
Note that the last four options need to create temporary work files on
disk. Thus it is necessary to have at least twice as much free disk
space to work with as the total length of the archive. All other
options use only the archive file, so it is possible to use them with
minimal free disk space.
HPACK Options:
-0 Store files without attempting any compression. This option can be used
to quickly add incompressible files to an archive or when breaking up a
large file to move to another system via a multidisk archive when space
isn't at a premium.
-a Store file attributes. Many operating systems support two levels of
files, those classed as 'normal', and those classed as 'hidden',
'invisible', 'system files', and so on (for example the Macintosh,
MSDOS, and the Atari ST all have these file types). By default HPACK
will only add normal files to an archive. However using the
[-a]ttributes flag allows archiving of files with special attributes as
well as full restoration of attributes when archives are extracted.
The [-a]ttributes flag is also necessary under some operating systems to
store extra information pertaining to a file, for example access control
information, file/directory type information, icons, and so on.
HPACK will attempt to translate the attributes of files from different
systems into equivalent file attributes for the local system. This has
varying degrees of effectiveness: Many of the Apple IIgs, Atari ST,
Macintosh, MSDOS, and OS/2 attributes are equivalent so a direct
translation is possible, and the Amiga, the Apple IIgs, the Archimedes,
Unix, and VMS also have some of the read/write attributes in common, and
have a rough equivalent of a read-only file attribute in these
attributes.
If directories are stored within the archive, HPACK will also store
directory attributes, and set the directory attributes to the stored
values when creating the directories on extraction.
Example: To extract all files in the root directory of the archive
ARCHIVE.HPK, restoring all possible attribute information:
HPACK X -A ARCHIVE
-b Specify a base pathname for all files. This option is followed by the
pathname which HPACK will use as a base path for all files to be added
to or extracted from an archive. This option is very convenient when
adding a number of files in the same directory to an archive or when
extracting an archive to a directory which is not the same as the
current directory. It is also useful for handling archives which
contain subdirectories. To add files to a subdirectory within HPACK,
the base pathname is used to specify the path to the subdirectory, with
the actual file pathname given being the path inside HPACK in which the
file will be stored. In this case the argument given with the [-b]ase
path option is the part of the pathname outside the archive, and the
file pathname is the part of the pathname inside the archive.
Example: To extract all files in the archive ARCHIVE.HPK to the
directory D:/OUTPUT/DATA:
HPACK X -BD:/OUTPUT/DATA ARCHIVE
Example: To add the files FILE1, FILE2, TEXT, and PROGRAM.EXE, all in
the directory D:/JUNK/DATA, to the archive ARCHIVE.HPK:
HPACK A -BD:/JUNK/DATA ARCHIVE FILE[1-2] TEXT PROGRAM.EXE
Example: To add the files in C:/JUNK/DATA/FILES to the archive
ARCHIVE.HPK inside the archive directory DATA/FILES:
HPACK A -BC:/JUNK ARCHIVE DATA/FILES/*
-c Encryption options (conventional and public-key encryption).
Encrypt/decrypt archive data using a selection of public- and
conventional-key encryption algorithms. Using this option with
conventional-key encryption will prompt for a passphrase before any
files are added, followed by a request to retype the passphrase for
security if the data is being encrypted. This passphrase, which is not
echoed to the screen, should be a minimum of eight and a maximum of
eighty characters long, and may contain any combination of upper and
lowercase letters, numbers, spaces, punctuation symbols, and control
characters. If public-key encryption is used, the userID of the
recipient of the data is specified as part of the encryption command.
Although HPACK itself will support non-ASCII text strings, the userID's
for public keys must be in ASCII format for compatibility with other
programs. Be warned that forgetting or losing a conventional or public-
key encryption key will present you with a fairly substantial exercise
in cryptography.
By default HPACK will encrypt entire archives (rather than just the
files in them), meaning that not even the archive directory can be read
by someone who does not have the decryption password.
The encryption options are divided into two classes, those employing
conventional-key encryption and those employing public-key encryption:
-c Use conventional-key encryption to encrypt the entire archive, the
same as [-c]rypt [a]ll.
-ci Encrypt individual files using conventional-key encryption. The
use of this option is not generally recommended as it is not quite
as secure as the standard [-c]rypt [a]ll option. It is however
useful when only a few files need to be encrypted, the rest being
subject to constant change which makes encrypting them impractical.
-ca Encrypt entire archive. This will encrypt not only the files
themselves but all additional data associated with them
(attributes, icons, and so on), as well as the archive directory
information. The only remaining accessible data is a small amount
of archive identification information needed to allow HPACK to
process the archive.
-cs Prompt for second password to access archive data. This allows the
archive directory to be encrypted with one password, and files to
be encrypted with another password. This option is useful if it is
desirable to give a group of users access to the archive directory
but not to the files themselves, since the contents of the archive
can be made available with the first password, but a second
password is required to access the files themselves.
-cpi
Encrypt individual files using the public key which matches the
given userID. The public-key-encryption equivalent of the [-c]rypt
option. This option is not recommended if more than a small number
of files are present in an archive due to the amount of time needed
to perform each public-key decryption calculation.
-cpa
Encrypt the entire archive using the public key which matches the
given userID. The public-key-encryption equivalent of the [-c]rypt
[a]ll option.
-cps
Encrypt the archive with a secondary public key which matches the
given userID. The public-key-encryption equivalent of the [-c]rypt
[s]econdary option.
When processing an encrypted archive, all that is necessary is to tell
HPACK to handle encrypted data by specifying the [-c]rypt option. HPACK
will determine the encryption type and prompt for passwords as necessary
as it processes the archive. If the archive is public-key encrypted and
the recipients secret key is protected by encryption, HPACK will prompt:
Please enter password for secret key (8..80 characters)
If an incorrect password is given, HPACK will warn:
Password is incorrect.
and allow the password to be reentered. Up to three attempts at the
password are allowed before HPACK gives up.
When searching for the key corresponding to a given userID, HPACK will
perform a case-insensitive match of the given userID against any part of
the keys userID. This means that only a partial userID need be given on
the command line, and HPACK will use the first key for which the partial
userID matches. This makes specifying the userID easier since the
entire ID need not be given, but also means care should be taken if
there are several similar userID's (all of which may match a certain
userID fragment) in a collection of keys. In all cases these userID's
act exactly like they do in PGP.
If there is a chance that the userID is ambiguous, the key can also be
specified by its keyID using the standard C programming language format
for hexadecimal values namely a prefix of '0x' and then the value
itself. The keyID is the 6-digit hexadecimal value displayed for the
key. As with userID's, HPACK will perform a case-insensitive match
against any part of the full keyID.
HPACK will also allow the public-key encryption of data for multiple
recipients, meaning that a single encrypted archive can be sent to an
arbitrarily large number of recipients. This allows archives to be
distributed to working groups or via mailing lists without necessitating
a seperate encrypted archive for each recipient. Note that there is a
slightly increased risk involved in this process since the chain of
intended recipients is only as strong as its weakest link - only one of
the private keys needs to be compromised to render the encrypted data
insecure.
The use of encryption for multiple recipients is specified by enclosing
a comma-seperated list of recipient userID's or keyID's inside a key-or
construct:
or(user1,user2,...userN)
On decryption, the data can be decrypted by user1 or user2 or ... userN.
Future versions of HPACK will also allow key-and (where all of a given
list of keys must be used to decrypt data) and key-quorum (where a
certain proportion of a given number of keys must be used to decrypt
data).
In addition there are moves afoot to add a mailing-list capability to
the public keyring format which will be fully supported by HPACK if it
eventuates.
Example: To encrypt the entire archive ARCHIVE.HPK, leaving only a small
amount of identification information readable:
HPACK A -C ARCHIVE
Example: To encrypt all files to be added to the archive ARCHIVE.HPK:
HPACK A -CI ARCHIVE
Example: To encrypt the entire archive ARCHIVE.HPK with the archive
directory readable by "TheMunsters" but the archive data itself only
readable by "UncleFester":
HPACK A -CPATheMunsters -CPSUncleFester ARCHIVE
Example: To encrypt the file BASEBALL.BAT in the archive ARCHIVE.HPK
with the key corresponding to the hexadecimal keyID A72F3B, taking
advantage of the fact that HPACK will match any fragment of the ID:
HPACK A -CPI0x2F3 ARCHIVE BASEBALL.BAT
Example: To encrypt the entire archive ARCHIVE.HPK making it readable
by either "Boris", "Igor", or "Ivan":
HPACK A -CPAor(Boris,Igor,Ivan) ARCHIVE
Note that the public-key decryption process can take a long time,
especially when it must be performed multiple times (for example when
the [-c]rypt [p]ublic-key [i]ndividual files option is used). HPACK
will display the message:
One moment...
whenever it performs the calculations involved in public-key decryption.
This process can often take significantly longer than one moment - on
slower machines HPACK may appear to have ground to a halt as it performs
the public-key decryption operation. Unless there is a special need for
it, the use of conventional-key encryption is recommended.
One advantage of public-key encryption is that the key management is
automatic - there is no need to enter passwords to perform the
encryption and decryption operations. When passwords must be entered
manually for conventional-key encryption, there is a chance that an
incorrect password will be entered by mistake. If this happens for
archive directories, HPACK will warn:
Warning: Archive directory corrupted, probably due to
incorrect password. Continue (y/n)
Since the password was incorrect, the archive directory information has
been decrypted incorrectly. The 'No' option should be selected and the
password reentered.
If this happens for archived files, the files will not be extracted
properly:
Warning: File may be corrupted
Again, the password should be reentered when HPACK is re-run.
-d Directory options. This hideously complicated command has a large
number of suboptions. Normally HPACK will store any directories it
finds files in inside an archive, in effect allowing you to archive
entire directory trees. This directory options allow more precise
control over the storing of directories inside the archive.
HPACK will add directories traversed only if there are files contained
in them. To add all directories regardless of whether they contain
files or not, use the [-d]irectories [a]ll option (see below).
The extended directory options are are as follows:
.
-da Store/extract all directories scanned, even if they contain no
files. This option is useful for storing entire filesystems inside
archives and restoring entire directory trees from archives.
-dc Create only immediate containing directory for a group of files,
not the entire directory path. This is mainly for use by GUI
versions of HPACK to allow extraction of individual directories,
folders, or drawers (depending on what the host operating system
calls them) of files.
-df Flatten directories. This option can be used to disable HPACK's
storing of directories, so that all files added or extracted are
placed in the same directory, in effect flattening the directory
structure.
-dm Mkdir: Create the given directories.
' where path is the new
directory to add and the non-matching filespec ensures that only
the new directory, but none of the files in it, are added>
-dn Do not create the directory inside the archive if it doesn't
already exist. If an attempt is made to add a file to a
nonexistent directory, HPACK will exit with the error message:
Path not found
-dr Rmdir: Delete the given directories.
-dv Mvdir: Move the given directory into the second given directory.
Warning: Through injudicious use of this command it is possible to
create circular directory references, or to cut off entire
directory trees. Do not try to move directories into
subdirectories of themselves! (Or should HPACK check for this??)
Example: To delete the directory DATA/JUNK inside the archive
ARCHIVE.HPK:
HPACK A -DR ARCHIVE DATA/JUNK
Note the use of the [A]dd command as a dummy command: In this case the
main command is ignored and only the directory option is used (ICK!).
Example: To move all files and directories in and below DATA/JUNK in the
archive ARCHIVE.HPK into the directory STUFF:
HPACK A -DV ARCHIVE DATA/JUNK STUFF
Example: To add all files and directories (even empty ones) in and below
the current directory to the archive ARCHIVE.HPK:
HPACK A -RPDA ARCHIVE
-e Add/use error recovery information. This option allows the adding of
error recovery information to the archive when adding files, or makes
use of error recovery information present in an archive. HPACK will
write extra information with the file data which may be used to recover
the data if the main archive directory is seriously damaged. This
recovery information will increase the amount of data stored for each
file by about 20-25 bytes. Note that although HPACK will add this extra
information, the current version will not make use of it.
Example: To add all text files in the directory A:/DATA to archive
ARCHIVE.HPK, adding error recovery information for each file:
HPACK -E ARCHIVE A:/DATA/*.TXT
Example: To extract the same files from the archive, making use of the
error recovery information:
HPACK X -E ARCHIVE *.TXT
-i Interactive mode - prompt for all actions. This option works for all
commands except [V]iew files (for which it would be pointless). Before
the file is processed, HPACK will ask whether you wish to process this
file; answering 'Y' will handle the file, 'N' will skip the file, and
'A' will process all files from this point (in other words it will
assume a 'Y' answer for each file from this point).
Example: To add all files in the current directory to the archive
ARCHIVE.HPK, prompting for each file before adding it:
HPACK A -I ARCHIVE *
-f Force file move into/out of an archive. This option can be used with
the [A]dd, [F]reshen, [R]eplace, [U]pdate, and [X]tract commands to move
the files instead of merely copying the data into or out of an archive.
Note that when the move option is used in conjunction with encryption,
HPACK will go to extreme lengths to destroy any traces of the file which
is being moved. Caution is recommended when using move with encryption
as forgetting the password or using the wrong public key will lead to
the permanent loss of the encrypted data.
If all files are moved out of an archive (leaving an empty archive),
HPACK will delete the archive as well.
Example: To move all text files from the archive ARCHIVE.HPK into the
current directory:
HPACK X -F ARCHIVE *.TXT
-k Overwrite existing archive. This only works with the [A]dd command.
Normally, using the [A]dd command will add any new files to the end of
an existing archive. Using the [-k]ill switch will erase the old
archive and create a new one.
Example: To create the archive ARCHIVE.HPK on drive A:, overwriting it
if it already exists, and add all files in the current directory to it:
HPACK A -K A:ARCHIVE
-l Security options (data authentication). This option allows the
encapsulation of either entire archives or individual files inside a
secure envelope which it is computationally infeasible to break. This
option allows anyone to later determine that the data has been both
untampered with, and genuinely came from the source (corresponding to
the userID) from which it claims to have originated.
When searching for the key corresponding to a given userID, HPACK will
perform a case-insensitive match of the given userID against any part of
the keys userID. This means that only a partial userID need be given on
the command line, and HPACK will use the first key for which the partial
userID matches. This makes specifying the userID easier since the
entire ID need not be given, but also means care should be taken if
there are several similar userID's (all of which may match a certain
userID fragment) in a collection of keys. In all cases these userID's
act exactly like they do in PGP.
If there is a chance that the userID is ambiguous, the key can also be
specified by its keyID using the standard C programming language format
for hexadecimal values namely a prefix of '0x' and then the value
itself. The keyID is the 6-digit hexadecimal value displayed for the
key. As with userID's, HPACK will perform a case-insensitive match
against any part of the full keyID.
If the secret key is protected by encryption, HPACK will prompt:
Please enter password for secret key (8..80 characters)
If an incorrect password is given, HPACK will warn:
Password is incorrect.
and allow the password to be reentered. Up to three attempts at the
password are allowed before HPACK gives up.
The security options are as follows:
-l
Secure the entire archive with security information from a given
userID.
-li
Secure individual files rather than the archive as a whole, with
security information for a given userID. The use of this option is
not generally recommended since the generation of the security
information for each file can consume a considerable amount of
time, and since only the files themselves are secured it leaves the
file attributes and directory information open to modification. It
is however useful when only a few files need to be secured, the
rest being subject to constant change which makes securing them
impractical.
Example: To create the archive ARCHIVE.HPK, add all files in the current
directory to it, and secure it on behalf of your cat:
HPACK A -LTHECAT ARCHIVE
-m Create a multipart archive. Normally when HPACK runs out of disk space
it will exit with an error message. When this option is used HPACK will
instead prompt for another disk and continue the archive on the new
disk. In this manner it is possible to spread an archive which would be
too large for a single disk over several disks. Due to their rather
special nature, multipart archives do not support the [D]elete,
[F]reshen, [R]eplace, or [U]pdate commands (since, for example, deleting
a file from the middle of an archive which stretches over 15 disks would
be quite time-consuming). All other operations are supported however.
Example: To fully back up hard drive C: onto drive A:
HPACK A -KMARDA A:ARCHIVE C:/*
This will create the archive ARCHIVE.HPK on one or more disks in drive
A: containing the complete contents of the drive C: (the options used
are [-k]ill existing archive, [-m]ultipart archive, store file and
directory [-a]ttributes, [-r]ecurse through all subdirectories, for
[-d]irectories store [a]ll of them, even empty ones). Once each disk
has been completely filled, HPACK will prompt:
Please insert the next disk and press a key
followed by the message:
Continuing...
as it continues the archive on the next disk inserted. Note the use of
the [-k]ill existing archive option to overwrite any existing archive of
the same name which may already exist on the disk - if HPACK finds an
archive of the given name already on the disk and the [-k]ill option is
not specified, it will not, by default, overwrite it but will exit with
an error message.
Multipart archives have a minimum size of around 500 bytes (roughly the
size of a disk sector for many disk formats - storing archive parts of
less than 500-odd bytes would be pointless). If a section of a multi-
part archive is less than approximately 500 bytes HPACK will skip it and
move it to the next (hopefully less full) disk after printing the
following warning:
Warning: Archive section too short, skipping...
If a multipart archive is small enough to fit onto a single disk, HPACK
will store the archive as a standard archive instead of a multipart one.
Example: To view the files in the previously created multipart archive:
HPACK V A:ARCHIVE
HPACK will automatically determine whether the archive is a multipart
archive or not so the [-m]ultipart command is only necessary when
creating the archive. Since HPACK stores its directory information at
the end of the archive, only the last disk or disks of the archive must
be read to obtain the archive directory. Initially HPACK will prompt:
Please insert the disk containing the last part of this archive and
press a key.
If the wrong disk is inserted, HPACK will prompt:
This is part of a multipart archive.
Please insert the disk containing the last part of this archive and
press a key.
where is the part number of this section of the archive.
Example: To extract the single file LETTER.TXT from the previously
created archive:
HPACK X A:ARCHIVE LETTER.TXT
HPACK will then prompt for the disk which contains the file LETTER.TXT:
Please insert the disk containing part of this
a key.
where is the part number of the archive section which contains
LETTER.TXT.
Example: To fully restore the contents of a hard drive from the
previously created archive:
HPACK X -ARDA A:ARCHIVE
HPACK will prompt for the last part of the archive as usual and then for
each disk in turn as it extracts the files from the archive.
-o Overwrite on extraction options. Normally when HPACK tries to extract a
file which already exists, it will prompt for whether the existing file
should be overwritten or not. With this switch it is possible to
specify a default action to be taken. There are four possibilities:
-oa Automatically overwrite [A]ll existing files on extraction.
-on Automatically overwrite [N]one of the existing files on extraction.
-os [S]mart overwrite. HPACK will change the extension of the file to
be extracted to "000", and try to extract this file. If a file of
this name already exists, the extension will be changed to "001"
and so on until it is possible to extract the file. This option is
very useful for files that have been archived on a system which
allows filenames which are longer or more complex than those
allowed by the local system and which due to the filename being
truncated or translated end up with identical names. Note that the
term "extension" can mean different things to different operating
systems - HPACK will do its best to use the local equivalent.
-op [P]rompt for new filename. HPACK will ask for a new filename and
try to use that name, repeating until a non-conflicting filename is
given.
Example: To extract all files from the archive ARCHIVE.HPK to the
current directory, skipping any files that already exist:
HPACK X -ON ARCHIVE
-r Recurse through subdirectories. HPACK will step through all sub-
directories of the current directory, and add all files with names
matching those given on the command line.
Example: To add all files in all directories in and below the current
directory to the archive ARCHIVE.HPK:
HPACK A -R ARCHIVE *
-s Run in stealth mode. All messages except warnings and error messages
are suppressed. HPACK will automatically turn on stealth mode if it
detects it is running in the background on operating systems which
support background operation.
Example: To add all files in the current directory to all archives in
the current directory, without printing the usual progress reports to
the screen:
HPACK A -S *
-t Touch files on extraction. Normally HPACK will give all files and
directories extracted the original date they had when they were
archived. Using the [-t]ouch option will give files and directories the
current date.
Example: To extract all files from the archive ARCHIVE.HPK, giving them
todays datestamp:
HPACK X -T ARCHIVE
-u Unified compression mode. In this mode HPACK will attempt to achieve
increased compression by using unified compression across all files to
be added. This is especially effective when many generally similar
files or many small files are being added to an archive. The
disadvantage of unified compression is that the archive cannot be
updated or changed later, and that when extracting individual files
there is a slight speed penalty as intervening files are skipped.
Unified compression is ideal for storing data like Usenet news articles,
collections of icons, and program source code, in which cases
significant compression gains are usually seen.
Example: To add all files in /USR/SPOOL/NEWS/COMP/COMPRESSION to the
archive COMPRESS.HPK using the unified compression mode:
HPACK A -U COMPRESS /USR/SPOOL/NEWS/COMP/COMPRESSION/*
-v View options. Normally when the [V]iew command is used, HPACK will
print information on all the directories and files in an archive. With
these options it is possible to specify which parts of the archive
directory are to be viewed. There are two possible options:
-vf Display information only on matching files.
-vd Display information only on matching directories.
Example: To print all the files, but not any directories or
subdirectories, in the archive ARCHIVE.HPK:
HPACK V -VF ARCHIVE.HPK
-w Treat files as archive comments. This makes the [A]dd, [D]elete,
[F]reshen, [R]eplace, and [U]pdate commands work for archive comments
instead of normal files. Archive comments are files which are displayed
when the [V]iew archive command is used, and may contain text describing
the contents of the archive, ANSI extended characters, graphics,
digitised sound, even full motion video with 16-bit stereo sound if
desired. Most CLI versions of HPACK will currently only handle the
displaying of plain text, although some will handle ANSI-text type
archive comments as well. Comments can be added, deleted, replaced, and
so on just like normal files. Subdirectories can contain their own
comments, and each directory can contain multiple comment files. In
addition comment filenames are not treated as normal archive filenames,
so a directory can contain a comment file and a normal archived file of
the same name. Possible archive comment types are:
-w Plain text comment. This can be entered in free-form since HPACK
will automatically word wrap the text to fit the screen size.
Plain text comments may also contain formatting commands which
control the way the text is displayed. For more information on
formatting the text comments, see the extended documentation file
HPACKEXT.DOC.
-wa ANSI text comment. This type of comment can contain the extended
8-bit character set used by IBM PC's, as well as ANSI escape codes.
No reformatting of any type is done on ANSI comments. Note that
the plain text comment type is preferred, since many systems cannot
display the extended ANSI character set or interpret ANSI escape
codes. Also note that if an ANSI comment is stored as plain text
HPACK will quietly delete all extended characters and ANSI escape
codes when it displays the comment, to make it conform to the 7-bit
ASCII character set.
-wg GIF format graphics comment. Display of this comment format is
generally only suported on systems running graphics-based user
interfaces.
-wj JPEG format graphics comment. Display of this comment format is
generally only suported on systems running graphics-based user
interfaces.
-wm MPEG format graphics comment. Display of this comment format is
generally only suported on systems running graphics-based user
interfaces.
Example: To view all comment-type files in the archive ARCHIVE.HPK as
files instead of displaying them as comments:
HPACK V -W ARCHIVE.HPK
-x Text file translate options. Different systems store text files in
different formats, for example on the Amiga, the Archimedes, and under
Unix, these are stored in ASCII format with a linefeed at the end of
each line; on the Atari ST and under MSDOS and OS/2, there are carriage
return/linefeed pairs at the end of each line; and on the Macintosh,
there are carriage returns at the end of each line. Some systems store
text in a non-ASCII format altogether, for example IBM systems which use
the EBCDIC character set, and Prime systems which use their own bizarre
text encoding technique. Using this option it is possible to specify
translation of different character systems and end-of-line markers to
the one used by the local system. In most cases the [-x]late option
will suffice, however it is possible to override the translation using
the following options:
-x Smart translate. HPACK will attempt to translate all files it
recognises as text files from the textfile format used on the
system the file was archived on to the textfile format used on the
system the file is being extracted on. In most cases this option
will be the only one necessary.
-xr Treat carriage return (ASCII 13) as end-of-line marker. The
Macintosh stores text this way.
-xl Treat linefeed (ASCII 10) as end-of-line marker. Text on the
Amiga, the Archimedes, and UNIX systems is stored in this manner.
-xc Treat carriage return/linefeed pairs as end-of-line marker. The
Atari ST, MSDOS and OS/2 store text files like this.
-xxnn
Treat the one- or two-character hexadecimal value 'n' or 'nn' as
the character to use as the end-of-line delimiter. For example
when moving textfiles from a QNX 2.x/3.x system (which uses the RS
character, ASCII 30 or 1E hexadecimal), the option would be -xx1e.
-xe Translate the character set from EBCDIC to ASCII. Text on IBM
systems is stored this way.
-xp Translate the character encoding from that used on Prime systems to
ASCII.
-xa Translate from ASCII to ASCII.
The textfile translation works by first translating entire character
sets (either ASCII, Prime ASCII or EBCDIC) if necessary, and then
translating the end-of-line characters, depending on the options
specified.
The end-of-line translation options are only available where they would
make sense (for example the ability to translate linefeed to linefeed
isn't particularly useful). The possible translation options are shown
below, with LF being the linefeed character, CR being carriage return,
and CRLF being carriage return/linefeed pairs:
To | Atari ST Amiga
| MSDOS Archimedes Macintosh
From | OS/2 Unix
----------+-----------------------------------------------
Atari ST |
MSDOS | [-xc] [-xc]
OS/2 | --- CRLF -> LF CRLF -> CR
|
Amiga |
Archimedes| [-xl] [-xl]
Unix | LF -> CRLF --- LF -> CR
|
| [-xr] [-xr]
Macintosh | CR -> CRLF CR -> LF ---
|
Example: To extract all files with the extension ".TXT" from the archive
ARCHIVE.HPK, translating linefeed characters into whatever end-of-line
character the local system uses:
HPACK X -XL ARCHIVE *.TXT
Example: To extract all files with the extension ".TXT" from the archive
ARCHIVE.HPK, translating the files from EBCDIC to ASCII, and
translating all carriage return characters to the end-of-line character
used by the local system:
HPACK X -XEXR ARCHIVE *.TXT
HPACK Extended Options
The extended options supported by HPACK are usually somewhat system-
specific and in general will only be present on one particular version of
HPACK. They either support the storing/extraction of system-specific
information in archives, or the special handling of data which has been
archived on another system. The recognised options are:
+devcheck
MSDOS version only. MSDOS has a serious problem in that when a file
with the same name as a device driver is extracted (for example 'CON',
'COM1', or 'LPT1') it will force the contents of that file into the
device driver. The damage can be minor for devices like 'CLOCK$' (it
will at a minimum mangle the system date and time, perhaps scramble the
CMOS ram, or cause the system to hang - even the changing of system
dates can cause problems on a system running a computer bulletin board
which relies on correct timestamps), all the way through to very serious
for devices like 'SMARTAAR' (it will corrupt the disk cache and
therefore corrupt the drives being cached).
The [+devcheck] option will check each file before extracting it, and
if it corresponds to a device driver will print the warning:
File corresponds to device driver - skipping
and move on to the next file. The only way in which HPACK will allow a
file of this type to be extracted is by using the [-o]verwrite [p]rompt
option, in which you will be prompted for a new filename to extract
under. Even [-o]verwrite [s]mart is unsafe since the peculiar handling
of device drivers by DOS makes the automatic substitution of a new
filename very difficult.
Filenames which can cause these problems are virtually unheard-of - they
would have to be created deliberately by a malicious user, in which case
there are few limits on the potential damage they can cause.
+invert
Archimedes version only. ADFS doesn't support extensions to filenames
since dots are used as directory delimiters, which can lead to problems
when moving, for example, source code files ending with the traditional
.c and .h to the Archimedes. Many programs allow a workaround where the
file foo.c is accessed as c.foo. This option allows this form of
inversion of the filename/directory structure so that *.c and *.h would
be extracted as c.* and h.*. So for example:
include/stdio.h
would be extracted as:
include.h.stdio
This command usually invokes an intense sense of disbelief in
non-Archimedes owners.
Incidentally, non-Archimedes owners may wonder what the Archimedes uses
in place of a '.' in filenames. It uses a '/', of course.
+lower
Amiga, Archimedes, OS/2, Macintosh, and Unix versions only. Force all
file and directory names to lowercase. Some systems store file and
directory names in uppercase only. Using this option all names will be
converted to lowercase before any operations (such as [V]iew archive,
[X]tract from archive, and so on), are performed on them. When
processing Atari ST, MSDOS, and some OS/2 archives, the use of the
[+lower] option is recommended.
+noext
By default HPACK will force an extension of '.HPK' (where the operating
system allows it) to be added to the archive name, with any existing
extension being replaced by '.HPK'. This option allows the default
behaviour to be overridden so that no extension is added or changed.
However this lack of an extension will force HPACK to work much harder
in deciding what is and isn't an HPACK archive, and will disable certain
features such as its ability to automatically pick out HPACK archives
when simply told to process all files in a directory. This option is
mainly for use with automated mail-processing software such as Fidonet
mail unpackers which depend on the extension for information on the
packet contents.
+noumask
Unix version only. Normally the setting of the umask environment
variable affects the attribute bits of any files and directories HPACK
creates. This option overrides the umask setting and uses the
attributes stored within the archive. Since these attributes can be set
to allow outsiders read/write access to files and directories which
would normally be off-limits to them, this option should be used with
care.
+rsx
VMS version only. Normally VMS files can have 39 characters of filename
and 39 characters of extension, or type. This can lead to
strange-looking filenames when they are truncated from operating systems
which allow longer or more flexible names. Using this option truncates
filenames to an RSX-11 compatible format, which results in more
traditional-looking names with 9 characters of filename and three
characters of file type, and directory names with 9 characters of
filename.
+select
Apply an SQL SELECT command. This option is explained in more detail in
the section "HPACK SQL Commands" in the extended documentation
HPACKEXT.DOC.
+type
Archimedes, Apple IIgs, and Macintosh versions only. Some operating
systems store file type information for each file. HPACK will, when
extracting files, try to determine the type information for each file
and set it correctly. However in some cases no type information can be
determined, or the determined information may be incorrect. This option
can be used to set type information for a file, or to override HPACK's
internal type-determining rules.
Type information is given as a type-association, associating a file
extension with whatever type information the OS requires, and is given
in the form:
.={,}
For example to associate the Macintosh ThinkC source file type with the
extension ".c", the type argument would be "TEXT,KAHL", corresponding to
the ThinkC file type and creator type.
Example: To associate the ".c" extension on the Macintosh with the
ThinkC source file type:
+type.c=TEXT,KAHL
Example: To associate the ".gif" extension on the Archimedes with the
GIF file type:
+type.gif=693
The types given above are actually already part of HPACK's default rule
set for type associations, but can be overridden with the use of the
[+type] option if desired.
HPACK Archive Integrity
HPACK checks the integrity of files stored within an archive by encoding a
continuous checksum as part of each file when it is archived, and decoding
it as the file is extracted. As soon as an error is encountered, HPACK will
skip over the rest of the file and move on to the next one. If the file
checksums differ then it may be reasonably assumed that there is an error in
the extracted data. This is important: The entire physical universe,
including HPACK itself, may one day collapse back into an infinitely small
space. Should another universe subsequently re-emerge, the integrity of
HPACK archives in that universe cannot be guaranteed.
HPACK also checksums the archive directory. If an error is found in the
directory information, the message:
Warning: Archive directory corrupted. Continue (y/n)
will be displayed. Hitting 'N' at this point will abort any attempts to
process the archive, hitting 'Y' will process the (damaged) archive. HPACK
will attempt some error recovery in this case (for example files and
directories which seem to be in impossible directories will be moved into
the root directory), and some files may be able to be recovered. If error
recovery information (specified with the [-e]rror recovery option (see
"HPACK Options" above)) is present, chances of recovering data from an
archive with a corrupted directory are greatly enhanced.
HPACK Archive/Data Authentication:
Data authentication facilities in an archiver should provide the following
features:
1. Sender authenticity. The data could only have come from the source
which it is supposed to have come from.
2. Data integrity measures. Any attempt to tamper with the data should be
recognised and reported by the authentication system.
3. Non-repudiation of origin. The originator of the data cannot later
disclaim responsibility for it.
HPACK includes provisions for authenticating archived data by adding a
unique digital signature to either entire archives or individual files
within an archive. This works exactly like a normal signature on a piece of
paper, proving that the sender was the true originator of the file or
archive. Forgery of a digital signature of this sort is computationally
infeasible, and once the data has been signed the sender cannot later
disavow his or her signature. In addition a cryptographic checksum of the
data or archive is made and included as part of the signature to allow
detection of any attempts to tamper with the data. Like forging a
signature, defeating the checksum is computationally infeasible.
When the data in an archive with authentication information present is
extracted or tested, an authentication check is performed for the entire
archive before it is processed. Similarly, an authentication check is
performed on files before they are extracted if there is authentication
information present.
In order for the authenticity information generation and checking to be
possible, two key files are required. To secure archives, the files
SECRING.PGP or RIPEMPRV, which contain the secret key of the person securing
the archive, are required. To check secured archives, the files PUBRING.PGP
or RPUBKEYS, which contain the public key of the person or organization who
signed the file or archive, are needed. These key files are generated and
managed by either version 2.0 or higher of Philip Zimmermanns excellent PGP
encryption package (for the PGP keys), or various implementations of PEM,
among them Mark Riordans equally good RIPEM encryption package. If you
don't have a copy of PGP or RIPEM, it is recommended you obtain one. PGP is
freely available on many archive sites, computer bulletin boards and other
systems. RIPEM may only be available within the United States. PGP is also
required to handle any key management, and for authentication of the keys
themselves. RIPEM currently doesn't support much key management or key
authentication. The PGP documentation and portions of the extended HPACK
documentation HPACKEXT.DOC are recommended reading for those wanting more
information on the background of PGP and the security techniques used by PGP
and HPACK.
If PEM (Privacy-Enhanced Mail) ever becomes a reality, HPACK will support
PEM/PKCS format keys as well as PGP ones. This will allow data to be
encrypted and decrypted inside the US with PEM keys and outside the US with
PGP keys, allowing, for the first time, the easy transfer of public-key
encrypted data to and from the US.
Before HPACK can use it, the secret keyring SECRING.PGP must have a small
amount of extta information added to it. Details on this are given in the
section "Using PGP Secret Keyrings" below.
HPACK will search for the key files in the directories given in the
environment variables PGPPATH and PEMPATH. These variables should contain
the paths to any PUBRING.PGP, SECRING.PGP, RIPEMPRV, and RPUBKEYS files
which are needed, with more than one path being possible. In order to
eliminate the possibility of spoofing via a bogus keyring placed in the
current directory, HPACK will, like all well-designed OS shells, not search
the current directory unless this is explicitly specified in the PGPPATH or
PEMPATH variables with the use of the "." option indicating the path to the
current directory.
For example if the search path for PGP keyrings included the directories
$HOME/bin/pgp, /usr/bin/pgp, and /usr/local/pgp then PGPPATH should be set
with:
set PGPPATH=/bin/pgp (Amiga, Atari ST, MSDOS, OS/2)
set PGPPATH filesys::drive.$.bin.pgp,filesys::drive.$.usr.bin.pgp
set PGPPATH ,filesys::drive.$.usr.local.pgp
(Archimedes)
setenv PGPPATH ~/bin/pgp:/usr/bin/pgp:/usr/local/pgp
(Unix csh)
PGPPATH=$HOME/bin/pgp:/usr/bin/pgp:/usr/local/pgp; export PGPPATH
(Unix sh)
The directories for PGP and PEM keyrings are always searched in the order
given in the PGPPATH and PEMPATH variables. Note that in the above example
the single-user Amiga, Atari ST, MSDOS and OS/2 systems only have a single
path for keyrings, whereas the multiuser Unix environments have multiple
search paths corresponding to custom user keyrings followed by system-wide
master keyrings.
If the data in the archive, or the archive itself, is to be checked, the
authentication check will be performed using the key found in PUBRING.PGP or
RPUBKEYS. If the authentication check succeeds, the message:
Good signature from .
Signature made on .
will be displayed, with being the name of the person or organization
who made the signature, and being the date the signature was made (on
some systems the signature time may be off by a few hours if the system
doesn't adjust for different time zones properly). If the check fails, the
message:
Warning: Bad signature, doesn't match file contents.
Bad signature from .
Signature made on .
will be printed. If the archive is a multipart archive (for which the
authentication check can take some time since an archive stretching over
several disks needs to be processed), the message:
Verify multipart archive authenticity [y/n]
is displayed. 'Y' will check the authenticity of the archive, 'N' will skip
the authenticity check and continue with processing the archive.
If the data in the archive, or the archive itself, is to be secured, the
authentication information will be generated using the key found in
SECRING.PGP or RPEMPRIV.
The signature scheme used is the RSA public key cryptosystem (for more
information on this and the PGP encryption package see the extended
documentation HPACKEXT.DOC). This scheme involves the manipulation of very
large numbers, which can be quite time-consuming on slow systems, where the
signature generation and checking can take several minutes (for this reason
the use of authentication for entire archives rather than individual files
in an archive is recommended).
Unlike encryption software, authentication code is not export-restricted
from the US. The U.S. Code of Federal Regulations, Title 22 which includes
sub-chapter M, "International Traffic in Arms Regulations" (ITAR), makes an
exception for software that can only be used for authentication purposes and
cannot not be used for general-purpose encipherment and decipherment, as is
the case for the data authentication code in HPACK.
HPACK Archive/Data Encryption
HPACK allows data stored in an archive to be encrypted with a variety of
public or conventional-key encryption algorithms. Encryption of either
entire archives or individual files is possible, as well as the use of
multiple keys to encrypt different sections of an archive (though the use of
public-key encryption is preferred for this since its inherent automatic key
management greatly simplifies handling the encrypted data).
When chosing an encryption key for a conventional-key algorithm, the
following guidelines should be observed:
- HPACK allows keys of up to 80 characters in length. These keys can
contain letters, numbers, spaces, and punctuation. This fact should be
made use of to the fullest, with preferred passwords being entire phrases
rather than individual words. There exist programs designed to allow
high-speed password cracking of conventional-key encryption algorithms
which can, in a matter of hours (sometimes minutes, even seconds in the
case of very weak algorithms), attempt to use the contents of an average
large dictionary as sample passwords. Most passwords composed of single
words can be broken with ease in this manner, even in the case of
algorithms like the MDC one which is used by HPACK, which has been
specially designed to be resistant to this form of attack (doing a brute-
force search of all 8-letter passwords (the minimum length allowed by
HPACK) assuming a worst-case situation in which the password contains
lowercase letters only, can be accomplished in 662 years on a fast CPU
(Sparcstation IPX) if the attacker knows the contents of the encrypted
file(s) in advance - or about 8 months on a network of 1000 of these
machines. Using an intelligent dictionary-based cracking program will
reduce this time significantly. This is especially apparent if the
encryption algorithm used is very weak - the Pkzip encryption, for
example, can be broken in this manner in a few seconds on a cheap personal
computer using the standard Unix /usr/dict wordlist).
- Simple modifications to passwords should not be trusted. Capitalizing
some letters, spelling the word backwards, adding one or two digits to the
end, and so on, only present a slightly more difficult challenge to the
average password-cracker than plain unadorned passwords.
- Probably the most difficult passwords to crack in this manner are ones
comprising phrases or sentences, since instead of searching a small body
of text like the contents of a dictionary, the cracker must search a much
larger corpus of data, namely all possible phrases in the language being
used. Needless to say, the use of common phrases should be avoided, since
these will be an obvious target for crackers.
As is the case when using public-key encryption for data/archive
authentication, the secret keyring SECRING.PGP will need to have a small
quantity of extra information added to it, for which details are given in
the section "Using PGP Secret Keyrings" below.
HPACK Internationalization
HPACK is available in Bavarian, Dutch, English, German, Italian, Polish,
Spanish, and Swiss German versions using the ASCII, IBM PC (Codepage 437),
IBM Codepage 850, IBM Codepage 869, ISO 8859-1 (Latin 1), ISO 8859-2 (Latin
2), ISO 8859-3 (Latin 3), ISO 8859-4 (Latin 4), Macintosh, Mazovia, and
NeXTSTEP character sets. The exact language and character set used by HPACK
is controlled by the environment variables CHARSET and LANGUAGE. By default
HPACK interacts with users in English using the ASCII/ISO646 character set.
By setting these two variables, another language and/or character set can be
selected. Note that not all combinations of languages and character sets
will provide a useful result.
Possible options for LANGUAGE are 'bavarian', 'dutch', 'english', 'german',
'italian', 'polish', 'spanish', and 'swiss'.
Possible options for CHARSET are 'ascii', 'cp850', 'cp869', 'ibmpc',
'iso8859-1', 'iso8859-2', 'iso8859-3', 'iso8859-4', 'macintosh', 'mazovia',
and 'nextstep'.
For example to set HPACK to interact with the user in Italian using the ISO
8859-1 (Latin 1) character set, the environment variables should be set as
follows:
set LANGUAGE=italian
set CHARSET=iso8859-1 (Amiga, Atari, MSDOS, OS/2)
or
set LANGAUGE italian
set CHARSET iso8859-1 (Archimedes)
or
setenv LANGUAGE=italian
setenv CHARSET=iso8859-1 (Unix csh)
or
LANGUAGE=italian; export LANGUAGE
CHARSET=iso8859-1; export CHARSET (Unix sh)
Obtaining Public Keys
There are currently several key servers which can be used to obtain PGP
public keys through the Internet and UUCP email systems. These are a
convenient way of obtaining keys for people you wish to communicate with. The
servers do NOT attempt to guarantee that a key is a valid key - the signators
on the key should be used for that kind of security. These services can be
discontinued at any time without prior notification.
Operating key servers as of 1 July 1993 are:
Server: pgp-public-keys@pgp.iastate.edu
Administrator: Michael Graff
Site: Iowa State University
FTP: tbird.cc.iastate.edu:/usr/explorer/public-keys.pgp
Server: pgp-public-keys@toxicwaste.mit.edu
Administrator: Derek Atkins
Site: MIT/Athena
FTP: toxicwaste.mit.edu:/pub/keys/public-keys.pgp
Server: pgp-public-keys@phil.utmb.edu
Administrator: John Perry
Site: University of Texas
FTP: phil.utmb.edu:/pub/pgp/public-keys.pgp
Server: pgp-public-keys@cs.tamu.edu
Administrator: Gary Ratterree
Site: Texas A&M University
Server: pgp-public-keys@demon.co.uk
Administrator: Mark Turner
Site: Demon Internet Services, UK
FTP: ftp.demon.co.uk:/pub/pgp/pubring.pgp
Server: pgp-public-keys@chao.sw.oz.au
Administrator: Jeremy Fitzhardinge
Server: pgp-public-keys@kiae.su
Administrator: Victor Borisov
Site: Relcom Corporation, Moscow
Server (UUCP): pgp-public-keys@jpunix.com (uunet!jpunix!pgp-public-keys)
Administrator: John Perry
Site: J. P. and Associates
Server (UUCP): pgp-public-keys@proxima.alt.za
Administrator: Lucio de Re
Updates to this list are posted to the Usenet alt.security.pgp newsgroups.
Each keyserver processes requests in the form of mail messages. The commands
for the server are entered on the 'Subject:' line of the message, for
example:
To: pgp-public-keys@junkbox.cc.iastate.edu
Subject: help
In the above example the server will return an informational message on how
to use it. Other possible commands are:
Command Message body contains
------- ---------------------
ADD Your PGP public key to add to server.
INDEX Returned list of all PGP keys the server knows about (the
same as the output from PGP's -kv command).
VERBOSE INDEX Returned list of all PGP keys in verbose format (the same
as the output from PGP's -kvv command).
GET Returned complete public key ring from the server.
GET Returned public key for the given userID.
MGET Returned set of keys for which the userID matches the
given
LAST All new keys added in the last days.
To have your key added to the collection maintained by the key servers, save
your public key to a file in ASCII-armoured format and simply mail it to one
of the PGP key servers using 'add' as the message subject line. For example
with most command-line oriented mailers the command would be:
mail -s add < file.asc
To get the key for the userID 'pgut1' (my own public key), the command would
be:
mail -s "get pgut1"
To get multiple keys using the mget command, possible options are:
mget michael Gets all keys whose userID's have "michael" in them.
mget F605A5|3A738B Gets the two keys with the given keyID's.
In addition to this service, there is a large collection of public keys
available for anonymous FTP at:
ftp.informatik.uni-hamburg.de:/pub/virus/misc/pubkring.pgp
To have your key added to the collection send it to Vesselin Bontchev,
bontchev@fbihh.informatik.uni-hamburg.de.
Using PGP Secret Keyrings
Like PGP and PEM implementations, HPACK can store its secret keys in an
encrypted format to protect them from prying eyes. However the encryption
algorithm HPACK uses is somewhat different to the one used in PGP due to
patent restrictions and in PEM due to export restrictions. This means that
encrypted PGP keyrings need to have a small amount of extra information
added to them before HPACK can use them. The HPACK distribution includes a
utility called KEYCVT which performs this task. KEYCVT is run as follows:
KEYCVT [