From owner-freebsd-questions@freebsd.org Mon Feb 24 15:38:48 2020 Return-Path: Delivered-To: freebsd-questions@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id D6E922382BB for ; Mon, 24 Feb 2020 15:38:48 +0000 (UTC) (envelope-from galtsev@kicp.uchicago.edu) Received: from kicp.uchicago.edu (kicp.uchicago.edu [128.135.20.70]) by mx1.freebsd.org (Postfix) with ESMTP id 48R5ng3MdRz4LvP for ; Mon, 24 Feb 2020 15:38:47 +0000 (UTC) (envelope-from galtsev@kicp.uchicago.edu) Received: from point.uchicago.edu (point.uchicago.edu [128.135.52.6]) (Authenticated sender: galtsev) by kicp.uchicago.edu (Postfix) with ESMTPSA id 776494E6A1 for ; Mon, 24 Feb 2020 09:38:46 -0600 (CST) Subject: Re: rm | Cleaning up recycle bin To: freebsd-questions@freebsd.org References: <20200223184908.b35d656a.freebsd@edvax.de> <20200224145317.GA9130@neutralgood.org> <20200224151337.30d8d819e7cf74bde984b77a@sohara.org> From: Valeri Galtsev Message-ID: Date: Mon, 24 Feb 2020 09:38:46 -0600 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 MIME-Version: 1.0 In-Reply-To: <20200224151337.30d8d819e7cf74bde984b77a@sohara.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 48R5ng3MdRz4LvP X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=fail reason="No valid SPF, No valid DKIM" header.from=uchicago.edu (policy=none); spf=none (mx1.freebsd.org: domain of galtsev@kicp.uchicago.edu has no SPF policy when checking 128.135.20.70) smtp.mailfrom=galtsev@kicp.uchicago.edu X-Spamd-Result: default: False [-1.60 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; DMARC_POLICY_SOFTFAIL(0.10)[uchicago.edu : No valid SPF, No valid DKIM,none]; NEURAL_HAM_MEDIUM(-0.82)[-0.821,0]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-0.999,0]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-questions@freebsd.org]; TO_DN_NONE(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; IP_SCORE(0.12)[ip: (0.33), ipnet: 128.135.0.0/16(0.16), asn: 160(0.13), country: US(-0.05)]; RCVD_IN_DNSWL_NONE(0.00)[70.20.135.128.list.dnswl.org : 127.0.10.0]; R_SPF_NA(0.00)[]; RCVD_NO_TLS_LAST(0.10)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:160, ipnet:128.135.0.0/16, country:US]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Feb 2020 15:38:48 -0000 On 2020-02-24 09:13, Steve O'Hara-Smith wrote: > On Mon, 24 Feb 2020 09:53:17 -0500 > "Kevin P. Neal" wrote: > >> The thing about security is that often all you can do is raise the cost >> of an attack. If the cost is high enough then you can often make an >> attacker find a better use of their time. > > If data security is the goal then encrypt the drive It depends on what kind of attack you are trying to defend from. If it is theft of your hard drive from your cold powered off machine, then this will help (not 100% solve it, just brute force drive decryption attack is too expensive or slow). If, however, it is physical machine security that you are trying to solve, encrypting drive not necessarily will help. The following is the speculation about how the attack can be performed. Bad guy has physical access to your machine when it is up and running. He opens the case, splashes liquid nitrogen onto your RAM, pulls RAM modules, plugs them into his device. Low temperature ensures the content of RAM is not lost while physically swapping it over to bad guy's device, and that device ensures the content of RAM is not lost (pretty much the same way as dynamic RAM is used always). And the guy takes the hard drive. Encryption/decryption happens on the fly on running machine (otherwise yanking the power will allow on to have decrypted drive), and therefore the encryption/decryption key(s) must me somewhere in the RAM when machine runs. And the bad guy has it all now: the whole content of the RAM (with the keys), and [encrypted] hard drive. He has your information. It sounds a bit too elaborate, but as someone said already, it can be done, the difference is just in the amount of effort/cost. Valeri > and try not to > upset the NSA. > -- ++++++++++++++++++++++++++++++++++++++++ Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247 ++++++++++++++++++++++++++++++++++++++++