	Written By:	Adam Berent
Document Revision 1.1

Password Based Cryptography

Outline

1. Preface

2. Summary

3. Message Format

3.1. XML Schema

4. Padding

5. Salt Generation

6. Deriving the Iteration Count

7. Initialization Vector

8. Key Derivation Function

9. HMAC

10. Encryption

11. Decryption

12. Multiple File Encryption

13. File Destruction

14. Base64

15. References

16. Test Vectors

1.0 Preface

The following document provides a guideline for implementation of password-based (symmetric) cryptography. The goal of this guideline is to provide a relatively simple and secure implementation. The document follows the PKCS#5 v2 standard in all aspects except for the message format. The message is instead stored in XML rather then ASN.1.

1.1 Introduction

Encryption algorithms can be divided into two distinct categories: symmetric and asymmetric. These are also often referred to as conventional and public key encryption algorithms. Conventional encryption uses the same key for both encryption and decryption. On the positive site conventional encryption is much faster, easier to implement and manage. However it is almost impossible to use for communication between two parties without prior contact. The problem is how do you get the encryption key to the other user? This problem is solved by public key encryption. However public key encryption has its own problems as it is very slow and often requires a third party to verify keys. In reality most cryptographic systems use public key encryption for exchanging keys and conventional encryption for data encryption.

There are however many cases where a full cryptographic system is not needed and conventional encryption will do. This often happens when the encrypted data does not need to be exchanged between two users. A good example of this is hard disk encryption. This document focuses on data encryption using conventional encryption and omits public key encryption entirely.

It is surprisingly difficult to encrypt data considering the last two decades of advances in modern cryptography. One would presume that simply using a modern encryption algorithm such as AES or 3DES would be sufficient. Unfortunately this is not the case. There are many small details that need to be considered. For example how do we derive the encryption key? Do we rely on the user to enter binary data, or do we ask him to enter a pass phrase and later generate a key? If so what algorithm can we use to generate this key? How do we prevent an attacker to simply keep guessing the most likely pass phrases and eventually decrypt the file? The list of these issues goes on.

Fortunately there are well defined and tested standards that we can follow to successfully secure our data. Unfortunately this information spans many separate documents and is hard to collect and follow without any background information. One of the goals of this document is to collect all relevant information into a single source that is easy to follow for even an inexperienced user.

2.0 Summary

The system outlined in this document requires an implementation various encryption, message digest algorithms.

A minimum of one of the following encryption algorithms will be needed:

· AES-128

· AES-192

· AES-256

A minimum of one of the following message digest algorithms will be needed:

· SHA-1

· SHA-256

· SHA-512

The document also uses various supporting methods and modes.

· CBC Mode of operation

· HMAC Signature

· Key Derivation Function

· XML Message Format

The end of this document provides various references to the above-mentioned algorithms and supporting methods.

3.0 Message Format

The encrypted cipher text as well as the supporting information is encapsulated in XML. The XML tags are not encrypted, only the certain values between them.

Here is a sample XML message:

<?xml version="1.0"?>

<SaltValue>DFEEBEBF</SaltValue>

<CipherValue>DEADBEEF</CipherValue>

</CipherData>

<SignatureValue>cOQGJE3d3fXi1BIfdvr1v6tz/4lt9xGznfyDPXEvc4Q=</SignatureValue>

</Signature>

</EncryptedData>

The only optional value in the message is <DocumentName>; the value of that field can be left blank although the XML tag should always be present.

Some of the values must be encoded in base64 in order to be visible using variants of ASCII and EBCDIC characters. This is done so that the encrypted message can be viewed as text in a web browser, email or even just notepad.

The following XML tags contain values encoded in base64:

<SignatureValue>

3.1 XML Schema (XSD)

The purpose of the XML Schema is to define what elements are types are legal in a given XML document. The XML Schema is usually saved in a separate file with the extension XSD. For those people not familiar with XSD documents the important portions to note are the legal algorithm types for the Encryption and Signature Method fields. The schema file does not have to be attached to the encrypted file; it could be strictly used during development.

<?xml version="1.0"?>

<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema" version="1.0">

<xsd:element name="EncryptedData">

<xsd:complexType>

<xsd:sequence>

<xsd:element name="DataID">

<xsd:simpleType>

<xsd:restriction base="xsd:integer">

<xsd:minInclusive value="1"/>

</xsd:restriction>

</xsd:simpleType>

</xsd:element>

<xsd:element name="EncryptionMethod" type="EncryptionAlgorithm"/>

<xsd:element name="DocumentName" type="xsd:string"/>

<xsd:element name="IterationCount">

<xsd:simpleType>

<xsd:restriction base="xsd:integer">

<xsd:minInclusive value="0"/>

</xsd:restriction>

</xsd:simpleType>

</xsd:element>

<xsd:element name="SaltValue" type="xsd:string"/>

<xsd:element name="CipherData">

<xsd:complexType>

<xsd:sequence>

<xsd:element name="CipherValue" type="xsd:string"/>

</xsd:sequence>

</xsd:complexType>

</xsd:element>

<xsd:element name="Signature">

<xsd:complexType>

<xsd:sequence>