Back to the standard "app" module.

This return to "app" instead of "bitmask_android" is due to this reading: https://developer.android.com/sdk/installing/studio-build.html#projectStructure
I'll have to tweak the final apk name in build.gradle.

1 files changed, 131 insertions, 0 deletions

diff --git a/app/openssl/crypto/des/asm/readme b/app/openssl/crypto/des/asm/readme
new file mode 100644
index 00000000..1beafe25
--- /dev/null
+++ b/app/openssl/crypto/des/asm/readme
@@ -0,0 +1,131 @@
+First up, let me say I don't like writing in assembler.  It is not portable,
+dependant on the particular CPU architecture release and is generally a pig
+to debug and get right.  Having said that, the x86 architecture is probably
+the most important for speed due to number of boxes and since
+it appears to be the worst architecture to to get
+good C compilers for.  So due to this, I have lowered myself to do
+assembler for the inner DES routines in libdes :-).
+
+The file to implement in assembler is des_enc.c.  Replace the following
+4 functions
+des_encrypt1(DES_LONG data[2],des_key_schedule ks, int encrypt);
+des_encrypt2(DES_LONG data[2],des_key_schedule ks, int encrypt);
+des_encrypt3(DES_LONG data[2],des_key_schedule ks1,ks2,ks3);
+des_decrypt3(DES_LONG data[2],des_key_schedule ks1,ks2,ks3);
+
+They encrypt/decrypt the 64 bits held in 'data' using
+the 'ks' key schedules.   The only difference between the 4 functions is that
+des_encrypt2() does not perform IP() or FP() on the data (this is an
+optimization for when doing triple DES and des_encrypt3() and des_decrypt3()
+perform triple des.  The triple DES routines are in here because it does
+make a big difference to have them located near the des_encrypt2 function
+at link time..
+
+Now as we all know, there are lots of different operating systems running on
+x86 boxes, and unfortunately they normally try to make sure their assembler
+formating is not the same as the other peoples.
+The 4 main formats I know of are
+Microsoft	Windows 95/Windows NT
+Elf		Includes Linux and FreeBSD(?).
+a.out		The older Linux.
+Solaris		Same as Elf but different comments :-(.
+
+Now I was not overly keen to write 4 different copies of the same code,
+so I wrote a few perl routines to output the correct assembler, given
+a target assembler type.  This code is ugly and is just a hack.
+The libraries are x86unix.pl and x86ms.pl.
+des586.pl, des686.pl and des-som[23].pl are the programs to actually
+generate the assembler.
+
+So to generate elf assembler
+perl des-som3.pl elf >dx86-elf.s
+For Windows 95/NT
+perl des-som2.pl win32 >win32.asm
+
+[ update 4 Jan 1996 ]
+I have added another way to do things.
+perl des-som3.pl cpp >dx86-cpp.s
+generates a file that will be included by dx86unix.cpp when it is compiled.
+To build for elf, a.out, solaris, bsdi etc,
+cc -E -DELF asm/dx86unix.cpp | as -o asm/dx86-elf.o
+cc -E -DSOL asm/dx86unix.cpp | as -o asm/dx86-sol.o
+cc -E -DOUT asm/dx86unix.cpp | as -o asm/dx86-out.o
+cc -E -DBSDI asm/dx86unix.cpp | as -o asm/dx86bsdi.o
+This was done to cut down the number of files in the distribution.
+
+Now the ugly part.  I acquired my copy of Intels
+"Optimization's For Intel's 32-Bit Processors" and found a few interesting
+things.  First, the aim of the exersize is to 'extract' one byte at a time
+from a word and do an array lookup.  This involves getting the byte from
+the 4 locations in the word and moving it to a new word and doing the lookup.
+The most obvious way to do this is
+xor	eax,	eax				# clear word
+movb	al,	cl				# get low byte
+xor	edi	DWORD PTR 0x100+des_SP[eax] 	# xor in word
+movb	al,	ch				# get next byte
+xor	edi	DWORD PTR 0x300+des_SP[eax] 	# xor in word
+shr	ecx	16
+which seems ok.  For the pentium, this system appears to be the best.
+One has to do instruction interleaving to keep both functional units
+operating, but it is basically very efficient.
+
+Now the crunch.  When a full register is used after a partial write, eg.
+mov	al,	cl
+xor	edi,	DWORD PTR 0x100+des_SP[eax]
+386	- 1 cycle stall
+486	- 1 cycle stall
+586	- 0 cycle stall
+686	- at least 7 cycle stall (page 22 of the above mentioned document).
+
+So the technique that produces the best results on a pentium, according to
+the documentation, will produce hideous results on a pentium pro.
+
+To get around this, des686.pl will generate code that is not as fast on
+a pentium, should be very good on a pentium pro.
+mov	eax,	ecx				# copy word 
+shr	ecx,	8				# line up next byte
+and	eax,	0fch				# mask byte
+xor	edi	DWORD PTR 0x100+des_SP[eax] 	# xor in array lookup
+mov	eax,	ecx				# get word
+shr	ecx	8				# line up next byte
+and	eax,	0fch				# mask byte
+xor	edi	DWORD PTR 0x300+des_SP[eax] 	# xor in array lookup
+
+Due to the execution units in the pentium, this actually works quite well.
+For a pentium pro it should be very good.  This is the type of output
+Visual C++ generates.
+
+There is a third option.  instead of using
+mov	al,	ch
+which is bad on the pentium pro, one may be able to use
+movzx	eax,	ch
+which may not incur the partial write penalty.  On the pentium,
+this instruction takes 4 cycles so is not worth using but on the
+pentium pro it appears it may be worth while.  I need access to one to
+experiment :-).
+
+eric (20 Oct 1996)
+
+22 Nov 1996 - I have asked people to run the 2 different version on pentium
+pros and it appears that the intel documentation is wrong.  The
+mov al,bh is still faster on a pentium pro, so just use the des586.pl
+install des686.pl
+
+3 Dec 1996 - I added des_encrypt3/des_decrypt3 because I have moved these
+functions into des_enc.c because it does make a massive performance
+difference on some boxes to have the functions code located close to
+the des_encrypt2() function.
+
+9 Jan 1997 - des-som2.pl is now the correct perl script to use for
+pentiums.  It contains an inner loop from
+Svend Olaf Mikkelsen <svolaf@inet.uni-c.dk> which does raw ecb DES calls at
+273,000 per second.  He had a previous version at 250,000 and the best
+I was able to get was 203,000.  The content has not changed, this is all
+due to instruction sequencing (and actual instructions choice) which is able
+to keep both functional units of the pentium going.
+We may have lost the ugly register usage restrictions when x86 went 32 bit
+but for the pentium it has been replaced by evil instruction ordering tricks.
+
+13 Jan 1997 - des-som3.pl, more optimizations from Svend Olaf.
+raw DES at 281,000 per second on a pentium 100.
+