China has started ranking citizens…just like Callisto House’s plans

Well now, if you have read my About page [1], you will see that my proposal is practically identical to China’s social scoring system they are testing. Here are my old business plans [2][3], I call their Social Score, building Esteem. Awesome! Those are my trick or treats, blessing or curse. We have fundamentally different ways of tricking or treating, anarchy is my solution the most spread network, every individual can give blessings and curses to each other!

Every individual has sovereignty over their conduct. Go Hong Kong!

[1] About –
[2] CallistoHouse Biz Plan –
[3] Homeless Council Biz Plan –

Thoughts of the great internet/DOJ war over the right to privacy during data-in-motion encryption

With the coming ability, in ParrotTalk, to detect initiation of encrypted connection negotiations, among many different protocols, along with the introduction of a redirect message, allows for implementation of a superb encrypted negotiation traffic analyzer. With connection control at the locally scoped naming services, the host domain of internal networks can be searched, managed & monitored.

a) No weakening encryption for the purposes of personal security.

We do not accept either the addition of back-doors or ghost protocols requiring group encryption negotiation, in order to eavesdrop in data-in-motion encryption, as it would result in the weakening of the encryption.

b) public security is limited to network traffffic analysis

We do allow that such a negotiation traffic analyzer, mentioned above, and monitoring of who is communicating with whom is of some value and acceptable state monitoring, by those authorized to monitor the local domain context.

It is the network authority‘s right to information to search & monitor this activity.

PAPAS – Redesigning ParrotTalk as an Automated Protocol Analyzer & Selector…

Through the AgentMap (config), a list of supported protocolNames are specified. In construction of the SessionProtocolSelector, a ProtocolSelectorRegistration with the SessionOperation’s subclass for that protocolName is installed into the Selector. A call and answer ProtocolState is installed into the Selector’s compiled stateMap, within the expectCall and expectAnswer states. As well, the protocol is installed as a selectable protocol through protocolOffered & protocolAccepted messages for explicit ParrotTalk protocol negotiation. The result is installation of the selected protocol sessionOperations into the subjectStack accomplished through either negotiation or the initial sending of initial call/answer message headers.

The last is possible due to ASN1 structure definitions which construct the appropriate header class from the DER encoding. So the appropriate header will be distinguishable between different protocol versions. As such, within the version history of ParrotTalk headers, due to the frame specification of ParrotTalk, each protocol can be determined & will setup the stack with that protocol’s sessionOperations, starting in the correct initial state to reprocess the frame that resulted in that protocol’s installation, so the rendezvous will proceed, for that version of the protocol.

Thought has been given to the other area of discrimination, which is the FrameBuffer. That includes an assumption about frame specification and is currently only supporting ParrotTalk frames. With full implementations of SSL (TLS v1.2) [1] and SSH [2], with its required Telnet [3] package, initially ported onto ParrotTalk’s [4] framework, in Squeak’s Cryptography project, a FrameAnalyzer may be able to be defined to automatically detect frame specifications for a given incoming frame and choose non-ParrotTalk frames and the associated SessionOperations.

From the package comment for ParrotTalk-rww.31 :::

I ported initial attempts to subclass an important stateMachine, from
each of SSL and SSH, to be rooted at ParrotTalk’s SessionOperations.
More work is needed, including defining active frameSpecifications that can detect appropriate frames for these new Protocols, in a new
FrameAnalyzer, to be used by the new SessionProtocolSelector. I
renamed the ParrotTalk SessionOperations. The current hierarchy of
SessionOperations as follows:

– ParrotTalkSessionOperations_v3_8
– ParrotTalkSessionOperations_v3_7
– ParrotTalkSessionOperations_v3_6
– SSLHandshakeStateMachine
– SSHTransportHandshakeStateMachine

and hence distinguish Protocol SessionOperations subclasses :::

  • ParrotTalkSessionOperations_v3_8
  • ParrotTalkSessionOperations_v3_7
  • ParrotTalkSessionOperations_v3_6
  • SSL_TLS_1_2
  • SSL_TLS_v1_3
  • SSH
  • Signal

That would be a powerful capability.

In thinking further about the current state of affairs, it would be a powerful addition to define a SignalSessionOperations and detect&read Signal [5] frames/messages.

For Squeak/Pharo…

[1] SSL –
[2] SSH –
[3] Telnet –
[4] ParrotTalk –
[5] libsignal-protocol-java –

Browse Oceanside or Cryptography, for latest developments.

The logic behind ParrotTalk

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