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

--

---
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 22, 2014 at 4:43 PM, Markus Mayer <lotharlutz@gmx.de> 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 don't know. Crypto can be and is already implemented in form of
portable libraries. And building something like this in a safe way is
hard. I think this is best left to those who really know what they are
doing. Of course, one could just take an existing library and
standardize its interface. But what's the point of doing that?
Programmers could just as well use that library.

> 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?

This would be a very huge addidion to the standard library. I'm not
conviced that it's a good idea to do that. This list also does not
cover the algorithms that appear to get popular these days (Chacha20
stream cipher, Poly1305 authentication, Curve25519 public key crypto)
which were added to TLS 1.2 recently in response to RC4 and CBC
attacks or which are things you find in a modern crypto library NaCl
("salt", http://nacl.cr.yp.to/ ).

--

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

.

I asked some of the Chrome security folks about "constant time"
guarantees in the integer class
(http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3542.html),
and they replied that this is probably best left to specialized
libraries rather than standard library implementers. All of these
algorithms need to be constant time relative to their secret inputs,
so I suspect the same guidance applies.

That said, we are looking at some more hash functions for applications
where the input isn't secret:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n3898.htm.

On Wed, Jan 22, 2014 at 7:43 AM, Markus Mayer <lotharlutz@gmx.de> 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
>
> --
>
> --- 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/.

.

--047d7b86c76cbc0a3004f0a8210c
Content-Type: text/plain; charset=UTF-8

In reply to n3898, I don't see a benefit to have more
implementation-defined hash functions.  Instead, I'd like to see **named**
cryptographic hash functions (md*, sha*) to be standardized.  See also
FreeBSD's libmd and its Linux port, and Python's hashlib.

--
Zhihao
On Jan 23, 2014 11:48 AM, "Jeffrey Yasskin" <jyasskin@google.com> wrote:

> I asked some of the Chrome security folks about "constant time"
> guarantees in the integer class
> (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3542.html),
> and they replied that this is probably best left to specialized
> libraries rather than standard library implementers. All of these
> algorithms need to be constant time relative to their secret inputs,
> so I suspect the same guidance applies.
>
> That said, we are looking at some more hash functions for applications
> where the input isn't secret:
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n3898.htm.
>
> On Wed, Jan 22, 2014 at 7:43 AM, Markus Mayer <lotharlutz@gmx.de> 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
> >
> > --
> >
> > --- 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/.
>

--

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

--047d7b86c76cbc0a3004f0a8210c
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<p>In reply to n3898, I don&#39;t see a benefit to have more implementation=
-defined hash functions.=C2=A0 Instead, I&#39;d like to see **named** crypt=
ographic hash functions (md*, sha*) to be standardized.=C2=A0 See also Free=
BSD&#39;s libmd and its Linux port, and Python&#39;s hashlib.</p>

<p>--<br>
Zhihao</p>
<div class=3D"gmail_quote">On Jan 23, 2014 11:48 AM, &quot;Jeffrey Yasskin&=
quot; &lt;<a href=3D"mailto:jyasskin@google.com">jyasskin@google.com</a>&gt=
; wrote:<br type=3D"attribution"><blockquote class=3D"gmail_quote" style=3D=
"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I asked some of the Chrome security folks about &quot;constant time&quot;<b=
r>
guarantees in the integer class<br>
(<a href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3542.h=
tml" target=3D"_blank">http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2=
013/n3542.html</a>),<br>
and they replied that this is probably best left to specialized<br>
libraries rather than standard library implementers. All of these<br>
algorithms need to be constant time relative to their secret inputs,<br>
so I suspect the same guidance applies.<br>
<br>
That said, we are looking at some more hash functions for applications<br>
where the input isn&#39;t secret:<br>
<a href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n3898.ht=
m" target=3D"_blank">http://www.open-std.org/jtc1/sc22/wg21/docs/papers/201=
4/n3898.htm</a>.<br>
<br>
On Wed, Jan 22, 2014 at 7:43 AM, Markus Mayer &lt;<a href=3D"mailto:lotharl=
utz@gmx.de">lotharlutz@gmx.de</a>&gt; wrote:<br>
&gt; In one of my projects I rely on hash functions (eg. md5) to do some ch=
ecksum<br>
&gt; calculations. As those function are (supposedly) quite common, I think=
 it<br>
&gt; would be beneficial to include them into the standard library.<br>
&gt;<br>
&gt; As hash functions are only a small part within cryptography, maybe oth=
er<br>
&gt; functions should be included as well.<br>
&gt;<br>
&gt; But before starting to come up with a proposal I want to hear some opi=
nions<br>
&gt; if there is a/no need for such functions.<br>
&gt;<br>
&gt; I think the following categories maybe relevant to include:<br>
&gt; - Hash functions (md5, sha1, ...)<br>
&gt; - Symmetric ciphers (aes, ...)<br>
&gt; - Encryption modes (cbc, ecb, ...)<br>
&gt; - Secure random number generation<br>
&gt; - Asymmetric ciphers (RSA, ...)<br>
&gt; - Signing functions<br>
&gt; - Password derivation functions (PBKDF2, bcrypt, scrypt)<br>
&gt; - message authentication code functions (hmac, ...)<br>
&gt; - padding schemes (PKCS7, ...)<br>
&gt; - Key exchange (DH)<br>
&gt; - Have I missed something?<br>
&gt;<br>
&gt;<br>
&gt; regards<br>
&gt; =C2=A0 Markus<br>
&gt;<br>
&gt; --<br>
&gt;<br>
&gt; --- You received this message because you are subscribed to the Google=
<br>
&gt; Groups &quot;ISO C++ Standard - Future Proposals&quot; group.<br>
&gt; To unsubscribe from this group and stop receiving emails from it, send=
 an<br>
&gt; email to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org">std=
-proposals+unsubscribe@isocpp.org</a>.<br>
&gt; To post to this group, send email to <a href=3D"mailto:std-proposals@i=
socpp.org">std-proposals@isocpp.org</a>.<br>
&gt; Visit this group at<br>
&gt; <a href=3D"http://groups.google.com/a/isocpp.org/group/std-proposals/"=
 target=3D"_blank">http://groups.google.com/a/isocpp.org/group/std-proposal=
s/</a>.<br>
<br>
--<br>
<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 <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org">std-propo=
sals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</blockquote></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 />

--047d7b86c76cbc0a3004f0a8210c--

.

FWIW, I've made that comment too. I think Geoff just ran out of time
to incorporate it before the mailing deadline. I'd like to see
something like <random> where most things are named, but there are a
couple implementation-defined ones for novices to default to.

On Thu, Jan 23, 2014 at 11:20 AM, Zhihao Yuan <zy@miator.net> wrote:
> In reply to n3898, I don't see a benefit to have more implementation-defined
> hash functions.  Instead, I'd like to see **named** cryptographic hash
> functions (md*, sha*) to be standardized.  See also FreeBSD's libmd and its
> Linux port, and Python's hashlib.
>
> --
> Zhihao
>
> On Jan 23, 2014 11:48 AM, "Jeffrey Yasskin" <jyasskin@google.com> wrote:
>>
>> I asked some of the Chrome security folks about "constant time"
>> guarantees in the integer class
>> (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3542.html),
>> and they replied that this is probably best left to specialized
>> libraries rather than standard library implementers. All of these
>> algorithms need to be constant time relative to their secret inputs,
>> so I suspect the same guidance applies.
>>
>> That said, we are looking at some more hash functions for applications
>> where the input isn't secret:
>> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n3898.htm.
>>
>> On Wed, Jan 22, 2014 at 7:43 AM, Markus Mayer <lotharlutz@gmx.de> 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
>> >
>> > --
>> >
>> > --- 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/.
>
> --
>
> ---
> 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/.

.

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?

This sounds like a laundry list of OpenSSL features.

It turns out that properly implementing cryptographic
whatever functions (even with known-good algorithms)
can be very challenging due to the need to thwart various
side channel attacks (timing, power consumption, noise from
capacitors, ...)

This, by itself, plus the fact that those functions are
probably implemented over and over again, are good reasons
for standardization.  On the other hand, I'd probably go
for some known-good external library (with source) rather
than trust my US-based standard library vendor to supply
a dependable cryptographic library (cf. default random
number generator from RSA Security).

That said, I'd love to have a standardized interface for these,
but maybe a better starting point would be to think about the
underlying principles, and have standardized abstractions for
them (similar to "iterator" as a concept):

 - A hash function incrementally consumes input byte ranges,
eventually producing a (small) set of bytes as output.

 - An encryption function (coupled with a mode) incrementally
consumes input byte ranges, producing one or more output byte
ranges, as space permits.  This is the same principle as any
compression function (e.g. gzip).

 - An asymmetric cipher consumes a (small) single input byte range,
together with a few parameters (e.g. the key), and produces
a (small) single output byte range.

 - A (secure) random number generator produces output byte
ranges from "nothing", except for injecting additional
entropy as byte ranges.

I don't know the other categories well enough to understand
whether they would plausibly fall in one of the categories
above.

Libraries such as OpenSSL already provide similar abstractions
(as C interfaces), so adapting e.g. OpenSSL to a standardized
interface such as outlined above is not very hard.

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_641_32514915.1390568511701
Content-Type: text/plain; charset=UTF-8

On Wednesday, January 22, 2014 4:43:54 PM UTC+1, 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,


They are. Why aren't you using an existing crypto library?
I'm using md5 and sha1 too (though I should be using something better for
password hashing) and I'm not using an existing lib because including
sha1.cpp in your project is easier than consuming a (third-party) lib most
of the time. IMO working on this problem would be better than including
everything into ISO C++.

