I am reading about cryptography I was thinking about these properties of AES (that I use):
same message = same ouput
no message length secrecy
possible insecurity if you know the messages (does this actually apply to AES?)
I hear that AES is secure, but what if I want to theoritcaly improve these properties?
I was thinking I could do this:
apply encryption algorithm A
XOR with random data D (making sure the output looks random in case of any cipher)
generate random data that are longer than the original message
use hashing function F to allocate slots in random data (this scrambles the order bytes)
Inputs: Encryption algorith A, Data to XOR with D and a hashing function F
My questions are
does the proposed solution theoreticaly help with my concerns?
is this approach used somewhere?
Possible enhancements to this approach
I could also say that the next position chosen by hashing function will be altered using a checksum of the last decoded byte after the XOR step (that way the message has to be decoded from beginning to end)
If I was to use this to have conversation with someone, the data to XOR with could be the last message from the other person, but thats probably a vulnerability.
I am looking forward to your thoughts!
(This is only theoretical, I am not in need of more secure encryption, just trying to learn from you guys.)
Yeah.
Look. If you want to learn about cryptography, I suggest you read Applied Cryptography. Really, just do it. You will get some nice definitive learnings, and get an understanding of what is appropriate and what is not. It specifically talks about implementation, which is what you are after.
Some rules of thumb:
Don't make up your own scheme. This is almost universally true. There may be exceptions, but it's fair to say that you should only invent your own scheme if you've thoroughly reviewed all existing schemes and have specific quantifiable reasons for them not being good enough.
Model your attacker. Find out what scenarios you are intending to protect against, and structure your system so that it works to mitigate the potential attacks.
Complexity is your enemy. Don't make your system more complex then it needs to be.
Stay up to date. You can find a few mailing lists related to cryptography and (and hashing) join them. From there you will learn interesting implementation details, and be aware of the latest attacks.
As for specifically addressing your question, well, it's confusing. I don't understand your goal, nor do I understand steps 3 and 4. You might like to take a quick look here to gain an understanding of the different ways you can use a given encryption algorithm.
Hope this helps.
You assumptions are incorrect.
same message != same output
The output will not be the same if you encrypt the same message twice.
This is because you are suppsed to use different IVs'.
Message length can be hidden by adding random data to the plaintext.
Attacks have been demonstrated against AES with lesser number of rounds.
Full-round AES has not been compromised in any way.
Other than that I suggest you follow Noon Silks recommendation and read Applied Cryptography.
What's the point of the random data XOR? If it's truly random, how will you ever decrypt it? If you're saying the random data is part of the key, you might as well drop AES and use only the truly random key - as long as it's the same length (or longer than) the data and is never used more than once to encrypt. It's called a one-time pad, the only theoretically unbreakable encryption algorithm I know about.
If the random bits are pseudo-randomly generated, it's highly unlikely that your efforts will yield added security. Consider how many talented mathematicians were involved in designing AES...
EDIT: And I too highly recommend Applied Cryptography, it's an actually very readable and interesting book, not as dry as it may sound.
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 currently informed myself about encryption a lot.
And I wonder, whether it would be good to toggle some bits (XOR and bitmasks) at a known position in the encrypted byte array and to toggle them again before decrypting them.
Because even if you know the algorithm and the key it wouldn't be possible to decrypt them propably without knowing where to toggle the bits wouldn't it?
The bit-toggling becomes part of the algorithm, so if "they know the algorithm" comes to include which bits were toggled.
It does become marginally harder to find out that "the algorithm", but this gain is small. If they can get their hands on the key, I think your problem is somewhere else...
There are some disadvantages to this as well. First, you may introduce security flaws in the system. I don't think this will happen, but I don't know I won't, and in security you should assume you might cause security flaws unless you know you won't.
The second problem is that if you make a mistake here somewhere it is possible to corrupt data. Of course, rigid testing will make sure that a mistake won't make it to production, but it just isn't as safe as using the functionality of a security library.
Lastly, there is the problem that your code and data will be harder to work with. If you need to work with it in the future, or someone has to work with it, it'll probably take more effort than it otherwise would have.
Those aren't big things, but I'd say more than the gain. At the end of the day, this is little more than "security through obscurity", so no, I wouldn't say it is a good idea.
You need to look at Kerckhoff's Principle. Any crypto-system needs to be secure, even if the attacker knows the entire algorithm. Only the key must be kept secret. Your bit-twiddling is part of the algorithm, and so will be known to any enemy.
Consider AES. There are public papers describing in great detail exactly how AES works: NIST AES Description. That description of the algorithm is public, yet AES is still secure because if follows Kerckhoff. You need to make sure that your algorithm is secure. Simple bit-twiddling as you describe will not make an insecure algorithm secure. Any attacker will know what bits to twiddle and can untwiddle them and break the underlying insecure cypher.
As an alternative, you could add the bitmask you use to the key. This increases the key size and the processing time for very little security gain. There are usually better ways to increase the security of a cypher, such as adding more rounds.
I am pondering creating a hash function (like md5 or sha1) using the RSA crypto algorithm. I am wondering if there are any obvious reasons that this algorithm wouldn't work:
Generate RSA public/private keys.
Discard private key, never store it at all.
Begin with a hash with a length of the block size for the RSA encryption.
Encrypt message using public key, one block at a time.
For each encrypted block of the message, accumulate it to the hash using a specified algorithm (probably a combination of +, xor, etc.)
To verify a message has the same hash as a stored hash, use the saved public key and repeat the process.
Is this possible, secure, and practical?
Thanks for any comments.
RSA encryption is not deterministic: if you follow the RSA standard, you will see that some random bytes are injected. Therefore, if you encrypt with RSA the same message twice, chances are that you will not get twice the same output.
Also, your "unspecified step 5" is likely to be weak. For instance, if you define a way to hash a block, and then just XOR the blocks together, then A||B and B||A (for block-sized values A and B) will hash to the same value; that's collision bonanza.
Academically, building hash functions out of number-theoretic structures (i.e. not a raw RSA, but reusing the same kind of mathematical element) has been tried; see this presentation from Lars Knudsen for some details. Similarly, the ECOH hash function was submitted for the SHA-3 competition, using elliptic curves at its core (but it was "broken"). The underlying hope is that hash function security could somehow be linked to the underlying number-theoretic hard problem, thus providing provable security. However, in practice, such hash functions are either slow, weak, or both.
There are already hashes that do essentially this, except perhaps not with the RSA algorithm in particular. They're called cryptographic hashes, and their salient point is that they're cryptographically secure - meaning that the same strength and security-oriented thought that goes into public key cryptographic functions has gone into them as well.
The only difference is, they've been designed from the ground-up as hashes, so they also meet the individual requirements of hash functions, which can be considered as additional strong points that cryptographic functions need not have.
Moreover, there are factors which are completely at odds between the two, for instance, you want hash functions to be as fast as possible without compromising security whereas being slow is oftentimes seen as a feature of cryptographic functions as it limits brute force attacks considerably.
SHA-512 is a great cryptographic hash and probably worthy of your attention. Whirlpool, Tiger, and RipeMD are also excellent choices. You can't go wrong with any of these.
One more thing: if you actually want it to be slow, then you definitely DON'T want a hash function and are going about this completely wrong. If, as I'm assuming, what you want is a very, very secure hash function, then like I said, there are numerous options out there better suited than your example, while being just as or even more cryptographically secure.
BTW, I'm not absolutely convinced that there is no weakness with your mixing algorithm. While the output of each RSA block is intended to already be uniform with high avalanching, etc, etc, etc, I remain concerned that this could pose a problem for chosen plaintext or comparative analysis of similar messages.
Typically, it is best to use an algorithm that is publicly available and has gone through a review process. Even though there might be known weaknesses with such algorithms, that is probably better than the unknown weaknesses in a home-grown algorithm. Note that I'm not saying the proposed algorithm has flaws; it's just that even if a large number of answers are given here saying that it seems good, it doesn't guarantee that it doesn't. Of course, the same thing can be said about algorithms such as MD5, SHA, etc. But at least with those, a large number of people have put them through a rigorous analysis.
Aside from the previous "boilerplate" warnings against designing one's own cryptographic functions, it seems the proposed solution might be somewhat expensive in terms of processing time. RSA encryption on a large document could be prohibitive.
Without thinking too much about it, it seems like that would be cryptographically secure.
However, you'd have to be careful of chosen plaintext attacks, and if your input is large you may run into speed issues (as asymmetric crypto is significantly slower than cryptographic hashes).
So, in short: yes, this seems like it could be possible and secure… But unless there is a really compelling reason, I would use a standard HMAC if you want a keyed hash.
As mentioned above step 4.) is to be done deterministic, i.e. with modulus and public key exponent, only.
If the hash in step 3.) is private, the concept appears secure to me.
Concerning Step 5.): In known CBC mode of kernel algorithms the mix with previous result is done before encryption, Step 4.), might be better for avoiding collusions, e.g. with a lazy hash; XOR is fine.
Will apply this, as available implementations of known hash functions might have backdoors :)
Deterministic Java RSA is here.
EDIT
Also one should mention, that RSA is scalable without any limits. Such hash function can immediately serve as Mask Generation Function.
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 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.