***********************Message to the user *********************************
Klein Nordende, june 28th,
2016
Dear user,
Academic Signature is a special software trying to provide an
incentive for you to use the wonderful possibilities of digital
signatures.
(As a side effect, you also get up to 1024 bit elliptic curve
encryption. Encryption that strong is inofficially banned in the
five eyes countries, there they are limited to 521 bit by their
orwellian administrations.)
Signing a document is a very personal act possibly implying
serious consequences. Thus Academic Signature doesn't do
anything "automatically" or "in the background" without your
explicit order and consent.
You have full manual control over each step the software
performs. After signing, you are responsible to manually hand
out digital documents and the detached corresponding signatures
if and when you find it appropriate. You will do this manually:
Attach them to an email and manually send it, or copy them onto
a memory stick and hand it out to the recipient, or -possibly-
withhold them at the last split second for another double
checking.
Installing or updating "Academic Signature" is at the same time
more cumbersome but also more transparent than with "usual"
programs.
For competent usage it is absolutely necessary that you know the
whereabouts of your files on your hard disk. (Microsoft and
Apple try to lure you into getting lost there......)
Now I will describe how to freshly install Academic
Signature.
************************************
INSTALLING From the Windows
installers:
This is the easy one.
Just click on the installer and do what you are told. Depending
on system configuration you may have to do this with
administrator privileges.
INSTALLING From the binary(Linux or Windows):
Unzip into an empty directory of your choice, preferably in a
cryptographically protected(e.g. by truecrypt) virtual drive.
Run the executable. You may have to mark it as an "executable
file" depending on the platform you are running it with.
Thats it.
You may wish to MANUALLY add shortcuts for starting the program
and employ an Icon to click on as starter. But you might as well
decide to have it hidden somewhere on your hard disk deeply
buried in your directory structure.
The program should not be "registered" to the system in any way.
It can/should live independently with as little as possible
"embedding" in the OS, preferably in an encrypted hard disk
domain. I recommend that windows users should apply the usual
good practice and scan it for viruses prior to use.(The
cryptographically protected parts are clean, I promise!)
Don't forget that you may have to mark the new program-file as
"executable" on some platforms.
If you are just updating from a prior version, just replace the
executable file and leave the previous “secrets_x" folder as is
to retain access to your key files, password and settings.
****************************************************************
INSTALLING
From Source Tarball(Linux):
0.- Make sure, you have the wxWidgets the dev-libraries "libwxgtk3.0-dev" and
"libwxbase3.0-dev" (or both in version 2.8) and a current
C++ compiler (e.g. g++) installed on your system.
In case you want to run it on a legacy wxWidgets 2.8, you
have to also uncomment the #define in line 27 of dolonu.h (
//#define WX28 ) or insert the line if missing.
1.- Download the tarball and
my digital signature. Verify the signature using my
corresponding public
key.
2.-
Usual procedure:
Unzip the tarball, open a terminal, change to the project
directory, type "./configure".
If there are no errors type "make". If make succeeds, you may
already use the local copy of academic signature named
"aca_sig".
Type "sudo make install" if you want to install the binary in
/usr/local/bin and copy the needed file structure to your home
folder.
3.- You
may use one of the supplied icons to set up a link from your
preferred desktop environment or the main menu manually.
INSTALLING From Alternate
Source(Linux, manual install in protected drive):
0. -Download the respective archive and verify its integrity and
authenticity with the GnuPG signature(or the elliptic curve
signature if you have a prior version already installed).
Make sure, you have wxWidgets version 3.0 and gtk2.0 installed
on your system.
Unzip into an empty directory of your choice.
Edit the longnumber arithmetics header file dolonuxx.h and on
the first page according to your system (32bit or 64 bit Linux)
outcomment the define that is inappropriate and make sure the
appropriate one is active
(default is linux 32)
In case you want to run it on a legacy wxWidgets 2.8, you have
to also uncomment the #define in line 27 of dolonu.h ( //#define
WX28 ) or insert the line if missing.
1.- Open a terminal and cd into the topmost directory
("aca_sig_bXX_sout" - replace XX by version number).
2.- Call "make release". The executable "aca_sig_xx" should be
created in this directory.
3.- Move the executable, the png-files used by the executable
and both subdirectories "x_secrets" and "key_tray", to a
place of your choice, preferably in a cryptographically
protected(e.g. by truecrypt) virtual drive. Make sure a file
named local.flg is present in x_secrets.
A) Optionally step 3 can
be replaced by calling "sudo make install" for a fresh install
(watch out your old installation with all key info will be
overwritten).
B) If a previous
installation exixts step 3 can be replaced by calling "sudo make
update" - this will just replace the binary.
C) You may also safely
work with the local copy without installing on the system level.
4.- Manually place one of the included icons (e.g.
"aca_sig_icon.png") on your desktop and link it to the
executable for your convenience.
5.- You are done and may now execute the binary to enter the
hatching procedure.
Anytime- You may always replace the current "x_secrets" folder
by the inital version to enter into a new hatching process and
reinitialize Academic Signature.
********************************************************************************
Remark: You can also use the local binary in the project folder
without installing at system level in the proper place for
binaries. In this case make sure, that a file named local.flg is
present in "x_secrets". This directs Academic Signature to use
the local configuration subfolders "x_secrets" and "key_tray".
This allows for multiple parallel installations of different
versions with unique password, keyfiles, PRNG etc. Removing or
renaming local.flg directs Academic Signature to search for
configuration files at the standard location
~/.config/aca_sig/ . In this case you switch to
sharing password, keyfiles, PRNG etc. with the standard
installation.
********************************************************************************
Sincerely yours,
Michael Anders
********************************************************
CHANGELOG:
I will keep on searching for flaws and will promptly post
security updates after identification of weaknesses..
changes to version 55:
A new key derivation function for extrinsic NADA-Caps has been
introduced.
Adversaries with large resources, like state funded agencies,
are capable of fabricating large numbers of ASICs to
parallelize password cracking. In order to aggravate dictionary
attacks carried out with such gear, the neccessary chip surface
per cracking circuit may be increased. The most straightforward
method to achieve this is using a key derivation function with a
large memory footprint.
The legacy key derivation function used in academic signature's
login procedure and in symmetric encryption already has
formidable memory and number crunching requirements. Using
legacy elliptic curve stretching with a 1024 bit elliptic curve
already requires at least 4096 bit storage space.
In order to hike up this limit further, a new key derivation
function, suitable for up to 2 GByte block size, was introduced.
It is used in Academic Signature NADA-Cap protection for
extrinsic caps with a block size of 500 kilobyte. Intrinsically
it needs at least a second consecutive block of 500 kilobytes.
Thus an attacker attempting to parallelize NADA-Cap password
cracking needs to assign at least a Megabyte of storage space to
each circuit and has to supply fast integer arithmetics
capabilities (modulo reduction and multiplication) for each
cracking circuit.
For an intermediate time, Academic Signature will offer a
selector box in the en/decryption dialogs to use the legacy
capping key derivation function. Thus the contents of previously
encrypted NADA-Capped Files will remain accessible to the
legitimate user. The legacy key derivation function still being
better than state of the art, I did not see any necessity to
abandon that variant for login or symmetric encryption.
changes to version 54:
This version has mainly internal changes in the build system,
that allow to continue developing the windows binary under a
Windows10. Please note: In Windows10, locking of critical memory
sections apparently cannot be achieved any more via the API-call
"VirtualLock". The upgrade step from Windows7 to 10 seems to
come ever again with a further regression in user security and
controllability.
Besides some renaming of menu entries and a dialog guided
encouragement in the hatching dialog to create a first keypair
upon first installation, the changes will be hardly noticeable
to the user.
changes to version 53:
Two recent developments have driven new developments in academic
signature:
1. The user base is increasing and there is a growing
need for convenience in handling public key lists.
Thus I rearranged the Module dealing with public keys. An
"export" function was newly introduced to be able to remove
rarely used keys and store them in some remote archive of the
users choice. When needed they can be reimported again. I
recommend to sign the storage archive in order to prevent
tampering with the swapped out keys. Furthermore functions for
rearranging the key order in the list have been introduced.
2. There is increasing political pressure in my
country(Germany) to criminalize encryption, further deteriorate
civil rights and march into an Orwellian society. Thus the day
may be near when we will all need steganography, hide
our enforcement of privacy and need "plausible deniability".
To get closer to this defense I introduced the concept of a
"NADA Cap". NADA stands for No Access Data Available. A NADA Cap
is an additional layer, which protects all format information
and access data. A capped cipher file is indistinguishable from
noise in toto. You can feed it to whatever "Die the Hardest"
test of randomness without detecting the slightest sign of
deviation from randomness. (Achieving this beautiful, perfect
cipher state in Academic Signature gave me deep satisfaction.)
Thus you will now always be able to claim your EC-cipher is just
data from your last SETI search round, or you XOR it with your
favourite Michael Jackson video and claim the cipher were just a
one time pad for your illegally downloaded video. A featureless
cipher is the ideal input for any steganography tool. There is
always a good explanation for noise in your pictures or audio
files if it truly looks like noise.
Upon producing en elliptic curve cipher you can now tick a box
"apply NADA Cap". If you do so, you will be asked for a NADA Cap
key. If you use "intrinsic" the Cap key will be
deterministically set from the public key data of the recipient.
The "public key" should then be kept somewhat confidential, like
confidential in the group of say your 10 coworkers. The
recipient has to guess then, which of his private keys the file
was encrypted to. Alternatively you could share a newly agreed
on keyword within your group and keep that confidential. In this
case you may even have your plain public key accessible to
anyone. Please note, that this would also render your ECC-cipher
secure against Shor's Algorithm which may become a threat after
the future advent of Quantum Computing. Without knowledge of the
ecc-header file, quantum computing doesn't help them shit.
As a consequence I removed the previous option "hide key ID"
since this was much weaker, didn't conceal the nature of the
file as a cipher and thus became obsolete.
On January 20th, 2016 I uploaded an
improved version: Due to a regression(unbuffered IO in some
routines), using AES in conjunction with elliptic curve
asymmetric ciphers had been unnecessarily slow - this was fixed.
Also on Jan 20 I introduced Payload Size Camouflage (PLSC) also
for symmetric ciphers. Since these were minor adjustments, the
version number 53 was retained.
Please note: Symmetric PLSC'ed ciphertexts can only be
deciphered with current versions of Academic Signature(later
than jan 20th 2016).
changes to version 52:
There was one mayor change. I added the new algorithm "chimera".
Chimera is what it says, it is a chimera of two algorithms. In
fact it is a pile of the threefish cipher xored with a single
branch fleas_x, applied in counter mode. I introduced that
cipher to address several possible security concerns.
1.) Threefish is a nice cipher, yet it is a conventional
substitution permutation network designed by a group of people
who partially live under US jurisdiction and one of them even is
employed by Microsoft. Let me call this a social concern.
2.) Threefish has a rather regular, simple structure and has a
fixed mixing pattern, which some cryptographers view as a
potential vulnerability. This point is purely technical.
3.) Although Threefish has a larger block size and a larger key
space than other conventional ciphers, in my view they are still
too small.
4.) Flightx or my other newly developed algorithms are of a
completely different type than traditional ciphers and have to
my knowledge not yet been rigorously attacked by other
cryptographers.
5.) I am completely unknown in the cryptographic community. This
point and partially also the last one are social concerns again.
A pile or a "chimera" of these two
algorithms is at least as secure as Threefish. If my Flighx were
completely trivial to crack(it is obviously not), the security
would reduce to the security of Threefish. If Threefish were
trivial to break(it has been rigorously studied in the SHA3
competition), we had still the security of flightx. If both
would contain slight vulnerabilities, the chimera would still be
completely secure. I like to think of these algorithms as
fighters, covering each others back in the Chimera. Flightx
brings the large block size, the large key size (4 kilobit) and
the key dependent mixing pattern. Threefish brings the fame of
its developers and the speedy diffusion of a substitution
permutation network. Flightx can be used singly pathed since
Threefish is used in place of the second path. This is
sufficient to block "backtracing" and allows enhanced speed.
Thus Chimera is somewhat faster than a full two pathed Flightx,
but (of course) is slower than its component Threefish alone.
changes to version 51:
There were just two changes. First, I extended the dialog
"settings" to include a selection of the favorite defaults for
hash and enciphering algorithms and routines to refer to these
settings in all the other dialogs. That was easy.
Secondly I changed the ecc-deciphering procedure such that now
academic signature does just one read/write pass. Before,
plaintext, ciphertext and intermediate states were rewritten,
split and rearranged multiple times. This used to be a
negligible overhead on fast storage media and allowed for a more
orderly code and better maintainability. However on slow storage
media with large files in the gigabyte range the logically
unneccessary rewritings were painful. So I finally wrote these
special "big lump routines" featuring badly intertwined
decryption, reading, evaluation and writing. These are included
only for the counter mode encryption modes so far(and I'll
probably leave it that way). One pass ecc encryption comes in a
natural sequence and had been included long ago.
changes to version 50:
In response to a request by a user(Joao) I added the cipher
Threefish and the SHA3 finalist Skein. I used the Skein
and Threefish API by Werner Dittmann and the code posted by him.
(I don't know you, Werner, but thanks a lot!) What I like about
these new algorithms is
a) that they offer somewhat larger bit lengths than what the NSA
favors and
b) the cipher is tweakable.
c) I understand that users may prefer algorithms from scientists
with a high reputation in cryptography and ciphers that have
been analyzed by other experts.
You may notice that I set up Threefish as default cipher for the
windows version while I left Fleas in counter mode for the linux
version. This decision was not made by accident.
In addition I somewhat reduced and rearranged the list of
offered ciphers and removed some minor functionality bugs. The
new mode "flightx" was added, which is a successor of "flight"
and incorporates some computationally cheap improvements of the
safety margin.
changes to version 49:
I renamed some dialog entries for clearer language and fixed an
embarrassing bug within my binding of HongJun Wu's JH Hash.
Please excuse that in the wake of this fix, JH evaluation
results are now corrected with respect to previous version's
such that JH signatures from builds previous to 01/24/15 won`t
verify in more recent versions and vice versa.
I apologize for the inconvenience.
Version 48 was an intermediate where only the build system had
been restructured.
changes to version 47:
I changed the defaults for enciphering. Furthermore I introduced
an especially fast cipher by lowering the safety margin to a
level that I expect to still be safe. The mode is called
"flight"(=fleas-light). Because of the low safety margin, I only
use it in counter mode where known plaintext attacks are
irrelevant. Please do not use this mode yet in matters of life
and death. I introduced the mode to get close in speed to
AES(Self referential scrambling always has a speed disadvantage
against a small blocksize, fixed optimized pattern permutation
substitution network. So AES is still somewhat faster.)
There is a twofold objective with introducing "flight":
1.) I want a fast, US-independent option to encipher gigabyte
size files that can be comfortably used to encipher e.g. large
videos.
2.) I want to encourage amateur and professional cryptanalysts
to attack the algorithm - there might be some chance to break
"flight". If I had virtually unlimited access to computer power
and to an army of programmers with exceptionally high
frustration tolerance, I would know how to try the attack.....
So if you want to hide your girlie pics from your mother or
small tax sins from the internal revenue office, please use
"flight". If you are an american serviceman and communicate with
wikileaks, you better stick to e.g. Fleas_c for now(and
communicate from a TAILS of course).
For elliptic curve asymmetric ciphers I introduced what I call
"payload size camouflage" (PLSC). You will notice that different
enciphering runs will produce differently sized ciphers. This is
to disallow resourceful spoofing organizations like the NSA to
derive knowledge about plaintext equivalence for differing
ciphertexts by large scale interceptions from the web and
subsequent statistical analysis. This is about metadata
protection.
changes to version 46:
a) Previously the plain header and plaintext of elliptic ciphers
had to be concatenated first and rewritten to disk. This took
some time when enciphering files of gigabyte size. Now
enciphering is done in a one pass process. (Deciphering is
unaffected.)
b) A directory once selected for a signature or an
en-/deciphering process is remembered and used as a default
directory for the next signature or en-/deciphering process.
Furthermore some buffers have been increased to consistently
allow for a full extreme 4 bytes/chacter utf8 encoding
everywhere.
changes to version 45:
a) The option to produce deterministic signatures is made
accessible from the dialog "Sign Elliptic". It will ask for a
determining codeword. If a specific word is used consistently,
this enables the user to find out, if a "good" signature was
illegitimately created by an external entity knowing the private
key. The signature will simply be different from the codeword
determined deterministic signature. This cannot not be proven,
however, to other parties and is just for private intrusion
detection. The determining codeword can be short and simple. The
standard argument to introduce deterministic signatures is that
it makes you independent of access to good random numbers. This
does not apply here, Academic Signature's PRNG is sound.
b) Symmetric ciphers file naming convention has been changed
from .ciph to _ciph to ease confusion for windows users. Windows
seems to be hiding secondary file name extensions if it can't
assign a type to it and thus misleads users.
c) I introduced full UTF8 treatment of special characters in
keyword evaluation. If symmetric cipher's keys or the login
keyword contain special characters and were set with versions
prior to 45, wxWidgets treatment was not well defined and might
have differed between platforms and wxWidgets versions. If you
have trouble logging in after upgrade or cannot decipher legacy
symmetric ciphers, you may try ticking the box "legacy
interpretation of keywords/passphrases". The main access
keyword will automatically be converted to the new full UTF8
processing upon successful login with the legacy method.
changes to version 44:
I fixed a minor functionality bug with secret key export that
surfaced in the wake of allowing stretchfactors other than one
for login. Furthermore I introduced user guidance to suggest
adding 4 bytes of public key material to the key ID. Of course
this can be overridden manually by the user to set any ID.
changes to version 43:
I changed the assignment of hashes for the authenticated
symmetric encryption to the new Fleas_b/c/d, respectively. Older
symmetric ciphers with the old assignments may now throw a mild
warning about unusual hash assignments upon deciphering. The GUI
is now based on wxWidgets3.0 (formerly 2.8.12).
I included the new hash algorithm JH written by Hongjun Wu for
ECDSA signatures and time stamps. It is a finalist of the last
SHA3 competition. I like it, because it could be easily included
in my code and it is written by a single individual(Hongjun) who
got the guts to enter into the competition without an army of
big name coworkers. The way the winner Keccak had finally been
selected was generally regarded with deprecation. Sorry, Keccak
is probably good, but my distrust towards the NSA/NIST is so
deeply engraved that I just cannot implement the version of
Keccak mitigated by the NSA.
I found and fixed an embarrassing bug in the Fleas_b/c/d
implementation as hash and as hmac on may 15th 2014. Prior
versions of academic Signature should be updated as soon as
possible since Fleas_b/c/d hash output of long files did
change after may 16th and signatures made with these hashes in
the buggy version may not be verifiable any more.
SORRY! This felt like my personal heartbleed disaster. Since
they haven’t been online for long I decided not to blacklist
them and replace them by newly named hashes but rather just fix
them quickly. Unfortunately Fleas_b had been used for file
protection internally - be prepared to have an integrity
warning thrown at you once after upgrading to the fix. I
will not suppress the emission of the warning since this might
enable a new albeit temporary attack path. Safety is more
important than image polishing :-)
Additionally on may 16th I reduced and rearranged the collection
of offered hashes in the "encipher_n_authenticate" dialog.
changes to version 42:
A critical re-evaluation of all cryptographic functions was
undertaken. It revealed the chance for a new type of a highly
specific attack on the Fleas Hash and MAC functions. To get a
better safety margin, new routines "Fleas_b, Fleas_c, Fleas_d"
have been introduced to replace the algorithms "Fleas_lb,
Fleas_lc, Fleas_ld". I didn't consider the success chances for
this attack sufficiently threatening to blacklist the old
routines, so they are still accessible. Use of the old hash
functions should be gradually phased out, however. No new
threats have yet been found for the legacy ciphers. I still
consider them safe as rock. I keep sticking to this
version number 42 since I really like this number...
Some additional minor enhancements have been introduced in
version 42. Now those guys who like special characters in
filenames like ".../grönland muße.klöter didöter" will be served
perfectly by academic signature since full weirdo character
support has now been put into place.
changes to version 41:
A background picture of an elliptic curve was introduced in the
main window. “Hardened Symmetric Encryption” has been updated to
provide for cipher integrity in addition to secrecy. From this
version 41 on, this new mode is also used for enhanced
protection of public key info on your computer. Upon first usage
of the new version the old public key file will be converted to
the new cipher and will cause a warning message prior to
conversion from the unauthenticated cipher.
Since “Academic Signature” seems to gain visibility dramatically
since July 2013, some inconveniences in importing external
public keys became noticeable. Thus the first small usability
improvements have been included now. More are to follow in
subsequent releases.
changes to version 40:
Improvement of memory locking to prevent storage of secret
information in the swap, forced change of the salt in hardened
symmetric cryptography upon counter mode enciphering and
introduction of private public crosscheck for used key ids.
changes to version 39(38 was an
unpublished intermediate):
More symmetric algorithms were introduced. Now we can use the
2,3,4-Paths Fleas backbone(with 2kbyte blocksize) in countermode
as "F_cnt_lb, .._lc and .._ld, respectively.
Over Christmas break 2012 I found some time to work on the speed
of the basic arithmetic algorithms again - mainly multiplication
and division. The improvements(and gained insights) were
substantial, so there is a new version to be uploaded. For even
the largest domains (e.g. a newly created 1024 bit ECC-domain),
signature and verification are performed within the blink of an
eye now.
In retrospective, introducing parallelization in ver37 was fun
but was not really necessary....
Swapping critical memory sections to hard disk has been
blocked(moreless blocked in windows, to be honest) from the
current version on.
changes to version 37:
I introduced multi thread calculations to make use of multi core
processors for elliptic curve operations. This speeds up the
parallelizable signature verification by a factor of 2 (if
hashing time is negligible and adequate system resources are
available).
Successively introducing multi threading in other program
sectors may yield further speed improvements in the future.
Reviewing algorithms for parallelizability is fun.
Furthermore a counter mode enciphering algorithm based on the
Fleas_lc oneway function is introduced. As an add on to textbook
counter mode, the start number is not given in the plain but is
encoded in a traditional Feistel structure. In counter mode the
relevant enciphering operations up to the last xoring are
completely independent of the plaintext. This renders chosen
plaintext attacks irrelevant. I did not include an AES counter
mode because of the meager block size(16 byte) which I feel
requires the additional entropy of the plaintext to achieve
reasonable safety.
changes to version 33:
Minor fixes, mainly typos in the menu entries and a few marginal
improvements in the arithmetic routines. A warning will be
issued now if a signature employing the insecure Fleas_l-Hash is
being checked. Another new Hash and Enciphering algorithm is
introduced namely "Fleas_lc". This is basically a
cleanup-update, since 32 had been issued as a fix in a rush
prior to the summer break.
changes to version 36(34-35 were unpublished intermediates):
Another marginal speed improvement of some percent. Using
multiple processor cores and distributing calculations (multi
threading) is still an obvious future option for further
improvements. I don't feel hard pressed to it though since speed
of the ECC operations should be no issue any more. Changing the
arithmetics of subtraction and addition to assembler coding for
using the processors carry bit directly, could get the last 30%
possible speed increase. Since this would open a can of worms
for maintenance on different architectures I will definitely not
do that.
This is a major update introducing the comfortable use of
multiple domains and domain portfolio management. The NIST
curves have been omitted to avoid legal issues. Domains smaller
than 200 bit have been omitted to ensure future safety. It is
easily possible to add domains of your choice by manually
editing the file "ellipse_list.els" in the secrets folder.
Some default settings and the background color of the Frame were
changed.
changes to version 32:
After a phase of analyzing the Hashes I found an embarrassing
flaw in Fleas_l-hashing(and an intermediate version of Fleas_lx)
so that I had to take it off the menu for signing. Fleas_l
signatures can still be verified, they are insecure though. The
fixed Fleas_lx and Fleas_l3(like the earlier ones) adhere to the
Merkle Damgard hash construction and furthermore include a
hardening against what I call "early cancellation attacks". No
ciphers were affected and e.g. I consider the Fleas_l cipher
safe.
Additionally new enhanced enciphering algorithms were introduced
(Fleas_ls and Fleas_l3).
changes to version 31:
there was a vulnerability to so called "existential forgery" of
signatures using the former Fleas hashes. (By no means critical,
it was possible to add about a couple of the right gibberish
characters in the first block of the document and still retain a
valid signature). This was easy to fix and since there's no
excuse not doing it, we are at version 31 now. Now the fixed
Fleas_lx hash is offered in signatures and timestamps, but all
the older ones can still be verified. Signatures using sha2 or
sha4 were not affected.
Well we are at version 30 now.
There has been another small performance increase (10-15%
faster) by introducing Jacobian projective coordinates and using
the Koblitz expansion - the low hanging fruits had already been
harvested before. This was fun.
Some misleading dialog texts have been improved. The main work
had been done in ensuring a proper integration into the
respective OS(Windows or Ubuntu) to allow for standard placement
of the binary and the configuration files. A whole bunch of new
icons has been created. All of this was boring.
Version 27(Upload February
25 2012):
Reviewed elliptic curve calculation routines for efficiency and
added routine for Koblitz expansion of point factors to decrease
hamming weight in point multiplication. Execution time is half
of version 26 now. Removal of some minor glitches.
Version 26(Upload February 6 2012):
Removed a memory leak and added the menu "Hardened Symmetric
Crypto" employing salting and elliptic curve stretching as
countermeasures against dictionary attacks on symmetric ciphers.
The general stretching method was somewhat changed also. "eve"
or "Lisa" may still be a bad idea for a password, but something
like "adam&eve" would already blow the fuse for Oscar. Each
guess will take him about a second(two on win7) for stretch
factor one :-)
Version 25:
For completeness I made GnuPG enciphering accessible through the
Academic Signature GnuPG GUI.
Version 24:
Some new features were introduced. I abandoned building separate
versions with and without elliptic enciphering and will only
post one version with all features activated. For GnuPG
aficionados(and other users who frown on GnuPG's zero usability
concept...) I included a limited GnuPG-GUI. Now they may also
use their favorite RSA or DSA PGP-Keys for Open-PGP signing and
verifying.
A note of caution:
GnuPG is a wonderful tool but is not made for the concept of
"mosaic of trust". Never ever prove signatures against public
keys "just taken from some server..." without personally
convincing yourself they really belong to the presumed owner!
GnuPG can be described as being "signature centered": We have a
signature here, can we find some key and some document that
prove true as a triple? If so, GnuPG happily informs the user
about having found a "good signature".... I furthermore
disapprove of GnuPGs abusing a signature as pinboard - for
clarity information does belong into the document - a signature
is a signature is a signature..... A time stamp is something
other than a signature and only makes sense in a three party
setting! Many more objections are in store on my side - but
GnuPG is established, compatible and certified(is it?).
I recommend to stick to academic signatures modern elliptic
curve procedures though.
There was a major update to version 22 mainly concerning
passphrase handling:
In order to reduce vulnerability towards dictionary attacks on
the passphrases, I introduced stretching (using elliptic curve
calculations) and salting with a 512 bt salt. Necessarily this
renders updating from prior versions somehow complicated.
Furthermore some malicious user behavior(like deleting/renaming
needed directories while aca_sig is running) was caught in oder
to avert crashes.
Version 20 mainly introduces the
new time stamping feature. Since in timestamping three parties
are actively involved(client, stamper="Trent" and prover in
contrast with just two parties in signing/proving), I decided to
suppress the stamp generation feature in the uploaded versions.
Trent, the time stamper has to:
- act responsibly in general,
- manually sign documents, ciphers (or hashes for very large
files) for his/her clients,
- have a neutral relationship to the clients(otherwise the stamp
isn't worth a penny),
- protect his/her private key with due diligence,
- be ready to keep the public part available online for an
extended period(more that ten years)
- has to be a widely acceptable witness.
- If challenged, trent may even be morally obliged to testify in
court that timestamping was done with double checked and true
time and date and that the private key has not been compromised
to his/her knowledge so far.
People not willing to go that far should not stamp. I am willing
to do that in the near future for my students and
graduates(university of Applied Sciences Wedel). As long as my
resulting workload is not exceeding a tolerable limit(may be 10
stamps a week), I will also timestamp for other users of
academic signature - of course ensuring the appropriate lifetime
and validity of stamps also for other users. (Under normal
circumstances I will obviously not be able to testify in court
outside of the FRG, if the timestamp is challenged.)
People who do want to go that far may send me an e-mail,
disclose their position in the education business to me and
receive the "Trent" version directly from me in response.
Since these matters are getting more official and may in extreme
cases end up in court, I sadly abandoned the practice of setting
my wonderful new and fancy "Fleas"-Algorithms as default and
rather use sha2(512 bit). Thus timestamps generated with the
default parameters exclusively rely on officially approved
algorithms (sha4 and ECDSA).
Caution: I may have to warn you, though, that the program
academic signature itself is not officially approved, it is
supplied for use in the academic community and I do not have any
intention to go through the pain and financial bleeding of
official approval or accreditation.
(The bureaucratic "colleagues" of the German academic
accrediting circus did strain my nerves more than enough for
accrediting my/our curriculum "Industrial Engineering" at
Fh-Wedel - I definitely do not need more of this committee
baloney - it was part of my job, however, so I had to endure
that waste of time.)
Version 19 does fix an
embarrassing security flaw. When symmetrically enciphering with
Algorithms Fleas_4, 5, x2 and x5 plaintext information of about
half the amount of keysize -16 byte in most applications- may
leak from the first block of the cipher. This bug has been fixed
for the newly introduced algorithms Fleas_o2, Fleas_o5 and
Fleas_l. I consider Fleas_o2 as secure with reasonable
redundancy in security, Fleas_o5 is the "overkill-version" and
Fleas_l is a lean version optimized for speed without breaching
security. A thorough statistical analysis gave me enough
confidence to lift some of the overkill that is not really
necessary in the light of the results of such analysis.
Furthermore the "o-versions" have been optimized against the
x-versions to reach statistical equilibrium quicker without
reducing the applied number of rounds.
Using the 4,5 and x-versions actively has been disabled, they
are still available though in deciphering or signature
verifications to ensure backwards compatibility. I consider the
security flaw as not serious enough to demand blacklisting.
Private key ex/import, however, has consequently been switched
from x5 to o5 enciphering in the top enciphering shell.(The
inner enciphering shell operates still with old Fleas_1_8, which
I consider a little slow but still secure as rock).
AES has been introduced to add an officially endorsed
enciphering method for chicken who don't dare to use my new
algorithms.
The code for AES has been taken from the polar ssl website
again. The polar-SSL library is used only for the bare ECB-Mode,
the framework for CBC-Mode, CPA-blocking and head padding is
supplied by my routines. Tail padding is not necessary since
streaming data are not an issue in the context of academic
signature. So I pad at the head and use the flexible length
random number pad as IV. Thus AES-ciphers from Academic
Signature are not cross-compatible with aes-ciphers of other
packages. My key preparation to cast the variable length
passphrase into the fixed length AES-Key is different from
other's and unique anyways.
Additionally the algorithm sha-512bit(named sha4) has bee
included as an option for hashing.
Version 17
does introduce some "security engineering" enhancements.
Academic Signature logs out automatically after 15 minutes. To
continue security relevant work, the user will be redirected
to the login procedure first. This is to limit the danger from
carelessly forgetting to close Academic Signature and leaving
it in the logged in state. Additionally if a careless and
negligent user leaves dialog boxes open, which concern private
keys or even show private keys in the clear, they are closed
automatically after some minutes of idle time. I have mixed
feelings about these additions since such users should
possibly not use serious security software. These additions
attempt to catch blatant misbehaviour that should not happen
in the first place. It is principally not possible to fully
protect against user misbehaviour and attempts to do so
partially will hamper usability for sound users.
Version 16 has coloured, rearranged dialogs. The exit
button is now always in the upper left corner. Red background
denotes dialogs concerned with private keys and should NEVER be
worked on in the presence of other people. Green background
denotes operations involving public keys. They are not secret,
but their integrity must be rigorously protected. Thus they are
also of prime security relevance.
Double enciphering of the private keys has slightly been altered
to fix a security weakness in enciphering very short private
keys. Thus insecurely short(<15 byte) private keys
originating from older versions(prior to 16) may not be
correctly recovered from the old secrets folder in version 16 or
higher. Regular keys are enciphered as before and will have no
need for manual conversion. Additionally from version 16 on, a
compound cipher of document and signature can be generated to
automatically ensure secrecy AND authenticity. The recipient
needs version 16 or higher to decrypt and authenticate these
compound ciphers.
Version 15 (uploaded on August
17 2011) features the improved versions "Fleas_x2" and
"Fleas_x5". These are supposed to replace "Fleas_4" and
"Fleas_5" in the future. In comparison to the predecessors, they
are programmed in a more orderly code, have abolished code lines
of marginal value and contain improvements that arose from a
security analysis that I conducted in preparation of publishing
the code and principles of the "Fleas"-one way functions. The
RNG was hardened further against attack by incorporating the new
"Fleas_x2" routines. Some small usability improvements were
included as well. I furthermore introduced a private key
export/import routine to allow for easy transfer of your private
key(s) to other installations of Academic Signature(e.g. between
home and office systems).
In version
14 (uploaded on July 24 2011) the private keys are
doubly protected and never ever reside on disk in plain. Thus
Oscars inspection of "deleted" files on a stolen disk is no
longer a threat :-). In this version some usability
improvements and cosmetic changes were included as well.
Version 13 contains a few usability
improvements(e.g. setting working directories for signing and
verifying and en/deciphering), a new "Fleas_5" crypto-family for
hashing and enciphering that fullfils the requirements of even
the most extreme paranoiacs and additional second level
protection for your private keys such that they now never ever
reside on the disk in plain form(except if the system decides to
swap memory to HD at the wrong split second...).
For me "Fleas_5" is security overkill for the price of a
somewhat reduced execution speed. From Fleas_1_8 on the
algorithms are self referential, virtually parameterless and
thus should be extremely resistant against the classical linear
and differential cryptoanalysis and combinations thereof. I did
however develop certain ideas on how an attack could be lauched
in principle(->backtracing, using incomplete onewayedness).
So I added new features which harden additionally against
backtracing i.e. 5-fold statistically independent parralell
oneway development with subsequent 5-fold XORing of the
results.(Some modern ciphers use 2-fold as the former Fleas_x
families). Of course the blocksize remains 8 kB (AES has 16
byte).