view release on metacpan or  search on metacpan

lib/Crypt/PWSafe3/Databaseformat.pm  view on Meta::CPAN

=head1 NAME

PasswordSafe database format description version 3.03


=head1 LICENSE

Copyright (c) 2003-2008 Rony Shapiro <ronys@users.sourceforge.net>.
All rights reserved. Use of the code is allowed under the Artistic
License terms, as specified in the LICENSE file distributed with this
code, or available from
http://www.opensource.org/licenses/artistic-license-2.0.php 

=head1 1. Introduction

This document defines a file format for the secure
storage of passwords and related data. The format is designed
according to current cryptographic best practices, and is beleived to
be secure, in the sense that without knowledge of the master
passphrase, only a brute-force attack or a flaw in the underlying
cryptographic algorithm will result in unauthorized access to the
data.

1.1 Design Goals: The PasswordSafe database format is designed to be
secure, extensible and platform-independent.

1.2 History: This specification is an evolution of previous
formats. The main differences between version 3 of the format and
previous versions are:
1.2.1. This version addresses a minor design flaw in previous versions
of the PasswordSafe database format.
1.2.3. This version replaces the underlying cryptographic functions
with more advanced versions.
1.2.4. This version allows the detection of a truncated or
corrupted/tampered database.

Meeting these goals is impossible without breaking compatibility: This
format is NOT compatible with previous (major) versions. Note,
however, that since the data stored in previous versions is a proper
subset of the data described here, implementers may read a database
written in an older version and store the result in the format
described here.

=head1 2. Format

A V3 format PasswordSafe is structured as follows:

    TAG|SALT|ITER|H(P')|B1|B2|B3|B4|IV|HDR|R1|R2|...|Rn|EOF|HMAC

Where:

2.1 TAG is the sequence of 4 ASCII characters "PWS3". This is to serve as a
quick way for the application to identify the database as a PasswordSafe
version 3 file. This tag has no cryptographic value.

2.1 SALT is a 256 bit random value, generated at file creation time.

2.3 P' is the "stretched key" generated from the user's passphrase and
the SALT, as defined in by the hash-function-based key stretching
algorithm in [KEYSTRETCH] (Section 4.1), with SHA-256 [SHA256] as the
hash function, and ITER iterations (at least 2048, i.e., t = 11).

2.4 ITER is the number of iterations on the hash function to calculate P',
stored as a 32 bit little-endian value. This value is stored here in order
to future-proof the file format against increases in processing power.

2.5 H(P') is SHA-256(P'), and is used to verify that the user has the
correct passphrase.

2.6 B1 and B2 are two 128-bit blocks encrypted with Twofish [TWOFISH]
using P' as the key, in ECB mode. These blocks contain the 256 bit
random key K that is used to encrypt the actual records. (This has the
property that there is no known or guessable information on the
plaintext encrypted with the passphrase-derived key that allows an
attacker to mount an attack that bypasses the key stretching
algorithm.)

2.7 B3 and B4 are two 128-bit blocks encrypted with Twofish using P' as the
key, in ECB mode. These blocks contain the 256 bit random key L that is
used to calculate the HMAC (keyed-hash message authentication code) of the
encrypted data. See description of EOF field below for more details.
Implementation Note: K and L must NOT be related.

2.8 IV is the 128-bit random Initial Value for CBC mode.

2.9 All following records are encrypted using Twofish in CBC mode, with K
as the encryption key.

2.9.1 HDR: The database header. The header consists of one or more typed
fields (as defined in section 3.2), terminated by the 'END' type field. The
version number field is mandatory. Aside from the 'END' field, no
order is assumed on the field types.

2.9.2 R1..Rn: The actual database records. Each record consists of one or
more typed fields (as defined in Section 3.2), terminated by the 'END' type
field. The UUID, Title, and Password fields are mandatory. All non-
mandatory fields may either be absent or have zero length. When a field is
absent or zero-length, its default value shall be used. Aside from the
'END' field, no order is assumed on the field types.

2.10 EOF: The ASCII characters "PWS3-EOFPWS3-EOF" (note that this is
exactly one block long), unencrypted. This is an implementation convenience
to inform the application that the following bytes are to be processed
differently.

2.11 HMAC: The 256-bit keyed-hash MAC, as described in RFC2104, with SHA-
256 as the underlying hash function. The value is calculated over all of
the plaintext fields, that is, over all the data stored in all fields
(starting from the version number in the header, ending with the last field
of the last record). The key L as stored in B3 and B4 is used as the hash
key value.

3. Fields: Data in PasswordSafe is stored in typed fields. Each field
consists of one or more blocks. The blocks are the blocks of the underlying
encryption algorithm - 16 bytes long for Twofish. The first block contains
the field length in the first 4 bytes (little-endian), followed by a one-
byte type identifier. The rest of the block contains up to 11 bytes of
record data. If the record has less than 11 bytes of data, the extra bytes
are filled with random values. The type of a field also defines the data
representation.

=head1 3.1 Data representations