-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

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,429
  • 20
  • 29