I'm taking cryptography course on cousera.
When I'm reading the lecture slides, it says
Encryption algorithm is publicly known
• Never use a proprietary cipher
What does "Never use a proprietary cipher" mean?
Thanks
Never use a proprietary cipher
It means - Never use a proprietary cipher!
The idea behind is - until a cipher is adopted as a standard, the cipher goes through mathematical elaboration, proofs, validation, ... and then a lot of smart people say it's ok to use the cipher to some extends or expected lifetime.
Almost all current battle-proven ciphers went this way (AES, RC4, DES, 3DES, ...). We know (or we think we know) their real strength and their weaknesses.
When creating a proprietary cipher - everybody could create a cipher which himself won't be able to break. However - are you able to validate, if the cipher is resistant to modern cryptoanalytical methods or side-channel attacks?
Using a cipher which is "proprietary", where the algorithm is not know, most probably the cipher can be broken and the cipher is not to be considered as secure. Stick to the industrial standards.
Proprietary ciphers go through much less rigorous testing than public ciphers do
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.
I am wondering if there are any functionalities that are explicitly provided in openssl but not in crypto++, or vice versa.
I am trying to write a unified interface to both the libraries so that I can switch between using an underlying crypto library without modifying my calling source code. At this point, I want to figure out if there is anything substantial that can only be done in one of those libraries. I know that the basic hashing, encryption and signing functionalities are provided in both.
Any comments or points of wisdom will be appreciated. Thanks.
I am wondering if there are any functionalities that are explicitly provided in openssl but not in crypto++, or vice versa.
Yes, there are lots of differences between them.
OpenSSL is more similar to Peter Gutmann's Cryptlib and GNU's GnuTLS. Perhaps even Jack Lloyd's Botan. I don't think OpenSSL and Crypto++ is a good comparison.
Crypto++ provides more low level cryptographic primitives. Crypto++ provides nothing related to TLS and DTLS. Crypto++ is like a low level cryptographic Swiss army knife.
OpenSSL provides some low level cryptographic primitives, support for hardware modules, and working TLS and DTLS implementations. Because it supports hardware, it provides a PKCS 11 interface. Because it supports TLS and DTLS, it has richer socket support and an X509 parser.
There are many other similarities and differences. If you want to know a specific similarity or difference, then you need to ask about a specific feature.
You might also want to look at the OpenSSL wiki's Related Links page. It lists other, similar libraries.
Some of the BouncyCastle methods take a Digest as input. According to http://en.wikipedia.org/wiki/Cryptographic_hash_function#Hash_functions_based_on_block_ciphers and http://www.mindrot.org/projects/jBCrypt/ it should be possible to use a block cipher as a hash function.
So does that mean that it should be possible to use any of the JCE ciphers (such as Blowfish) as a Digest?
You cannot use a block cipher as a hash function; you can, if you are a cryptographer, design a hash function out of a block cipher, which means that the block cipher will be an important element within the hash function -- important, but not alone. You need more.
(Analogy: a car can be powered by an engine -- and often is. However, there is more to a car than an engine, and there are a lot of ways to build a car around an engine. Many such ways are bad, too, and won't result in a safe, efficient or beautiful car.)
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.
The Skein hash proposed for SHA-3 boasts some impressive speed results, which I suspect would be applicable for the Threefish block cipher at its heart - but, if Skein is approved for SHA-3, would this imply that Threefish is considered secure as well? That is, would any vulnerability in Threefish imply a vulnerability in SHA-3? (and thus, a lack of known issues and a general trust in SHA-3 imply the same for Threefish)
Nope. The security of Skein does not imply the security of Threefish. Putting it positively, if someone finds a weakness in Threefish then this does not imply that Skein is also insecure.
The question however, is quite intersting an applies to other hash functions too.
Skein uses a Davis-Meyer construction with some modification. MD5, SHA1 and many other hash functions are also using this Davis-Meyer construction and hence they are in principle based on a block cipher. Just in case of MD5 or SHA1 that block cipher does not have a name and I'm not aware of much research on how suitable these constructs are.
The requirements for a good block cipher and for a good hash function are different. Somewhat simplified, if E is a block cipher and it is not feasible to find two keys K, K' and two messages M, M' such that EK(M) xor M = EK'(M') xor M' then E is suitable for constructing a hash function using Davis-Meyer. But to be secure as a block cipher E would need other properties. E would have to resist chosen-ciphertext attacks, chosen-plaintext attacks etc.
Furthermore, if E is a good block cipher then that does also not mean it gives a good hash function. Microsoft had to learn this the hard way with the hash they used in the XBOX. This hash was based on the block cipher TEA that had a weakness that was insignificant for a block cipher, but proved fatal when used for a hash function.
To be fair, there are some relations between being a good block cipher and being suitable for a hash function. E.g., in both cases differential attacks need to be avoided. Hence some design methods used for construction good block ciphers can be used to construct good hash functions.
Let me also add that some of the proposals for SHA-3 are based on AES. So far, I haven't seen much support for favoring AES based hash functions, just because AES is already a standard. These hash functions are analyzed just like any other SHA-3 proposal.
Disregard my previous answer. I misunderstood the relationship between Skein and Threefish. I still don't think Skein being approved absolutely proves Threefish is generally secure (it's possible Threefish is only secure when used in a particular manner), but it would be an indication.