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.
Related
This is the article published by Microsoft for encrypting/decrypting data using RSA:
https://learn.microsoft.com/en-us/dotnet/standard/security/walkthrough-creating-a-cryptographic-application
As a relatively new person into the cryptography world and having read a comment on stackoverflow saying that cryptography should use a hybrid model, I researched that and it seems that hybrid models use AES and RSA for encryption and I was wondering if the example provided by Microsoft fits into the hybrid model since it uses both and if is constructed well enough and not just for novice devs just venturing into the world of cryptography.
I already have a working example where an app would encode and another would decode by loading the private key file, similar to the example.
I found an article here:
https://www.codeproject.com/Tips/834977/Using-RSA-and-AES-for-File-Encryption
He creates signatures and manifests and I'm wondering if this is what I'm looking for is Microsoft's example generally just enough, or weak?
PS: I removed the key container code and persistence as I don't want to persist or store my keys on the local machine, instead they are exported as standalone files to be stored in a DB maybe, so I'm not looking for opinions on that part at the moment.
and not just for novice devs just venturing into the world of cryptography
Well, at least it tries to define some kind of protocol, although very sparse. It also uses CBC mode (implicitly, never a good idea) and RSA with PKCS#1 v1.5 padding for encryption. Most people would opt for OAEP if RSA is used and use an authenticated cipher such as GCM.
I already have a working example where an app would encode and another would decode by loading the private key file, similar to the example.
Bad idea, the example is for file encryption, not for transport mode security, for which you need a secure transport protocol. Both the RSA implementation and CBC implementation are malleable, and are both susceptible to padding oracle attacks as well.
I don't want to persist or store my keys on the local machine
You need to establish trust, something that is missing from the example. And to establish trust you do need to persist your keys, especially if they have been randomly generated.
In the end, asking if something is secure depends on context: you need to know what your goals are and then check if the protocol provides enough protection to achieve these goals.
This is also my problem with these generic examples or wrapper classes; they make no sense to me, as the generic security that they seem to provide may not fit your use case; I'd rather design a protocol specific to the use case.
Recently, I was pointed to a post from 2011 by a friend, which described Google's move towards forward secrecy. From what I understand, the essence of forward secrecy seems to lie in the fact that the private keys are not kept in persistant storage.
I have various doubts about how something like this could be implemented.
What if the server goes down without warning - do the key pairs have to be regenerated? Does the public key have to be signed again to create another certificate?
Could someone point me to posts/pdfs where the implementation of something like this is described. Suggested reading resources?
Are you aware of anyone else that has implemented forward secrecy? Have you tried something similar at your workplace?
Thanks!
In Forward Secrecy, there are still long-term keys. The only implication is, that the compromisation of a long-term key will not allow an attacker to compromise temporary session keys, when the long-term key has changed. This means that a long-term key must not be derived from another (older) key.
Here is a good survey on this topic.
According to Wikipedia:
PFS is an optional feature in IPsec (RFC 2412).
SSH.
Off-the-Record Messaging, a cryptography protocol and library for many instant messaging clients, provides perfect forward secrecy as well as deniable encryption.
In theory, Transport Layer Security can choose appropriate ciphers since SSLv3, but in everyday practice many implementations refuse to offer PFS or only provide it with very low encryption grade.
In TLS and many other protocols forward secrecy is provided through the Diffie-Hellman (DH) algorithm. Vanilla DH is rather simple and provides perfect forward secrecy if the exponents are randomly generated each time, but provides no authentication. Therefore in TLS it is using in combination with a signature algorithm, usually RSA.
TLS provides many ciphersuites that support PFS and many that do not. Most TLS clients support PFS but many servers do not, because it is thought that PFS takes too much CPU.
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.
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