Yes use dbatools in particular the command Enable-DbaForceNetworkEncryption

I think you're mistakenly recalling the movie. In Citizenfour, Snowden warns the journalist on the risks of leaving a SD card unencrypted on his laptop with sensitive documents on it. He never says that SD cards cannot be encrypted. In fact, as the other answers point out, you can encrypt a SD card just like any other mass storage device.

The downside to encrypting your data, is that if you lose your password, and it wasn't an easy one; it's pretty much game over. As you made the password (you did, right?), try any password you ever made. If that fails, try using a script that brute forces the top 10 000 most used passwords, there are password lists scattered all over the itnernet. If that fails your last resort may be to brute-force the password, Kali Linux has lots of great offline password cracking tools. Note: Brute-forcing passwords can take a LONG time (we're talking anything from an hour to 300 billion years if you have a decent password) if your password is anywhere above 5-6 characters. You can test how long it would take to bruteforce a certain password on this website: www.howsecureismypassword.net.

If it isn't required that you can decrypt the customer ID, then I believe that you can use an HMAC. You create a shared secret between C and P. This should be a really nice long shared secret. When you go to store a customer ID you store HMAC(SECRET, CustomerID). When C wants to look up a record it performs the HMAC and passes the result to B who can do the DB lookup. You are protected from pre-computation attacks because you have used a very long shared secret (let's say 1024 bits but less may be secure - others maybe can help you). Likewise, the long secret protects you from brute-force attacks. I believe that this securely satisfies (1), (2), (3), and (4). Of course, if you need to be able to go backwards from the hashed ID to the actual ID, this doesn't work. I know that you don't specify that requirement in your question but maybe you assumed it was obvious.

I actually tried this with my neighbor who is connected to same ISP. PPPoE required 3 things: Username Password MAC if Binding is enabled by your ISP I was able to get these things from my neighbor. I spoofed the MAC address, started PPPoE connection with his credentials. And BOOM I was able to use his IP. But before that the PPPoE session of my neighbor has to be shut down. There could be only one PPPoE session at a particular time.

No, 2048 bit RSA key is weaker than 128 bit AES key. It may sound that the RSA key should be stronger, because it has more bits, but that is not the case. The reason for that is RSA key has to be product of two prime numbers while AES key can be completely random.

There is little you can do. While encryption is supported every step of the way, the only part under your control is your client to your server. To use encryption when sending from your server to other server, both servers have to support encryption and the receiver client server connection is completely out of your control. You should disallow unencrypted connections to your server (from your clients). There is no reason not to. You may refuse to connect to other servers without encryption, but this will cause e-mails not to be delivered to people, who use servers that don't support encryption. There is no way you can force encryption between recipients server and client, that part is out of your control. That is why end-to-end encryption (using third party tools such as enigmail) is much superior when communicating using e-mail. E-mail is inehrently insecure, because it has to support variety if legacy servers and clients.

HTTPS (or TLS in general) can be used to send the secret to the clients in a secure way, i.e. protected against sniffing and modification. But, it needs to have some form of authentication in order to protect against man in the middle attacks (which might sniff or modify the secret). Authentication is usually done with a certificate which the client must either know up-front or where the client can derive the trust because it was signed by a trusted issuer. Diffie-Hellman alone is not enough to exchange the key since it is missing the authentication part. In fact, TLS commonly (but not always) uses Diffie-Hellman as key exchange itself but also does server authentication.

Normally, it should not. The websites would not know how to decrypt it, so it couldn't. But Chrome for mobile has a compression thingy that is supposed to save on mobile data and I believe that may be encrypted (so it would be encrypted when it is turned on). In that case, the data saving compression feature may be acting as a sort of VPN, encrypting even HTTP up to Google servers.

To do this securely, you'll need to either Create a PGP certificate or S/MIME certificate, share it with the user, and then share content via email encrypted using PGP or S/MIME. Or Share a shared-secret with the recipient ahead of time - by phone is probably the easiest way. I'd recommend a 6 word or longer EFF Diceware password, but this will vary based on your threat model. A good tool for generating one can be found at https://www.rempe.us/diceware/#eff, although you can use whatever tool you want. After you share this shared secret, you can use any number of file-encryption (or email encryption) tools to send a document encrypted using the shared secret. I'm partial to ProtonMail because of its ease of use, but truly any reputable file encryption or encrypted email solution is fine. Alternatively, you can also use a tool like Sync.com or another file-sharing site that allows encrypted transfer and password protection. Truly, the important and difficult part is getting the shared secret out there in the first place. If you recipient isn't computer savvy, #2 is probably the easier workflow. All they have to do is click an link and type a password consisting of only common English words.

