An algorithm is simpler than another if

  1. It is easier to explain to a noob with basic high-school math knowledge.
  2. It is easier to securely self-implement by an intermediate programmer (Yes I know one should never 'roll their own' but this is just a metric of comparing simplicity)
  3. Can be done by hand & paper more easily (not necessarily that it can practically be done on paper, but that it is easier to do on paper if one were to take the pains to do so)
  4. Involves lesser steps.
  5. Any other factors that don't immediately come to mind.

To give an example with popular ciphers, by these criteria RSA is simpler than AES.

The point of this question is maybe find out about some very clever albeit less popular/unheard of cryptographic algorithms that are at or quite close to real commercial-level security while still being incredibly simple.

To use simpler words, the requirements are much above Caesar cipher but much below AES, in terms of complexity.

A question on the most secure hand ciphers inspired this question, except there are no such limitations of not having computational/calculational power here, but similar/stricter restriction on complexity. The idea is to test the limits of simplicity that cryptography can reach while still being done right.

Perhaps symmetric ciphers would be ideal for the criteria of simplicity. However, obviously, any cipher is to-the-mark if it is simple and secure enough.

Edit 1 : The criteria listed above are in order of importance, i.e, the 1st is more important than the second and so on.

  • 3
    $\begingroup$ Can you explain what you want from 3? Do you want someone to actually do it by hand as a computer would? Or are you just interested in that you can do a scaled-down version by hand just to understand it? You can perform RSA quite easily by hand if you're willing to use smaller primes. The size of the primes doesn't affect understanding how RSA works. $\endgroup$ Aug 7, 2020 at 13:17
  • $\begingroup$ @AmanGrewal No that was just my attempt at framing the the criteria for comparison and defining 'simple' ; that it is more simple if it is easier to do by hand than another -- i.e, if both X & Y are nearly impossible to do by hand , but if they were to be hypothetically to be done by hand X would be easier/faster than Y, then X is considered simpler than Y. However, this is obviously not as important as the first two steps and/or the actual security of the algorithm. $\endgroup$
    – An Ant
    Aug 7, 2020 at 13:30
  • 4
    $\begingroup$ en.wikipedia.org/wiki/Tiny_Encryption_Algorithm $\endgroup$
    – Nayuki
    Aug 7, 2020 at 20:59
  • 2
    $\begingroup$ en.wikipedia.org/wiki/Solitaire_(cipher) $\endgroup$ Aug 8, 2020 at 22:02
  • 1
    $\begingroup$ en.wikipedia.org/wiki/Speck_(cipher) $\endgroup$
    – OneUser
    Sep 25, 2020 at 18:07

7 Answers 7


I will throw tiny encryption algorithm into the mix: https://en.m.wikipedia.org/wiki/Tiny_Encryption_Algorithm

It's a very respectable block cipher. It really works as a block cipher with convenient block size of 64 bits and key size of 128 bits. So it behaves much like a DES or AES as in how you use it securely.

It's a Feistel network which anyone starting studying crypto should learn anyway. It's easy to follow why it's reversible and how the shuffling happens. So I think the level of understanding achievable to a novice is high if you want not only to memorize the code but also have a minimal understanding of why this is a good idea.

  • $\begingroup$ Meir , Indeed, this is another excellent , secure, and yet simplistic algorithm $\endgroup$
    – An Ant
    Aug 9, 2020 at 16:31
  • $\begingroup$ Meir, Which - RC5 or TEA, would be more sure ? and which would be simpler ? $\endgroup$
    – An Ant
    Aug 10, 2020 at 0:34

I would say MiMC is the simplest block cipher with plausible security. The idea is to cube the state, add a random constant, and repeat. This is typically done in a large prime field, but it is trivial to implement field arithmetic in any language with big integer support. Here's a Python implementation:

