3 ms·
I intended this to be constructive feedback and I'm sorry if it came off as otherwise. Even if the IVs themselves aren't actually problematic, I think the main
by throwaway81733 3y ago
I intended this to be constructive feedback and I'm sorry if it came off as otherwise. Even if the IVs themselves aren't actually problematic, I think the main point is that users of this would be interested in integrity being part of the threat model. To me, there is a tangible difference between trusting the server with complete shell access and only trusting it to deliver frontend assets that I can inspect. Additionally, using misuse-resistant cryptography constructs and libraries is a good practice to avoid some of these problems entirely. I look forward to seeing iterations, since otherwise this is very nice work.
- ekzhang 3y agoThe other comments make it fairly clear that this suspicion was unfounded but convinced people otherwise, and I have given a fair response to your comments. I of course appreciate you scrutinizing the application, and while the feedback was constructive, comments about the brokenness of a security model need to be taken very seriously. --- From the application perspective, the root of our disagreement seems to be that you would prefer using higher-level managed cryptographic primitives. I understand this criticism, but there were systems reasons why these were not appropriate for sshx. I agree with you that for most standard applications, you would avoid having to use stream ciphers directly as much as possible. sshx kind of straddles the boundary of what's technically feasible with real-time stream multiplexing and communication though. I'm glad you find the work interesting, it's something I've spent a lot of time on!