Cryptography-Digest Digest #228, Volume #13 Sun, 26 Nov 00 06:13:00 EST
Contents:
Re: consecuitive Fibonacci Numbers ("G. Orme")
Re: Partial Image Encryption References (Raphael Benedet)
Re: voting through pgp ("Trevor L. Jackson, III")
Cyrptography Digest Archive ? (Mark Harrop)
Re: Cryptogram Newsletter is off the wall? (Vernon Schryver)
Re: My new book "Exploring RANDOMNESS" (Rob Warnock)
Re: hardware RNG's (Tim Tyler)
Re: Cyrptography Digest Archive ? (Richard Heathfield)
----------------------------------------------------------------------------
From: "G. Orme" <[EMAIL PROTECTED]>
Subject: Re: consecuitive Fibonacci Numbers
Date: Sun, 26 Nov 2000 06:47:44 GMT
G. Say there is a sequence a,b,c,d,e,.... If a and b are coprime then a+b=c
must be coprime to both. Since b and c are coprime b+c=d must be coprime to
both, and so on forever.
<[EMAIL PROTECTED]> wrote in message news:8vabeh$ioe$[EMAIL PROTECTED]...
> How can we show that every two consecuitive Fibonacci Numbers are
> coprime.
>
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.
------------------------------
From: Raphael Benedet <[EMAIL PROTECTED]>
Subject: Re: Partial Image Encryption References
Date: Sun, 26 Nov 2000 09:32:14 +0100
Reply-To: [EMAIL PROTECTED]
John Savard wrote:
>
> On Sat, 25 Nov 2000 21:00:09 +0100, Raphael Benedet
> <[EMAIL PROTECTED]> wrote, in part:
>
> >I currently work on my thesis about "Partial Image Encryption". However,
> >I have some difficulties finding good references (either books or
> >papers) about that subject. I've heard of image encryption using
> >space-filling curves, quadtrees, ...
> >Could you recommend me some books, articles, web adresses, ... that
> >could help me?
>
> Mostly, such techniques of image encryption are not taken seriously,
> even if they are of theoretical interest.
>
> Instead, think of techniques of image _compression_, and once the
> digitized image is compressed, encrypt it as you would any other data.
>
> Probably, techniques such as using the Peano curve on images would be
> more likely to be described in works on image compression as well.
>
> John Savard
> http://home.ecn.ab.ca/~jsavard/crypto.htm
At the moment, I work on a jpeg encoder/encrypter where I encrypt the
low frequencies once the quantization has been done and before the
huffman coding so that the image is still perfectly viewable by any jpeg
viewers. The borders, edges, ... (high frequencies) in the images remain
exactly the same while the low frequencies are encrypted.
------------------------------
Date: Sun, 26 Nov 2000 04:20:03 -0500
From: "Trevor L. Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: voting through pgp
David A Molnar wrote:
> Trevor L. Jackson, III <[EMAIL PROTECTED]> wrote:
>
> >> we'd have to make sure that the results didn't leak until
> >> after the close of the polls. This might be difficult.
>
> > IMHO "calling" the election is the expression of an opinion rather than fact.
> > Reporting the votes tallied so far would be reporting facts. If the news
> > media avoided reporting opinions and reported only the facts then their
> > reports would tend to _increase_ the turnout in the precincts still open
> > rather than discouraging it.
>
> OK. I assumed that we would want to keep the voting totals secret until
> after the election is over. You are right to point out that if counting
> is instantaenous, then there is no technical reason why that should be
> so and it may be preferable to have fact over misinformation.
>
> > An active ballot can provide an unambiguous summary display of the
> votes to be > cast. When the voter executes the commit action the votes
> are not subject to > further interpretation by any agency, including the
> voter, election officials, > or courts.
>
> Sounds like a good idea. Of course the active ballot had better damn
> well be bug free...
I suspect this issue can be designed out. Consider that the immediacy of the
feedback allows the _voter_ to be arbiter of whether a bug/glitch/error has
occurred. Of course down-stream processing can still offer opportunities to
"improve" the tally by finding lost ballot boxes.
>
>
> > You probably didn't have elected officials removed from office for election
> > fraud. Florida did. The deposed Mayor of Miami secured a position with a
> > political party as the person responsible for the absentee ballots that he has
> > used to cheat in his election. C.f., a recent post in this ng by Paul Pires.
>
> Wow. We just have the Mob. (*had* the Mob).
>
> I think the point still stands, though -- if people are being turned
> away from the polls or "disqualified" from voting based on bogus
> reasons, the fact that the voting machine is electronic is irrelevant.
Yes. In fact as the automated glitches are suppressed by the gradual perfection of
the automated system the human issues will loom larger.
>
>
> >> * Recounts by machine are less reliable than recounts by
> >> hand.
>
> > What units are you using for reliability? I suspect machine tallies are more
> > repeatable than human tallies. I suspect this repeatability is a foundation
> > for accuracy and thus trust.
>
> Sorry, I should have said "are perceived to be less reliable."
The popular media may believe this, but I do not (I cut my teeth on an 026).
>
> I was also going by figures of 2%-5% error for machine voting which I've
> heard from news reports. This is why candidates (claim) to be asking for
> hand recounts, after all.
Now that's a serious problem. Perhaps I missed the reporting on that issue. But I
_still_ find it hard to believe. I find it easier to believe that someone with a
chainsaw to grind "selected their facts carefully".
>
>
> I agree that repeatability is key. Repeatability strikes me as the
> potential big win for an automated system, as long as there is some kind
> of "hand recount" which can get the same results.
>
> That is, if the counting procedures of the computer system are called
> into question, there must be some "manual" way of re-doing the count.
> Because anything automated can have charges of "tampering" or "bugs"
> mounted against it. So there have to be at least two separate ways of
> counting...and ideally they'll all match.
I believe this auditing process should be part and parcel of the active ballot. For
example, the commit action might print out the interpretation of the ballot _on_ the
ballot. This would allow the voter to confirm that the later interpretations would
match his interpretation. The printout could be in both human readable and machine
readable (bar code) form. This would allow a second set of machines (and/or
software) to verify the integrity of the initial machine count.
I was delighted by the initial design of the MC68000 because it has a special pin
that turns all of the output pins into inputs. One tests an MC68000 with another
MC68000. We should be able to do the same thing with both the active ballot devices
and the hardcopy ballots they generate.
>
>
> > Feedback to the voter that enables the ballot interpretation to occur prior to
> > the voter exiting the voting booth seems to be key in eliminating the voter
> > confusion and ballot interpretation issues.
>
> I like this idea of an active ballot. I think we have to be careful
> though, about two things
>
> * bug-freeness of the active ballot mechanism. resistance to
> corruption. also resistance to misinterpretation. These are
> software engineering, computer security, and user interface
> design problems.
I was thinking of something driven by a PIC. A device with just enough capability
for the ballot software and no room for anything else. Three of these with software
from three independent sources would make it extremely difficult to influence the
actual devices. Of course whatever wire leads to the tally machine also has to be
protected.
>
>
> * the finalize step -- make very sure that people understand
> that it is final. and make sure that it cannot be appealed
> because of "problems with the machine." and also how do we
> know a voter really did finalize a ballot?
This is a simple record keeping operation. Supermarkets do it all the time. The
corrections to voided, doubled, or otherwise questionable ballots, is recorded in
real time in a separate registry by supervisory personnel. It would require perhaps
2-3 supervisors to void an improper ballot. And all such records go into the audit
record.
The "final" action would be for the voter to deposit the hardcopy ballot with the
confirming printout in an official ballot box used only for auditing purposes
(second machine etc.)
I suppose the design rule is to close every open control loop as locally as
possible, and to provide hooks for as many layers of control/audit loops as is
necessary.
>
>
> > Electronic processing might close the temporal gap that attends absentee and
> > overseas ballots. Consider a ballot transport system designed around secure
> > comm protocols that allowed a person to submit their ballot to an out-of-state
> > or overseas polling booth within the normal voting hours on election day. The
> > booth would cryptographically secure the contents of the ballot for immediate
> > delivery to the home-state election counting mechanism. POst offices could
> > offer the facility.
>
> I was thinking about this. For the military it could piggyback on the
> existing communications channels they have...but I don't know anything
> about the suitability of such channels for this purpose. Outside the
> millitary, it's a tossup. Not everywhere has network connectivity.
> I used to live in Saudi Arabia; they had a few BITNET connections,
> an (expensive) X.25 network, and that was about it for years.
> Maybe this will change or satellites will rescue us. It looks like an
> engineering challenge. Which means it may not happen immediately.
POTS is probably adequate.
>
>
> One potential problem - currently only a limited number of absentee
> ballots are mailed abroad for expatriates and millitary personnel.
> What if we accidentally implement a system in which these remote
> terminals can be used to vote an unbounded number of times?
> What happens when the Republic of Foo freedom fighters silently
> break into the embassy and use its terminal to cast 938 votes in
> Florida?
All parts of the spec. This is a non-trivial problem because enemy governments may
have an "avid interest" in the potential for misusing the system. This pits the
system against the toughest opponents there are.
But the availability of ballots is not the point of control. Only registered voters
can cast ballots. So the filtration should be done at the point of receipt of a
completed ballot rather than at the point of disbursement of blank ballots.
>
>
> > Is crypto up to providing the security equivalent to a postmarked and signed
> > hardcopy document? In the minds of the voters?
>
> You know, I have to think about that.
>
> > To pick on an eminent authority, B. Silverman has communication
> > issues with a
> > non-trivial fraction of the posters in this forum. Imagine
> > the conversation
> > given an audience of ancient Floridians. Perhaps the present systems is not
> > as bad as some alternatives.
>
> I appreciate the humor, but I doubt that B. Silverman will be the one
> explaining future voting schemes to the Florida or any other electorate.
> (Though I should let him speak for his own intentions).
>
> It seems more likely to me that if we were to go down this route, we
> would find (or train) a small legion of people to explain the new voting
> scheme. Look at the public education effort surrounding the Census and
> the new dollar coin. These people would no doubt acquire proficiency in
> explaining the voting scheme to ancient Floridians.
>
> Either that or the change would just happen and only a few people will
> notice.
The states are the laboratories of our system. As Oregon is experimenting with
all-mail voting, perhaps some other state, like the one now experiencing problems,
might try out such a system.
------------------------------
Date: Sun, 26 Nov 2000 20:19:09 +1100
From: Mark Harrop <[EMAIL PROTECTED]>
Subject: Cyrptography Digest Archive ?
--=====================_8105565==_.ALT
Content-Type: text/plain; charset="us-ascii"; format=flowed
Hi all...
Thank you to all who have helped me finding the archives of this list. I am
in the process of d/ling all of the now, except, of course, the missing '97
to '99 ones !
Does someone like Bruce Schneier who has probably been on this list since
the start have a personal archive of all the emails they received from this
list ?? If one of you old-timers out there have them, how about making them
avaliable to the rest of us ?? Either by email or someone setting up an
web/ftp site ?
Speaking of Bruce, I am in the middle of reading his amazing book (part of
uni course) and it is blowing my mind ! Though some of them at this stage
are _WAY_ over my
head ;-).
One of the things that intrigues me is how _HARD_ it is to get a truly
random number out of a computer! Most people who do not know cryptography
would think that a computer would be the _PERFECT_ device for something
like that.
I'm sure it has been asked before, and as I am only now d/ling the archives
and haven't had time to search them, does anyone recommend a computer
program to generate a truly (as possible) random number? Any URL that you
could point me to would be helpful.
PS. Once I have all of the archives, to thank those kind souls that helped
_ME_, I will make them avaliable for anyone who asks.
Cheers!
Mark Harrop
[EMAIL PROTECTED]<mailto:>
Moderator of the following Programming Lists:
Send a empty message to:
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
Cheers!
Mark Harrop
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
Moderator of the following Programming Lists:
Send a empty message to:
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
+<(:o)|<:
--=====================_8105565==_.ALT
Content-Type: text/html; charset="us-ascii"
<html>
Hi all...<br>
<br>
Thank you to all who have helped me finding the archives of this list. I
am in the process of d/ling all of the now, except, of course, the
missing '97 to '99 ones !<br>
<br>
Does someone like Bruce Schneier who has probably been on this list since
the start have a personal archive of all the emails they received from
this list ?? If one of you old-timers out there have them, how about
making them avaliable to the rest of us ?? Either by email or someone
setting up an web/ftp site ?<br>
<br>
Speaking of Bruce, I am in the middle of reading his amazing book (part
of uni course) and it is blowing my mind ! Though some of them at this
stage are _WAY_ over my<br>
head ;-).<br>
<br>
One of the things that intrigues me is how _HARD_ it is to get a truly
random number out of a computer! Most people who do not know cryptography
would think that a computer would be the _PERFECT_ device for something
like that.<br>
<br>
I'm sure it has been asked before, and as I am only now d/ling the
archives and haven't had time to search them, does anyone recommend a
computer program to generate a truly (as possible) random number? Any URL
that you could point me to would be helpful.<br>
<br>
PS. Once I have all of the archives, to thank those kind souls that
helped _ME_, I will make them avaliable for anyone who asks.<br>
<br>
<x-sigsep><p></x-sigsep>
Cheers!<br>
Mark Harrop<br>
<b>[EMAIL PROTECTED]<a href="mailto:"><br>
<br>
</a>Moderator of the following Programming Lists:<br>
<br>
Send a empty message to:<br>
<br>
[EMAIL PROTECTED]<br>
<br>
[EMAIL PROTECTED]<br>
[EMAIL PROTECTED]<br>
[EMAIL PROTECTED]<br>
[EMAIL PROTECTED]<br>
</b><br>
<font face="Comic Sans MS" color="#000080"><br>
</font>Cheers!<br>
Mark Harrop<br>
<b>[EMAIL PROTECTED]<br>
[EMAIL PROTECTED] <br>
[EMAIL PROTECTED]<br>
<br>
<br>
Moderator of the following Programming Lists:<br>
<br>
Send a empty message to:<br>
<br>
[EMAIL PROTECTED]<br>
<br>
[EMAIL PROTECTED]<br>
[EMAIL PROTECTED]<br>
[EMAIL PROTECTED]<br>
[EMAIL PROTECTED]<br>
<br>
+<(:o)|<:</b></html>
--=====================_8105565==_.ALT--
------------------------------
From: [EMAIL PROTECTED] (Vernon Schryver)
Subject: Re: Cryptogram Newsletter is off the wall?
Date: 25 Nov 2000 10:32:13 -0700
In article <[EMAIL PROTECTED]>,
Anne & Lynn Wheeler <[EMAIL PROTECTED]> wrote:
>> If you mean that the TCB created by a SYN should be deleted if the
>> SYN-Ack sent toward the source of the SYN elicits an ICMP Unreachable,
>> then I disagree. At least some TCP stacks honor ICMP Unreachables
>> when the TCP state machine is not in Established. In other words,
>> TCBs created by orphan SYNs are already going poof as the result of
>> ICMP Unreachables in what I define as good TCP stacks.
>
>I guess I've only had to deal with TCP stacks that weren't good.
>
>W/o opaque identifier that TCP pushed down and was returned in ICMP
>responses ... so when IP pushed the ICMP up ...the upper layers could
>filter out ICMPs not for them ... somebody has to filter ICMPs that might
>be pushed up one or more instances.
What's that about opaque identifiers? ICMP error messages are supposed
to include the first bytes of the IP packet that caused the problem. An
ICMP Unreachable message complaining that a TCP/IP segment was sent to an
unreachable destination includes the IP header and start of the TCP/IP
header of the undeliverable TCP/IP packet. A concrete example of the
generation of ICMP messages can be seen in the icmp_error() function in
netinet/ip_icmp.c in your favorite BSD TCP/IP variant.
The BSD TCP/IP code uses the addresses and port numbers to find the right
Transmission Control Block (TCB). A concrete example of the start of that
process can be seen icmp_input() also in netinet/ip_icmp.c.
Note that Microsoft's WINSOCK library is based on the BSD code.
Page 3 of RFC 777 says an Unreachable should include:
Internet Header + 64 bits of Data Datagram
The internet header plus the first 64 bits of the original
datagram's data. This data is used by the host to match the
message to the appropriate process. If a higher level protocol
uses port numbers, they are assumed to be in the first 64 data
bits of the original datagram's data.
See also page 71 of RFC 1122 where it says:
The IP layer MUST pass certain ICMP messages up to the
appropriate transport-layer routine. This function could be
considered to be a special case of the RECV() call, of
course; we describe it separately for clarity.
For an ICMP error message, the data that is passed up MUST
include the original Internet header plus all the octets of
the original message that are included in the ICMP message.
This data will be used by the transport layer to locate the
connection state information, if any.
Starting on page 103 of RFC 1122 are words that require TCP to do the
right things:
TCP MUST act on an ICMP error message passed up from the IP
layer, directing it to the connection that created the
error. The necessary demultiplexing information can be
found in the IP header contained within the ICMP message.
"MUST" is a special word. Any TCP/IP stack that violates "MUST"
or "MUST NOT" provisions of RFC's with status "STANDARD" is not
only not good, but non-compliant and broken.
In this area, my idiosyncratic definition of "good" differs at most
slightly from IETF standard by having TCP honor Unreachables outside of
the Established state.
Vernon Schryver [EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED] (Rob Warnock)
Crossposted-To: sci.math,sci.logic
Subject: Re: My new book "Exploring RANDOMNESS"
Date: 26 Nov 2000 10:34:03 GMT
Chris Gillespie <[EMAIL PROTECTED]> wrote:
+---------------
| [EMAIL PROTECTED] wrote:
| > my new book "Exploring RANDOMNESS" ...
| > http://www.cs.umaine.edu/~chaitin/ait
| > http://www.cs.auckland.ac.nz/CDMTCS/chaitin/ait
|
| Um, is it just me or is that a published version of a Masters/PhD thesis?
+---------------
Hardly. It's his sixth (seventh?) book. If you look up one level
(E.g., <URL:http://www.cs.umaine.edu/~chaitin/>) you'll see a fairly
extensive publication record going back at least 25 years...
+---------------
| Looks very deep but not very wide. i.e interesting to those people
| who know a lot about your area but not to the decently educated cryto
| interested man on the street.
+---------------
Again, look up-level, and I think you'll find several more "popular"
(or at least more generally-accessible) introductions, e.g.:
<URL:http://www.cs.umaine.edu/~chaitin/sciamer.html>
<URL:http://www.cs.umaine.edu/~chaitin/cmu.html>
<URL:http://www.cs.auckland.ac.nz/CDMTCS/chaitin/unknowable/ch6.html>
-Rob
=====
Rob Warnock, 31-2-510 [EMAIL PROTECTED]
Network Engineering http://reality.sgi.com/rpw3/
Silicon Graphics, Inc. Phone: 650-933-1673
1600 Amphitheatre Pkwy. PP-ASEL-IA
Mountain View, CA 94043
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: hardware RNG's
Reply-To: [EMAIL PROTECTED]
Date: Sun, 26 Nov 2000 10:40:27 GMT
David Schwartz <[EMAIL PROTECTED]> wrote:
: Tim Tyler wrote:
:> [...] I would conclude that biased streams like the one above
:> are rather predictable - and not very random.
: Note that you use cautionary words like "rather" and "not very". If
: it's "rather predictible", than it is, to some extent, unpredictable. If
: it's "not very random", then it is, to some extent, random.
:> Certainly I think if you describe such biased streams as "random",
:> then you are likely to cause confusion in discussions with many people.
: Not at all. Only in people who have some deliberate interest in
: pretending to be confused. It's possible to use such terms in a way that
: people will get confused, but if you're careful to point out that the
: streams must be correctly processed to distribute the entropy, there's
: no chance for confusion. [...]
Here's what I'm objecting to:
David Schwartz wrote:
> Alan Rouse wrote:
> > David Schwartz wrote:
> > > Random is not absolute. If I roll a die with a '1' on one side and a
> > > '2' on five other sides, the result is random, however it will have
> > > biases. Your formulation defies common usage as well.
> >
> > Ok we have established that our differences are semantics. If I am to
> > communicate further with you on this subject I need a new word that
> > means to you what "random" means to me. How about arfbixqy? [...]
>
> How about "unpredictable" or even "random"?
If you say "unpredictable" people with think that's what you mean - not
"containing some unpredictable element". The same with "random" - a
stream with some random element should not be called "random" without
qualification - or confusion is likely to result.
Enough. If you want to use these terms in the way you suggest you are
welcome to do so - provided you have clearly defined your terms.
Personally, I think you'd cause less confusion if you went for a
different term - rather than re-using a common word with what
appears to be a different commonly accepted meaning.
--
__________ Lotus Artificial Life http://alife.co.uk/ [EMAIL PROTECTED]
|im |yler The Mandala Centre http://mandala.co.uk/ Free gift.
------------------------------
Date: Sun, 26 Nov 2000 10:57:17 +0000
From: Richard Heathfield <[EMAIL PROTECTED]>
Subject: Re: Cyrptography Digest Archive ?
Mark Harrop wrote:
>
<snip>
>
> One of the things that intrigues me is how _HARD_ it is to get a truly
> random number out of a computer! Most people who do not know
> cryptography would think that a computer would be the _PERFECT_ device
> for something like that.
>
> I'm sure it has been asked before, and as I am only now d/ling the
> archives and haven't had time to search them, does anyone recommend a
> computer program to generate a truly (as possible) random number? Any
> URL that you could point me to would be helpful.
No computer program, on its own, can generate a truly random number.
The Mersenne Twister makes a fair old attempt at it, but cannot succeed.
If you want truly random numbers (or, rather, numbers that are random
enough for cryptography), you need a non-deterministic process or, at
least, something that might as well be non-deterministic - something an
attacker can't reproduce.
Some possible ways to get cryptographically reasonable randomness:
o Toss a coin. (NOT on a computer! A real,
physical coin.) That gives you one bit of
entropy per toss. Record the results, and
type them in.
o Roll a die. (NOT on a computer! A real,
physical die.) An eight-sided die,
available from any good fantasy roleplaying
store, will give you 3 bits of entropy
per roll. Record the results, and type them in.
o Hook up your computer to a lava lamp.
(This has been done, by the way - A Web
search may well reveal more information.)
o Hook up your computer to a radioactive
source. Careful...
o On some (all?) Linux systems, /dev/random might
be worth a look. This is probably the least good
option from this list.
--
Richard Heathfield
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton
------------------------------
** FOR YOUR REFERENCE **
The service address, to which questions about the list itself and requests
to be added to or deleted from it should be directed, is:
Internet: [EMAIL PROTECTED]
You can send mail to the entire list (and sci.crypt) via:
Internet: [EMAIL PROTECTED]
End of Cryptography-Digest Digest
******************************
