Team,
I would like to have asymmetric encryption using AES algorithm for iPhone application using Objective C.
I have widely seen symmetric encryption using AES, so im not sure about the support for asymmetric encryption with AES. Kindly suggest me on this.
AES is a symmetric cipher. It can't simply be used an an asymmetric (i.e., public-key) capacity.
I am guessing the reason for your question is the issue of key exchange - such that you can establish an AES-encrypted connection without having to rely on a pre-shared key.
Numerous valid approaches exist, but I'll just hit on two:
Take a look at or Diffie-Hellman. You can get both sides of a connection to agree on a key without actually having to exchange that key. http://en.wikipedia.org/wiki/Diffie–Hellman_key_exchange
RSA. I'm a fan of Botan. It's free. It works. You can generate public/private key pairs on both sides, exchange the public keys, then securely exchange private keys, and then start AES. http://botan.randombit.net/pubkey.html
As always, this advice needs to be accompanied with a warning: it's very easy to do this incorrectly and largely (or entirely) thwart your security efforts. Tread carefully.
Related
After reviewing the subject craefully, I know understand how ECDHE-RSA provides PFS by creating a new set of private and public keys for every session.
Yet what I cannot understand, is how does this scheme relates to the basic DH scheme? The same one that is explained by using colors.
It seems to me that the basic DH scheme I know for key exchange, is not occuring on ECDHE-RSA, and instead, just a generation of new private and public key for every connection.
My question is,
How does ECDHE-RSA scheme even relates to the basic DH scheme of secure key exchange? its seems that ECDHE-RSA is just like using AES-RSA, with a new set of key of each connection. Can't seem how Diffie-Hellman itself is actually involved in the process.
There's a few things going on here, some of which might be implementation dependent. Lets start with what that long acronym of ECDHE-RSA means.
ECDHE means Elliptic Curve Diffie-Hellman Ephemeral. The first part, Elliptic Curve, talks about the dirty math behind the cryptography. For implementation purposes, it basically means that you can use shorter key lengths without compromising the security.
Diffie-Hellman is the key exchange protocol. Its a method to derive a secret key over an unsecured communication line. However, the standard DH protocol is subject to a Man-in-the-middle attack. This means that an adversary can intercept a few messages, alter them if he so chooses, and forward them on to the recipient without no one being none the wiser. Standard DH does not provide authentication. This is where the RSA bit will come in handy later.
Ephemeral means that we are doing an ephemeral key exchange and the key generated will only be used for this communication session. This is what provides perfect forward secrecy.
Now back to the RSA bit: RSA can provide authentication by means of asymmetric cryptography. By using private and public keys to secure the messages in the DH protocol, you can prevent these MITM attacks.
Then why isn't RSA and asymmetric crypto used everywhere? Asymmetric crpto functions are computationally expensive to do. It is more efficient to use asymmetric crypto to negotiate a shared secret and used symmetric crypto for the renaming transaction.
Yes, Elliptic Curve Diffie-Hellman is very much like Diffie-Hellman, but it uses a different math basis for the same "using paint" algorithm.
Classic Diffie-Hellman is a based on Finite Field Cryptography (FFC), with the formula s = mod(exp(mod(exp(g, a), p), b), p) (which produces the same value if a and b are flipped). That's a fairly unfriendly formula.
EC Diffie-Hellman is based on Elliptic Curve Cryptography (ECC), with the formula s = a*b*G, which only requires believing in the commutativity of multiplication to understand why it works (only the X coordinate is used in the end, and... of course, the actual math of multiplying by G is pretty ugly; but both a and b are just (large) integers).
To use the paint colors analogy of classic DH:
A common curve is used by both parties. Every "curve" in ECC has an established start point (G=generator); to compare with the Wikipedia picture, call it yellow.
Alice has a private key, a, that says how many times to let the Press Your Luck game board advance around the color wheel. The selected color combined with G produces the color peach.
Bob has a private key, b. Using the Press Your Luck analogy he gets light blue after combining with G.
Just like the classic DH picture, merging Alice's peach with Bob's secret Press Your Luck color produces the same color as merging Bob's light blue with Alice's secret Press Your Luck color.
For mathy reasons, ECC keys are more "densely secure". So a 160-bit ECC DH key is as secure as a 1024-bit FFC DH key. So it lets the same security go much more quickly, which is why ECDH is replacing DH and ECDSA is replacing DSA. Using the more common secp256r1 curve (which uses 256-bit ECC keys) it gains up to the equivalence of a 3072-bit FFC DH key.
I am attempting to use RSA public key encryption to encrypt a AES+CBC key over a network, however I'm having trouble finding the right tools or setup in order to achieve my goal.
I've been looking over at the Transforms API, which is perfectly capable of using RSA for signing/verifying data, but have thus far been unable to figure out how to utilize it for encrypting itself.
My question is therefore as follows: Am I stuck with libcrypto/OpenSSL or is what I'm trying to accomplish actually still possible with the API? The goal being using `SecEncryptTransformCreate' etc. to use RSA rather than AES/Symmetric encryption.
SecEncryptTransformCreate seems to support both PKCS#1 (v1.5, although it doesn't say) and OAEP padding, according to the API. I've also seen some samples for the (more secure) OAEP padding.
Again, the API does not seem to specify RSA anywhere, but PKCS#1 padding and OAEP padding are RSA specific encryption schemes.
So you seem to be looking at the correct API to use. Note that to encrypt larger amounts of plain text you should be using hybrid encryption (both AES and RSA).
Say I have some data and a password, and I want to encrypt the data in such a way that it can only be recovered with the right password.
How does this technically work (i.e. how to implement this)? I often hear people use bitshifting for encryption, but how do you base that on a password? How does password-based encryption work?
An example is Mac OS X FileVault
Thanks.
If you give sample code, preferably in C, Objective-C or pseudocode.
For (symmetric) encryption you need a secret key for encryption and decryption.
Usually, the password you supply is used as the source of this key. For various security reasons, the password is not (and often cannot, due to requirements of the cipher used) directly used as the key. Instead, a key derivation function is used to generate the key from the password.
This is why passwords for encryption must be long and fairly random: Otherwise the resulting key will only come from a very small subset of possible keys, and these can then simply all be tried, thus brute-forcing the encryption.
As to code examples, there are several possibilities:
look at the source code of a crypto library, such as OpenSSL
look at the source code of a program that implements encryption, such as GnuPG
google some sample source code for a simple encryption algorithm, or a key derivation function, and try to understand it
This depends on what you want to learn.
You'll need to look to other resources for a deep explanation, as this question is extremely broad.
Speaking generally: you use a password as a "seed" for an encryption key, as sleske pointed out. Then you use this key to apply a two-way encryption algorithm (i.e. one that can be applied once to encrypt and again to decrypt). When you apply the algorithm to a piece of data, it becomes encrypted in such a way that you could never get the data back out again without using the same key, and you can't practically produce the same key without having the same password as a seed.
If you're interested in crypto, read Applied Cryptography by Bruce Schneier. Excellent read, lots of examples. It goes through many different cryptography types.
An easy way, but not exactly secure, is to rotate each byte by a number determined by the password. You can use a hash code from a string, or count the number of characters, or whatever for the number.
What you are probably thinking of, though, is public key encryption. Here is a link to a document that will tell you the math for it - you'll have to work out the implementation details yourself, but it's not that hard once you understand the math.
http://mathaware.org/mam/06/Kaliski.pdf
The basic building block of most block ciphers is a construction called a Feistel Network. It's reasonably easy to understand.
Stream ciphers are even simpler - they're essentially just pseudo-random number generators, albeit with some important security properties, where the initial internal state is derived from the key.
Password based encryption IS symmetric. The input usually consists of a salt in addition to the password. FooBabel has a cool app where you can play around with this... currently they hard code the Salt to an array of eight bytes (zero to seven) for simplicity. I put in a request to see that they let users input the salt. Anyway, here it is - PBECrypto
Does anybody know some simple authentication and data transfer protocol based on symmetric keys only? Due to memory constraints (kilobytes RAM and ROM) we cant afford asymmetric cryptography and due to closed environment asymmetric cryptography does not increase security of any way.
I am looking for simple symmetric cryptography protocol that can be kept in head and written on one paper sheet. I was looking in EAP-PSK https://www.rfc-editor.org/rfc/rfc4764#page-4 but still think that 2^6 pages is way to much for something simple and secure.
Does anybody know some useful url, paper or idea?
For secrecy, use AES-CBC. For message authentication, use HMAC-SHA256. Use a different key for each.
In both cases, use an existing, validated, timing-attack-free implementation of the cryptographic primitives.
I think you're looking for the Diffie-Hellman key exchange: only requires bignum integer arithmetic (powers, multiplication, and modulus only, at that): http://en.wikipedia.org/wiki/Diffie–Hellman_key_exchange
I am a newbie in cryptographic system but i have seen many sources tell that
even the good algorithm and good key is not enough,
i have a little confuse why is that?
Possibly not enough because in the game of cryptography there is also the trust part.
Anyway, check out this article: Security Pitfalls in Cryptography
http://en.wikipedia.org/wiki/Cryptographic_engineering
There are two basic kinds of encryption algorithms in use today:
Private key cryptography, which uses the same key to encrypt and decrypt the message. This type is also known as symmetric key cryptography.
Public key cryptography, which uses a public key to encrypt the message and a private key to decrypt it. The name public key comes from the fact that you can make the encryption key public without compromising the secrecy of the message or the decryption key. Public key systems are also known as asymmetric key cryptography.
http://www.amazon.com/Applied-Cryptography-Protocols-Algorithms-Source/dp/0471117099
. This book is nice one regarding this
Algorithms
http://hell.org.ua/Docs/oreilly/tcpip/puis/ch06_04.htm
U can read this patent is talking about US Patent 6769062 - Method and system of using an insecure crypto-accelerator
http://www.patentstorm.us/patents/6769062/claims.html
Read this http://www.schneier.com/essay-028.html
Your question is vague, but I'll add an aspect that is important: The users handling of the key and understanding of the system. Cryptography does in a way move the target from the communication to the sender or recipient.
Also, the algorithms quality is only halfway there - the implementation of the algorithm can introduce unforseen security issues.
The security of a system depends on many factors, only one of which is the cryptosystem of choice.
Modern symmetric (e.g. AES) and asymmetric (e.g. RSA) cryptosystems are very secure (read: practically impossible to break) in themselves, but the way you use the cryptosystem, and user behavior changes everything.
I've always argued that even the most basic cryptographic tasks should be done, or at least supervised, by cryptography experts, and Jeff has recently proved me right.
If you have had no formal education on cryptography, please seek professional advice from an expert.