-1

The answers to my previous question (How safe is XOR with multiple independent but non random keys?) revealed quite a few problems, to a degree that a new approach had to be developed.

I took the recommendations of @Daffy and put together a MessageSafe product, which I need your comments about the degree of its security. Sorry, I understand this is more security than cryptography issue. Please, let me know if there is better place for the question.

Like before, I have a practical example with fake data. I have a highly valuable message, which is a private Bitcoin key written on paper.

MESSAGE = KwjwmREseNZmZ8yeNKrurN6qPuh9FhrLAefYa2nTLafLkGmWW9ta

So I go through the following security protocol:

  • I take my kids' old iPod 4, and open the above HTML page in Safari browser.
  • I disconnect Wi-Fi, Bluetooth, and put the iPod into Airplane Mode.
  • I type the message and password into corresponding fields.

  • I press Encrypt and following happens:

    • The password gets hashed by bcrypt
    • Password = Horses will fly by 2050
    • Salt (Hard-coded value) = S\$2a\$12\$PVD.XSaA.GyzVZgknaw.jO
    • KeyHash = \$2a\$12\$PVD.XSaA.GyzVZgknaw.jOmMXANF67Cetb9jNkreUX54cdVwiMnp6
    • Last 32 characters of KeyHash are the Key = mMXANF67Cetb9jNkreUX54cdVwiMnp6
    • The message is then encrypted by AES in CTR mode with the Key.
    • The encrypted message is converted into Base58 alphabet, spaced every 4 positions, and the secure code is below:
    • Code = asKP-1JKq-2YbJ-qwT2-5h5d-fSSG-J5f4-rE6b-qDx5-jUx9-gXqg-zKWD-Q4Ga-ks73-XAnP-mxau-SzkN-b7UA-vN1x-zRbH-bdGo-w5t6-fzmb-PA1e-F

  • I magnify this code on the small iPod screen, so no other fields are visible, and make a picture of it with my phone.

  • I clear all the fields in the HTML form, and go the opposite direction, typing in the pictured code and the password and then press Decrypt.

  • If the message is successfully decrypted, the iPod has to be destroyed (preferably in fire)

  • The resulting secure code picture can be stored in mail, on drives, etc.

Suppose for now the authenticity of the program opened on iPod is not in question, there might be a special signature checking procedure to discuss later.

The question is: What am I missing? Is the security on par with the best practices? Can it or should it be improved?

I am interested in public review, because I will use the program myself and need to be sure.

Evgeny
  • 67
  • 6
  • If your message is truly valuable and might attract "professionals" trying to recover your secrets, I would suggest not drawing attention to (1) the fact that you have a valuable message at all, and (2) the method you are using to store/encrypt this message. You can achieve a lot of "practical security" just using common sense. – TMM Jun 27 '17 at 19:01
  • Agreed, I do not even have a Bitcoin secret key, the nature of actual messages I would not discuss. I was using the common sense with success for a long time, but schemes are getting overly complex and the probability of screwing up myself getting high. I need a clean solution. – Evgeny Jun 27 '17 at 19:12
  • What if your software has a bug? What if the iPod has a bug? What if the web browser has a bug? And don't you think that destroying the device is a little expensive if you want to encrypt more than one message (with different salts / IVs!) – SEJPM Jun 27 '17 at 19:31
  • Good concerns. To alleviate some of them open the software in two browsers: Chrome and Safary. Do all the steps in both. If the results match, for your particular message, chances are greatly improved you will recover it later. As for the device, I have few obsolete phones nobody in the family wants. For great many security setups, factory-resetting the device can be sufficient – Evgeny Jun 27 '17 at 20:00
  • My answer to your last question did not contain enough information to securely encrypt anything. You, as the end user looking for security, should be using a pre-made file encryption tool instead of building your own. For instance, 7-zip's archive encryption tool. – Daffy Jun 27 '17 at 21:07
  • I will be happy to use a pre-made solution, if it satisfies my requirements. Suppose I have a string of characters on paper and is uneasy even to make a photocopy of it, because there might be some image caching in the machine. There is no way I am ready to commit it to a computer. The phones which saw the password must be destroyed. Is there a good market solution which runs on lowest denominator phone? – Evgeny Jun 27 '17 at 23:58
  • 1
    @Evgeny You have to balance security and usability. What's your threat? Are you being spied on by government agents? Is your house filled with cameras? I sincerely doubt that a phone seeing your password is any more dangerous than your bitcoin wallet.dat file existing on your computer. – Daffy Jun 28 '17 at 04:32
  • @Daffy Thanks. I feel that I probably found the right balance with this solution. It is not perfect, but thanks to your input, it is a great improvement over prior setup in both: security and usability. For private use it should be sufficient. Thanks again. PS. It was not about Bitcoin, I do not own enough to worry about it – Evgeny Jun 28 '17 at 16:49

