5
$\begingroup$

I recently completed a semester studying some basic amount of cryptography. So my knowledge is not very broad/deep.

What I currently see is that we have a bunch of fairly secure encryption modes to encrypt data and fairly secure authentication protocols to authenticate/identify subjects.

Now security protocols are a broad domain. Sticking to encrypting data and authenticating users, are there any use cases (ability to process encrypted data or special authentication case, if any) that the current set of well known protocols don't cover? Do industry researchers need to spend time coming up with their own protocols?

$\endgroup$

migrated from security.stackexchange.com Dec 27 '16 at 23:50

This question came from our site for information security professionals.

6
$\begingroup$

Disclaimer: This may not be the most accepted academic conclusion since I'm talking (mostly) from my personal experience.

One big area where well defined security protocols are missing is distributed systems resistant to segmentation. For example, most NoSQL databases (mongo, couch) are such systems.

PKI (or even general purpose public key cryptography) works well for distributed systems but it requires connectivity to some kind of master node or a pool of master nodes. Yet, if a group of nodes become alienated from the master nodes (whilst being able to communicate between themselves), these nodes cannot perform any work.

In other words, using the current PKI methods the is a single point of failure. Or, in the best case, a point of failure where a group of nodes is more important than other nodes.

The research in the field of distributed systems (in general) has some US patents. And it was heavily studied a decade ago. The results of those studies are the systems we see today with master nodes responsible for the cryptography (that must not become segmented) and several worker nodes.

The distributed systems that aim for segmentation resistance simply ignored network security. To become segmentation resistant mongoDB and couchDB (for example) do not even have a user or node identification. In practice, the security of these systems is implemented by a firewall around a subnet containing all nodes and some kind of encrypted tunnel between node farms (if the traffic needs to go through the internet for example).

(I believe that) A protocol to implement PKI (or even a different public key infrastructure) over such systems is a researcher's dream. I need to admit that I try to get my head around this problem when insomnia hits me, and I'm probably not the only one.

$\endgroup$
7
$\begingroup$

There are plenty of security issues which are not yet solved with widely used protocols:

  • At the low level there are reflection/amplification attacks. DNS (and in particular DNSSEC) is known to be vulnerable to this. DNS cookies have only recently been standardized, and is not yet widely deployed. Other protocols are lacking in this area as well.
  • Logins are still performed in ways that allow servers to see passwords in clear. Rather than fixing this at the protocol layer we have tried to educate users to use different passwords for all sites. It is still a possibility that improvements in this area may become popular.
  • Anonymity is not very well protected by current protocols. At the moment there are big players actively trying to undermine users' anonymity. New protocols might try to address this.
  • Confidentiality could be protected better with opportunistic encryption. Opportunistic encryption where identification of the peer being communicated with is optional can improve security compared to a setting in which communication is done unencrypted due to the complexities of key management.
$\endgroup$
  • $\begingroup$ I completely forgot the work on opportunistic encryption, very well said (+1) $\endgroup$ – grochmal Dec 25 '16 at 13:47

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.