logistics of hashing messages.

  • (2 Pages)
  • +
  • 1
  • 2

23 Replies - 1184 Views - Last Post: 29 January 2020 - 04:58 AM Rate Topic: -----

#16 astonecipher   User is offline

  • Senior Systems Engineer
  • member icon

Reputation: 3069
  • View blog
  • Posts: 11,775
  • Joined: 03-December 12

Re: logistics of hashing messages.

Posted 28 January 2020 - 10:57 AM

https://www.php.net/...lic-encrypt.php
https://www.php.net/...ate-decrypt.php


You encrypt using the public key and decrypt using the private keys.
Was This Post Helpful? 0
  • +
  • -

#17 Bobby_Bubbles   User is offline

  • D.I.C Regular

Reputation: 1
  • View blog
  • Posts: 339
  • Joined: 13-March 18

Re: logistics of hashing messages.

Posted 28 January 2020 - 11:17 AM

sorry mean the azure vault i know how to encrypt/decrypt.
Was This Post Helpful? 0
  • +
  • -

#18 astonecipher   User is offline

  • Senior Systems Engineer
  • member icon

Reputation: 3069
  • View blog
  • Posts: 11,775
  • Joined: 03-December 12

Re: logistics of hashing messages.

Posted 28 January 2020 - 11:30 AM

Not sure what you are asking for in that case. Just go to the Azure site and look at the key vault.
Was This Post Helpful? 0
  • +
  • -

#19 Bobby_Bubbles   User is offline

  • D.I.C Regular

Reputation: 1
  • View blog
  • Posts: 339
  • Joined: 13-March 18

Re: logistics of hashing messages.

Posted 28 January 2020 - 05:43 PM

i uno....its made by microsoft. Isnt this just essentially giving microsoft your keys?

This post has been edited by Bobby_Bubbles: 28 January 2020 - 05:43 PM

Was This Post Helpful? 0
  • +
  • -

#20 ArtificialSoldier   User is offline

  • D.I.C Lover
  • member icon

Reputation: 2494
  • View blog
  • Posts: 7,551
  • Joined: 15-January 14

Re: logistics of hashing messages.

Posted 28 January 2020 - 05:50 PM

So you don't want to store your keys on your server, and you don't want to give them to anyone else? You need Shroedinger's encryption keys.

And you also need to spend some time thinking about whether or not a service that bills itself as only being secure key storage would do anything with their customers' keys. I mean, if their entire service relies on trust, and they know that, and their customers know that, are they going to sell your keys or give them away or something like that? If you're worried about security, if you can't trust a 44 year old company with one or two experiences involving security under their belt in that time, with $125 billion in revenue to hire people who specialize in security at this point, then who are you going to trust? A startup? Google, who makes their money from advertising and tracking data? Who else? You can look into Amazon if you want, maybe they have something if you trust Jeff Bezos with your keys over Microsoft.

Otherwise, you need to develop a specific list of requirements and then ask about that.
Was This Post Helpful? 1
  • +
  • -

#21 Bobby_Bubbles   User is offline

  • D.I.C Regular

Reputation: 1
  • View blog
  • Posts: 339
  • Joined: 13-March 18

Re: logistics of hashing messages.

Posted 28 January 2020 - 06:11 PM

i was thinking on another server i control. i got another rpi 4 available. i was maybe considering storing it on that server. Hmm......but if someone gained access and got the link then its futile...

Ugh. I get the sense im being way too paranoid....i mean is it? If someone gets control of the server is that the end? really?
Was This Post Helpful? 0
  • +
  • -

#22 CTphpnwb   User is offline

  • D.I.C Lover
  • member icon

Reputation: 3826
  • View blog
  • Posts: 13,946
  • Joined: 08-August 08

Re: logistics of hashing messages.

Posted 28 January 2020 - 06:18 PM

Your problem is that like many beginners you want a specific answer to a vague question. There is a reason the rules state that you need to post code.

If you want to write secure code, you need to first write code. Then you need to have it reviewed by people who know how to write code. That's what this forum is for.

This post has been edited by CTphpnwb: 28 January 2020 - 06:18 PM

Was This Post Helpful? 0
  • +
  • -

#23 astonecipher   User is offline

  • Senior Systems Engineer
  • member icon

Reputation: 3069
  • View blog
  • Posts: 11,775
  • Joined: 03-December 12

Re: logistics of hashing messages.

Posted 28 January 2020 - 07:41 PM

I don’t know what data you are trying to hide, and it really doesn’t matter. My company uses it and many more do or it wouldn’t exist. And whatever you are encrypting is way less damning and way less desired than the data stored by large companies, just saying.
Was This Post Helpful? 0
  • +
  • -

