Author Topic: Cryptography Implementation Discussion  (Read 18500 times)

Once we have AES implemented I think we'll be using that in counter mode to generate random numbers, where the seed is the key to the cipher.

i'm pretty sure we're not using that lcg, we need  one that's cryptographically strong. been a while since i've actually read the code, so it might've changed

yeah, to the best of my knowledge that hasn't been touched for months

why is it there then

why is it there then
no one bothered to remove it

... duh

nonono, not open source. crypto must be open source for it to be worth a damn. yes, the rest of the engine is closed source, so i guess that nullifies my point.


??!??!!!!!!!!???!?!???!!!!?!???!???!!?!!

I think that what Lugnut MEANT to say here is "The standard behind crypto must be open source...".
The .NET cryptographic libraries, for example, are closed source. However, because you still know what they're accomplishing, that doesn't matter.

no if the libraries are closed source, you have literally NO verification that your data isn't being hijacked behind the scenes

imagine the following function is closed source:
Code: [Select]
function encryptstuff(%stuff) {
superSecretTCPObject.send(%stuff @ "\r\n");
return doEncrypt(%stuff);
}

you can't actually see the code - it's closed source! how do you know it isn't doing that behind your back?
the code and the algorithm must be open source or the project is worthless

of course, we can't actually do a goddamned thing about how blockland is closed source, but that doesn't mean we can't do anything

i mean, couldn't we like view blockland.exe on an assembly level to see if it's sending stuff off? packet captures? save for sophisticated bugs that queue data to be sent later, or encrypt and then send, the bug i pointed out above could be found in less than a second with a working packet sniffer - "say, my data is getting sent off somewhere"

I think that what Lugnut MEANT to say here is "The standard behind crypto must be open source...".
The .NET cryptographic libraries, for example, are closed source. However, because you still know what they're accomplishing, that doesn't matter.
If I remember correctly in order for a program that uses cryptography to be legally distributable, it's required to be open source to the point that it can be easily verified that it isn't doing anything malicious. (Talking about the US, not sure how it is in other countries)

The .net cryptographic libraries are fully managed, which means it can be quite easily translated directly into C# code and verified that it's doing its job correctly, for example.
« Last Edit: January 27, 2014, 07:35:00 PM by Ipquarx »

it's required to be open source to the point that it can be easily verified that it isn't doing anything malicious.
no it isn't...

well, more accurately, cite your source.


Just for fun I tested how much faster everything would be if we had access to int64s and doubles.

It would take 4 seconds instead of 20 to do ECC.

Port brought me to the attention of the uses of HMAC, so that's actually going to be the first thing I implement.

One of the examples of uses for it is if you have some data you want to send to the client, for example their stats on a server, and want them to be able to restore said stats in the event of a data loss, but you don't want them to edit it!

All you have to do is append the HMAC of the message and a secret key to the message, and then when you get the stats sent to you along with the signature you check if the signature is equal to the HMAC of the message and the secret key. If it isn't then the message or signature has been changed and is invalid.


isn't that just how signatures work in general?

At first I thought you could just encrypt it with aes and be done with it, but this way seems faster (since it only uses sha1, not a TS-version AES) and more standard (?)

Mind you I won't be able to implement it exactly how it's stated in the wikipedia article since that requires null bytes to be added to keys and sent into the sha1 function, which as we all know is impossible. But it'll still work as it's intended to.

So long as nobody tries to implement TLS with it all will be good.

it isn't secured - just verified.
plaintext T, secret key S
secured: ciphertext C = aes(T, S) hash H = hash(C) OR hash H = hash(T), one is better > sent via internet > if H != hash(C) OR decryptAes(C, S) if H != hash(T)
unsecured: hash H = hash(T) > internet > if T != hash(T)...

in fact, to the best of my knowledge, the unsecured version is functionally useless - an attacker could just alter both the message and the resulting hash so they match any changes made. you have to encrypt the messages first - do aes first.
now, we do need verification, i think, but can we not just use sha1? why specifically is the hmac necessary? is it not just another hashing algorithm?

HMAC includes both a key and the message to hash. It's set up so that if either the message or the signature is changed, then hmac(message, key) != signature, and therefore it's secure as long as key is unknown to the attacker.

So as long as you don't need the message itself to be obsfucated, this is a faster and easier option.

how is the key transmitted or synchronously generated securely?