Ok, this is the current model I am working from. It is based on the
somewhat inconclusive discussions over the past few days, plus a
couple of my own changes w/r/to the Storables. Nothing is set in stone
yet, but we need to get there soon -- 0.4 isn't far off once we
settle this.
I believe the hashing of Storables has been settled so I won't repeat
it here.
STORABLES: may contain the following fields --
1. Part-size
2. Initial-digest
3. Symmetric-cipher
4. Document-header
5. Public-key
6. Document-name
7. Signature
For CHKs the Storables must contain exactly fields #1-4 only.
For SVK-type keys, fields #1-7 are required, with #6 optional.
The meaning and format of fields #1,3, and 6 are the same as
in 0.3. However, Part-size is now required and must be greater
than zero, and Symmetric-cipher is also required.
The Public-key is a hex-encoded DSA public key as in 0.3, but
the DSA group is now appended after a comma, always, so you
get Public-key=y,p,q,g. If that's a problem I
can go back to using the optional Group field.
Fields #2,4,7 are explained below.
KEY VERIFICATION:
All keys are progressive-hashed as CHKs are in 0.3. The
Initial-digest field in the Storables contains the hash of
the first part. Hence once the key is verified with respect
to the Storables, the rest of the stream is verified the
exact same way regardless of the keytype.
CHKs: The routing key must be the hash of the Storables.
SVKs: The routing key must be the fingerprint of the Public-key
field in the Storables. The Signature field must be a valid
signature of the hash of the Storables w/r/to the Public-key.
KSKs: Same as SVKs.
SSKs: Same as SVKs except the routing key must be
hash(SVK-routing-key + Document-name), as in 0.3
The byte structure of a key is:
<20 bytes: routing key>
<1 byte: key-size>
<2 bytes: key type>
So instead of using the 21st byte to doublecheck the partsize, instead it
is set equal to log2 of the length of the trailing field MINUS ALL CONTROL
BYTES (i.e., the total file length as perceived by the user, metadata + data).
The key will fail to verify unless this holds.
DOCUMENT STRUCTURE:
The document is encrypted and interleaved with the progressive hash
control bytes. Its length must be a power of 2 _prior_ to the addition
of the control bytes.
The Document-header Storable is a hex-encoding of an encrypted byte
array, ZERO padded to power of 2 length, composed of:
<2 bytes: crypto key length>
<crypto key>
<2 bytes: length of metadata-length field>
<metadata-length>
The idea is that in the future we can add additional fields with a
2-byte length marker for each.
When encryption or decryption of the document is performed, it is
done AS IF the Document-header were at the beginning of the trailing
field stream. The implementor may literally append the two together
before performing the operation. In the case of our Java code, what
I am doing is retaining the same PCFBMode object and using it to
first en/decrypt the Document-header, then the rest.
At the moment I'm using an IV initialized to all-zeroes, as it was
done in 0.3. We probably want to define a way to initialize the IV
-- ??
Clients should check that the crypto key read from Document-header
matches the one they are using, and fail with a notification that
the user does not possess the correct key otherwise.
--
# tavin cole
#
# "The process of scientific discovery is, in effect,
# a continual flight from wonder."
# - Albert Einstein
_______________________________________________
Devl mailing list
Devl at freenetproject.org
http://lists.freenetproject.org/mailman/listinfo/devl
