Author Topic: Cryptography Implementation Discussion  (Read 18441 times)

You can still tell packets apart. Find the packets to and from random.org. There's your private key.
You can use pretty much any packet sniffer to do this. But again, that would require access to not only transmissions between parties, but also between parties and outside sources.

by your definition:

bob > eve > alice = bad, eve can hear
but
bob > tom > alice = good, leaves eve out of the loop because cmmunications are not 'directly between bob and alice'

eve is assumed to have full knowledge of all public data exchanged between all parties. this is why crypto is important - from public data comes private data

I'm not saying it's a good idea. I agree that we need to generate our own numbers.

EDIT: if someone could be so kind as to implement The first function in this snippet of code using my library I would quite appreciate it as I'm quite busy at the moment. That code tests a number to be a prime with 1/4k margin of error where k is the number of iterations.
« Last Edit: November 22, 2013, 08:55:13 PM by Ipquarx »

You can still tell packets apart. Find the packets to and from random.org. There's your private key.

What if that person uses random.org for other things regularly, and, to make matters worse, you may not have access to the complete history of packets sent and received?

What if that person uses random.org for other things regularly, and, to make matters worse, you may not have access to the complete history of packets sent and received?

Most people don't use that site, and it's still not ideal.

I made a bunch of optimizations to multiplication and it's now shorter and in cases of larger numbers, 2x+ the previous speed. This is good.

I got bored so I decided to run a prime number generator because the list of prime numbers up to the one with 10,000,000 digits was formated like stuff, so Im gonna generate as many of my own that I can and I'll post here if you guys want.

UPDAT:
Take some thousand primes:
http://hastebin.com/waqawowoqa.txt
« Last Edit: December 04, 2013, 09:37:39 PM by 0xBRIANSMITH »

10,000,000 digits was formated like stuff,
it was one per line..?

i too have a sieve of eratsones so like if we need more primes that isn't a problem..

I managed to speed up the classic multiplication by a factor of ~1.8. Multiplying two ECC-sized numbers now only takes a mere 20ms!

For those of you actually interested in it; I used long multiplication in groups of 3 digits.

Also guys, for ECC we don't need to generate random primes (at least as far as I know) The prime is part of the curve specification.
Public key: starting point
Private key: number of point additions
« Last Edit: December 06, 2013, 08:42:47 PM by Ipquarx »

Well I've been working hard and I've managed to make some major speedups and progress; I now have modular addition, subtraction, and multiplication working.

On top of that, integer addition and subtraction are now ~5x as fast, and I've fixed a couple bugs.

That means that adding/subtracting two ECC-sized numbers now takes just over a tenth of a millisecond.

I'll be pushing changes in a few moments.

I just need to get integer division working 100%, and then I can implement modular division. Once that's done I can get straight to implementing ECC point addition and doubling. If anyone's willing to help it would be greatly appreciated...
« Last Edit: December 11, 2013, 06:06:04 PM by Ipquarx »

Nice work. Once finals are over I'll be able to contribute.

Now that I know you can fully use numbers of up to 9 digits, I managed to speed up base number multiplication by 2x once again. However that doesn't really matter for our purposes because modular multiplication is what we need and the two aren't related in the slightest.

Once I actually get mod multiplication actually WORKING then I'll start on making it faster... I'm having some issues with mod addition.

"oh i made super big numbers do their thing in a bajillionth of a second"

"no biggie"


jesus christ

"oh i made super big numbers do their thing in a bajillionth of a second"

"no biggie"


jesus christ
Hah, just you wait. I still have a lot of things to change. By the way, ECC crypto WILL happen. It's just a matter of time before the library is fit and ready for implementing it.

If I had to estimate how long it would take async with no major lag to do an ECC encryption, I'd say maybe 7-10 on a mid-range computer. Depends on how well we split up the work.

Speaking of, it would be really helpful for someone to devise a way to create/manage async tasks of this nature.
« Last Edit: December 14, 2013, 06:32:36 PM by Ipquarx »