On 01/22/2014 04:43 PM, Markus Mayer wrote:
> In one of my projects I rely on hash functions (eg. md5) to do some
> checksum calculations. As those function are (supposedly) quite common,
> I think it would be beneficial to include them into the standard library.
>
> As hash functions are only a small part within cryptography, maybe other
> functions should be included as well.
>
> But before starting to come up with a proposal I want to hear some
> opinions if there is a/no need for such functions.
>
> I think the following categories maybe relevant to include:
> - Hash functions (md5, sha1, ...)
> - Symmetric ciphers (aes, ...)
> - Encryption modes (cbc, ecb, ...)
> - Secure random number generation
> - Asymmetric ciphers (RSA, ...)
> - Signing functions
> - Password derivation functions (PBKDF2, bcrypt, scrypt)
> - message authentication code functions (hmac, ...)
> - padding schemes (PKCS7, ...)
> - Key exchange (DH)
> - Have I missed something?
>
>
> regards
>    Markus
>

Based on the feedback given on the mailing list, I've created a first
draft of my proposal. By now it just contains information for hash
functions.

It is far from being complete, but I post it to gain additional feedback.

https://github.com/markus-mayer/std-crypto/blob/master/proposal/proposal.pdf


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/.

.

On Wed, Jan 29, 2014 at 10:54 PM, Markus Mayer <lotharlutz@gmx.de> wrote:
> Based on the feedback given on the mailing list, I've created a first draft
> of my proposal. By now it just contains information for hash functions.
>
> It is far from being complete, but I post it to gain additional feedback.
>
> https://github.com/markus-mayer/std-crypto/blob/master/proposal/proposal.pdf

> A single byte is represented as an usinged char.

Wouldn't uint8_t be a better type?

I think it's better to create a proposal based on an existing widely
used library, perhaps you should start with a library and then (later)
create a proposal.

--

---
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/.

.

On 01/29/2014 10:54 PM, Markus Mayer wrote:
> Based on the feedback given on the mailing list, I've created a first
> draft of my proposal. By now it just contains information for hash
> functions.
>
> It is far from being complete, but I post it to gain additional feedback.
>
> https://github.com/markus-mayer/std-crypto/blob/master/proposal/proposal.pdf

Suggestions:

  - rename process_bytes() to operator()

  - Remove the "unsigned char" variant; if someone needs it, it can be
emulated with the (const void *, size_t) overload.  Nobody should use
cryptographic hash functions in a byte-at-a-time approach.

  - You should say somewhere that the value_type of IterType must be
"unsigned char".

 - The choice is either "unsigned char" or "uint8_t".  Thanks for expressly
excluding "char".  "uint8_t" might not be available on some implementations
that lack an exactly-8-bit type.  "unsigned char" might be larger than 8 bits.
For the latter case, you need to say what happens.

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/.

.

------=_Part_309_5498392.1391066718246
Content-Type: text/plain; charset=UTF-8

On Wednesday, January 29, 2014 4:58:06 PM UTC-5, Olaf van der Spek wrote:

> On Wed, Jan 29, 2014 at 10:54 PM, Markus Mayer <lotha...@gmx.de<javascript:>>
> wrote:
> > Based on the feedback given on the mailing list, I've created a first
> draft
> > of my proposal. By now it just contains information for hash functions.
> >
> > It is far from being complete, but I post it to gain additional
> feedback.
> >
> >
> https://github.com/markus-mayer/std-crypto/blob/master/proposal/proposal.pdf
>
> > A single byte is represented as an usinged char.
>
> Wouldn't uint8_t be a better type?
>
> Not every system uses octet-sized bytes. There's no need to hard-wire the
common 8/16/32(/64)-bit assumption. However, 9-bit byte mainframes have
fallen aside for DSP chips making everything 16/32-bit for efficiency (I
think) in terms of odd-ball byte sizes.

Daryle W.

--

