208 reputation
16
bio website
location Sweden
age 41
visits member for 1 year, 7 months
seen Aug 16 '13 at 16:54

Aug
16
comment Is it safe not to encrypt ping packets them?
Both would be in-protocol. The question is if one puts the ping at the packet dispatch/read layer, or if it should be done much higher up, on equal standing with normal (usually encrypted) messages.
Aug
16
comment Is it safe not to encrypt ping packets them?
I've clarified the usage. It's not a VPN connection but a custom protocol over a single connection.
Jun
23
comment Is there a known vetted alternative to this key-exchange protocol?
Actually I think you identified it. The first part of my protocol is very similar to TLS (with the client already holding the server cert, and the second part to Needham-Schroeder. But surely someone must have married those two before?
Jun
22
comment Recommended authenticated stream cipher for minimum overhead?
@D.W. I've tried my luck at asking for a protocol here: security.stackexchange.com/questions/37827/…. No protocol suggestion as of yet though.
Jun
22
comment Is there a known vetted alternative to this key-exchange protocol?
@CodesInChaos as for Kerberos, the similarity is in the encrypted session data M. Unlike Kerberos there is no central key store, instead I rely on an asymmetric key to securely request a "ticket". This in turn makes quite a different set of possible issues.
Jun
22
comment Is there a known vetted alternative to this key-exchange protocol?
@CodesInChaos I already tried a protocol with asymmetric key exchange. Granted, I used too large a key (which upped the cost by a magnitude), but even with that taken into a account I saw a large CPU impact so early that it's not an attractive solution. Also, with a separate login server, I can assure that resource-exhausting DoS/DDoS attack on the login won't affect games running on a different machine.
Jun
21
comment Is there a known vetted alternative to this key-exchange protocol?
@jcopenha A and B both do. Salts are constants and are only used to make sure keys for encryption and signing are different.
Jun
21
comment Is there a known vetted alternative to this key-exchange protocol?
@TildalWave the "previously suggested protocol" is exactly what I detail above. So basically this is asking if there's an alternative to my own hand-rolled protocol.
Jun
21
comment Is there a known vetted alternative to this key-exchange protocol?
@TildalWave basically the "session" M contains a nonce only known to the client and anyone who can decrypt M. Using this secret nonce together with public nonces from A and B, we can create new keys without having to retrieve a new session every time. Since public nonces from A and B are new for every connect, we can assure ourselves that our keys are different for each connect, even if the "session" used is the same.
Jun
21
comment Any obvious flaws in this protocol?
@Michael thanks, that paper was interesting.
Jun
20
comment Recommended authenticated stream cipher for minimum overhead?
@D.W. that might be a good suggestion. Where is the most appropriate? Here or at cryptography?
Jun
18
comment Any obvious flaws in this protocol?
@Rook the advantage I've had with AES-CBC + HMAC-SHA256 is the ready availability of these cryptographic primitives in well-used libraries, letting me not worry so much about the actual implementation of them and focusing on the higher level aspects of the protocol. In order to use CCM or GCM I feel I must thoroughly understand them first. I've started to ask a bit about perhaps switching to CTR or some variant thereof, for example here: security.stackexchange.com/questions/37490/…
Jun
18
comment Any obvious flaws in this protocol?
@Rook I'm uncertain of what you mean. PBKDF2 is used to create new sign / encryption keys for each connection (from NonceC || NonceLS || NonceGS || Csec where NonceC and NonceGS are unique for each connection) salting PBKDF2 with different salts for sign and encryption.
Jun
18
comment Any obvious flaws in this protocol?
@tylerl it's TCP all the way.
Jun
18
comment Any obvious flaws in this protocol?
@Rook inefficient in what sense? I was originally simply running AES CBC, which I believe should be ok against attacks as long as the HMAC check is correct. The puzzle is just find a value n such that SHA1(challenge nonce | n) has at least <difficulty> number of trailing zeroes. Integrity checks are everywhere except for the initial public key. I'll add it, but is there really room for an exploit here? Is it really helpful to alter the public key-signed request?
Jun
17
comment Any obvious flaws in this protocol?
@Ladadadada updated the question.
Jun
17
comment Recommended authenticated stream cipher for minimum overhead?
By the way, I posted the details of the protocol here: security.stackexchange.com/questions/37592/…
Jun
17
comment Recommended authenticated stream cipher for minimum overhead?
@D.W. I know I shouldn't take offense, but I didn't start working on this yesterday. If I use SSL, I will have to use the black box that is a SSL implementation. From a technical perspective, it's very hard to create a robust, scalable and predictable server engine from that. Then taking into account that I only need a subset of SSL - for example, all certificates will be known a priori - it's very hard to see that SSL is a good fit. Since I know how gnarly this is, I've presented various versions of the protocol here and elsewhere to get feedback.
Jun
16
comment Recommended authenticated stream cipher for minimum overhead?
@tylerl - Because I don't want the SSL hammer. And because I know exactly the trade offs I want in terms of security. And because I want fine grained control of my communications to ensure maximum scalability. And because I think cryptography is extraordinarily interesting. So really. You should not make assumptions.
Jun
14
comment Recommended authenticated stream cipher for minimum overhead?
I believe any HMAC with a decent hash function should evenly distribute across all bits, or it would be biased. That should mean that reducing the number of bits would simply change the difficulty for a brute force attack.