Best encryption technology that's resource-efficient?

I’m making a game, and am currently using AES. Would that be the best?

@LordLambda because you seem to know quite a lot about encryption.

Please read and sign Foot Shooting Prevention Agreement before continuing with this thread.


I am a noob at this kind of stuff, sorry if I upset you :frowning:

haha not upset, just a rare circumstance to use an extremely detailed XKCD comic.


Haha alright I’ll go for it. Really you should also worry about transmission of key. That’s the thing most people generally get wrong in production results. Insecure transmission of key, which no matter how strong of an encryption you have. Will be the downfall.

However resource efficient encryption? There’s quite a wide variety.
However my two favorite are for quick computational ciphers that are secure are RC5, and RC6.
RC5 has a minor attack (for the attack to work you need both the plaintext, and the ciphertext. AKA. you have to have the decrypted content) when done over 12 rounds (however this is only the case of 64 bits, so use a different bit size, or change number of rounds).
RC6 has no attacks documented on it.

Both are quite quick to compute, and secure. They are both implemented in bouncycastle.

why not an asymmectric thing such as RSA?

or PGP? Wait nvm eww norton

I’m not very good at encryption and all that but I recently made a super short python thing for my own thingy:

That unfortunately would take little to no time to break. So much that it would be extremely trivial. Sorry to be the bearer of bad news.

@wetsponge if I understand correctly, the code is a single ascii character?! If you can deduce from the structure of the sentence a SINGLE CHARACTER, that would be sooo easily broken, even if you don’t brute force it.

EDIT: omg that’s bad. Assuming no tabs or line breaks, take each number and add their position. Find the smallest number in the new list, subtract 32, and you have the code. You don’t need to belong to Berkeley hill to break that one o-o I understand that you have no professional experience in encryption, and respect that you made an attempt.

@DotDash, @LordLambda, would RSA be a good idea? An async system would make protection of transmitted keys unnecessary.

In some cases it could be. However I’m not sure exactly what @DotDash was looking to do with it. So I recommended some that fit decently well for every situation.

For things like file protection, or giving data a master server using RSA would be one of the most optimal solutions (as you could give the public key to the client, and decrypt only on the server side). So in that instance yes it would be.

However for any sort of players talking to each other, or allowing players to connect to player made servers it would become messy, and would have way more downfalls than just a symmetric encryption (rather than a symmetric encryption which can be set up quite easily, securely).

no rot26 is obv. the best lel

Hehe No one can see my encrypted with ROT-26 message

I can because I know how rot 26 works :open_mouth:

Out of interest, where does the subtract 32 come from?

Yeah… But anyway, making your own code can be super secure if it’s right. I mean if you got


and didn’t know anything about it, surely it would be fairly hard to crack. Just don’t make the source public and it becomes a lot more secure.

Actually no it can’t. It takes extremely talented Mathematicians, and Cryptologists years (or tons of work) to create actual secure cipher. SECURITY THROUGH OBSCURITY IS NEVER A GOOD IDEA. While it is a bonus, it should not be the only security mechanism, or even as a reason to the security of your cipher. Security through obscurity can be said to be bad because it often implies that the obscurity is being used as the principal means of security. Obscurity is fine until it is discovered, but once someone has worked out your particular obscurity, then your system is vulnerable again. Given the persistence of attackers, this equates to no security at all. Obscurity should never be used as an alternative to proper security techniques.

“Security through obscurity” is an expression which uses the term obscurity, not secrecy. Cryptography is about achieving security through secrecy. That’s the whole difference: a password can be secret; an algorithm is, at best, obscure. Obscurity is dispelled as soon as some smart guy thinks about bringing a metaphorical lantern. Secrecy is more like a steel safe: to break through it, you need more powerful tools.Here is some links talking about why it’s bad.

  1. National Institute of Standards, and Technology (Section 2.4, Open Design)
    "System security should not depend on the secrecy of the implementation or its
    components. "
  2. OWASP
    “The security of an application should not rely upon knowledge of the source code being kept secret. Hiding things like hard-coded passwords and otherwise vulnerable code by not releasing the source code is a poor security control (see the Assume attackers have source code Principle for more information). The security should instead rely on a well understood and open design including reasonable password policies, defense in depth, business transaction limits, solid network architecture, and fraud and audit controls. A practical counter-example to relying on obscurity of source code as a security control is Linux. Linux’s source code is widely available, and yet when properly secured, Linux is a hardy, secure and robust operating system.”

There are many more examples, and I shall leave that as an exercise to you.


Ah, Cool. I don’t know anything about encryption so…

fades into background

It’s alright sorry if I came off as harsh. I just wanted to make it overwhelmingly clear (because there are tons who think security through obscurity is okay).

Including me up until 30 secs ago. The more you know!


Check the gist page. I left a comment with more details on the attack, and why it works.

space is the printer’s symbol with the lowest ascii value, and the ascii value of space is 32. If encrypted = decrypted - code, then encrypted - decrypted = code. We know the lowest one in the list (after adding the position back in) is highly likley to be 32, a space.