Yes, I should add the parameters used for difffieHellman. It is standard DH key exchange with a generator of 2 and the prime is prime from rfc3526: 2048-bit MODP Group (https://tools.ietf.org/html/rfc3526#section-3). SharedKeyPadPositiveByteArray, adds an intial 0 if the bytes are 2s complement negative. This matches the byteArray produced by Java's diffieHellman.
I will try to give my opinion why this protocol is superior. It is a minimal protocol to establish an encrypted connection. I view it as a positive that it does not use Certificates, you just need public and private keys for each agent. While being minimal, the protocol still allows negotiation of the cipher used and the encoder used. I use this protocol as the session layer beneath my distributed capabilities layer, called Raven. I have implemented SSL and SSH before. You can find them in the Cryptography repository for Squeak/Pharo, although they are broken at this time. I am considering porting these onto the ThunkStack design of ParrotTalk. For myself, that is the real advantage of the ParrotTalk protocol is its implementation in Squeak/Pharo and its Java implementation. I would suggest that you load the code and explore the design. After many iterations I came up with the ThunkStack, managing the connection. The other aspect which is a strong advantage is that all the headers used in the message flow are defined as ASN1 structures, so this represents a solid standard for messaging to bring about the minimal protocol. With my Java code, one can see the ASN1 encoder and the ParrotTalk impl can be easily ported to new languages, thus my one issue with ParrotTalk is to implement in C, C++, C#, Objective-C, Rust, Dart, etcetera. Port ASN1 then port ParrotTalk. Currently, ParrotTalk in Squeak/Pharo and Java are bit-compatible and interoperable.
{ 8-byte frame spec | ASN1 Header | [payload] }
A data frame over the wire looks like this with frame embedding:
{8-byte spec | MAC (20-byte mac) | [ spec | Encrypted (ivSequence) | [ spec | Encoded | [ spec | RawData | [ RavenMessage ] ] ] ] }
Regarding the comm stack, during Rendezvous, prior to an encrypted connection settling, here is what the stack looks like with the send buffering thunk and the SessionOperations managing the state machine and the SecurityOps for rendezvous negotiation
1: RavenTerminal
2: Session
3: SendFramesBuffer
4: SessionOperations (SecurityOps)
5: ReceivingFrameBuffer
6: SocketThunk
And when rendezvous completes the fully encrypted stack looks like this:
1: RavenTerminal
2: Session
3: EncoderThunk (for de/serialization)
4: CustomsThunk (for MAC validation)
5: CipherThunk (for encryption)
6:; ImmigrationThunk (for MAC access)
7: SessionOperations (SecurityOps cleared)
8: ReceivingFrameBuffer
9: SocketThunk
1: RavenTerminal
2: Session
3: SendFramesBuffer
4: SessionOperations (SecurityOps)
5: ReceivingFrameBuffer
6: SocketThunk
And when rendezvous completes the fully encrypted stack looks like this:
1: RavenTerminal
2: Session
3: EncoderThunk (for de/serialization)
4: CustomsThunk (for MAC validation)
5: CipherThunk (for encryption)
6:; ImmigrationThunk (for MAC access)
7: SessionOperations (SecurityOps cleared)
8: ReceivingFrameBuffer
9: SocketThunk
When I find the time and motivation, I may work SSL and SSH into the ThunkStack design as both implementations in the Cryptography repository are BROKEN. In porting SSL (TLS 1.2) I may extend to the new TLS 1.3, which has a quick three msg negotiation.
I primarily documented both versions of the ParrotTalk protocol in two slideshows in the specified PDFs from my earlier msg and documented in the readme.MD.
I hope I answered your questions to your satisfaction.
Best,
I primarily documented both versions of the ParrotTalk protocol in two slideshows in the specified PDFs from my earlier msg and documented in the readme.MD.
I hope I answered your questions to your satisfaction.
Best,
Robert
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Tuesday, November 20, 2018 2:31 PM, Eric Rescorla <ekr@xxxxxxxx> wrote:
Robert,I took a quick look at this document. To be honest, it's a bit hard to make sense of. There's quite a bit of code and code-like stuff, abd not very much text. So, for instance, looking at page 18, I see "sharedKey := diffieHellman sharedKeyPadPositiveByteArray", but I don't see definitions for either diffieHellman or sharedKeyPadPositiveByteArray, so I don't know how to do this computation. If you would like people to provide opinions on this document, you will probably need to flesh it out more..With that said, a preliminary question: can you expand on the ways in which you believe this protocol to be superior to other Authenticated Key Agreement protocols that we have already standardized in IETF, such as IKE, SSH, or TLS?-EkrOn Tue, Nov 20, 2018 at 8:37 AM Robert <robert.withers=40protonmail.com@xxxxxxxxxxxxxx> wrote:I am unsure why Facebook is considered a violation of what a sensible person would reach to, as it is not any sort of phishing scam. I also have a github project (https://github.com/CallistoHouseLtd/ParrotTalk) and the README.MD should prove descriptive. To satisfy your curiousity regarding what ParrotTalk is here is a description.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 these documents.The two protocol documents v3.6 and v3.7 are hosted on github:andHere is the IETF draft I wrote up for version 3.6, though not yet updated for version 3.7. The slides should suffice:https://github.com/CallistoHouseLtd/ParrotTalk/blob/master/docs/draft-withers-parrot-talk-v36-00.pdfKindly,Robert‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐On Tuesday, November 20, 2018 8:44 AM, Ted Lemon <mellon@xxxxxxxxx> wrote:It would help to give enough information about what ParrotTalk is so that we know whether it's worth visiting the link.. However, that's moot, since it's a facebook link, and no sensible person is going to visit it.On Tue, Nov 20, 2018 at 1:09 AM Robert <robert.withers=40protonmail.com@xxxxxxxxxxxxxx> wrote:Please read my Facebook post introducing the features of the new version 3.7 protocol of ParrotTalk, now a 5 message handshake, 3 messages like TLS 1.3 and an initial 2 message negotiation to determin which version of the protocol to use. My release of the Squeak/Pharo implementation which is capable of supporting both v3.6 and v3.7 in the same SessionAgent, spawning Sessions with either version, based on the negotiation. The Java version at https://github.com/CallistoHouseLtd/ParrotTalk can only talk v3.6 right now. The interesting feature of the Squeak/Pharo implementation is that it supports version negotiation for either version. Tests are all green.best regards,Robert
