220 12444 <53F98696.7010909@gmx.net> article Path: news.gmane.org!not-for-mail From: Jens Maurer Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Cryptographic hash functions reloaded [was Interest in cryptographic functions within the standard library] Date: Sun, 24 Aug 2014 08:30:46 +0200 Lines: 63 Approved: news@gmane.org Message-ID: <53F98696.7010909@gmx.net> References: <53F8F620.3090701@gmx.de> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 X-Trace: ger.gmane.org 1408861861 28180 80.91.229.3 (24 Aug 2014 06:31:01 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 24 Aug 2014 06:31:01 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBDPMTYGK64JRBGMN42PQKGQEM4RZCKY@isocpp.org Sun Aug 24 08:30:52 2014 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-we0-f198.google.com ([74.125.82.198]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1XLRKF-0004EM-8P for gclcip-std-proposals@m.gmane.org; Sun, 24 Aug 2014 08:30:51 +0200 Original-Received: by mail-we0-f198.google.com with SMTP id x48sf7370855wes.5 for ; Sat, 23 Aug 2014 23:30:50 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-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; bh=esi/CBWdOEqGGce9zsswuqhCLw082S5sagI0grtWb3A=; b=AAgRp4R/IcpynDqzi19BePkVT935xP6KTZbuhRltbMM36Yq9UiAlok12st4ASuKNFe vaN3IgQsP7wPDpUuVhmJnWdV1xCnK4PbygBD3g8KCSw/TZDueupiihl7I4NNUm9RbcCo lrCO7kJO47QrYKcntNME8plzaaLY5sMaXAswzZTtSRrMRRyLb4PGTIQaboiADgCzdtnB E4//N/bX3YeeOqAq2o/FDnQaanCRUk/WJbpJ1GB3u4nFyIIlDCMoZYX60BHK4pPqNcDk 8peqjfjh3K+iNQudt624coVKLR5uu7i4gRS/v1TxwnBd8oSSzZxw8byTijCjH3PTL6n7 He2A== X-Gm-Message-State: ALoCoQnzoRjd4UxTzO1KEpa4UqgehVobZAdWmo98hIRQ+o79R/Lw9KT912A7cSMI/Fc3nuRRhOJ9 X-Received: by 10.180.8.1 with SMTP id n1mr6559wia.1.1408861850660; Sat, 23 Aug 2014 23:30:50 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.152.6.38 with SMTP id x6ls308354lax.75.gmail; Sat, 23 Aug 2014 23:30:48 -0700 (PDT) X-Received: by 10.152.27.2 with SMTP id p2mr13773940lag.23.1408861848637; Sat, 23 Aug 2014 23:30:48 -0700 (PDT) Original-Received: from mout.gmx.net (mout.gmx.net. [212.227.15.18]) by mx.google.com with ESMTPS id m8si6402521lbd.8.2014.08.23.23.30.48 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 23 Aug 2014 23:30:48 -0700 (PDT) Received-SPF: pass (google.com: domain of Jens.Maurer@gmx.net designates 212.227.15.18 as permitted sender) client-ip=212.227.15.18; Original-Received: from [192.168.2.100] ([178.7.39.200]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0Lpspj-1Wj5hA3FYt-00fg1W for ; Sun, 24 Aug 2014 08:30:47 +0200 User-Agent: Mozilla/5.0 (X11; Linux i686; rv:6.0.1) Gecko/20110830 Thunderbird/6.0.1 In-Reply-To: <53F8F620.3090701@gmx.de> X-Provags-ID: V03:K0:B5tn/SlEog2AEquOiC8Mq46eZtZBkHgsSOsUZf3LfDsWjKuSQVQ XuDG2q3PHNVMvvlLYjMzHuCbKBqFMP1Hci180T2/j4TAd/EL+ypphykqw5sLROJMeyc/4y4 TdM0V9D6zEux3nOWt6smZTmJ4Ust9lNiTzWDYyJqbAu50koSRLJZRPzYERUAkqfWr3V5KUg T5m2JXJh+3YVCHpL/HHTQ== X-UI-Out-Filterresults: notjunk:1; X-Original-Sender: Jens.Maurer@gmx.net X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: domain of Jens.Maurer@gmx.net designates 212.227.15.18 as permitted sender) smtp.mail=Jens.Maurer@gmx.net 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: , Xref: news.gmane.org gmane.comp.lang.c++.isocpp.proposals:12444 Archived-At: On 08/23/2014 10:14 PM, Markus Mayer wrote: > -Why 'unsigned char' and not 'uint8_t' for result_type? > Most hash algorithms work on an 8 bit basis. But as long as unsigned > char has a multiple of 8 bits, the algorithms can still be applied. So > 'unsigned char' enables those architectures to implement the functions. > Architectures where 'unsigned char' is not a multiple of 8 bits will be > excluded by the proposal. If you specify that a hash function operates on octets, i.e. 8-bit quantities (I believe all them do), then it seems ok to have a 9-bit unsigned char, whose top bit will always be zero. Conversion from object representation to octets is a separate issue. > -Why not implement operator()? > Having a function (with a name) is more vocal (and clear) then just > braces. IMHO Operator() is only useful if the object will be used as a > functor (as in std::less). But the signature is to uncommon to be used > in any standard algorithm. But I'm willing to change if someone came up > with a good example. In my opinion, a hash is a function object and should have operator(). > Open topics: > -How to handle the large state of a hash function? > Hash function can have a large internal state (64 Byte for sha2, 200 > Byte for sha3) is it OK to put such objects on the stack, or do we need > to allocate them dynamically (using allocators)? No, you've got constant state size. Putting 200 bytes on the stack is totally ok; implementations where that isn't are free to use another strategy. > -How to hash a files? > Hashing a file is quite common. As the iterator interface was removed, > there is no easy way to hash a file (using istream_iterator). How to do > it now? It's certainly possible to provide a generic wrapper template that converts from input iterators to byte buffers, i.e. template void process(H&, InputIterator first, InputIterator last); > -Should we only add some crc classes (like crc_32, crc_16 or crc_ccitt) > or a an generic (templated) crc algorithm (like in boost:crc)? Yes, please add crc32c at least. Intel has a special instruction for it that we should make easily usable. > -Add 'nothrow' where applicable noexcept Jens -- --- 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 email 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-proposals/. .