Andy Polyakov wrote:
Hi,
BTW, have you considered synergetic implementation, which would work as
following. Arrange an intermediate buffer followed by non-accessible
page [commonly would be done with anonymous mmap of two pages followed
by mprotect(PROT_NONE) for the second page]. Upon *_init
Hi,
BTW, have you considered synergetic implementation, which would work as
following. Arrange an intermediate buffer followed by non-accessible
page [commonly would be done with anonymous mmap of two pages followed
by mprotect(PROT_NONE) for the second page]. Upon *_init we call
software
Hi Andy,
I'm sorry for such a late reply ;-) I didn't have the hardware available
during past few months and only got it up and running again recently.
BTW, have you considered synergetic implementation, which would work as
following. Arrange an intermediate buffer followed by non-accessible
Should I add/fix something?
BTW, have you considered synergetic implementation, which would work as
following. Arrange an intermediate buffer followed by non-accessible
page [commonly would be done with anonymous mmap of two pages followed
by mprotect(PROT_NONE) for the second page]. Upon
Andy Polyakov wrote:
Could be. But should it be run automatically
during make? I guess no...
No, but I'd like to *see* some test program and I'd like to hear
explicit statement that the implementation passes this test. As you
might recall we have tested AES by encypting with software and
Could be. But should it be run automatically
during make? I guess no...
No, but I'd like to *see* some test program and I'd like to hear
explicit statement that the implementation passes this test. As you
might recall we have tested AES by encypting with software and
decrypting with engine and
Andy,
Ping :-) Did you have time to look at this patch? Should I add/fix
something?
Thanks!
Michal Ludvig
--
* Personal homepage: http://www.logix.cz/michal
__
OpenSSL Project
Ping :-)
(-: Pong
Did you have time to look at this patch?
No, unfortunately. Are you in hurry? If yes, what's the hurry?
Should I add/fix something?
Windows support:-) SHA-224 [which differs from SHA-256 only by initial
constants and truncated output]. Test programs [extra -e argument
Andy Polyakov wrote:
Did you have time to look at this patch?
No, unfortunately. Are you in hurry? If yes, what's the hurry?
No I'm not. I just wanted to move forward...
Should I add/fix something?
Windows support:-)
Uh, eh, ... afterall I don't have a machine to test it on.
SHA-224
Test programs [extra -e argument perhaps].
... to enable engines?
Yes. On the other hand I suppose one can write a script, which would
simply call 'openssl dgst -sha[1|256] -engine padlock' with a set of
known input vectors...
Could be. But should it be run automatically
during make? I
Andy Polyakov wrote:
What happens when you issue the instruction without rep prefix?
That's invalid instruction I believe.
Dare to actually try?
Just tried = Invalid instruction ;-)
Instead its necessary to accumulate all data from
update()s in some buffer and hash them only in final().
The intermdiate status (and finally the result) is stored in the
128Bytes memory array in padlock_do_sha1(). I.e. it's context switch safe.
What happens when you issue the instruction without rep prefix?
That's invalid instruction I believe.
Dare to actually try?
Instead its necessary to
the attached patch adds SHA1 support for VIA PadLock engine.
Did VIA publish documentation for new instructions on their web-site? If
not and you have it, can you send a copy to me?
There are several design decisions that I may need to explain:
The xsha1 instruction always finalizes the MD
Andy Polyakov wrote:
The xsha1 instruction always finalizes the MD computation,
That kind of sucks...
Hopefully the next version of the CPU will have a new hashing
instruction that will finalize only on request. I was already in touch
with the CPU architects, explained them what problems
14 matches
Mail list logo