---
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/.

------=_Part_309_5498392.1391066718246
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Wednesday, January 29, 2014 4:58:06 PM UTC-5, Olaf van =
der Spek wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin: 0;mar=
gin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On Wed, Jan=
 29, 2014 at 10:54 PM, Markus Mayer &lt;<a href=3D"javascript:" target=3D"_=
blank" gdf-obfuscated-mailto=3D"GgN0V29UuvIJ" onmousedown=3D"this.href=3D'j=
avascript:';return true;" onclick=3D"this.href=3D'javascript:';return true;=
">lotha...@gmx.de</a>&gt; wrote:
<br>&gt; Based on the feedback given on the mailing list, I've created a fi=
rst draft
<br>&gt; of my proposal. By now it just contains information for hash funct=
ions.
<br>&gt;
<br>&gt; It is far from being complete, but I post it to gain additional fe=
edback.
<br>&gt;
<br>&gt; <a href=3D"https://github.com/markus-mayer/std-crypto/blob/master/=
proposal/proposal.pdf" target=3D"_blank" onmousedown=3D"this.href=3D'https:=
//www.google.com/url?q\75https%3A%2F%2Fgithub.com%2Fmarkus-mayer%2Fstd-cryp=
to%2Fblob%2Fmaster%2Fproposal%2Fproposal.pdf\46sa\75D\46sntz\0751\46usg\75A=
FQjCNGxWcjvAqy2P5XlQM1O6HYf8-pbpw';return true;" onclick=3D"this.href=3D'ht=
tps://www.google.com/url?q\75https%3A%2F%2Fgithub.com%2Fmarkus-mayer%2Fstd-=
crypto%2Fblob%2Fmaster%2Fproposal%2Fproposal.pdf\46sa\75D\46sntz\0751\46usg=
\75AFQjCNGxWcjvAqy2P5XlQM1O6HYf8-pbpw';return true;">https://github.com/mar=
kus-<wbr>mayer/std-crypto/blob/master/<wbr>proposal/proposal.pdf</a>
<br>
<br>&gt; A single byte is represented as an usinged char.
<br>
<br>Wouldn't uint8_t be a better type?
<br><br></blockquote><div>Not every system uses octet-sized bytes. There's =
no need to hard-wire the common 8/16/32(/64)-bit assumption. However, 9-bit=
 byte mainframes have fallen aside for DSP chips making everything 16/32-bi=
t for efficiency (I think) in terms of odd-ball byte sizes.</div><div><br><=
/div><div>Daryle W.</div><div><br></div></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_309_5498392.1391066718246--

.

On 01/29/2014 10:58 PM, Olaf van der Spek wrote:
> On Wed, Jan 29, 2014 at 10:54 PM, Markus Mayer <lotharlutz@gmx.de> wrote:
>> Based on the feedback given on the mailing list, I've created a first draft
>> of my proposal. By now it just contains information for hash functions.
>>
>> It is far from being complete, but I post it to gain additional feedback.
>>
>> https://github.com/markus-mayer/std-crypto/blob/master/proposal/proposal.pdf
>
>> A single byte is represented as an usinged char.
>
> Wouldn't uint8_t be a better type?
AFAIK a char is defined as at least 8 bits and the smallest available type.

This concludes to "If uint8_t is available, char must have 8 bits".

Please correct me if I'm wrong.

I prefer unsigned char, because it is much more common inside the
standard library than uint8_t.

>
> I think it's better to create a proposal based on an existing widely
> used library, perhaps you should start with a library and then (later)
> create a proposal.
>

You're right it is not based on _one_ library.
The proposal is based on the OpenSSL, libgcrypt, Crypto++ (to a lesser
amount) and boost:crc(only for hash functions), which I would call
'widely used'.

But as OpenSSL and libgcrypt have rather similar API, you could call it
OpenSSL/libgcrypt based.



--

---
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/.

.

