~ubuntu-branches/ubuntu/jaunty/luatex/jaunty

« back to all changes in this revision

Viewing changes to src/libs/zziplib/docs/zzip-crypt.htm

  • Committer: Bazaar Package Importer
  • Author(s): Norbert Preining
  • Date: 2007-09-24 12:56:11 UTC
  • Revision ID: james.westby@ubuntu.com-20070924125611-a8ge689azbptxvla
Tags: upstream-0.11.2
ImportĀ upstreamĀ versionĀ 0.11.2

Show diffs side-by-side

added added

removed removed

Lines of Context:
 
1
<section> <date> 15. July 2002 </date>
 
2
<h2> ZIP Std Encryption </h2>       Standard Zip Encryption is Weak!
 
3
 
 
4
<!--border-->
 
5
 
 
6
<section>
 
7
<h3> Some rationale </h3>
 
8
 
 
9
<P>
 
10
  Some people might ask why not adding standard zip-encryption. Well,
 
11
  first of all the standard zip-encryption has not been strong enough
 
12
  for modern computers, and there are hacker tools that even a 
 
13
  half-literate computer-user can use to crack the password of a
 
14
  zip-archive. In other words: <b> every encrypted zip file can be
 
15
  cracked using freely downloadable helper tools </b>. That's because
 
16
  standard zip encryption is weak regarding modern personal computer 
 
17
  power. Furthermore, adding <em>real</em> encryption is a heavy weight
 
18
  that many people do not need, see the last argument for seeing the
 
19
  standard one is useless anyway, and adding a non-standard one 
 
20
  should not be the case of the standard zziplib either, ye know.
 
21
</P><P>
 
22
  On the other hand, obfuscation is a means to fear off half-literates
 
23
  just as well - there are no <em>premade</em> tools for the obfuscation you
 
24
  can invent from the xor examples. And a hacker that can de-obfuscate
 
25
  such a dat-file is able to dissassemble your program as well - just to
 
26
  remind you that the disassembly of a program will reveal the decryption
 
27
  routine <em>and</em> the decryption key, even for a heavyweight crypt
 
28
  algorithm. Although there is a difference, it just ranges on about times 
 
29
  and exprience, not magnitudes. Remember the old saying: you can irritate
 
30
  some people for some time but not irritate all people for all the time.
 
31
  As for encryption of artwork and AI scripts in games and applications,
 
32
  just keep in mind that the final recipient has the decryption key on
 
33
  his system anyway, just obfuscated. So each such encryption is nothing
 
34
  more than just a clever form of obfuscation, nothing mathematical strong.
 
35
</P><P>
 
36
  Some other people might ask why to obfuscate anyway. Well, the reason
 
37
  is theft. Even people who write opensource free software generally
 
38
  like to get some reward for what they do, some fame or atleast some 
 
39
  sweet dream to have helped the world go a bit easier in the future.
 
40
  As for program text this is quite natural for the programmers who
 
41
  pick up some code from somewhere else - it happens that most of them
 
42
  have gone through some formation and they know how hard it is to get
 
43
  even some lines of code out of your brain. This is not the case for
 
44
  some artwork and AI parameters, people do not have much respect for
 
45
  those - they just pick it up, put it under their umbrella, and 
 
46
  that's it - they even claim they could have done that themselves,
 
47
  and in most cases it is that they never have been really trying to
 
48
  do it and think of it as being comparable to that action-art they've
 
49
  seen on TV. 
 
50
</P><P>
 
51
  Just be sure that there is nothing wrong with obfuscating
 
52
  things for a binary distribution of your program even for the
 
53
  opensource case - the program text itself is an obfuscation in its
 
54
  source form when being compiled into cpu instructions. Still, the
 
55
  interested people can get hold of the source code since you provide
 
56
  it somewhere and actually the original programmers like to hear 
 
57
  from literate people who could help with modifying the project. The
 
58
  same is true for you artwork and AI scripts, the interested people
 
59
  can still see them in the opensource project material, but only
 
60
  those will look who dare to, not just the halfwit next door. 
 
61
</P><P>
 
62
  Well, you do not need to that on the other hand - ID software has
 
63
  shown that it can be very helpful since people will start to
 
64
  write new maps and new bots, pack them and publish them. An open
 
65
  data format is a form of attraction for people who can use a 
 
66
  graphics program and an editor but who do not know how to program.
 
67
  And if you use obfuscation within an opensource program, it is
 
68
  surely enought to just use the xor-format presented here, so that
 
69
  it easy for third people to get involved if they want to, they
 
70
  just have to rewrite their new datapacks with zzxorcopy, and
 
71
  that's it.
 
72
</P><P>
 
73
  As for the non-opensource projects, be aware that there are
 
74
  some ways to even staticlink the zziplib into your project, so
 
75
  you can even hide that you used zip tools to create your dat files.
 
76
  This is well enough for anyone to do - as soon as a hacker will
 
77
  get to the point to notice you used a zip format, he would have
 
78
  had found any other deobfusation or decryption routine as well.
 
79
  If you are frightened, just encrypt the executable with tools
 
80
  you bought from somewhere else. On the other hand, should there
 
81
  be problems or bugs, you have an easier time to find them when
 
82
  they could be caused by your dat entries, and it is again easy
 
83
  to send a fixup file to your clients, since the command line
 
84
  tools are just a breeze compared with some other anti-hacking
 
85
  tools you'll find on the market.
 
86
</P><P>
 
87
  Well, hope this is enough rationale to tell you that I do not
 
88
  see a need to implement anything more than obfuscation within
 
89
  zziplib - if you need real encryption, use real encryption
 
90
  software and its fileformat that supports it, not zip files.
 
91
</P>
 
92
</section></section>