On Wed, Nov 21, 2018 at 3:35 AM Robert <robert.withers@xxxxx> wrote:
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.
OK. You should specify this. I would like to note two points here:
- I do not see nonces being mixed in. This is potentially safe if you guarantee fresh DH shares for each connection, but if both sides replay their DH shares (which I don't see you forbidding), then you have some very serious key reuse problems. For this reason, you would be better served to add some nonces. Perhaps I missed something.
- It's generally not a good idea to assume that the DH function provides contributive behavior. If you compare to (e.g., TLS 1.3), you will see that the current style is to mix in most of the protocol transcript.
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.
This is possible to do with TLS as well, using RFC 7250.
. 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.
I doubt that I or others are likely to do that. If you want people to review your protocol, it's usually necessary to produce a sufficiently clear document that they are able to understand the document without reference to the code. As I indicated in my previous message, in my opinion that is not the case for the document as-is.
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.
This form of interoperability is generally a property of all the protocols we design, regardless of the language used to specify the protocol.
As you observe, it is often helpful to specify the protocol messages (PDUs) for a protocol in a formal language, and depending on the relative complexity of the PDUs compared to the complexity of the language, this might or might not minimize implementation effort. For instance, TLS is specified in such a language [0] though IKE is not (it uses bit diagrams). Of course, it is also possible to retroactively design formal languages which allow you to express PDU formats which were previously expressed in bit diagrams and the like. So I'm not sure if I perceive this to be a sufficiently large advantage to justify designing an entirely new AKE.
-Ekr
[0] And in fact I believe that there is at least one TLS implementation which processes the formal language more or less directly.
A frame has this structure:
{ 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: SocketThunkWhen 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,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
