# NEOCLASSIC, A simple dynamic encryption scheme (with authentication) based # largely on the straightforward use of well-known classical crypto techniques.
# [Note] Users who prefer to examine the proper code part directly may skip the # prologue and epilogue section, there being sufficient comments explaining the # code lines. The system parameters are explained in a section that follows the # proper code part.
# Having during the years designed a small number of encryption algorithms, I # am increasingly convinced that no practical encryption algorithm could be # absolutely secure in the strict sense of the word and hence the quest for # such is futile from the very beginning. In fact, there exist rather strong # critiques  on the so-called proofs of crypto-security. Thus what seems to # 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 that, when # appropriately employed (eventually in combinations, i.e. with different # ciphers working in tandem), are intuitively safe with a satisfactory "factor # 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 everywhere # 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 when # the user chooses sufficiently conservative values for its system parameters # and employs key materials having sufficient amount of entropy. A deplorable # dilemma I am facing as designer is however that, in distinction 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 NEOCLASSIC at the very beginning: This software checks only # that certain heuristically determined lower limits of system parameter values # are satisfied. The user is himself responsible for the appropriate choice of # the system parameters of NEOCLASSIC 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 # takes sufficient care to ensure the fulfillment of all other security measures # (software, hardware, human) that are required in practice of the applications # in which NEOCLASSIC is selected to be utilised.
#  N. Koblitz, The uneasy relationship between mathematics and cryptology. # 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 PRNG (and # the use of computer), everything in NEOCLASSIC is straightforward application # 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 encryption # algorithms first published by the present author in the forum # http://s13.zetaboards.com/Crypto/index/ (the other 3 are JADE-S, JADE, # SHUFFLE2). With appropriate setting of parameters, its strength is considered # to be comparable to the other members of the set. It may however be preferred # by the user because of the comparatively smaller number (150) of its code # lines and consequently presumably also less time required to understand its # design and verify the coding for correctness and freedom from backdoors. In # fact, NEOCLASSIC has been developed primarily in view of the evidently # highly 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 universal secret # surveillance done by certain mighty countries of the world as recently # revealed by the apparently highly convincing reports of The Guardian, and # months later of Le Monde, which aroused some noteworthy non-trivial reactions # in France.
# NEOCLASSIC highly exploits the benefits of dynamics/variability, which the # present author has repeatedly stressed in a number of Usenet groups and which # seem to have been largely ignored in the design of most modern ciphers.
# Details of how the code parts work are given in the comment lines preceding # the respective functions further below. Here we present for the convenience of # those users who may prefer to postpone a detailed examination of the code for # a later time a brief sketch of what is in essence (i.e. excepting some minor # deviations for achieving e.g. higher variability) done in one round on # encryption, namely in the function process(), neglecting initially, for ease # 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 to the # 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 # pseudo-random). # 4. Update sigma according to sigma=sigma+idx (modulo alphabet size), i.e. # sigma gets an addend idx, which is a value (dynamically) dependent on # the plaintext character that has just been processed. # # Perform a mono-alphabetical substitution on all the intermediate ciphertext # characters, yielding the ciphertext characters (to be similarly processed in # the next following round, if there is one). # # For purpose of authentication we extend the user-given plaintext with a number # of characters that are pseudo-randomly generated (termed the authentication # block). It is the thus extended plaintext that is actually subjected to the # 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 by the # opponent, the authentication block recovered on decryption by the recipient # 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 # cryptography.
# 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 from the # 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 would be # entirely negligible) but rather in ease of code understanding and verification # and in flexibility (of specification of system parameters, note also that the # length of session-key is not fixed) and ease of use to perform encryption and # decryption of intuitively/presumably (since we can offer no crypto-"proof") # equivalent, if not superior, strength (depending on entropy of session-key and # choice of system parameters).
# Although the author has only tested (with Python 3.3.2) the software on texts # in English, there seems to be no reason why NEOCLASSIC shouldn't well function # on texts in other languages that have an alphabet. For Chinese, use of the # Unicode (or telegraphic codes) to transcribe the logograms into decimal digits # and an arbitrary alphabet containing the decimal digits as a subset appears to # be a viable possibility for employing NEOCLASSIC in practical applications.
# It may be noted that outputs of Python't built-in PRNG are only used by us # indirectly and not directly as would have been the case for stream encryption # 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 means, he # 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 decrypt # the rest of the ciphertext.) Further, there is processing-dependent # dynamics/variability provided by the feedback operations (skipping of PRNs # output from the PRNG etc., see the function process()). Thus the question # concerning extremely high quality of the PRNG being used isn't a critical one # 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 mention # that, besides the evident requirement of keeping session-keys (and preferably # also the chosen system parameters) secret, it may be under circumstances # prudent (because of possible malware infections) to do encryption/decryption # 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 sticks. # The possibility of opponent's eventual access to one's computer and somehow # recover the keys that had been employed should not be underestimated and # preventive measures taken accordingly. Risks of electromagnetic emanations may # eventually have to be considered as well (see R. Anderson, Security # Engineering, chap. 15, Emission Security).
# Version 1.2, released on 24.10.2013.
# Code lines of documents with the same version number are always identical. # There may be interim modifications of comment lines. The most recent document # of NEOCLASSIC can be obtained from # http://s13.zetaboards.com/Crypto/topic/7115671/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 number # and authorship are explicitly mentioned and that the author is informed of # 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 software are # however the sole responsibilty of the author.
# Concrete comments and constructive critiques are sincerely solicited either # via the above thread or directly via email. Questions about programming # details are also welcome (please use however email only and avoid usage of # bandwidth of the forum).
# Email address of the author: firstname.lastname@example.org
# Loading a system module of Python that provides functionalities of its # built-in PRNG.
# Perform one round of pseudo-random transposition and substitution on # textstring with Python's built-in PRNG seeded by roundkey. Transposition is # done in the straightforward classical sense by Python's function shuffle() on # textstring. Substitution is done in two stages. First, each character's index # in alphabet is added by sigma and a pseudo-random value from Python's built-in # PRNG (modulo alphabet size). This kind of addition goes back to the ancient # Caesar cipher in classical cryptography. Then this intermediate ciphertext # character is subjected to a substitution with a dynamically varying alphabet. # The variable sigma is initialized with a pseudo-random value from Python's # built-in PRNG and updated with the index of the character being processed as # the addend, thus resulting in processing-dependent dynamics/variability which # is beneficial for security (but which is albeit lacking in most other modern # ciphers). As a second step, a global substitution is done via Python's # function translate(), with a substitution alphabet 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 modern crypto terminology). If the # updated sigma is less than the value of the parameter feedback, the next PRN # from the PRNG is skipped. This feedback to the PRNG provides further # dynamics/variability that renders the cryptanalysis by the opponent hard. # (Some details deviate from the above for obtaining more dynamics/variability: # The binary switches skip1 and skip2 determine runtime alternative computations # of the ciphertext character and the sigma. The eventcount controls the time # point of re-shuffling of the alphabet used in the substitution that involves # sigma.) # # kn=0 for encryption, kn=1 for decryption.
def process(roundkey,textstring,kn): global alphabetstr,alphabet,lenalpha,lentext global feedback,eventthreshold lenalpham1=lenalpha-1 # Seed the built-in PRNG with roundkey. random.seed(roundkey) # Generate an alphabet for a substitution processing of the individual characters, # see below. substalphabet=alphabet[:] random.shuffle(substalphabet) # Generate an alphabet for a global mono-alphabetical substitution, see below. cipheralphabet=alphabet[:] random.shuffle(cipheralphabet) cipheralphabetstr="".join(cipheralphabet) # Generate an index sequence for performing transposition. ciphersequence=[i for i in range(lentext)] random.shuffle(ciphersequence) # Initialize sigma, flip1, flip2 and eventcount. sigma=random.randint(0,lenalpham1) flip1=random.randint(0,1) flip2=random.randint(0,1) eventcount=0 if kn==0: # Begin of encryption processing for this round: newstring="" for i in range(lentext): # This does transposition of the characters of textstring. tt=textstring[ciphersequence[i]] # This does a substitution of the individual character. idx=alphabet.index(tt) rr=random.randint(0,lenalpham1) if flip1: gg=(idx+sigma+rr)%lenalpha else: gg=(idx+sigma-rr)%lenalpha newstring+=substalphabet[gg] # Update sigma. if flip2: sigma=(sigma+idx)%lenalpha else: sigma=(sigma-idx)%lenalpha flip1^=idx&1 flip2^=rr&1 # Very roughly with probability feedback/lengalpha an event is considered to # have occurred, whereupon an event counter is updated and one PRN output from # the PRNG is skipped. When the event counter reaches eventthreshold, # substalphabet will be re-shuffled. if sigma<feedback: eventcount+=1 skipped=random.randint(0,lenalpham1) flip1^=1 flip2^=1 if eventcount>=eventthreshold: random.shuffle(substalphabet) eventcount=0 # This does a global substitution (here from plaintext alphabet to ciphertext # alphabet, a mono-alphabetical substitution). transtab=newstring.maketrans(alphabetstr,cipheralphabetstr) newstring=newstring.translate(transtab) else: # Begin of decryption processing for this round (reversal of encryption # processing): # This reverses the global substitution. tmpstring=textstring[:] transtab=tmpstring.maketrans(cipheralphabetstr,alphabetstr) tmpstring=tmpstring.translate(transtab) newlist=["" for i in range(lentext)] for i in range(lentext): # This reverses the substitution of the individual character. uu=tmpstring[i] gg=substalphabet.index(uu) rr=random.randint(0,lenalpham1) if flip1: idx=(gg-sigma-rr)%lenalpha else: idx=(gg-sigma+rr)%lenalpha tt=alphabet[idx] newlist[ciphersequence[i]]=tt # Update sigma. if flip2: sigma=(sigma+idx)%lenalpha else: sigma=(sigma-idx)%lenalpha flip1^=idx&1 flip2^=rr&1 # See above for feedback. if sigma<feedback: eventcount+=1 skipped=random.randint(0,lenalpham1) flip1^=1 flip2^=1 if eventcount>=eventthreshold: random.shuffle(substalphabet) eventcount=0 newstring="".join(newlist) # Return the result of processing of this round. return(newstring)
# Session-key used is a character string consisting in detail of two parts, # secretkey and sessionkeyextension, of which only secretkey is assumed to be # secret and to contain sufficient entropy (randomness) to be able to deliver # the security protection required. It seeds Python's built-in PRNG to generate # pseudo-random roundkeys that each has roundkeybits number of bits (plus some # additional bits) for use (in their turn) as seeds for Python's built-in PRNG # in the numround rounds of transposition and substitution done on inputstring # by the function process(). authenblock is a block of pseudo-random characters # generated to be processed together with inputstring to serve the purpose of # authentication (integrity check). # # On encryption neoclassic() generates materials that are needed to call # process() numround times to treat textstring, which is the inputstring # extended by authenblock, and performs a final transposition of the 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 ciphertext during transmission from # the sender to the recipient. # # Encryption: kn=0. # Decryption: kn=1.
def neoclassic(inputstring,kn): global alphabetstr,alphabet,lenalpha,lentext global secretkey,sessionkeyextension global numround,roundkeybits,roundkeyaddendbits,authenblocklen global feedback,eventthreshold # Some plausibility checks with recommended limits. User is responsible for # appropriate choice of system parameters as well as entropy in secretkey. if len(sessionkeyextension)==0 or numround<2 or roundkeybits<128 or \ roundkeyaddendbits<10 or authenblocklen<30 or \ feedback<1 or eventthreshold<1: print("Error: Inadmissible sessionkeyextension, numround, roundkeybits, " "roundkeyaddendbits, authenblocklen, feedback or eventthreshold") exit(1) for i in range(len(alphabetstr)): ch=alphabetstr[i] if alphabetstr.count(ch)!=1: print("Error in init: alphabetstr has duplicated character") exit(2) alphabet=list(alphabetstr) lenalpha=len(alphabet) lenalpham1=lenalpha-1 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") exit(3) if kn==0: lentext=len(inputstring)+authenblocklen else: lentext=len(inputstring) # Seed the built-in PRNG with session-key (secretkey and sessionkeyextention). random.seed(str(secretkey)+str(sessionkeyextension)) # Generate roundkeys. roundkeys= for i in range(numround): roundkeys+=[random.getrandbits(roundkeybits)+\ random.getrandbits(roundkeyaddendbits)] # Generate authentication block. authenblock="" for i in range(authenblocklen): authenblock+=alphabet[random.randint(0,lenalpham1)] # Generate index sequence for performing the final transposition (on # encryption). finaltranspsequence=[i for i in range(lentext)] random.shuffle(finaltranspsequence) if kn==0: # Encryption processing. # Append authentication block. textstring=inputstring+authenblock # Perform numround rounds of encryption processing. for i in range(numround): textstring=process(roundkeys[i],textstring,kn) # Perform final transposition. tmpstring=textstring[:] textstring="" for i in range(lentext): textstring+=tmpstring[finaltranspsequence[i]] else: # Decryption processing: # This reverses the final transposition done on encryption. tmpstring=inputstring[:] newlist=["" for i in range(lentext)] for i in range(lentext): newlist[finaltranspsequence[i]]=tmpstring[i] textstring="".join(newlist) # Perform numround rounds of decryption processing. for i in range(numround-1,-1,-1): textstring=process(roundkeys[i],textstring,kn) # Separate out the (recovered) authentication block from the (recovered) # plaintext. lastblock=textstring[-authenblocklen:] textstring=textstring[:-authenblocklen] # The recovered authentication block should be identical to the authentication # block (authenblock) that is obtained from computing with session-key above # (same as what the sender does on encryption). if lastblock==authenblock: print("Authentication (integrity check) o.k.") else: print("Authentication (integrity check) failed ***************") exit(4) # Return the processing result. return(textstring)
# Both communication partners have to download the same version 3x of Python # from http://www.python.org. The present code can be stored in a file named # e.g. neoclassic.py and the example given further below run in Python's GUI # IDLE. (One could also type neoclassic.py in a DOS-window.)
# Explanation of the system parameters to be defined by the communication # partners. The limiting lower bounds below are set heuristically, taking # considerations of the design goals of NEOCLASSIC. Appropriate choice of the # system parameters is however user's own responsibility.
# numround: Number of rounds in the encryption/decryption processing, min. 2.
# roundkeybits: Number of bits of roundkeys to be generated from session-key, # min. 128.
# roundkeyaddendbits: Number of bits of roundkeyaddends, min. 10. # (roundkeyaddends serve to add some variablity to the # roundkeys.)
# authenblocklen: Number of bytes of the authentication block generated, # min. 30. (In general, the larger the value, the higher will be # the effectiveness of authentication (integrity check)).
# feedback: Measure of feedback to trigger an event (a PRNG output is then # skipped etc.), min. 1. See process(). (Larger values means stronger # feedback effects.)
# eventthreshold: When number of accumulated events reaches eventthreshold, the # prefix code is regenerated, min. 1. See process().
# alphabetstr: This string defines the user-given alphabet. The characters in # alphabetstr are arbitrary but must be unique. Size of alphabetstr # is arbitrary. Plaintext may only use a subset of alphabet, but # ciphertext will as a rule nonetheless involve the entire set of # characters in alphabet. If space 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 easily # overlooked on subsequent handling of the ciphertext.
# Explanation of key materials to be defined by the communication partners.
# secretkey: This is to be specified as a string containing sufficient entropy, # preferably at least 128 bits. For example, it can be 32 hexs # obtained e.g. through throwing a number of 8-sided dice, each # delivering 3 bits. Or it can be an arbitrarily chosen natural # language (sensible or non-sensical) text string that is estimated # to possess the required entropy. secretkey to be used during a # certain time period could also be generated using e.g. a (longer # durated) master-key to encrypt a selected text (in some way # dependent on that time, for example explicitly containing the # period of use of the envisaged secretkey) and post-processing the # resulting ciphertext, e.g. xor-ing segments of its hexs, to result # in a key in the suitable format desired. (An hierachy of # master-keys could also be used, all stemming from a grand # master-key.) secretkey must be carefully kept secret by the # communication partners against diverse generes (software, # hardware and human) of sophisticated attacks by the opponent.
# sessionkeyextension: This is an arbitrary string, length min. 10. It is highly # recommended to have this string different for different # sessions, e.g. containing time, message serial number # etc. It need not necessarily be kept secret. Its purpose # is to render the effective key (resulting from its # combined use with secretkey) variable across the # different sessions, which is highly valuable for # enhancing the security of encryption/decryption # processing, since the material encryted by one and the # same session-key available for analysis is greatly # reduced thereby.
# Explanation of formal parameters of the function to be invoked for encryption # and decryption.
# Encryption: inputstring is plaintext string, kn is 0. Ciphertext string is # returned.
# Decryption: inputstring is ciphertext string, kn is 1. Recovered plaintext # string is returned.
# Recipient with the same system parameters, secretkey and sessionkeyextension, # decrypts the received ciphertext ct to plaintext pt1. NEOCLASSIC automatically # verifies the correctness of the authentication block recovered from ct and # tells whether the authentication is o.k.
print("Identity of plaintext and recovered plaintext:",pt1[:len(pt)]==pt)
# If the plaintext message to be encrypted is in an external file (last line # preferably without 'return'), it can be read into pt with: # f=open("messagetobesent.txt","r")) # pt=f.read() # f.close() # Similarly, after decryption is performed, the recovered plaintext message can # be stored into an external file from pt1 with: # f=open("messagereceived.txt","w") # f.write(pt1) # f.close()
# In order to maximize the ease of examination as well as undestanding of the # code by the majority of our targeted users, we have opted to reduce the # complexity of the design to a great extent, relying on the fact that there # 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 value of # numrounds, without thereby seriously effecting its acceptance in issues of # processing efficiency in practice.
# If both sender and recipient are in genuinely democratic countries and hence # there is no problem at all arising from any third person's knowing of the # existence of their encrypted message exchange (the protection being solely # against the surveillance of the Big Brothers of the Internet), then the # ciphertext could be simply sent via email as usual. Otherwise, as I recently # argued in some Usenet groups, use of facilities of the genre of remailer or # Tor is risky anyway for the sender. For his email carries his own IP address # (which cannot be faked) 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 sent. In 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 # identify the post of the sender, a chosen pseudonym and/or some special # plaintext string in 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. Thus the recipient might under circumstances have to # pick up also a number of posts that are not from his partner and later # discard these (after failing to decrypt them properly with the agreed-upon # session-key). One method of avoiding this is to encrypt something agreed upon # (which may be dynamically varying) and use the corresponding ciphertext as the # subject line for posting 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 # encrypt the message proper.) It goes without saying that in non-democratic # countries there 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 present author unfortunately could currently neither verify that # claim nor have good ideas of eliminating risks arising from such control.) # Note that in certain situations the sender could simply publish the encrypted # messages on his web page for the recipient to read from any neutral place, # e.g. an Internet cafe.
# The present author has pointed out in posts to a few Usenet groups that one # feasible way of principally reducing, if not eliminating, the impact of # universal surveillance by the secret agencies would be to somehow achieve to # have a sufficiently large number of common people in the world who, besides # sending proper encrypted private messages as needed, send also encrypted # irrelevant stuffs (e.g. texts from newspapers) or else constantly insert into # their emails simply some fairly random lines of hexs or other characters that # are barely distinguishable from genuine ciphertexts of good ciphers (random # tapping on the keyboard, or better using e.g. Python's built-in PRNG to # generate random characters from an arbitrary alphabet, see the code below). # This way, since the secret agencies would suspect that at least some of these # materials could eventually contain informations of vital interest to the # goals of surveillance and thus would attempt to decrypt a substantial part of # them (which they however can never succeed, since there is no corresponding # plaintext at all), their computing resources, despite being of almost # astronomical scale, would evidently be quickly exhausted.
#import random #alphabetstr="ABCDEFGHIJKLMNOPQRSTUVWXYZ"\ # "abcdefghijklmnopqrstuvwxyz"\ # "0123456789()-?/=%&" #lenalpha=len(alphabetstr) #def randomstr(textlength): # randstr="" # for i in range(textlength): # randstr+=alphabetstr[random.randint(0,lenalpha-1)] # print(randstr) ##We don't set seed, since we don't want/need reproducibility. Python uses then ##a dynamic seed, which is exactly what we require for the current purpose. #randomstr(100)
# It cannot be overemphysized that risks of IT security are ubiquitous. A good # cipher can only be one member of a chain of elements responsible for the # desired secure communication and that that security is nonetheless lost, if # any one of the other elements of the chain is insecure. A potential point of # weakness that we like to specially call attention to is the use of proprietary # (non-opensource) software, e.g. for digital signatures. For it is evidently # fairly simple for the secret agencies to manage to implant backdoors in them, # through coercion of the employees of the manufacturers of the software or by # other means. One notes also that recently there are claims that even certain # encryption algorithms that are standardized by NIST (and obviously because of # the (till recently) good faith/trust in NIST have later also become ISO # standards) might have weakness in them introduced by the secret agencies. It # is deplorable that little details of the claimed weakness have been published # to date.