# How to design a secure data container?

I want to design a secure data container that can be used to transfer encrypted data over a public network that can defeat common attacks. Data is already encrypted before entering this container so that is out of scope. The container need to store some detail about the cipher used so that it can be properly decrypted when arrived at the other end.

My basic idea is to use chunks of data, with headers seperated from actual data, containing:

• CHNK chunk: chunk list chunk, always the first chunk.
• DATA chunk: encrypted data, as is or optionally compressed (after encryption).
• SIGN chunk: Signature of the data chunk, either a digital signature or a MAC.
• INIT chunk: (Optional) IV of the cipher used, optionally encrypted with the asymmetric algorithm used.
• ISGN chunk: (Optional) Signature of (possibly encrypted) IV.
• SKEY chunk: (Optional) Encrypted session key, if the main algorithm is asymmetrical.
• KSGN chunk: (Optional) Signature of encrypted session key.
• INFO chunk: (Optional) Comments that is not encrypted or verified.

File structure: (Using C structure notation, all multi-byte numbers is stored in network byte order)

struct chunk_s
{
uint8_t  magic[4]; // Chunk FourCC header.
uint32_t flags;    // Chunk flags, including information of the algorithm.
uint64_t offset;   // Offset of the chunk from head of file.
uint64_t size;     // Size of the chunk.
}


EDIT:

To resolve some issues raised in comments, I will say again that the signature chunks can be either a signature or a MAC, also you can apply both a signature and a MAC by using two (or more, if different algorithms are used) SIGN, KSGN, ISGN,HSGNorSSGN chunks carrying different flags. Algorithm is identified by the flags field.

• HSGN chunk: signature of header/chunk list.
• RSGN chunk: "signature of randomness", essentially a chunk of nonce that is counted when calculating SSGN chunk
• SSGN` chunk: signature of all other types of signature chunks concatenated together in the exact order as found in the chunk list. Usually the last chunk.
-
Having per-chunk MACs/signatures might make some attacks possible (depending on your reqs). Ideally you'd also have a MAC/signature across all chunks to preserve a bunch of things like chunk types, chunk order, and which chunks are present/absent (also, duplicate chunks!). If you had just one had MAC/signature for everything, you'd be obsoleting the SIGN, ISGN, and KSGN chunks. Also, you should be careful of replay attacks by using timestamps and/or sequence numbers, etc. –  Reid Nov 4 '13 at 4:43
@Reid Add some more chunk specs to allow nonce and chain of trust. –  Maxthon Chan Nov 5 '13 at 4:19