What are the possible ways to attach the iv to the encrypted string. Prepending iv as the first sixteen is the most common approach. Are there any other ways can we able to do it?
You can attach it however you like (at the beginning, or end, or middle if you really feel like it), or send it separately, via smoke signals if you like! As long as your decryption code knows where to find it. At the beginning is certainly the logical place for it though (especially if you want to start decrypting before you've got the entire ciphertext). But from a security point of view, there isn't a reason not to put it elsewhere if you have that need for some reason.
Just remember that you should assume any eavesdropper knows where you've put the IV. You shouldn't consider that to be a secret.
Related
sorry if there is an answer to this somewhere, but I could not find a clear explanation.
If I need to encrypt a sensitive field before storing it in my db, can the following approach possibly work?
I write a hard-coded encryption-cipher algorithm (in my php file) without any random behavior, like shuffling a deck of cards in a certain sequence, but only I know the exact sequence. I then also write the exact opposite algorithm to de-crypt the ciphered field, thus (hopefully) eliminating the need for a decryption key.
My understanding is that only the resulting string will be exposed to http(s) traffic and even if the result is posted back it is over https.
Can this approach work?
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'm building a simple trivia game that has "hangman" style clues (where letters are revealed as the player asks for hints). I don't want to flat out send the answer with the question any user with sufficient smarts could figure it out) - rather I'd like to encrypt answers on the server and decrypt them on the client. Security isn't of huge importance I just want to make the process harder then it's worth for players. I was wondering if anyone could recommend a strategy for doing this?
A simple approach, which might be sufficiently difficult for most users, would be to send the answer and encryption key to the web client (as hidden form fields), and use Javascript to decrypt it on the fly (inside the browser). A simple exclusive-or'ing of the answer string characters with the key string should be sufficient to "shroud" the answer without requiring large amounts of crypto processing on the client side. Using more than one key string might increase the difficulty of cracking it, too.
I'm assuming that you don't want to implement full commercial-grade crypto on the client side, and also assuming that you only want to hide the answers for a few minutes at most.
I want to ask for a mature model to do this.
Suppose I want to deliver a program and a sensitive data file to user. The program is able to read any data stored in the data file, but user is not allowd to easly break the data file. The data file will be encrypted by standard algorithm such as AES. Now, the problem turns to how to manage the key. Putting the key in the program seems to be a bad idea, but what else I can do? Apparently I can't give the key to user directly.
There is no way to do this securely, ie. to really prevent the user from reading the data. As long as they have the data and they have the program that can read it a competent disassembler will be able to figure out how the program reads it and do the same thing. Or, even easier, they could let the program do it and then get the decrypted version out of its memory.
Having said that, if you just want to prevent the average user from doing it, hardcoding the key in your source code should be fine. :) Just be realistic about the level of protection this provides.
Does it have to be pure software? If not, you could look at a solution which does decryption and storage of the key on a hardware device, e.g. a USB dongle.
You can also potentially prevent the whole problem by having your software retireve the data from a web-service instead of a data file. In this case you can control access to the data much more tightly (i.e. who gets how much of what and when). This might or might not work for your application.
Otherwise as others pointed out, there is no known good pure software solution.
There is no 100% safe solution to this because at some point you have to have the key loaded into memory so that de/encryption can take place and a savvy-enough hacker will be able to capture it. The best you can do is to make it very difficult to capture and to mitigate exposure to data (by limiting access as much as possible) if the key is compromised.
As far as how to make it safer... you could have a combined key that is made up of something stored in the program and something derived from the user's passcode?
Is your perceived user determined? are they skilled enough to do reverse the application or the key? If the user is considered to just be a generic desktop user you probably could implement a partial key using some general encryption just to make the key non obvious, beyond that a determined individual will be able to reverse must simple means of encrypting keys and data.
A DVD John conundrum, eh? Why is having a key in the program bad? You could have a super-obscured function which computes it reliably once. Someone with disassembler and debugger can break your key given enough time, IMO.
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.