5 ms·

Hey, this is a serious accusation. I would be very careful about raising false suspicions like this publicly. The application does not reuse IVs. For your seco

Hey, this is a serious accusation. I would be very careful about raising false suspicions like this publicly. The application does not reuse IVs. For your second point, I am aware of authenticated encryption and the possibility of bit-level tampering with commands. The point of the encryption is to make sure to preserve confidentiality here. Tampering with commands is not really part of the threat model. The server needs to be trusted in some regard. If the server were compromised and actually modified commands, and it could send arbitrary network messages, then it could just change the HTML payload to the website and show the end user something different. The point of the encryption is only to preserve confidentiality with a properly running server, so CTR mode was chosen. I appreciate your dedication to security, but I would strongly advise you do more research before making comments like this — I take security very seriously as well, and making vague, unfounded accusations without actually reading the code only serves to confuse people.

jchook 3y ago
Maybe you can provide intuition about how the IVs are not predictable? They seem to be formulaic. https://github.com/ekzhang/sshx/blob/91c82d46cde4d1ffa0ae34e2a9a49911e2e53baa/src/lib/encrypt.ts#L55 https://github.com/ekzhang/sshx/blob/91c82d46cde4d1ffa0ae34e...
- ekzhang 3y ago
  You're exactly right. The IVs are completely predictable, and crucially, that allows us to guarantee that they are not reused. The security of CTR mode of encryption depends on avoiding IV reuse. Once again, I'm very happy to have this discussion at length! I just would prefer a context where people are not confused by misleading information from the start, and the readers are able to spend time thinking about it.
pvg 3y ago
Hey, this is a serious accusation. I would be very careful about raising false suspicions like this publicly. It's not an 'accusation', it's feedback on your thing. It could be mistaken but it's a Show HN, the purpose is public feedback. If that sort of feedback is not what you're looking for, don't do a Show HN.
- ekzhang 3y ago
  Once again, security is very tricky to get right, and I'm very transparent about the security model and encryption of the application. I've discussed this at length and have thoroughly documented the code. The commenter makes factual errors, and stating something is insecure, even on the level of suspicion, is a claim that as software developers, we take very seriously.
  - pvg 3y ago
    It doesn't matter if the commenter is wrong or right, you can't start writing grumpcomments with threatening auras at them. Particularly as an author in a Show HN but really anywhere on HN in general. If you think the critique is wrong, you can address that without hyperbole and without suggesting they're making accusations or need to 'be careful'. People are allowed to be simply wrong and if you think they are, you can explain that to them.
sneak 3y ago
Accusations are against people. GP criticized the code.
biorach 3y ago
> making vague, unfounded accusations without actually reading the code only serves to confuse people. It wasnt accusations, it was feedback. And it wasn't that vague. And it seems to be based on reading the code, quickly perhaps, but still. So I think it's on you to respond to the specific points in the feedback and either explain why they don't apply or accept and act on them.
- ekzhang 3y ago
  Thanks, yes as you suggested, I already responded to their specific points and explained my rationale for the security model in detail.
simonebrunozzi 3y ago
You are way off here. It's not a false suspicion, it's a suspicion. And it was worded very gently. Don't do a show HN if you don't want feedback like this.
- ekzhang 3y ago
  The comment says that the IV is reused. The IV is not reused! I am very open to feedback, but false statements about the security of an application need to be taken very seriously, especially when given from a commenter who speaks with a tone of authority on the subject. If I am truly unwelcome to do a Show HN, please let me know — but I think I have comported myself reasonably. I'm just trying to share something of interest to people!
  - simonebrunozzi 3y ago
    You are certainly not unwelcome. If a comment is wrong, just say so. It's a discussion.
egberts1 3y ago
A suspicion is a non-factual feeling based on seemingly incomplete fact. To say false suspicion, is to run counter to a person's feeling. To mitigate a feeling of this (suspicion), you will need to demonstrate some (not-so-counter-but-initial-)factual presentation. Asserting a false suspicion is a blatant insult to the Aristotle logic discourse and two-debate debate exchange. You say False suspicion? We say: you prove it, don't evade it.
- ekzhang 3y ago
  My concern with the comment is that it speaks from a position of authority and raises a lot of false alarms about the security of the application. The anonymous commenter publicly shared a suspicion of something that is 1) very serious and 2) false, and it essentially forces me to respond immediately. That is really stressful, especially since it's a tricky technical subject that a general audience of software developers is not expected to be familiar with. It's hard to explain why the comment is vague without giving more cryptographic background. I cannot disprove IV reuse in a short comment of this regard. It's an imperfect analogy, but imagine writing a piece of systems software and someone commenting "this leaks memory, just add a print statement to line N. I don't have time to look more." I could show them in a couple minutes why they were incorrect about line N, but "leaks memory" in general is a very vague accusation that could refer to any part of the program, as are the comments about integrity and AE and so on.
  - pvg 3y ago
    The anonymous commenter To most casual readers, you're a pseudonymous and unknown poster too (and that goes for nearly everybody, really). it essentially forces me to respond immediately. That is really stressful There are a lot of processes and rules to make Show HN welcoming and unstressful - it has extra guidelines, accepts a very wide variety of work in terms of quality, size, polish, etc. But it can't remove the stress of public feedback, including potentially inaccurate public feedback and you can't start going after your critics like that because of it.
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 ago
  The 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!

