[148505] in cryptography@c2.net mail archive
Re: [Cryptography]
daemon@ATHENA.MIT.EDU (Bill Cox)
Wed Dec 18 12:35:48 2013
X-Original-To: cryptography@metzdowd.com
Date: Wed, 18 Dec 2013 06:58:45 -0500
From: Bill Cox <waywardgeek@gmail.com>
To: cryptography@metzdowd.com
In-Reply-To: <5B99F4E5-A069-4375-A61B-DC6BDC79CBE4@safechat.im>
Errors-To: cryptography-bounces+crypto.discuss=bloom-picayune.mit.edu@metzdowd.com
This is a multi-part message in MIME format.
--===============7800142234945514507==
Content-Type: multipart/alternative;
boundary="------------010800020403010609030006"
This is a multi-part message in MIME format.
--------------010800020403010609030006
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
On 12/17/2013 4:58 PM, SafeChat.IM wrote:
> *
> Dear mailing list,
>
> A friend and me are working on a plugin that enables encryption on top
> of Facebook messaging. The idea is to encrypt messages before they
> leave the chat client, sending only the cipher to Facebook and decrypt
> the message on the receiver client, before it is displayed. The plugin
> automatically realizes which users have it installed and only encrypts
> these chats.
> *
Very cool!
> *
> Since the reliability of the cryptographic system is a crucial part of
> the design, I would to discuss the protocol here:
>
> First, we use PBKDF2 to derive a 256 bit data block from a passphrase
> the user chooses and a salt (the username). We advise the user to use
> a long and hard-to-guess passphrase. We use Parvez Anandam’s
> JavaScript implementation [1].
> *
PBKDF2, just like TrueCrypt? I hope you decide to have better password
security than those guys. The PBKDF2 key stretching in TrueCrypt is a
joke. You have to find an obscure option to even enable the 2000-round
SHA256 key stretching, which provides close to no security at all. The
kinds of passwords your users on Facebook will actually use have very
few bits of entropy, and can be guessed by hardware based brute force
attacks very quickly.
To have much better password protection, take a look at the key
stretching used in FreeCoin: scrypt. While it is less effective at
reducing hardware based password guessing attacks than it should be,
it's still many thousands of times more effective than SHA-256 based key
stretching. I wrote some code that is like scrypt but it understands
that we should thrash the on-chip cache while keeping the DRAM interface
at 100% data transfer rates to more effectively beat hardware based
password guessing. Scrypt causes a cache miss every cycle, enabling
hardware that does faster random access to accelerate it's key
stretching by a factor of maybe 100. Scrypt also has some undesirable
properties such as needing to put scrypt parameters along side the salt,
making it clear that the file is an script based encrypted password
rather than random junk, reducing deniability. My code gets around the
weaknesses in scrypt that I perceived, but please just use scrypt rather
than untested code. Freecoin proved scrypt works, and that's worth a
lot. Also, you guys will naturally do what everyone should be doing:
perform the key stretching in the browser, not on the server. For
example, default Microsoft key stretching is only 1000 rounds of SHA-256
because it's done in ASP.net on the server rather than in the browser.
Now for my tin hat conspiracy theories: Why is Microsoft so stupid about
where to perform key stretching? Why wont the TrueCrypt team adopt
decent password security? Why does PGP have 0 key stretching by
default, and why is my SSH private key encrypted with no key stretching
and no option to use it? You want to encrypt Facebook traffic with real
security? I just have to wonder if some tall suits with dark sunglasses
are going to convince you to do otherwise. My other theory is people
are really that stupid, whether they write SSH encryption code, PGP, or
TrueCrypt.
--------------010800020403010609030006
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 8bit
<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 12/17/2013 4:58 PM, SafeChat.IM
wrote:<br>
</div>
<blockquote
cite="mid:5B99F4E5-A069-4375-A61B-DC6BDC79CBE4@safechat.im"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
<div style="word-wrap: break-word; -webkit-nbsp-mode: space;
-webkit-line-break: after-white-space; "><b
id="docs-internal-guid--7464a69-01b7-5e75-8b73-89673e4e1507">
<div style="line-height: 1.15; margin-top: 0pt; margin-bottom:
0pt; "><span style="font-size: 15px; font-family: Arial;
font-weight: normal; vertical-align: baseline;
white-space: pre-wrap; ">Dear mailing list,</span></div>
<p dir="ltr" style="line-height: 1.15; margin-top: 0pt;
margin-bottom: 0pt; "><span style="font-size: 15px;
font-family: Arial; font-weight: normal; vertical-align:
baseline; white-space: pre-wrap; "> </span></p>
<div style="line-height: 1.15; margin-top: 0pt; margin-bottom:
0pt; "><span style="font-size: 15px; font-family: Arial;
font-weight: normal; vertical-align: baseline;
white-space: pre-wrap; ">A friend and me are working on a
plugin that enables encryption on top of Facebook
messaging. The idea is to encrypt messages before they
leave the chat client, sending only the cipher to Facebook
and decrypt the message on the receiver client, before it
is displayed. The plugin automatically realizes which
users have it installed and only encrypts these chats.</span></div>
</b></div>
</blockquote>
<br>
Very cool!<br>
<br>
<blockquote
cite="mid:5B99F4E5-A069-4375-A61B-DC6BDC79CBE4@safechat.im"
type="cite">
<div style="word-wrap: break-word; -webkit-nbsp-mode: space;
-webkit-line-break: after-white-space; "><b
id="docs-internal-guid--7464a69-01b7-5e75-8b73-89673e4e1507">
<div style="line-height: 1.15; margin-top: 0pt; margin-bottom:
0pt; "><span style="font-size: 15px; font-family: Arial;
font-weight: normal; vertical-align: baseline;
white-space: pre-wrap; "></span></div>
<div style="line-height: 1.15; margin-top: 0pt; margin-bottom:
0pt; "><span style="font-size: 15px; font-family: Arial;
font-weight: normal; vertical-align: baseline;
white-space: pre-wrap; ">Since the reliability of the
cryptographic system is a crucial part of the design, I
would to discuss the protocol here:</span></div>
<p dir="ltr" style="line-height: 1.15; margin-top: 0pt;
margin-bottom: 0pt; "><span style="font-size: 15px;
font-family: Arial; font-weight: normal; vertical-align:
baseline; white-space: pre-wrap; "> </span></p>
<div style="line-height: 1.15; margin-top: 0pt; margin-bottom:
0pt; "><span style="font-size: 15px; font-family: Arial;
font-weight: normal; vertical-align: baseline;
white-space: pre-wrap; ">First, we use PBKDF2 to derive a
256 bit data block from a passphrase the user chooses and
a salt (the username). We advise the user to use a long
and hard-to-guess passphrase. We use Parvez Anandam’s
JavaScript implementation [1].</span></div>
</b><br>
</div>
</blockquote>
PBKDF2, just like TrueCrypt? I hope you decide to have better
password security than those guys. The PBKDF2 key stretching in
TrueCrypt is a joke. You have to find an obscure option to even
enable the 2000-round SHA256 key stretching, which provides close to
no security at all. The kinds of passwords your users on Facebook
will actually use have very few bits of entropy, and can be guessed
by hardware based brute force attacks very quickly.<br>
<br>
To have much better password protection, take a look at the key
stretching used in FreeCoin: scrypt. While it is less effective at
reducing hardware based password guessing attacks than it should be,
it's still many thousands of times more effective than SHA-256 based
key stretching. I wrote some code that is like scrypt but it
understands that we should thrash the on-chip cache while keeping
the DRAM interface at 100% data transfer rates to more effectively
beat hardware based password guessing. Scrypt causes a cache miss
every cycle, enabling hardware that does faster random access to
accelerate it's key stretching by a factor of maybe 100. Scrypt
also has some undesirable properties such as needing to put scrypt
parameters along side the salt, making it clear that the file is an
script based encrypted password rather than random junk, reducing
deniability. My code gets around the weaknesses in scrypt that I
perceived, but please just use scrypt rather than untested code.
Freecoin proved scrypt works, and that's worth a lot. Also, you
guys will naturally do what everyone should be doing: perform the
key stretching in the browser, not on the server. For example,
default Microsoft key stretching is only 1000 rounds of SHA-256
because it's done in ASP.net on the server rather than in the
browser.<br>
<br>
Now for my tin hat conspiracy theories: Why is Microsoft so stupid
about where to perform key stretching? Why wont the TrueCrypt team
adopt decent password security? Why does PGP have 0 key stretching
by default, and why is my SSH private key encrypted with no key
stretching and no option to use it? You want to encrypt Facebook
traffic with real security? I just have to wonder if some tall
suits with dark sunglasses are going to convince you to do
otherwise. My other theory is people are really that stupid,
whether they write SSH encryption code, PGP, or TrueCrypt.<br>
</body>
</html>
--------------010800020403010609030006--
--===============7800142234945514507==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
_______________________________________________
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography
--===============7800142234945514507==--
