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.


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.
  • 3
    $\begingroup$ 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. $\endgroup$
    – Reid
    Commented Nov 4, 2013 at 4:43
  • $\begingroup$ @Reid Add some more chunk specs to allow nonce and chain of trust. $\endgroup$ Commented Nov 5, 2013 at 4:19

1 Answer 1


You should encrypt the data using a well-vetted standard, like TLS (for data in motion) or GPG (for data at rest). Designing your own is more likely to lead to sadness. The format of the data that you protect in this way is up to you and can be broken down into structs and chunks and headers etc. to your heart's delight.

  • $\begingroup$ I am looking at a format that can both be sent and stored still. All hardware handling it may not have adequate computing power to do cryptography a lot so this container can be sent and stored across them without the need of decryption. $\endgroup$ Commented Nov 5, 2013 at 4:16
  • $\begingroup$ @MaxthonChan, you can encrypt the data with something like GPG, and that'll handle both data at rest and data in motion (you can send the encrypted data over a network). Make sure to use both confidentiality and integrity/authentication. $\endgroup$
    – D.W.
    Commented Nov 5, 2013 at 6:16
  • $\begingroup$ @D.W. I also have licensing issue if GPG is employed. $\endgroup$ Commented Nov 6, 2013 at 12:25

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.