220 12449 <53F9AAF7.8030602@gmx.de> article Path: news.gmane.org!not-for-mail From: Markus Mayer 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 11:05:59 +0200 Lines: 136 Approved: news@gmane.org Message-ID: <53F9AAF7.8030602@gmx.de> 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; format=flowed X-Trace: ger.gmane.org 1408871171 20772 80.91.229.3 (24 Aug 2014 09:06:11 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 24 Aug 2014 09:06:11 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBDL3H4GM24GBB6OV42PQKGQE7WIFAEI@isocpp.org Sun Aug 24 11:06:04 2014 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-wg0-f72.google.com ([74.125.82.72]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1XLTkQ-0001Z0-GI for gclcip-std-proposals@m.gmane.org; Sun, 24 Aug 2014 11:06:02 +0200 Original-Received: by mail-wg0-f72.google.com with SMTP id b13sf7382993wgh.3 for ; Sun, 24 Aug 2014 02:06:02 -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=kpH/SqaJ14XKxtYuD3q32idD22uPV69TGQpGTa3WJZE=; b=kjJAVxpaLHOUPgbPWjwCeNiuHzAEbZPRirV5x1MRQvfVtiyidGEAcOZNx3s3nFB1xy 6n1nTnfHdshQ7r8eftA4x2B0MDbssrbcjufOXMou11zjB+HkruYe8kOmagME12vn7NCi +DM9MbQARDVlaoJ3cVc8MryamJHO74FZwaKUObc20XmA+KBKCfHqjS4ubQwm0umhrvQN asmJbXF1En0LmC8JtQmEOUcqccJdg1oVQ+x7j33WZmcSZmhdUY8wOlibtbaUemXQDaU+ nLvv6inOmVjuDODeVIa+UpSW2oDihrSLw/VzisbTDCqtncz/iQMVDw7fX5XTRYtIr8ve vmsg== X-Gm-Message-State: ALoCoQmaKEMIKbSeEZtllxc26CsykusKqoh0cNYAKXR+1jF+Tg0MsTZJ14Y//HdHoHdhEBu8leRT X-Received: by 10.152.243.33 with SMTP id wv1mr1269326lac.2.1408871162046; Sun, 24 Aug 2014 02:06:02 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.152.21.137 with SMTP id v9ls331511lae.7.gmail; Sun, 24 Aug 2014 02:06:00 -0700 (PDT) X-Received: by 10.152.5.42 with SMTP id p10mr1009659lap.82.1408871160635; Sun, 24 Aug 2014 02:06:00 -0700 (PDT) Original-Received: from mout.gmx.net (mout.gmx.net. [212.227.17.20]) by mx.google.com with ESMTPS id ua5si24691066lbb.105.2014.08.24.02.06.00 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 24 Aug 2014 02:06:00 -0700 (PDT) Received-SPF: pass (google.com: domain of lotharlutz@gmx.de designates 212.227.17.20 as permitted sender) client-ip=212.227.17.20; Original-Received: from [192.168.178.22] ([92.194.36.58]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0MS1g6-1WtSCT3cvS-00TFC8 for ; Sun, 24 Aug 2014 11:05:59 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.7.0 In-Reply-To: <53F8F620.3090701@gmx.de> X-Provags-ID: V03:K0:OOnOEeHdoM3MgR8uvnveCtXNvQaX9hNvGawkPiXA82xz5hZKMgI W+GKY2OojUBr3BKZpjQL//CYtIgZngt7bqgHZsctDDGf6x5pPbeWCngQtmWseGJgPKUPkNs F4d9q3t2kyntcQnc6mwIWOgHDRxSqg/3/Yn7DPuKeOKpERnnUI8Yd8Kr0NU28gi2CN0mRh4 1npOJjW78FYv4pwW4OMMQ== X-UI-Out-Filterresults: notjunk:1; X-Original-Sender: lotharlutz@gmx.de X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: domain of lotharlutz@gmx.de designates 212.227.17.20 as permitted sender) smtp.mail=lotharlutz@gmx.de 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:12449 Archived-At: Thanks for all your feedback. Here comes the new version... Changes: -Add operator() -Make hash_value() const and return a value -Remove question if a allocator is needed. It is not. -Rename 'nothrow' to 'noexcept' -Add a rational for operator() -Rewrite 'Why 'unsigned char' and not 'uint8_t' for result_type?' New open questions: -Should we add an overload for 'signed char' and 'char' also? Design: class hash_function { public: typedef std::array result_type; //Default contructable //Copyable //Moveable hash_function& process_bytes( void unsigned char *buffer, std::size_t byte_count); hash_function& operator() ( void unsigned char *buffer, std::size_t byte_count); void reset(); result_type hash_value() const; }; //I am not sure about this function yet... template typename hash::result_type calculate_hash(void const *buffer, std::size_t byte_count); The implemented algorithms will be (the class name is given in the list): -md5 -sha_1 -sha_224 -sha_256 -sha_384 -sha_512 -sha3_224 -sha3_256 -sha3_384 -sha3_512 -Various flavors of crc Rational: -Why 'result_type'? To be consistent with std::function. And the name fits pretty good anyway. -Why 'unsigned char' and not 'uint8_t' for result_type? Most hash algorithms work on an 8 bit basis. But they can often by implemented on odd-sized architectures as well. As such architectures often uses freestanding implementations, they are also free to not implement it. -Why 'unsigned char' and not 'char' for result_type? It is to prevent, that people think that the result is a text(string). Furthermore if I interpret a raw byte it is always positive. Or do you interpret 0xFF as -128 when it is given in a raw byte stream. -Why 'process_bytes' and not 'write', 'update', ...? Well, naming is hard. I will stick to 'process_bytes' during design, but I'm open to suggestions. -Why operator()? To allow the usage of hash functions as function objects. -Why not rename 'hash_value' to result_type()? What do you prefer? auto result = myHash.hash_value; or auto result = static_cast(myHash); -Why 'sha_512' and not 'sha2_512'? 'sha_512' is the official name for the algorithm. I know it is bad, but better be consistent. -Why not add an iterator based process_bytes? For now I consider it to complex. -Why not add/delete algorithm XXX? I think these are the most common. But I am open to suggestions. -Why not use the naming of 'N3980: Types Don't Know #'? Is already discussed above. Open topics: -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? -Sync with 'Types Don't Know #' -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)? -Add 'noexcept' where applicable -More naming discussions -Find a suitable header file (maybe functional or algorithm) regards Markus -- --- 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/. -- --- 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/. .