--

---
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_641_32514915.1390568511701
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Wednesday, January 22, 2014 4:43:54 PM UTC+1, Markus Ma=
yer wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:=
 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">In one of my project=
s I rely on hash functions (eg. md5) to do some=20
<br>checksum calculations. As those function are (supposedly) quite common,=
 </blockquote><div><br></div><div>They are. Why aren't you using an existin=
g crypto library?</div><div>I'm using md5 and sha1 too (though I should be =
using something better for password hashing) and I'm not using an existing =
lib because including sha1.cpp in your project is easier than consuming a (=
third-party) lib most of the time. IMO working on this problem would be bet=
ter than including everything into ISO C++.</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_641_32514915.1390568511701--

.

On 01/23/2014 10:10 AM, Sebastian Gesemann wrote:
> On Wed, Jan 22, 2014 at 4:43 PM, Markus Mayer <lotharlutz@gmx.de> 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 don't know. Crypto can be and is already implemented in form of
> portable libraries.
If this argument holds, we shouldn't have included many boost features.

> And building something like this in a safe way is
> hard.
Well, that's a reason to build it into the std library.

What I actually see today is that developers just google for 'aes c/c++
implementation' or 'c++ crypto library' and take the first appropriate
solution. They don't evaluate how well the implementations (in terms of
security) are. Most don't even have the knowledge to do this. For the
average user the std-impl could be more secure then most implementations
found by just googleing.