jchook 3y ago

Maybe you can provide intuition about how the IVs are not predictable? They seem to be formulaic. https://github.com/ekzhang/sshx/blob/91c82d46cde4d1ffa0ae34e2a9a49911e2e53baa/src/lib/encrypt.ts#L55 https://github.com/ekzhang/sshx/blob/91c82d46cde4d1ffa0ae34e...

ekzhang 3y ago
You're exactly right. The IVs are completely predictable, and crucially, that allows us to guarantee that they are not reused. The security of CTR mode of encryption depends on avoiding IV reuse. Once again, I'm very happy to have this discussion at length! I just would prefer a context where people are not confused by misleading information from the start, and the readers are able to spend time thinking about it.

pvg 3y ago

Hey, this is a serious accusation. I would be very careful about raising false suspicions like this publicly. It's not an 'accusation', it's feedback on your thing. It could be mistaken but it's a Show HN, the purpose is public feedback. If that sort of feedback is not what you're looking for, don't do a Show HN.

ekzhang 3y ago
Once again, security is very tricky to get right, and I'm very transparent about the security model and encryption of the application. I've discussed this at length and have thoroughly documented the code. The commenter makes factual errors, and stating something is insecure, even on the level of suspicion, is a claim that as software developers, we take very seriously.
- pvg 3y ago
  It doesn't matter if the commenter is wrong or right, you can't start writing grumpcomments with threatening auras at them. Particularly as an author in a Show HN but really anywhere on HN in general. If you think the critique is wrong, you can address that without hyperbole and without suggesting they're making accusations or need to 'be careful'. People are allowed to be simply wrong and if you think they are, you can explain that to them.

sneak 3y ago

Accusations are against people. GP criticized the code.

biorach 3y ago

> making vague, unfounded accusations without actually reading the code only serves to confuse people. It wasnt accusations, it was feedback. And it wasn't that vague. And it seems to be based on reading the code, quickly perhaps, but still. So I think it's on you to respond to the specific points in the feedback and either explain why they don't apply or accept and act on them.

ekzhang 3y ago
Thanks, yes as you suggested, I already responded to their specific points and explained my rationale for the security model in detail.

simonebrunozzi 3y ago

You are way off here. It's not a false suspicion, it's a suspicion. And it was worded very gently. Don't do a show HN if you don't want feedback like this.

ekzhang 3y ago
The comment says that the IV is reused. The IV is not reused! I am very open to feedback, but false statements about the security of an application need to be taken very seriously, especially when given from a commenter who speaks with a tone of authority on the subject. If I am truly unwelcome to do a Show HN, please let me know — but I think I have comported myself reasonably. I'm just trying to share something of interest to people!
- simonebrunozzi 3y ago
  You are certainly not unwelcome. If a comment is wrong, just say so. It's a discussion.

egberts1 3y ago

A suspicion is a non-factual feeling based on seemingly incomplete fact. To say false suspicion, is to run counter to a person's feeling. To mitigate a feeling of this (suspicion), you will need to demonstrate some (not-so-counter-but-initial-)factual presentation. Asserting a false suspicion is a blatant insult to the Aristotle logic discourse and two-debate debate exchange. You say False suspicion? We say: you prove it, don't evade it.

ekzhang 3y ago
My concern with the comment is that it speaks from a position of authority and raises a lot of false alarms about the security of the application. The anonymous commenter publicly shared a suspicion of something that is 1) very serious and 2) false, and it essentially forces me to respond immediately. That is really stressful, especially since it's a tricky technical subject that a general audience of software developers is not expected to be familiar with. It's hard to explain why the comment is vague without giving more cryptographic background. I cannot disprove IV reuse in a short comment of this regard. It's an imperfect analogy, but imagine writing a piece of systems software and someone commenting "this leaks memory, just add a print statement to line N. I don't have time to look more." I could show them in a couple minutes why they were incorrect about line N, but "leaks memory" in general is a very vague accusation that could refer to any part of the program, as are the comments about integrity and AE and so on.
- pvg 3y ago
  The anonymous commenter To most casual readers, you're a pseudonymous and unknown poster too (and that goes for nearly everybody, really). it essentially forces me to respond immediately. That is really stressful There are a lot of processes and rules to make Show HN welcoming and unstressful - it has extra guidelines, accepts a very wide variety of work in terms of quality, size, polish, etc. But it can't remove the stress of public feedback, including potentially inaccurate public feedback and you can't start going after your critics like that because of it.

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 ago
The 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!