A friendly reminder...

Please be sure that you are familiar with the forum rules and guidelines. These are in place to try to maintain a place that we all want to come back to. One specifically I would like to mention is keeping threads on topic. As much as is possible, please do not be afraid to start a new thread if you have a question that shifts even just a little bit in meaning. This will help users searching for solutions, and this will also help a conversation not become confusing to follow.
See more
See less

Encrypternet on the Web

  • Filter
  • Time
  • Show
Clear All
new posts

  • Encrypternet on the Web

    There is a post on Encrypternet that I wrote last year which has had 464 views but only Mike Doty responded so there may not be an interest in the latest version. It has moved on a bit since then and is easier to use. I have been 'badgered' into publishing it on the Web but resisted. I enjoy coding but I don't enjoy messing about with web pages. Some people love it but I don't. Anyway, I finally gave in.

    I have held off making any changes to the engine but have made a change to the efficiency of generating the random 'password'. If you are using the forum version then you will need to decrypt and then encrypt with the new version.

    There are now two versions: 32-bit and 64-bit, not everybody has a 64-bit Windows. Minimum OS required is Windows Vista. The 64-bit is a little faster than the 32-bit when decrypting.

    I have put a copy of the Encrypternet64 folder onto a flash drive/usb stick. My private keys are then not on my system and get loaded automatically. In 'home encryption' mode I simply navigate to a target file and do nothing else: No 'password' required and no navigating for keys.

    I will say no more - the package includes a revised Help file.


  • #2
    Someone contacted me the other day and referred to my Seattle scenario on the website and asked what other uses Encrypternet may have.

    Well, a lot of folks are now working from home nowadays rather than an office. We could have, say, a dozen employees working from home and live hundreds of miles from the office. Some employees could be working in a different country.

    If the office wanted to send some confidential material to one of those employees and vice versa then Encrypternet would be ideal. If Alice, at the office, wanted to send Bob some confidential material then only he could decrypt the package. In turn, only Alice could decrypt Bob's response material. Alice could be just an employee at the office or someone who is designated to send/receive encrypted material.

    I was then asked what would happen if Alice created a package for Bob but sent it to Jack instead. Well, there are 28 error traps in Encrypternet and this mistake would be trapped. Most of the errors would be notified as a position number and a hex of the API error code. The position number tells me where in the source code the error occurred and that with the API error code helps me to fathom out what may have gone wrong.

    If Alice sends Jack a package meant for Bob Jack would be advised that the error occurred at position 20 with an error code of C000000D. C000000D is STATUS_INVALID_PARAMETER which is the worst code we can get given that an API may have, for example, 10 parameters. However, position 20 is about decrypting a password. All the other parameters should be OK as they are system related and not user related.

    So, this is now displayed (in the next version)
    Click image for larger version  Name:	DecryptFailure.jpg Views:	0 Size:	19.5 KB ID:	779532

    Notice that 'may' is used because it may not be the password at fault although that is the most likely reason. If Jack contacted Alice she may say: "Sorry, Jack, I should have sent that to Bob." Alternatively, she may say: "Sorry, Jack, I used someone else's RSA public key - I'll send you a package replacement". If I should be so lucky.

    We could have verification errors where Alice has done things correctly sending work to Bob but he uses the wrong ECDSAPublicKey. That is trapped and we have advised 'Signature verification', 'Signature was not verified'. Bob has another go and realizes he used Jack's key and not Alice's key. However, in this scenario the chances are that Bob only has two ECDSA public keys; his and Alices. Of course, he could have used his own key by mistake in which case he needs to have a lie down in a darkened room. His ECDSA public key needs to be in the Encrypternet folder if he uses home encryption.

    We should not get any private key issues: If they are in the Encrypternet folder they will be loaded automatically otherwise an open file dialog will use their full names as a filter. It is with the public keys that we may have user problems.

    We could be advised the hash of the encrypted data does not match with the given hash. To get to this point the signature would have been verified. It is highly unlikely that we have an encrypted data transmission corruption but that could happen. Whatever the reason the receiver should contact the sender and ask for a package replacement.

    The website now has version which has the 'Password decryption failure' message. I noticed that after returning the timing feature to not just home encryption, for further testing, I forgot to pull it out again. The timing is now restricted to home encryption as was originally intended. <signs of senile decay creeping in here>. There was also a couple of cosmetic changes. No changes have been made to the 'engine'. Unless anyone finds an engine 'bug' then the engine will be treated as 'carved in stone'.

    The only changes made are to Encrypternet32.exe and Encrypternet64.exe. So, pull them out of the new unzipped folder and replace the versions.

    Tip: What do we do if two receivers are called Joe Bloggs and Joe Smith? With an RSA public key, for example, we could use JoeRSAPublicKeyBloggs and JoeRSAPublicKeySmith because the filter accommodates prepend or/and append.