def mimc(x, p, k, constants):
    x = (x + k) % p
    for c in constants:
        x = (x**3 + k + c) % p
    return x


  • x is the input.
  • p is the (prime) order of the field.
  • k is the block cipher key.
  • constants is a list of r random field elements, where r is the number of rounds. (The paper uses r - 1 constants, since adding one in the final step does nothing for security, but it doesn't hurt either.)
  • The authors recommend r = ceil(log(p)/log(3)).
  • The field must be one in which cubing is a permutation, which holds if gcd(3, p - 1) = 1.

The one time pad technically meets all your criteria and I think it's the simplest. It gets used all the time within encryption schemes where it's usually called blinding.

Otherwise I would look into small block ciphers. For example, RC5 and skip32. These are probably the simplest beside the OTP.

  • 1
    $\begingroup$ I like this answer because you recommended RC5, which is probably the simplest one suggested here which is also unbroken and quite seriously secure for the near future as well. $\endgroup$
    – An Ant
    Aug 9, 2020 at 13:22
  • 1
    $\begingroup$ @AnAnt Try to avoid steering up / downvotes. You can indicate why you think it is a good answer (if the information is not already in the answer) but don't use things like "underrated" and other such comments. $\endgroup$
    – Maarten Bodewes
    Aug 9, 2020 at 15:56

I think the most simple ciphers that are available are stream ciphers. Of course there are secure and non-secure stream ciphers. But e.g. LFSR's based ciphers are pretty easy to understand, and generally you just have to deal with bitops and basic possibly (modulo) addition. Those operations are generally easy to perform "by hand". Of course, to achieve security, the algorithms do generally have a pretty large state, so updates to the state will also take a lot of time for a human.

You could look at RC4 as used in the TLS protocols (up to 1.2 anyway) and A5/1 as used for protecting GSM communications. Those are actively used for commercial applications. Although I should have mentioned that neither of these are still secure (or as secure as they should be in the case of RC4).

The disadvantage of using a stream cipher is that the use is limited compared to e.g. a block cipher. Block ciphers are used as constructs in e.g. MAC algorithms, sometimes even hash algorithms and many other projects.

RSA is also known as a relatively easy algorithm indeed. It's source code can and was printed in PERL on T-shirts during the crypto wars. Note that you'd need at least PKCS#1 padding for it to be secure, which adds to the complexity. Key pair generation is also much harder for RSA.

If you'd use anything, then Diffie-Hellman might be a good choice. The key pair generation is easier and DH-operations themselves are simply the calculations and some conversions to bits. You should however stick to a well known named set of domain parameters; generating a new set adds unneeded complexity.

In general I'd think that a stream cipher is vastly less complex than most asymmetric primitives though.

  • 2
    $\begingroup$ Maarten and @ilkkachu about that... if the algorithm is broken , is it really commercial-level ? is it even considered secure at all ? $\endgroup$
    – An Ant
    Aug 9, 2020 at 5:31
  • 1
    $\begingroup$ Yes, an algorithm may be broken in a theoretical sense and still be used commercially for sure. A5/1, RC4 buyer also the proprietary MIFARE algos address examples of that. Broken doesn't mean that no security is left. $\endgroup$
    – Maarten Bodewes
    Aug 9, 2020 at 6:25
  • 1
    $\begingroup$ @AnAnt, with the info from Wikipedia, RC4: "In 2015, security researchers from KU Leuven presented new attacks against RC4 in both TLS and WPA-TKIP. [...] Their attack against TLS can decrypt a secure HTTP cookie within 75 hours. The attack against WPA-TKIP can be completed within an hour" and "The use of RC4 in TLS is prohibited by RFC 7465 published in February 2015." -- with that last one, I hope no-one uses RC4 commercially $\endgroup$
    – ilkkachu
    Aug 9, 2020 at 8:40
  • $\begingroup$ @AnAnt, again from Wikipedia, the attacks on A5/1 are described to take "minutes", but requiring hundreds of GB to some TB of precomputed data. I don't know the actual details, but nothing I read about is very convincing about it being safe. And AFAIU, that's still used for GSM, at least 2G. $\endgroup$
    – ilkkachu
    Aug 9, 2020 at 8:49
  • $\begingroup$ @MaartenBodewes Why would you recommend RC4 over RC5 , I'm curious... $\endgroup$
    – An Ant
    Aug 9, 2020 at 13:35

Those are good answers if you need a cypher or public key cryptosystem, but they are not the most secure nor the most simple of cryptographic algorithms. Even Playfair is more complicated than codebook encryption. The more simple and most secure cryptographic algorithm by far is the one-time pad. It is proven secure, and exists of an exclusive-or. The painful parts are generating true randomness, and the requirement of "one-time" use per pad.

  • $\begingroup$ Steve, you commented a bit too early. See user82867 's answer as well as the one give by Daniel Lubarov . RC5, i am sure, you cannot allege is not simple ? and neither RC5 nor MiMC are insecure... $\endgroup$
    – An Ant
    Aug 9, 2020 at 13:33

Perhaps RSA serves both your criteria very, very well , and is also a valid candidate ?

  • 1
    $\begingroup$ Except it doesn't ... The basics of RSA are easy to grasp, but the huge primes that need to be generated and stored, the e value's conventional fixing and the fact that huge private and public keys are involved and stored basically break 2). , 3) , and possibly even 1) $\endgroup$
    – An Ant
    Aug 7, 2020 at 12:27
  • 5
    $\begingroup$ Please backup any argument with reasons if not facts. Just naming an algorithm, especially when already mentioned in the question, is not enough. $\endgroup$
    – Maarten Bodewes
    Aug 7, 2020 at 13:49

You question is quite broad

cryptographic algorithm

What kind of task shall this algorithm solving?

  • symmetric encryption, like AES
  • asymmetric, like RSA
  • key-exchange, like Diffie–Hellman
  • hash function, like sha256
  • quantum-theoretical-encryption-algorithm, like something new from the IACR
  • quantum-key-exchange algorithms, like one used across EU already...
  • steganography, like spies used
  • signing algorithms, like used in PGP/GPG schemes
  • pseudo-random numbers algorithm, like used mostly everywhere in crypto as sub-algo

And probably 10+ fields in crypto, little bit minor...

When you are comparing RSA - easier than AES - you are comparing "Hammer" and "Saw", it is used for different things, this gives different environment for algorithm and of-course - stream encryption little bit harder than just generate private & public keys...

What is better "Blue-Color" or "Cold-Ice-Cream"?

You could say, sha256 easy than ECC - Elliptic-curve cryptography, but this is two completely different targets. It is like to say "ZIP file format" ( an archive ), and all algorithm inside it, easier than Bitcoin's block-chain algorithm... is it easier? or they are equal? Or perhaps, block-chain is so popular - because it is one of the easiest algorithm on the Earth?

One-time pad - will be easiest one to understand than anything you could met, methinks. But would it be easy to handling two big secret books containing one big secret key??? I'm not sure... Are you ready to physically meet with your counter-part to give em copy of your one-time pad. And thereafter - like you said, on the paper, encrypt e-mails - symbol-by-symbol...

So, we could separate categories

  • easiest in handling
  • easiest in understanding
  • easiest in coding

.... and somehow connected to cryptography, hash, key-exchange, stream, no-matter..

I think the answer on this question will not satisfy your researching.

  • $\begingroup$ AES isn't neither a stream cipher, nor a encryption scheme on its own. It's just too pointless to point out other factual errors in your answer. $\endgroup$
    – DannyNiu
    Sep 25, 2020 at 8:09

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.