#tlsnotary-chat

waxwing: https://en.wikipedia.org/wiki/Three-pass_protocol I presume you have read this before?

proslogion: not that page no. though the idea i've seen in many places.

waxwing: it occurs to me that, in a typical DH protocol, when you send a g^a mod p to the other party, an eavesdropper cannot distinguish if g is some base specified in a general protocol, or it's a secret message m, so Alice can hide a message m in the form of m^a mod p, and send it to the server Bob, but Bob wouldn't know if it's a general DH pubkey as well, so he just does (m^a)^b mod p and send it back regardless

no there is a caveat

waxwing: so basically, TLStweet wouldn't work too well, if the pubkey is ephemeral

proslogion: i'm a bit lost about the details of that, but clearly there'd be some long lived pubkey that has to be known out of band.

i'll have to go back and look at my first stab at writing some code and figure out what i was doing ..

waxwing: right, this part may make the whole communication not so stealth....

proslogion: you think? but first, what scenario are you considering

alice communicates with server, or alice communicates with another client?

alice communicates with server

ok

so yeah the first issue is how the server knows it's a communication.

right

it's that old thing in cryptanalysis: how do you know you've succeeded in cracking. the usual answer is an hmac

or other hash

well forget 'cracking', i mean successful decryption. hmac the message.

hmmm

so if tlstweet is mac-then-encrypt then the matt greens of this world will put a price on my head :)

waxwing: right, but that doesn't change the fact that some keys have to be distributed first, and the distribution itself is suspicious

oh i c

proslogion: at least, server's key has to be out there. i'm guessing you're still interested in applications where the server is helping the client jump over certain kinds of wall?

alice could encrypt something using the server's pubkey, in the client random field

the server doesn't need her pubkey

hmmm that's good

proslogion: possibly, but that's why i asked about the application you're interested in

waxwing: yes, we are on the same page, i just didn't realize the server doesn't need client's pubkey

proslogion: well, but only if the idea is just instructions and not 2-way conversation

i originally had in mind 2 way conversation

i suppose client could send pubkey in message, is that it

i am thinking the same

yeah that works eh

can the server's TLS cert pubkey be used for this? there might be some technical difficulties there

i don't see why not

i was imagining 28 byte instead of 32 byte key

waxwing: does the client need to sign his DH pubkey in a DH keyexchange as specified in the TLS RFCs?

not in 5246 , i just looked

7.4.7.2

hmmm, i guess as long as the server signs it, it's fine, heh

yeah server signs

you can't use a shared key if one of the two halves gets replaced

ah, i just realize that the server sends first in a TLS DH session

silly me :)

the key exchange message i meant

OT but this is amazing. Textbook costs $92 :) https://www.reddit.com/r/math/comments/3k1qe6/t...

waxwing: what language do you plan to use for the server side development? i don't think python can really be used for developing http server modules and stuff?

proslogion: i don't plan anything :) i agree that, except for maybe some proof of concept, you wouldn't do this in python.

i'd imagine making some kind of patch to nginx or apache or whatever

client side is different ... i guess you could do anything, maybe javascript, or whatever you want

yes

otoh people have written TLS stack in JS ;)

i did mull over the possibilities a bit .. i think it might be quite feasible to leave the server untouched and have a little module that you route the traffic through, on the server machine

"leave the server untouched" = leave the server software untouched.

you know, like pipe it through a port on localhost

well, yeah, but to state the obvious, performance issues, maybe using in memory hash-tables and moon stuff like that

no, not really

AES decryption would almost have no impact on performance, otoh RSA....

waxwing: re the textbook, hardly surprising, consider how many in American high school really need to study at this level...

yes it's arguably just as bad to throw a 'fact' in there when students aren't equipped to understand it, as to get the fact horribly wrong.

but i guess what enrages people so much about it is the fact that this is one of the very few bits of 'advanced' mathematics that *anyone* can understand. to botch up such a beautiful piece of mathematics is a crime.

oh, so surjection is called "onto correspondence" in high-school speak, okay

yeah 'one to one' and 'onto' are commonly used

not particularly ground breaking i think.