summaryrefslogtreecommitdiff
path: root/Build/source/texk/web2c/luatexdir/zziplib/docs/zzip-cryptoid.htm
diff options
context:
space:
mode:
Diffstat (limited to 'Build/source/texk/web2c/luatexdir/zziplib/docs/zzip-cryptoid.htm')
-rw-r--r--Build/source/texk/web2c/luatexdir/zziplib/docs/zzip-cryptoid.htm106
1 files changed, 106 insertions, 0 deletions
diff --git a/Build/source/texk/web2c/luatexdir/zziplib/docs/zzip-cryptoid.htm b/Build/source/texk/web2c/luatexdir/zziplib/docs/zzip-cryptoid.htm
new file mode 100644
index 00000000000..ee6b120d7f9
--- /dev/null
+++ b/Build/source/texk/web2c/luatexdir/zziplib/docs/zzip-cryptoid.htm
@@ -0,0 +1,106 @@
+<section> <date> 11. May 2004 </date>
+<h2> ZIP Ext Encryption </h2> ext/io used for cryptoid plugins
+
+<!--border-->
+
+<section>
+<h3> Stronger Obfuscation For ZZip </h3>
+
+<P>
+ Some people feel that a simple bytewise xor is not strong enough
+ as an obfuscation for the data. There we have the question how to
+ implant a stronger obfuscation routine to protect that data of an
+ application from artwork theft. Perhaps there is even the idea to
+ use an obfuscation in the range of a real crypt routine - in which
+ case I want to recommend strongly to read the
+ <a href="zzip-crypt.html"> reasoning page </a> why it can not be
+ real encryption and that the resulting obfuscation has an upper
+ limit being <em>lower</em> than the crypt routine complexity.
+</P>
+
+<P>
+ After reminding you of this fact we can go at evaluationg how to
+ implant a stronger obfusction routine to protect your data. The
+ ext/io feature uses a callback routine "read" that must read a
+ block of the given size - for the obfuscation case it will call
+ the "read()" function of the underlying operation system, and
+ the obfuscated block will be deobfuscated before returning it to
+ the caller.
+</P>
+
+<P>
+ In this mechanism there is not asseration at which file-offset
+ the ext/io-read() callback is triggered. That is the reason we
+ have shown obfuscation with bytewise xor-key example - formally
+ this is using obfuscation blocks of 8bit width being aligned
+ on 8bit boundaries in the data file, and our decryption stream
+ is stateless being the same for each obfuscation block (of 8bit
+ width).
+</P>
+<P>
+ In order for a stronger obfuscation we have to break those
+ limitations which are directly derived from the natural way
+ of the handling of files by a contemporary operating system.
+ This is triggered as the call synopsis of the ext/io read()
+ callback matches <em>exactly</em> the one of posix, so that
+ one can use the posix read() function reference as the default
+ for ensuring the most minimal overhead in accessing non-obfuscated
+ zip files.
+<br><small>And btw, the abbreviation "posix" stands for
+ "Portable Open System in Unix".</small>
+</P>
+
+<P>
+ The trick we show here: the first argument of the ext/io read
+ callback is the file descriptor of the underlying operationg
+ system. While we can not add another argument to the ext/io
+ read call we can pick up additional information with the help
+ of that file descriptor id being globally unique even across
+ multiple threads. One solution would make the application map
+ that descriptor id to a special argument but this is often too
+ much overhead: the current file position is enough.
+</P>
+<P>
+ The current file position is managed by the operation system
+ via the file descriptor table. There is a function call to
+ map a file descriptor to the current read position offset
+ usually named "tell(fd)". Since this call is not mandated by
+ posix, you can emulate it with the posix lseek() call which
+ returns the resulting offset after the operation was performed,
+ so we just seek by a zero offset: <br><code>
+ <> <> <> <> #define tell(fd) lseek(fd,0,SEEK_CUR)
+</code>
+</P>
+
+<P>
+ That file offset is measured from the start of the zip archive,
+ not per each zipped file. Remind yourself of that fact when
+ creating your own "zzobfuscate.exe" which should work on the
+ zip archive and not per file before zipping. That is a difference
+ over normal zip archives where the user can atleast recognized the
+ dat file as a zip archive and see a list of files contained in the
+ archive, atleast their names and data start offset.
+</P>
+<P>
+ Now, let's use the file read offset to break the blocking
+ limitations of 8bit/8bit to a larger xor-key. In our example
+ we expand to a 32bit/32bit xor-key giving a search space of
+ 4<>billion keys instead of the just 256<>keys in 8bit blocking.
+ That is simply done by a static 4<>byte xor-key sequence and using
+ modulo operations for alignment. For the 2^X cases any modulo
+ operations shrink to a set of ultra-fast bitwise-and operations.
+</P>
+
+<pre>
+ static char xor_value[4] = { 0x55, 0x63, 0x27, 0x31 };
+ static zzip_ssize_t xor_read (int f, void* p, zzip_size_t l)
+ {
+ zzip_off_t y = tell(f);
+ zzip_size_t r = read(f, p, l);
+ zzip_size_t x; char* q = p;
+ for (x=0; x &lt; r; x++) q[x] ^= xor_value[(y+x)&amp;3];
+ return r;
+ }
+</pre>
+
+</section></section>