Re: [9fans] RUDP and/or others
On 18 October 2015 at 23:43, Aleksandar Kuktin wrote: > BAM! I run straight into RUDP. "Designed at Bell Labs for the Plan 9 > operating system". I just skimmed through the (expired) IETF draft from > 1999 and I honestly think the design might be too much. It looks like > it's almost completely like TCP, but without segmenting and possibly > The Cisco RUDP defined in the IETF draft is not the rudp in the Plan 9 code. Both use a UDP shell to carry their packets, but the two RUDP headers are different. The protocols seem to be unrelated. The Cisco one is derived from an earlier BBN one, and all three had the tcp-like SYN/ACK/RST flags. Plan 9's does not.
Re: [9fans] RUDP and/or others
Do I understand correctly, you just want to avoid having to implement the complexities of TCP on an fpga? If there was a TCP IP core would you buy it? Why does VNC require an fpga, are you going to transfer enormous resolutions? If yes then I personally would use UDP and a lossy and loss tolerant compression. If not I would use TCP and no FPGA.
Re: [9fans] RUDP and/or others
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 >On Mon, 19 Oct 2015 10:14:46 +0100 >Charles Forsyth wrote: > > On 18 October 2015 at 23:43, Aleksandar Kuktin > wrote: > > > BAM! I run straight into RUDP. "Designed at Bell Labs for the Plan 9 > > operating system". I just skimmed through the (expired) IETF draft > > from 1999 and I honestly think the design might be too much. It > > looks like it's almost completely like TCP, but without segmenting > > and possibly > > > > The Cisco RUDP defined in the IETF draft is not the rudp in the Plan > 9 code. Both use a UDP shell to carry their packets, but the two RUDP > headers are different. There are two RUDPs? O.o > The protocols seem to be unrelated. The Cisco one is derived from an > earlier BBN one, > and all three had the tcp-like SYN/ACK/RST flags. Plan 9's does not. That's a good thing. The less flags and states, the better. - -- Svi moji e-mailovi su kriptografski potpisani. Proverite ih. All of my e-mails are cryptographically signed. Verify them. - -- You don't need an AI for a robot uprising. Humans will do just fine. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.15 (GNU/Linux) iQIcBAEBAgAGBQJWJUSRAAoJEKa4cgqNx31/aDYP/0AS8wyBKxnlkbwdWi8VT4+Z /BbTfQa+nN5HcDPn1xI+2roFri+R8I/wqHMsSHHgTAbUMP7bar4L52aFY0yUXJiW apmzyVzLHHBKXlmV15GAWoMWKTDstrmqArN0/xOMHys2ldyYn/chxlEBVjbKWSQD nm96LLcKz5xDnTP0ebGg5v7P2YhIOMVCcwSyPfRDG04fY6T6HqkwfvFhnTiYhs/G vghQJHYurF5SpcCE8KiCJgd3jnoNP+Rsm8WHdF6JCWU6jDeC16Gi3WOpIzEcFUGk bP9HC7rB2CND8wmU1XZB1dvkLSP2OLxeR4CVZVItMoRB3HYJ0VarDxc8V4Vpst11 WVkFeSLci6VqGhAccQQCKW9kPmfo73UGZ0OXKfS+Nc4ZvDLGZ804UM9koTb5bP+C KKTKBbYcqeKucfRAHZJ/TjsNju7zuEw1FZt/dxmjdIqrGcP3ryAFeBMfsd7ZlKZu mHWj7oP3ipJZJS0gvtRRHBQSvRsrQ3LwAwtlKBqpXCeFyqhkh/H5TM1ji+emJ2SN buJiCn7+1IUsy26C4lToYA9RDd52zpSaOGBDGZ+j4ol0fkfap6uM2ncUBhjfhZWs dSITGTpWkblpcxAphMw2SdgDqcAW3p348wcdqlgaMGI2O9PDR9LL5rsBbR3Xl6RJ XKZVPi/IAEA1eURGPGVq =dNnW -END PGP SIGNATURE-
[9fans] dp9ik draft
requesting comments and questions.
later versions of this draft may be found under:
http://felloff.net/usr/cinap_lenrel/newticket.txt
Abstract:
The goal of this crypto scheme is to replace DES in the Plan 9 authentication
and to augment the authentication server with an authenticated key exchange
to prevent offline dictionary attacks on the user's secret key. We propose a
new protocol named dp9ik (Diffie-Hellman Plan 9 Intermediate Key) as an
alternative to p9sk1 that uses the new authsrv capabilities and can be
negotiated in p9any.
Problem:
The user's secret key is derived from a low entropy password that is prone
to dictionary attacks. With the old authserver protocol, it is easy for an
attacker to just try to decrypt tickets with a dictionary of DES keys.
The dictionary can be precomputed once and will then work forever for
all users as the key is only dependent on the password.
Tickets contain known plaintext that makes it easy to check if decryption
with a guessed key was successfull. Also due to the small 56-bit DES key size
it is possible to bruteforce the key with modest computing resources.
To address the small key size of DES, we replace the DES cipher with 128-bit
AES,
introducing a bigger 128-bit key called the aeskey that is derived using an
expensive pbkdf2 key derivation function. Ticket encryption is changed to use
128-bit AES-CBC with hmac_sha2_256 for message authentication.
We add an authenticated elliptic curve Diffie-Hellman key exchange (AuthPAK)
at the beginning of a authsrv session to generate randomized intermediate
keys (pakkey) that are used to encrypt/decrypt the tickets instead of using
the user's secret keys directly. The public keys are derived in a way that
to complete the exchange requires the knowledge of the user's secret leaving
the attacker with only one password guess per ticket request making offline
bruteforce impossible.
aeskey[16]:
The 128-bit aeskey is derived from the password using pbkdf2_hmac_sha1
[rfc2898],
with the salt string "Plan 9 key derivation" (not including terminating null)
and iteration count 9001.
In addition to deriving the pakhash (see below), the aeskey is also used
for encrypting the keyfs user database on the authentication server, tho
details on this is beyond the scope of this document.
The aeskey is be stored along with the old DES key in nvram and keyfs.
pakhash[32]:
The 256-bit pakhash is used as the basepoint G on curve25519 for the
elliptic curve Diffie-Hellman exchange. It is derived from the aeskey
and the user name (id) so that each user gets a unique pakhash
even when different users share the same password.
Curve25519 scalars and compressed curve points are represented as
32 byte arrays in little endian order.
info = "Plan 9 AuthPAK hash";
salt = sha2_256(user);
x = hkdf_hmac_sha2_256(salt, info, aeskey);
x[31] = 0x40 | (x[31] & 0x7f); // set bits 254-255 to 01 to prevent timing
attacks
pakhash = curve25519(x, 9);
This calculation only needs to be done once and is reused in all
authentication sessions of the same user. The pakhash can be stored instead
of the aeskey or precomputed by keyfs to avoid some computational costs on
the authentication server.
pakkey[32]:
With the pakhash, two parties generate a new curve25519 Diffie Hellman
shared secret Z in the following way:
mkkey(){
// generate 32 random bytes
x = random()
// curve25519 secret keys are defined as:
// n ∈ { 2²⁵⁴ + 8{0,1,2,3,...,2²⁵¹-1} }
// - Use a fixed position for the leading 1 in the secret key.
// (timing attacks)
// - Multiply the secret key by a small power of 2 to account for
// cofactors in the curve group and the twist group.
// (small subgroup attacks)
x[0] &= ~7;
x[31] = 0x40 | (x[31] & 0x7f);
return x
}
G = pakhash (base point)
xa = mkkey()(secret key)
Ya = curve25519(xa, G) (public key)
G = pakhash (base point)
xb = mkkey()(secret key)
Yb = curve25519(xb, G) (public key)
Exchange the public keys Ya and Yb, then both sides calculate:
Z (shared secret)
= curve25519(xb, Ya)
= curve25519(xa, Yb)
= curve25519(xb, curve25519(xa, G))
= curve25519(xa, curve25519(xb, G))
The shared secret Z is then hashed to get the final pakkey:
info = "Plan 9 AuthPAK key"
salt = sha2_256(Ya | Yb)
pakkey = hkdf_hmac_sha2_256(salt, info, Z)
Note that we use a hash of the concatenation of the public keys Ya|Yb
as the salt to the key derivation function so that any manipulation on
the public keys in the message exchange causes a pakkey mismatch.
Client and server both establish new pakkeys with the authentication
server before each ticket request.
Dp9ik and authsrv protocol:
Dp9ik is is mostly the same as p9sk1, but at the beginning there is
the new AuthPAK (type 19) message sent to the authentication server
to exchange c
Re: [9fans] RUDP and/or others
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 >On Sun, 18 Oct 2015 16:15:13 -0700 >Skip Tavakkolian <9...@9netics.com> wrote: > > > Anyone know of a leaner reliable datagram protocol? I know I saw > > one a year ago, but I just can't remember what it was! > > are you looking for Internet Link (IL)? I seem to remember IL being more complex than just a UDP with counters and ACK, which is what I'm - sort of - looking for. But I'll look into it, it's worth it. - -- Svi moji e-mailovi su kriptografski potpisani. Proverite ih. All of my e-mails are cryptographically signed. Verify them. - -- You don't need an AI for a robot uprising. Humans will do just fine. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.15 (GNU/Linux) iQIcBAEBAgAGBQJWJUUfAAoJEKa4cgqNx31/KbcP/jg32am9Vai1MyJkLjZ5LERP pSbVPP/fcuJwRTKHN8pCUV/wpheQPD6vz6gQnmjnFwaKFeyofs0qefzPedfTRAtr 5T8SnTyevv4udvaDfUBD7fI+m/ayWM9wpCI7mKhdzb1WyYNvrkoOHr57p2AzrvCs UkCwObHSCni0FpEBUOWc+SPRhQzmoB/5x1vTedMjIBODfiM2c0IV1I1sy3b2/nXh PLdQpR8m2ZhaVzBqKk3d26005mxuCQnC03FH3TX23YyJzoWjyBNy5wliic9KaRls mEyEB9PV3ukBrQAsUPoDgzgp++olL+fxvzK1BIrj/vTHSm1MczbcIsI+u/f159vs xlE2xs4Ng1Rgw/sK7SdnE2dT5pN3b/3KN56sHeUr8vZ46PHVg1EBg+m6sIeVUQKe eY5UuG/I8dM2YHfeq8n/J8T5hLpucVjR1m4xB3uaMv8/k41VRWWlVhYuHS83ul/6 x+okrAn1uy5T8Ceen3aiRr+oxRavdA7RoC+5jHMsFqvksWxTdL5RIBOcmsbquflr 30C3yhi3EAWAF/pwj+nWLBZ7FbJKVPnkMssUXhHyzxBSVA7dC0xRjp1Qi/aeiwN7 ejCIyQHnY+URK9GDmbRGWr152OUEp35AksKI10dgDSdVYS3OOwE2kVzCn6/lEm4G lc+vpzANBR9+HmtOCv/W =FeoK -END PGP SIGNATURE-
Re: [9fans] RUDP and/or others
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 >On Sun, 18 Oct 2015 16:59:44 -0700 >erik quanstrom wrote: > > On Sun Oct 18 16:16:59 PDT 2015, 9...@9netics.com wrote: > > > Anyone know of a leaner reliable datagram protocol? I know I saw > > > one a year ago, but I just can't remember what it was! > > > > are you looking for Internet Link (IL)? > > there's also rudp, which if i have gotten my second-hand stories > straight, was used on the pathstar backplane. > > - erik You mean the telecom stuff? http://www.freepatentsonline.com/7738449.html (no Google allowed) I only read the abstract and found "pathstar" mentioned in references. - From a Bell Labs Technical Journal, no less. :) - -- Svi moji e-mailovi su kriptografski potpisani. Proverite ih. All of my e-mails are cryptographically signed. Verify them. - -- You don't need an AI for a robot uprising. Humans will do just fine. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.15 (GNU/Linux) iQIcBAEBAgAGBQJWJUZXAAoJEKa4cgqNx31/J3gP/j6fWbuMrSRHHfxq7jwC1TUs yACeCFGSRZJn5uQcDqwMVzCfsl3lwUhy6yRuSnS04o6VBNo19Q30Oo7hN5zb3zoc QKPivFwHvJFalkB2I6AT2N4nzAyquXjR1WQd52m2Wjp63WoAcbQ/a3kf0LDpQZLW 12ksI/GKjTP6W25DTbiMA8PbgAL1CTJl2/i3E2pk/4sMXJMu+pZXwEZLGbz6B+Gi PbLebxpOktxWTKOMQaeMPVSpfJitleYVhQ4E4hpTZYaAvhwL8bXN1bbuHZEKxrZz cmG4CXl0qS3rSMKkQCE2pBvveaxIoRZJwH8H7O81cLfDg5yhhA/M84JO68Yy3YcE IAmjMD7A+6c1mqmfCBnlMSB1Kb+SKCogucE0OEKxRZQ/AqmJK1J4IysVSIk9jf47 VuYXvydJIFvRMtfdl8DJvGKHFyGg1A4IJTaRUmDtnfhrbZPsuO2+DH0udtiV3Nd2 KGnyB2rFZjWlORR52Ea3T8y6KULaouEQMCyB5HXn7sCYuRnsuvdNHtHalt5s/AR9 XnDyNksQO/+qwbt8baP3d3df/mLAdt/WF91rfLE11SnaP+dVWUx3Wzb/jKMSOg/o 9JbrGVypNWh68tCrY6X9iopi5EG6y/kwiULk8KB6KwWsEFJrtFiM7yKJB0wXcA6H NkF7LyZdANZh43mbgFRo =r0HZ -END PGP SIGNATURE-
Re: [9fans] dp9ik draft
sorry, typoed the url: http://felloff.net/usr/cinap_lenrek/newticket.txt -- cinap
Re: [9fans] RUDP and/or others
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 >On Mon, 19 Oct 2015 11:28:13 +0200 >hiro <23h...@gmail.com> wrote: > > Do I understand correctly, you just want to avoid having to implement > the complexities of TCP on an fpga? If there was a TCP IP core would > you buy it? > Why does VNC require an fpga, are you going to transfer enormous > resolutions? If yes then I personally would use UDP and a lossy and > loss tolerant compression. > If not I would use TCP and no FPGA. The idea here is to implement a FOSH computer. Currently, I'm pilfering a lot of technology from Milkymist but I already had to write my own bits of hardware - so far only a memory controler. I wasn't happy with what Milkymist was using so I wrote my own. By the time I finish, I'll probably also implement the framebuffer with the video output. Gigabit ethernet is also somewhere in the pipeline and will probably get implemented, *if* I can get its analog bits to work properly. I already have a working 10BASE-T implementation (and some other things) so I'm not a newbie at this. However, because of the severe speed limits imposed by the implementation technology (FPGA), this computer will never be particularly fast. If you want to play pretty video games and watch pretty CGI videos, the obvious solution is to have a separate computer serve as the CPU server and renderer with the bitty box being a terminal. One option is to do the normal software based processing. But once you do the math, you realize that either you won't be sending a lot of data or your FPGA CPU won't be doing a lot of processing because of the interaction between system components contending to access the main memory. The main memory is implemented as DDR1 SDRAM. DRAM *really* doesn't like random memory accesses - the kind CPU will execute. You can optimize the memory controller to serve the CPU well, but then you are left in a bind when it comes time to implement the DMA because it has the exact opposite memory access profile. Not having the DMA is completely and absolutely out of the question, ofcourse. You can use, perhaps, wide memory buses and well optimized cache line sizes to perform DMA in short bursts, but each DMA-CPU switchover is expensive because (unless you get really lucky) you need to open and close memory pages. This sets an upper limit to the data transfer before the human usability of the system tanks. Streaming 1280x1024x24 video at 25 fps is, you guessed it, way beyond that limit. So the solution, I believe, is to perform DMA at the different point, specifically, between the network interface and the framebuffer/video card. This scheme completely bypasses the main memory, leaving the CPU to run at full capacity but has the drawback that now the framebuffer has to talk network. The obvious hack is to have the CPU initiate, handshake and configure the connection and then hand it over to the framebuffer for data transfer. The obvious problem is that the framebuffer STILL needs to talk network, albeit not whole protocols but only the grindy parts, leaving the more intricate bits to the CPU. Did I mention network analysis needs to be on-the-fly? Yeah, there ain't enough memory on the chip to store the whole network packet, and there aren't enough I/O pins on the device to store it off-device. So you just have to handle the packet literally as it is zooming past you. Receive the headers, analyze if the packet is for us or the CPU (and route it there if that's the case), read the application headers, set up the datapath, ram data into the video DRAM and maybe invalidate/rollback the whole operation if any of the myriad checksums indicate a transmission error. Yes, we're checksumming. :) I'm not saying it's possible, I'm only saying that I'll try and that I need a simple transport protocol to help me do it. :) I chose VNC because (a) it's actually a pretty neat protocol and (b) it's all over the place. You could use it to interface to a whole host of applications. VNC, on its side, requires a reliable transport. TCP is way too complicated for a few thousand gates of digital logic (I think) and UDP is not reliable enough. So, I went looking. - -- Svi moji e-mailovi su kriptografski potpisani. Proverite ih. All of my e-mails are cryptographically signed. Verify them. - -- You don't need an AI for a robot uprising. Humans will do just fine. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.15 (GNU/Linux) iQIcBAEBAgAGBQJWJVWaAAoJEKa4cgqNx31/YBwP/i5ZiM6kh04rn2IaVSxYSqwq tDMH0xf3dyMxOl8Wm6NltH48T+CXs7ukZ41DPuwcZFaLttRRtydOFgwtpmTy3aBm wkCCwNNjsttP6vABaKiGKcLVN+1yGgcBuN/9X6r3Yp7AXtHZKhnGHabmVFs/jYtN QlMbVtBtp8DrTx2u+t1TVbUTpywvW5JGXcwNIKpjFSz7fL+QA2uIO5tz7KLuyK/x COFW8rcglTAX7pvDpyRYUevk/eZw1uoiayh2TVV2KQuISIS3QrG+TmLsI9JxonnK A2KXUPKslhShJ+I539VdYNvgKiiVCFnxAyqGBDK+N0T96mFQZfOll/gZ34OotUKa iimY6JAfgM/zXyWpAt3cUTHvUHgX+4TzCpKVDkru364RmHQNRqxUlCILLcIjWkoc tTk8P1UN0fQxGoITLcnQHnT7+MUVzxpdtMud5kHSjXKGIddG6WMlN38W6uyXJjPK Lezfar5X7eTMUMvqsUHiNMLEfKto1B/Fl
Re: [9fans] RUDP and/or others
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 >On Mon, 19 Oct 2015 21:36:55 +0200 >Aleksandar Kuktin wrote: > http://www.freepatentsonline.com/7738449.html (no Google allowed) > > I only read the abstract and found "pathstar" mentioned in references. > - From a Bell Labs Technical Journal, no less. :) No, it mentioned pathstarT, with a 't' at the end. Or is that a typo? Apparently the same article is mentioned here: https://www.google.com/patents/US7170854 (okay, some Google allowed) I can't read it because Google thinks I'm a robot and won't perform the search for me. - -- Svi moji e-mailovi su kriptografski potpisani. Proverite ih. All of my e-mails are cryptographically signed. Verify them. - -- You don't need an AI for a robot uprising. Humans will do just fine. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.15 (GNU/Linux) iQIcBAEBAgAGBQJWJVgvAAoJEKa4cgqNx31/EgQP/RPmpgVfIRANnSy+WwoXyRIU WcdcO67m5QCT4lJYQ5ID3aoJ+ONH3JsvWpdOs0kPXifRJeWWkOJhKKS7iSOjR8I5 xiGjKlTmbu/LBj91ax/i+8vLDDqlVLXaoVEfC5WkEA6HBKwiodRRz9IM1iK7myw4 fa8T7E415b4zuAQQagiUIbb3fzTVTsnhRL5UUUz521uuwUeAgbH64iI7zRUjhKz3 Feeje6SWAmHNOec4ACFxxUTaIWyy422hRGlkQvDYRS902Q6ihehtgqFwqwmCHyOz F+vMsdF0Zty1AI0zkised3btSgG9Vk3whsiUD/9kARXg8RuXKUCitFlumOFoh6+W IFR+JeNT3/YD2lDh4ifJidpKMEfeO+cEr/gZeApfz01NyAKMWDAB9Zi3UztR3LHz r1aYoJ20hLAZVPdsRps1TZHqfC0d0aksVbQ/zD5kkS3F24hl0KcqlOLWFs8C75dP 7kM+ElItg8A3Ky1XPLkKQre9dZGp8lVnXc4IoBDJ6UfREVFps6sm5r87DeraFxwi rExZYV4g7ueXmenGj5/HNZwoL8YwU7UawES1dDAjJznVU49DfCRJ5sSrIX9+MfFi aXi6J75Q9ac5E5YX69M7dr+v1ToFwY2q1w4sIoudACf3y7F+Y14VSA3rb3uw8bru W2mJvhFkH7SH2lBu0G9H =1jXj -END PGP SIGNATURE-
Re: [9fans] RUDP and/or others
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 >On Mon, 19 Oct 2015 21:31:43 +0200 >Aleksandar Kuktin wrote: > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > >On Sun, 18 Oct 2015 16:15:13 -0700 > >Skip Tavakkolian <9...@9netics.com> wrote: > > > > > Anyone know of a leaner reliable datagram protocol? I know I saw > > > one a year ago, but I just can't remember what it was! > > > > are you looking for Internet Link (IL)? > > I seem to remember IL being more complex than just a UDP with counters > and ACK, which is what I'm - sort of - looking for. > > But I'll look into it, it's worth it. TFTP? - -- Svi moji e-mailovi su kriptografski potpisani. Proverite ih. All of my e-mails are cryptographically signed. Verify them. - -- You don't need an AI for a robot uprising. Humans will do just fine. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.15 (GNU/Linux) iQIcBAEBAgAGBQJWJVk8AAoJEKa4cgqNx31/lwkP/3GwL6uz/YYBLgxqVxe7XnXt GVr+/isjZQ3KzrQkb4KslLlpnLXfHjYG8a0PkOhyAEFjMpeNISzHM9tsJZsmE0jT e+qMY370QwvqKuSClxWgwUZNf3vyypM5kdv6aN/F54a6xZgPiJuICCzOxpFovyII N7T7MWz/VAntbbMrxOGvhdiI8vPU0EWiwxjcMGPpT0zVHf9UUpyjV2t117n6xNgA +8+c3zIzBq02MZ1rg1vFj7prIFw/bad4aH1HUnqC+VdiGC9lEEvCrQ1/A4h/JMtt m8rIiXYGxO8UoUGCNpV0ZvvcPiRwY3vXse8QB+cOwFdxovlWjt/L5C14cdh/ahom rE1JtdSM1y+etlZezNyol19qZA1QRfSMGhsC8dLvZWI+85LJE0KxPKwHbaVG7UWc GqNfe7rvZPwETIRviVLCTvMV1z1wLagWXOm1uJDi0kDP0pAiFSpo2BOY0I4eH0nS nU0gJTV/zYaMdqQ1CRYJgT926dhc6dlqbvDloNOYUepag1THdLSr2VWCVTmqaryl EymH+OleyGsTMoR292Ob89KxHlgV+A6d9CQdqYZmWDvF1WzpAiSiw9ZTtuzY8cgk eTu0u9R081w9FSUmrgYE6w7IcEBVAqKq6sIy4Sp73+Vqd/gxdhBj6xrzNY84lr0v Nln4hRz46bPajfJfRGwb =EJJN -END PGP SIGNATURE-
Re: [9fans] RUDP and/or others
On 19 October 2015 at 20:31, Aleksandar Kuktin wrote: > I seem to remember IL being more complex than just a UDP with counters > and ACK, which is what I'm - sort of - looking for. > I think you might find Plan 9's rudp is essentially that. Conversations are determined by a generation number; packets are labelled (gen, seq) for seq within a given generation gen; and acks are piggybacked as (agen, aseq) in every packet. The header is just uchar relseq[4]; /* id of this packet (or 0) */ uchar relsgen[4]; /* generation/time stamp */ uchar relack[4]; /* packet being acked (or 0) */ uchar relagen[4]; /* generation/time stamp */ I can't say much about how well it works, because it has been years since I last poked at it, and for my purposes I thought I needed something more elaborate (but I might have been wrong about that). In your case, allowing for implementation bugs, it sounds as though it might work for you, or at least be easily adaptable.
Re: [9fans] dp9ik draft
Robert Ransom pointed out offlist that the pak crypto is flawed in this draft so its back to the drawing board. please consider this version of the draft retracted :-) > If an attacker can find scalars s1 and s2 such that s1*H(p1) = > s2*H(p2), then he can send s1*H(p1) as his public key, receive the > other party's public key P and a message encrypted using the resulting > shared secret key, then compute both possible shared secrets s1*P and > s2*P and try each of them to decrypt the message. > > If H(p) = p*G, then s1*H(p1) = s1*p1*G = s1*(p1/p2)*p2*G = > s1*(p1/p2)*H(p2) (with the divisions and multiplications computed in > the ring of scalars). -- cinap
