[squeak-dev] [Pharo-dev] [ANNOUNCE] ParrotTalk release/design change considerations

henry henry at callistohouse.club
Sun Oct 29 05:55:59 UTC 2017


Yes well it is an extension to what you found as I combined with eventual references such that it computes in a single thread.

- HH

On Sat, Oct 28, 2017 at 23:59, Ben Coman <[btc at openinworld.com]("mailto:btc at openinworld.com")> wrote:

> On Thu, Oct 26, 2017 at 12:00 AM, henry <[henry at callistohouse.club]("mailto:henry at callistohouse.club")> wrote:
>
>> I disabled vatId authorization in version 3, located in SessionOperations>> processIWant | SessionOperations>>processIAm: .
>>
>> I was asked to disseminate my news to Pharo Users, hello there. I was asked to describe ParrotTalk well, provide use cases and adopters of its use. Alright, I will give an attempt.
>>
>> ParrotTalk is an encrypted connection framework. Currently allowing anonymous 2048-bit key negotiation to establish user-provided encryption cipher and user-provided encoding and decoding, both through a provided SessionAgentMap to a starting SessionAgent server. Please look in the test case ThunkHelloWorldTest for building these maps and running a connection iwth data passing after encryption is established. There is a 4-way negotiation, from ProtocolOffered/Accepted to Go/GoToo. In using RSA 2048 signature validation and DH 2048 primes to establish the key used within the selected Cipher. The Cipher and Encoder are selected by name through the negotiation protocol. Currently three Ciphers are selectable, AESede, DESede, and DES. There are two encoders tested, asn1der, and Bytes. This protocol is described here, in this document.
>>
>> [https://github.com/ZiroZimbarra/callistohouse/blob/master/docs/ParrotTalkFrameDesign-3.5.pdf]("https://github.com/ZiroZimbarra/callistohouse/blob/master/docs/ParrotTalkFrameDesign-3.5.pdf")
>>
>> For as to use cases, this encrypted connection has no third party, man-in-the-middle situation by not using Certificates. As such, this is a tight implementation of NSA-proof encryption without explicit authorization beyond knowledge of a host:port. The use cases involve any communication desired to be encrypted with such high encryption. The support will last my lifetime, so we have a settled solution, here in the third version, provided here. It requires version 111 of Cryptography, as a prerequisite. Both run on Squeak and Pharo.
>>
>> [http://www.squeaksource.com/Cryptography/Cryptography-zzz.111.mcz]("http://www.squeaksource.com/Cryptography/Cryptography-zzz.111.mcz")
>> [http://www.squeaksource.com/Cryptography/ParrotTalk-HenryHouse.3.mcz]("http://www.squeaksource.com/Cryptography/ParrotTalk-HenryHouse.3.mcz")
>>
>> The current use is with my hubbub system, a promise-based distributed object implementation. I am working to bring ParrotTalk to Java and allow hubbub to operate interdependently between Squeak, Pharo, Java and any other languages which can support ParrotTalk and STON. My latest efforts with hubbub are to bring STON as the Layer 6 encoding. Hubbub depends on eLinda.
>
> Took me a while to track down what eLinda was.  I presume its an implementation of Linda "a model of coordination and communication among several parallel processes operating upon objects stored in and retrieved from shared, virtual, associative memory"
> [https://en.wikipedia.org/wiki/Linda_(coordination_language)]("https://en.wikipedia.org/wiki/Linda_(coordination_language)")
> [http://www.cs.yale.edu/publications/techreports/tr984.pdf]("http://www.cs.yale.edu/publications/techreports/tr984.pdf")
>
> cheers -ben
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20171029/a1a78154/attachment.html>


More information about the Squeak-dev mailing list