On Wed, Mar 06, 2002 at 10:13:55AM +1300, Geoff Thorpe wrote:
Well yes, but as Richard was explaining - static linking with a libcrypto.a
full of stuff is not that different to linking with a custom-built
./crypto/des/-only libdes.a - your linked executable should just contain
the DES
I'm not sure why you need to yank out source when it's just as easy to
link with libcrypto and make sure you only use the specific
algorithms. In such a case, one should avoid using things like
EVP_get_cipherbyname() since that requires that all compiled
algorithms be linked in.
I
Hi,
On Tuesday 05 March 2002 08:12, John Viega wrote:
On Mon, Mar 04, 2002 at 02:48:46PM +0100, Richard Levitte - VMS Whacker
wrote:
I'm not sure why you need to yank out source when it's just as easy to
link with libcrypto and make sure you only use the specific
algorithms. In such a
Sorry to be a couple of weeks behind on the discussion. Too much
going on.
On Fri, Feb 15, 2002 at 04:41:10PM -0600, Stephen Sprunk wrote:
The current state is EAY legacy. His idea was that one should be able
to pick out any of the algorithm directories and create a separate
library for
Thus spake Dr S N Henson:
Maybe. It would be good to the the CFB and OFB modes working properly in
general for other numbers of bits.
The code for this is trivial; define me an API and I'll write the code
underneath.
I thought about moving the whole cipher mode handling to the EVP layer
Stephen Sprunk wrote:
Thus spake Dr S N Henson:
Maybe. It would be good to the the CFB and OFB modes working properly in
general for other numbers of bits.
The code for this is trivial; define me an API and I'll write the code
underneath.
Well I was thinking of something almost
Thus spake Richard Levitte - VMS Whacker:
From: Stephen Sprunk [EMAIL PROTECTED]
stephen After implementing CBC, CFB, OFB, and CTR for AES (mostly plagiarized
stephen from IDEA), I'm beginning to wonder why we have 40 different
stephen implementations of the exact same algorithms in the
Stephen Sprunk wrote:
Thus spake Richard Levitte - VMS Whacker:
The current state is EAY legacy. His idea was that one should be able
to pick out any of the algorithm directories and create a separate
library for them (the old libdes is actually exactly the same as
crypto/des/).
From: Stephen Sprunk [EMAIL PROTECTED]
stephen The current state is EAY legacy. His idea was that one should be able
stephen to pick out any of the algorithm directories and create a separate
stephen library for them (the old libdes is actually exactly the same as
stephen crypto/des/).
Thus spake Dr S N Henson:
The reason for the macros was that when the EVP layer was being revised
it was an absolute nightmare to change anything. IIRC at one point I had
to add an additional field to the EVP_CIPHER structure. I then spent the
next couple of hours modifying lots of almost
Thus spake Richard Levitte - VMS Whacker:
Note that this puts a requirement on the algorithm functions to follow
a certain name standard. The expected frunctions are, for a certain
{prefix} (AES in the AES case, I assume :-)):
{prefix}_ecb_encrypt
{prefix}_cbc_encrypt
Stephen Sprunk wrote:
Can someone help me implement the EVP macros for AES 128-bit CFB and
OFB modes? It's too messy for me to figure out.
I've got non-EVP versions written, but it appears the EVP macros do
their own implementation of the various modes and only call the base
ECB
From: Stephen Sprunk [EMAIL PROTECTED]
stephen Can someone help me implement the EVP macros for AES 128-bit CFB and
stephen OFB modes? It's too messy for me to figure out.
stephen
stephen I've got non-EVP versions written, but it appears the EVP macros do
stephen their own implementation
Can someone help me implement the EVP macros for AES 128-bit CFB and
OFB modes? It's too messy for me to figure out.
I've got non-EVP versions written, but it appears the EVP macros do
their own implementation of the various modes and only call the base
ECB function.
I've also got a trial
14 matches
Mail list logo