Revised answer In general, you may want to start by basing your cipher (mostly relevant for asymmetric ciphers) on a known hard problem. You may want to make mathematical proofs verifying your cipher has the desired properties and breaking it indeed requires solving the known hard problem. What kind of problems to choose was explained more on Crypto SE. By creating these mathematical proofs, you will make sure your cipher is not easily breakable directly. The next step may be to look at side channels. Most notably timing attacks. If your cipher takes different amount of time for different inputs and keys, you may want to at least add code to either make it take the same amount of time always or just add random amount of time by active waiting. There are many other side-channels and considerations a widely used cipher has to take into account, but this should get you started. Of course, making all these mathematical proofs is very difficult and even then, it does not give you any guarantee the cipher can't be broken. Even if the cipher is secure on its own, in combination with other cryptographic primitives, it may turn out to be easily breakable. That is why rolling your own crypto is such a big taboo. Getting it right is very very difficult and you will not find out you did something wrong until someone breaks it, or if you are unlucky, not even after that.

This image is confusing. The private key of the sender is different from the private key of the receiver. These keys are private, so not even the proper sender and receiver know each others private keys. They are not distributed at all, only public keys are. I don't know why this image portraits them being the same. Also there are two public keys. One for each private key. You should probably find a better image.

You don't need to EMP satellites. Nuclear superpowers have anti-satellite missile to take down enemy communications. This would also make it hard to launch new satellites as there would be large amount of debris in orbit. A nuclear war would cause nuclear winter, which is caused by high amount of dust in the air. Assuming the dust has lots of metal in it, I can easily imagine it blocking radio-waves, even though I am not sure, if it would in reality. The cables are harder to justify away. There is not really much tactical value in cutting them IMO. But as they are likely to terminate in or near cities, you can go with them being nuked. Another option is that the transmitting devices were destroyed by the EMP and they are way too high-tech to replace in post-apocalyptic world. EDIT: Cables in oceans have repeaters, that help extend the range of the signal, as the light can only travel certain distance. You can claim the EMP blast destroyed these repeaters (in reality, it is likely the water would protect them IMO).

The currently published documentation on what that deterministic encryption really does is not sufficient to come to any definitive conclusion. What can be said is that such deterministic encryption may be designed and implemented "properly", in which case it incurs no extra weakness beyond the ones inherent to its functionality: namely, that if two values are identical, they will be encrypted to the same value, and this will be visible to the attacker. This is a big unavoidable problem if the values are in a small enough set (e.g. a boolean true/false). Existing documentation seems to imply that the underlying encryption algorithm is "AEAD_AES_256_CBC_HMAC_SHA_256", which says both a lot, and not nearly enough to actually know what runs under the hood. A "proper" implementation that matches the documentation would compute the IV for CBC encryption with EK(SHA-256(m)) (symmetric encryption of the hash of the complete data to encrypt). Such an implementation would avoid the ECB/Penguin issue. However, it is not clear whether this is what Microsoft actually implemented.

As you wrote, 1-5 can be achieved using KeePass + thumb drive. As for point 6, It seems YubiKey already thought of that. You can use YubiKey or other HW token with KeePass using the OtpKeyProv plugin. However, I could not find a detailed explanation of how it works and it does not seem to me as very secure. I have a feeling it could be bypassed rather easily by a more advanced attacker. There are plugins for KeePass that allow use of RSA keys, but I am not convinced they are usable with a HW token. Check (here, here and here) The RSA key approach if implemented correctly would be very secure and would protect against the theft of the password vault from unlocked thumb drive. For point 7, just pick a good USB drive, maybe the one recommended by Steven. But honestly, the thumb drive will never provide significant increase in security. Final note: KeePass can be used on android, but I don't believe the plugins can be. So using 2FA would be at the cost of using it on Android.

I don't believe there is. Though technically some firewalls/corporate proxies do sort of MITM attack and they do verify the certificates and reencrypt the traffic with their own key, so that may be similar. You can use pre-shared keys with TLS. It is specified in RFC-4279. It is hard to compare. SSL/TLS is currently the easiest, most flexible and most user friendly. It has great interoperability and so on. It also wen through large amounts of research and testing, so it can be considered more reliable than something new. On the other hand, for specific use-cases there certainly are better option. They are just not as universal. I do not know about anything outright better than TLS in all areas.

