57183Re: patch for encryption, strengthened key with salt.
- Jun 1, 2010On Mon, May 31, 2010 at 12:17 PM, Bram Moolenaar <Bram@...> wrote:
>Yes. key_strengthening is not really important.
> Mohsin wrote:
>> >> Attaching patch7.zip encryption Key_strengthening
>> >> Changes:
>> >> 1 added 8 bytes salt to file header,
>> >> 2. sha256_key takes password, salt, salt_len (salt is binary, not
>> >> null terminated)
>> >> 3. sha256_seed also generates salt along with iv.
>> >> 4. bf_key_init takes password and salt.
>> >> 5. bf_key_init converts ascii hex key to binary key (this
>> >> change is independent of the 1..4 above)
> Can we avoid the intermediate step with ascii hex?
>> >> Also attached is vc-proj.zip (contains dsp and dsw project files).
>> >> The HG repository didn't have these files, so I copied them from older
>> >> older source tree.
>> >> Might be useful to others on this list using vc++ on windows to debug.
>> > Can you explain what this does, how it makes the encryption stronger,
>> > and if there is any impact on performance? A link to a page that
>> > explains it would be helpful.
>> Here is the doc for salting, this can be added to the code:
>> Its summary is:
>> The salt is a random number concatenated to the password to create a
>> one time key.
>> This prevents someone from precomputing keys (dictionary),
>> because the salt is a different in each file.
> We already had the seed for this. The wiki page actually describes a
> method to feed the password through an algorithm that costs time, to
> increase the time needed for a brute force attack.
> Instead of using both a seed and a salt, can we use one? Hmm, I suppose
> using two different strings adds to the strength.
>> The key computation is slowed down for offline attack;
>> this prevents someone with the file+salt but not the password,
>> from using brute force -
>> That is they feed all passwords 'a', 'aa', ... but they should NOT
>> have enough time to to try all 8 char passwords.
>> Other docs that relate to this code:
> OK. I'm not sure if we really need this for Vim, or perhaps in limited
> form. I would like this to work well on slow machines. One important
> difference from many other applications of cyphers is that Vim has no
> check if the correct key is used. The attacker has to know something
> that must exist in the file, literally. That also makes attacks a lot
I was just going by the standard literature.
>Any value of similar magnitude would do; the wiki suggests 65000;
> You use a strengthen_key value of 1000. Why not 100 or 10000?
> Perhaps we should put this value in the header as well, so that we can
> change it over time?
Reason: Time to compute one key is feasible for a user, but
time to compute for whole dictionary + salt is infeasible.
>I thought I did that, except that I used spaces instead of tabs.
> About the code: Please, please use the Vim formatting style.
> Another question: I would like to also encrypt the swapfile. TheThis can be done:
> problem is that this is written and read in blocks of 4Kbyte or more.
> There is no predefined order in which to perform the I/O, thus each
> block must be crypted and decrypted by itself.
a Use any key (password with/without salt) to init blowfish;
and then call the blowfish to encrypt/decrypt blocks
of 8 bytes of swap file.
for i = 0 ; i < 4k/8 ; i+=8
block[i*8..i*8+8] ^= bf_encrypt(integer i); // blowfish in CTR mode.
CTR diagram is in here
>If you keep a constant salt + password, you get a session key,
> What we could do is generate a seed or salt for each block, and store
> that in the pointer block that refers to the data block. We can
> generate a new seed each time a block is written. The pointer block
> must then also be written later. We do need to restart the encryption
> for each block though. I suppose there is no safe way to store the
> state of the crypter in the file so that we can continue from there.
use that in bf_init, then you can just use the file offset:
block[i] ^= bf_encrypt(offset)
So any 8byte block can be encrypted/decrypted independently.
>Yes. Or keep a separate session key in memory for swap files.
> Another problem is when changing the key: we would need to read back all
> blocks with the old key and crypt them with the new key.
This would make it impossible to recover swap files in case of crash.
Or keep the hashmap: swap -> key, and switch tp new
keys lazily - during write.
About random number usage:
The random number for IV is generated using sha(loop time),
this is good enough in practice. For better randomness,
vim could measure the time deltas between user keystrokes (like pgp).
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
- << Previous post in topic Next post in topic >>