Home

SES: A Super-Encypherment Scrambler

Welcome to the Sourceforge Wiki home of SES.

Introduction

SES brings back the uncrackable onetime pad, with a digital twist. It is well known that a random letter key of message-length is the only cipher which is provably unbreakable. It is also thought to be impracticable. SES uses cryptographic-strength pseudo-random keys of message length for its many encipherments, in addition to offering true one-time pad capability for the intrepid.

SES is built on ISAAC, Bob Jenkins' CSPRNG, a fast and simple stream cipher placed in the Public Domain in 1996. Until SES, no one had used ISAAC for its intended purpose: encryption and decryption in a practical context, mediated by a compact and usable interface. SES, either in its original guise or through its new GSES front-end, gives you the ability to efficiently cipher text of arbitrary length or files of any size or type.

SES Design Goals

SES was designed to strike a balance between straightforwardness and enough complexity to deter potential attackers. Multiple super-encipherment was decided upon as the optimal basic strategy, preceded by rigorous key stretching and then nonce/IV mixing to achieve avalanche and diffusion with the goal of rendering every ciphertext unique.

Thus, for complete one-on-one privacy, SES traverses several levels en route to its output. The more words in your key-phrase, the more layers of encipherment SES applies. It is part Vigenere, part one-time pad, part cryptographic hash, not to mention the essential scrambler element, each component driven by ISAAC, with all key-derivation and stretching being SHA-3 based, in Keccak's highest 512-bit configuration.

Crypto-speak aside, that's merely another way of saying that SES is state-of-the-art.

But SES also reaches far back in history to the most venerable ciphers of all: the Caesar and Vigenère. Caesar's code, or Caesar shift, is one of the simplest and most widely known encryption techniques. It is a type of substitution cipher in which each letter in the plaintext is replaced by a letter some fixed number of positions down (or up) the alphabet.

Vigenère enhanced the basic scheme into a grid of multiple alphabets. When driven by a cryptographic-grade random number generator like ISAAC, Caesar-shifting offers a far stronger alternative to the simpler and more common XOR, or Vernam, operation used in many of today's standard stream ciphers. Thus Caesar provides SES with an augmented armoury against the potential adversary.

SES is a symmetric-key encryption system. It uses the same secret key to encipher and decipher a message or file. To send a secret message, just paste the ciphertext generated by SES into an e-mail. To receive one, run the ciphertext through SES with the -d option. Both sender and recipient must possess the key.

A Keccak (SHA-3) ciphertext-hash IV brings both avalanche and diffusion: even the tiniest change to a message will result in a completely different ciphertext. A unique nonce IV ensures that EVERY ciphertext is different, even the same message encrypted with the same key: effective deterrants against so-called "known plaintext" and "known ciphertext" attacks.

