The problem almost certainly is that your file a.txt ends in a newline. Try
getting rid of the newline and see what happens.
-- David Jacobson
--- On Tue, 2/17/09, xh wrote:
> From: xh
> Subject: errer found in file evp_test.c
> To: openssl-dev@openssl.org
> Date: Tuesday, February 17, 20
There are two cases. Sometimes a null pointer is used to indicate that some
value is not supplied or that the caller does not want some output stored. In
that case, the check must be done.
But many times a valid pointer must be supplied. In that case, I don't think
it is a necessarily a bug
I don't know why this has degenerated into an argument about use of
non-FIPS-approved algorithms.
For some reason I don't understand, there is a line about "Non-approved
cryptographic operation test". But that is not what caused the failure. The
failure came from the fips_rand_selftest.
This is only conjecture, but it is an educated conjecture. I've done several
implementations of FIPS-approved RNGs, and once had trouble with the RNG test
failing.
The algorithm we used was the one in FIPS 186-2 appendix 3. This algorithm
involves taking an SHA-1 hash, and then treating it as
You don't usually use ECC to encrypt large amounts of text (or any data). You
usually use it in key exchange protocols (ECDH, ECMQV) and in signature
protocols (ECDSA).
-- David Jacobson
shizumi <[EMAIL PROTECTED]> wrote:
hi everybody,
i need some sample code to encrypt/decrypt text usin
I'm only familiar with Solaris. In that system the real stuff in a mutex is a
byte about 12 bytes into the lock structure. On SPARC the mutex_lock function
accesses it with an LDSTUB instruction, which is a special atomic instruction
that loads the old value into a register, and stores 0xff in
Try using /usr/ucb/echo instead of just echo.
This is what I found on Sun's web site:
The shells csh(1), ksh(1), and sh(1), each have an echo built-in
command, which, by default, will have precedence, and will be invoked
if the user calls echo without a full pathname. /usr/ucb/echo and
csh's
This is not a problem with the algorithm or the protocol. It is a bug in the
implementation. Digest values that are zero are allowed by the ANSI X9.62 (and
there is no special case for them) and they work fine in other implementations.
The code is trying to compute u1 * P + u2 * Q, where u1 is
I'm running OpenSSL 0.9.8e. If I set up an ECDSA verify with
EC_KEY_new_by_curve_name(NID_X9_62_prime256v1) and call ECDSA_do_verify with
dgst (first arg) an array of all zeros and dgst=1 (second arg), the call fails
with error 16.
There are two errors in the queue:
lib 16 reason 68 location
