From marete@toshnix.com Thu May 22 06:48:36 2014 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 869371A017A for ; Thu, 22 May 2014 06:48:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.722 X-Spam-Level: X-Spam-Status: No, score=0.722 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v8pXTOQvtz8o for ; Thu, 22 May 2014 06:48:31 -0700 (PDT) Received: from mail-ve0-f182.google.com (mail-ve0-f182.google.com [209.85.128.182]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E54E1A0168 for ; Thu, 22 May 2014 06:48:31 -0700 (PDT) Received: by mail-ve0-f182.google.com with SMTP id sa20so4456494veb.13 for ; Thu, 22 May 2014 06:48:29 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-type; bh=oE+xBCgD3nJuvXEI4n5KPzS1sjp1YXG+QkaiX3GJsL0=; b=jeKwzgqKbMaHFNfsfYQOu1F5goC+7DAVBP0mt+MErTUi/h/xQVm06ggXbt9m9/hmN6 1RcoMQ1Qslv3P/SDr/xh13uZXZy085KEMQQk7J5Bw+kz+nixynZNzW72e25SjDi+Bus7 Kdm7ebYWzWYnMA99lVZVEMNaW3NCyXDCZUsNL7Xn4Ndj6s2D7HNmdARssvSRb42zXJ/I VRl+TnLF3zU8Sj/PVht6nytin4VOTEH7Y2Bo/kk34jbKtyaJkCIQtjLdHpCstsJcISYF nr9bL7Z/sq7djQEGe7KlXE0aM86GZlozOR45oxAowKrHDf6h/QuTMr7/ECJyioPeMWBS hHTQ== X-Gm-Message-State: ALoCoQki0pQaB2Mdu5+7Zmw2eLfQIRigtdlgJO4BVvgm5O8ggdilkfJ719UgonBS0rnsc3xY2sJq X-Received: by 10.52.149.99 with SMTP id tz3mr221671vdb.92.1400766509461; Thu, 22 May 2014 06:48:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.12.68 with HTTP; Thu, 22 May 2014 06:48:09 -0700 (PDT) X-Originating-IP: [197.237.93.196] From: Brian Gitonga Marete Date: Thu, 22 May 2014 16:48:09 +0300 Message-ID: To: openpgp@ietf.org Content-Type: multipart/alternative; boundary=bcaec51b986d35ca8004f9fd5e0b Archived-At: http://mailarchive.ietf.org/arch/msg/openpgp/IubZlQfTENP_qMX9rHGhgVOmHag Subject: [openpgp] On composing scrypt and openpgp s2k key stretching for symmetric encryption X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 May 2014 13:50:25 -0000 --bcaec51b986d35ca8004f9fd5e0b Content-Type: text/plain; charset=UTF-8 Hello all! What would be the security effect of generating a 32 byte key from a passphrase using scrypt and then using that as a "passphrase" for openpgp's symmetric encryption (this 32 byte key will of course then be acted upon by openpgp's s2k algorithm). Specifically, can one expect that this will make brute-forcing a symmetric passphrase (theoretically or practically) harder? (Given the same strong passhrase). Please note that I am asking this from an application point of view and not calling for the inclusion of scrypt into the openpgp standard. Thanks! Brian Gitonga Marete. --bcaec51b986d35ca8004f9fd5e0b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello all!

Wha= t would be the security effect of generating a 32 byte key from a passphras= e using scrypt and then using that as a "passphrase" for openpgp&= #39;s symmetric encryption (this 32 byte key will of course then be acted u= pon by openpgp's s2k algorithm). Specifically, can one expect that this= will make brute-forcing a symmetric passphrase (theoretically or practical= ly) harder? (Given the same strong passhrase).

Please note that I am = asking this from an application point of view and not calling for the inclu= sion of scrypt into the openpgp standard.

Thanks!

=
Brian Gitonga Marete.
--bcaec51b986d35ca8004f9fd5e0b-- From nobody Thu May 22 14:42:18 2014 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D681A1A037E for ; Thu, 22 May 2014 14:42:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MXKqCZSYo9Mr for ; Thu, 22 May 2014 14:42:15 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id E8BBC1A0283 for ; Thu, 22 May 2014 14:42:14 -0700 (PDT) Received: from [10.70.10.78] (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id DB973F984; Thu, 22 May 2014 17:42:11 -0400 (EDT) Message-ID: <537E6F33.5090901@fifthhorseman.net> Date: Thu, 22 May 2014 17:42:11 -0400 From: Daniel Kahn Gillmor User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Icedove/24.5.0 MIME-Version: 1.0 To: Brian Gitonga Marete , openpgp@ietf.org References: In-Reply-To: X-Enigmail-Version: 1.6+git0.20140323 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="HI7rmsO08e167nvqnaPsNdq8M72Cdm0ad" Archived-At: http://mailarchive.ietf.org/arch/msg/openpgp/cHu3MgpOywVmYU5tcBhiQQgQkP8 Subject: Re: [openpgp] On composing scrypt and openpgp s2k key stretching for symmetric encryption X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 May 2014 21:42:17 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --HI7rmsO08e167nvqnaPsNdq8M72Cdm0ad Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 05/22/2014 09:48 AM, Brian Gitonga Marete wrote: > What would be the security effect of generating a 32 byte key from a > passphrase using scrypt and then using that as a "passphrase" for openp= gp's > symmetric encryption (this 32 byte key will of course then be acted upo= n by > openpgp's s2k algorithm). Specifically, can one expect that this will m= ake > brute-forcing a symmetric passphrase (theoretically or practically) har= der? > (Given the same strong passhrase). sounds to me like it would make things harder, but you might need to be careful with your tooling to ensure that the passphrase handed off to s2k "looks like" a normal human-typed passphrase. For example, if the raw scrypt 32-byte key contains a NUL byte or a newline char, and you pass it to a tool that expects the passphrase as a single line of null-terminated text, you could have a pretty nasty failure mode. you could always base64-encode the output of scrypt before it gets fed into the later tools just to be sure. > Please note that I am asking this from an application point of view and= not > calling for the inclusion of scrypt into the openpgp standard. Why would you want to do it this way instead of including it in the standard? if you do this to a piece of passphrase-encrypted OpenPGP data, and then hand the data to some other person or machine, and expect them to be able to decrypt it, how will that person or machine know to use scrypt on the passphrase before invoking s2k? we are not short on available s2k identifiers [0] -- allocating another one for scrypt given a reasonable specification doesn't seem like a bad idea to me, especially if people are interested in implementing it. --dkg [0] https://tools.ietf.org/html/rfc4880#section-3.7 --HI7rmsO08e167nvqnaPsNdq8M72Cdm0ad Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iQJ8BAEBCgBmBQJTfm8zXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFQjk2OTEyODdBN0FEREUzNzU3RDkxMUVB NTI0MDFCMTFCRkRGQTVDAAoJEKUkAbEb/fpckdgP/A6vMYJ7KDaBPo3bXHx2OSLy L9CDMa0z93wuf3fUQfHPYGIjBgEfAjhFPj1XIOQ9x6/+U6LRrwNpFfg+td+jJaaK Kb7ZTn/gI63lKO6M85RuMV9d/5d/a/l7XYOIFEVauK+BRSpYsDAInCVlOp4VSlFu Nagpl11dgHz8z/ze65cVNg2Pg1BWwU+lojz/wGP+Rf4mT3WrjSOI+zHgB6slJqSm rypb4Dx+LuIyGgcB09DepZOUIluUJkVUHbrsYjf81LlyfrlOFWxUTbF1rwG0mE/w 4roVnpbHNYF7ukK+4YNK4NgxMdQ8wTWYVSySX7VV9l68r9LaT1SKBc6x1dVztmL4 SwX+OAaQpWivWMq3rdC5dW0MXdeucf6OMmwTrge1J3ROTRhs4jkFKtUBlNfb380h xOdXA8iihSQn68+/QflLild4lXgQgkU5dnT2k5WD+dz2tFqzXCOivZq3yWXd4oSf kDhjUScp4f3oFt94C7a13y43VRV2eHamxdD5sxHdhRbqkrCFaKTPbuQ7cUeXG6Ts UQ7p/qwFvzuFGEt01Ku+ipEd1PNrr0e/WkTzl7inU+JnAWtuSUAb3Ze7iWyfcjs9 2eBVYvqvTJ2cSWEaTMzQsMqGq050xotsV71R6CamWVbEu0TUVz1rOtXfSn9xGHGn RufMzMZtucKqCZh7c9AS =p4Bt -----END PGP SIGNATURE----- --HI7rmsO08e167nvqnaPsNdq8M72Cdm0ad-- From nobody Thu May 22 16:41:54 2014 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9D4A1A0256 for ; Thu, 22 May 2014 16:41:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id onCZoVYUTd0o for ; Thu, 22 May 2014 16:41:50 -0700 (PDT) Received: from mail.merrymeet.com (merrymeet.com [173.164.244.100]) by ietfa.amsl.com (Postfix) with ESMTP id 86C321A0248 for ; Thu, 22 May 2014 16:41:50 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.merrymeet.com (Postfix) with ESMTP id 149C153FF50C; Thu, 22 May 2014 16:41:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at merrymeet.com Received: from mail.merrymeet.com ([127.0.0.1]) by localhost (merrymeet.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4-YUhBP+wEBS; Thu, 22 May 2014 16:41:39 -0700 (PDT) Received: from keys.merrymeet.com (keys.merrymeet.com [173.164.244.97]) by mail.merrymeet.com (Postfix) with ESMTPSA id 14B4D53FF4EB; Thu, 22 May 2014 16:41:38 -0700 (PDT) Received: from [10.0.23.30] ([173.164.244.98]) by keys.merrymeet.com (PGP Universal service); Thu, 22 May 2014 16:41:39 -0700 X-PGP-Universal: processed; by keys.merrymeet.com on Thu, 22 May 2014 16:41:39 -0700 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Jon Callas In-Reply-To: Date: Thu, 22 May 2014 16:41:37 -0700 Message-Id: <5E5B20C2-7647-4437-A489-7321CC8079C6@callas.org> References: To: Brian Gitonga Marete X-Mailer: Apple Mail (2.1878.2) Content-Type: multipart/alternative; boundary="Apple-Mail=_BEA6228A-3F8F-41FF-81D7-44CE369C2334" Archived-At: http://mailarchive.ietf.org/arch/msg/openpgp/RjJE6_EZ5FXOmb-MtAmq-RzmB3c Cc: openpgp@ietf.org, Jon Callas Subject: Re: [openpgp] On composing scrypt and openpgp s2k key stretching for symmetric encryption X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 May 2014 23:41:52 -0000 --Apple-Mail=_BEA6228A-3F8F-41FF-81D7-44CE369C2334 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On May 22, 2014, at 6:48 AM, Brian Gitonga Marete = wrote: > Hello all! >=20 > What would be the security effect of generating a 32 byte key from a = passphrase using scrypt and then using that as a "passphrase" for = openpgp's symmetric encryption (this 32 byte key will of course then be = acted upon by openpgp's s2k algorithm). Specifically, can one expect = that this will make brute-forcing a symmetric passphrase (theoretically = or practically) harder? (Given the same strong passhrase). Meh. Intuitively, yes, it would. However, there's really nothing theoretic = that says it's better. Most things that are intuitively better but = unmeasurable turn out to be far less good than your intuition says. = Depressingly often, someone comes up with a clever attack that reduces = the intuitive thing to being no better than a bit or two, and in the = case of passwords, I've rarely seen anything that's better than adding = another character to your password. > Please note that I am asking this from an application point of view = and not calling for the inclusion of scrypt into the openpgp standard. If you are set on doing it, Dan Gillmor brings up an important point = (and a way one could shoot oneself in the foot). An easy way to protect = against that is to take your scrypt() result and put it into text -- = base64, hex, whatever -- and then use *that* as your input to s2k. Jon --Apple-Mail=_BEA6228A-3F8F-41FF-81D7-44CE369C2334 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
On May 22, 2014, at 6:48 AM, Brian = Gitonga Marete <marete@toshnix.com> = wrote:

Hello = all!

What would be the = security effect of generating a 32 byte key from a passphrase using = scrypt and then using that as a "passphrase" for openpgp's symmetric = encryption (this 32 byte key will of course then be acted upon by = openpgp's s2k algorithm). Specifically, can one expect that this will = make brute-forcing a symmetric passphrase (theoretically or practically) = harder? (Given the same strong = passhrase).

Meh.
Intuitively, yes, it would. However, there's really nothing = theoretic that says it's better. Most things that are intuitively better = but unmeasurable turn out to be far less good than your intuition says. = Depressingly often, someone comes up with a clever attack that reduces = the intuitive thing to being no better than a bit or two, and in the = case of passwords, I've rarely seen anything that's better than adding = another character to your password.

Please note = that I am asking this from an application point of view and not calling = for the inclusion of scrypt into the openpgp standard.

If you are set on doing it, Dan = Gillmor brings up an important point (and a way one could shoot oneself = in the foot). An easy way to protect against that is to take your = scrypt() result and put it into text -- base64, hex, whatever -- and = then use *that* as your input to s2k.

= Jon


= --Apple-Mail=_BEA6228A-3F8F-41FF-81D7-44CE369C2334-- From nobody Fri May 23 07:33:45 2014 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFBF91A0157 for ; Fri, 23 May 2014 02:03:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.203 X-Spam-Level: X-Spam-Status: No, score=-2.203 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yCRYIr4xU2RZ for ; Fri, 23 May 2014 02:03:48 -0700 (PDT) Received: from annwfn.iks-jena.de (annwfn-eth.iks-jena.de [IPv6:2001:4bd8:0:104:20a:e4ff:fe80:3138]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9BF061A014E for ; Fri, 23 May 2014 02:03:46 -0700 (PDT) X-SMTP-Sender: IPv6:2001:4bd8:0:666:248:54ff:fe12:ee3f Received: from belenus.iks-jena.de (belenus.iks-jena.de [IPv6:2001:4bd8:0:666:248:54ff:fe12:ee3f]) by annwfn.iks-jena.de (8.14.3/8.14.1) with ESMTP id s4N93ZVM027342 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 23 May 2014 11:03:38 +0200 X-MSA-Host: belenus.iks-jena.de Received: (from lutz@localhost) by belenus.iks-jena.de (8.14.3/8.14.1/Submit) id s4N93YXq025728; Fri, 23 May 2014 11:03:34 +0200 Date: Fri, 23 May 2014 11:03:34 +0200 From: Lutz Donnerhacke To: Jon Callas Message-ID: <20140523090334.GA25165@belenus.iks-jena.de> References: <5E5B20C2-7647-4437-A489-7321CC8079C6@callas.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5E5B20C2-7647-4437-A489-7321CC8079C6@callas.org> X-message-flag: Please send plain text messages only. Thank you. User-Agent: Mutt/1.5.17 (2007-11-01) Archived-At: http://mailarchive.ietf.org/arch/msg/openpgp/qVxfir8vQ1LTd-6wKAXaVvfrF7c X-Mailman-Approved-At: Fri, 23 May 2014 07:33:44 -0700 Cc: Brian Gitonga Marete , openpgp@ietf.org Subject: Re: [openpgp] On composing scrypt and openpgp s2k key stretching for symmetric encryption X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 May 2014 09:03:50 -0000 On Thu, May 22, 2014 at 04:41:37PM -0700, Jon Callas wrote: > Most things that are intuitively better but unmeasurable turn out to > be far less good than your intuition says. Depressingly often, someone > comes up with a clever attack that reduces the intuitive thing to being Yep. One aspect was already mentioned "NUL" characters. The obvious counter measurement was also mentionen "base64". But this reduces the possible input variation. It might be possible to mount an attack on it. The general rule is: If you fear, that the default algorithm is not safe, change it! You can't incease security by chaining algorithms. From nobody Fri May 23 07:41:14 2014 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DBE61A0476 for ; Fri, 23 May 2014 07:41:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bMZl-JkfSjM2 for ; Fri, 23 May 2014 07:41:11 -0700 (PDT) Received: from mail.merrymeet.com (merrymeet.com [173.164.244.100]) by ietfa.amsl.com (Postfix) with ESMTP id F32D81A0198 for ; Fri, 23 May 2014 07:41:10 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.merrymeet.com (Postfix) with ESMTP id 33DDB54098FF; Fri, 23 May 2014 07:41:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at merrymeet.com Received: from mail.merrymeet.com ([127.0.0.1]) by localhost (merrymeet.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CS9-rN0k6RUV; Fri, 23 May 2014 07:41:08 -0700 (PDT) Received: from keys.merrymeet.com (keys.merrymeet.com [173.164.244.97]) by mail.merrymeet.com (Postfix) with ESMTPSA id 9BEF454098F2; Fri, 23 May 2014 07:41:06 -0700 (PDT) Received: from [10.0.23.30] ([173.164.244.98]) by keys.merrymeet.com (PGP Universal service); Fri, 23 May 2014 07:41:08 -0700 X-PGP-Universal: processed; by keys.merrymeet.com on Fri, 23 May 2014 07:41:08 -0700 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Jon Callas In-Reply-To: <20140523090334.GA25165@belenus.iks-jena.de> Date: Fri, 23 May 2014 07:41:05 -0700 Message-Id: <4BEA8A87-85A1-4625-A067-FA60D1798BCF@callas.org> References: <5E5B20C2-7647-4437-A489-7321CC8079C6@callas.org> <20140523090334.GA25165@belenus.iks-jena.de> To: Lutz Donnerhacke X-Mailer: Apple Mail (2.1878.2) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/openpgp/-pfAGV6Lvp_MbUEfaBkpWMiHYQI Cc: Brian Gitonga Marete , openpgp@ietf.org, Jon Callas Subject: Re: [openpgp] On composing scrypt and openpgp s2k key stretching for symmetric encryption X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 May 2014 14:41:12 -0000 > Yep. One aspect was already mentioned "NUL" characters. The obvious = counter > measurement was also mentionen "base64". But this reduces the possible = input > variation. It might be possible to mount an attack on it. If you can, the hash function is broken. Assuming of course that you're = taking then entire expanded string. Any textification of a string is = just a sloppy coding, and if the hash function has odd properties, then = it's very, very broken. >=20 > The general rule is: If you fear, that the default algorithm is not = safe, > change it! You can't incease security by chaining algorithms. Yes! I couldn't agree more.=20 Jon= From nobody Fri May 23 07:46:22 2014 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7ED441A01D8 for ; Fri, 23 May 2014 07:46:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oUOuoFfUHJQS for ; Fri, 23 May 2014 07:46:18 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id B7CD51A0168 for ; Fri, 23 May 2014 07:46:18 -0700 (PDT) Received: from [10.70.10.78] (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id 350ECF984; Fri, 23 May 2014 10:46:13 -0400 (EDT) Message-ID: <537F5F36.7000800@fifthhorseman.net> Date: Fri, 23 May 2014 10:46:14 -0400 From: Daniel Kahn Gillmor User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Icedove/24.5.0 MIME-Version: 1.0 To: Lutz Donnerhacke , Jon Callas References: <5E5B20C2-7647-4437-A489-7321CC8079C6@callas.org> <20140523090334.GA25165@belenus.iks-jena.de> In-Reply-To: <20140523090334.GA25165@belenus.iks-jena.de> X-Enigmail-Version: 1.6+git0.20140323 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="IRFGfckamJP1qBSnl7A8vkQbJlGLk7nP2" Archived-At: http://mailarchive.ietf.org/arch/msg/openpgp/ra4cNTgusHP-cIEo8ty131ClROg Cc: Brian Gitonga Marete , openpgp@ietf.org Subject: Re: [openpgp] On composing scrypt and openpgp s2k key stretching for symmetric encryption X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 May 2014 14:46:20 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --IRFGfckamJP1qBSnl7A8vkQbJlGLk7nP2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 05/23/2014 05:03 AM, Lutz Donnerhacke wrote: > Yep. One aspect was already mentioned "NUL" characters. The obvious cou= nter > measurement was also mentionen "base64". But this reduces the possible = input > variation. It might be possible to mount an attack on it.=20 The amount of entropy going into a base64 encoding is *exactly* equal to the amount of entropy coming out of it. From a brute-force perspective, nothing is lost. The only attacks that fit what you're describing would be an attack based on plaintext patterns of specific bits of the input (e.g. the high bit of every octet of input is known to be zero), but i have not heard of any such attack on an s2k transformation. If the s2k input tends to come directly from the keyboard, the same patterns are likely to be present as well (and even more, since human-memorable passwords have much more structure than base64-encoded scrypt output). --dkg --IRFGfckamJP1qBSnl7A8vkQbJlGLk7nP2 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iQJ8BAEBCgBmBQJTf182XxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFQjk2OTEyODdBN0FEREUzNzU3RDkxMUVB NTI0MDFCMTFCRkRGQTVDAAoJEKUkAbEb/fpc2gUP/10NkqXOnc/b8KYMbSHu7UXj L+PjIKmaiGoiLkMg/zOdWCNcegsimgvAfLzuYCVjANcw4osYVbnYcni0uUmP4gOl h5s+N7VMGU8luofpoVEALr3V9pkPJTr4VIAelT0yWYooKUhGQuAAOpA3+0Sls6Pl XENUwJg7pyJyiW5eEwM8Qj8qVW4AZSZGpl0Bn6uja9yz5bCk46fL3zqrFP9foJjZ ElVzncwefHevZFVCY/jdm/oS2Ra8zBp8C69rOzxUaJjPbG/WJ2LqmSHNSDhM2XpH 7i8Xwg7AcfPUU4qN9yI1Z8RIrvokTodNflTOZ4YYu4wpwYOw5YHn+LDt5SJ7lGZL 2vybIfA98PPpl1EmJp0EH0qbIW7FBEJQJl9Fa/KLgZJCD0pMYGNbK7k+co4T4lzr 3Ju2DjZgvYCY3FGIT3QkGe3Ig/3HpAyhOxg0sMoE3l5wF9syc2t4e7/29ftujtyX m2NjJeQudCYKO/zOYAgfkUpzfJgiOGlFwBEXWHmEu5ZNvDKj44sRPz89q+bRngDJ XFyAJzUEGFLVZN5Gsbx5I7XLQWb1WP1cBb6t0de0MLmGW6fWNH+C955M6CyWTWO/ 9MEsLmbhusGMwo3YL+uWOtgJVgjSJOdOABh0tn51XPW+uAt65wmJ/TpMQsXSlvnl UZfzV02sI7ehwQOL5Kh/ =2qaR -----END PGP SIGNATURE----- --IRFGfckamJP1qBSnl7A8vkQbJlGLk7nP2--