From mboxrd@z Thu Jan 1 00:00:00 1970 From: Edward Shushkin Subject: Re: Proposal for keying encrypted filesystem Date: Mon, 31 Mar 2003 16:09:48 +0400 Sender: edward Message-ID: <3E88300C.22B54FD7@namesys.com> References: <200303282026.23543.phma@webjockey.net> <200303291155.40419.phma@webjockey.net> <3E85E338.CEAA7DC7@namesys.com> <200303301130.24136.phma@webjockey.net> <3E8824B4.55C63A55@namesys.com> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Return-path: list-help: list-unsubscribe: list-post: Errors-To: flx@namesys.com List-Id: Content-Type: text/plain; charset="us-ascii" To: reiserfs-list@namesys.com Edward Shushkin wrote: > > Pierre Abbat wrote: > > > > On Saturday 29 March 2003 13:17, Edward Shushkin wrote: > > > Any collision can be used by attacker for access to remained decrypted data > > > in memory, so you should assign the *whole* output of any crypto-stable > > > hash function (20 bytes for SHA1). If you use 19 bytes for ID, there is no > > > any guarantee that someone can not find a collision easy. > > > Edward. > > > > There isn't any guarantee with all 20 either, > > Yes of course, but with all the 20 bytes I have a guarantee of SHA1 stability > announced in appropriate papers, and I do have nothing for 19 bytes.. So from this standpoint I would rather prefer 16-byte ID created by full-grade md5, then 19-byte ID created by restricted SHA1. Maybe this standpoint is too conservative, but this is right.. > > it's just 256 times as hard to > > find one and practically impossible. What about using the MD5 of the > > passphrase for the key ID, and the SHA1 of the passphrase for the key? > > Each secret key must be generated by special method which is specific for > the used crypto algorithm, I think such methods are already exists, so we > don't need to invent something new.. > > Edward. > > > > > phma > > -- > > .i toljundi do .ibabo mi'afra tu'a do > > .ibabo damba do .ibabo do jinga > > .icu'u la ma'atman.