Date: Jul 23, 2013 2:36 PM
Author: Mok-Kong Shen
Subject: NEOCLASSIC, An encryption scheme based largely on use of well-known<br> classical crypto techniques
Attached below is the code of my encryption software NEOCLASSIC
Version 1.1.1. For comments and critiques I should be very grateful.
Currently there is a challenge competition for it with a prize to
be won, see:
M. K. Shen
# NEOCLASSIC, A simple versatile encryption scheme (with authentication)
# largely on the straightforward use of well-known classical crypto
# Having during the years designed a small number of encryption
# am increasingly convinced that no practical encryption algorithm could be
# "absolutely" secure in the "strict" sense of the word and hence the
# such is futile from the very beginning. In fact, there exist rather strong
# critiques  on the so-called proofs of crypto-security. Thus what
# be desirable in practice will be the availability of a sufficiently large
# number of diverse kinds of sufficiently strong (preferably also easy for
# the common users to understand, verify and use) encryption algorithms
# when appropriately employed (eventually in combinations, i.e. with
# ciphers working in tandem), are intuitively safe with a satisfactory
# of safety" in relationship to the power of attacks that one's opponent
# "presumably" has in hand. One is IMHO therefore defacto always doing some
# gambling in the crypto practice. But this is actually also the case
# in real life, e.g. in the practice of medicine. In releasing the present
# software to the public, I am certainly conscious that it is definitely not
# absolutely secure but can only be hopefully practically secure, namely
# the user chooses sufficiently conservative values for its system
# A deplorable dilemma I am facing as designer is however that, in
# to e.g. pharmacy, there are in crypto barely any practical tests of the
# nature of those pertaining to drugs to determine the right dosage for
# administration to the patients. Since I could hardly provide any sensible,
# ubiquitously valid, guidances to the selection of the system parameters, I
# am obliged to warn the potential users of my software at the very
# The user is himslef responsible for the appropriate choice of the system
# parameters of this software in any actual applications. On the other hand,
# it is intuitively clear that higher values of the system parameters chosen
# should, in general, imply higher security, assuming that the user also
# sufficient care to ensure the fulfillment of all other security measures
# that are required in practice of the applications in which NEOCLASSIC is
# selected to be utilised.
#  N. Koblitz, The uneasy relationship between mathematics and
# Notices AMS, vol.54, 2007, pp.972-979, 1454-1456, vol.55, 2008, pp.6-7.
# NEOCLASSIC is a Python code for encryption processing that performs an
# arbitrary user-chosen number of rounds of pseudo-random transposition and
# substitution determined by a user-given session-key utilizing Python's
# built-in pseudo-random number generator (PRNG). Excepting the use of
# the use of computer), everything in NEOCLASSIC is straightforward
# of well-known techniques in classical cryptography, hence the name of the
# scheme. It is the latest member of a set of (to date) 4 members of
# algorithms first published by the present author in
# http://s13.zetaboards.com/Crypto/index/ (the other 3 are JADE-S, JADE,
# SHUFFLE2). With appropriate setting of parameters, its strength is
# to be comparable to the other members of the set. It may however be
# by the user because of the comparatively smaller number of its code
# Python code lines) and consequently presumably also less time required to
# understand its design and verify the coding for correctness and
# malicious backdoors. In fact, NEOCLASSIC has been developed primarily
# of the evidently enhanced needs of the common people to choose and employ
# sufficiently strong encryption software to protect the privacy of their
# innocent communications against the appallingly huge-scale international
# secret surveillance done by certain mighty countries of the world as
# revealed by the apparently highly convincing reports of the British
# The Guardian.
# NEOCLASSIC highly exploits the benefits of dynamics/variability, which the
# present author repeatedly stressed in a number of Usenet groups and which
# seem to be largely ignored in the design of most modern ciphers.
# Details of how the code parts work are given in the comment lines
# the respective functions further below. Here we present for the
# those users who may prefer to postpone a detailed examination of the
# a later time a brief sketch of what is in essence done in one round on
# encryption, namely in the function process(), neglecting, initially,
# of explanation, the authentication block:
# Perform a pseudo-random transposition of the given plaintext characters.
# With a variable sigma (initialized pseudo-randomly) do to each plaintext
# character the following:
# 1. Find the index (idx) of that plaintext character in the alphabet.
# 2. Generate a pseudo-random number (rr).
# 3. Determine the "intermediate" ciphertext character corresponding
# index gg in the alphabet, with gg=(idx+sigma+rr) (modulo alphabet
# size), i.e. one does a "shift" of amount sigma+rr as is done in the
# ancient Caesar cipher (our shift is albeit not a constant value but
# 4. Update sigma according to sigma=sigma+idx (modulo alphabet
# sigma gets an addend idx, which is a value (dynamically)
# the plaintext character that has just been processed.
# Perform a mono-alphabetical substitution on all the intermediate
# characters, yielding the ciphertext characters (to be similarly
# the next following round, if there is one).
# For purpose of authentication we extend the user-given plaintext with
# of characters that are pseudo-randomly generated (termed the
# block). It is the thus extended plaintext that is actually subjected
# kind of processing described above. Due to sigma, the processing of one
# character has influence on the processing of the next following one. Thus,
# additionally owing to the transpositions done in the number of rounds, the
# final ciphertext resulted is such that each character is highly correlated
# (the very opposite of being independent) with all the others. It is not
# difficult to see that, conversely, in case the ciphertext characters that
# correspond to the user-given plaintext are somehow manipulated/altered
# opponent, the authentication block recovered on decryption by the
# will (with a very high probability) not be identical to the authentication
# block that the sender generates on encryption. In this way we achieve our
# intended goal of authentication (integrity check), the necessity of which,
# we note, is often neglected/underestimated in practical applications of
# The function to be invoked by the user for encryption/decryption is
# neoclassic(). An example given further below illustrates its usage.
# Competition with established modern ciphers in processing speed is
# very beginning not a design goal of NEOCLASSIC (since message volumes of
# communications of common people (who are our targeted users) are as a rule
# fairly limited anyway and hence the difference in processing times
# entirely negligible) but rather in ease of code understanding and
# and in flexibility (of specification of system parameters, note also
# length of sessionkey is not fixed) and ease of use to perform
# encryption/decryption of intuitively/presumably (since we can offer no
# crypto-"proof") equivalent, if not superior, strength (depending on
# of sessionkey and choice of system parameters).
# Although the author has only tested (with Python 3.3.2) the software
# in English, there seems to be no reason why NEOCLASSIC shouldn't well
# on texts in other languages that have an alphabet. For Chinese, use of the
# Unicode or telegraphic codes to transcribe the logograms into decimal
# and an alphabet for English appears to be a viable possibility for
# NEOCLASSIC in practical applications.
# It may be noted that outputs of Python't built-in PRNG are only used
# indirectly and not directly as would have been the case for stream
# processing. (In stream encryption, outputs of a PRNG are xor-ed with the
# plaintext characters to result in the ciphertext characters, such
that, if a
# segment of the plaintext happens to be known to the analyst via some
# would know the corresponding outputs of the PRNG with which he could then
# eventually manage to determine the parameters of the PRNG and thus to
# the rest of the ciphertext.) Further, there is processing-dependent
# dynamics/variability provided by the feedback operations (skipping of PRNs
# output from the PRNG, see the function process()). Thus the question
# concerning extremely high quality of the PRNG being used isn't a
# to be examined for applications of NEOCLASSIC in practice.
# Communication partners should ensure having installed the same version of
# Python, since NEOCLASSIC depends on Python's built-in PRNG. We like to
# that, besides the evident requirement of keeping session-keys (and
# also the chosen system parameters) secret, it may be under circumstances
# prudent (because of possible malware infections) to do
# processing exclusively on physically secure computers isolated from the
# Internet and transfer the processed materials manually, i.e. on papers, to
# computers connected to the Internet, noting possible insecurity of USB
# Risks of electromagnetic emanations may eventually have to be
# well (see R. Anderson, Security Engineering, chap. 15, Emission Security).
# Version 1.1.1, released on 15.07.2013. Comment lines updated on
# Code lines of documents with the same version number are always identical.
# There may be interim modifications of comment lines. The most recent
# of NEOCLASSIC can be obtained from
# http://s13.zetaboards.com/Crypto/topic/7077275/1/ or from the author.
# This software may be freely used:
# 1. for all personal purposes unconditionally and
# 2. for all other purposes under the condition that its name, version
# and authorship are explicitly mentioned and that the author is
# all eventual code modifications done.
# The author is indebted to TPS for review and suggestions throughout
# NEOCLASSIC's development phase. Any remaining deficiencies of the
# however the sole responsibilty of the author.
# Concrete comments and constructive critiques are sincerely solicited
# via the above thread or directly via email.
# Email address of the author: firstname.lastname@example.org
# Loading a system module of Python that provides functionalities of its
# built-in PRNG.
# The following string defines the alphabet to be used by NEOCLASSIC and
# arbitrarily modified (altered, shortened or lengthened) by the user, if
# needed. Plaintext may only use a subset of alphabet, but ciphertext
# a rule nonetheless involve the entire set of characters in alphabet.
# is included in alphabet, user should note that the last character of the
# ciphertext obtained may happen to be a space and consequently could be
# overlooked on subsequent handling of the ciphertext.
# Alphabet defined.
# Alphabet size.
# Perform one round of pseudo-random transposition and substitution on
# textstring with Python's built-in PRNG seeded by roundkey.
# done in the straightforward classical sense by Python's function
# textstring. Substitution is done in two stages. First, each
# in alphabet is added by sigma and a pseudo-random value from Python's
# PRNG (modulo alphabet size). This kind of addition goes back to the
# Caesar cipher in classical cryptography. The variable sigma is initialized
# with a pseudo-random value from Python's built-in PRNG and updated
# index of the character being processed as the addend, thus resulting in
# processing-dependent dynamics/variability which is beneficial for security
# (albeit lacking in most other modern ciphers). Then there is a global
# substitution with Python's function translate(), with a substitution
# determined by Python's function shuffle(). This is mono-alphabetical
# substitution in the straightforward classical sense. Note that the varying
# value of sigma has the effect of block-chaining known in modern block
# encryption and is thus of particular significance to the performance of
# authentication achieved via the authentication block (i.e. the MAC in
# crypto terminology). If the updated sigma equals feedbackval, then the
# PRN from the PRNG is skipped. This feedback to the PRNG provides further
# dynamics/variability that renders the cryptanalysis by the opponent hard.
# process() is called by neocalssic() (which is directly invoked by the
# numround times.
# Seed the built-in PRNG with roundkey.
# Generate cipheralphabet.
# Generate index sequence for performing transposition.
ciphersequence=[i for i in range(lentext)]
# Initialize sigma.
# Begin of encryption processing for this round:
for i in range(lentext):
# This does transposition of the characters of textstring.
# This does a substitution of the individual character.
# Update sigma.
# Skip one PRN pseudo-randomly if sigma=feedbackval (this has a
# 1/lenalpha in case the characters in textstring are uniformly
# This does a global substitution (here from plaintext alphabet to
# alphabet, a mono-alphabetical substitution).
# Begin of decryption processing for this round (reversal of encryption
# This reverses the global substitution.
newlist=["" for i in range(lentext)]
for i in range(lentext):
# This reverses the substitution of the individual character.
# Update sigma.
# Skip one PRN pseudo-randomly if sigma=feedbackval.
# Return the result of processing of this round.
# sessionkey may be a decimal or hexadecimal integer or a character
# sufficient entropy. sessionkey is used as a seed for Python's built-in
# generate pseudo-random roundkeys that each has roundkeybits number of
# use as seeds for Python's built-in PRNG in the numround rounds of
# transposition and substitution done on inputstring by the function
# It also used to generate feedbackvals, an array of PRNs used for feedback
# operations done in the function process(). sessionkey is preferably to be
# chosen different for different sessions (it may consist e.g. of a
# part of sufficient entropy and a variable session-dependent part (not
# necessarily to be guarded secret) that is determined from e.g. date, time,
# message number etc.). roundkeybits is to be appropriately chosen in
# to entropy of sessionkey, i.e. too large a value for roundkeybits
# entropy of sessionkey doesn't make much sense in practice.
# the length of authenblock, which is a block of pseudo-random characters
# automatically generated by NEOCLASSIC to be processed together with
# inputstring to serve the purpose of authentication (integrity check),
# comment to the function process() above. In general, the larger the
# authenblocklen chosen, the higher will be the effectiveness of
# neoclassic() is the function to be directly invoked by the user for
# and decryption. On encryption neoclassic() generates materials that
# to call process() numround times to treat textstring, which is the
# extended by authentication block, and performs a final transposition
# characters (which renders the scheme more symmetrical with respect to
# transpositions and should also enhance its strength). On decryption these
# steps are reversed in the opposite order, with check of correctness of the
# decrypted authentication block for ensuring the integrity of the
# during transmission from the sender to the recipient. Note that, as
# the prologue, the appropriate choice of the parameter values is user's
# responsibility and so there is no check excepting the trivial one for
# Encryption: set kn=0.
# Decryption: set kn=1.
print("Error: No authentication block")
for i in range(len(inputstring)):
if inputstring[i] not in alphabet:
print("Error: inputstring contains character",\
inputstring[i],"which is not in the defined alphabet")
# Seed the built-in PRNG with sessionkey.
# Generate the arrays roundkeys and feedbackvals.
for i in range(numround):
# Generate authentication block.
for i in range(authenblocklen):
# Generate index sequence for performing the final transposition (on
finaltranspsequence=[i for i in range(lentext)]
# Encryption processing.
# Append authentication block.
# Perform numround rounds of encryption processing.
for i in range(numround):
# Perform final transposition.
for i in range(lentext):
# Decryption processing:
# This reverses the final transposition done on encryption.
newlist=["" for i in range(lentext)]
for i in range(lentext):
# Perform numround rounds of decryption processing.
for i in range(numround-1,-1,-1):
# Separate out the (recovered) authentication block from the (recovered)
# The recovered authentication block (lastblock) should be identical to the
# authentication block (authenblock) that is obtained from computing with
# sessionkey above (similar to what sender does on encryption).
print("Authentication (integrity check) o.k.")
print("Authentication (integrity check) failed ***************")
# Return the processing result.
# The following is an (abitrarily chosen, toy) example illustrating how
# NEOCLASSIC to do encryption/decryption.
# The alphabet (same for sender and recipient) has been defined further
# Sender defines the session-key and the other parameters and encrypts the
# plaintext pt to ciphertext ct for transmission to the recipient. (pt
# here uses only a subset of the alphabet defined further above. This
# is arbitrarily done by the sender in this particular example case and
# a necessary one.) Concerning choice of system parameters, see prologue
# beginning of the document.
# Recipient defines the same (agreed-upon with sender) session-key and the
# other parameters and decrypts the received ciphertext ct to plaintext pt1.
# NEOCLASSIC automatically verifies the correctness of the
# recovered from ct and tells whether the authentication is o.k., see
# the function neoclassic().
# If the plaintext message to be encrypted is in an external file (last line
# preferably without 'return'), it can be read into pt with:
# Similarly the received plaintext message (after decryption is
# be stored into an external file from pt1 with:
# In order to maximize the ease of examination as well as undestanding
# code by the majority of our targeted users, we have opted to reduce the
# complexity of the design as far as feasible, relying on the fact that
# is in any case always the possiblity available to the user to arbitrarily
# tune to his desire the strength of protection by NEOCLASSIC throgh a
# corresponding appropriate choice of the system parameters, e.g. the
# numrounds, without thereby seriously effecting its acceptance in issues of
# processing efficiency in practice. Thus, for example, in the
# the individual character (see process()) we employ the normal alphabet
# of a shuffled alphabet and we apply also a mono-alphabetical substitution
# instead of a poly-alphabetical substitution at the end of each round.
# having good experiences in programming may like to perform such
# to NEOCLASSIC, albeit on his own responsibility.)
# If both sender and recipient are in genuinely democratic countries and
# there is no problem at all arising from any third person's knowing of
# encrypted message transfer (the protection being solely against the
# surveillance of the Big Brother of the Internet), then the ciphertext
# simply sent via email as usual. Otherwise, as I recently argued in
# groups, use of facilities of the genre of remailer or Tor is risky
# the sender. For his email carries his own IP address (which cannot be
# and hence the agencies could efficiently obtain his identity by
tapping at the
# entrance of the remailer or Tor network, to which his email is being
# such situations the best solution is to post the ciphertext (encrypted at
# home) to a Usenet group like alt.anonymous.messages from a call shop or
# internet cafe (utilising the facility available there to access the Usenet
# group, thus not involving one's own IP address, nor email address). The
# recipient can collect the ciphertext similarly and decrypt it (at home) to
# obtain the plaintext. In order that the recipient could uniquely
# post of the sender, a chosen pseudonym and/or some special plaintext
# the subject line of the post may not always be sufficient, because other
# posters may by chance or for other reasons employ the same distinguishing
# feature. So the recipient may under circumstances have to pick up also a
# number of posts that are not from his partner and later discard these
# failing to decrypt them properly with the agreed-upon session key).
# of avoiding this is to encrypt something agreed upon (which may be
# varying) and use the corresponding ciphertext as the subject line for
# to the Usenet group. (The cipher for obtaining the subject line need not
# necessarily be one of very high quality, since the purpose is solely to
# perform an arbitrary transformation for purpose of distinguishing, though
# users of NEOCLASSIC could certainly conveniently do the subject line
# encryption processing with NEOCLASSIC as well. Its key should however
# preferably be one different from the session key that is used to
# message proper.) It goes without saying that in non-democratic
# may be agents doing observations in call shops or internet cafes and the
# communication partners have to take the potential risks duly into account.
# (A Usenet post claimed that in one West-European country customers of call
# shops or internet cafes must show their identities on entrance. The
# author unfortunately could currently neither verify that claim nor
# ideas of eliminating risks arising from such control.)