On 01/29/2014 11:59 PM, Jens Maurer wrote:
> On 01/29/2014 10:54 PM, Markus Mayer wrote:
>> Based on the feedback given on the mailing list, I've created a first
>> draft of my proposal. By now it just contains information for hash
>> functions.
>>
>> It is far from being complete, but I post it to gain additional feedback.
>>
>> https://github.com/markus-mayer/std-crypto/blob/master/proposal/proposal.pdf
>
> Suggestions:
>
>    - rename process_bytes() to operator()
I prefer process_bytes(), because it is much more verbal.
I will add operator() as an additional way to do it.

>
>    - Remove the "unsigned char" variant; if someone needs it, it can be
> emulated with the (const void *, size_t) overload.  Nobody should use
> cryptographic hash functions in a byte-at-a-time approach.
>

I will remove the overload for now. (But maybe add it later on, if I
find a need for it)

>    - You should say somewhere that the value_type of IterType must be
> "unsigned char".
>

Got catch. I will add a requirement like sizeof(IterType::value_type) ==
sizeof(unsigned char)[ == 1]
This will allow to pass an std::string, without signed/unsigned
conversion warnings.

>   - The choice is either "unsigned char" or "uint8_t".  Thanks for expressly
> excluding "char".  "uint8_t" might not be available on some implementations
> that lack an exactly-8-bit type.  "unsigned char" might be larger than 8 bits.
> For the latter case, you need to say what happens.
>
> Jens
>
>
For now I will just state that it is only available on architectures
that provides an 8-bit type.

--

---
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/.

.

On Wed, Jan 29, 2014 at 10:54 PM, Markus Mayer <lotharlutz@gmx.de> wrote:
>
> Based on the feedback given on the mailing list, I've created a first draft
> of my proposal. By now it just contains information for hash functions.
>
> It is far from being complete, but I post it to gain additional feedback.
>
> https://github.com/markus-mayer/std-crypto/blob/master/proposal/proposal.pdf

Personally, I don't know whether I would trust _all_ the C++ vendors
to provide high quality implementations for such cryptographic
primitives and protocols. Relying on that seems like a bit of a risk
especially if your portable software that uses "std::crypto" gets
compiled with a toolchain that did not open source their crypto
implementation. I could not care less about how std::regex is
implemented, but for cryptographic primitives and protocols this is a
very different story. It's just to easy to screw things up and to leak
secrets and it just takes one vendor to make a mistake. so, basically,
std::crypto is only as good as the weakest link in the C++ vendor's
implementations. And don't get me started on random number generators.

Anyhow, I thought you might appreciate the following link:

https://cryptocoding.net/index.php/References

As for your proposal, you write "A hash function is any algorithm that
maps data of arbitrary length to data of a fixed length." This is not
strictlly true (anymore). For example, some of the SHA-3 submissions
(including the winner Keccak) offer an output of arbitrary length
which is _very_ useful in many applications (full domain hashing, mask
generation).

On Wed, Jan 29, 2014 at 10:58 PM, Olaf van der Spek <olafvdspek@gmail.com>
> Wouldn't uint8_t be a better type?

I don't think so. unsigned char is very popular among existing crypto
libraries. It's the "smallest type" that is both (1) guaranteed to
exist and (2) able to store octets. And even if unsigned char has more
than 8 value bits, only the values of 0-255 are (should be) used.

Cheers!
sg

--

---
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/.

.

On Thu, Jan 30, 2014 at 10:39 AM, Markus Mayer <lotharlutz@gmx.de> wrote:
>> I think it's better to create a proposal based on an existing widely
>> used library, perhaps you should start with a library and then (later)
>> create a proposal.
>>
>
> You're right it is not based on _one_ library.
> The proposal is based on the OpenSSL, libgcrypt, Crypto++ (to a lesser
> amount) and boost:crc(only for hash functions), which I would call 'widely
> used'.
>
> But as OpenSSL and libgcrypt have rather similar API, you could call it
> OpenSSL/libgcrypt based.

