Michal Ludvig wrote:
James Yonan wrote:

  
I have personally seen this behavior as well with the Padlock, though it
was last year (June or July) and I don't have model/stepping info.  In my
case it was fixed by inserting sleep(0) calls immediately after OpenSSL
EVP crypto calls.  So it appeared to be timing-related.


openvpn --test-crypto --secret key --cipher AES-128-CBC --verb 0 --engine padlock --tun-mtu 10000
    

Still no problems. What OpenSSL version do you use? There *could* be a
problem with forcing key reload from memory.

Rolf - try adding call to padlock_reload_key() to the end of
padlock_verify_context() in OpenSSL crypto/engine/hw_padlock.c file and
tell us if it helped.
  
What I did yesterday - triggered by a suggestion from centtech - was this: I inserted a padlock_reload key at the end of both padlock_aes_cipher_omnivorous and padlock_aes_cipher.  This solves the problem.

Some CPU stepping details:

[EMAIL PROTECTED] ~]# cat /proc/cpuinfo
processor       : 0
vendor_id       : CentaurHauls
cpu family      : 6
model           : 9
model name      : VIA Nehemiah
stepping        : 8
cpu MHz         : 1002.482
cache size      : 64 KB
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 1
wp              : yes
flags           : fpu vme de pse tsc msr cx8 mtrr pge cmov pat mmx fxsr sse rng rng_en ace ace_en
bogomips        : 1982.46


Reply via email to