0

I implemented a crypto format (in the form of a MultiCipherOutputStream and a MultiCipherInputStream) that supports nesting multiple cipher streams 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 Syncany, a use-any-storage Dropbox-like file sync tool.

So my questions are:

  • Is the concept of this crypto format cryptographically sound?
  • Are any of my assumptions and design concepts wrong or questionable?
  • Is it implemented correctly?

Here is a description for the format:

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)

General design concepts and assumptions:

  • Assumption: A single password is shared among all users
  • Input parameters: Password string, list of cipher specs (e.g. AES/GCM/NoPadding, 128 bit)
  • The password is used to derive one symmetric key per cipher using PBKDF2 (12 byte salt, 1k rounds)
  • The symmetric key(s) are used to encrypt files; it is reused in max. 100 files (~ 200 MB)
  • 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.)
  • Ciphers are initialized with a random initialization vector (IV), IVs are never re-used
  • Multiple cipher algorithms can be nested/chained (1-n ciphers), e.g. AES-128 and Twofish-256
  • Cipher configurations, IVs and salts are authenticated with an HMAC (SHA256)

Source:

binwiederhier
  • 1,893
  • 1
  • 16
  • 23
  • This comes under the general heading of 'security by obscurity'. The use of a single password among an entire community restricts its usefulness. – user207421 Nov 05 '13 at 22:17
  • Key use case is a single user syncing on one-to-many machines. And connection details (to the storage have to be shared anyhow, e.g. FTP details), so complete trust is a must in a dumb-storage environment. However, point duly noted. A multi user concept is high on the list once the basic version flies ... Doesn't 'security by obscurity' apply more to 'trying to hide the mechanism' rather than to 'have a symmetric password'? – binwiederhier Nov 05 '13 at 22:31
  • 2
    It applies to any technique that relies on the attacker not knowing the *technique,* as opposed to the encryption key. Once the attacker knows the technique, i.e. in this case the cipher sequence, this is no stronger than the key was in the first place. – user207421 Nov 05 '13 at 22:40
  • This explanation would condemn all password-based encryption? Is what you are trying to say that "passwords are evil"? – binwiederhier Nov 05 '13 at 22:43
  • Nonsense. None of that follows from anything I've said here. Don't put words into my mouth. – user207421 Nov 05 '13 at 23:13
  • Let's not get OT, hehe, I really(!) appreciate the input :-) Let's simply assume that PBE is the method of choice. Given that assumption, is the design is secure? – binwiederhier Nov 05 '13 at 23:19
  • I've answered that. The only additional security this offers is security by obscurity. – user207421 Nov 06 '13 at 01:04
  • I think EJP is trying to say that ciphers like AES and Twofish are *unbreakable*. There's no way to break a cipher if the key stays secret. You can't add any more security to that. – ntoskrnl Nov 06 '13 at 15:32
  • This must have been a language issue... I apologize for the confusion. I believe I get it now: What you are saying - @EJP - is that multiple ciphers are not adding any security if the key is guessed correctly (using the first cipher or the HMAC). That is most certainly true! However, doesn't it at least help against cryptanalysis? Assuming that AES has been broken, there is still a Twofish layer, right? – binwiederhier Nov 07 '13 at 18:31
  • This question appears to be off-topic because it is about reviewing a securities design. – Duncan Jones Nov 08 '13 at 14:56

1 Answers1

2

Your scheme is not very safe regarding key management, as EJP has already stipulated. The common way to do this is using asymmetric keys, e.g. the PGP key distribution scheme. Currently only one person has to leak the password to make this scheme insecure, and nobody will know who is the culprit.

Furthermore, the same password is used to derive the keys. Now I presume one of these keys is used to calculate the HMAC over the header. So that means that if a dictionary or brute force attack is feasible on the password, that the result can be checked against the HMAC over the header. Once the password is found, then the rest of the keys can be derived from it.

So although you have muliple layers of encryption, you do not have multiple layers within your key/password management scheme. Attacks will likely only focus on your key management scheme, making your the additional rounds of encryption redundant. You would actually already be a bit more secure to use a PBKDF with larger salt and iteration count initially, and then derive the keys using a KBKDF on the result of the PBKDF. But even that won't hide the issues with key management.

So no, this scheme is not particularly secure.

Maarten Bodewes
  • 90,524
  • 13
  • 150
  • 263
  • I appreciate you taking the time for a detailed answer! I understand now that the scheme's weakness is key management -- especially if (as stated) more users are involved. Assuming that there is only one user, however, or a few 'trusted' users, is the scheme secure if I follow your idea - i.e.: create master key (PBKDF2 w/ 1MM rounds), and derive other keys using HKDF. That would make brute force (even on the HMAC) unfeasible, right? – binwiederhier Nov 07 '13 at 18:37
  • 1
    It would still depend on the security of the password, of course. A bad or commonly known password as only secret input to generate the key will always remain a vulnerability. But if a sole password is the only option you cannot do much better. – Maarten Bodewes Nov 07 '13 at 18:48
  • I know that a single password is not the best way to go, and reading your evaluations, I will definitely look at how to implement an asymmetric scheme (given the rest of the application's architecture). For now, the typical user-convenience-problem forces me into a password-based scheme. To add a bit more security, I am planning strict password restrictions and a check against a rudimentary local wordlist. – binwiederhier Nov 07 '13 at 19:01