> I think this is best left to those who really know what they are
> doing. Of course, one could just take an existing library and
> standardize its interface. But what's the point of doing that?
> Programmers could just as well use that library.
>
>> 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?
>
> This would be a very huge addidion to the standard library. I'm not
> conviced that it's a good idea to do that. This list also does not
> cover the algorithms that appear to get popular these days (Chacha20
> stream cipher, Poly1305 authentication, Curve25519 public key crypto)
> which were added to TLS 1.2 recently in response to RC4 and CBC
> attacks or which are things you find in a modern crypto library NaCl
> ("salt", http://nacl.cr.yp.to/ ).
>

The question of what algorithms to implement is a whole other story.

--

---
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 24 January 2014 15:03, Markus Mayer <lotharlutz@gmx.de> wrote:
>> I don't know. Crypto can be and is already implemented in form of
>> portable libraries.
> If this argument holds, we shouldn't have included many boost features.

No worries, it doesn't hold. The benefits of standardizing common existing
practice include wider portability and better specification, which existing
libraries, even portable ones, seem to somewhat lack as compared to having
a library in the standard.

--

---
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/24/2014 08:38 AM, Jens Maurer wrote:
> 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?
>
> This sounds like a laundry list of OpenSSL features.
>
> It turns out that properly implementing cryptographic
> whatever functions (even with known-good algorithms)
> can be very challenging due to the need to thwart various
> side channel attacks (timing, power consumption, noise from
> capacitors, ...)
>
> This, by itself, plus the fact that those functions are
> probably implemented over and over again, are good reasons
> for standardization.  On the other hand, I'd probably go
> for some known-good external library (with source) rather
> than trust my US-based standard library vendor to supply
> a dependable cryptographic library (cf. default random
> number generator from RSA Security).
>
> That said, I'd love to have a standardized interface for these,
> but maybe a better starting point would be to think about the
> underlying principles, and have standardized abstractions for
> them (similar to "iterator" as a concept):
>
>   - A hash function incrementally consumes input byte ranges,
> eventually producing a (small) set of bytes as output.
>
>   - An encryption function (coupled with a mode) incrementally
> consumes input byte ranges, producing one or more output byte
> ranges, as space permits.  This is the same principle as any
> compression function (e.g. gzip).
>
>   - An asymmetric cipher consumes a (small) single input byte range,
> together with a few parameters (e.g. the key), and produces
> a (small) single output byte range.
>
>   - A (secure) random number generator produces output byte
> ranges from "nothing", except for injecting additional
> entropy as byte ranges.
>
> I don't know the other categories well enough to understand
> whether they would plausibly fall in one of the categories
> above.
>
> Libraries such as OpenSSL already provide similar abstractions
> (as C interfaces), so adapting e.g. OpenSSL to a standardized
> interface such as outlined above is not very hard.
>
> Jens
>

That are really good points Jens. I was already think about something
similar. My current ideas are the following:
- provide a standardized interface for each algorithm category.
Interface means method signatures, behaviors, ... (not an abstract base
class!)

-provide the most common algorithms within the std library

This enables the 'crypto novice' user to easy use crypto functions
within his program.

Advanced users who needs additions algorithms, needs some special
implementation or simply don't trust the std implementation can use an
'stl compatible' implementation.


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

.

--001a11330964dee09404f0b9294d
Content-Type: text/plain; charset=UTF-8

Am I correct that, following Jens points, such a library interface if
standardized could become
 one of these libraries that are supposed to be optional for implementors?
If I remember correctly, part of the coming math functions additions will
not be required to be present in
standard C++ implementations, but if they are present they must just match
the specified interface.
It allows for implementors to provide the library if they can put efforts
in it, without bothering about being 100% standard complete.

--

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

--001a11330964dee09404f0b9294d
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra">Am I correct that, following Je=
ns points, such a library interface if standardized could become<br>=C2=A0o=
ne of these libraries that are supposed to be optional for implementors?=C2=
=A0</div><div class=3D"gmail_extra">
If I remember correctly, part of the coming math functions additions will n=
ot be required to be present in</div><div class=3D"gmail_extra">standard C+=
+ implementations, but if they are present they must just match the specifi=
ed interface.</div>
<div class=3D"gmail_extra">It allows for implementors to provide the librar=
y if they can put efforts in it, without bothering about being 100% standar=
d complete.</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 />

--001a11330964dee09404f0b9294d--

.

On 01/24/2014 02:17 PM, Markus Mayer wrote:
> That are really good points Jens. I was already think about something
> similar. My current ideas are the following:
> - provide a standardized interface for each algorithm category.
> Interface means method signatures, behaviors, ... (not an abstract base
> class!)

Make sure you're not requiring unnecessary memory allocations in
the interface.  For example, if the interface takes a key by std::string,
every key setting requires a dynamic memory allocation from the default
allocator.  Not necessarily good in today's multi-threaded world.

These are all rather basic byte-oriented algorithms, so memory management
is best left to another level.

Here are my tests for your interfaces.  Neither are "cryptographic",
but check whether your interface is flexible enough:

 - Does "bzip2" fit?  (including being able to pass minor config
items such as the compression level)

 - Does crc32 fit?

> -provide the most common algorithms within the std library

This should be (in essence) a one-sentence spec for each algorithm,
pointing to some external standard or paper where it's defined.

> Advanced users who needs additions algorithms, needs some special
> implementation or simply don't trust the std implementation can use an
> 'stl compatible' implementation.

Similar to using own::vector<> instead of std::vector<>, but with
a common iterator interface, I'd hope.

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_752_12422684.1392324668264
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable



2014. janu=C3=A1r 22., szerda 16:43:54 UTC+1 id=C5=91pontban Markus Mayer a=
=20
k=C3=B6vetkez=C5=91t =C3=ADrta:
>
>
> I think the following categories maybe relevant to include:=20
> (...)
> - Have I missed something?=20
>
> Compression is kinda necessary for secure communications, if you have a=
=20
lower entropy source (like, you want to be platform-independent, and=20
sending data in XML), then you are more vulnerable to some attacks.
I know it is a bit loosely related, and worth a complete separate proposal=
=20
(there might be even existing ones?), but it would be nice to keep this in=
=20
mind designing the functionality.

Regards, Robert

=20

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

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

<div dir=3D"ltr"><br><br>2014. janu=C3=A1r 22., szerda 16:43:54 UTC+1 id=C5=
=91pontban Markus Mayer a k=C3=B6vetkez=C5=91t =C3=ADrta:<blockquote class=
=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #cc=
c solid;padding-left: 1ex;"><br>I think the following categories maybe rele=
vant to include:
<br>(...)<br>- Have I missed something?
<br>
<br></blockquote><div>Compression is kinda necessary for secure communicati=
ons, if you have a lower entropy source (like, you want to be platform-inde=
pendent, and sending data in XML), then you are more vulnerable to some att=
acks.<br>I know it is a bit loosely related, and worth a complete separate =
proposal (there might be even existing ones?), but it would be nice to keep=
 this in mind designing the functionality.<br><br>Regards, Robert<br><br>&n=
bsp;</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_752_12422684.1392324668264--

.