less a criticism (as this is a fantastic project) and more a general comment about security protocols. The protocol (https://mikrophone.net/ecp.html https://mik

less a criticism (as this is a fantastic project) and more a general comment about security protocols. The protocol (https://mikrophone.net/ecp.html https://mikrophone.net/ecp.html) for privacy appears to require another MikroPhone device on the other side to communicate with. the cryptographic backdoors I have encountered in my work were in closed loop systems where having a standards based interface to facilitate separate or independent implementations would have foiled the schemes, as replicating the sabotage in another project would have been far more complex. the first student project is building this, the next really interesting one is reasoning about that security protocol. the ideal protocol described provides good forward secrecy, and speculatively if I were looking for implementation sabotage I would look for where the padding nulls were used instead of bytes of the nonce to reduce its entropy to something brute-forcible, and off hand as far as threads to pull, whether the parity bit on the key could reduce the search space by %50 as either even or odd. from a design perspective, if it only talks to copies of itself, why add the complexity of a new protocol? from a mass interception perspective, the "don't roll your own crypto" cliché is probably one of the most successful psyops of all time and I don't think it's a useful admonition in this case, but imo the question of "why" for a new protocol is the most interesting one.