At 11:39 AM +1000 on 5/24/99, Adrian Sutton wrote:
>> DeRobertis: Well, I guess you'll have to come up with a new password now.
>
>Adrian: It was only a randomly generated one anyway.
>
>> DeRobertis: But _proving_ mathematicians wrong is so much fun!
>
>Adrian: Unless you happen to be the mathematician. :)
>
>Adrian: After reading up on RSA and other cryptography methods even more (I
>must have read over 1000 pages on cryptography so far and still don't fully
>understand it.) I'm beginning to get the impression that we cannot securely
>encrypt passwords while having the source code freely available.
Read some more. You'll find that security by secrecy of algorithm is not secure. One
reason is that no such thing exists once the stack is distributable: I can open it in
BBEdit. If it's an xThing, I can disassemble it.
real security depends on a near non-rersable algorithm.
>
>Adrian: I say this because 1) We need to use numbers larger than HC can
>deal with (100 digits or more) and
That's why we should go to C++. Even an xThing would work. I'd suggest an algorithm
like this:
Each of us generates two 2048-bit numbers. That's not hard at all.
Call them "a" and "b".
Each of us sends the product of a and b (call that "ab") to the server.
Each of us stores a and b. Whenever one needs to authenticate, he
would send an a and a b to the server. The server multiplies and then
compares.
The only way to crack ab is to factor a 4096-bit value. And that is not possible to
the best of anyone's knowledge with today's computers.
We could get away with a and b being far less than 2048 bits, btw.
>2) we need to add a few random numbers to
>the start or the end of the encrypted password so that encrypting the same
>text doesn't give the same answer unless you know how many digits to ignore
>(which everyone would because the source code is public). Hence we need a
>new way to determine if a vote should be counted.
A) Any reasonably competant programmer could guess-and-check at ignored digits.
B) We don't need ignored digits. See above.
>
>Adrian: I would tend to look towards some kind of email verification that
>is sent to the member who supposedly voted alerting them that they have
>voted (if it wasn't them we can do something about it), but we also need
>some kind of identification scheme before this message is sent. Otherwise
>we could be swamped with emails when we haven't voted and have to keep going
>back and changing things. Perhaps a password system like we have now, but
>somehow preventing access to the password file to be downloaded or viewed.
We should certainly have email confirmation. I doubt we will very much need it with
the system above, though.
>
>> The source code can be gotten at <http://www.erols.com/derobert/break.sit.bin>
>>
>> If you want to use new numbers, you'll have to edit tab.pl. You'll then
>> have to run "perl tab.pl > tab.cp"
>
>Adrian: I've got it and I will try some other numbers, for now though I just
>get the message "MPW does not recognise the command perl" or something to
>that effect. I'd guess this means I need to find perl add-ons for MPW or
>adjust a global variable in MPW somewhere.
Yep. You need to get the perl tool. Alternativly, you could use HyperCard to generate
tab.cp.
tab.cp is basicly a list of:
(i+32)^e MOD k
where i is the item number, ranging from 0 to (256-32).
The perl code is some fancy work to "distribute" the modulous over the exponent. This
avoids having to work with really large numbers.