#24 Ornstein   User is offline

  • D.I.C Head

Reputation: 32
  • View blog
  • Posts: 64
  • Joined: 13-May 15

Re: logistics of hashing messages.

Posted 29 January 2020 - 04:58 AM

*bangs head on desk*

If I'm understanding correctly, what you're hoping for is a browser-based* messaging system, where people can talk to each other securely - and where the server is responsible for everything - and where the users themselves don't have any responsibility - but where no one server can be a single point of failure? You ask the impossible. :P

* I base this assumption on your earlier PHP code having HTML output.

Here's a quick example of the closest you could possibly get, given your requirements:

Server A stores private and public keys - and also stores hashes/checksums of ciphertexts (or uses some other mechanism of verifying ciphertexts; this will make more sense later.).

(The private key should possibly be encrypted; I'll expand on this later)

Server B stores public keys, stores encrypted messages and sends encrypted data between users.

Server C hosts the client HTML/JS - and the HTML/JS is responsible for interacting with the two servers (e.g. using AJAX), generating keys, doing the encryption/decryption, etc.

Both servers A and B store a copy of the user's credentials* - and the client (from server C) will request public keys for a given user from both servers A and B simultaneously (to ensure both keys are the same i.e. no one server can give a false public key for which the attacker has the private key).

* This may seem redundant, but having one central authentication server would itself be a single point of failure.

You may also want to ensure the admin credentials, software, configurations, etc. are different between all 3 servers - because having identical attack vectors on all servers obviously defeats the point.

Either way, you still have the (unavoidable, given your particular requirements) problem that server C being compromised - or both servers A and B being compromised at the same time - is bad news.

So the general workflow for each stage might look like this:

1. When a user registers...
- They download the HTML/JS client from server C
- They fill out the registration form
- Client JS hashes their password
- Client generates key pairs
- Client registers user's credentials and both keys with server A
- Client registers user's credentials and public key with server B

2. When a user logs in...
- They download the HTML/JS client from C
- They type their password
- Client JS hashes the password
- Client authenticates with server A to download their private and public keys
- Client authenticates with server B to download encrypted data and their own public key
- Client ensures both public keys match
- Client decrypts data

3. To establish contact between two people...
- User enters the username (or whatever identifier you're using)
- Client looks up the public key for given user from both A and B
- If public keys differ, client gives a warning.
- If public keys match, messages can be sent.

4. When sending a message...
- User enters message to send
- Client encrypts using recipient's public key
- Client sends encrypted message to server B
- Client hashes/other the encrypted message
- Client sends the hash/whatever to server A
- Server B sends encrypted message to recipient

(In addition, if you want the sender to have their own copy of the sent message...)

- Client encrypts message using sender's public key
- Client sends this encrypted message to server B
- Client hashes/other the encrypted message
- Client sends the hash/whatever to server A

5. When a message is received...
- Client receives encrypted data from server B
- Client requests the related hash/checksum/whatever from server A
- Client verifies the authenticity of the ciphertext*
- If the authenticity is confirmed, the client decrypts the message.

* This is to ensure the ciphertext hasn't been tampered with e.g. an attacker in control of server B hasn't used the public key to create their own message.

In the above configuration, server A being compromised means an attacker has keys, but no data to decrypt. Server B being compromised means the attacker has access to encrypted data, but no keys with which to decrypt. Neither server A nor B alone can play MITM by tampering with data because the client will verify data from both servers. Server C being compromised means the attacker has no immediate access to anything, but can modify the client to enable them to access a user's data when that user next logs in or a new user registers, etc. (In this case, server C is still technically the "one point of failure")

You could add additional layers of security e.g. by having the private key stored on server A be encrypted using a key derived from the user's password - and then the client can decrypt the encrypted private key on login (or whatever). You may also want to have a mechanism for verifying the authenticity of the private key given by server A, similar to the mechanism used for verifying cipher texts from server B (e.g. hashes and such), but that's probably not important.

Pretty much every other required improvement involves placing more responsibility on the user and/or using other communication channels - whether that's trusting them to keep their own private key somewhere safe, using SMS or email (or scanning QR codes or something) to facilitate verifying the identity/authenticity of both parties, having the user verify the authenticity of the client software (e.g. to detect tampering) before using it, etc.

I could probably go on, but I'll let you digest this first.

(In any case, I'm worried this talk of Azure Key Vault could be a bit distracting. It could probably be used as part of the whole process, but I don't think it's a magic cure for any of the architectural problems by itself)
Was This Post Helpful? 0
  • +
  • -

  • (2 Pages)
  • +
  • 1
  • 2