From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from v6.tansi.org (ns.km31936-01.keymachine.de [87.118.116.4]) by mail.server123.net (Postfix) with ESMTP for ; Wed, 3 Dec 2014 00:22:28 +0100 (CET) Received: from gatewagner.dyndns.org (77-57-49-177.dclient.hispeed.ch [77.57.49.177]) by v6.tansi.org (Postfix) with ESMTPA id 97FE720DC210 for ; Wed, 3 Dec 2014 00:22:28 +0100 (CET) Date: Wed, 3 Dec 2014 00:22:27 +0100 From: Arno Wagner Message-ID: <20141202232227.GA17650@tansi.org> References: <5e1359f05d092cc49d6b80ba5941fca5@unseen.is> <20141201163919.GA1737@tansi.org> <258c1129921e267d5ea7024d0caffb46@unseen.is> <20141201222552.GA7055@tansi.org> <4ff5f3299a34890282ae5a0cbf8e71f3@unseen.is> <20141202210246.GA15782@tansi.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Subject: Re: [dm-crypt] Pass+keyfile List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: dm-crypt@saout.de On Tue, Dec 02, 2014 at 23:48:51 CET, 0x14@unseen.is wrote: > >I beg to differ: Good quality paper has a life-expectancy > >of several hundred years, and so has good quality ink. > >Make it waterproof with a zip-lock bag. Make it non-obvious by > >folding it. > > > >Even an industial SD card only has 10 years data life expectancy, > >your ordinary commercial "quality" one can become shaky after as > >little as a year and a "no name" one even sooner. > > Hm, I think you compare some spaceship technology paper and ink with > noname sd car manufacturer. No. Ordinary, acid-free white copy paper has a life-expectancy of several hundred years. Ordinary, non-acidic pigmented ink does too. And as to digital flash storage media, have a look at data-sheets. > I have no idea where I can get that > eternal paper and ink that never wares while active use, but I have > 3 n-year old 1 gb sd and microsd cards that I can still use without > problem. I have even older working 256-mb flash drive... You have been lucky. > I still don`t get why I shouldn`t use encrypted keyfile for the > purpose of destroying information. You tell me that there is an > alternative. That`s good! But what`s wrong with my way? I have given a few things. Feel free to ignore my advice. > >>it is not resistant to > >>water, it could be easily copied by attacker and not by you (if you > >>don`t trust electronics)... > > > >Huh? And the SD card cannot be copied? > > SD could be copied of course, but not as easy as to make a foto of > piece of paper. > > >And why shoudl the attacker > >have any advantage here? > > Because then I cannot destroy encrypted container with destroying my > copy of keyfile. But why should the attackr have any advantage for the case of paper over the case of flash storage? > >>and I don`t mention convenience like > >>ability to carry as many keyfiles as I want without being looking > >>strange, etc. > >> > >>Also, for example, 1024 or 16k letters is far more better for > >>security than 50+what_you_can_remember letters for passphrase...from > >>"cryptographical perspective", please excuse my ignorance :) > > > >They get hashed to 160 bits by the passphrase input. From > >about 30 characters onwards, you do not get a better hash. > > That is another thing I wanted to talk about later, but you mention > it here. Quentin Lefebvre wrote before: "it's worth remembering hash > algorithms are ignored with key files in plain mode, so that the > --hash=sha512 is not effective and actually equivalent to > --hash=plain in this case". That is not the hash for the password hashing. That is the hash used in the passphrase iteration and the AF-splitter. Initial passphrase hashing is done with ripmed160 (as far as I remember) and non-configurable. > I have three questions: > > 1. Are you saying passphrases longer than "about 30 characters" are > useless with plain mode? > > 2. So it is more secure to remove --key-file=- and pass unencrypted > keyfile as passphrase but make sure I have no new lines there? Then > I could use --hash=sha512 and it would be effective? > > 3. When I try to replace "--hash=sha512" with "--hash=plain", I > cannot mount mapped device, so it is not the same. Em? > > I may write very stupid things here, so I apologise in advance for > that :) > > > >It really depends on the details of the scenario. > > Ok, let`s stay in IT security. It could be some sort of timer, and I > must remotely do something before data get destroyed (phone special > number, go to website and type password, send email, pay bills, > etc), then timer resets. Forget it. This "remotely doing something" is far too open to attack and observation. > >>>>3. Attacker can attach a hidden camera behind me while I typing > >>>>password (or do similar approach) and then get a copy of encrypted > >>>>data (it is far easier than get full root access) > >>> > >>>Oh? Just have the attacker look with the camera while you type > >>>in your root password... > >> > >>Root password != full access right away. Also, they could "catch" > >>one password and not other. > > > >Sorry, but irrelevant. If you do not notice, they have all the time > >they want. If you notice, then even "right away" is not fast enough. > > > >There may be small residual benefit from scenarios where you notice, > >but only a short time later. > > I could be in video-controlled area for a short period of time, and > they can get video and data copy far later, when it is obvious it is > needed. But I agree, this is not very practical case. In other hand, > not impossible :) IDK If you want security, then you need to do risk management, not wishful thinking. Risk management takes the real world into account. Sure, what you propose _could_ be secure, but then nobody _could_ be attacking you anyways and not even encrypting could be secure. Arno -- Arno Wagner, Dr. sc. techn., Dipl. Inform., Email: arno@wagner.name GnuPG: ID: CB5D9718 FP: 12D6 C03B 1B30 33BB 13CF B774 E35C 5FA1 CB5D 9718 ---- A good decision is based on knowledge and not on numbers. -- Plato If it's in the news, don't worry about it. The very definition of "news" is "something that hardly ever happens." -- Bruce Schneier