This question is unlikely to help any future visitors; it is only relevant to a small geographic area, a specific moment in time, or an extraordinarily narrow situation that is not generally applicable to the worldwide audience of the internet. For help making this question more broadly applicable, visit the help center.
Closed 9 years ago.
I am implementing AES. Encryption will take place on server side and decryption on client side. What is the secure way to store the key and pass it to client side? Will I need to store in notepad or XML to transfer? Can I use jks pr certificate to store that key?
Probably the best way is to let the remote party generate an asymmetric key pair (e.g. RSA 2048 bit) and let them send you the public key. This transport must be secure in the sense that the public key should be verified to be from the other party. Then you can encrypt the data with a (random) AES key, and encrypt the AES key with the public key. The remote party decrypts the AES key using the private key (which is kept at the remote location). Then the data can be decrypted. Use AES-CBC mode at the minimum, which will only provide confidentiality of the data, not integrity or authentication. Also note that e.g. the amount of data may already let an attacker guess what is inside.
The real question is how to establish trust. This is why you need to check that the RSA public key is really from the correct person, e.g. by verifying an RSA public key fingerprint over the phone. Note that instead of programming this yourself, you are better off using an established solution like the PGP protocol.
Related
I'm trying to understand the mechanism of encryption used on the web.
One thing is not clear to me at this point:
If I check, for example, google.com certificate, I can see that the public key is 4320 bits long, but Chrome shows that the connection is encrypted using AES_128_GCM, that I would expect to work with 128 bit keys.
What am I missing here?
The 4320 bits in the public key algorithm are used to encrypt the 128 bits in the symmetric key algorithm. The public key establishes a secure channel of communication between two parties who initially don't have any shared key. Think of this as a low bandwidth channel, which isn't very useful due to the computationally expensive nature of the public key algorithm. In practice -- the sole use of this public-key is to communicate a shared key to establish a high bandwidth channel which uses something like AES (which requires both parties to have the same key). The overall process is an example of a hybrid cryptosystem.
The whole process is more involved but here are the basis to answer the question.
The data is encrypted with a symmetric algorythm such as AES, it is fast, secure and can handle any length of data.
The symmetric key is encrypted by an asymetric algorythm sucb as RSA or EC, they are slow and the data length is limited by the key length.
There are many articles on the Internet about HTTPS, it can get quite complicated.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 7 years ago.
Improve this question
The goal of this question is that I am just trying to better understand the nature of P2P and networking and security / encryption. I am a front-end web developer and my knowledge of the networking stack is not great if we go lower than HTTP requests.
That being said, I am trying to understand how torrent traffic is "sniffed" by ISPs and the content identified. I feel like this question will expose my ignorance, but is it not possible to have some sort of HTTPS-like P2P protocol that would not be so readable?
I grasp that a given packet has to identify its destination to the network along the way, but couldn't torrent packets be configured to show ONLY their destination, so that nobody could identify its purpose along the way, until it arrived at its destination? Why is it apparently an unrectifiable situation that ISPs can just look at P2P traffic and know everything about it, yet SSH is extremely safe?
Every answer here seems to have a different interpretation of the question, or rather, a different assumed purpose of the encryption. Since you compare it to https, it seems like a reasonable assumption is that you're looking for authentication and confidentiality. I'll enumerate a few attempts in decreasing level of "security". This is a bittorrent centric answer, because you tagged the question with bittorrent.
SSL
Starting with the strongest system, it is possible to run bittorrent over SSL (it's not supported by many clients, but in a fully controlled deployment it can be done). This gives you:
Authentication of every peer participating
The ability to pick which peers are let into the swarm by signing their certificate with the swarm root.
SSL encryption of all peer connections + tracker connections
The tracker can authenticate every peer connecting to it, but even if the peer list (or one peer) is leaked or guessed, there's still the peer-to-peer authentication, blocking any unauthorized access.
Bittorrent over SSL has been implemented and deployed.
encrypted torrents
At BitTorrent (in the uTorrent client) we added support for symmetric encryption of torrents at the disk layer:
Everything in the bittorrent engine would operate on encrypted blocks. The data integrity checks (sha-1 hashes of pieces) would be done on encrypted blocks and the .torrent file would have hashes of the encrypted data. An encrypted torrent like this is backwards compatible with clients that don't support the feature, but they won't be able to access the data (just help out the swarm and seed it).
To download the torrent in an unencrypted form, you would add the &key= argument to the magnet link, and uTorrent decrypts and encrypts data at the disk boundary (leaving the data on disk in the clear). Anyone adding the magnet link without the key, would just get encrypted data.
There are some other details involved too, like encrypting some of the metadata in the .torrent file. Such as the list of files etc.
This does not let you pick which peers get to join. You can give access to the peers you want, but since it's a symmetric key, anyone with access can invite anyone else, or publish the key. It does not give you any stronger authentication than you had when you found the magnet link.
It gives you confidentiality among trusted peers and the ability to have untrusted peers help out with seeding.
bittorrent protocol encryption
The bittorrent protocol encryption is probably better described as obfuscation. Its primary intention is not to authenticate or control access to a swarm (it derives the encryption key from the info-hash, so if you can keep that a secret you do get that property). The main purpose is to avoid trivial passive snooping and shaping of traffic. My understanding is that it's less effective to avoid being identified as bittorrent traffic these days. It also provides weak protection against sophisticated and active attacks. For instance, if the DHT is enabled, or tracker connections are not encrypted, it's easy to learn about the info-hash, which is the key.
In the case of private torrents (where DHT and peer exchange are disabled) assuming the tracker runs HTTPS there aren't any obvious holes in it. However, my experience is that it's not uncommon for https trackers to have self signed certificates, and for clients to not authenticate trackers. Which means poisoning the DNS entry for the tracker may be enough to enter the swarm.
Torrent traffic can be encrypted, and there are VPNs/SOCKS proxies that can be used to redirect traffic, i.e., via another country through an encrypted tunnel before connecting to peers. That said, even if you use such services, there are a lot of ways of leaking traffic via side channels (e.g., DNS lookups, insecure trackers, compromised nodes), and most people aren't knowledgeable enough to follow all proper security/anonymity precautions. Furthermore, restricting yourself to communicating only with clients who have also forced encryption will limit the number of peers you can connect to.
The problem you're considering is the difference between point-to-point encryption where there are only two peers in a private context and an unbounded number of peers in a public context.
Decryption by any of the public peers can only be effected if there's a primer somewhere -- a decryption key that is available for all the public peers to use. In the case of protecting from the ISPs, they would also have access to that key unless there was some exclusionary protocol for only sharing the key amongst everyone else. It's not practical to do this.
In a point-to-point connection, a TLS key negotiation eventually creates a session encryption key that is shared by both peers. The key is pseudorandom and session-specific. Data shared on the internet this way would be unusable to clients that didn't participate in the key negotiation.
Bittorrent traffic (specifically the peer-peer protocol used to transfer the bulk of the data) can be encrypted. But it's the kind of encryption that does not provide strong confidentiality/authentication guarantees, similar (but not identical) to HTTP2's opportunistic encryption
Client-Tracker communication can be encrypted with HTTPS.
These two components give you a working, albeit restricted, bittorrent stack that's encrypted and whose contents are not visible to a passive observer.
ISPs may still be able to identify it as "bittorrent, probably" based on side-channel data (packet sizes/traffic patterns, domains contacted, ...) but they won't know exactly what is being transferred.
I'm looking for a distributed hash table to store and retrieve values securely. These are my requirements:
It must use an existing popular p2p network (I must guarantee my key/value will be stored and kept in multiple peers).
None but myself should be able to edit or delete the key/value. Ideally an encryption key that only I have access to would be required to edit my key value.
All peers would be able to read the key value (read-only access, only the key holder would be able to edit the value)
Is there such p2p distributed hash table?
Would the bittorrent distributed hash table meet my requirements?'
Where could I find documentation?
You don't need encryption, you need signatures.
The mainline bittorrent DHT does not allow arbitrary key value storage at the moment, only key -> IP:Port storage where the IP is fixed to the originator of the storage request. The vuze DHT on the other hand does support binary blob storage, on top of which you could implement some signature scheme.
Update: BEP44 added signed or hash-based key-value storage to the bittorrent DHT. But it imposes some restrictions what can be used as keys to randomly distribute data throughout the keyspace.
I am trying to use asymmetric encryption to encrypt firmware. The bootloader will decrypt and update the flash. This is on a embedded device with 32 bit CPU executing at 60MHz.
I want to use ECC due to its varies advantages. I am new to encryption and my understanding os ECC as implemented in ECIES is to use ECC for the key generation and use AES for actual data encryption. Due to code and ram size, I cannot support multiple encryption algorithms.
Is there a implementation of ECC that can be used just like AES. All I am looking for is to use a "Private key" to encrypt firmware and the bootloader uses "Public Key" to decrypt it.
Thanks.
I'm not sure that you completely understand what ECIES consists of:
http://en.wikipedia.org/wiki/Integrated_Encryption_Scheme
That's quite a bit of work, and it requires a whole lot of primitives, including at least one symmetric primitive, it seems to me. That might as well be AES.
Let's start from the last sentence of the question:
All I am looking for is to use a "Private key" to encrypt firmware and the bootloader uses "Public Key" to decrypt it.
There's some confusion in terminology here. Private keys are used to decrypt (or sign) and public keys are used to encrypt (or verify). If I understand correctly, what you want is for the bootloader to verify a signature on the firmware so that only a firmware that was properly signed by yourself will be accepted by the bootloader.
There are various asymmetric signature schemes which can be used for this purpose, including some which are based on eliptic curve cryptography. For example you could use the OpenSSL implementation of ECDSA (see http://www.openssl.org/docs/crypto/ecdsa.html).
I'm afraid there's not enough information in the question to properly choose the best signature scheme (and possibly an encryption scheme as well if there is a need to keep the firmware secret). In any case, good cryptography is not enough to make a system secure and other considerations such as secure implementation are no less important.
If this is is something that is important for you to protect and that you are worried that hackers may try to break, I would strongly advise procuring the services of a security professional. Using cryptography correctly is a very tricky business that requires a full understanding of the system - otherwise you may find yourself in a situation like this
If you look for "authentication" you have to use asymmetric algorithm like EC, this usually done because if the user or process want to update the "firmware" he should identify him self to the bootloader by his "signature" to check who request this update.
After that is done, the bootloader will load the symmetric key from a secure memory to decrypt what you want to do.
So, you have a symmetric key for encryption (AES), and asymmetric two keys for authentication (=Who are you?).
Note: there is no advantages of EC on 32 bit CPU executing at 60MHz for Encryption, unless your application need asymmetric for Encryption NOT authentication, this happen due to line between the user and bootloader is not secure.
Therefore, you could use bootloader's "public key" to encrypt firmware and the bootloader uses its "private Key" to decrypt it, however, the implementation cost a lot due to the high computing for asymmetric algorithm.
Look for "lightweight cryptography", it is typical for your application.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
First of all,
do those successful commercial MMORPGs use encryption for game data transmission?
I got an impression that many developers tend to not use encryption, because it can not prevent reverse engineering for cheating and making private server, but doesn't it effectively reduce the number of those?
Encryption also impacts performance, even just a little.
Good encryption does prevent network sniffering and man-in-the-middle, are these important for MMORPGs?
How about protecting chat messages for privacy concerns?
How do you think?
PS: I'm talking about game data, not user/password, auth info need to be encrypted for sure.
Encryption is a tool. Make sure the tool fits the problem.
Encryption is useful for essentially three things: 1) 3rd party can't view data, 2) both parties are who they say they are, 3) data hasn't be modified. None of those really apply here. Remember the client is on the user (attacker) machine. If they modify the client it will gladly sign & encrypt any message they want.
The second thing to consider is the fact that the client has the keys and thus you should assume the attacker also has the keys. Even if you use asymmetric encryption the client has the key to decrypt anything it receives. If you send "private data" to the client an attack can find the key and decrypt it.
A good MMORPG (deisgned to make cheating difficult) should assume two things:
a) user/attacker can see any data sent to client (so don't send things to client you don't want user to see)
b) an attacker can send any possible command to the user (so don't rely on the client for security).
In most MMORPG the client is little more than a dumb terminal with impressive graphics. All computation, error checking, and validation occurs server side. The client doesn't determine is you hit or miss, nor does it determine how much damage. The client simply tells the server "I am attack with item 382903128." or some other action (not result). The server validates that the player has access to that option, has the item, and the command is valid at this time. To prevent sniffing attacks the client is only given data that the user would have access to anyways.
In any security context, you need to think about what exactly the threat scenarios are.
Attacker A has access to a machine running the game client and wants to write a bot to automate his actions so as to win battles easily.
Attacker B is eavesdropping on packets on a local network, with the aim of
Stealing login credentials so as to play the game for free.
Spying on player-to-player private chat, perhaps to gain advantage in the game, or maybe for blackmail or harassment in the real world.
Inserting extra behaviour into the stream of commands, e.g. instructions to buy or sell items at prices that make money for the attacker.
Encryption has no effect on attacker A (since the game client can decrypt the communication, so can the attacker; counter-measures must be taken on the server) but defeats attacker B.
I disagree with some of the other answers about the value of the data being transmitted. Your private chats with other players are as worthy of protection as your instant messages with them, and your gold and possessions, earned with hours of toil, deserve some protection from attackers, if perhaps not as much as your dollars in a bank account.
During the 90's Ever Quest used a low level packet encryption. I recall fondly as there used to be a side application that would sniff the packet data and give you a zone wide info about everyone in the zone. The EQ team crippled this for a while when they added the packet encryption, but that didn't stop the hacker community as they would just get the key out off the client machine. So in the end, it really didn't help in any way.
As to the other MMO's out there, I've not looked at the packet data to make a determination one way or the other.
You don't need encryption for security per se.
Consider this 'packet':
<USER_ID><COMMAND><MD5HASH>
The MD5HASH is generated from the USER_ID + COMMAND + some other value both the server and client know, but is not transmitted over the wire (user email or some token supplied securely during login). The server can reconstruct the string used for hashing and verify the authenticity of the command. If some man-in-the-middle changes the COMMAND, the hash won't match.
Besides validating authenticity this method also allows you to check you received the entire instruction. (It's possible that your 'game packet' is spread across multiple TCP/IP packets, some might get lost, etc.)
This does not prevent snooping around in messages, but is does prevent tampering. It's a game, who cares about what players say? I mean, emails are unencrypted and nobody cares about those, while their contents is more valuable than the average in-game chat.
Encryption is always a good thing if it actually protects valuable data. For that would be bank data, mails, instant messaging and file transfers. Not because I'm terribly paranoid of my ISP or network provider, but there is a specific risk if you are in an open network (for instance, school networks or company networks), that someone might be reading sniffing network traffic.
For MMORPGS I don't see a benefit in either security nor in performance, since most data is highly session based and man-in-the-middle attacks are rather unlikely (because, afterall, why would you want to sniff and attack such a connection?).
What I would do is to transmit passwords and login credentials as hashed values (or even encrypt just that part), and leave the rest of the connection cleartext; so you don't suffer from CPU hogging and lag caused by encryption (especially when there is a heavy load on the server).
At least the login should be encrypted, and the client should verify the public key of the server against a white-list to prevent man-in-the-middle attacks.
Encrypting the data transfered during the game itself isn't that important.
You need to distinguish encryption and obfuscation which have quite different goals.For example SSL is useful as encryption but useless as obfuscation since the encryption happens in known APIs, and it's trivial to intercept the plaintext when it gets passing into/out from these APIs.
Obfuscation needs to be mixed into your own code and doesn't need to be cryptographically secure.
Encryption needed vs administrators of local network or Wi-Fi, they potentially could sniff your traffic/packets and grab/change game information/passwords.
Tipically (99.99999%) accounts are hacked by trojans, not by packet sniffing. So in 99.99999% encryption is useless.
Encryption is totally useless vs Botting or Cheating. For that cases there is special forces, like - Anti-Cheating/Bot systems.