Is it safe to hide secrets this way?

I have n secrets to hide, my goal is to remember only a seed and derive them from the seed. Is this a safe aproach?

Calculate n keys:

``````k(1) = seed XOR secret(1)
...
k(n) = seed XOR secret(n)
``````

Store these keys in an apllication, asking the user for a seed and compute the secrets using XOR.

The user will get a result even using a wrong seed and he doesn't know if he got the correct secrets.

What are the cons in storing these keys in a place where anyone can possibly look at?

Edit: based on replies and further readings I did something like this:

• Use the seed as a password for a PBKDF2 to generate an AES key and IV
• Write the secrets in JSON format
• Encrypting the JSON text with AES key and IV generated from the seed
• Ciphertext is stored inside the application
• The seed is used as an input to compute the key and IV at runtime

Any other thought would be appreciated

• The problem with asking if something is theoretically secure in an artificial scenario that never happens in real life is that a lot of people only note that it’s “secure” and fail to note the “except in any circumstance you will ever actually encounter” bit. So people will rightly be reluctant to comment on your scenario unless you can make it a real-world scenario. – Mike Scott Jan 11 '18 at 11:40
• With regards to your update the IV needs to be unique on every encryption. Generate it using a secure random number generator and store it with the ciphertext. – Hector Jan 14 '18 at 1:07

This is unlikely to be secure for a number of reasons. Primarily XOR is only secure for a one time pad - you are reusing the key (your "seed" is the key here).

If a party knows any individual secret they can calculate the seed - and hence read all others. I.e. secret([known]) XOR [knownValue] yields seed. This entirely defeats the point of having multiple unique secrets - you could just as well use the seed value everywhere as your secret.

The user will get a result even using a wrong seed and he doesn't know if he got the correct secrets.

Are the plaintext secret values random binary? If not an attacker can just brute force trying seed values then manually reviewing seeds that provide only printable characters for each key. If the secrets are words or phrases this becomes even easier.

Why are you trying to re-invent the wheel? You have basically described an offline password manager with very poor encryption. Why not just use an offline password manager which uses a modern trusted secure encryption scheme?

• Let's assume that if a party knows one of the secrets there is no point to hide the others, i've lost anyways. Yes the secrets are binary values. Main reason for asking was to know if something this simple would work in my scenario. Thanks – sguerrini97 Jan 11 '18 at 10:51
• @sguerrini97 - So why have multiple secrets? Why not just use the seed in a normal password based key derivation algorithm? Surely using an off the shelf library supporting something like PBKDF2 isn't any more work than using XOR? – Hector Jan 11 '18 at 10:52
• @sguerrini97 - and by binary are they entirely randomly generated? If there are any patterns in the data at all then XOR can not be considered secure when the same key is reused. – Hector Jan 11 '18 at 10:55
• Actually I was rethinking about it and my last statement is wrong, it makes sense to hide every secret properly – sguerrini97 Jan 11 '18 at 11:54

It is recommended to go through the logic of the encryption algorithm used. The algorithm won't keep in mind the structure of the file that has to be encrypted.

For example XOR'ing a file that contains:

• 0x00 bytes as padding will convert this part to the key itself .

• the key itself in bytecode will result in 0x00 bytes.

The key is then leaked by comparing the file before and after encryption.

The same thing apply for all the logic functions including:

• NOT
• AND

• OR

• All the permutations of them.

Key leakage can be mitigated by leaving the parts that are part of the key or 0x00 unchanged.