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

Ben Coman btc at openinworld.com
Fri Nov 3 00:04:00 EDT 2017


On Fri, Nov 3, 2017 at 4:06 AM, henry <henry at callistohouse.club> wrote:

> I have a question about my derivation of a MAC key. It is very complicated
> and I am considering ways to simplify for use by potential language
> implementations. Here is the current derivation in Squeak/Pharo. Should I
> just use the sharedKey as the SHA1HMAC key or some simplified hash of the
> sharedKey, without all the pad hashings I am doing? What do you think? I
> want to hear from you.
>

Hi Henry,

I'd guess not many people here are *really* competent enough in crypto to
confidently advise you.  I know I'm not.  I only know enough to know crypto
is *hard*.
* https://www.happybearsoftware.com/you-are-dangerously-bad-
at-cryptography.html
* https://www.schneier.com/blog/archives/2011/04/schneiers_law.html
* https://www.schneier.com/essays/archives/1997/01/why_cryptography_is.html

I hope that doesn't discourage you, and I'm interested to hear a more
useful reply from anyone else.
cheers -ben


P.S. I just bumped into what looks like an interesting intellectual
exercise...
http://cryptopals.com/


>
> makeHMAC
>
>             | sharedKey hashPadder macKey |
>            sharedKey := diffieHellman sharedKeyPadPositiveByteArray.
>            hashPadder := self class.
>            macKey := MD5 hashMessage: (
>                       (hashPadder hash: sharedKey pad: 16rCC),
>                       (hashPadder hash: sharedKey pad: 16rBB),
>                       (hashPadder hash: sharedKey pad: 16rAA),
>                       (hashPadder hash: sharedKey pad: 16r99)).
>            macKey := macKey, (MD5 hashMessage: (
>                       (hashPadder hash: sharedKey pad: 16r88),
>                       (hashPadder hash: sharedKey pad: 16r77),
>                       (hashPadder hash: sharedKey pad: 16r66),
>                       (hashPadder hash: sharedKey pad: 16r55))).
>            macKey := macKey, (MD5 hashMessage: (
>                       (hashPadder hash: sharedKey pad: 16r44),
>                       (hashPadder hash: sharedKey pad: 16r33),
>                       (hashPadder hash: sharedKey pad: 16r22),
>                       (hashPadder hash: sharedKey pad: 16r11))).
>            ^  SHA1 new hmac key: macKey.
>
> Would a better way forwards is simply this?
>
> makeHMAC
>
>            macKey := diffieHellman sharedKeyPadPositiveByteArray.
>            ^  SHA1 new hmac key: macKey.
>
>
> Thank you.
>
> - HH
>
>
> -------- Original Message --------
> Subject: Re: [Pharo-users] [Pharo-dev] [ANNOUNCE] ParrotTalk
> release/design change considerations
> Local Time: November 2, 2017 3:50 PM
> UTC Time: November 2, 2017 7:50 PM
> From: henry at callistohouse.club
> To: henry <henry at callistohouse.club>
> Squeak-dev <squeak-dev at lists.squeakfoundation.org>, Pharo-users list <
> pharo-users at lists.pharo.org>, Pharo Development List <
> pharo-dev at lists.pharo.org>
>
> I have developed the ParrotTalk Protocol, documented in part here[1],
> while I have two implementations: 1 in Squeak/Pharo [2 a/b] and the other
> in Java [3 a/b]. Particulars of some decisions are absent from the
> specification: namely the MAC key and ivSequence derivations, as well as
> constrained traffic signing; they are in the implementations. I will update
> the 3.6 slideshow to specify these items.
>
> Thank you.
>
> - HH
>
> [1] - ParrotTalk Protocol : http://jmp.sh/OqlYpyg
>
> Squeak/Pharo implementation
> [2 a] - http://www.squeaksource.com/Cryptography/Cryptography-Henr
> yHouse.113.mcz
> [2 b] - http://www.squeaksource.com/Cryptography/ParrotTalk-HenryH
> ouse.9.mcz
>
> Java implementation
> [3 a] - https://github.com/ZiroZimbarra/ASN1
> [3 b] - https://github.com/ZiroZimbarra/ParrotTalk
>
> - HH
>
>
> -------- Original Message --------
> Subject: Re: [Pharo-users] [Pharo-dev] [ANNOUNCE] ParrotTalk
> release/design change considerations
> Local Time: November 2, 2017 3:43 PM
> UTC Time: November 2, 2017 7:43 PM
> From: henry at callistohouse.club
> To: Squeak-dev <squeak-dev at lists.squeakfoundation.org>
> Pharo-users list <pharo-users at lists.pharo.org>, Pharo Development List <
> pharo-dev at lists.pharo.org>
>
> More celebration requested. I got encrypted data passing between
> Squeak/Pharo and Java: AES with CBC and IVs and SHA1 HMAC. It works!
> NSA-proof crypto rocking Squeak, Pharo & Java!
>
> *Celebrates again, drinks for everyone*
>
>
> - HH
>
>
> -------- Original Message --------
> Subject: Re: [Pharo-users] [Pharo-dev] [ANNOUNCE] ParrotTalk
> release/design change considerations
> Local Time: October 31, 2017 1:54 PM
> UTC Time: October 31, 2017 5:54 PM
> From: henry at callistohouse.club
> To: henry <henry at callistohouse.club>
> Ben Coman <btc at openinworld.com>, Squeak-dev <squeak-dev at lists.squeakfounda
> tion.org>, Pharo-users list <pharo-users at lists.pharo.org>, Pharo
> Development List <pharo-dev at lists.pharo.org>
>
> I wanted to share my good news, though I have not yet gotten Pharo, Squeak
> and Java talking. What I was able to accomplish, after finishing the port
> of Cryptography's ASN1Types, Module and Streams is to get Java's rendezvous
> and key exchange working. After I got that connecting, I looked at the
> ciphers, ivSequences and MAC and got that working. In Java, I am now able
> to encrypt and decrypt "hello world".
>
> *Celebrates*
>
> - HH
>
>
> -------- Original Message --------
> Subject: Re: [Pharo-users] [Pharo-dev] [ANNOUNCE] ParrotTalk
> release/design change considerations
> Local Time: October 25, 2017 12:00 PM
> UTC Time: October 25, 2017 4:00 PM
> From: henry at callistohouse.club
> To: Ben Coman <btc at openinworld.com>, Squeak-dev <
> squeak-dev at lists.squeakfoundation.org>, Pharo-users list <
> pharo-users at lists.pharo.org>
> Pharo Development List <pharo-dev at lists.pharo.org>
>
> 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
>
> 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/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.
>
> http://www.squeaksource.com/Cryptography/elinda-HenryHouse.14.mcz
> http://www.squeaksource.com/Oceanside/hubbub-HenryHouse.38.mcz
>
> Hubbub currently fails to load correctly in Pharo. In Squeak the two
> ParrotRemoteTestCases: LookupTestCase and OperationalTestCase really screw
> everything up, do not save an image after running. I never run these tests
> until I get a better handle of serialization. Currently, do to a shift in
> progress to STON, the serialization tests fail, just the way we like it.
> Fix the tests then the system starts to work right.
>
> The shift away from vatId authorization should not adversely affect
> hubbub, we hope! When STON starts to work, and I think I need to turn off
> jsonMode, then traffic between vats can start to be analyzed and figure out
> how resolving is working with redirectors invoked remotely.
>
> - HH
>
>
> -------- Original Message --------
> Subject: Re: [Pharo-dev] [ANNOUNCE] ParrotTalk release/design change
> considerations
> Local Time: October 25, 2017 12:43 AM
> UTC Time: October 25, 2017 4:43 AM
> From: btc at openinworld.com
> To: henry <henry at callistohouse.club>, Pharo Development List <
> pharo-dev at lists.pharo.org>
> Stephane Ducasse <stepharo.self at gmail.com>
>
>
> If I google... parrottalk protocol
> nothing seems related.  So what is ParrotTalk?
>
> P.S... since this is not "part of" pharo, [pharo-users] would be a better
> place for discussion than [pharo-dev].
> Could you re-announce there, with some description of use cases and
> who/where the protocol is used?
>
> cheers -ben
>
> On Wed, Oct 25, 2017 at 1:42 AM, henry <henry at callistohouse.club> wrote:
>
>> Please excuse all the low-level detail, if inappropriate to the
>> discussion. The protocol changes are here specified.
>>
>>
>> - HH
>>
>>
>> On Tue, Oct 24, 2017 at 13:40, henry <henry at callistohouse.club> wrote:
>>
>> In order to bring ParrotTalk-3.6 support, alongside historical 3.5
>> support, the frame header stays the same and the processing of the
>> ProtocolOffered would select "ParrotTalk-3.6" to use the compact protocol
>> of
>>
>> - ProtocolOffered { offered, preferred }
>> - ProtocolAccepted { accepted }
>> - IWant|GiveInfo|ReplyInfo { vatId, domain, publicKey, cryptoProtocols,
>> dataEncoders }
>> - IAm|ReplyInfo { vatId, domain, publicKey, cryptoProtocol, dataEncoder,
>> dhParam }
>> - Go { cryptoProtocol, dataEncoder, dhParam, signature }
>> - GoToo { signature }
>>
>>
>> Using eLinda :
>>
>> http://www.squeaksource.com/Cryptography/elinda-HenryHouse.14.mcz
>>
>> Above the FrameBuffer, below the SessionOperations for each version of
>> the protocol, an ELindaSession could be inserted. This session think would
>> have the stacks for each protocol version SessionOperation registered by
>> protocol in a Tuple, for eventual callback. When the ProtocolOffered comes
>> in we publish the tuple frame, with set selected version, to route to the
>> correct SessionOperation to support each version of the protocol.
>>
>> With a non-specific vatId required, anonymous connections would be
>> supported.
>>
>> - HH
>>
>>
>> On Tue, Oct 24, 2017 at 12:52, Stephane Ducasse <stepharo.self at gmail.com>
>> wrote:
>>
>> Hi henry thanks for this announce. Can you tell where such protocols are
>> used? Stef On Tue, Oct 24, 2017 at 6:33 PM, henry wrote: > Hi all, > > I
>> am happy to announce the release of version 3.5 of ParrotTalk, for Squeak >
>> and Pharo, found here: > > http://www.squeaksource.com/Cr
>> yptography/ParrotTalk-zzz.2.mcz > > It follows this specification: >
>> https://github.com/ZiroZimbarra/callistohouse/blob/master/do
>> cs/ParrotTalkFrameDesign-3.5.pdf > > One item of note, in version 3.5,
>> the system connecting to a server, sending > the IWant msg, must know the
>> vatId of the system being connected to. I am > considering changing this to
>> version 3.6 by removing one round-trip in > messaging. Therefore, these
>> messages would be combined: IWant/GiveInfo, > IAm/ReplyInfo. I will keep
>> ProtocolOffered and ProtocolAccepted to allow > eLindaSession to support
>> both versions: 3.5 and 3.6. > > Thoughts please? > > - HH
>>
>>
>
>
>
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/attachments/20171103/6f12f1f8/attachment-0002.html>


More information about the Pharo-dev mailing list