OpenSSL 1.1.1-pre2
This commit is contained in:
Hakase
+17
-17
@@ -8,7 +8,7 @@
|
||||
|
||||
#
|
||||
# ====================================================================
|
||||
# Written by Andy Polyakov <appro@fy.chalmers.se> for the OpenSSL
|
||||
# Written by Andy Polyakov <appro@openssl.org> for the OpenSSL
|
||||
# project. The module is, however, dual licensed under OpenSSL and
|
||||
# CRYPTOGAMS licenses depending on where you obtain it. For further
|
||||
# details see http://www.openssl.org/~appro/cryptogams/.
|
||||
@@ -39,7 +39,7 @@
|
||||
# for scaling too, I [try to] avoid the latter by favoring off-by-2
|
||||
# shifts and masking the result with 0xFF<<2 instead of "boring" 0xFF.
|
||||
#
|
||||
# As was shown by Dean Gaudet <dean@arctic.org>, the above note turned
|
||||
# As was shown by Dean Gaudet, the above note turned out to be
|
||||
# void. Performance improvement with off-by-2 shifts was observed on
|
||||
# intermediate implementation, which was spilling yet another register
|
||||
# to stack... Final offset*4 code below runs just a tad faster on P4,
|
||||
@@ -55,8 +55,8 @@
|
||||
# better performance on most recent µ-archs...
|
||||
#
|
||||
# Third version adds AES_cbc_encrypt implementation, which resulted in
|
||||
# up to 40% performance imrovement of CBC benchmark results. 40% was
|
||||
# observed on P4 core, where "overall" imrovement coefficient, i.e. if
|
||||
# up to 40% performance improvement of CBC benchmark results. 40% was
|
||||
# observed on P4 core, where "overall" improvement coefficient, i.e. if
|
||||
# compared to PIC generated by GCC and in CBC mode, was observed to be
|
||||
# as large as 4x:-) CBC performance is virtually identical to ECB now
|
||||
# and on some platforms even better, e.g. 17.6 "small" cycles/byte on
|
||||
@@ -123,7 +123,7 @@
|
||||
# words every cache-line is *guaranteed* to be accessed within ~50
|
||||
# cycles window. Why just SSE? Because it's needed on hyper-threading
|
||||
# CPU! Which is also why it's prefetched with 64 byte stride. Best
|
||||
# part is that it has no negative effect on performance:-)
|
||||
# part is that it has no negative effect on performance:-)
|
||||
#
|
||||
# Version 4.3 implements switch between compact and non-compact block
|
||||
# functions in AES_cbc_encrypt depending on how much data was asked
|
||||
@@ -159,7 +159,7 @@
|
||||
# combinations then attack becomes infeasible. This is why revised
|
||||
# AES_cbc_encrypt "dares" to switch to larger S-box when larger chunk
|
||||
# of data is to be processed in one stroke. The current size limit of
|
||||
# 512 bytes is chosen to provide same [diminishigly low] probability
|
||||
# 512 bytes is chosen to provide same [diminishingly low] probability
|
||||
# for cache-line to remain untouched in large chunk operation with
|
||||
# large S-box as for single block operation with compact S-box and
|
||||
# surely needs more careful consideration...
|
||||
@@ -171,12 +171,12 @@
|
||||
# yield execution to process performing AES just before timer fires
|
||||
# off the scheduler, immediately regain control of CPU and analyze the
|
||||
# cache state. For this attack to be efficient attacker would have to
|
||||
# effectively slow down the operation by several *orders* of magnitute,
|
||||
# effectively slow down the operation by several *orders* of magnitude,
|
||||
# by ratio of time slice to duration of handful of AES rounds, which
|
||||
# unlikely to remain unnoticed. Not to mention that this also means
|
||||
# that he would spend correspondigly more time to collect enough
|
||||
# that he would spend correspondingly more time to collect enough
|
||||
# statistical data to mount the attack. It's probably appropriate to
|
||||
# say that if adeversary reckons that this attack is beneficial and
|
||||
# say that if adversary reckons that this attack is beneficial and
|
||||
# risks to be noticed, you probably have larger problems having him
|
||||
# mere opportunity. In other words suggested code design expects you
|
||||
# to preclude/mitigate this attack by overall system security design.
|
||||
@@ -202,7 +202,7 @@ $output = pop;
|
||||
open OUT,">$output";
|
||||
*STDOUT=*OUT;
|
||||
|
||||
&asm_init($ARGV[0],"aes-586.pl",$x86only = $ARGV[$#ARGV] eq "386");
|
||||
&asm_init($ARGV[0],$x86only = $ARGV[$#ARGV] eq "386");
|
||||
&static_label("AES_Te");
|
||||
&static_label("AES_Td");
|
||||
|
||||
@@ -240,7 +240,7 @@ $small_footprint=1; # $small_footprint=1 code is ~5% slower [on
|
||||
# contention and in hope to "collect" 5% back
|
||||
# in real-life applications...
|
||||
|
||||
$vertical_spin=0; # shift "verticaly" defaults to 0, because of
|
||||
$vertical_spin=0; # shift "vertically" defaults to 0, because of
|
||||
# its proof-of-concept status...
|
||||
# Note that there is no decvert(), as well as last encryption round is
|
||||
# performed with "horizontal" shifts. This is because this "vertical"
|
||||
@@ -585,7 +585,7 @@ sub enctransform()
|
||||
# +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|
||||
# | mm4 | mm0 |
|
||||
# +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|
||||
# | s3 | s2 | s1 | s0 |
|
||||
# | s3 | s2 | s1 | s0 |
|
||||
# +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|
||||
# |15|14|13|12|11|10| 9| 8| 7| 6| 5| 4| 3| 2| 1| 0|
|
||||
# +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|
||||
@@ -805,7 +805,7 @@ sub encstep()
|
||||
|
||||
if ($i==3) { $tmp=$s[3]; &mov ($s[2],$__s1); }##%ecx
|
||||
elsif($i==2){ &movz ($tmp,&HB($s[3])); }#%ebx[2]
|
||||
else { &mov ($tmp,$s[3]);
|
||||
else { &mov ($tmp,$s[3]);
|
||||
&shr ($tmp,24) }
|
||||
&xor ($out,&DWP(1,$te,$tmp,8));
|
||||
if ($i<2) { &mov (&DWP(4+4*$i,"esp"),$out); }
|
||||
@@ -1558,7 +1558,7 @@ sub sse_deccompact()
|
||||
&pxor ("mm1","mm3"); &pxor ("mm5","mm7"); # tp4
|
||||
&pshufw ("mm3","mm1",0xb1); &pshufw ("mm7","mm5",0xb1);
|
||||
&pxor ("mm0","mm1"); &pxor ("mm4","mm5"); # ^= tp4
|
||||
&pxor ("mm0","mm3"); &pxor ("mm4","mm7"); # ^= ROTATE(tp4,16)
|
||||
&pxor ("mm0","mm3"); &pxor ("mm4","mm7"); # ^= ROTATE(tp4,16)
|
||||
|
||||
&pxor ("mm3","mm3"); &pxor ("mm7","mm7");
|
||||
&pcmpgtb("mm3","mm1"); &pcmpgtb("mm7","mm5");
|
||||
@@ -1606,7 +1606,7 @@ sub decstep()
|
||||
# no instructions are reordered, as performance appears
|
||||
# optimal... or rather that all attempts to reorder didn't
|
||||
# result in better performance [which by the way is not a
|
||||
# bit lower than ecryption].
|
||||
# bit lower than encryption].
|
||||
if($i==3) { &mov ($key,$__key); }
|
||||
else { &mov ($out,$s[0]); }
|
||||
&and ($out,0xFF);
|
||||
@@ -2028,7 +2028,7 @@ sub declast()
|
||||
{
|
||||
# stack frame layout
|
||||
# -4(%esp) # return address 0(%esp)
|
||||
# 0(%esp) # s0 backing store 4(%esp)
|
||||
# 0(%esp) # s0 backing store 4(%esp)
|
||||
# 4(%esp) # s1 backing store 8(%esp)
|
||||
# 8(%esp) # s2 backing store 12(%esp)
|
||||
# 12(%esp) # s3 backing store 16(%esp)
|
||||
@@ -2738,7 +2738,7 @@ sub enckey()
|
||||
&mov (&DWP(80,"edi"),10); # setup number of rounds
|
||||
&xor ("eax","eax");
|
||||
&jmp (&label("exit"));
|
||||
|
||||
|
||||
&set_label("12rounds");
|
||||
&mov ("eax",&DWP(0,"esi")); # copy first 6 dwords
|
||||
&mov ("ebx",&DWP(4,"esi"));
|
||||
|
||||
Reference in New Issue
Block a user