Anything in memory could end up swapped out, but stack is the least likely
since it's more often in use, the best you can do is zero the area ASAP.
My other objection to putting all of this into an engine is that the engine
code is unusable in quite a few cases. Export approvals, and
On Thursday 11 December 2008 05:04:36 Peter Waltenberg wrote:
Anything in memory could end up swapped out, but stack is the least
likely since it's more often in use, the best you can do is zero the
area ASAP.
My other objection to putting all of this into an engine is that the
engine code
On Thu, Dec 11, 2008 at 10:03:32AM -0500, Geoff Thorpe wrote:
Engines like eng_cryptodev.c *are* built in (they're in ./crypto/engine/
rather ./engines/) and the intention is that they should be the
implementation de base for those build targets to which they apply.
I'm surprised this can
On Thursday 11 December 2008 10:52:36 Thor Lancelot Simon wrote:
On Thu, Dec 11, 2008 at 10:03:32AM -0500, Geoff Thorpe wrote:
Engines like eng_cryptodev.c *are* built in (they're in
./crypto/engine/ rather ./engines/) and the intention is that they
should be the implementation de base for
Geoff Thorpe wrote:
...
Caveat: I haven't been involved in FIPS at all BTW, so I find myself
in the couldn't care less category regarding the details. But if
there's something that needs to be locked down (ie. fixed in the C
code), we can surely lock it down as a part *of* the engine code
Hi All,
I am having a issue when using digest command from openssl. When I issue
digest command md5 from openssl, kernel side it will never receive IOCTL -
CIOCGSESSION with sop-mac getting set, also it wont receive IOCTL -
CIOCCRYPT with mac operation set. Tho, crypto driver which I have written
On Thu, 2008-12-11 at 23:03 +0800, Geoff Thorpe wrote:
On Thursday 11 December 2008 05:04:36 Peter Waltenberg wrote:
Anything in memory could end up swapped out, but stack is the least
likely since it's more often in use, the best you can do is zero the
area ASAP.
My other objection to
On Thu, 2008-12-11 at 18:04 +0800, Peter Waltenberg wrote:
Anything in memory could end up swapped out, but stack is the least likely
since it's more often in use, the best you can do is zero the area ASAP.
At least on UNIX system, mlock() can be used to prevent specified memory
range from
I think it's overly paranoid :). No other keys are protected in that way.
Also: If mlock()'d memory isn't automatically free'd when a process crashes
you risk DOS'ing the OS eventually as well. (I'm not sure whether that's
the case or not, just a vague memory from the past.).
I'd certainly
From: owner-openssl-...@openssl.org On Behalf Of Ger Hobbelt
Sent: Wednesday, 10 December, 2008 12:51
To: openssl-dev@openssl.org
Subject: Re: Realligning const void *data variables into 32-bit
boundaries
Processing unaligned data in an aligned fashion always requires some
data copying.
On Thursday 11 December 2008 20:39:41 Huang Ying wrote:
On Thu, 2008-12-11 at 23:03 +0800, Geoff Thorpe wrote:
Engines like eng_cryptodev.c *are* built in (they're in
./crypto/engine/ rather ./engines/) and the intention is that they
should be the implementation de base for those build
On Fri, 2008-12-12 at 11:38 +0800, Geoff Thorpe wrote:
On Thursday 11 December 2008 20:39:41 Huang Ying wrote:
On Thu, 2008-12-11 at 23:03 +0800, Geoff Thorpe wrote:
Engines like eng_cryptodev.c *are* built in (they're in
./crypto/engine/ rather ./engines/) and the intention is that they
On Thursday 11 December 2008 23:02:12 Huang Ying wrote:
On Fri, 2008-12-12 at 11:38 +0800, Geoff Thorpe wrote:
The cipher and digest support is at the granularity of nids, and
these combine algorithm, key-length, and mode. So if you implement
support for those cipher,length,mode
13 matches
Mail list logo
