Cryptography-Digest Digest #166
Cryptography-Digest Digest #166, Volume #13 Thu, 16 Nov 00 07:13:00 EST
Contents:
Re: vote buying... (Paul Rubin)
WS_FTP is insecure - it supports SSL, but only with 40-bit keys! (Eric Smith)
Re: New record SNFS factorization (John Savard)
Re: vote buying... (Eric Smith)
Re: vote buying... ([EMAIL PROTECTED])
Re: Anyone has read / poses / is found of book by M.Schroeder(not the ("John A.
Malley")
Re: Anyone done/doing Schneier's self-study cryptanalysis course? ("John A. Malley")
Re: Q: fast block ciphers ("Scott Fluhrer")
Hitachi - on what grounds ?? ("kihdip")
Re: Anyone has read / poses / is found of book by M.Schroeder(not the (Ariel
Burbaickij)
Re: Anyone has read / poses / is found of book by M.Schroeder(not the ("John A.
Malley")
Re: Q: fast block ciphers (Lauri Pesonen)
Re: Anyone has read / poses / is found of book by M.Schroeder(not the (Ariel
Burbaickij)
Re: vote buying... (Bill Godfrey)
Re: Big-block cipher, perhaps a new cipher family? (Mok-Kong Shen)
Re: Hitachi - on what grounds ?? (Mok-Kong Shen)
Re: Anyone has read / poses / is found of book by M.Schroeder(not the (Richard
Heathfield)
From: Paul Rubin [EMAIL PROTECTED]
Subject: Re: vote buying...
Date: 15 Nov 2000 20:07:04 -0800
David Schwartz [EMAIL PROTECTED] writes:
That traceability is bad even if the election officials are honest and
the election is fair. Years later, Sheriff Bubba has worked his way
up to being Supreme Dictator Bubba, has the election officials
executed and gets the archived code numbers and uses the ballot data
to locate everyone who voted against him.
Won't work. It'll just give him the code numbers of everyone who voted
against him. Remember, we were talking about a case where a citizen
presents his electronic voting receipt to an official.
Nope. Remember, Bubba already got the receipts from the voters back
when he was still Sheriff and couldn't decode them. Now he can decode
them and there is hell to pay.
The goal of being able to check votes after the election (to detect
fraud) is in conflict with the goal of not being able to check the
votes (to protect voter secrecy).
So long as you need the voter's help to check them, you can easily meet
both goals.
The whole point of the original Sheriff Bubba scenario was to show
that receipts are bad even if the voter has to help decode it. I
don't see this as helping. Maybe there could be some protocol where
all the receipts are public, and the statistics of a signed collection
of votes (signed by the voting machine) can be computed, but nothing
about individual votes can be computed, and the statistics of unsigned
collections can't be computed. (Otherwise, you could find statistics
of different subsets of the receipts and figure out individual votes
or votes of small groups). Then the voting machine would spit out
its signed receipt collection as soon as the polls close, and destroy
its signing key immediately afterwards, so Bubba wouldn't be able to
use the key to sign more stuff later (i.e. if the election was honest
in the first place, the receipts couldn't be retroactively misused).
Really though, we're talking about Star Trek solutions to a Babylon 5
problem (I love that description but don't remember who originally
made it).
--
From: Eric Smith [EMAIL PROTECTED]
Subject: WS_FTP is insecure - it supports SSL, but only with 40-bit keys!
Date: 15 Nov 2000 20:37:11 -0800
I've been trying to find an FTP client for Windows that supports SSL,
and tried WS_FTP from Ipswitch. It's inexpensive, and they provide
a time-limited demo.
I'm very glad that they provided the demo. If I'd paid money for it
I'd demand a refund. I found out the hard way that they support
*only* 40-bit ciphers. I inquired of their technical support,
expecting perhaps to be told that I needed an expensive SGC certificate
in order to use secure crypto. To my surprise they said that they
don't support it at all.
Although the product seems to be quite good in other respects, I have
to recommend *against* it for anyone who actually is concerned about
security.
Eric Smith
--
From: [EMAIL PROTECTED] (John Savard)
Crossposted-To: sci.math
Subject: Re: New record SNFS factorization
Date: Thu, 16 Nov 2000 04:59:27 GMT
On 15 Nov 2000 19:58:23 GMT, [EMAIL PROTECTED] (Bill Unruh) wrote,
in part:
In [EMAIL PROTECTED] "Herman J.J. te Riele" [EMAIL PROTECTED] writes:
]``The Cabal'' announces the completion, on November 14, 2000,
]of the factorization with the Special Number Field Sieve (SNFS)
]of the 233-digit Cunningham number 2,773+ = 2^773 + 1 into the product
]of 3, 533371 and three primes of 55, 71, and 102 digits, respectively.
]This establishes a new record for the Special Number Field Sieve SNFS.
Well, I would not call this factoring a 233 digit number, maybe a
Cryptography-Digest Digest #167
Cryptography-Digest Digest #167, Volume #13 Thu, 16 Nov 00 13:13:00 EST
Contents:
Re: Q: fast block ciphers (Tom St Denis)
Re: Randomness from key presses and other user interaction (Tim Tyler)
Re: New record SNFS factorization (Chris Thompson)
My new book "Exploring RANDOMNESS" ([EMAIL PROTECTED])
Re: New record SNFS factorization (Bob Silverman)
Re: vote buying... ("Frog2000")
Re: vote buying... ("Frog2000")
Re: Big-block cipher, perhaps a new cipher family? (Manuel Pancorbo)
Re: Comments on this book (Bob Silverman)
Re: Hitachi - on what grounds ?? (John Savard)
Re: Hitachi - on what grounds ?? (John Savard)
Re: Big-block cipher, perhaps a new cipher family? (Tom St Denis)
Re: vote buying... ("Paul Pires")
Re: Hitachi - on what grounds ?? (Richard Heathfield)
Re: Anyone has read / poses / is found of book by M.Schroeder(not the ("John A.
Malley")
Re: vote buying... (zapzing)
Re: vote buying... (Dan Oetting)
Re: Hitachi - on what grounds ?? ("Paul Pires")
From: Tom St Denis [EMAIL PROTECTED]
Subject: Re: Q: fast block ciphers
Date: Thu, 16 Nov 2000 12:22:17 GMT
In article 8uvh3t$lgt$[EMAIL PROTECTED],
"Brian Wong" [EMAIL PROTECTED] wrote:
"Tom St Denis" [EMAIL PROTECTED] wrote in message
news:8uvbod$7l6$[EMAIL PROTECTED]...
I once designed a block cipher that uses decorrelation modules for
security. The idea was to precompute multiplication in GF(2)^32 as
a
series of four 8x32 sboxes. With six rounds I achieved a rate of
about
13 cycles/byte on my AMD K6-II machine which is the fastest speed
for a
block cipher I ever heard of.
It's GF(2^32), something you should remember after being corrected
for this
so many times. If you can't get this simple statement right, how do
you
expect to have any credibility at all?
Then why is GF(p) modulo a prime modulus, such as in IDEA?
That's why I get confused. I am working with a 32-degree polynomial,
not a 32-bit scalar.
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
--
From: Tim Tyler [EMAIL PROTECTED]
Subject: Re: Randomness from key presses and other user interaction
Reply-To: [EMAIL PROTECTED]
Date: Thu, 16 Nov 2000 12:44:31 GMT
Steve Roberts [EMAIL PROTECTED] wrote:
: Aargh, the user will just hold a key down so that all the key strokes
: will have the same spacing in time!! Don't forget that humans will
: usually find the easiest possible way of doing something. The same
: thing for human-chosen random typing - there will be a lot of repeated
: a's out there.
You can detect this easily. Insisting on a number of key releases
is one counter-measure to having the user hold down a key.
--
__ http://alife.co.uk/ http://mandala.co.uk/
|im |yler [EMAIL PROTECTED] http://hex.org.uk/ http://atoms.org.uk/
--
From: [EMAIL PROTECTED] (Chris Thompson)
Crossposted-To: sci.math
Subject: Re: New record SNFS factorization
Date: 16 Nov 2000 14:47:15 GMT
In article [EMAIL PROTECTED],
John Savard [EMAIL PROTECTED] wrote:
On 15 Nov 2000 19:58:23 GMT, [EMAIL PROTECTED] (Bill Unruh) wrote,
in part:
In [EMAIL PROTECTED] "Herman J.J. te Riele" [EMAIL PROTECTED] writes:
]``The Cabal'' announces the completion, on November 14, 2000,
]of the factorization with the Special Number Field Sieve (SNFS)
]of the 233-digit Cunningham number 2,773+ = 2^773 + 1 into the product
]of 3, 533371 and three primes of 55, 71, and 102 digits, respectively.
]This establishes a new record for the Special Number Field Sieve SNFS.
Well, I would not call this factoring a 233 digit number, maybe a 227
digit number. Those factors of 3 and 533371 are trivial.
Because the particular 233-digit number being factored was chosen for
its mathematical interest, you have been criticized for going as far
as saying that the announcement was "overplaying" the achievement.
This, of course, doesn't contradict the specific motivation behind
your concern: as far as the direct applicability of this to attacks on
RSA, one might even consider only the largest two factors, and note
this implies that a 173-digit modulus is insecure.
But this again misses the point that this is an SNFS record, not a GNFS
one. The moduli used for RSA encryption, for example, are not going to be
subject to an SNFS attack in the first place, unless your key-choosing
method is very strange indeed. The fact that SNFS has done a 233-digit
number which happens to have a 173-digit composite factor, says nothing
about the ability of GNFS to tackle a general 173-digit number (it's
still way short of that target, I think).
BTW, yes, congratulations to The Cabal are in order!
Chris Thompson
Email: cet1 [at] cam.ac.uk
--
From: [EMAIL PROTECTED]
Crossposted-To: sci.math,sci.logic
Subject: My new book "Exploring RANDOMNESS"
Date: Thu, 16 Nov 2000 14:41:33 GMT
Hi, in
Cryptography-Digest Digest #168
Cryptography-Digest Digest #168, Volume #13 Thu, 16 Nov 00 15:13:00 EST
Contents:
Re: Big-block cipher, perhaps a new cipher family? (Mok-Kong Shen)
Re: so many fuss about impossibility to backtrace from MD to original ("Douglas A.
Gwyn")
Re: Hitachi - on what grounds ?? ("Douglas A. Gwyn")
Re: Hitachi - on what grounds ?? (Mok-Kong Shen)
Re: vote buying... (David Schwartz)
Re: Q: fast block ciphers (David Schwartz)
Re: vote buying... ("Frog2000")
Re: vote buying... ("Frog2000")
Re: Anyone has read / poses / is found of book by M.Schroeder(not the ("John A.
Malley")
Re: Hitachi - on what grounds ?? ("Paul Pires")
Re: vote buying... (Paul Rubin)
Re: Q: fast block ciphers (Tom St Denis)
Re: vote buying... (Eric Lee Green)
From: Mok-Kong Shen [EMAIL PROTECTED]
Subject: Re: Big-block cipher, perhaps a new cipher family?
Date: Thu, 16 Nov 2000 19:32:55 +0100
Manuel Pancorbo wrote:
Mok-Kong Shen [EMAIL PROTECTED] wrote:
It is not clear in your description how the 'diffusion' is
achieved through stream encryption. A stream cipher encrpyts
each 'unit' independent of the other. The 'state' of the
cipher changes with each unit, but this is generally
independent of the content of the plaintext unit being
processed. So there is no 'interaction' between the units.
Should I name it "stream cipher with feedback"? In my design, state
depends on the input. Anyway, let me explain how it works.
As I said the chosen unit length is 32 bits. The key (K) can be 128 to
256 bit long (in 32 bit steps); let's take 128 bits i.e. 4 units. The
state vector (S) is also 4 units long.
At the beginning the state vector is filled up with the key:
S - K
In the forward encryption each plaintext unit is ciphered this way:
P'[0] = F(P[0], S[0], S[1])
S[1] = G(P[0], P'[0])
.
P'[1] = F(P[1], S[1], S[2])
S[2] = G(P[1], P'[1])
.
And so on. The state cycles over itself (S[0], S[1], S[2], S[3], S
[0],...). F and G are two 32-bit nonlinear functions. Both propagate
any single bit change of the P[0] input to 16 bits on the output P'[0]
and to 24 bits on the new state unit S[1]; in the next step S[1]
carries the (imperfect) diffusion of P[0] again to F and G which
amplify it to 32 bits in P'[1] (and S[2]).
You can see how avalanche works forward. At the end a new encryption
pass is performed backwards:
S - K
.
C[N-1] = F(P'[N-1], S[0], S[1])
S[1] = G(P'[N-1], C[N-1])
.
C[N-2] = F(P'[N-2], S[1], S[2])
S[2] = G(P'[N-2], C[N-2])
The result is that any single bit change in the plaintext packet
propagates to the full ciphertext packet (except perhaps if the change
occurs in the last units).
The point is that it doesn't really matter how F and G are built,
provided a minimum diffusion, unlinearity and operations economy (I
think). Anyway I can give details in a further post.
You can also use any common block cipher to do chaining
in the forward direction and, after having processed the
whole file, do a second encryption pass in the backward
direction. (This is a known method of forcing the opponent
to process the whole file, as also mentioned previously in
several threads of the group.) In fact, the block cipher
is doing 'stream' encryption here if you look on the block
as a single 'unit' of the 'stream'.
My goal is to avoid the repetitive rounds and the key scheduling of
block ciphers, but giving the same diffusion power and disorder. If
possible, giving the same strength ;-)
But in the scheme you described there are the functions
F and G which you don't specify in detail. If the F is
not good, you wouldn't have good diffusion. One can have
a combination of stream and block techniques. I designed
one with a block size of 640 bits driven by a PRNG with
feedback to the PRNG by hash values obtained during the
processing and with block chaining. In other words, the
state of the PRNG is influenced by the plaintext blocks
and the processing of the blocks is determined by the
PRNG outputs and the successive blocks are chained. See
my web page.
M. K. Shen
http://home.t-online.de/home/mok-kong.shen
--
From: "Douglas A. Gwyn" [EMAIL PROTECTED]
Subject: Re: so many fuss about impossibility to backtrace from MD to original
Date: Thu, 16 Nov 2000 17:51:03 GMT
[EMAIL PROTECTED] wrote:
Birthday Paradox (if you bring random people into a room, you can only
have 20 of them on average before 2 of them have the same birthday)
That's not accurate; it's 23 people and the "averaging" is over
the ensemble of sets of 23-random-people, or better expressed:
if you randomly select a sample of 23 people from the whole
population, the probability is greater than 0.5 that at least 2
of that sample were born on the same day of the year.
Suppose a man has a drawer in which there are 100 black socks
and 100
Cryptography-Digest Digest #169
Cryptography-Digest Digest #169, Volume #13 Thu, 16 Nov 00 18:13:01 EST
Contents:
Re: vote buying... (Eric Lee Green)
Attacks on the key setup in RC4? (sorry "Arc4") (Ichinin)
Re: vote buying... (Eric Smith)
Re: Hitachi - on what grounds ?? (Eric Smith)
Re: Hitachi - on what grounds ?? (Mok-Kong Shen)
Re: Hitachi - on what grounds ?? ("Paul Pires")
Re: Hitachi - on what grounds ?? ("Paul Pires")
Re: Hitachi - on what grounds ?? (Mok-Kong Shen)
Re: vote buying... (David Wagner)
Is Triple DES the BEST Algorithm ? ("Laurent")
Re: Hitachi - on what grounds ?? ("Paul Pires")
RSA question (shren)
Re: Hitachi - on what grounds ?? (Mok-Kong Shen)
Re: Help - Microsoft CryptoAPI and SDK (Greggy)
Re: Hitachi - on what grounds ?? ("Paul Pires")
Re: voting through pgp ([EMAIL PROTECTED])
From: [EMAIL PROTECTED] (Eric Lee Green)
Subject: Re: vote buying...
Reply-To: [EMAIL PROTECTED]
Date: Thu, 16 Nov 2000 20:11:43 GMT
On Thu, 16 Nov 2000 10:47:49 -0700, Dan Oetting [EMAIL PROTECTED] wrote:
The envelopes can be opened and the ballots shuffled by a closed machine
to protect the secrecy of the ballots. The process can be verified by
repetition, testing with sample ballots and public inspection of the
hardware and software. Only one layer of envelope may be necessary.
You are assuming that El Dictatador has not rigged the voting machines.
This is my whole problem with the entire concept of voting machines.
This isn't a new concern, by the way. Harry Harrison wrote an entire
novel about how to corrupt an electronically-recorded election ("The
Stainless Steel Rat For President").
--
Eric Lee Green There is No Conspiracy
[EMAIL PROTECTED] http://www.badtux.org
--
From: Ichinin [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
Subject: Attacks on the key setup in RC4? (sorry "Arc4")
Date: Sun, 12 Nov 2000 19:53:53 +0100
Hi.
Does anyone know of any attacks on the "key setup"
(or whatever one should call it) on RC4? I know
there are some onservations on using it as a PRNG,
and mr C. Hall mentioned something on cycles at
Crypto 99, but are there anything else?
(I only have papers from 81-97...:oP)
Thanks in advance,
Glenn
Ichinin (.SE)
"Anything-over-IP--802.11"-Solutions provider.
===
NOTE: EMAIL ADDRESS IS FOR SPAMMERS, IT WILL BOUNCE REGARDLESS.
--
From: Eric Smith [EMAIL PROTECTED]
Subject: Re: vote buying...
Date: 16 Nov 2000 12:23:27 -0800
"Frog2000" [EMAIL PROTECTED] writes:
Hmmmmincing words, I think. Anyway, am I to assume you aren't from US?
Why would you assume that?
In general in the United States the government does not have the
power to grant privileges. Any time you hear about them doing so,
you should immediately be suspicious that they're exceeding their
authority.
I wouldn't put you on Gore's or Bush's legal team.
Thank you!!!
We are testing these very notions as we speak.
Note that I didn't say that the government *doesn't* grant privileges,
only that it doesn't have the legal *power* to do so. They routinely
overstep their official powers, and only part of the time get reined
in by the courts.
--
From: Eric Smith [EMAIL PROTECTED]
Subject: Re: Hitachi - on what grounds ??
Date: 16 Nov 2000 12:26:07 -0800
"Paul Pires" [EMAIL PROTECTED] writes:
In patents, like in most specialized areas of interest, obvious has a
special meaning.
Apparently not an obvious one.
If obvious doesn't mean the obvious thing, what does it mean?
--
From: Mok-Kong Shen [EMAIL PROTECTED]
Subject: Re: Hitachi - on what grounds ??
Date: Thu, 16 Nov 2000 21:30:41 +0100
Paul Pires wrote:
Mok-Kong Shen [EMAIL PROTECTED] wrote:
I would feel better if examples were cited that adhered to
a less general and more rigorous process. A white paper
with source code, An acedemic publication, a publicized
contest submission. Along those lines.
Rarely are claims drafted as broad as the discussions
mentioned. To anticipate them, the discussions would
need to be a little more substantial and definitive.
When I say that one can permutate the round keys
of a (any) block cipher, do I have to write code to
show that? If I did, with a particular cipher, the
code is only for a 'particular' cipher. But it is the
principle that is at issue.
M. K. Shen
--
From: "Paul Pires" [EMAIL PROTECTED]
Subject: Re: Hitachi - on what grounds ??
Date: Thu, 16 Nov 2000 12:56:13 -0800
Mok-Kong Shen [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]...
Paul Pires wrote:
Mok-Kong Shen [EMAIL PROTECTED] wrote:
I would feel better if examples were cited that adhered to
a less general and more rigorous process. A white paper
with source code, An acedemic publication, a
Cryptography-Digest Digest #170
Cryptography-Digest Digest #170, Volume #13 Thu, 16 Nov 00 19:13:00 EST
Contents:
Re: Hitachi - on what grounds ?? (Mok-Kong Shen)
Re: "Lotto Balls lack enough mass to be influenced by electromagnetism" (WAS:Re:
FINANCIAL ASTROLOGY WEEK OF NOV 13 (Pete Stapleton)
Re: RSA question (Tom St Denis)
Re: Hitachi - on what grounds ?? ("Paul Pires")
Re: Book recommendation, please (Rex Stewart)
Re: Attacks on the key setup in RC4? (sorry "Arc4") (Tom St Denis)
Re: My new book "Exploring RANDOMNESS" (Mok-Kong Shen)
Re: Hitachi - on what grounds ?? (Mok-Kong Shen)
Re: Hitachi - on what grounds ?? ("Paul Pires")
Re: Is Triple DES the BEST Algorithm ? ([EMAIL PROTECTED])
Re: Is Triple DES the BEST Algorithm ? (Eric Smith)
Re: Hitachi - on what grounds ?? (Mok-Kong Shen)
From: Mok-Kong Shen [EMAIL PROTECTED]
Subject: Re: Hitachi - on what grounds ??
Date: Thu, 16 Nov 2000 23:28:11 +0100
Paul Pires wrote:
Mok-Kong Shen [EMAIL PROTECTED] wrote:
Paul Pires wrote:
Mok-Kong Shen [EMAIL PROTECTED] wrote:
Paul Pires wrote:
Mok-Kong Shen [EMAIL PROTECTED] wrote:
Paul Pires wrote:
Mok-Kong Shen [EMAIL PROTECTED] wrote:
I would feel better if examples were cited that adhered to
a less general and more rigorous process. A white paper
with source code, An acedemic publication, a publicized
contest submission. Along those lines.
Rarely are claims drafted as broad as the discussions
mentioned. To anticipate them, the discussions would
need to be a little more substantial and definitive.
When I say that one can permutate the round keys
of a (any) block cipher, do I have to write code to
show that? If I did, with a particular cipher, the
code is only for a 'particular' cipher. But it is the
principle that is at issue.
If principles are not patentable, How can they be
Prior art? Think about it. Saying one can do it and
"teaching" how it is done are two different things.
I'm not saying that you have to do anything. I am saying
that your every utterance doesn't have the same weight
as reduction to practice or substantial work to disclose.
Your example above is perfect. So general as to
be meaningless. If I permute round keys of a specific
cipher for a specific reason, in a specific way
that is new and novel...
maybe even usefull...
to achieve a new or superior result...
Does your "Prior art" read over it?
Nope. If it did the examiners would have to consider
every speculative flight of imagination from T.V. shows
to romance novels for "Similarity".
Why did you do it?
What exactly did you do?
What did you achieve?
What are the limits and parameters of the process?
What did you teach?
You have left much room for me to substantially improve
the art.
Your "Prior art" only keeps me from claiming it as broadly
as you do. Maybe not even that.
So I have to, among others, explain what a permutation
is alike like a school teacher tells his pupils, in
your opinion?? When we discuss in a certain environment,
certain contexts can be assumed, don't we?
Don't try and make it sound trivial or childish. I thought I
added a little bit to the discussion. I didn't say
you had to define the elementary terms. If you get to pick
representative examples for my words then I start to look
pretty silly. I don't need help there!
You don't have to do
anything. But, if you want to achieve an effect, a reasonable
amount of work may be required.
When you cite these discussions as prior art, what parts
are valid? All of those that "Teach" your method or the
corrections, contradictions, denials and rebuttals?
Your right, contexts are assumed all the time. Do you
walk away thinking that yours are the only ones?
Get this straight, I have never seen a definitive
conclusion to one of these threads yet. You're just
remembering your side of them. I acknowledge
that I am an under-achieving plodder but I am not
an elementary school pupil. With work and effort
I may yet achieve that goal.
This might be a good point to ask ourselves
"Have we been understood/do we understand
and are we now playing for points?"
I certainly would appreciate the opportunity to learn
something valuable from you. You have put forward
several questions 'Why did you do it?' etc. Let's
take the example of my suggestion of permuting the
round keys. This is in an addendum to the thread
'On introducing non-interoperability'. Which of the
quenstions do you think that I need to provide
additional materials for answering and why? Thanks.
Frankly, I'd rather be
Cryptography-Digest Digest #171
Cryptography-Digest Digest #171, Volume #13 Thu, 16 Nov 00 22:13:01 EST
Contents:
RE: Big-block cipher, perhaps a new cipher family? ("Manuel Pancorbo")
Re: Hitachi - on what grounds ?? ("Paul Pires")
Re: Big-block cipher, perhaps a new cipher family? (Terry Ritter)
Re: Hitachi - on what grounds ?? (Terry Ritter)
Re: Is Triple DES the BEST Algorithm ? (Tom St Denis)
Re: Re: ECC help please ("James Russell")
Re: My new book "Exploring RANDOMNESS" (Greggy)
Silly idea to prevent decrypt (Silly Things)
Re: Book recommendation, please (Greggy)
Re: Randomness from key presses and other user interaction (Steve Roberts)
Re: voting through pgp (Sundial Services)
Re: WS_FTP is insecure - it supports SSL, but only with 40-bit keys! ("George
Peters")
Re: Silly idea to prevent decrypt (Tom St Denis)
[Question] Export restrictions on following algos. (Shri Desai)
[Question] XOR encryption (Shri Desai)
[Question] Generation of random keys (Shri Desai)
Re: My new book "Exploring RANDOMNESS" (Tim Tyler)
From: "Manuel Pancorbo" [EMAIL PROTECTED]
Subject: RE: Big-block cipher, perhaps a new cipher family?
Date: Fri, 17 Nov 2000 00:27:03 GMT
"Mok-Kong Shen" [EMAIL PROTECTED]
But in the scheme you described there are the functions
F and G which you don't specify in detail.
I will; give me a couple of days and I'll publish the whole code with
graphic explanation and test packets.
If the F is
not good, you wouldn't have good diffusion.
In fact I have no *good* diffusion: only 16 bits (for F) and 24 bits (for G)
out of 32, are affected by a single bit change in input *at the first step*.
Good diffusion is obtained by running this kernel cipher over the packet
(and backwards).
One can have
a combination of stream and block techniques. I designed
one with a block size of 640 bits driven by a PRNG with
feedback to the PRNG by hash values obtained during the
processing and with block chaining. In other words, the
state of the PRNG is influenced by the plaintext blocks
and the processing of the blocks is determined by the
PRNG outputs and the successive blocks are chained. See
my web page.
My cipher method has no upper limit (except the system memory) for the
packet size. You can apply it to a 1 MByte file without chaining (provided
enough memory).
Nevertheless I don't pretend be original. The question is: if this
"large-block-stream-ish" ciphers are really faster than traditional block
ciphers, good diffusive and strong against known attacks... why not give
them more attention?
--
Manuel Pancorbo
[EMAIL PROTECTED] (Apply ROT13)
--
From: "Paul Pires" [EMAIL PROTECTED]
Subject: Re: Hitachi - on what grounds ??
Date: Thu, 16 Nov 2000 16:49:19 -0800
Snip
If you have other methods which the communication partners
can easily and safely employ (i.e. without weakening
the cipher) and hinder the work of the opponent, then it
would be fine if you would let others of the group partake
you knowledge through posting these to the group.
Anyway, if you think that posts (not only those of mine)
you see in the group do not contain materials giving
sufficient answer to your five questions listed in a
previous follow-up, then please be kind enough to say so.
This is why we have a 'discussion' forum, isn't it?
As usual you and I are misconnected, I'm trying to back out
of it gracefully. If you wish to continue the discussion by E-mail
I will be happy to do so. I am feeling a little self concious about
how the group feels about this and don't want to continue this
here as it has gone way past anything usefull or interesting.
I don't have any problems, criticisms or questions about the
thread you mentioned. I also have no interest in the topic.
I suggested the questions as general content for the hypothetical
or example situation you originally brought up, not any actual thread
that might exist. Which, by the way, has nothing to do with the
original topic of discussion.
I do not disparage the content or authorship of any of that
material since I have not read it and have no interest in the
topic or knowledge of the subject. You don't have to
prove me an idiot, I freely admit it after getting sucked
into another weird exchange with you. We have to stop
meeting like this.
For someone who has such a problem with English,
you sure don't seem to have a problem with
condecension, misdirection and snide comments.
Be careful, that Columbo act is wearing a little thin.
Paul
--
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: Big-block cipher, perhaps a new cipher family?
Date: Fri, 17 Nov 2000 00:54:50 GMT
On Fri, 17 Nov 2000 00:27:03 GMT, in
rX_Q5.1169$[EMAIL PROTECTED], in sci.crypt
Cryptography-Digest Digest #172
Cryptography-Digest Digest #172, Volume #13 Fri, 17 Nov 00 00:13:01 EST
Contents:
Re: My new book "Exploring RANDOMNESS" ("Matt Timmermans")
Re: vote buying... ("Trevor L. Jackson, III")
Re: vote buying... ("Trevor L. Jackson, III")
Breaking Leviathan (Paul Crowley)
Re: vote buying... ("Trevor L. Jackson, III")
Re: vote buying... ("Trevor L. Jackson, III")
Re: vote buying... ("Trevor L. Jackson, III")
Re: And you FBI people reading my messages ... this is just starting .. :) ... I
know you are there . ("Alien8")
short encripted message (my first first cript agor) ("Alien8")
Rijndael: Impossible differential cryptanalysis on 5 rounds ([EMAIL PROTECTED])
Rijndael: Impossible differential cryptanalysis on 5 rounds ([EMAIL PROTECTED])
Re: vote buying... (Paul Rubin)
DES question: Has this ever been proven before? (Raphael Phan)
From: "Matt Timmermans" [EMAIL PROTECTED]
Crossposted-To: sci.math,sci.logic
Subject: Re: My new book "Exploring RANDOMNESS"
Date: Fri, 17 Nov 2000 03:13:21 GMT
"Greggy" [EMAIL PROTECTED] wrote in message
news:8v21tv$eoh$[EMAIL PROTECTED]...
[...]
In fact, have you considered making the book
online and free to read through? I for one have no curiosity for such
a book if I have to pay for it. Sounds like snake oil. Or can I get
my money back if I don't think it was worth the price?
Heh. Did you actually notice _who_ wrote the book?
--
Date: Thu, 16 Nov 2000 22:16:32 -0500
From: "Trevor L. Jackson, III" [EMAIL PROTECTED]
Subject: Re: vote buying...
David Schwartz wrote:
Paul Rubin wrote:
That traceability is bad even if the election officials are honest and
the election is fair. Years later, Sheriff Bubba has worked his way
up to being Supreme Dictator Bubba, has the election officials
executed and gets the archived code numbers and uses the ballot data
to locate everyone who voted against him.
Won't work. It'll just give him the code numbers of everyone who voted
against him. Remember, we were talking about a case where a citizen
presents his electronic voting receipt to an official.
You are looking at a scheme specifically designed to provide X and
complaining that it doesn't provide Y. Of course not, it isn't designed
to. Unless you want to argue that no scheme can provide both X and Y,
your argument is pointless.
I may have missed something but I think I agree with this. Any scheme
that solves all problems must do both X and Y, where X and Y are in
conflict with each other.
What goal is in conflict with what goal?
The goal of being able to check votes after the election (to detect
fraud) is in conflict with the goal of not being able to check the
votes (to protect voter secrecy).
So long as you need the voter's help to check them, you can easily meet
both goals.
Not quite. If the voter can prove the validity of his vote than a person
threatening the voter can force him to reveal the validity token. The only way to
protect the voter is to permit him to present a fake validity token. But that
conflicts with the fraud detection mechanism because it can be used to hide fraud.
--
Date: Thu, 16 Nov 2000 22:30:02 -0500
From: "Trevor L. Jackson, III" [EMAIL PROTECTED]
Subject: Re: vote buying...
David Schwartz wrote:
Paul Rubin wrote:
David Schwartz [EMAIL PROTECTED] writes:
That traceability is bad even if the election officials are honest and
the election is fair. Years later, Sheriff Bubba has worked his way
up to being Supreme Dictator Bubba, has the election officials
executed and gets the archived code numbers and uses the ballot data
to locate everyone who voted against him.
Won't work. It'll just give him the code numbers of everyone who voted
against him. Remember, we were talking about a case where a citizen
presents his electronic voting receipt to an official.
Nope. Remember, Bubba already got the receipts from the voters back
when he was still Sheriff and couldn't decode them. Now he can decode
them and there is hell to pay.
He only got the receipts of those people who contested the vote. And he
can't even be sure that the people who present the contest are the
original voters. All he knows is that someone presented a voting receipt
for a vote for candidate X and that this vote wasn't correctly counted
for candidate X. Unless the system totally breaks down, the number of
people issuing such disputes should be very small. The disputes could
even be done anonymously. All that's needed to process the dispute are
the numbers on the voting receipt.
The goal of being able to check votes after the election (to detect
fraud) is in conflict with the goal of not being able to check the
votes (to protect