That's good, but IMO having an actual implementation to experiment
with would be even better.


On Thu, Jan 30, 2014 at 10:48 AM, Markus Mayer <lotharlutz@gmx.de> wrote:
> I prefer process_bytes(), because it is much more verbal.
> I will add operator() as an additional way to do it.

What about write instead of process_bytes?


On Fri, Jan 31, 2014 at 12:40 PM, Sebastian Gesemann
<s.gesemann@gmail.com> wrote:
> I don't think so. unsigned char is very popular among existing crypto
> libraries. It's the "smallest type" that is both (1) guaranteed to
> exist and (2) able to store octets. And even if unsigned char has more
> than 8 value bits, only the values of 0-255 are (should be) used.

If it works when char has more than 8 bits then unsigned char seems
the right choice.

--
Olaf

--

---
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/.

.

On Wed, Jan 29, 2014 at 10:54 PM, Markus Mayer <lotharlutz@gmx.de> wrote:
> It is far from being complete, but I post it to gain additional feedback.

Chaining for process_bytes would also be nice. Could you return *this?

--
Olaf

--

---
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/.

.

On 01/31/2014 12:40 PM, Sebastian Gesemann wrote:
> On Wed, Jan 29, 2014 at 10:54 PM, Markus Mayer <lotharlutz@gmx.de> wrote:
>>
>> Based on the feedback given on the mailing list, I've created a first draft
>> of my proposal. By now it just contains information for hash functions.
>>
>> It is far from being complete, but I post it to gain additional feedback.
>>
>> https://github.com/markus-mayer/std-crypto/blob/master/proposal/proposal.pdf
>
> Personally, I don't know whether I would trust _all_ the C++ vendors
> to provide high quality implementations for such cryptographic
> primitives and protocols. Relying on that seems like a bit of a risk
> especially if your portable software that uses "std::crypto" gets
> compiled with a toolchain that did not open source their crypto
> implementation. I could not care less about how std::regex is
> implemented, but for cryptographic primitives and protocols this is a
> very different story. It's just to easy to screw things up and to leak
> secrets and it just takes one vendor to make a mistake. so, basically,
> std::crypto is only as good as the weakest link in the C++ vendor's
> implementations. And don't get me started on random number generators.
>
> Anyhow, I thought you might appreciate the following link:
>
> https://cryptocoding.net/index.php/References
>

Thanks for the link. It's a really interesting reading.

I think for most users their toolchain implementation will be
good/secure enough. They neither have the knowledge to judge the secrecy
of an implementation nor have interest in it. The mostly chose their
implementation/library on the API rather on the implementation.

'Paranoid' users can still dictate what toolchain to use, or can use a
trusted drop-in replacement.

Regarding random number generators: As long as you don't have trusted
hardware and a trusted os, you are lost anyway.

> As for your proposal, you write "A hash function is any algorithm that
> maps data of arbitrary length to data of a fixed length." This is not
> strictlly true (anymore). For example, some of the SHA-3 submissions
> (including the winner Keccak) offer an output of arbitrary length
> which is _very_ useful in many applications (full domain hashing, mask
> generation).
>

I think most people will use sha3_512 and others. If output of arbitrary
length is worth standardization must be discussed.


> On Wed, Jan 29, 2014 at 10:58 PM, Olaf van der Spek <olafvdspek@gmail.com>
>> Wouldn't uint8_t be a better type?
>
> I don't think so. unsigned char is very popular among existing crypto
> libraries. It's the "smallest type" that is both (1) guaranteed to
> exist and (2) able to store octets. And even if unsigned char has more
> than 8 value bits, only the values of 0-255 are (should be) used.
>
> Cheers!
> sg
>

--

---
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/.

.