Along with a pseudo-OTP enciphered shell protecting the core encryption, SES makes at least five super-encipherments on any plaintext, usually more. SES, like a fortress with many walls, is impregnable given a key-phrase of sufficient entropy (80-90 bits is recommended - that's six or seven stochastically chosen words).

For elucidation of the SES algorithm, please consult SES.txt or the source code itself.

Why hasn't SES been broken?

Certain wimpy academics and soi-disant cryptanalysts are still whining about SES. They can't break it, you see. And they certainly couldn't have conceived it themselves. So they try to pick holes in the algorithm and the code without achieving anything. Despite their obvious impotence, my challenge still stands and will always stand: Break it.

But the answer to the question is simple. SES rests on the strongest possible foundation. That foundation is ISAAC, Bob Jenkins' little masterpiece, unassailed after more than two decades.

Does Cascaded Encipherment Really Make a Cipher Stronger?

Paraphrasing Terry Ritter:

Academics like to tell us there is no reason to think super-encipherment would make ciphering stronger. But there are very good reasons to think that multiple encryption makes a stronger cipher! First is the real-world example of Triple DES: Despite extensive analysis, Triple DES is still unbroken, and Triple DES is the multiple encryption composed only of broken DES. There could hardly be a more dramatic example of strength improvement than Triple DES! Next, many if not most ciphers are best attacked with some form of known plaintext attack. But using multiple ciphers in sequence hides the known plaintext from external analysis, which prevents those attacks. Similar hiding is not possible with only a single ciphering.

Isn't SES a little slow?

Yes! The surest way to defeat any brute-force attempt is to slam the brakes on. SES has excellent brakes, serviced primarily by an ultra-secure, iterative key-derivation and stretching function. Your key-phrase is thoroughly mangled once it's passed through that engine.

Why SES?

Why use SES? Isn't the world replete with off-the-shelf cryptographic solutions? I can only offer my own perspective on the question. I despise academia and I don't trust governments. Governments are behind standards. Government and academia are behind NIST, which approves most of the ciphers in common use today. Most damning of all, government is behind the NSA and academia is in its pocket. The same goes for GCHQ and any other intelligence or law-enforcement agency you care to name.

http://en.wikipedia.org/wiki/Nist#Controversy

I think it is naive even to hope that NSA is not a heavy influence on NIST's decisions. There is much discussion of "NSA backdoors". How are we to trust AES and other officially approved ciphers to secure us complete personal privacy?

In light of the inevitable negative answer, one of the aims of SES has been to eschew standards, thereby evading the possibility of NSA intrusion.

I found a stream cipher I knew I could trust. ISAAC, ignored by NIST, has impeccable credentials. ISAAC, open source and Public Domain, has not been subject to a single significantly successful attack. It is relatively little-known. The preliminary implementation of Keccak (now SHA-3) offered a more than suitable cryptographically secure hashing scheme for key-derivation. The scene was set for a practical cipher application; guaranteed best-case safety for my most private communications and data.

SES hides nothing of its inner workings. The source code is there to scrutinize and it's all rather simple. It uses ancient techniques to encipher on virtually random keys. Perfect ingredients.

The bottom line? Strong cryptography is easy once you make your decision for Christ - ignore the academics. They are nothing but hot air: resentful, hostile, incestuous and fearful for their tenures. Would you trust one, let alone heed his advice? SES said "no" and happily went its own way.

Strong Cryptography: Easy with GSES

GSES is a new GUI interface to SES.

GSES supports encipherment and decipherment of text of arbitrary length. Along with convenient drag-and-drop file encryption and decryption, the GSES shell boasts several features for enhancing session security and privacy, including key-phrase obfuscation and password session validation after short periods of user inactivity. An emergency Hide feature is also present for those - hopefully rare - occasions when you are under unexpected supervision or duress.

Please see Help.txt under the /GSES directory in the distribution archive for a comprehensive guide to using GSES.

Is SES being used in a production environment?

In at least one that I know of. No issues or complaints. SES just works.

Compiling and Invoking SES

Please invoke 'ses -h' for command line options, and see the text documents included with the package for more background and usage tips.

As a quick-start, type 'ses -e' at the prompt to encipher interactively.

SES should compile and run equally well in all flavors of Windows and Linux/Unix/BSD, including Mac OS X. It will probably run on all little-endian machines for which an FPC compiler exists, in fact.

For Windows, a free 3rd party console application is recommended to replace the DOS-prompt utility as shipped with the OS prior to Windows 7: My favorite - Console2 - may be downloaded from

http://sourceforge.net/projects/console/

SES, programmed in Free Pascal, is both free and Open Source and released under the GNU General Public License, version 3.0.

Pre-compiled executables are found under the "win" and "nix" directories inside the distribution archive's /bin folder. Source code is in the root directory. SES will compile in any Free Pascal distribution from version 1.0 upwards.

http://freepascal.org/

Simply cd to the directory into which you extracted the archive and type

fpc ses.pas

at the prompt.

Alternatively, you may run one of the pre-compiled binaries, which you will find inside the /bin directory.

SES now includes GSES, an example GUI front-end. You'll find it under the /GSES/ directory inside the distribution archive, either in pre-compiled binary form or as a Lazarus source project. Please see the ReadMe's in the relevant folders.

If you would like to get involved in the development and maintenance of SES, need to report a bug, port SES to another language or platform, add another GUI, or simply leave some feedback, please get in touch. Your input is both desired and welcome.

Cryptanalysts: Please look at the file Challenge.txt - modest prizes are still being offered for successful attacks on two short SES encipherments. After more than seven years and several thousand downloads of SES, not a single correct solution to either of these has been submitted.

Who is C.C. Kayne?

An IT and Cryptography professional with more than 30 years background in the field. But more important than that, I pride myself on writing useful, elegant programs that work. And they invariably do.

I wish everyone all possible enjoyment and benefit from SES. It's certainly been fun to code and develop.

Conrad C. Kayne
cckayne@gmail.com
handle: cck
sig: "MOD 26, mon amour"
https://plus.google.com/u/2/114160148833284687117
https://sourceforge.net/projects/sessuperencyphermentscrambler/
https://code.google.com/p/ses-super-encypherment-scrambler/
https://github.com/cckayne/ses-scrambler
https://sourceforge.net/projects/motet-cipher-scrambler/
https://sourceforge.net/projects/bedbug-csprng-stream-cipher/
https://sourceforge.net/projects/mote-csprng-stream-cipher/