I have implemented Single-decree Paxos, and have shown it not to fail in a Monte Carlo network simulator. I followed "Paxos Made Simple" http://lamport.azurewebsites.net/pubs/paxos-simple.pdf
I have read: Castro, Miguel; Liskov, Barbara (February 1999). "Practical Byzantine Fault Tolerance" http://pmg.csail.mit.edu/papers/osdi99.pdf
As far as I understand, the paper describes a Byzantine Multi-Paxos algorithm. It includes complexity which I hope I don't need for the single-decree use-case, such as Views and Leaders.
What is required to turn the Single-decree Paxos protocol into a Byzantine Single-decree Paxos protocol?
i.e. Is adding public key signatures to messages, and waiting for f+1 acceptors to agree, sufficient? Or do I need a pre-prepare phase too?
The paper you linked (thanks for that) has this statement "All
replicas know the others’ public keys to verify signatures". This means that the protocol uses standard public/private keys for verification.
The pub/pri approach is safe under two assumptions: a) there is a way for each node to safely learn about public keys of other nodes and b) each node has its own private key and the key is secured.
The rest of the approach is standard approach for messages verification: when a node A wants to send a message to node B:
Node A creates a message
Node A creates hash of the message
Node A encrypts the hash with its own private key (we will call encrypted hash - message signature)
Node A sends to Node B: [message, message signature, from: Node A]
Node B receives all three parts and verifies them
Node B creates hash is the message
Node B uses Node A's public key to decrypt signature of the message
Node B compares hash from the message and the decrypted hash: if they are the same, then the message for sure came from Node A
That pretty much guarantees that messages came from right nodes.
Related
Suppose I have a fixed message pool of 1000 messages, person A is sending message from this fixed message pool to person B using RSA.
If an interceptor also have the message pool he can precompute all the encrypted messages using B's public key. Now if he intercept A's message can he surely tell which message A has sent to B?
In this case should we use RSA only for a symmetric key exchange and then messages should be encrypted using a symmetric algorithm?
The text-book RSA encryption algorithm is deterministic. But the official RSA specifications (and also all implementations used in practice) include some (partly random) padding, so we don't actually encrypt plaintext, but pad(plaintext). So the above mentioned problem will not occur.
More details can be found in this answer https://stackoverflow.com/a/7933071/10690480
in the following case, if privateKeyOfA is leaked, what's the security problem? Can someone decrypt the message without privateKeyOfB??
Aes.encrypt(privateKeyOfA, publicKeyOfB, message)
Aes.decrypt(publicKeyOfA, privateKeyOfB)
If not, I guess why we need privateKeyOfA here is for A's signature?
The signature is needed since the receiver must know that the message is coming from someone that he can identify. If he cannot verify the signature, this means that he doesn't know the person.
If the private key of A is compromised by a hacker, he can send messages to everybody with signature impersonating the A.
A key exchange (e.g. using DH or ECDH) would be used by A to convert privateKeyOfA + publicKeyOfB into an AES key. This same AES key can also be generated identically by B using privateKeyOfB + publicKeyOfA. All traffic between A and B would be encrypted using the same AES key.
Assuming that all public keys are known (they are public after all), then anyone who has access to privateKeyOfA can regenerate all AES keys that were generated by A to communicate with anyone. This means all traffic involving this key (messages sent or received by A, with B or anyone else) would be compromised.
But if an ephemeral version was used (like in some modes of TLS), then a new key is generated for each session, so that if 1 key is ever compromised, only this session is compromised. You can read more about forward secrecy.
If the keys are used in the way you describe, then they are not used for signature.
For a personal MMO game project I am implementing a homebrew reliable UDP-based protocol in java. Given my current setup I beleive it would be relatively simple for a snooper to hijack a session, so in order to prevent this I am taking the opportunity to learn a little cryptology. Its very interesting.
I can successfully create a shared secret key between the client and server using a Diffie-Hellman key exchange (a very clever concept), but now I need to use this to guarantee the authenticity of the packets. My preliminary testing so far has shown that the couple of different ciphers Ive tried bloat the amount of data a bit, but I would like to keep things as small and fast as possible.
Given that I am only trying to authenticate the packet and not nessecarily conceal the entire payload, I have the idea that I could put an 8 byte session ID generated from the secret key into the packet header, encrypt the whole packet, and hash it back down to 8 bytes. I take the unencrypted packet and put the 8 byte hash into the place of the session ID and then send it off.
Would this be secure? It feels a little inelegant to encrypt the whole packet only to send it unencrypted - is there a better/faster way to achieve my goal? Please note I would like to do this myself since its good experience so Im not so interested in 3rd party libraries or other protocol options.
If both peers have access to a shared secret (which they should, since you're talking about Diffie-Hellman), you could simply store a hash of the datagram in its header. The receiver checks to see if it matches.
As an added security measure, you could also add a "challenge" field to your datagram and use it somewhere in the hashing process to prevent replays.
So this hash should cover:
The shared secret
A challenge
The contents of the datagram
EDIT
The "challenge" is a strictly incrementing number. You add it to your datagram simply to change the hash every time you send a new message. If someone intercepts a message, it cannot resend it: the receiver makes sure it doesn't accept it.
I have a small confusion on SSL handshake between browser and server in a typical https web scenario:
What I have understood so far is that in the process of SSL handshake, client (browser in this case) encrypts a randomly selected symmetric key with the public key (certificate received from server). This is sent back to the server, server decrypts it (symmetric key) with the private key. This symmetric key is now used during rest of the session to encrypt/decrypt the messages at both the ends. One of main reasons to do so is given as faster encryption using symmetric keys.
Questions
1) How does browser pick and generates this "randomly" selected symmetric key?
2) Do developers (or/and browser users) have control on this mechanism of generating symmetric keys?
Here is a very good description of how HTTPS connection establishment works. I will provide summary how session key is acquired by both parties (client and server), this process is known as "a key agreement protocol", here how it works:
The client generates the 48 byte “pre-master secret” random value.
The client pads these bytes with random data to make the input equal to 128 bytes.
The client encrypts it with server's public key and sends it to the server.
Then master key is produced by both parties in following manner:
master_secret = PRF(
pre_master_secret,
"master secret",
ClientHello.random + ServerHello.random
)
The PRF is the “Pseudo-Random Function” that’s also defined in the
spec and is quite clever. It combines the secret, the ASCII label, and
the seed data we give it by using the keyed-Hash Message
Authentication Code (HMAC) versions of both MD5 and SHA-1 hash
functions. Half of the input is sent to each hash function. It’s
clever because it is quite resistant to attack, even in the face of
weaknesses in MD5 and SHA-1. This process can feedback on itself and
iterate forever to generate as many bytes as we need.
Following this procedure, we obtain a 48 byte “master secret”.
Quoting from a this great video on network video, minute 1:18:07
Well where do you get randomness on your computer because your
computer is a deterministic device?
Well it collects entropies like your mouse stroke movements, your key
stroke movements and the timing of your hard disk, it tries to collect
all that randomness from the universe into a pull so that it can generate random keys just for one connection [this session]. And if that randomness is broken and its happened many times
in the last 30 years, then none of this works. If the adversary can
figure what your randomness can be then they can guess your keys. So use good randomness.
Note: the keys are created per session.
I'm wondering why ssl encrypted data can't be cracked easily once the packets are intercepted. As i understand it when you connect to a site like facebook the browser and site agree on a cipher, what stops the sniffer from seeing what cipher they agreed to?
SSL uses asymmetric encryption, meaning the decryption key is different than the encryption key. So if you as a client encrypt your packets with the server's public key, it can only be decrypted by the private key, which remains on the server. Of course, this is a simplification of everything that happens in an SSL transaction, but that's the basis of the concept.
Imagine sending a box with an open padlock to the other side - when the other side wants to send a message, they put it inside the box, lock the padlock and send it back to you, where you use your (private) key to unlock it. Even if the intercepting party has sees the padlock, they still don't have the key.
There's a lot of ways to describe it. For me, my ah-hah moment was when I figured out that, after information is encrypted multiple times, it can be decrypted in any order.
A encrypts first, passes to B a single encrypted message [A encryption].
B encrypts the message a second time, and passes to A a double encrypted message [A encryption and B encryption]
A removes [A encryption] from the message, leaving only [B encryption], and sends the message to B.
B now has a [B encrypted] message, and knows how to decrypt it.
The sniffer sees the message encrypted three different ways: [A], [AB], and [B].
That's three message passes to exchange one message, but once it's passed and both sides have the unique information to decrypt further communication, future messages only need one trip.
If you want a simple example of how a message could be decrypted in any order, you can use XOR as a sample encryption method. For keys A and B, message M, and XOR is ^, then
M ^ A ^ A = M
M ^ A ^ B ^ A ^ B = M
Facebook signs it's package with a certificate that Facebook got from an certificate authority such as RapidSLL.
As long as you trust the certificate authorities that all certificate they issue for facebook.com do really belong to facebook.com the connection is safe.
Facebook then sends you via a signed message it's public encyrption key which you can use to encrypt your messages to be read by facebook.
Yes, the cipher is public. However, the client asymmetrically encrypts a random session key (or rather a precursor) using Facebook's public key (they verify it's really Facebook's key by checking that it is signed by someone trusted). So only Facebook (who has a private key) should be able to derive the actual symmetric keys that are used to exchange website data.
See this detailed walk-through. In that example, an eavesdropper can tell that the connection uses RSA, RC4, and MD5. But they don't have Amazon's private key, so they can't derive the session keys.
Like Derek H said, there are fundamental differences between symmetric and asymmetric encryption. Look up stuff like DH key exchange protocol and RSA cipher, they are fundamental in SSL/TLS. On the other hand, it's relatively easy to decrypt sniffed data (ROBOT attack).
If you just need to be sure your communication is secure, you can simply use SSL/TLS Server Test, there you can see if you're not using recommended algorithms or see if your SSL/TLS configuration is PCI-DSS/HIPAA/NIST compliant.