On 02/01/2014 05:04 PM, Olaf van der Spek wrote:
> On Wed, Jan 29, 2014 at 10:54 PM, Markus Mayer <lotharlutz@gmx.de> wrote:
>> It is far from being complete, but I post it to gain additional feedback.
>
> Chaining for process_bytes would also be nice. Could you return *this?
>

I have Incorporated your feedback into the proposal.

https://github.com/markus-mayer/std-crypto/blob/master/proposal/proposal.pdf

I also created a sample implementation based on libgcrypt and a small
test application.

https://github.com/markus-mayer/std-crypto/blob/master/include/hash.hpp
https://github.com/markus-mayer/std-crypto/blob/master/src/test_hash.cpp

There is still an open question, which I am not sure about:
- What is better: sha<512> or sha512?

There are other open question, but I think it makes more sens to discuss
them when the whole proposal is drafted:
- Naming
- Namespaces/Header files

--

---
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/.

.

On 2014-02-10 17:07, Markus Mayer wrote:
> There is still an open question, which I am not sure about:
> - What is better: sha<512> or sha512?

MHO: If you can reasonably implement sha512 like sha_impl(..., 512),
then sha<512> is good. If the implementation is non-trivially different,
stick with e.g. sha512.

Note also you may want to use sha2_512 instead :-).

--
Matthew

--

---
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/.

.

On Mon, Feb 10, 2014 at 11:07 PM, Markus Mayer <lotharlutz@gmx.de> wrote:
> I have Incorporated your feedback into the proposal.

Thanks.
What about write instead of process_bytes?

Your assignment operator should return *this too.

> for (; bytes_begin != bytes_end; bytes_begin++ )

A range-based for loop?

--

---
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/.

.

On 02/10/2014 11:27 PM, Olaf van der Spek wrote:
> On Mon, Feb 10, 2014 at 11:07 PM, Markus Mayer <lotharlutz@gmx.de> wrote:
>> I have Incorporated your feedback into the proposal.
>
> Thanks.
> What about write instead of process_bytes?

I don't favor write, because if I 'write' something it someone must be
able to read somewhere else.
Maybe some examples make it clear.

If I write to a file, I can read it again from that file.
If I write to std:cout, the user can read it from the console.
If I write to a socket, the other site can read it.
But if I write to a hash function, there is no way to retrieve the
original data from the function.

>
> Your assignment operator should return *this too.
>
fixed

>> for (; bytes_begin != bytes_end; bytes_begin++ )
>
> A range-based for loop?
>

AFAIK a range-based for loop can not be used on a pair of iterators
directly.

--

---
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/.

.

On Mon, Feb 10, 2014 at 11:46 PM, Markus Mayer <lotharlutz@gmx.de> wrote:
> But if I write to a hash function, there is no way to retrieve the original
> data from the function.

True, but not having a read function doesn't mean that this isn't like
a write function.

>>> for (; bytes_begin != bytes_end; bytes_begin++ )
>>
>>
>> A range-based for loop?
>>
>
> AFAIK a range-based for loop can not be used on a pair of iterators
> directly.

Oops. Though I think this byte at a time hashing shouldn't be part of
the interface.

--

---
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/.

.

Em seg 10 fev 2014, =E0s 23:07:03, Markus Mayer escreveu:
> On 02/01/2014 05:04 PM, Olaf van der Spek wrote:
> > On Wed, Jan 29, 2014 at 10:54 PM, Markus Mayer <lotharlutz@gmx.de> wrot=
e:
> >> It is far from being complete, but I post it to gain additional feedba=
ck.
> >=20
> > Chaining for process_bytes would also be nice. Could you return *this?
>=20
> I have Incorporated your feedback into the proposal.
>=20
> https://github.com/markus-mayer/std-crypto/blob/master/proposal/proposal.=
pdf

Hello Markus

That looks interesting.

