For AP Computer Science my class had to use Snap whose source can be found at https://github.com/jmoenig/Snap--Build-Your-Own-Blocks in class. We had to make a simple encryption algorithm using a Caesar cipher. I thought to myself, why can't you use something more secure?
So I tried making RSA encryption in Snap. I realize snaps computing limitations but wanted something a small as 1 bit or 2 bit encryption to work. My code can be found on this webpage.
The code however does not work and I wanted to know if it was because my understanding of RSA was wrong or I missed a step in RSA. My end goal is for my code to be able to encrypt any text in 1 or 2 bit RSA.
Here is the actual code:
Related
i'm a novice and trying the security shepard project where you have to pass challenges. https://www.owasp.org/index.php/OWASP_Security_Shepherd
I did all of the challenges but one that i have a really a hard time with.
To complete this challenge you have to find the key to an encryption method.
They just give you an application that can decrypt encrypted text.
IAAAAEkQBhEVBwpDHAFJGhYHSBYEGgocAw== gives This crypto is not strong.
Unlike other challenges there is no information in the source code.
I don't understand how I'm supposed to proceed.
Thanks
Instead of trying to find the algo, just try to find the algos which are most unlikely to be possible. for a instant, this is not a classic mono-alphabetic or key-less transposition cipher. On the other hand compare input and output bit sizes. Narrow down your possibilities like that and it will helps you to decide which cryptanalysis method to be used.
This may be not the perfect approach, but sure it's a start.
I have been reading up on encryption algorithms and am trying to implement them with my research without using any libraries. However, I am finding it a bit difficult to understand how they work.
The algorithms I have looking at in particular are,
triple des - uses 3 keys, 1st to encrypt, 2nd to decrypt and third to encrypt again
RSA - uses large positive integers to generate encryption and decryption e.g., e,d and n
AES - uses substitution permutation with fixed blocks of bits and key size.
I have searched online and came across many libraries like cryptoJS, OpenPGP and cryptico but am finding it hard to follow the code - because of being new to them.
I understand the main idea behind them but finding it difficult to put in code, please can someone guide me - is there any psuedo code/psuedo algorithm that I can use or make reference to when implementing.
I have implemented AES and DES on Java. For my experience, If you know theory everything is very simple. You can get MIT or Stanford course of cryptography. Anyway first off all you should know theory. After that there are too many implementations at Github. You may even use Youtube to see how algorithm encrypts on sample data.
To be honest I love resources of Ruhr University Bochum. AES/DES are chapter III, IV. This is official web page link. They have recorded video lectures and also free book, named "Understanding cryptography" published by Springer.
P.S BouncyCastle is very popular library. It is very well implemented on Java. You can look at this too.
I don't know much about the heavy math behind cryptosystems, I get stuck when it gets bad with the Z/nZ algebra, and sometimes with all these exponent of exponents. It's not I don't like it, it's just that the information you find on the web are not easy to follow blindly.
I was wondering: how reliable can a algorithm be when it encodes a message into plain binary. If my algorithm is arbitrary and known only to me, how can a cryptanalist study an encrypted file and decrypt it, with or without having the decoded file ?
I'm thinking about not using ASCII text to code my message, and I have some ideas to make this algorithm/program.
Attacking a AES or blowfish crypted file is more trivial for a cryptanalyst, than if the algorithm the file is encrypted with is unknown to him, but how does he do then ?
I don't know if I understanded well, but a CS teacher once told me that codes are harder to crack that crypted ciphers.
What do you think ?
Attacking a AES or blowfish crypted file is more trivial for a cryptanalyst, than if the algorithm the file is encrypted with is unknown to him...
What about:
Attacking an untested self written algorithm with no real research is more trivial for a cryptanalyst, than if the algorithm the file is encrypted with, is a well known and proofed one, that has been correctly used....
In short, DO NOT roll your own cryptography unless you're an expert, no unless you're part of an expert group in that field.
Nintendo failed when they implemented RSA on their own in the Wii, Sony failed too when using it in the PS3 (they pretty much used XKCD's random number function for M...)
And you really think you can win by using security by obscurity?
PS: That doesn't mean that you should take the Wikipedia entry on RSA and roll you own implementation from that one (that's exactly were Sony and Big-N failed), no use a tested, open source implementation.
You seem to be using two words interchangeably but remember that Encoding is Not Encryption
When the attacker has no idea which algorithm you used and it is safe, cryptoanalyst has a hard job. So it is unimportant if you use AES or your own cipher as long as it is as strong and safe as AES. Here is the but. Cryptography is a bit demanding and therefore you have many ways to shoot yourself in a foot without knowing it. I would suggest using standard algorithms, maybe with some safe variations.
Common wisdom is that you should not build your own algorithms, and especially not rely on these algorithms remaining secret.
The conceptual reason is that good encryption is about quantified confidentiality. We do not want our secrets to get cracked, but in a more precise way we want to be able to tell how much it would cost to crack our secrets (and hopefully show that the cost is way too high to be envisioned by any entity on Earth). This is the real advance which occurred a few years after World War II: to understand the distinction between key and algorithm. The key concentrates the secret. The algorithm becomes the implementation.
Since the implementation is, well, implemented, it exists as some code or a device, which is tangible and stored even when it is not used. Keeping an implementation secret requires keeping track of the hard disk on which the code resides at all times. If the attacker sees the binary code, he may be able to reverse-engineer it, something which depends on his wits and patience. The point here is that it is very difficult to be able to say: "it costs X dollars to recover a description of the algorithm".
On the other hand, the key is short. It can be stored safely much more easily; e.g. you could memorize it, and avoid committing it to any permanent storage device. You then have to worry about your key only at times when you use it (and not when you do not, e.g. in the middle of the night, when you sleep). The number of possible keys is a simple mathematical problem. You can easily and accurately estimate the average cost of enumerating the possible keys until your key is found. The key is a sturdy foundation for quantified security.
So you should not roll your own algorithms because then you do not know how much security you get.
Also, most people who rolled their own algorithms found out, usually the hard way, that they did not get much security at all. Designing a good encryption algorithm is hard, because it cannot be automatically tested. Your code may run, and properly decrypt data that it encrypted, but it tells you nothing about how secure the algorithm is. The design of the AES was the result of a process which took several years and involved hundreds of skilled cryptographers (most of whom had a PhD and years of experience in academic research on symmetric encryption). That a lone developer could do as well, let alone better, in the secrecy of his own workshop, looks kind of... implausible.
The biggest part of your strategy is called "security through obscurity." You're making the gamble that, since nobody knows the precise details of your little variation on an idea, they won't be able to figure it out.
I'm not a security expert, but I can tell you that you probably won't come up with something incredibly new. Cryptography has been studied by people for millenia and your idea is highly unlikely to be original. Even if you're a relatively good programmer and code something really tricky, the question will come down to who you're up against. If you're just trying to protect your data from your kid sister, then it will probably be fine. On the other hand, if you're using it to send credit card numbers across the internet, then you're doomed to fail. It will be analysed in ways you didn't think of or don't know, and ultimately cracked.
Another way to think of it: algorithms like AES have been extensively studied by professionals in the field and its level of security is pretty well understood. Anything you come up with by yourself will not have the benefit of having been attacked by the best and brightest minds out there. You will have almost no idea of how good it actually is until people start reporting identity theft.
I heard some time that encryption and cipher are not the same thing, if so, what's the difference?
a cipher is a method (algorithm) used for encryption of some text. But english speakers have that habit of making verbs from nouns... hence ciphering became a synonym of encrypting.
Now, the fun part. If you consider decrypt and decipher, now they have different meanings.
decrypt means applying the decryption key to some code
decipher means finding the meaning of some text that was not deliberately encrypted.
In France (I'm french) we also have funny confusion with similar words. We have "chiffrer" (very similar to "cipher") that is the correct word and means encrypt, but we also use the verb "crypter" that means the same thing but is considered as an anglicism (verb built from english "crypted"). When we go for the opposite words "décrypter" and "dechiffrer" we also have different meanings but not like the english ones... "déchiffrer" means the same that both english words decrypt and decipher depending on the case, but "décrypter" is used when you try to get the clear text without the code (it means breaking the code). I believe there is no english word that means that.
Looking at my answer, I wonder if things were not clearer before it.... natural language is definitely some kind of encryption.
You might take a look at this article on the difference between Encryption and Cryptography. It also addresses the definition of cipher in the process.
Excerpts:
What is Cryptography?
In simple terms, cryptography is the science concerned with the study of secret communication.
What is Encryption?
...
... "encryption" basically is some process or algorithm (known as a cipher) to make information hidden or secret. And to make that process useful, you need some code (or key) to make information accessible.
A cipher is an algorithm of encryption. Ex. substitution cipher, permutation cipher, etc.
Encryption is just the process of obfuscating information.
So in a simplistic sense of the idea, you use a cipher to encrypt stuff. :)
I realize this question might not be that programming related, and that it by many will sound like a silly question due to the intuitive logical fault of this idéa.
My question is: is it provable impossible to construct a cryptographic scheme (implementable with a turing-complete programming language) where the encrypted data can be decrypted, without exposing a decryption key to the decrypting party?
Of course, I can see the intuitive logical fault to such a scheme, but as so often with formal logic and math, a formal proof have to be constructed before assuming such a statement. Is such a proof present, or can it easely be constructed?
Thank you for advice on this one!
Edit: Thank you all for valuable input to this discussion!
YES!!! This already exists and are called zero knowledge protocols and zero knowledge proofs.
See http://en.wikipedia.org/wiki/Zero-knowledge_proof
However, you have to have a quite a good background in mathematics and crypto to understand the way it works and why it works.
One example of a zero knowledge protocol is Schnorr's ZK protocol
No; but I'm not sure you're asking what you want to be asking.
Obviously any person who is decrypting something (i.e. using a decryption key) must, obviously, have the key, otherwise they aren't decrypting it.
Are you asking about RSA, which has different keys for decrypting and encrypting? Or are you asking about a system where you may get a different (valid) result, based on the key you use?
If by "decrypted" you just mean arrive at the clear text in some way, then it is certainly possible to create such a cryptographic scheme. In fact it already exists:
Take an asymmetric encryption scheme, eg: RSA where you have the public key but not the private key. Now we get a message that's been encrypted with the public key (and therefore needs the private key to decrypt it). We can get the original message by "brute force" (yes, this'll take an enormously long time given a reasonable key/block size) going through all possible candidates and encrypting them ourselves until we get the same encrypted text. Once we get the same encrypted text we know what the decrypted text would be without ever having discovered the private key.
Yes.
Proof: Encryption can be considered as a black box, so you get an input and an output and you have no idea how the black box transforms the input to get the output.
To reverse engineer the black box, you "simply" need to enumerate all possible Turing machines until one of them does produce the same result as the one you seek.
The same applies when you want to reverse the encryption.
Granted, this will take much more time than the universe will probably live, but it's not impossible that the algorithm will find a match before time runs out.
In practice, the question is how to efficiently find the key that will decode the output. This is a much smaller problem (since you already know the algorithm).
It's called encoding.
But everyone with the encoding algorithm can "decrypt" the message. This is the only way of keyless encryption.