The logic behind ParrotTalk

Hits: 133

Problem Space

Per the recent C4ISR Conference ( the problem is how to link thousands of connections in a military communications network, that needs reliable, simple encryption? [1][2][3][4][5] Foremost in mind is the requirement that this be integrated and operational in Combined Arms, Joint and Coalition contexts. When the concept of identity is baked into the protocol, we loose an ability to evolve solutions. So part of the problem is adaptability and a design that supports experimentation. We need a layered solution that can be modified in Cyber time-frames.

To meet these needs a standard & extensible framework for encrypted communications is absolutely necessary. I would introduce ParrotTalk as an inviting solution.

ParrotTalk as a solution

ParrotTalk is a minimal protocol for establishing a secured link between two computers. It allows for user-defined cipher and encoder. It exchanges Diffie-Hellman parameters with 2048-bit primes/generator to determine the shared key. It uses 2048-bit RSA Public/Private keys only for the purpose of signing the message traffic for Authentication, avoiding issues with RSA Certificate encryption which has been shown to be vulnerable. There are no Certificates, so there is no Certificate Management. It meets the minimal, capable requirements to establish an encrypted connection. Small in scope, wide in applicability.

We deferred the issue of identity verification to a software management layer above the secure connections. This provides a pathway to evolution and experimentation in identity management. The result of this decision implies various things about the encryption layer. It should be the simplest, most-minimal protocol negotiation that can be achieved. It should have the flexibility to specify cipher and encoding.

It must have the ability to encrypt end-to-end, between users (automated or actual). This implies the requirement to have double encryption: a capability to encrypt between computers and also encrypt a layer above over a route of links of computer connections. So we can manage routing, as well as deal with NATs and firewalls protecting internal networks. That would require a naming service and a coordinated bridging service, to bridge links. So we need a doubly layered encryption mechanism. With naming we need an identity solution.

However, the capability to negotiate a second higher layer encryption is missing in ParrotTalk, though the pieces to do so are there. As ParrotTalk was designed carefully to offer building blocks of a componentized, composable, reconfigurable manufacturing design nature, such a second layer of encryption can be realized with this framework. The existence of a naming service and a bridging service are absent. The identity is not present.

View 3 message specification for ParrotTalk-v3.7 Protocol.
Browse the Java code for ParrotTalk.
Browse the Squeak/Pharo code for ParrotTalk.

Given the shortcomings, more development is needed to meet all the objectives in the Problem Space. However, what exists is a simply designed, highly adjustable protocol that could fill the need to have an encryption standard across countries, branches and units. It is flexible enough to sustain evolutionary requirements. It may be able to support TLS-v1.2 and SSH. With such a capability it is an obvious framework for doing automated encrypted traffic analysis.

[1] If the Army doesn’t get the network right, is everything else a wasted effort?

[2] The Army wants a singular focus, not one-off solutions

[3] Can the Army innovate on a traditional budget?

[4] The Navy and the need for interoperability in the fleet

[5] Army cannot rely on the cloud at the end of the spectrum

One thought on “The logic behind ParrotTalk”

  1. Appreciating the commitment you put into your site and detailed information you present. It’s good to come across a blog every once in a while that isn’t the same outdated rehashed information. Excellent read! I’ve saved your site and I’m adding your RSS feeds to my Google account.

Leave a Reply

Your email address will not be published. Required fields are marked *