I'm not sure I like the iterator-based API. It means it's way too easy for=
=20
people to shoot themselves on the foot. If you do:

 std::string data; // or std::vector<char>
 sha1 hash;
 hash.process_bytes(data.cbegin(), data.cend());

It will process a contiguous range of bytes byte-by-byte, which is horribly=
=20
inefficient. Not only will it make function calls for each byte, most=20
implementations can actually operate faster if you provide a bigger range.=
=20
Hashing a non-contiguous range is probably going to be an extreme corner ca=
se=20
and it might be acceptable to require people to write their own loops.

If you keep them, you should also add wording that IterType::value must be=
=20
unsigned char, char or signed char, in addition to the static_assert.

May I also suggest a static function that processes a sequence of bytes and=
=20
returns the result? It's quite useful in many contexts and it can probably =
be=20
implemented inline. Or even as a free function. Looking at the uses of=20
QCryptographicHash in Qt, this is the distribution:

 (non-static) QCryptographicHash::addBytes: 0
 (static) QCryptographicHash::hash: 10

> I also created a sample implementation based on libgcrypt and a small
> test application.
>=20
> https://github.com/markus-mayer/std-crypto/blob/master/include/hash.hpp
> https://github.com/markus-mayer/std-crypto/blob/master/src/test_hash.cpp
>=20
> There is still an open question, which I am not sure about:
> - What is better: sha<512> or sha512?

See my other email. But since the number of digits is not free, I don't thi=
nk=20
you should make it a template parameter. I can't do
 sha<1024>
 sha<999>

Those algorithms don't exist. There are exactly 4 hash lengths standardised=
=20
for both SHA-2 and SHA-3.

I also recommend rectifying a past failure to foresee the future and naming=
=20
the SHA-2 algorithms with "sha2" in the name. That also makes it clear abou=
t=20
SHA-3, which your proposal failed to include.

> There are other open question, but I think it makes more sens to discuss
> them when the whole proposal is drafted:
> - Naming
> - Namespaces/Header files

And which algorithms must be implemented.

--=20
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

--=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/.

.

--f46d043c06be11eda304f217fad3
Content-Type: text/plain; charset=ISO-8859-1

On 10 February 2014 18:31, Thiago Macieira <thiago@macieira.org> wrote:

>
> I'm not sure I like the iterator-based API. It means it's way too easy for
> people to shoot themselves on the foot. If you do:
>
>         std::string data; // or std::vector<char>
>         sha1 hash;
>         hash.process_bytes(data.cbegin(), data.cend());
>
> It will process a contiguous range of bytes byte-by-byte, which is horribly
> inefficient.


Not if N3884<http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2014/n3884.pdf>passes.
 You could most certainly optimize it based on the type of iterator.
--
 Nevin ":-)" Liber  <mailto:nevin@eviloverlord.com>  (847) 691-1404

--

---
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/.

--f46d043c06be11eda304f217fad3
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On 10 February 2014 18:31, Thiago Macieira <span dir=3D"lt=
r">&lt;<a href=3D"mailto:thiago@macieira.org" target=3D"_blank">thiago@maci=
eira.org</a>&gt;</span> wrote:<br><div class=3D"gmail_extra"><div class=3D"=
gmail_quote">

<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><br>
I&#39;m not sure I like the iterator-based API. It means it&#39;s way too e=
asy for<br>
people to shoot themselves on the foot. If you do:<br>
<br>
=A0 =A0 =A0 =A0 std::string data; // or std::vector&lt;char&gt;<br>
=A0 =A0 =A0 =A0 sha1 hash;<br>
=A0 =A0 =A0 =A0 hash.process_bytes(data.cbegin(), data.cend());<br>
<br>
It will process a contiguous range of bytes byte-by-byte, which is horribly=
<br>
inefficient.</blockquote><div><br></div><div>Not if <a href=3D"http://www.o=
pen-std.org/JTC1/SC22/WG21/docs/papers/2014/n3884.pdf">N3884</a> passes. =
=A0You could most certainly optimize it based on the type of iterator.</div=
>

