i dont think that means that aes is patented at all. that looks like a patent for a particular implementation of it, which hardware vendors are ok with; because they will send their designs to somebody else to manufacture. but these days, the algorithm is not considered interoperable if both sides need to license it.

the environment has changed a lot. people used rsa for a while, and were simultaneously dealing with export issues. if you include legally encumbered anything in your design, it's going to get rejected until there is no other option.

TLS only encrypts from you to the server. The server gets the plaintext. If you were storing data that you encrypted on your end, then the server would not be able to decrypt your data. They can only store it for you. So it's not "double encryption" to encrypt inside of TLS, because from the standpoint of protecting you from the server admin, it's not encrypted at all by TLS.

i'm dealing with this same issue, where i am trying to use encryption at rest, and i'm required to have the encryption key sitting on the filesystem. it might be ok if it was a temporary file that can only be read once, and supplied remotely on startup. the idea is to prevent a tar of the filesystem from being enough to recover the database. i looked into vault.io a while back for scenarios like this, but it just moves the problem around when connecting to the secret server requires... a private (x509 verify) key on disk.

removing a pointer to something can be a constant time operation. zeroing out deleted data is on the order of the length of the data. this is why many languages don't force the zeroing of allocated data either. it's lazy to not do it, but it's not a small or even constant factor in performance.

It shows up in snopes. It's an old scam to order a bunch of stuff and ship it to you. Then they wait for you to open the packages, and send you a huge bill. snopes.com/crime/fraud/supplies.asp

Perhaps this person is trying to order your ink?

It's not entirely clear what kind of DDoS attack it actually is (which tells you how/whether it really can be mitigated without just having two independent connections). I assume that they are not amplification attacks (like synflood), which do have practical mitigations; or spoofing that could be mitigated by egress filtering by the ISP. I presume that the gaming protocol is speaking peer-to-peer with the real attacker rather than purely to the server; so setting up the interfaces to only respond to a few server IPs may not be a possibility.

Amanda and Neil get on video chat and sharpie themselves with DH key exchanges, then resume the connection under the new key. They know each other well, so don't expect real-time video manipulation by the man in the middle to fool them. If you try to authenticate with somebody you don't actually know, you haven't really authenticated no matter what tech you used; as your new friend is an NSA employee.

I think this is too pedantic. The problem is authenticating the other end, and having secure computers on both ends. Key exchange is a solved problem, and authentication mostly so. In the worst case, get into a video chat to authenticate. Do the DH key exchange with your eyes open (verify the key exchange) from your secure computer.

Though it would be ideal, TLS isn't solving this in practice because the server will almost never require a certificate from the client to prove its identity. SmartCards that supply these client certs work, but are a logistical headache outside of a centralized environment (like the military). Because passwords may be reused among sites, it's also not a good idea to send the plain-text password to an authenticated server. But this is often done because many backend systems are not design to securely delegate challenge/response up to the user (ie: they want a password).

That's bobo. Most ISPs here learned their lesson, because it costs more to deal with the botnets than it does to just set them up right.

Actually, modifying traffic is a big design issue. You lose stealth when you mess with traffic. If you mess with traffic, you need to be careful to not break applications or introduce performance problems.