7 ms·
I’m not even sure that OTP is secure by modern standards. Since OTP encrypts with XOR only, a man-in-the-middle can still modify the message by XOR a few bytes
by charlieyu1 5y ago
I’m not even sure that OTP is secure by modern standards. Since OTP encrypts with XOR only, a man-in-the-middle can still modify the message by XOR a few bytes with constants like 0x01 to modify the message.
- DarylZero 5y agoOTP can be combined with some message authentication code, so I don't think that's a fair criticism.
- mistercow 5y agoYeah, nothing is secure if you apply it incorrectly. SSH isn't secure if you tweet your private key.
- danlugo92 5y agoBut my private key just laying there unencrypted in `~/.ssh/id_rsa` is safe for some reason?? I've never understood this.
- freeqaz 5y agoYou should encrypt your private key with a password. Then you can use ssh-agent to hold a copy of that decrypted key in-memory so that you don't have to type your password in every time you 'git push'
- nerdponx 5y agoIs this actually an extra layer of security? Is it harder to get read access to another user's file with 0600 permissions, or to read memory from another user's process? In my limited understanding they seem equivalent (at least on Linux).
- joombaga 5y agoThey're approximately equivalent on Linux. Adding a password helps if you accidentally tweet or email your private key, leave it on a flash drive, leave your computer's disk decrypted, etc.
- auxym 5y agoEncrypting the file, or better whole disk encryption, prevents someone stealing the laptop and yanking the drive to get access to everything.
- staticassertion 5y agoIt's primarily targeting offline attacks ie: I've stolen your laptop or I am accessing it when you haven't decrypted it. But there are also niche situations where an attacker has read permissions for files but not memory. It's atypical, but in cases where you have 'confused deputies' it happens - for example, if I have a service that attempts to safely broker reads to files but that service has a logic bug where a client can trick it into reading sensitive files. The classic example of this is a path traversal in a web service. Also, while there's no boundary, attackers are a lot happier reading files than memory. They're only human. In general I find that, when you can, you should just encrypt your data. It can protect you in some surprising ways.
- csunbird 5y agoNo, you are supposed to use a passphrase to protect it.
- m-p-3 5y agoYou should always protect your private key(s) with a password.
- jamespwilliams 5y agoSmartcards e.g Yubikeys help with this. You store the key on the smartcard, then use ssh-agent to have the smartcard perform whatever cryptographic operations are necessary. On Yubikeys at least, the keys can never leave the smartcard, by design.
- LinuxBender 5y agoOne mitigation against this is to specify on the target hosts where that keys are valid from. One could even be as liberal as to give the entire CIDR block of their ISP or Corporate IP CIDR block or preferably use a VPN network. The key will not be valid for anyone not in the specified networks or IP's separated by commas. e.g. using my tinc VPN mesh grep keys /etc/ssh/sshd_config AuthorizedKeysFile /etc/ssh/keys/%u cat /etc/ssh/keys/root # honeypot server from="192.168.0.0/16,10.15.10.2" ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDDlyvd+LAveSiIIgQW3Y+aWsb8bTu70tgXQjoWMrMAbKt1/sDoE/w2qqLBSqLjJmA46zKqwgZhnO8hkZjpizjb909fNYrgyNOsRcHOvumanORUGjcumxi5fklqNZCXC1rehX4z+tnVzygtDNQcqlmyy1ElBM+SxKS+YIrOymPOU6bc5V1sildq5cVUSuEHcLggOadCj6azbiR1J46D6UYxAaKYjq2OloLZXRhvSYrmVeH+PNKiShgYBu4TfCg4UoJKZsHTaeS2akZAQTqcjy7bB8HRWGXYEMKAKA95w8MTqaWlIoMKBuOJnd8+wRXrZKnSsTQmQQZg0rggO6GC8ufT leaked_on_purpose I would be happy to provide my private key and a VM IP if anyone would like to try this out.
- xyzzyz 5y agoIf you think this is secure even if you leak private key, why not just disable key checking altogether and just allow anyone to log in if they come from accepted network?
- LinuxBender 5y agoOne could do that as well. Different use cases can mix and match any restrictions using the Match block in sshd_config or simply having a general restriction like this. AllowUsers root@192.168.*.*
- Taek 5y agoDefense in depth - have several independent layers of security so you have some breathing room to fix things if one of the layers is fully compromised.
- DarylZero 5y agoDoes OpenSSH let you disable all authentication?
- 5y ago
- SavantIdiot 5y agoI believe that's why ChaCha20 is used with Poly1305 to provide authentication, which is why you see it referred to as ChaChaPoly.
- tptacek 5y agoEncryption and message authentication are separate problems; the combination of both is called "authenticated encryption". Almost all AE/AEAD schemes ultimately encrypt by simply XOR'ing a keystream against plaintext.
- zarzavat 5y ago"OTP" should not be taken literally here, it's merely an analogy. Yes, true one-time pad encryption is not secure by modern standards, as you mention there's no authentication, you need a perfect random number source, and key management is horrendous. However, the concept of encryption by XORing a stream and the plaintext is very much the modern way of doing things, and "OTP" is an analogy for that.
- akerl_ 5y ago“OTP” isn’t an analogy for the concept of XORing a stream. One-time-pad is a specific way of handling key generation.