3 ms·

If there are fears and doubts, perhaps it would be safest to just assume the transport is clear text in risk ranking and adapt other counter-measures to fill pe

If there are fears and doubts, perhaps it would be safest to just assume the transport is clear text in risk ranking and adapt other counter-measures to fill perceived gaps. For really sensitive flows, perhaps dark fiber + non standard ciphers + encrypting the payload with application layer encryption using non standard or custom ciphers. I mean, why not, if it's your own B2B flows. Take an existing cipher / protocol and make a few subtle changes. It's just math. For end-user encryption, that would take some more thought and would probably get into layers of turtles.

robbya 7y ago
There's a lot of ways to get encryption wrong. A few subtle changes could undo a very deliberate countermeasure for a somewhat obscure vulnerability. I don't think that's good advice.
- LinuxBender 7y ago
  I agree, but I would probably do it anyway if I were mitigating someones concerns. It could be a layer on top of the standard ciphers / protocols. I certainly would not do this for end-user comms. For B2B if you control both ends, maybe its a risk worth taking. Each entity would have to weigh the risks.
arcticbull 7y ago
Rolling your own crypto is dreadful advice. You’re making tweaks to something to avoid a backdoor you don’t know exists and in the process likely opening yourself up a gaping hole in the middle.
- LinuxBender 7y ago
  Oh I would not suggest rolling your own crypto. Rather, just fork openssl and make a very subtle change to each formula. For in-house use of course. Ages ago, I used to change up a rubix-cube for a friend. The more I changed it, the quicker he could solve it. If I made just a very subtle change, it would take him up to an extra 7 seconds to solve it.
  - nullc 7y ago
    That is likely to introduce vulnerabilities unless you are a subject-matter expert that understands the design of the things you are changing well enough to know which parameters were free choices.
  - arcticbull 7y ago
    My dude, there aren’t any “extra knobs” you can just turn and expect to maintain the security and integrity of a cryptographic solution. This isn’t some Node/React website we’re talking about. If you move one assembly opcode out of place you may end up disclosing your private key via side-channel attack — and that’s a best case outcome. The fact you’re so cavalier about this tells me you have no idea what you’re talking about. Ask an infosec person, then report back lol This has nothing; and I do mean nothing to do with your Rubik’s cube analogy. One small tweak and the whole thing may be utterly worthless. It’s like if you were tweaking the starting position of the Rubik’s cube with a nuclear warhead.
jasonvorhe 7y ago
This is terrible advice, sorry.

robbya 7y ago

There's a lot of ways to get encryption wrong. A few subtle changes could undo a very deliberate countermeasure for a somewhat obscure vulnerability. I don't think that's good advice.

LinuxBender 7y ago
I agree, but I would probably do it anyway if I were mitigating someones concerns. It could be a layer on top of the standard ciphers / protocols. I certainly would not do this for end-user comms. For B2B if you control both ends, maybe its a risk worth taking. Each entity would have to weigh the risks.

arcticbull 7y ago

Rolling your own crypto is dreadful advice. You’re making tweaks to something to avoid a backdoor you don’t know exists and in the process likely opening yourself up a gaping hole in the middle.

LinuxBender 7y ago
Oh I would not suggest rolling your own crypto. Rather, just fork openssl and make a very subtle change to each formula. For in-house use of course. Ages ago, I used to change up a rubix-cube for a friend. The more I changed it, the quicker he could solve it. If I made just a very subtle change, it would take him up to an extra 7 seconds to solve it.
- nullc 7y ago
  That is likely to introduce vulnerabilities unless you are a subject-matter expert that understands the design of the things you are changing well enough to know which parameters were free choices.
- arcticbull 7y ago
  My dude, there aren’t any “extra knobs” you can just turn and expect to maintain the security and integrity of a cryptographic solution. This isn’t some Node/React website we’re talking about. If you move one assembly opcode out of place you may end up disclosing your private key via side-channel attack — and that’s a best case outcome. The fact you’re so cavalier about this tells me you have no idea what you’re talking about. Ask an infosec person, then report back lol This has nothing; and I do mean nothing to do with your Rubik’s cube analogy. One small tweak and the whole thing may be utterly worthless. It’s like if you were tweaking the starting position of the Rubik’s cube with a nuclear warhead.

jasonvorhe 7y ago

This is terrible advice, sorry.