Maybe sort of. The DUKPT algorithm is defined to use "two-key triple-DES", or formally TDEA Keying Option 2 from SP800-57 or originally FIPS46-3. Every key in this algorithm (BDK, device initialization key(s), future keys, and working key(s)) is a "double-length key" consisting of two classic-DES (DEA) keys, each 56 real key bits plus 8 bits reserved for parity and today often ignored, stored and transmitted and used as 64 bits, totalling 128-bits. Some implementations of triple-DES aka TDEA aka DESede (possibly including yours) require you always represent the key in full-length 192-bit or 24-octet form. Given a double-length key, you create a triple-length key by duplicating the first half, i.e. if the double-length key is (k1) (k2) then the triple-length key is (k1) (k2) (k1) . The result occupies 192-bits but only contains 112-bits of "real cryptographic keyosity".

This is not a full answer but I want to highlight an aspect you did not mention. Apart from physical security (temper prevention and detection?) and encryption you have to be very careful what you are doing. That means that no process having direct internet connection (web surfing, chat, skype...) or which has indirect connection (mail) should be able to access any sensitive data. The best would probably to have no internet connection at all. Another option would be to only access the internet through a companies VPN where you hopefully get the needed protection. Unfortunately you often need direct internet access to at least establish a WLAN connection (because of capture portals) which you can use with your VPN. So one option would be to have a virtual machine and only do any connection from inside this machine.

Determining What Is Running Locally, Ask The Host The most definitive way to determine what is communicating on port 3030 is to ssh into the server and run netstat. netstat -nap | grep 3030 Will display connections and listening processes -n skips DNS resolution of IP addresses, -a shows the state of all sockets, and -p shows the PID of the process bound to that socket. If you are using windows, check out this SO post. Determining Remotely If you can't get access to the server, there are other things you can try. Run nmap against the port. nmap has pretty good service detection and if what is running on 3030 is a well known protocol, nmap will likely determine it. nmap -sV host You can find out more about nmap service detection in Chapter 7 of the nmap book. What if nmap can't determine the service? It may be that you are looking at a legitimate custom service for that application. Though you could also be looking at malware. Determining the functionality of the service If have permission to interact with the service, here are a few things you could try/notice: It appears that each response is base64 encoded, and ends with a > ``` . This to me suggests that it is a shell of some kind. Base64 decoding gives garbage, which suggests that this could be encrypted, although it could also be a custom base64 alphabet. Enter various text. Does the same output get produced for the same input? Is there a correlation between input length and output length? Is output length always a multiple of some number? For example, in the four lines you showed in the question, the lines decoded to 48,48,16 and 16 bytes long. This could suggest a block cipher of some kind is being used. Does the initial response to your connection change each time you make the connection? This could suggest the server is using a one time encryption key (or base64 encoding) for each connection. Thus, the first response likely contains the information necessary to interact with the service. If you start to get common strings, start googling them. If you get a hit, you may get your answer. Note, if custom encoding or encryption is being used, it is unlikely that your input will do anything, as the input will probably need to match the same encoding scheme.

If you want to create an encryption key or store a hashed password, you want to use a key derivation function, not a simple hashing function like SHA-256. A KDF is like a hash that gets applied many times, but is typically designed to be computationally expensive in order to make brute-force searches harder. While you might be able to use SHA-256 as a KDF by calling it multiple times, this is not the standard way to do things, and may be much less secure than it appears since you need a very large number of iterations to provide effective mitigation against brute-force attacks. The most popular (read: carefully studied and probably secure) KDFs in current use are PBKDF2 ("password-based key derivation function 2") and bcrypt. Either is suitable for hashing and storing passwords, as well as for creating encryption keys. There are also some newer algorithms such as scrypt which may be more secure under some definitions, but it is my understanding that they are newer and less well-studied. "Security" is, of course, not a numerically quantifiable variable, so it's not entirely meaningful to say that "algorithm X is the most secure choice." Generally, a KDF will take a parameter called the work factor or the number of rounds. This describes how much computational effort is required to compute a hash or derive a key. As computers get faster, this parameter needs to be increased in order to ensure that your hashed passwords remain sufficiently resistant to brute-force attacks.