Revision | Comments |
---|---|
1.1 | Author(s): Roger McFarlane (roger@zks.net),
Philippe Boucher (philippe@zks.net);
Initial draft. |
1.2 | Incorporated suggestions based on feedback from Adam Shostack (adam@zks.net). |
See Also:
Your feedback is welcome. Please direct your comments, criticism, and suggestions to the author of this document and/or the Core Development Team (core-team@zks.net").The application which initially motivated the development of ZKCP was the Zero-Knowledge Database Server. The verbosity and overhead associated with ZKIP was perceived to be detrimental to the performance of the server, which is a perfomance critical component. At the same time, schedule and legacy constraints prevented the logical progression to SQL. Rather than inventing a context specific interim (read throw-away) solution, the Core Development Team elected to create a successor to ZKIP for use with the database server.
ZKCP is an attempt to fix many of the problems inherent in ZKIP. Its first application will be that of the database server; however, it is intended to phase out ZKIP as the Freedom software matures. ZKCP is suitable for server-to-server communication, client-server communication, client-to-client communications, and for serialization to persistant storage.
Further to this, some 'transactions' (not in the database sense) span multiple commands. For instance sending a piece of mail using AMTP involves sending a header command, then a message command (to send the body), and then a target command (to send the recipients).
Datatype | Format | Description |
---|---|---|
uint32 | 4 bytes in NBO | Unsigned 32 bit value |
uint16 | 2 bytes in NBO | Unsigned 16 bit value |
uint8 | 1 byte | Unsigned 8 bit value |
TimeStamp | 8 bytes in NBO | An unsigned 64 bit integral value which counts the number of seconds since 1 January 1970 00:00:00 (in UTC) |
+----------+--------------+--------------+-------+--------------+---------+ | Header | Parameter1 | Parameter2 | ... | ParameterN | MAC | +----------+--------------+--------------+-------+--------------+---------+ | | +--------> Optional Params <--------+
+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+ | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | +-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+ | | | | | | | | | | +--+--+ | | +--------+--------+ +--------------------+------------------- + | | | | | | | | | | | | | | | +--> Reserved | | | | | | | | | | | +--> Command ID | | | | | | | | | +--> Time Stamp | | | | | | | +--> Sequence Number | | | | | +--> Flags | | | +--> Version | +--> Prefix
Bytes | Field | Datatype | Description |
---|---|---|---|
0 - 1 | Buffer Prefix | uint16 | A constant value (i.e., magic number) which identifies the data buffer as being a command protocol packet. |
2 | Version | uint8 | Packet version (current value is 1) |
3 | Flags | uint8 | Bit field.
|
4 - 7 | Sequence | uint32 | Sequence number |
8 - 15 | Time | TimeStamp | Time at which the packet was generated |
16 | Command ID | uint8 | The numeric identifier of the command which this packet represents |
17 | reserved | uint8 | Reserved. Must be zero (0). |
+-----+-----+-----+-----+-----+-----+-----+-----+-----+------- | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | ... +-----+-----+-----+-----+-----+-----+-----+-----+-----+------- | | | | | | | +--------+--------+ +--------+------ ... | | | | | | | +--> Value Data | | | | | +--> Size | | | +--> Type ID | +--> Param ID
Bytes | Field | Datatype | Description |
---|---|---|---|
0 | Param ID | uint8 | Identification code for the parameter. The Param ID zero (0) is reserved for as the MAC identifier (see MAC Format) |
1 | Type ID | uint8 | Identifies the type of the parameter's value. This would denote, for instance, that a parameter was a binary blob or an integer. The Type ID zero (0) is reserved for as the MAC type identifier (see MAC Format). |
2 - 5 | Size | uint32 | Size of the value data (in octets).
{ In most cases, a 16-bit field would suffice; however, there are applications in which a 16-bit field would be insufficient (e-mail, for instance). - roger } |
6 - ? | Data | raw bytes | Format depends on the particular data type (i.e., the Type ID value). Usually an NBO integer like format or a byte array. |
+-----+-----+-----+-----+-----+-----+-----+-----+-----+----------------+ | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 ... 20 | +-----+-----+-----+-----+-----+-----+-----+-----+-----+----------------+ | | | | | | | | +--------+--------+ +--------+----------- ... ---+ | | | | | | | +--> MAC Data | | | | | +--> Size = 14 | | | +--> Type ID = 0 | +--> Param ID = 0
Bytes | Field | Datatype | Description |
---|---|---|---|
0 | Param ID | uint8 | Reserved Parameter ID for MAC. This is always zero (0). |
1 | Type ID | uint8 | Reserved Type ID for MAC. This is always zero (0). |
2 - 5 | Size | uint32 | Size of MAC buffer. This must be 14 (semi-arbitrary) |
6 - 20 | MAC | Message Authentication Code.
To authenticate we will use the lower 14 bytes of an HMAC as defined in [RFC 2104] with the SHA-1 cryptographic hash function described in [SHA]. |
[RFC2104] | HMAC: Keyed-Hashihg for Message Authentication
H. Krawczyk, M. Bellare, and R. Canetti February 1997 |
[SHA] | NIST, FIPS PUB 180-1: Secure Hash Standard, April 1995. |
Copyright © 2000 Zero-Knowledge Systems Inc.
All rights reserved.