</div>-- <br>=A0Nevin &quot;:-)&quot; Liber=A0 &lt;mailto:<a href=3D"mailto=
:nevin@eviloverlord.com" target=3D"_blank">nevin@eviloverlord.com</a>&gt;=
=A0 (847) 691-1404
</div></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--f46d043c06be11eda304f217fad3--

.

On Tue, Feb 11, 2014 at 3:11 AM, Nevin Liber <nevin@eviloverlord.com> wrote:
> Not if N3884 passes.  You could most certainly optimize it based on the type
> of iterator.

Then array_view<unsigned char> looks like the right type, perhaps with
overloads for char and signed char.

--
Olaf

--

---
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/.

.

On Tue, Feb 11, 2014 at 1:31 AM, Thiago Macieira <thiago@macieira.org> wrote:
> May I also suggest a static function that processes a sequence of bytes and
> returns the result? It's quite useful in many contexts and it can probably be
> implemented inline. Or even as a free function. Looking at the uses of
> QCryptographicHash in Qt, this is the distribution:
>
>         (non-static) QCryptographicHash::addBytes: 0
>         (static) QCryptographicHash::hash: 10

hash_function<>().process_bytes(...).hash_value() ?

or

hash_function<>()(...).hash_value() ?

--

---
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/.

.

Em ter 11 fev 2014, =E0s 09:35:25, Olaf van der Spek escreveu:
> On Tue, Feb 11, 2014 at 1:31 AM, Thiago Macieira <thiago@macieira.org>=20
wrote:
> > May I also suggest a static function that processes a sequence of bytes
> > and
> > returns the result? It's quite useful in many contexts and it can proba=
bly
> > be implemented inline. Or even as a free function. Looking at the uses =
of>=20
> > QCryptographicHash in Qt, this is the distribution:
> >         (non-static) QCryptographicHash::addBytes: 0
> >         (static) QCryptographicHash::hash: 10
>=20
> hash_function<>().process_bytes(...).hash_value() ?
>=20
> or
>=20
> hash_function<>()(...).hash_value() ?

It's just verbose. Since it doesn't cost anything to do:

 hash_function<sha1>::hash_value(data);

I believe it should be done.

Though... that might be against the design philosophy for the Standard=20
Library. More experienced people, please correct me.

--=20
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

--=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/.

.

On Tue, Feb 11, 2014 at 7:08 PM, Thiago Macieira <thiago@macieira.org> wrote:
>> hash_function<>()(...).hash_value() ?
>
> It's just verbose. Since it doesn't cost anything to do:
>
>         hash_function<sha1>::hash_value(data);
>
> I believe it should be done.

Verbose? Are you talking about the 3 extra chars my solution requires?

--

---
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/.

.

On 02/11/2014 01:31 AM, Thiago Macieira wrote:
> Em seg 10 fev 2014, =E0s 23:07:03, Markus Mayer escreveu:
>> On 02/01/2014 05:04 PM, Olaf van der Spek wrote:
>>> On Wed, Jan 29, 2014 at 10:54 PM, Markus Mayer <lotharlutz@gmx.de> wrot=
e:
>>>> It is far from being complete, but I post it to gain additional feedba=
ck.
>>>
>>> Chaining for process_bytes would also be nice. Could you return *this?
>>
>> I have Incorporated your feedback into the proposal.
>>
>> https://github.com/markus-mayer/std-crypto/blob/master/proposal/proposal=
..pdf
>
> Hello Markus
>
> That looks interesting.
>
> I'm not sure I like the iterator-based API. It means it's way too easy fo=
r
> people to shoot themselves on the foot. If you do:
>
>  std::string data; // or std::vector<char>
>  sha1 hash;
>  hash.process_bytes(data.cbegin(), data.cend());
>
> It will process a contiguous range of bytes byte-by-byte, which is horrib=
ly
> inefficient. Not only will it make function calls for each byte, most
> implementations can actually operate faster if you provide a bigger range=
..
> Hashing a non-contiguous range is probably going to be an extreme corner =
case
> and it might be acceptable to require people to write their own loops.
>

