Note that there are some explanatory texts on larger screens.

plurals
  1. POIs this Java-based multi-cipher crypto format implementation secure?
    text
    copied!<p>I implemented a crypto format (in the form of a <a href="https://github.com/binwiederhier/syncany/blob/c391dbcf9b4c838d0233ed285cf8884c1f7b2060/src/org/syncany/crypto/MultiCipherOutputStream.java" rel="nofollow">MultiCipherOutputStream</a> and a <a href="https://github.com/binwiederhier/syncany/blob/c391dbcf9b4c838d0233ed285cf8884c1f7b2060/src/org/syncany/crypto/MultiCipherInputStream.java" rel="nofollow">MultiCipherInputStream</a>) that supports <strong>nesting multiple cipher streams</strong> into one another. The goal was to produce a flexible crypto file format that will satisfy even the most paranoid users. While I believe I have gathered quite a bit of knowledge about how to implement something like this, I am not an in-depth crypto expert. Background: The crypto format is for <a href="http://www.syncany.org" rel="nofollow">Syncany</a>, a use-any-storage Dropbox-like file sync tool. </p> <p><strong>So my questions are:</strong> </p> <ul> <li>Is the concept of this crypto format cryptographically sound?</li> <li>Are any of my assumptions and design concepts wrong or questionable?</li> <li>Is it implemented correctly? </li> </ul> <p>Here is a description for the format:</p> <pre><code>Length HMAC'd Description ---------------------------------------------- 04 no "Sy" 0x02 0x05 (magic bytes, 4 bytes) 01 no Version (1 byte) 12 no Header HMAC salt 01 yes (in header) Cipher count (=n, 1 byte) repeat n times: 01 yes (in header) Cipher spec ID (1 byte) 12 yes (in header) Salt for cipher i (12 bytes) (dyn.) yes (in header) IV for cipher i (cipher specific length, 0..x) 32 no Header HMAC (32 bytes, for "HmacSHA256") (dyn.) yes (in mode) Ciphertext (HMAC'd by mode, e.g. GCM) </code></pre> <p>General design concepts and assumptions:</p> <ul> <li>Assumption: A single password is shared among all users</li> <li>Input parameters: Password string, list of cipher specs (e.g. AES/GCM/NoPadding, 128 bit)</li> <li>The password is used to derive one symmetric key per cipher using PBKDF2 (12 byte salt, 1k rounds)</li> <li>The symmetric key(s) are used to encrypt files; it is reused in max. 100 files (~ 200 MB)</li> <li>Cipher algorithms are configurable, but not every cipher is allowed: only AES and Twofish (128/256 bit), only authenticated modes (as of now only GCM; no ECB, CBC, etc.)</li> <li>Ciphers are initialized with a random initialization vector (IV), IVs are never re-used</li> <li>Multiple cipher algorithms can be nested/chained (1-n ciphers), e.g. AES-128 and Twofish-256</li> <li>Cipher configurations, IVs and salts are authenticated with an HMAC (SHA256)</li> </ul> <p>Source:</p> <ul> <li><a href="https://github.com/binwiederhier/syncany/tree/c391dbcf9b4c838d0233ed285cf8884c1f7b2060/src/org/syncany/crypto" rel="nofollow">Full crypto package on Github</a></li> <li><a href="https://github.com/binwiederhier/syncany/tree/c391dbcf9b4c838d0233ed285cf8884c1f7b2060/tests/org/syncany/crypto/MultiCipherStreamsTest.java" rel="nofollow">Tests for the package on Github</a></li> </ul>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload