I understand the basic system of public vs. private keys and how if I want to send a person something, I need their public key and they decrypt with their private key, but what kind of logical mechanisms are at play so that a private key can decrypt what a public key encrypted? For example, say I wanted to write my own asymmetric key system. How would I go about generating these keys in pairs and how would I implement them?
I know there's not just one way to do it, but I am just trying to wrap my head around any way of doing it.
All these systems are based on mathematics. Check out
http://en.wikipedia.org/wiki/Rsa_encryption
it goes through the math.
At one point I actually understood that stuff ;)
To generate the keys, you would need some extremely large prime numbers (for them to be useful in practice, you can do it with 7 and 11 if you want, but thats not so secure).
Related
I'm wondering if the way we "design" keys in Redis can impact performance and scalability.
For example, if I store content related to "users" under keys like "user:<user_id>" and content related to say, groups, under keys like "group:<group_id>", all my keys will start with either "user:" or "group:".
Will this have a negative impact on the way Redis hashes keys internally?
There is no negative impact. Precisely the design you mention is recommended in the official Redis docs, which are quite clear on this:
Very long keys are not a good idea, for instance a key of 1024 bytes is a bad idea ...
but, read on:
Very short keys are often not a good idea. There is little point in writing "u1000flw" as a key if you can instead write "user:1000:followers". The latter is more readable and the added space is minor compared to the space used by the key object itself and the value object. While short keys will obviously consume a bit less memory, your job is to find the right balance.
Try to stick with a schema. For instance "object-type:id" is a good idea, as in "user:1000". Dots or dashes are often used for multi-word fields, as in "comment:1234:reply.to" or "comment:1234:reply-to".
(Emphases mine.)
See also: Redis key naming conventions?
As it is basically a hash table under the hood, there is nothing analogous to a SQL-style WHERE. That's where bad design could effect performance.
No, it shouldn't be any issue with prefixing your keys like that. Redis uses a hash table internally which in turn uses a proper hash function (one of the murmur hashes if I recall correctly) that won't budge by prefixes.
I took up cryptography recently, and 1 of my task was to create a kama sutra cipher. Up till the point of generating the keys, I will have no problems. However, due to the nature of kama sutra, I believe that the keys are not supposed to be hard coded into the program, but rather generated for each plain text it takes in.
What I understand is that the cipher text's length should be the same as the length of plain text. However, the thing is that where do I place the key, such that as long as the cipher text is generated by my program, the program would be able to decipher it even if the program was closed. Given that this is an algorithm, I am sure that I should not be looking at storing the key in another flat file/ database.
There are not many related information online regarding this cipher. What I saw are those that allow you to randomise a key set, generate a cipher text based on the given key set. When decrypting, you will also need to provide the same key set. Is this the correct way of implementation?
For those who have knowledge about this, please guide me along.
If you want to be able to decrypt the cyphertext, then you need to be able to recover the key whenever you need. For a classical cypher, this was usually done by using the same key for multiple messages, see the Caesar Cypher for an example. Caesar used a constant key, a -3/+3 shift while Augustus used a +1/-1 shift.
You may want to consult your instructor as to whether a fixed key or a varying key is required.
It will be simpler to develop a fixed key version, and then to add varying key functionality on top. That way you can get the rest of the program working correctly.
You may also want to look at classical techniques for using a keyphrase to mix an alphabet.
I'm wanting to encrypt some data (hopefully under five hundred bytes' worth) and store it in a QR code. Originally I wanted to use RSA, so the data would be signed with User A's private key and User B's public key, but unfortunately, VB.NET doesn't like encrypting that much data. I've read that I should use Rjindael to encrypt the actual data, and then use RSA to encrypt the key used by Rjindael. However, I'm not having much luck being able to search the web for some kind of tutorial or something.
Also, if I was wanting to store this on a QR code, wouldn't I have to store both the encrypted data and the encrypted key used by Rjindael? Do you think this would all fit? I may be able to use version 40 on medium error correction (according to http://www.denso-wave.com/qrcode/vertable4-e.html, it stores 18,672 "data bits"), but I would prefer to use a lower version (that is, smaller) if at all possible.
Generating the QR code won't be the problem (I know there's a .NET library for that), I'm just curious about getting the data encrypted to begin with.
Thanks for your help!
Sam
Look at the "binary" column. This is actually how many bytes you can store.
Anything above version 10 gets a bit hard to scan in practice, though possible. Above version 20 it's quite difficult from a camera, though can be scanned off a printed page. So if the point is to scan with a camera -- no doesn't sound like it will fit in practice.
When I hear about methods for breaking encryption algorithms, I notice there is often focused on how to decrypt very rapidly and how to reduce the search space. However, I always wonder how you can recognize a successful decryption, and why this doesn't form a bottleneck. Or is it often assumed that a encrypted/decrypted pair is known?
From Cryptonomicon:
There is a compromise between the two
extremes of, on the one hand, not
knowing any of the plaintext at all,
and, on the other, knowing all of it.
In the Cryptonomicon that falls under
the heading of cribs. A crib is an
educated guess as to what words or
phrases might be present in the
message. For example if you were
decrypting German messages from World
War II, you might guess that the
plaintext included the phrase "HElL
HITLER" or "SIEG HElL." You might pick
out a sequence of ten characters at
random and say, "Let's assume that
this represented HEIL HITLER. If that
is the case, then what would it imply
about the remainder of the message?"
...
Sitting down in his office with the
fresh Arethusa intercepts, he went to
work, using FUNERAL as a crib: if this
group of seven letters decrypts to
FUNERAL, then what does the rest of
the message look like? Gibberish?
Okay, how about this group of seven
letters?
Generally, you have some idea of the format of the file you expect to result from the decryption, and most formats provide an easy way to identify them. For example, nearly all binary formats such as images, documents, zipfiles, etc, have easily identifiable headers, while text files will contain only ASCII, or only valid UTF-8 sequences.
In assymetric cryptography you usually have access to the public key. Therefore, any decryption of an encrypted ciphertext can be re-encrypted using the public key and compared to the original ciphertext, thus revealing if the decryption was succesful.
The same is true for symmetric encryption. If you think you have decrypted a cipher, you must also think that you have found the key. Therefore, you can use that key to encrypt your, presumably correct, decrypted text and see if the encrypted result is identical to the original ciphertext.
For symmetric encryption where the key length is shorter than the cipher-text length, you're guaranteed to not be able to produce every possible plain-text. You can probably guess what form your plain--text will take, to some degree -- you probably know whether it's an image, or XML, or if you don't even know that much then you can assume you'll be able to run file on it and not get 'data'. You have to hope that there are only a few keys which would give you even a vaguely sensible decryption and only one which matches the form you are looking for.
If you have a sample plain-text (or partial plain-text) then this gets a lot easier.
I need to provide some passwords, API keys and similar sensitive data in my code. What are best practices in that regard? Hard-coded? SQlite? Some cryptographic framework?
Like the others said, you can't both secure an API key and use it in your app. However, you can do simple obfuscation relatively easy and if the payoff to the cracker is low then you may not get burned.
One simple technique is to break your API key into several sub-strings. Make sure you put them in your code in some random order. For instance, if your API key is 12345678901234567890 you might break it up into 5 sub-strings like this:
static char *part1 = "12345";
static char *part5 = "7890";
static char *part3 = "890123";
static char *part2 = "67";
static char *part4 = "456";
If you run /usr/bin/strings on the resulting binary then you should not see the API key in order. Instead you'll see the API substrings in the order listed in your C file. With 5 substrings like this, that is 5*4*3*2*1=120 permutations. If you break it into 13 substrings you're looking at over 6 billion permutations.
However, that won't stop someone who knows what they're doing from getting your API key if they want it. Eventually you'll have to combine the strings together and pass it to one of your methods, at which point a cracker could use a debugger to set a breakpoint and inspect memory.
Use the Mac OS X Keychain:
Keychain Services Reference
Mac Dev Center: Security Overview
Update:
If your goal is to conceal information from your end users, then I'm not aware of a built-in way to do this.
Hard-coding is a start, but a user with a debugger can read the string out of your binary. To combat this, I've heard of developers that store the data as many separate strings and then combine them at the last minute. YMMV
You can use anyone of the posix compliant C cytographic libraries but as noted above anyone with the skills to crack your code can defeat the encryption by finding the key.
There are a few tricks you can use to slowdown a cracker: (1) Use gibberish names for classes, methods and variables to obscure the code handling encryption e.g. -(void) qwert asdf:(NSString *) lkj; (2) Put in duplicate routines and branches that don't actually do anything. (3) Hide data in unexpected place such as within images.
To add to the direct answers: It's all for naught if you don't use a secure method of transport, such as TLS or SSH. If you're sending the reconstituted API key in clear text, it's not hard for someone to use something like Wireshark or tcpdump (or, a bit more difficultly, a customized router) to capture it after it leaves your app.
If whatever API you're using doesn't offer a method of encrypted access, then there's nothing you can do about that (besides ask for one), but if it does, then you should use it.
You can not secure them. You can only try to hide them so it's not too obvious.
Security by obscurity that is. But I don't think there is a way to keep someone who is willing to get his hands dirty from finding them.