I know Python is a powerful programming language but is it secure for cryptography? I mean is it possible to reverse engineer the program (written in python) and discover the algorithm of cryptography or other things?
-
5$\begingroup$ Anything compiled to run on a processor using a standardized instruction set can be reverse engineered $\endgroup$– Richie FrameCommented Nov 2, 2014 at 8:56
-
$\begingroup$ Python is interpreted and considered on that basis alone to be slow, but libraries like numpy and pandas are used in scientific computing with big data and with good programming practices and just in time compilers like pypy.org, you can see performance increases of 400x to 1500x. see nbviewer.ipython.org/github/fonnesbeck/Bios366/blob/master/… $\endgroup$– HarveyCommented Jan 21, 2015 at 20:32
-
4$\begingroup$ And because anything can be reverse-engineered, it's a bad idea to rely on keeping the cryptosystem secret. $\endgroup$– cpastCommented Jan 21, 2015 at 21:04
3 Answers
Python is a scripting language, so if you've got the program, you usually also have the source code. So you don't even have to reverse-engineer. That doesn't matter much for two reasons:
- other languages are pretty easy to reverse engineer (or they are complex for both the programmer and the attacker);
- the algorithm does not have to be kept safe anyway, due to Kerckhoffs' principle
Now the above does not directly make Python suitable for cryptography. One of the main things about cryptography is security. Without a secure programming environment, you can have any strength of cryptography, and still not have a secure system.
Languages have many constructs that make them more or less suitable for security and cryptography, so I show a few and indicate how Python fares:
type system: it has a dynamic type system with strong typing - with regards to security this is not as good as a static type system but it is better than weak typing;
character encoding: not good, python may confuse bytes and characters if specialized classes are not used;
operations on bytes, 16 bit words, 32 bit words and 64 bit words: not good, python simply regards everything as an unbounded number;
operations on large integers: good; modular exponentiation can be done directly on numbers using pow();
destruction of keys & state: this is a problem for any language that doesn't directly manage it's memory; Python is not likely to fair better than the rest, it may be hard to prove that keys can be safely destroyed while the program is running.
Finally, in general people like their systems to be fast. Unfortunately, scripting languages are often not fast with regards to binary operations required for symmetric cryptography (SHA-256, AES). Interpreted languages such as Java are already much faster, but languages such as C and assembly are faster than that (when used correctly).
More important for regular use of cryptography is the maturity of cryptographic support provided in libraries. Python has a relatively well kept crypto libraries called PyCrypto, PyOpenSSL available; those libraries however are mainly implemented mainly in C. These and other libraries are discussed here. One advantage of PyOpenSSL is that it should be possible to securely store and use keys from a hardware module (for instance a smart card or HSM).
Note that side channels may apply when using Python for direct implementation of cryptographic primitives. I'd say that Python is especially OK for fast prototyping of cryptographic primitives rather than library creation.
All in all, I would summarize that Python is OK-ish, but not great for cryptography if such a generalist statement can be made at all.
-
1$\begingroup$ Compared to JavaScript and PHP, Python is heaven, so if you require a scripting language you can certainly do worse than Python. That's basically because you cannot do worse than JS or PHP though. $\endgroup$– Maarten Bodewes ♦Commented Nov 2, 2014 at 16:18
-
$\begingroup$ BTW, most of the points do not really address the question: is Python secure. Type safety and destruction of keys&state is are the ones that do. It's mainly about how easy is it to implement something, i.e. what operations are provided by the language. The OP could edit his question to reflect what he actually wanted to know, so that people wanting to ask similar questions finds it. $\endgroup$ Commented Nov 2, 2014 at 17:03
-
$\begingroup$ I asked this question because i heard recently that someone has found a bug in Truecrypt encryption software! So i thought even i can make an encryption program with python finally someone will find a bug! $\endgroup$– hamedb71Commented Nov 2, 2014 at 17:04
-
2$\begingroup$ @hamed71: Your current question is about whether Python can help you hide implementation details. It seems like what you want to know is whether as a language it will help you write correct code? $\endgroup$ Commented Nov 2, 2014 at 17:13
-
2$\begingroup$ That question invariably leads to some kind of flame war. I would be able to argue successfully that such a language does not yet exist, and that too little research is being done on such languages / security in general (let alone that they get mainstream support). $\endgroup$– Maarten Bodewes ♦Commented Nov 3, 2014 at 7:51
The point of cryptography is having algorithms that are secure even when the attacker knows them. Google security by obscurity to see why it's bad.
I'll add the following based on otus comment. Python can be reverse engineered, so you can't hide your algorithms. Basically, if someone can run your code, they can reverse engineer the algorithms. The point of crypto is that you can publish all your algorithms to the world, and, unless you tell them some secret key, they won't be able to break the encryption.
However, in practice you'll have issues like side channel attacks, i.e. the code leaks information about the data it's processing. This includes secret keys. This will pop up in any programming language unless you really know what you're doing. If you use a crypto library in Python, then most of these issues are more or less a problem of the library writer, so you need to trust that they know what they're doing, but even the user can use the library in bad ways.
To conclude, Python is neither better or worse than any other programming language as long as you use a good crypto library. However, if you're thinking about implementing something like RSA yourself or some other crypto algorithm you found in a book/paper, then most probably the code will be vulnerable unless you're an expert and you really know what you're doing. This applies to any language.
First of all, python is interpreted and almost always exists in source code... Reverse engineering is thus pointless. The source code is already public. However, like Maarten and Edvard say, that doesn't matter. An RSA algorithm is secure even though everyone who wants to can find out how it works.
The only real concern about python is that it has dynamic types and is a managed language, both of which make it faster to write code with... And slower to run. This means it would take longer for python to encrypt the same amount of data.
However, this has nothing to do with the real "security" of the language. Python would take longer to run the same algorithm, but since it is the same algorithm the resultant encryption would be identical to that of a different language. Language really has no effect on actual security.
With this clarified, I also feel I should address sideline attacks, which could certainly be a security concern. Sideline attacks are still a matter of the algorithm being used, not the language that runs it. Sideline attacks can be a concern when the algorithm does not adequately conceal information from an attacker who sends altered versions of messages they intercepted. For example, a CTR mode AES algorithm has fairly strong security in most circumstances, but is really quite vulnerable to a sideline attack. On the other hand, a better algorithm like GCM mode AES can recognize that it is trying to decipher an altered message, and will give the attacker far less information, rendering sideline attacks impractical.