(back to academic signature homepage)

***********************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).