I've browsning some of the code, and have a few comments.
I think Crypto.SHA ought to be renamed Crypto.SHA1.
The name Crypto.Proxy is somewhat strange (it's actually a buffer). Perhaps it should be renamed, and perhaps it would make sense with a feed/drain interface. Also the pad method looks a little strange,
PIKEFUN string pad() { ptrdiff_t i;
for (i = THIS->backlog_len; i < THIS->block_size - 1; i++) THIS->backlog[i] = DO_NOT_WARN((unsigned char)(my_rand() & 0xff));
THIS->backlog[THIS->block_size - 1] = DO_NOT_WARN((unsigned char)(7 - THIS->backlog_len)); ^
The constant should probably be something like THIS->block_size - 1.
I think Crypto.SHA ought to be renamed Crypto.SHA1.
SHA is the name most people would guess. The documentation says it is SHA1.
The name Crypto.Proxy is somewhat strange (it's actually a buffer).
Yes, I tried Nettle.Buffer first, but it doesn't work (some sort of name collision I think). But it is of course simple to rename it in Crypto.pmod so that we get Crypto.Buffer.
Perhaps it should be renamed, and perhaps it would make sense with a feed/drain interface.
Add it if you like.
Also the pad method looks a little strange,
That code is copied from _Crypto.crypto. It does look fishy...
/ Martin Nilsson (saturator)
Previous text:
2004-02-04 17:39: Subject: Crypto naming
I've browsning some of the code, and have a few comments.
I think Crypto.SHA ought to be renamed Crypto.SHA1.
The name Crypto.Proxy is somewhat strange (it's actually a buffer). Perhaps it should be renamed, and perhaps it would make sense with a feed/drain interface. Also the pad method looks a little strange,
PIKEFUN string pad() { ptrdiff_t i;
for (i = THIS->backlog_len; i < THIS->block_size - 1; i++) THIS->backlog[i] = DO_NOT_WARN((unsigned char)(my_rand() & 0xff));
THIS->backlog[THIS->block_size - 1] = DO_NOT_WARN((unsigned char)(7 - THIS->backlog_len)); ^
The constant should probably be something like THIS->block_size - 1.
/ Niels Möller (vässar rödpennan)
SHA is the name most people would guess. The documentation says it is SHA1.
I would guess SHA1 as I would guess MD5 and not MD...
/ Mirar
Previous text:
2004-02-04 21:21: Subject: Crypto naming
I think Crypto.SHA ought to be renamed Crypto.SHA1.
SHA is the name most people would guess. The documentation says it is SHA1.
The name Crypto.Proxy is somewhat strange (it's actually a buffer).
Yes, I tried Nettle.Buffer first, but it doesn't work (some sort of name collision I think). But it is of course simple to rename it in Crypto.pmod so that we get Crypto.Buffer.
Perhaps it should be renamed, and perhaps it would make sense with a feed/drain interface.
Add it if you like.
Also the pad method looks a little strange,
That code is copied from _Crypto.crypto. It does look fishy...
/ Martin Nilsson (saturator)
SHA is the name most people would guess. The documentation says it is SHA1.
I'm not so sure about that. And if we ever need to implement the original "SHA" function, what should that be named? (Google yields 209 000 hits for "sha1 hash", and only 84 500 for "sha hash", using "all of the words"-queries).
Yes, I tried Nettle.Buffer first, but it doesn't work (some sort of name collision I think).
Odd. No idea what it collided with?
Perhaps it should be renamed, and perhaps it would make sense with a feed/drain interface.
But on second thought, feed/drain might need an arbitrary large buffer. The current convention (if I understand it correctly) never needs to save more than one block of data. Which is nice from an implementation point of few, in particular as the implementation is written in C.
There are also a few different conventions for padding, so I hope the class can be extended easily.
/ Niels Möller (vässar rödpennan)
Previous text:
2004-02-04 21:21: Subject: Crypto naming
I think Crypto.SHA ought to be renamed Crypto.SHA1.
SHA is the name most people would guess. The documentation says it is SHA1.
The name Crypto.Proxy is somewhat strange (it's actually a buffer).
Yes, I tried Nettle.Buffer first, but it doesn't work (some sort of name collision I think). But it is of course simple to rename it in Crypto.pmod so that we get Crypto.Buffer.
Perhaps it should be renamed, and perhaps it would make sense with a feed/drain interface.
Add it if you like.
Also the pad method looks a little strange,
That code is copied from _Crypto.crypto. It does look fishy...
/ Martin Nilsson (saturator)
I'm not so sure about that. And if we ever need to implement the original "SHA" function, what should that be named? (Google yields 209 000 hits for "sha1 hash", and only 84 500 for "sha hash", using "all of the words"-queries).
Well, then I'll rename it SHA1.
Odd. No idea what it collided with?
object(is 12), whatever that is.
But on second thought, feed/drain might need an arbitrary large buffer.
That is of course easy to add in a Pike wrapper with String.Buffer.
There are also a few different conventions for padding, so I hope the class can be extended easily.
Well, no. Even if you inherit it you can not access the backlog. We could either add accessor methods or add some sort of static pike variables. But we don't HAVE to do that now...
/ Martin Nilsson (saturator)
Previous text:
2004-02-04 21:47: Subject: Crypto naming
SHA is the name most people would guess. The documentation says it is SHA1.
I'm not so sure about that. And if we ever need to implement the original "SHA" function, what should that be named? (Google yields 209 000 hits for "sha1 hash", and only 84 500 for "sha hash", using "all of the words"-queries).
Yes, I tried Nettle.Buffer first, but it doesn't work (some sort of name collision I think).
Odd. No idea what it collided with?
Perhaps it should be renamed, and perhaps it would make sense with a feed/drain interface.
But on second thought, feed/drain might need an arbitrary large buffer. The current convention (if I understand it correctly) never needs to save more than one block of data. Which is nice from an implementation point of few, in particular as the implementation is written in C.
There are also a few different conventions for padding, so I hope the class can be extended easily.
/ Niels Möller (vässar rödpennan)
Well, no. Even if you inherit it you can not access the backlog. We could either add accessor methods or add some sort of static pike variables. But we don't HAVE to do that now...
I was thinking more of thingh like having pad and unpad methods that can be overridden, or some optional argument to say which style to use. (But I don't quite see the point of having this class implemented in C anyway).
/ Niels Möller (vässar rödpennan)
Previous text:
2004-02-04 22:29: Subject: Crypto naming
I'm not so sure about that. And if we ever need to implement the original "SHA" function, what should that be named? (Google yields 209 000 hits for "sha1 hash", and only 84 500 for "sha hash", using "all of the words"-queries).
Well, then I'll rename it SHA1.
Odd. No idea what it collided with?
object(is 12), whatever that is.
But on second thought, feed/drain might need an arbitrary large buffer.
That is of course easy to add in a Pike wrapper with String.Buffer.
There are also a few different conventions for padding, so I hope the class can be extended easily.
Well, no. Even if you inherit it you can not access the backlog. We could either add accessor methods or add some sort of static pike variables. But we don't HAVE to do that now...
/ Martin Nilsson (saturator)
It was implemented in C in _Crypto, so I thought I could just as well copy it instead of reimplement it in Pike.
/ Martin Nilsson (saturator)
Previous text:
2004-02-04 22:34: Subject: Crypto naming
Well, no. Even if you inherit it you can not access the backlog. We could either add accessor methods or add some sort of static pike variables. But we don't HAVE to do that now...
I was thinking more of thingh like having pad and unpad methods that can be overridden, or some optional argument to say which style to use. (But I don't quite see the point of having this class implemented in C anyway).
/ Niels Möller (vässar rödpennan)
pike-devel@lists.lysator.liu.se
-
Martin Nilsson (saturator) ＠ Pike (-) developers forum -
Mirar ＠ Pike developers forum
-
Niels M�ller (v�ssar r�dpennan) ＠ Pike (-) developers forum