|
|
 Up |
|
|
  |
Author: TCTC
Date: Nov 13, 2006 21:57
> E.g., on the CD, there is a directory called "fastfile". Inside that
> directory, there are a bunch of files like "Tex1.FFL", "Tex2.FFL", etc.
|
| |
|
| |
no comments
|
|
|
Author: TCTC
Date: Nov 13, 2006 21:48
> TC wrote:
>> But how do you know the length of each file *inside the installer exe*?
>
> Ah, I see the confusion. They are not *inside* an "installer exe".
> There is a "setup.exe" executable, but there are also directories with
> files, layed out exactly as they are when installed.
Ok, I see now.
It might be interesting to see if you can find another installation CD,
& install it on another PC. Are the "input" files identical on the two
CDs, and are the "output" files identical on the two PCs? Perhaps that
would shed some light on it.
I also found a reference to someone else's linux port of this game. Ask
Mr Google for more information :-)
HTH,
TC (MVP MSAccess)
http://tc2.atspace.com
|
| |
|
| |
no comments
|
|
|
Author: Tom St DenisTom St Denis
Date: Nov 13, 2006 20:35
Valgrind found an overflow in the code called by mp_reduce().
Fortunately, due to the padding it hasn't been exploited in the wild.
Fixed as part of LTM 0.40 and will be released on Friday.
[BTW: mm, this is the sort of stuff I worry about instead of
microoptimization, flamewar=on]
Patch...
RCS file: /cvs/libtom/libtommath/bn_fast_s_mp_mul_high_digs.c,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -d -r1.4 -r1.5
--- bn_fast_s_mp_mul_high_digs.c 31 Mar 2006 14:18:44 -0000
1.4
+++ bn_fast_s_mp_mul_high_digs.c 14 Nov 2006 03:46:25 -0000
1.5
@@ -78,7 +78,7 @@
register mp_digit *tmpc;
|
| Show full article (1.06Kb) |
|
45 Comments |
|
|
Author: Antony ClementsAntony Clements
Date: Nov 13, 2006 15:07
> You are worrying about the wrong things, you have generated a pointlessly
> comple system, that does nothing, it would be far simpler, far more
> effective, far more secure to harvest a truly random nonce, and shove it
> along with the passphrase (not a 4-byte number, a real passphrase) into
> SHA-256.
ok thanks for that Joe
|
| |
|
no comments
|
|
|
|
|
|
Author: Joseph AshwoodJoseph Ashwood
Date: Nov 13, 2006 12:54
"Antony Clements" optusnet.com.au> wrote in message
news:45585e15$0$11968$afc38c87@news.optusnet.com.au...
I'll assume you mean mod not multiply, multiply doesn't make sense here. If
you did mean multiply, the answer is very simply, no.
> int x = 0;
>
> {
> k = rnd() * 2 ^32;
> k = k xor date;
non-entropic, it is safe to assume the attacker knows the date
> k = k xor time;
Depending on precision, and the amount of seperation between runs, this may
have as much as much as 5 bits of entropy. But none of this matters because:
> k = kci(k);
is only a 32-bit number, so if kci is a good simulation of a random oracle
it will collide every 2^16.
Your maximum entropy at this point is 32-bits
|
| Show full article (1.93Kb) |
|
no comments
|
|
|
Author: xmathxmath
Date: Nov 13, 2006 10:33
Mike Amling wrote:
> xmath wrote:
>> To avoid this making local vote-buying easier, it shouldn't help to
>> prove a voter's vote after the fact. This is easily accomplished by
>> making sure the ballot sheets are easily forged.
>
> That makes Byron the buyer's task harder, and Sabu's task easier.
Partially mitigated by giving poll stations hard to forge ballots (or
augment them with a signature or other mark of authenticity by the poll
worker), while giving absentee voters easy to forge ones but the
ability to check and complain early.
I think this style is particularly well suited for absentee voters:
http://cds.xs4all.nl:8081/punch/splitballot2.png
The ballot sheet (a simple black-on-white printed list) is easy to
forge. They only need to send in the card, or maybe even send in the
information by phone (using a unique per-voter authentication code as a
substitute for a signature).
|
| Show full article (1.47Kb) |
|
1 Comment |
|
|
|
|
|
Author: sorceror171sorceror171
Date: Nov 13, 2006 09:59
TC wrote:
>> Because they are *precisely* the same length as the files that are
>> eventually stored on the hard drive, but contain different data. I
>> should have mentioned that before.
>
> But how do you know the length of each file *inside the installer exe*?
Ah, I see the confusion. They are not *inside* an "installer exe".
There is a "setup.exe" executable, but there are also directories with
files, layed out exactly as they are when installed. I should have made
that clear before.
E.g., on the CD, there is a directory called "fastfile". Inside that
directory, there are a bunch of files like "Tex1.FFL", "Tex2.FFL", etc.
Here's a series of commands:
cd /media/cdrom/fastfile
ls -l Tex1.FFL
-r-xr-xr-x 1 sorceror sorceror 375580 2000-02-08 09:00 Tex1.FFL
|
| Show full article (2.83Kb) |
|
no comments
|
|
|
|
|
|
Author: xmathxmath
Date: Nov 13, 2006 09:48
> Apparently a drill is a fancy piece of equipment? Drilling holes in
> paper (especially stacks thereof) is not expensive; computerized
> industrial drilling technology is mature, and Chaum has already
> designed the process and demonstrated it can be done for pennies a
> ballot. I'd be happy to talk more about the Punchscan ballot production
> process, since a lot of thought has gone into it. However perhaps it's
> best saved for the alt.paper forum. :-)
Punching holes isn't the only option. I can also imagine solutions
involving carbon-copy/NCR paper. If you don't have too many
races/options you can even do it entirely single-sheet, like this:
http://cds.xs4all.nl:8081/punch/splitballot.png
This has the downside that all circles must be in a single row (though
you can still use the backside for one or more other races).
As for making copies... I just realized it's probably more convenient
to have the poll worker simply sign (or otherwise mark as "genuine")
the voter's receipt, rather than keep authentic copies and dig through
them in case of a voter complaint of misrecording.
- xmath
|
| |
|
1 Comment |
|
|
|
|
|
|
