<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: The One-Time Pad Hard Drive</title>
	<atom:link href="http://pthree.org/2012/08/26/the-one-time-pad-hard-drive/feed/" rel="self" type="application/rss+xml" />
	<link>http://pthree.org/2012/08/26/the-one-time-pad-hard-drive/</link>
	<description>Linux.  GNU.  Freedom.</description>
	<lastBuildDate>Thu, 20 Jun 2013 10:21:35 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.6-beta3-24432</generator>
	<item>
		<title>By: Aaron Toponce : The NSA and Nubmer Stations- An Historical Perspective</title>
		<link>http://pthree.org/2012/08/26/the-one-time-pad-hard-drive/#comment-126852</link>
		<dc:creator>Aaron Toponce : The NSA and Nubmer Stations- An Historical Perspective</dc:creator>
		<pubDate>Thu, 20 Jun 2013 05:49:36 +0000</pubDate>
		<guid isPermaLink="false">http://pthree.org/?p=2474#comment-126852</guid>
		<description><![CDATA[[&#8230;] OTP can be an effective and practical way to send messages securely. I mentioned almost a year ago, of a way to create a USB hard drive with a OTP on the drive. Both the sender and the recipient have an exact copy of the drive, along with a software utility [&#8230;]]]></description>
		<content:encoded><![CDATA[<p>[&#8230;] OTP can be an effective and practical way to send messages securely. I mentioned almost a year ago, of a way to create a USB hard drive with a OTP on the drive. Both the sender and the recipient have an exact copy of the drive, along with a software utility [&#8230;]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Aaron Toponce</title>
		<link>http://pthree.org/2012/08/26/the-one-time-pad-hard-drive/#comment-116855</link>
		<dc:creator>Aaron Toponce</dc:creator>
		<pubDate>Mon, 27 Aug 2012 17:00:35 +0000</pubDate>
		<guid isPermaLink="false">http://pthree.org/?p=2474#comment-116855</guid>
		<description><![CDATA[Encrypting the hard drive? Well, if the drive is lost or stolen, you don&#039;t want the bad guys to have access to the keys, do you? So, use something like LUKS, TrueCrypt or eCryptfs to encrypt the keys on the drive.]]></description>
		<content:encoded><![CDATA[<p>Encrypting the hard drive? Well, if the drive is lost or stolen, you don&#8217;t want the bad guys to have access to the keys, do you? So, use something like LUKS, TrueCrypt or eCryptfs to encrypt the keys on the drive.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Nikos Fotiou</title>
		<link>http://pthree.org/2012/08/26/the-one-time-pad-hard-drive/#comment-116854</link>
		<dc:creator>Nikos Fotiou</dc:creator>
		<pubDate>Mon, 27 Aug 2012 13:56:15 +0000</pubDate>
		<guid isPermaLink="false">http://pthree.org/?p=2474#comment-116854</guid>
		<description><![CDATA[Can you please elaborate comment 2 a bit more?]]></description>
		<content:encoded><![CDATA[<p>Can you please elaborate comment 2 a bit more?</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Aaron Toponce</title>
		<link>http://pthree.org/2012/08/26/the-one-time-pad-hard-drive/#comment-116852</link>
		<dc:creator>Aaron Toponce</dc:creator>
		<pubDate>Mon, 27 Aug 2012 01:09:43 +0000</pubDate>
		<guid isPermaLink="false">http://pthree.org/?p=2474#comment-116852</guid>
		<description><![CDATA[If the key is not the same length as the message, then it&#039;s not a one-time pad. That&#039;s how it offers perfect secrecy.]]></description>
		<content:encoded><![CDATA[<p>If the key is not the same length as the message, then it&#8217;s not a one-time pad. That&#8217;s how it offers perfect secrecy.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Alan Bell</title>
		<link>http://pthree.org/2012/08/26/the-one-time-pad-hard-drive/#comment-116851</link>
		<dc:creator>Alan Bell</dc:creator>
		<pubDate>Sun, 26 Aug 2012 20:46:21 +0000</pubDate>
		<guid isPermaLink="false">http://pthree.org/?p=2474#comment-116851</guid>
		<description><![CDATA[better to use standard length key sizes, and have one set per direction. If you try and match the key size to the message then you give away the exact message length. If they are all 1024 bytes long or some other convenient size then you waste some bits (big deal) but leak less about your message. In fact if your keys are all bigger than any message you might want to send then you are giving away the least. The problem with one time pad is the requirement of distribution of the keys in advance. You can&#039;t really securely negotiate keys over the wire.]]></description>
		<content:encoded><![CDATA[<p>better to use standard length key sizes, and have one set per direction. If you try and match the key size to the message then you give away the exact message length. If they are all 1024 bytes long or some other convenient size then you waste some bits (big deal) but leak less about your message. In fact if your keys are all bigger than any message you might want to send then you are giving away the least. The problem with one time pad is the requirement of distribution of the keys in advance. You can&#8217;t really securely negotiate keys over the wire.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Aaron Toponce</title>
		<link>http://pthree.org/2012/08/26/the-one-time-pad-hard-drive/#comment-116850</link>
		<dc:creator>Aaron Toponce</dc:creator>
		<pubDate>Sun, 26 Aug 2012 16:24:03 +0000</pubDate>
		<guid isPermaLink="false">http://pthree.org/?p=2474#comment-116850</guid>
		<description><![CDATA[I thought about that, and the reason I decided against it, is because then every first byte starts with 0 or 1 for every message exchanged. While the rest of the data may be random, that first byte is not.]]></description>
		<content:encoded><![CDATA[<p>I thought about that, and the reason I decided against it, is because then every first byte starts with 0 or 1 for every message exchanged. While the rest of the data may be random, that first byte is not.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Jason</title>
		<link>http://pthree.org/2012/08/26/the-one-time-pad-hard-drive/#comment-116849</link>
		<dc:creator>Jason</dc:creator>
		<pubDate>Sun, 26 Aug 2012 16:01:19 +0000</pubDate>
		<guid isPermaLink="false">http://pthree.org/?p=2474#comment-116849</guid>
		<description><![CDATA[I don&#039;t see the benefit of having varying key sizes.  Why not just use a drive filled with random data, and use a system where you start at byte 0, and for each message exchanged, you walk through the key bytes and consume whatever is needed for that message size.  If we&#039;ve previously exchanged 31337 bytes of messages in the past, then the next message uses key data offset from 31338 through to the exact length of the new message.

There is a race condition problem if you both want to send a message at the same time, you may accidentally start at the same offset.  If you both send messages using the same OTP then you&#039;ve just broken the security.  But then your proposal has this problem too, so it would need to be solved in any case.]]></description>
		<content:encoded><![CDATA[<p>I don&#8217;t see the benefit of having varying key sizes.  Why not just use a drive filled with random data, and use a system where you start at byte 0, and for each message exchanged, you walk through the key bytes and consume whatever is needed for that message size.  If we&#8217;ve previously exchanged 31337 bytes of messages in the past, then the next message uses key data offset from 31338 through to the exact length of the new message.</p>
<p>There is a race condition problem if you both want to send a message at the same time, you may accidentally start at the same offset.  If you both send messages using the same OTP then you&#8217;ve just broken the security.  But then your proposal has this problem too, so it would need to be solved in any case.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
