[squeak-dev] [Pharo-users] [Pharo-dev] [ANNOUNCE] ParrotTalk release/design change considerationsBen Coman btc at openinworld.comFri Nov 3 04:04:00 UTC 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.squeakfoundation.org/pipermail/squeak-dev/attachments/20171103/6f12f1f8/attachment.html>
More information about the Squeak-dev mailing list |