ASLR

[deltarho[1859]]

@caseih

Thanks for that.

In a nutshell you are saying if you are a cryptographer/cryptanalyst then you probably don't need DEP/ASLR but since I am neither then I probably do.

It is time to move on, we have drifted well off topic now.

[badidea]

@badidea

At some point during the package encryption phase a plaintext 'password' is generated, 0.72ms later it ceases to exist in plaintext form, it is encrypted using the receiver's public RSA key. At some point during the package decryption phase the ciphertext 'password' is decrypted using the receiver's private RSA key, 0.0038ms later it ceases to exist in plaintext form.

Neither the sender nor the receiver ever see the plaintext 'password'. The plaintext 'password' is a random 128-bit binary key which is unlikely to be ever used again.

If you can come up something better than that let me know and I will gladly use it.

Previous post can be ignored. I misread the remark. Thought it was about plain text files.
Having the password in plain text in memory for a short time is probably unavoidable.
You do overwrite the memory location after use, I assume.
Maybe you could also vary the location in memory yourself a bit. E.g. at a random position within a 1000 bytes allocated?

[deltarho[1859]]

You do overwrite the memory location after use, I assume.

CryptProtectMemory using CRYPTPROTECTMEMORY_SAME_PROCESS, and we don't have to worry about it being paged out. Of course, we don't decrypt.

Maybe you could also vary the location in memory yourself a bit. E.g. at a random position within a 1000 bytes allocated?

Good idea, a bit of obfuscation doesn't do any harm.

[deltarho[1859]]

I have been busy for a few days but came back to consider

Maybe you could also vary the location in memory yourself a bit. E.g. at a random position within a 1000 bytes allocated?

I have a function, used in Encrypternet, which employs CBC-MAC AES 128 on a 8KB random buffer, a random IV (Initialization Vector), and a random AES key taking the last block of ciphertext (128 bits) as our random 'password'. The principle is to generate a random 128-bit multiplicative prediction resistant key. The idea was got from an Intel blog for improving RdRand for those who did not have RdSeed; RdRand is only additive prediction resistant.

Instead of one pass of the function it gets passed 64 times to give a 1KB buffer of multiplicative prediction resistance. There are 1009 possible contiguous blocks of 128 bits that we can choose from so one is chosen randomly.

The Windows APIs for encryption/decryption couldn't care less whether our 'password' is an array of bytes, a dynamic string, a fixed length string or whatever - it simply wants a pointer to a buffer and its length. The pointer is, of course, the pointer to the 1KB buffer start and the random offset to our 'password'. With decryption, we simply create a 1KB buffer of random bytes and randomly overlay with our decrypted 'password' straight into the buffer. Here too we have the pointer to the buffer start and the random offset.

Now bearing in mind, on encryption, we are encrypting a 8KB buffer 64 times to build out 1KB buffer of multiplicative prediction resistant bytes one would think that I had time to make a cup of tea. In fact, on my machine, I have the address to the plaintext 'password' in about 1.3 milliseconds. Considering the short shelf life of the plaintext 'password', mentioned above, an attacker is going to be hard-pressed, to say the least, on getting their hands on it.

You do overwrite the memory location after use, I assume.

That is easy - the 1KB buffer, on encryption or decryption, is simply populated with random bytes with BCryptGenRandom. That is very swift - just over 5 microseconds.

Thanks, badidea. .

[jj2007]

some year ago don't remember in which forum, Mike Lobanovsky mentioned that mingw did not produce proper dll's, something about a table, I wonder if mingw is producing executables that are not 100% Windows compliant?

I just learned that Mike passed away in January. RIP.