220 12505 article Path: news.gmane.org!not-for-mail From: "'Jeffrey Yasskin' via ISO C++ Standard - Future Proposals" Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Cryptographic hash functions reloaded [was Interest in cryptographic functions within the standard library] Date: Mon, 25 Aug 2014 11:01:42 -0700 Lines: 79 Approved: news@gmane.org Message-ID: References: <53F8F620.3090701@gmx.de> <53F989E9.5090701@gmx.net> <53FA5AB4.5030904@gmx.net> <4C3B8A40-F512-47CB-8411-44FD2216DA8F@gmail.com> <4B737628-1401-4B8D-9200-D4F6E2217BB1@gmail.com> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1408989732 15938 80.91.229.3 (25 Aug 2014 18:02:12 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 25 Aug 2014 18:02:12 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBDDM34EO6QDRBG7U5WPQKGQEUX4EHMQ@isocpp.org Mon Aug 25 20:02:07 2014 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-vc0-f198.google.com ([209.85.220.198]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1XLyaj-0002tu-7g for gclcip-std-proposals@m.gmane.org; Mon, 25 Aug 2014 20:02:05 +0200 Original-Received: by mail-vc0-f198.google.com with SMTP id le20sf42210392vcb.9 for ; Mon, 25 Aug 2014 11:02:04 -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:in-reply-to:references:from:date :message-id:subject:to:x-original-sender :x-original-authentication-results:reply-to:precedence:mailing-list :list-id:list-post:list-help:list-archive:list-subscribe :list-unsubscribe:content-type:content-transfer-encoding; bh=c9DYgu3a3knHK/lw/l5KgSWRRN8dNs8NTbQbAQFs164=; b=j9KR4wjVUZDXcNDiG1lQj1zILFJR11WFCOVKA2AhPXR/RPAz5CBkBCvhYICK4mEiqW AkCGQHM4XRRAtSPAYl6StxknmbgSRgqazdZmi8SqHp8Tz52VEHFjXsoqDhEBOPJ1riG7 DfwA41V5UWAYgToGytI0jTPdtedVmXSClBpaK8oSFFWwKVpLECwOGFWI03UnfLCTJu8W CVf6cvqnIBQGU2zGxmivDo1Ke8+qfAJhaBonsbSylE2SZB+h95edWmjQD1vkINSk8LMc 3MZICcYoZOTOO15jwwc0EXIQlDzRpSWRj9PGJauF8qjg9LstEL/vMidK6VDAvBbMSmIV ya2Q== X-Gm-Message-State: ALoCoQnext2JBoeU8/fRnzIou0g+69E71SPLKo834s8D+Kn6pXRtDOjoovUhhZcZG7VhXIrQXNYQ X-Received: by 10.224.127.6 with SMTP id e6mr15164523qas.3.1408989724213; Mon, 25 Aug 2014 11:02:04 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.140.88.203 with SMTP id t69ls2206944qgd.30.gmail; Mon, 25 Aug 2014 11:02:03 -0700 (PDT) X-Received: by 10.52.141.76 with SMTP id rm12mr3995843vdb.71.1408989723266; Mon, 25 Aug 2014 11:02:03 -0700 (PDT) Original-Received: from mail-vc0-x232.google.com (mail-vc0-x232.google.com [2607:f8b0:400c:c03::232]) by mx.google.com with ESMTPS id ip5si378551vcb.52.2014.08.25.11.02.03 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 25 Aug 2014 11:02:03 -0700 (PDT) Received-SPF: pass (google.com: domain of jyasskin@google.com designates 2607:f8b0:400c:c03::232 as permitted sender) client-ip=2607:f8b0:400c:c03::232; Original-Received: by mail-vc0-f178.google.com with SMTP id la4so15863650vcb.9 for ; Mon, 25 Aug 2014 11:02:03 -0700 (PDT) X-Received: by 10.221.62.195 with SMTP id xb3mr6888690vcb.45.1408989723064; Mon, 25 Aug 2014 11:02:03 -0700 (PDT) Original-Received: by 10.52.146.11 with HTTP; Mon, 25 Aug 2014 11:01:42 -0700 (PDT) In-Reply-To: <4B737628-1401-4B8D-9200-D4F6E2217BB1@gmail.com> X-Original-Sender: jyasskin@google.com X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: domain of jyasskin@google.com designates 2607:f8b0:400c:c03::232 as permitted sender) smtp.mail=jyasskin@google.com; dkim=pass header.i=@google.com; dmarc=pass (p=REJECT dis=NONE) header.from=google.com Precedence: list Mailing-list: list std-proposals@isocpp.org; contact std-proposals+owners@isocpp.org List-ID: X-Google-Group-Id: 399137483710 List-Post: , List-Help: , List-Archive: List-Subscribe: , List-Unsubscribe: , X-Original-From: Jeffrey Yasskin Xref: news.gmane.org gmane.comp.lang.c++.isocpp.proposals:12505 Archived-At: On Mon, Aug 25, 2014 at 8:45 AM, Howard Hinnant wrote: > On Aug 25, 2014, at 11:16 AM, Myriachan wrote: > >> On Sunday, August 24, 2014 4:22:35 PM UTC-7, Howard Hinnant wrote: >>> I have a hard time getting excited about hardware that you can't find >>> outside of museum. I do have fond memories of learning the VAX >>> operating system, but that was a very long time ago. However on >>> such a machine std::endian::native has a value that is not equal to >>> either of std::endian::little or std::endian::big. If the HashAlgorith= m >>> specifies little or big endian, the implementation is required to map t= he >>> bytes of the int (or whatever) to little or big endian prior to feeding= it to >>> the HashAlgorithm. For std::endian::big, this is the exact same thing >>> as inserting a call to hton() prior to the HashAlgorithm. >> >> Don't you mean std::endian::little, unless the hash algorithm is, say, M= D5, or the little-endian version of one of the SHA series? (The latter of = which would not make sense in the Standard since they're non-standard, and = the former is deprecated for security reasons.) > > The intended semantics is: > > struct MyHashAlgorithm > { > static constexpr std::endian endian =3D std::endian::big; > // ... > }; > > means: Attention hash_append function: Prior to feeding MyHashAlgorithm = bytes from scalar types, map them (from native) into big endian. So if two= platforms had scalars with identical layout except for endian, the two pla= tforms could generate identical hash codes for identical scalar input. > >> >> Also, I would love to say =A1adi=F3s! to such architectures as well, bec= ause it means signed integer overflow being undefined would have a chance i= n Hell of being removed instead of the current no. Only overzealous compil= er optimizers would be in the way, rather than architectures that'd be left= behind. >.< >> >> Does your design easily templatize into constructions like HMAC? > > I am unsure. > > One can easily build hash functors that can be seeded, for example: > > http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n3980.html#seedin= g > > I.e. you choose a seed (key?) and use that to initialize the HashAlgorith= m. And then the hash functor runs the update and finalization stages in th= e same way as previously shown. > > One could also prepend a message, by updating the HashAlgorithm with a ke= y prior to updating it with the message. Or one could append a message by = updating the HashAlgorithm just prior to running the finalization stage. > > But I am unsure if the abilities of seeding, prepending and appending are= sufficient to generate a HMAC. I think you need a "block size" accessor on cryptographic hashers in order to write the HMAC<> template, since HMAC involves padding the key to the block size. You could write an HMAC_SHA256 without that by hard-coding the block size. --=20 ---=20 You received this message because you are subscribed to the Google Groups "= ISO C++ Standard - Future Proposals" group. To unsubscribe from this group and stop receiving emails from it, send an e= mail to std-proposals+unsubscribe@isocpp.org. To post to this group, send email to std-proposals@isocpp.org. Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa= ls/. .