minilock

I'm probably stating the obvious here, but whatever your strategy for decrypting is you still must verify the ciphertext integrity, which unfortunately for you is calculated on the whole ciphertext. You may win some time by not reading the stuff before the block you're interested, but you will have to read the whole stuff anyway if you want to be safe. I'm no expert of course so I don't even know if there's an AEAD that can bring you integrity on parts of the input; at least I know that minilock (https://github.com/kaepora/miniLock/blob/master/README.md#-m...) builds some kind of counter mode where each chunk is properly encrypted and has everything needed to check its integrity.

minilock (https://github.com/kaepora/miniLock/), see the video for a good overview of how easy it is to use. I'm with moxie and Matthew Green (http://blog.cryptographyengineering.com/2014/08/whats-matter...), I think that we should seriously thank PGP for what it's done, understand what to do and what to not do (I believe Web of Trust is part of these) and take advantage of the fact that PGP has relatively few users to create something better.

How about my proposed salting change? This would thwart a one-table attack. https://github.com/kaepora/miniLock/pull/14

Actually, that's exactly what I proposed in my pull request[1], but it got rejected :( [1] - https://github.com/kaepora/miniLock/pull/14

Yes, and it clearly stated in the demo[1]. The key feature that this approach is trying to accomplish is allowing the user to not have to store anything beyond a password. Keeping track of a keyfile is HARD for a lay-user, so miniLock is trying to do the best it can securing files with only a password. [1] - https://github.com/kaepora/miniLock/blob/master/src/index.ht...

Yeah use of zxcvbn is a problem. Minilock's key strength checking goes[0]: key.length > 32 && zxcvbn(key).entropy > 100 Firstly minilock allows the following: zxcvbn(". . . . . . . . . . . . . . . . ").entropy = 161.421 [1] Secondly this only really works for English. While they are used to being forced to use English passwords, we can't expect that speakers of other languages would like English passphrases. It also has heuristics making assumptions of how people choose passwords (e.g. l33tifying) which may be less valid for longer phrases than short passwords. zxcvbn uses all English word lists and keyboard layout and automatically gives you a Unicode bonus[2] if you use unexpected characters. If I write a sentence in Chinese, I have a high entropy. Here minilock actually penalises Chinese by adding the key.length > 32 requirement as

Indeed, Base58 encoding would be preferable. I filed an issue https://github.com/kaepora/miniLock/issues/3