1 Answers1

1

First and foremost, if you had a hand in building it, consider it completely vulnerable. This is otherwise said as don't write your own crypto. The reason for this will become apparent later.

Practical answer

You should be using something already known and tested for storing sensitive information. Such as 7-Zip's archive encryption, or TrueCrypt drive encryption.

To put it in the words of Moserware, Sign this agreement before reading on:

I __[Your name]__ promise that when I know how to use crypto, I will not implement it in production code, even though it would be really fun.

This agreement shall be in effect until the undersigned creates a meaningful interpretive dance that compares and contrasts RNG bias attacks, attacks based on misuse of salts and IVs, and their countermeasures.

X__________ <- sign here

So with that out of the way.

Theoretical answer (for education only)

The first issue I see here is that you're using a fixed salt. Salts are supposed to be random for each password. They can be stored alongside your ciphertext. The purpose of a salt is to take the same password and give different outputs. This is so you can't correlate accounts with the same password if a password database is leaked. Bcrypt also happens to be good for turning passwords into usable encryption keys, which is why I suggested it for this purpose. In order to accomplish this, however, the salt must be completely random each time.

The second issue is that I don't see you using a nonce/IV in your encryption. This also needs to be completely random (especially for CTR mode). This prevents the same plaintext from encrypting to the same ciphertext. Additionally, for CTR mode (and other modes) it prevents attacks based using the same key twice.

The third issue is that the password doesn't allow for whitespace characters. This might sound like nothing, but really this tells me you're not handling passwords right. Your system shouldn't care what I type into the password field, at all. Yes, all those places that say your password needs to be 8-16 characters with a capital letter, lower case letter, number, symbol, etc, those are all just to encourage you to pick a good password (a fruitless effort if you ask me). You seem to be throwing out information for no good reason. You should feed the password directly into bcrypt without looking at it, other than maybe checking it isn't ridiculous like 4000 characters long.

Also keep in mind Javascript's Math.random() is not good for cryptographic uses. You have to use crypto.getRandomValues() instead.

Daffy
  • 2,389
  • 17
  • 29
  • Practical answer: The page I put together is just an interface to two encryption programs available on the market. I did not read the specs, and at this point do not know how the encryption is done, I know what it does. So, I do not write my own crypto. If experts (like yourself) will seem to be comfortable with the idea, I can come out with the ways to cross test the program with other implementations of the algos, and make sure they are solid. But I will not be in business to understand math. So, this is definitely not my crypto, I just want to put together a usable solution. – Evgeny Jun 27 '17 at 23:44
  • To reply to Theoretical answer will take me day, I am not a quick thinker – Evgeny Jun 27 '17 at 23:46
  • 1
    @Evgeny You did write your own crypto, in the fact that you're putting together the pieces. You're not putting together an interface for an already existing protocol, you're writing your own protocol using existing pieces. This is why I chose my words very carefully when I said if you had a hand in building it, consider it completely vulnerable. You had a hand in writing that page, therefore it should be considered vulnerable. – Daffy Jun 27 '17 at 23:48
  • @Evgeny Also I'm not an expert. I study cryptography as a hobby. I have no certification and no professional training. Keep that in mind when you're using my advice to secure your bank account. – Daffy Jun 27 '17 at 23:51
  • You are probably right. Thanks for pointing this out. I will consider authorship vulnerability once I have the whole picture. – Evgeny Jun 28 '17 at 12:17
  • "The purpose of a salt is to take the same password and give different outputs." You are right, and it is used in systems where great number of passwords is involved. For my purpose I use BCrypt as a strong one way hashing function with non biased distribution, not to differentiate passwords. The salt is public, one should not rely on the secrecy of the method for security. If I allow generated salt, it will become a second password. My advice would be, rather improve the first password instead. – Evgeny Jun 28 '17 at 12:19
  • "The second issue is that I don't see you using a nonce/IV in your encryption". For this particular usage, there is no need for salt. There is only one message (or very few) with its personal, never-used-any-where-else password. – Evgeny Jun 28 '17 at 12:20
  • "The third issue is that the password doesn't allow for whitespace characters". For every day passwords you are right. But this might not be a good idea for rarely used passwords. Imagine, if I decide that my password is a certain piece of message in my mail box. I type it in as I see it, but when time comes to decrypt, I cut and paste. If there is a TAB character instead of SPACE, and 10 years passed, there might be a lot of confusion. – Evgeny Jun 28 '17 at 12:20
  • "Also keep in mind Javascript's Math.random() is not good for cryptographic uses." As we do not use Nonce and Salt is not generated, the process is completely deterministic and Javascript's Math.random() should not be employed anywhere. – Evgeny Jun 28 '17 at 12:22