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.
Related
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).
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.
Up to now, I thought that if I have RSA-encrypted data, this data would be easily exchangable between most platforms (.net, java, pc, unix..), because of the commonly used algorithm.
Through investigating for another questions I had, I'm now confused. I have found even between MS-implementations differences (some provider reverse the resulting byte-array). Moreover the padding seems not to follow a standardization.
Can someone with experience in cross platform cryptography give a statement, if RSA-encoded data is relatively simple exchangable (with some obvious pitfalls) or if this is a headache?
Note that RSA encryption is normally not used by itself, but in combination with a symmetric encryption algorithm.
So, to make sure to be interoperable, you need to make sure that:
Both sides use the same padding scheme for RSA (e.g. the one originally defined in PKCS#1 v1.5, or OAEP). (That does not mean that the padding has to be deterministic, just that the decrypter know which bits of the decrypted text was padding and which were the original message).
Both sides use the same format for their messages (e.g. the one in PKCS#7 or its successors).
Both sides use the same symmetric algorithm (e.g. AES-128), mode of operation (e.g. CBC) and block cipher padding scheme (e.g. PKCS#5-padding).
The encrypting party must use the public key corresponding to the private key used by the decrypting party.
The simple answer to your question is no, the cryptographic algorithm itself does not specify how to store or transmit bytes between implementations to ensure interoperability. For that you must use a standard format or protocol that gives these instructions down to the bit level. For example, in Paulo answer he talks about PKCS#7 and PKCS#1. These in turn rely on the DER-encoding rules of ASN.1 that specify exactly how to covert the big integer pieces of RSA into an unambigous sequence of bytes and back again.
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.