tadavomnist / serch Goto Github PK

A detailed whitepaper is required for the protocol.

Jea creating a protocol is not easy :3

Forward secrecy is a property of cryptographic protocols that ensures that if an attacker gains access to a party's private key after the fact, they cannot use it to decrypt past communications. This means that even if an attacker intercepts and records encrypted traffic, and subsequently gains access to a party's private key (e.g., through a successful cyberattack or by judicial order), they will not be able to use that private key to decrypt past communications that occurred before the key was compromised.

Forward secrecy is achieved by using a different set of temporary keys for each session, instead of using a single long-term key. These temporary keys are generated on-the-fly for each communication session, and are discarded at the end of the session. Since these temporary keys are not stored anywhere, even if an attacker gains access to a party's private key, they cannot use it to decrypt past communication sessions which used different temporary keys.

One popular protocol that uses forward secrecy is the Diffie-Hellman key exchange, which allows two parties to establish a shared secret key without transmitting it in plain text. The temporary keys used in the Diffie-Hellman key exchange are unique for each session, ensuring that even if an attacker gains access to one of the parties' private keys, they cannot use it to decrypt past communication sessions.

Forward secrecy provides an additional layer of security to cryptographic protocols, as it ensures that past communications remain secure even in the event of a future key compromise.

I do need something like that in SeRCH...

what is blockchain financial interest for data savers? You can get some money from users to register their public key. It is better to apply blockchain on the etherium.

According to Wikipedia, A replay attack (also known as a repeat attack or playback attack) is a form of network attack in which valid data transmission is maliciously or fraudulently repeated or delayed. This is carried out either by the originator or by an adversary who intercepts the data and re-transmits it, possibly as part of a spoofing attack by IP packet substitution. This is one of the lower-tier versions of a man-in-the-middle attack. Replay attacks are usually passive in nature.

Another way of describing such an attack is: "an attack on a security protocol using a replay of messages from a different context into the intended (or original and expected) context, thereby fooling the honest participant(s) into thinking they have successfully completed the protocol run."

Preventing this attack is also needed.

For better referencing in my case, the result of openssl_error_string() is:
error:02001003:system library:fopen:No such processCant create session private key!

However, it's easy to fix by providing a path to openssl.conf manually like this:

if ($_ENV["OPENSSL_CONF"]){
    $this->private_key = openssl_pkey_new([
    "config" => $_ENV["OPENSSL_CONF"] //path to openssl.cnf
    ]);
}

So the final block could be like this:

$key_options = [
    "private_key_bits" => 2048,
    "private_key_type" => OPENSSL_KEYTYPE_RSA,
];

if ($_ENV["OPENSSL_CONF"]) $key_options["config"] = $_ENV["OPENSSL_CONF"]; //path to openssl.cnf

$this->private_key = openssl_pkey_new($key_options);
if (!$this->private_key) {
    print_r(openssl_error_string());
    die("Cant create session key pairs!");
}

if (!openssl_pkey_export($this->private_key, $private_key_pem, null, $key_options)){
    print_r(openssl_error_string());
    die("Cant create session key pairs!");
}

Greetings folks ,

Suppose we have built a system that uses asymmetric cryptography , and we have data exchange between clients (a chat system to be precise) .

The encryption is peer-to-peer between clients. The scenario is like:

Suppose Alice is going to send Bob a message, the message is encrypted with her own private-key (signature making), then the message will be re-encrypted with Bob's public-key (confidentiality), and then it'll be merged with plain message hash (message authentication) ,then it'll be sent over the network.

We have a central server which does all of the data transmissions.

Everything looks fine...

but we have a major problem!

How do we make sure the server doesn't do a Man In The Middle attack?!

Suppose it has malicious intentions or it's been hijacked, for the sake of argument...

There's a great opportunity for the server to lie about public-keys to both Alice and Bob!

The server tells Alice that Bob's public-key is 1234, but in truth it's not! 1234 is one of the key-pairs that the server generated for itself!

So Alice will encrypt with the server's key and not Bob's.
The result will be obvious!

The server implemented a MITM attack , and now is able to sniff and spoof messages!

How can we prevent that?

UPDATE:

I am aware of the Certificate Chain and how SSL solved that problem.
What I had in my mind , was to provide another solution (since we have a server handling communications, Certificate Chain is not really helpful).
I'm sure we can come up with another idea that can solve this...

What is the standard value of IV in AES?

I know that setting it to a specific value is kinda wrong and is has to be set randomly due some security reason.
This issue will discuss that reason and look for an appropriate approach.