On 11/26/2011 04:19 PM, Brad Anderson wrote:
How about putting a disclaimer on the module warning the code hasn't
been through a rigorous security audit and point them at well
established C libraries if they need that sort of assurance.
What does that gain over implementing the first
On Sun 27 Nov 2011 10:27:58 AM CST, bcs wrote:
On 11/26/2011 04:19 PM, Brad Anderson wrote:
How about putting a disclaimer on the module warning the code hasn't
been through a rigorous security audit and point them at well
established C libraries if they need that sort of assurance.
What
On Sun, Nov 27, 2011 at 9:27 AM, bcs b...@example.com wrote:
On 11/26/2011 04:19 PM, Brad Anderson wrote:
How about putting a disclaimer on the module warning the code hasn't
been through a rigorous security audit and point them at well
established C libraries if they need that sort of
Jude Young wrote:
On Sun 27 Nov 2011 10:27:58 AM CST, bcs wrote:
On 11/26/2011 04:19 PM, Brad Anderson wrote:
How about putting a disclaimer on the module warning the code hasn't
been through a rigorous security audit and point them at well
established C libraries if they need that sort of
On 11/27/2011 12:14 PM, Brad Anderson wrote:
That's even better but isn't the issue over bundling incompatibly
licensed libraries with phobos? Nothing is stopping someone from
writing bindings for these libraries as some random library on D Source
or Github already.
If we can't find
On 11/27/2011 12:15 PM, Piotr Szturmaj wrote:
Jude Young wrote:
On Sun 27 Nov 2011 10:27:58 AM CST, bcs wrote:
On 11/26/2011 04:19 PM, Brad Anderson wrote:
How about putting a disclaimer on the module warning the code hasn't
been through a rigorous security audit and point them at well
On Fri, Nov 25, 2011 at 10:31 PM, bcs b...@example.com wrote:
On 11/22/2011 08:16 AM, Piotr Szturmaj wrote:
bcs wrote:
How many people in the D community have the experience and know-how to
review the security of an implementation? If there are less than 2 or 3
people who can do that,
On 11/22/2011 08:16 AM, Piotr Szturmaj wrote:
bcs wrote:
How many people in the D community have the experience and know-how to
review the security of an implementation? If there are less than 2 or 3
people who can do that, can we afford to include native kernels? We
can't have just one and
bcs wrote:
On 11/20/2011 08:10 AM, Piotr Szturmaj wrote:
bcs wrote:
On 11/04/2011 04:27 AM, Piotr Szturmaj wrote:
bcs wrote:
Are you re-implementing the function kernels your self or are you
using
an existing implementation? Given what I've heard about things like
side-channel attacks using
On Tue, 22 Nov 2011 16:16:21 -, Piotr Szturmaj bncr...@jadamspam.pl
wrote:
bcs wrote:
On 11/20/2011 08:10 AM, Piotr Szturmaj wrote:
bcs wrote:
On 11/04/2011 04:27 AM, Piotr Szturmaj wrote:
bcs wrote:
Are you re-implementing the function kernels your self or are you
using
an existing
On 11/20/2011 08:10 AM, Piotr Szturmaj wrote:
bcs wrote:
On 11/04/2011 04:27 AM, Piotr Szturmaj wrote:
bcs wrote:
Are you re-implementing the function kernels your self or are you using
an existing implementation? Given what I've heard about things like
side-channel attacks using processing
bcs wrote:
On 11/04/2011 04:27 AM, Piotr Szturmaj wrote:
bcs wrote:
Are you re-implementing the function kernels your self or are you using
an existing implementation? Given what I've heard about things like
side-channel attacks using processing times to recover keys, I'd rather
not see Phobos
bcs wrote:
Are you re-implementing the function kernels your self or are you using
an existing implementation? Given what I've heard about things like
side-channel attacks using processing times to recover keys, I'd rather
not see Phobos use anything written by less than the best expert
On 11/04/2011 04:27 AM, Piotr Szturmaj wrote:
bcs wrote:
Are you re-implementing the function kernels your self or are you using
an existing implementation? Given what I've heard about things like
side-channel attacks using processing times to recover keys, I'd rather
not see Phobos use
On 11/4/2011 7:52 PM, bcs wrote:
tl;dr; It mentions cache-based, timing, and other side channel attacks. Unless
you can explain to me what those are, in painful detail, I don't think we should
trust you to avoid them. Get a good vetted C implementation and wrap it with a
nice D API and call it a
On 10/24/2011 05:10 PM, Piotr Szturmaj wrote:
https://github.com/pszturmaj/phobos/tree/master/std/crypto
This is some early work on std.crypto proposal. Currently only MD5, HMAC
and all SHA family functions (excluding SHA0 which is very old, broken
and no longer in use). I plan to add other
An easy test is that if the interface takes a T[] as input, consider a
range instead. Ditto for output. If an interface takes a File as input,
it's a red flag that something is wrong.
I have a question about ranges that occurred to me when I was composing a
MySQL result set into a random
On Wednesday, October 26, 2011 06:28:52 Steve Teale wrote:
An easy test is that if the interface takes a T[] as input, consider a
range instead. Ditto for output. If an interface takes a File as input,
it's a red flag that something is wrong.
I have a question about ranges that occurred
On 26.10.2011 10:28, Steve Teale wrote:
An easy test is that if the interface takes a T[] as input, consider a
range instead. Ditto for output. If an interface takes a File as input,
it's a red flag that something is wrong.
I have a question about ranges that occurred to me when I was
On Tue, 25 Oct 2011 23:45:58 -0700, Jonathan M Davis wrote:
On Wednesday, October 26, 2011 06:28:52 Steve Teale wrote:
An easy test is that if the interface takes a T[] as input, consider
a range instead. Ditto for output. If an interface takes a File as
input, it's a red flag that
On Wednesday, October 26, 2011 03:17 Steve Teale wrote:
On Tue, 25 Oct 2011 23:45:58 -0700, Jonathan M Davis wrote:
On Wednesday, October 26, 2011 06:28:52 Steve Teale wrote:
An easy test is that if the interface takes a T[] as input, consider
a range instead. Ditto for output. If an
On Wed, 26 Oct 2011 13:01:14 -0400, Jonathan M Davis wrote:
On Wednesday, October 26, 2011 03:17 Steve Teale wrote:
On Tue, 25 Oct 2011 23:45:58 -0700, Jonathan M Davis wrote:
On Wednesday, October 26, 2011 06:28:52 Steve Teale wrote:
An easy test is that if the interface takes a T[] as
On Wednesday, October 26, 2011 19:00:02 Steve Teale wrote:
On Wed, 26 Oct 2011 13:01:14 -0400, Jonathan M Davis wrote:
Ranges are defined per templates in std.range. isForwardRange,
isInputRange, isRandomAccessRange, etc. And it looks like isForwardRange
specifically checks that the return
Martin Nowak wrote:
I have to say though that I like the current struct based interface
much better.
struct Hash
{
// enhanced by some compile time traits
enum hashLength = 16;
enum blockLength = 0;
The reason why hash and block length are runtime variables is that some
hash functions are
On Tue, 25 Oct 2011 09:43:48 +0200, Piotr Szturmaj bncr...@jadamspam.pl
wrote:
Martin Nowak wrote:
I have to say though that I like the current struct based interface
much better.
struct Hash
{
// enhanced by some compile time traits
enum hashLength = 16;
enum blockLength = 0;
The reason
On 10/24/2011 5:10 PM, Piotr Szturmaj wrote:
https://github.com/pszturmaj/phobos/tree/master/std/crypto
This is some early work on std.crypto proposal. Currently only MD5, HMAC and
all SHA family functions (excluding SHA0
which is very old, broken and no longer in use). I plan to add other
Brad Roberts wrote:
On 10/24/2011 5:10 PM, Piotr Szturmaj wrote:
https://github.com/pszturmaj/phobos/tree/master/std/crypto
This is some early work on std.crypto proposal. Currently only MD5, HMAC and
all SHA family functions (excluding SHA0
which is very old, broken and no longer in use). I
On 10/24/2011 5:10 PM, Piotr Szturmaj wrote:
https://github.com/pszturmaj/phobos/tree/master/std/crypto
This is some early work on std.crypto proposal. Currently only MD5, HMAC and all
SHA family functions (excluding SHA0 which is very old, broken and no longer in
use). I plan to add other
Martin Nowak wrote:
On Tue, 25 Oct 2011 09:43:48 +0200, Piotr Szturmaj
bncr...@jadamspam.pl wrote:
Martin Nowak wrote:
I have to say though that I like the current struct based interface
much better.
struct Hash
{
// enhanced by some compile time traits
enum hashLength = 16;
enum blockLength
Walter Bright wrote:
On 10/24/2011 5:10 PM, Piotr Szturmaj wrote:
https://github.com/pszturmaj/phobos/tree/master/std/crypto
This is some early work on std.crypto proposal. Currently only MD5,
HMAC and all
SHA family functions (excluding SHA0 which is very old, broken and no
longer in
use). I
On 10/25/2011 3:40 PM, Piotr Szturmaj wrote:
I share your opinion. I was thinking about such filter concept for
std.crypto.cipher (TBD), but I will also try to convert current hash function
code to ranges.
Thanks for pointing that out.
Andrei and I have pretty much failed at articulating this
On Tuesday, October 25, 2011 15:55 Walter Bright wrote:
On 10/25/2011 3:40 PM, Piotr Szturmaj wrote:
I share your opinion. I was thinking about such filter concept for
std.crypto.cipher (TBD), but I will also try to convert current hash
function code to ranges.
Thanks for pointing that
On Tue, Oct 25, 2011 at 5:12 PM, Jonathan M Davis jmdavisp...@gmx.comwrote:
On Tuesday, October 25, 2011 15:55 Walter Bright wrote:
On 10/25/2011 3:40 PM, Piotr Szturmaj wrote:
I share your opinion. I was thinking about such filter concept for
std.crypto.cipher (TBD), but I will also try
On Tuesday, October 25, 2011 16:16 Brad Anderson wrote:
On Tue, Oct 25, 2011 at 5:12 PM, Jonathan M Davis
jmdavisp...@gmx.comwrote:
On Tuesday, October 25, 2011 15:55 Walter Bright wrote:
On 10/25/2011 3:40 PM, Piotr Szturmaj wrote:
I share your opinion. I was thinking about such filter
If you want a bit of history:
http://www.digitalmars.com/d/archives/digitalmars/D/announce/RFC_on_range_design_for_D2_12922.html#N12922
http://www.digitalmars.com/d/archives/digitalmars/D/announce/Revised_RFC_on_range_design_for_D2_13211.html
finally (somewhat) understood and used them in my
postgres client implementation. And I like them.
I wish there was some article about ranges and their uses. Some tips and
tricks thing for users and guidelines for range writers.
But let's get back to std.crypto. I planned to add input ranges
On 10/25/2011 4:12 PM, Jonathan M Davis wrote:
Ranges in general are not something that is comunicated very well. They're not
in TDPL, and none of the online documentation discusses them in detail. You
pretty much only learn them from reading Phobos' documentation and using
Phobos or from
On 10/25/2011 5:22 PM, Piotr Szturmaj wrote:
But let's get back to std.crypto. I planned to add input ranges to function put,
because it already forms an output range. I thought that std.range.put() would
serve the need if UFCS will be supported. But, as I guess, the best method is to
support
https://github.com/pszturmaj/phobos/tree/master/std/crypto
This is some early work on std.crypto proposal. Currently only MD5, HMAC
and all SHA family functions (excluding SHA0 which is very old, broken
and no longer in use). I plan to add other crypto primitives later.
I know about one SHA1
On Tue, 25 Oct 2011 02:10:49 +0200, Piotr Szturmaj bncr...@jadamspam.pl
wrote:
https://github.com/pszturmaj/phobos/tree/master/std/crypto
This is some early work on std.crypto proposal. Currently only MD5, HMAC
and all SHA family functions (excluding SHA0 which is very old, broken
Has anyone got something that would be a nucleus for this?
Steve Teale schrieb:
Has anyone got something that would be a nucleus for this?
I've used http://www.dsource.org/projects/dcrypt with D1 (just simple HMAC-SHA1
signing, so I can't tell how well the other stuff works).
42 matches
Mail list logo
