Research Kerckhoffs’ Principal, and read the segment in the text titled “Never Trust Proprietary Algorithms”. I think we can all agree that having open protocols is considered critical in cryptography. But what about other areas of IT? Should we also demand open protocols in other areas of IT? How might the use of proprietary versus open protocols affect IT security in other areas?
Reader Interactions
Comments
Leave a Reply
You must be logged in to post a comment.
Andres Galarza says
When Kerckhoff says that, “It should not require secrecy, and it should not be a problem if it falls into enemy hands” in his second principle, I take it as a strong indictment of “security through obscurity” brought by proprietary security products.
I think Kerckhoff’s Principle is already present in other areas of IT through items like open source software and (not quite proprietary-free) Raspberry Pi hardware. Also, last week’s readings also support his principle through many of the UNIX-based operating system (OS) software, and the security advantages those OS can bring.
JR says
I agree with your statement that Kerckhoff’s 2nd principle is a strong indictment of “security through obscurity” however, I think there could be exceptions to this for proprietary software that use the latest, patched, well-tested, open source software under the hood. Such software will have well tested processes whose implementation isn’t widely known as an out of the box system like Ubuntu would be.
I think Kerckhoff’s makes the assumption that the enemy will eventually discover how your defenses are setup. It doesn’t necessarily mean that you should reveal your blueprints and floor plans to the enemy.
JR says
Open standards can be challenged, broken down, patched and fixed by numerous people who rigorously test these standards. This allows the creation and development of products that are known to outlast issues that the standards are supposed to protect against or resolve.
We should open up other processes and systems in IT to open review/testing because this allows organizations to find potential issues that could be ironed out which would not be ironed out if the testing and reviews are done by fewer people.
However, I think there should be a balance between how open the review should be. It takes man hours ($$) to view process and code. There will probably be better outcomes by having a 2 SQL developers look at SQL code for issues than having 100 admin personnel or the average person in an enterprise review the code.
There is always a cost-benefit analysis that should be done to make sure that the review and testing are done by the right people.
A product doesn’t become better merely from going through more reviews, who reviews and tests the product probably matters more…
Ioannis S. Haviaras says
Kerckhoffs’ Principal states that cryptography should be secure even if the everything about the system (besides the key) is public knowledge. This is essentially the principle behind asymmetric keys and how they work. I believe that open protocols in other areas of IT are essential in maintaining security. Open source software allows other people to look at the same code making it available to others in the field, this gives the opportunity for others to give input and make improvements. Proprietary protocols we could use include internal organizational programs that require no one else view code. I believe however that open source software has both benefits and downfalls.
Mengxue Ni says
Nowadays, Kerckhoffs’s principle is applied in virtually all contemporary encryption algorithms (DES, AES, etc.). These algorithms are considered to be secure and completely investigated. Keeping algorithms secret may act as a significant barrier to cryptanalysis, but only if such algorithms are used in a strictly limited circle, which protects the algorithm from being revealed.
Proprietary vs Open Protocols
Pros of proprietary
• Usability
• Product stability
• Ownership
• Tailored support
Pros of open protocols
• Free to try before you buy
• Free support
• Open standards
• Fewer bugs and faster fixes
• Better security
• Avoids vendor lock-in
Both proprietary and open protocols are each based on differing philosophies, methodologies and business models. Many enterprises are successful with either approach based on their needs.
links: http://www.optimusinfo.com/downloads/white-paper/open-source-vs-proprietary-software-pros-and-cons.pdf
http://www.crypto-it.net/eng/theory/kerckhoffs.html
Darin Bartholomew says
I agree with the above explanations of Kerckhoffs’ Principal. I see no harm in the theory of an application and its functions being explained and public, but I think the specific nuts and bolts like code itself should be proprietary. I’m not in favor of giving the bad guys any more information than they need to have. I agree with the above point that internal applications should be proprietary. I do see the benefits of open source. The ability to have that level of input can be beneficial but I think it could be giving away too much information.
Amanda M Rossetti says
When I was reading about Kerckhoffs’ Principal and doing the reading for the week I had similar thoughts to you, Darian. I think that the more the ‘bad guys’ know about the code you use for your applications, the higher the risk of them finding a flaw to exploit. While Kerckhoffs’ Principal works in theory, I think that the human factor needs to be thought of. Not every developer is going to practice secure coding principals all the time and not every QA team is going to catch every hole in the code of an application. With these human error caused holes, having the code be open to the public is just asking for trouble.
Ruslan Yakush says
When the Kerckhoff’s Principle states that a cryptosystem should be secure even if everything about the system, except the key, is public knowledge, I think all is needed is to really keep the key secretly private without sharing it with public. For example, PKI concept and principles of operation are known by public, but cryptography key is known only to individual who has the private key. Given the algorithm complexity, it is almost impossible to break the algorithm unless an attacker posses the private key of end user.
Open protocols are critical to be known by public if it is used worldwide by majority of information systems for communications and data exchange. If everyone is using the same protocol when designing software or devices, then all systems will work properly since everyone follows standard development process. Also, professionals in internet community can analyze protocols and provide contribution to further influence better protocol design or fix vulnerabilities. As long as crypto keys are secured, encryption is not broken.
With proprietary algorithm, when companies develop custom software, OS or system with their own proprietary encryption algorithm, they may state that their protocol is secured because no one knows how algorithm works and therefore no one can break it. Actually, someone will always break the algorithm concept, because there is always weakness in the algorithm. In the example of Apple’s OS, the algorithm is proprietary and Apple did not allow FBI to know how to break it; however, a third party company in Israel broke the algorithm mechanism and decrypted the data. So, “never trust proprietary algorithms” is true statement and these type of companies should be ignored unless there is a big reason of accepting it. Proprietary algorithm create incompatibility and a huge obstacle when trying to integrate with other systems.
Good crypto algorithm should be designed so that even if algorithm concept is known, but the encryption is still secured. The strength of algorithm is in the secrecy of the key and never based on secrecy of the algorithm itself.
Loi Van Tran says
Ruslan,
Thanks for your post and examples. It really helped me understand Kerckhoff’s second principle: cryptosystem should be secure even if everything about the system, except the key, is public knowledge. If I understood correctly, then the importance in any cryptosystem is the “private” key and not the algorithms or protocols required for communication. In a sense, knowledge of proprietary or public algorithms does not necessarily cause any harm. Only when the private key is compromised is where there is a point of concern.
Jon Whitehurst says
Research Kerckhoffs’ Principal, and read the segment in the text titled “Never Trust Proprietary Algorithms”. I think we can all agree that having open protocols is considered critical in cryptography.
But what about other areas of IT?
There are some areas of IT that are at the mercy of the vendor for areas such as manufacturing or in research. There are some systems that come with their own proprietary OS, hardware, network protocols and they their own sense of security for devices such as PLCs, Allen Bradley and Rockwell Automation devices or networks. Usually these systems are on a closed network from the rest of the company network. The need is specific for the operation of that product and their need for openness to protocols or security is limited.
Should we also demand open protocols in other areas of IT?
In some cases you can demand the use for open protocols and the use of standard cryptography when the system will be used on the corporate network. It can be part of a RFP(Request for Proposal) if you are using vendors to provide information about using their system, software or product. It depends on what you are buying and the difficulty if the vendor is using a closed cryptography and what would be needed to re-program the system to use a standard cryptography.
How might the use of proprietary versus open protocols affect IT security in other areas?
If the system is considered proprietary, it would be best to segment from the rest of the corporate network. Cost to the system. If segmented it cannot use an automated process for access such as LDAP or radius and the process has to be manual using pen and paper or having a card key access only allowing physical access. There would be more manual effort to keeping the closed network secure and auditing would become a higher priority than if it was using standard security protocols.
Mushima K. Ngalande says
Kerckhoffs’ principle simply sated was a cryptosystem should be secure even if everything about the system, except the key, is public knowledge.
I think we can all agree that having open protocols is considered critical in cryptography. But what about other areas of IT?
They are some areas of IT where it required that the vendor restricts access to only licensed users most likely at a fee. The product may be just used in a corporate environment and not open to the public so may not be so prone to attack. In instances where it’s compromised the vendor is willing to work on a newer versions
Should we also demand open protocols in other areas of IT?
It is ideal to demand open protocols in other areas of IT because as Kerckhoffs says design your system assuming that your opponents know it in detail. Open protocols allows for cooperation and collective empowerment. If anything vendors with proprietary algorithm can be made to release their source code for a license fee which can make that more available to those using their product.
How might the use of proprietary versus open protocols affect IT security in other areas?
The issue with Propriety algorithms is that they are restricted to the Vendor and not shared so the argument is how you can know how secure your cryto is. Vendors will keep the algorithm secret as that guarantees the security but Kerckhoff argues If the security of your cryto algorithm is compromised by the transparency of its inner workings then it shouldn’t be used. He said neither “publish everything” nor “keep everything secret”; rather, he said that the system should still be secure even if the enemy has a copy. The argument is the strength of the crypto is based on the secrecy of the key and not the algorithm.
To this end the use of proprietary algorithms may affect IT Security in that it may not be proven to be secure and when made public will just be prone to attack and if and when creaked open it could be very costly to the owners. Such as in the case when DVDs first came to market with a proprietary encryption which was cracked very early in the game and cost the DVD player manufactures millions.So basically as Kerckhoffs points out – secrecy is not the best form of security so design your system assuming that your opponents know it in detail.
Anthony Clayton Fecondo says
Kerckhoffs’ Principal states that “a cryptographic system should be secure even if everything about the system, except the key, is public knowledge (1).” According to Cole, “the only true test of an algorithm is time. The best algorithms are those that have been published for the entire world to see and have stood the test of time (2).” Both Kerckhoffs and Cole believe that for an encryption algorithm to be secure, it has to be publicly available. By having experts consistently trying to crack the algorithm, any obvious weaknesses will be identified and addressed. Eventually, the algorithm will gain a reputation for being secure and can then be trusted.
Personally, I gravitate towards open-source software. I think that having the code available opens it up to critique, input, and improvement through the community. In theory, all security related applications/programs should be open source because ultimately, open source software has a higher potential for security. According to Vincent Rijmen, a developer of the winning AES encryption algorithm, open source is more secure “not only because more people can look at it, but, more importantly, because the model forces people to write more clear code, and to adhere to standards (3).” I think that as long as there is consistent input from the community and the community remains critical of the code, the open source options will always be more secure than proprietary.
1. http://www.crypto-it.net/eng/theory/kerckhoffs.html
2. Network Security Bible
3. http://www.dwheeler.com/secure-programs/Secure-Programs-HOWTO/open-source-security.html
Mengqi He says
Kerckhoffs’ Principal states that a cryptosystem should be secure even if everything about the system, except the key is public knowledge. This is called “security through transparency” that security is achieved through open source cryptography algorithms. A successful algorithm should be unable to be broken even it has been published or known by the enemy. With a misunderstanding that proprietary is more secure than open source algorithms, there are still many companies using proprietary cryptography algorithms to achieve data security through keeping the algorithms secret or private, which is also called “security through obscurity.” However, the proprietary algorithms are not actually secure as people thought. It is risky because once the algorithms are stolen, published or copied, they can be easily broken. Therefore, we can conclude that open source algorithms are more secure because they are public, but can hardly be broken as long as the key is secured. If an algorithm is published and analyzed for many years, it gains a reputation as being secure and thus being accepted by the community. The security of an open source algorithm is usually approved by the public.
Open source protocols are based on open source cryptography algorithms. Once designed, they are reviewed and re-reviewed by IT professionals for a long time to ensure that they can provide certain protection or be able to immune to common attacks. Even after they are published and used, their security is monitored all the time. Therefore, open source protocols are approved secure. Open source protocols also have high compatibility in various network environments, encourage innovations and have more available supports in the community. A disadvantage is that there is a greater likelihood of finding zero-day exploits because they are public. Proprietary protocols are based on proprietary cryptography algorithms. As we discussed above, proprietary protocols are less secure and less compatible to various network environment. An advantage is that it can be tailored to fulfill customer’s specific requirements. My suggestion is to use open source protocols as much as possible, but if you have to use a proprietary protocol, a thoroughly
assessment for security vulnerabilities must be conducted before design.
This topic also reminded me of the topic we discussed in week two that which do you think is more secure, Linux or Windows. Linux is also an open source OS, while Windows is a proprietary OS. Most of us think Linux is more secure due to many reasons, such as account privileges, many distros, diversity of computing environments, lower compatibility, competent community, and etc.
BIlaal Williams says
Kerckhoffs second axiom, which states a cryptosystem should be secure even if it falls into enemy’s hands, remains relevant today in modern cryptography and alludes to the fact that an effective cryptosystem should be secure even if everything about the system, except the private key, is public knowledge. This axiom provides the basis for public key infrastructure (PKI) in which an individual’s public key is known to all, and is used by correspondents to encrypt messages that can only be decrypted with this individual’s private key. A generalization some make from Kerckhoffs’ principle is: ‘The fewer and simpler the secrets that one must keep to ensure system security, the easier it is to maintain system security.’ This holds true with PKI because the only aspect of the system that must remain secret is the private key. The algorithms involved with producing the keys are known to the public, but still should not compromise the secrecy of the private key. By having open protocols in cryptography, a system can be tested to ensure its effectiveness. Once a system has been tried and tested by the IT community, it can be used with considerable confidence that it is an effective mechanism. Proprietary versions of cryptographic protocols remain suspect because they are not allowed to be tried and tested by the public before they are put into operation. This negates the axiom of Kerckoffs principle because too many secrets are required to ensure the system remains secure. This can cause a weak algorithm to be put into use to secure important data.
Open protocols have proved helpful in other areas of IT such as operating systems and software. Linux, an open source operating system, is known to be one of the most secure OSs. Since its code is available to all, developers are allowed to test and secure any vulnerabilities, and immediately make these results available to the public. Closed source systems such as Windows rely on in-house developers to patch and update system vulnerabilities, which may cause considerable lag in updates since there are obviously less people involved with the process
Vaibhav Shukla says
Kerckchoffs law states that a cryptographic system should be secure even if everything about the system, except the key, is public knowledge.In simple words the gold standard for any secret keeping system is that all its details should be able to be made public without compromising the security of the system. The security relies on the system itself, not the secrecy of the system.
Imagine if you bought a lock that stated that it must be hidden from view so that no one knew what type of lock you had installed. That wouldn’t provide much reassurance that the lock was any good. The security of the lock should depend on its mechanism and you keeping the key safe not on you keeping the lock a secret!
Example-Breaking of the Nazi German Enigma cipher during the Second World War. By stealing machines, receiving information from other secret services, and reading the manuals, the Allies knew everything there was to know about how the Enigma machine worked.
The security of HTTPS, SSL and ciphers like AES or RSA rely on the complexity of the algorithm, not on keeping them secret. In fact, they are all published, detailed standards. The only secret is the key that’s chosen when you connect to a secure web site
https://blog.cloudflare.com/a-note-about-kerckhoffs-principle/
Shain R. Amzovski says
Kerkhoff’s Principle states that a cryptosystem should be secure even if everything about the system, except the key, is public knowledge. It is applied in modern day encryption such as DES, AES, etc. The principle is formed on the basis of open security and security by design. “After a message has been subjected to a cryptographic algorithm, it is supposed to remain secure even if an intruder has or gains full access to the encrypted message and has knowledge of what algorithm was used.” The point of this is that even if an unauthorized user gains access to a system, it should still remain secure.
The Open Source Protocol is a way of telling developers where to access the source code for your website. This is necessary so that developers can develop for your product. For instance, Blackboard uses several third-party LTIs and Building Blocks. Developers for these third-party partners must have access to the open source protocol to develop for the product. In other areas of IT, open-source software has been helpful, and is also very secure. The reason open-source software can be more secure, such as Linux because more users can test the software and find vulnerabilities. Just because something is open source, does not mean necessarily that security isn’t as good as a software that is paid for.
Source: http://whatis.techtarget.com/definition/Kerckhoffs-principle
JR says
Open standards can be challenged, broken down, patched and fixed by numerous people who rigorously test these standards. This allows the creation and development of products that are known to outlast issues that the standards are supposed to protect against or resolve.
We should open up other processes and systems in IT to open review/testing because this allows organizations to find potential issues that could be ironed out which would not be ironed out if the testing and reviews are done by fewer people.
However, I think there should be a balance between how open the review should be. It takes man hours ($$) to view process and code. There will probably be better outcomes by having a 2 SQL developers look at SQL code for issues than having 100 admin personnel or the average person in an enterprise review the code.
There is always a cost-benefit analysis that should be done to make sure that the review and testing are done by the right people.
A product doesn’t become better merely from going through more reviews, who reviews and tests the product probably matters more…