Cryptography Implementation Discussion

[$trinick]

By the way, is there a particular reason you're using such a roundabout way of modulus?

What's wrong with %a % %b?

Ah, I realized you'll be dealing with huge numbers.

[Ad Bot]

[Greek2me]

they can call a function like onMathFunctionDone(%output, %phase); then just package that function to do stuff, where %phase is something like "keyGenPrimeCheck"

it's a completely different, almost totally roundabout way of thinking, but it can be done.

That seems unnecessarily complicated/convoluted. Those benchmarks seemed to show that the math functions are relatively fast. As long as you break the actual encryption algorithm into chunks so that you aren't performing too many math functions at once, you'll be fine.

[Ipquarx]

Division is still horridly slow imo and I want to improve it.

I've been fiddling around with things and I've found a formula that should work well in theory, but I have no idea how well it'll play out in practice:



where

(please mentally replace k with y, as I'm a derp)

I have no idea why it works, but it works. (If anyone has any insights as to why this works, I'm all ears)

EDIT: typed the formulas wrong. Silly me.

[Lugnut]

That seems unnecessarily complicated/convoluted. Those benchmarks seemed to show that the math functions are relatively fast. As long as you break the actual encryption algorithm into chunks so that you aren't performing too many math functions at once, you'll be fine.

you're right, we probably shouldn't waste time trying to do something that might not need to be done

[Lugnut]

by the scale of all the stuff made so far for this project, i just pushed a huge update with untested incomplete diffie hellman and otp stuff.

i also commented a lot, so read those and work with them please

[Lugnut]

NIST curves are apparently vulnerable somehow, but no one knows how (?)

oops

http://www.safecurves.cr.yp.to/rigid.html

either we go with one with questionable security that we have on hand already, or we go looking around for other curves (which appear to be much larger?)

or we just use the ones with questionable security for now until we get an understanding of the algorithm as a whole

Edit just the whole site in general damn
http://safecurves.cr.yp.to

Looks like I've got some reading to do. I don't think I'll actually start real work on ECC until Christmas break.

[Lugnut]

Just found a book that'll help tremendously: Cryptography: An Introduction, by Nigel Smart. There's a free pdf from www.cs.umd.edu which is the computer science department of the university of Maryland. I am about 90% sure it's legal. I mean, the university that sponsored the guy that made the book...? That's legit, right?

[Ipquarx]

Well er, could you link to it?

[Lugnut]

Not really because forget Google's link obfuscation system

Also mobile.

I'll link it later

[Greek2me]

NIST curves are apparently vulnerable somehow, but no one knows how (?)

Are you referring to the backdoor that NSA introduced? If yes, then we don't really need to worry too much (for our purposes).

[Lugnut]

the idea here is to make it as effective and secure that three amateur cryptographers can

if we didn't give a stuff about security, or even just a little bit of stuffs, we could just use diffie hellman and be all "we use diffie hellman with all integers, because forget prime numbers" which would obviously be bad because
well
primes are critical

basically what i'm saying is that i feel we have to go all the way or nowhere at all with this, anything else is just doing it wrong.


here's the book: www.cs.umd.edu/~waa/414-F11/IntroToCrypto.pdf‎
it's a third edition, in the second edition forward he writes that "the book didn't sell well so I made it free publicly online" (paraphrasing) so yes, this is legal.

[Lugnut]

made a new repo where I'll focus on implementing diffie-hellman key exchange with OTP cipher

mainly so i can feel good about myself for getting something done while i agonize a little bit about those goddamn curves

https://github.com/Tungul/Client_DiffieHellman
made port's rand.cs use arbitrary precision. untested, as usual with me (i do that a lot, making code, never testing it (see: event_daycycles))

[Port]

made port's rand.cs use arbitrary precision. untested, as usual with me (i do that a lot, making code, never testing it (see: event_daycycles))

if you're gonna use that + with bignum libraries then you might as well implement proper BSD-style linear congruential generators instead of the tiny version it uses

make the LCG function do this instead:
return (%state * 1103515245 + 12345) % 2147483648;

[Lugnut]

Are those arbitrary numbers? Wouldn't it be better to generate them randomly for even more randomness?

Edit: "[Linear congruential generators] should also not be used for cryptographic applications;"

Goddamn.


I'm probably totally wrong, but I think someone could brute force the OTP through a linear congruential generator.

Ip, our friend nigel touches on division algorithms in chapter 15, page 244 (255 on the pdf)

[Greek2me]

here's the book: www.cs.umd.edu/~waa/414-F11/IntroToCrypto.pdf‎
it's a third edition, in the second edition forward he writes that "the book didn't sell well so I made it free publicly online" (paraphrasing) so yes, this is legal.

Thanks, I'll read some when I get home.

Edit: "[Linear congruential generators] should also not be used for cryptographic applications;"

Goddamn.

Can we just get random mouse movement or something?