If you want to negate the meaning of the flag, then you have to write it
yourself. I, as non-developer of crypto code, can prove that on given path
the input data are read only once --- but I can't prove that on all paths
and all possible chaining modes of algorithms the data are read once,
becaus
On Fri, May 23, 2008 at 10:59:33AM -0400, Mikulas Patocka wrote:
>
> If you want to negate the meaning of the flag, then you have to write it
> yourself. I, as non-developer of crypto code, can prove that on given path
> the input data are read only once --- but I can't prove that on all paths
>
On Thu, May 22, 2008 at 08:32:45AM -0400, Mikulas Patocka wrote:
There may be external modules.
Sorry but we don't support external modules. They should be merged
upstream rather than distributed in the wild.
Cheers,
If you want to negate the meaning of the flag, then you have to write it
On Thu, May 22, 2008 at 08:32:45AM -0400, Mikulas Patocka wrote:
>
> There may be external modules.
Sorry but we don't support external modules. They should be merged
upstream rather than distributed in the wild.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~}
All the ciphers comply, so the bug is only a theroretical issue (but I
didn't check assembler versions --- they should be checked by the person
who wrote them, assembler is write-only language).
Since every current algorithm sets the flag could you invert
its sense? Sorry to have to do this to y
On Wed, May 21, 2008 at 10:18:43PM -0400, Mikulas Patocka wrote:
>
> All the ciphers comply, so the bug is only a theroretical issue (but I
> didn't check assembler versions --- they should be checked by the person
> who wrote them, assembler is write-only language).
Since every current algorith
On Wed, 14 May 2008, Herbert Xu wrote:
On Tue, May 13, 2008 at 04:35:03PM -0400, Mikulas Patocka wrote:
And where would you propose to place this bit?
One possibility would be struct crypto_tfm->crt_flags
Another possibility is struct crypto_alg->cra_flags
The latter definitely because th
On Tue, May 13, 2008 at 04:35:03PM -0400, Mikulas Patocka wrote:
>
> And where would you propose to place this bit?
>
> One possibility would be struct crypto_tfm->crt_flags
> Another possibility is struct crypto_alg->cra_flags
The latter definitely because this is an algorithm property.
> Can c
On Tue, 13 May 2008, Herbert Xu wrote:
On Mon, May 12, 2008 at 11:28:44PM -0400, Mikulas Patocka wrote:
Or do you thint it would be useless (all major disk-encryption algorithms
read input buffer more times?) or it would create too much code
complexity?
I'm open to this approach. As long
On Mon, May 12, 2008 at 11:28:44PM -0400, Mikulas Patocka wrote:
>
> Or do you thint it would be useless (all major disk-encryption algorithms
> read input buffer more times?) or it would create too much code
> complexity?
I'm open to this approach. As long as you do the work and come up
with
On Tue, 6 May 2008, Mikulas Patocka wrote:
On Tue, 6 May 2008, Herbert Xu wrote:
Mikulas Patocka <[EMAIL PROTECTED]> wrote:
BTW: is it guaranteed for crypto functions that they read the source data
only once?
There is no such guarantee.
Cheers,
So we'll have to copy the sector to tempor
On Tue, 6 May 2008, Herbert Xu wrote:
Mikulas Patocka <[EMAIL PROTECTED]> wrote:
BTW: is it guaranteed for crypto functions that they read the source data
only once?
There is no such guarantee.
Cheers,
So we'll have to copy the sector to temporary space before encrypting it.
I'll look at
Mikulas Patocka <[EMAIL PROTECTED]> wrote:
>
> BTW: is it guaranteed for crypto functions that they read the source data
> only once?
There is no such guarantee.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana
On Mon, 7 Apr 2008, Martin K. Petersen wrote:
"Malahal" == malahal <[EMAIL PROTECTED]> writes:
[I sent this last week but it never made it to the list]
Malahal> Very few drivers require it, so how about an interface to
Malahal> lock the pages of an I/O available to drivers. Only needed
Mal
14 matches
Mail list logo
