From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from tansi.org (ns.km10532-04.keymachine.de [87.118.102.195]) by mail.saout.de (Postfix) with ESMTP for ; Sat, 24 Apr 2010 18:58:29 +0200 (CEST) Received: from gatewagner.dyndns.org (84-74-164-239.dclient.hispeed.ch [84.74.164.239]) by tansi.org (Postfix) with ESMTPA id 3A2BE212804A for ; Sat, 24 Apr 2010 18:58:29 +0200 (CEST) Date: Sat, 24 Apr 2010 19:01:36 +0200 From: Arno Wagner Message-ID: <20100424170136.GA25497@tansi.org> References: <4BCF8371.60306@redhat.com> <20100422222227.GC15879@linux-m68k.org> <4BD15F13.3040604@redhat.com> <20100423111337.GA26121@linux-m68k.org> <4BD18899.7080700@redhat.com> <20100423200901.GA8023@linux-m68k.org> <4BD206EE.9070606@redhat.com> <20100423225918.GD8023@linux-m68k.org> <20100424155915.GC23598@tansi.org> <20100424164452.GA11910@linux-m68k.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100424164452.GA11910@linux-m68k.org> Subject: Re: [dm-crypt] LUKS - SSD trim List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: dm-crypt@saout.de On Sat, Apr 24, 2010 at 06:44:52PM +0200, Richard Zidlicky wrote: [...] > very offtopic, I would think there is certainly pressure from various > agencies and companies not to erase anything. Given that printers are > programmed to print secret identification patterns on every page there > could be quite a few surprises lurking in copiers. Only for color printers. It serves to identify a printer that was used in couterfiting currency. Storing everything in copiers is infeasible. Thstorage available is just about enough for the largest possible print-job, usually not more than 1000 or so different pages. Given that this limit is routinely exceeded in a day, almost all pages will not be stored. > > That is way you use encryoption on top. However, it is higly unlikely > > current HDDs/SSDs store a lot of information of this type. The storage > > space is just not there. > > most will do clever traffic analysis trying to predict access patterns at > the very least. Most likely not store everything to survive reboots but > there can be exceptions. Sorry, but I openend my SSD. There are just no bits in there for this. My 30GB SSD has 2GB extra storage, most used for spares for broken cells. The rest cannot store a lot. In addition, the SSD does not have a clock that would be essential for adding timestamps to a data access pattern log. Here is a story from my country some years back. The federal prolice wanted to have all emails copied and archived. The ISPs responded with the query where the cubic-meter of DAT tapes per day should go? After this (and after realizing the cost, which the police would have had to pay), the proposal was off the table. -- Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email: arno@wagner.name GnuPG: ID: 1E25338F FP: 0C30 5782 9D93 F785 E79C 0296 797F 6B50 1E25 338F ---- Cuddly UI's are the manifestation of wishful thinking. -- Dylan Evans If it's in the news, don't worry about it. The very definition of "news" is "something that hardly ever happens." -- Bruce Schneier