<div dir="ltr">Greetings all!<br><br>For uplink, we have a cryptographic challenge incorporated, for authorization. The baseline is to let everyone talk through the transponder, but authorization policies can vary from nearly zero to very heavy.<br><br>Part of the process is a station generated token. We say “random” but randomness is a hard subject in and of itself.<br><br>So, let’s talk about pseudorandom.<br><br>To get a pseudorandom number, we can use a pseudorandom number generator (PRNG). With a PRNG, we will see an approximately 50% chance of collision after generating the square root of the range. Square root of 2^32 is 65,536. So, if you generated a 32-bit random number, that’s quite a few times before you get a collision.<br><br>The token and the claimed station ID are sent in the uplink.<br><br>The working discussion text file is here: <a href="https://github.com/phase4ground/documents/blob/master/Engineering/Requirements/Air_Interface/Supporting_Discussions/Phase_4_Authentication_Authorization.txt">https://github.com/phase4ground/documents/blob/master/Engineering/Requirements/Air_Interface/Supporting_Discussions/Phase_4_Authentication_Authorization.txt</a><br><br>1) Any objections to using a PRNG for this field?<br><br>2) What length makes sense for a communications resource with a baseline of ~100 users (everyone has 100 kHz uplink) and maximum of ~1000 (if we use low bit rate codecs and cram people in - not our baseline)? <br><br>There are a lot of things that could influence the size. Since the token is sent every frame, it needs to be as small as possible. Since we don't want collisions, it needs to be large enough. If it was a predictable number, generated from station ID for example, or some sort of hash, then another station could guess it and there are some abuse and malfunction scenarios we would like to avoid. <br><br>The implementation of this approach will be in the uplink voice and data protocol. Code and working document to be published as soon as we can get initial work in the repository. <br><br>The name for the uplink voice and data protocol is Opulent Voice. The codec choice is flexible, but the default is OPUS 16 kHz, hence partial inspiration for the name. Target demo event is DEFCON at the earliest and getting voice streams delivered to our FPGA encoder is the goal.<br><br>Thank you to everyone that has helped out and been supportive along the way. It’s a privilege to be able to work with you all, and I believe this system will be inconveniencing a lot of electrons very soon. <br clear="all"><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div dir="ltr"><br>-Michelle Thompson<br><br><div dir="ltr"><br></div></div></div></div></div></div></div></div></div></div>