Cryptography Implementation Discussion

[Ipquarx]

Well that would work well if I made a function to arbitrarily divide a large number by a single digit number. It's easy enough since all the different cases can just be hardcoded in. Could that also be used for division by larger numbers as well?

Question though: is the & 1 to determine if it's odd?

[Ad Bot]

[Lugnut]

http://en.m.wikipedia.org/wiki/Elliptic_curve_Diffie%E2%80%93Hellman

This looks okay.

It's pure multiplication, no exponentiation. Yes, let's do that first.

[Lugnut]

I don't know, it doesn't look like we even need a modulous function for ECCDH. Am I wrong?

I'm studying the algorithm.

[Ipquarx]

I'm honestly not sure, in the primer you listed it says that you use a prime modulus as the public key.

[Lugnut]

Someone shpuld implement it anyway should we decide to branch out or something.

[Ipquarx]

Personally I think it should be our first one implemented, since all it seems to be is point addition/doubling with a modulus each time. I could have someone translate that python code to TS and I'd derive the code from that.

[Lugnut]

apparently my git wasn't working right on my tablet. probably something to do with adding you guys as contributors, for some reason. idk, fixed now.

i've made a few folders, check them out.


the res(ources) folder contains a pdf from the NIST (national institute of science and technology??) with a bunch of numbers (i think this is described in the pdf) called the "Domain Parameters" of a elliptic curve

To use ECC all parties must agree on all the elements defining the elliptic curve, that is, the domain parameters of the scheme.

this is basically the same thing as the domain you learned about when you learned about rational equations - all the values of x that make a function return real output
these things need to be agreed upon between parties utilizing the cryptosystem, and are all public, safe information (like p in the diffie hellman exchange)

i suggest we try implementing the 192 bit ones first, checking if they work, then the 384 bit ones, just to
A: make sure it actually works
B: the time is not unreasonable, as we are predicting.

once those matters are handled for 192 bits, we'll bump it up to 384, check if B is still true (A shouldn't change) and we will have victory

then we can do a dance or something because we will have done the "impossible"
edit: just tested the exp function from python, in python, >>> exp(51356727897,1959990087654330009997655553**14, 164)
57L

it took it all of about... jesus, i don't know, a hundredth of a second? on my stuffty hardware.

what with all these mathematical shortcuts, i wouldn't be extremely surprised to find RSA possible. not even kidding. like, in raw torquescript with no bignum. it might be possible. and fast, too. well, fast as can be.

[$trinick]

Ai is not cryptography, cryptography is secret numbers. They wouldn't be secret if we told someone else what they were, would they?

Make the PHP script or whatever not record them? Bam, perfectly secret. Unless you're sketch about a man in the middle attack in which case, brother you crazy.

[Lugnut]

Make the PHP script or whatever not record them? Bam, perfectly secret. Unless you're sketch about a man in the middle attack in which case, brother you crazy.

trinick, if you look at the benchmarks greek posted
and if you look at the elliptic curve algorithms (basically multiplication of two numbers, not even exponentiation)
you realize that these are not extremely hard problems, and that yes, even torquestuff can handle good numbers

i'm serious man, this can work

[$trinick]

The issue is that if they're "not extremely hard problems" they can be brute forced very quickly. You're effectively creating a functionally useless algorithm for no other purpose than to entertain yourself, while trying to argue that it has legitimate use.

[Lugnut]

trinick, even the loving NSA says 384 bit ecc crypto is satisfactory for "top secret" documents. (second to last paragraph)

you realize that these are not extremely hard problems

they aren't hard going one way, but they are the other way

trinick, if you can brute force this stuff, send it to some goverment agency (like the nsa) as they'll pay really loving good money for it

[Kalphiter^4]

trinick, even the loving NSA says 384 bit ecc crypto is satisfactory for "top secret" documents. (second to last paragraph)

they aren't hard going one way

trinick, if you can brute force this stuff, send it to some goverment agency (like the nsa) as they'll pay really loving good money for it

He can just leave it in his drafts and they'll read it.

[Ipquarx]

He can just leave it in his drafts and they'll read it.

Kalphiter, you crack me up.

[$trinick]

Tell you what, finish writing your BL crypto implementation and post a public key for me. I guarantee I can brute force it in a reasonable amount of time assuming that your crypto implementation is synchronous and doesn't lag BL.

[Lugnut]

Now you're putting words in our mouth. In the previous topic, we discussed modifying the libraries to be pseudo asynchronous through use of schedules. Of course if we had them small enough to be processed without a stutter, they would be brute forced pretty quick.