********************************************************
CHANGELOG


I will keep on searching for flaws and will promptly post security updates after identification of weaknesses. See past changes below(most recent ones on top):


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










 