AFAIK Most hash functions use a fixed sized internal buffer/block the=20
input is copied to. So if the compiler is able to optimize=20
std::copy{_n}, the performance should be equal to the other variant.

> If you keep them, you should also add wording that IterType::value must b=
e
> unsigned char, char or signed char, in addition to the static_assert.
>

fixed

> May I also suggest a static function that processes a sequence of bytes a=
nd
> returns the result? It's quite useful in many contexts and it can probabl=
y be
> implemented inline. Or even as a free function. Looking at the uses of
> QCryptographicHash in Qt, this is the distribution:
>
>  (non-static) QCryptographicHash::addBytes: 0
>  (static) QCryptographicHash::hash: 10
>

Sounds like a good idea.

>> I also created a sample implementation based on libgcrypt and a small
>> test application.
>>
>> https://github.com/markus-mayer/std-crypto/blob/master/include/hash.hpp
>> https://github.com/markus-mayer/std-crypto/blob/master/src/test_hash.cpp
>>
>> There is still an open question, which I am not sure about:
>> - What is better: sha<512> or sha512?
>
> See my other email. But since the number of digits is not free, I don't t=
hink
> you should make it a template parameter. I can't do
>  sha<1024>
>  sha<999>
>
> Those algorithms don't exist. There are exactly 4 hash lengths standardis=
ed
> for both SHA-2 and SHA-3.
>
> I also recommend rectifying a past failure to foresee the future and nami=
ng
> the SHA-2 algorithms with "sha2" in the name. That also makes it clear ab=
out
> SHA-3, which your proposal failed to include.
>
>> There are other open question, but I think it makes more sens to discuss
>> them when the whole proposal is drafted:
>> - Naming
>> - Namespaces/Header files
>
> And which algorithms must be implemented.
>

--=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/.

.

On 02/11/2014 09:33 AM, Olaf van der Spek wrote:
> On Tue, Feb 11, 2014 at 3:11 AM, Nevin Liber <nevin@eviloverlord.com> wrote:
>> Not if N3884 passes.  You could most certainly optimize it based on the type
>> of iterator.
>
> Then array_view<unsigned char> looks like the right type, perhaps with
> overloads for char and signed char.
>
If I understand the array_view proposal correctly, it's about getting an
one dimensional view of a multi dimensional array.

With that said I don't get how this is applicable here.

--

---
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/.

.

Em ter 11 fev 2014, =E0s 21:51:14, Markus Mayer escreveu:
> > It will process a contiguous range of bytes byte-by-byte, which is
> > horribly
> > inefficient. Not only will it make function calls for each byte, most
> > implementations can actually operate faster if you provide a bigger ran=
ge.
> > Hashing a non-contiguous range is probably going to be an extreme corne=
r
> > case and it might be acceptable to require people to write their own
> > loops.
> AFAIK Most hash functions use a fixed sized internal buffer/block the=20
> input is copied to. So if the compiler is able to optimize=20
> std::copy{_n}, the performance should be equal to the other variant.

Even if the implementations buffer up to 8 bytes and process in chunks, you=
're=20
still making one non-inlineable function call per byte. If you want to=20
calculate the hash of a 1024-byte block, you'll be making 1023 function cal=
ls=20
too many.

Unless this buffer is actually in the inlineable parts of the given=20
hash_function. That will make the code more complex, but maybe it won't be=
=20
horribly slow.

I am questioning that complexity: why accept a non-contiguous iterator at a=
ll?=20
The 0.01% corner-case that requires it can write their own loop or use=20
std::for_each.

--=20
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

--=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/.

.