Bouncy castle java - Triple DES cryptography is symemtric or asymmetric?
I am using bouncy castle Java API for implementing tripleDES, but I do not know if it is symmetric or asymmetric key cryptography.
Can somebody help me to answer this question.
Triple DES is an symmetric block cipher, a rather old one. I would stick to stronger algorithms (e.g. AES) if I had the choice.
Related
Any ideas/suggestions on how to implement the OpenPGP standard to use the HSM to handle cryptographic operations. PKCS11 is the standard to communicate with the HSM, and it is very primitive comparing to the OpenPGP standard.
I am using the Pkcs11Interop library to integrate with the HSM, and BouncyCastle to implement the OpenPGP standard. Does anyone have any experience integrate them together, or have some code examples?
For example, generating keys in an OpenPGP format correspond to some calls to the PKCS11 APIs and the steps may need to take a certain order. Is there any client library that may abstract all that and call a GenerateOpenpgpKeyPair which the HSM can understand (Ideal solution)? Otherwise, I would like to not have to rigorously go through the RFC4880 implementing every last detail and making sure that specific bytes are in the right positions. So ideally I'm looking for a OpenPGP formatting library where I can supply it with an AES key (encrypted with the recipient public key), as well as the AES encrypted signed message, and then the library would make sure that it fits the OpenPGP format.
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.
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.
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.