Cryptography-Digest Digest #66
Cryptography-Digest Digest #66, Volume #12 Mon, 19 Jun 00 21:13:01 EDT Contents: Re: MD5 Expansion (tomstd) Re: Encryption on missing hard-drives (Albert P. Belle Isle) Re: Extended Euclidean Algorithm ([EMAIL PROTECTED]) Re: obfuscating the RSA private key (Dave Ahn) Re: Observer 4/6/2000: "Your privacy ends here" (Dave Howe) Re: small subgroups in Blum Blum Shub (Terry Ritter) Re: quantum cryptography at nytimes.com (zzapzing) Subject: Re: MD5 Expansion From: tomstd <[EMAIL PROTECTED]> Date: Mon, 19 Jun 2000 15:59:08 -0700 Arthur Dardia <[EMAIL PROTECTED]> wrote: >[EMAIL PROTECTED] wrote: > >> In article <10839b68.9f89254c@usw-ex0104- >> 031.remarq.com>, >> tomstd <[EMAIL PROTECTED]> wrote: >> > Andrew Bortz <[EMAIL PROTECTED]> wrote: >> > >In the interest of increasing the size of a >> MD5 hash, I have >> > been >> > >thinking of a fairly simple method: >> > > >> > >1) Calculate the MD5 hash of the data >> > >2) Permute the data, preferable at the >> beginning, in some small >> > manner >> > >3) Calculate the MD5 hash of the new data, and >> append to the >> > original >> > >hash >> > >4) Lather, rinse, repeat as necessary/paranoid >> > > >> > >It seems as though it would work, and using >> the 256-bit variant >> > (one new >> > >hash) it would appear as though it yields huge >> advances in >> > protection, >> > >utilizing the apparent collision-free nature >> of MD5. >> > > >> > >Finally getting the root of my question... >> Since the hash >> > method in its >> > >entirety will/must be disclosed, it will be >> possible for >> > attackers to >> > >possibly utilize the two hashes in some attack >> to reveal the >> > data >> > >originally hashed. My question is, is MD5 >> secure enough to >> > withstand >> > >giving an attacker a significant statistical >> peep at the data >> > that was >> > >hashed? >> > >> > From what I gather you want todo this >> > >> > A = H(M) >> > B = H(L(A)) >> > >> > Where M is the original message, L is a linear >> transform and H >> > is the hash function. >> > >> > This is no more secure then the original >> underlying hash >> > function and I will show why. >> > >> > We know that a collision by the birthday >> paradox will take 2^64 >> > effort against MD5 (since it's a 128-bit >> hash). However, a >> > collision in A is sufficient to find a >> collision in the entire >> > hash. In otherwords your 256-bit hash can be >> broken in 2^64 >> > guesses which is far under the birthday paradox >> limit for a 256- >> > bit hash. >> > >> > Tom >> > >> > Got questions? Get answers over the phone at >> Keen.com. >> > Up to 100 minutes free! >> > http://www.keen.com >> > >> > >> >> Sorry, my news server sucks, so I'm using Deja. >> Anyway, Your logic evades me. Just because we can >> find 2 messages that have the same MD5 hash >> doesn't mean those two messages, run through the >> linear function, will have the same 2nd hash! >> That is where I see the security of using 2 >> hashes: Even when a collision is found in MD5, it >> will rarely have a collision in the 2nd hash >> because one bit change in the message will >> (supposed to) change on average half the bits of >> the hash. The attacker is back to searching... >> >> Sent via Deja.com http://www.deja.com/ >> Before you buy. > >I'm a newbie, so here it goes: > >Instead of doing what the original poster came up with. Why can't you >just hash the original message with MD5. Use the output as the input to >another hash algorithm (say SHA-1), and then to be safe repeat the same >thing replacing TIGER/192 for SHA-1. > >A=MD5(M); >B=SHA-1(MD5(M)); >C=TIGER/192(SHA-1(MD5(M))); > >C would be the final output. > >How does this increase security, by what percentage, if it does at all? Let's see the collection of A,B,C forms the new hash output and it's 480 bits in length. By the b-day paradox we should find a collsion after about 2^240 attempts... that's pretty good. However, I can find a collision in A with 2^64 work, and a collision in SHA with 2^80 work, that's about 2^80 work total since after 2^80 trials we are bound to see quite abit of MD5 collisions. Again after 2^96 trials to break Tiger we should see quite a bit of SHA collisions. So with about 2^96 hash operations we should see collisions in all three. That's hardly 2^240. The attack would work like this. 1. Try random pair of messages 2. Check if their hashes are equal for all three 3. If yes you win. Tom Got questions? Get answers over the phone at Keen.com. Up to 100 minutes free! http://www.keen.com -- From: Albert P. Belle Isle <[EMAIL PROTECTED]> Subject: Re: Encryption on missing hard-drives Date: Mon, 19 Jun 2000 19:20:01 -0400 Reply-To: [EMAIL PROTECTED] On Mon, 19 Jun 2000 22:19:46 GMT, [EMAIL PROTECTED] wrote: >Paul Rubin <[EMAIL PROTECTED]> wrote: > >Even if it was, it would be classified with a classified algorithm,
Cryptography-Digest Digest #65
Cryptography-Digest Digest #65, Volume #12 Mon, 19 Jun 00 19:13:00 EDT
Contents:
Re: Extended Euclidean Algorithm (Mok-Kong Shen)
Re: Forgot ZIP File password. (Simon Johnson)
Re: Small compression/encryption problem (Rickman)
Re: Random sboxes... real info (tomstd)
Re: Forgot ZIP File password. (tomstd)
Re: Random sboxes... real info (Roger Carbol)
Re: Extended Euclidean Algorithm (Simon Johnson)
Re: Extended Euclidean Algorithm (tomstd)
Re: Forgot ZIP File password. (Simon Johnson)
Re: Encryption on missing hard-drives (Paul Rubin)
Re: Random sboxes... real info (michael)
Re: Cipher design a fading field? ("Douglas A. Gwyn")
Re: Cipher design a fading field? ("Douglas A. Gwyn")
Re: Cipher design a fading field? ("Douglas A. Gwyn")
Re: Weight of Digital Signatures ("Douglas A. Gwyn")
Re: Extending LFSR.. ("Douglas A. Gwyn")
Re: oneway encryption for password (David P Jablon)
Re: Extending LFSR.. ("Douglas A. Gwyn")
Re: quantum cryptography at nytimes.com ("Douglas A. Gwyn")
Re: small subgroups in Blum Blum Shub (Secret Squirrel)
Re: Encryption on missing hard-drives ([EMAIL PROTECTED])
Re: Extended Euclidean Algorithm (Anton Stiglic)
Re: Extending LFSR.. (Joaquim Southby)
Re: MD5 Expansion (Arthur Dardia)
Re: Extending LFSR.. (Joaquim Southby)
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Extended Euclidean Algorithm
Date: Mon, 19 Jun 2000 22:19:51 +0200
Simon Johnson wrote:
> It would seem very logical that the Extended Euclidean Algorithm
> is an *extension* of the euclidean algorithm. What is this
> nature of this extention? - No source code please, all in
> prose. :)
>
> Also: i'm told it can solve the following problem:
>
> 6y + 7x + 14z mod n - where n is known
>
> How do i go about this?
See Knuth, The Art of Computer Programming. Vol. 2.
M. K. Shen
--
Subject: Re: Forgot ZIP File password.
From: Simon Johnson <[EMAIL PROTECTED]>
Date: Mon, 19 Jun 2000 13:12:14 -0700
Isn't there an attack that requires less than 100 bytes of known
plain-text and has a complexity of about 2^40..
Or is that what that cracking program does?
Got questions? Get answers over the phone at Keen.com.
Up to 100 minutes free!
http://www.keen.com
--
From: Rickman <[EMAIL PROTECTED]>
Crossposted-To: comp.compression
Subject: Re: Small compression/encryption problem
Date: Mon, 19 Jun 2000 16:16:49 -0400
Guy Macon wrote:
>
> Rickman wrote:
> >What you suggest could do the job well. But I can give you what should
> >be a simpler approach. Take your input data (uncompressed text string of
> >any form) and compress it by any of the conventional and redily
> >available means. PKZIP will do nicely. Generate a bit pattern using a
> >LFSR or other simple pseudo random number generator. XOR the compressed
> >data with the bit pattern. This is your compressed, encrypted data. You
> >may need to group it into 6 bit characters which are mapped to 64
> >printable ascii characters. I would bet that with a little searching on
> >the web for the random bit stream generator, you could reduce your
> >programming effort to almost nothing.
> >
> >This may not provide NSA level security, but it will be more than useful
> >enough for your application and you don't need to do a lot of coding.
>
> This looks like a near ideal solution. I wouldn't go for 64 characters
> on the basis of making things easy for the typist. I would use 16,
> (specifically abcdefghjkprstuv) presented in groups of 4 characters.
That is a good point. It might also be a good idea to add one of the ECC
methods that others have mentioned before encrypting. Since the
characters will be very random, the typist will have problems
transcribing this text and an error correcting code will help with this
problem. One or two wrong characters (or missing or repeated) will still
give you the data you intended.
I am not real busy at the moment. If you are interested, I can work on
this for you. Drop me an email or call if you are interested.
--
Rick Collins
[EMAIL PROTECTED]
Ignore the reply address. To email me use the above address with the XY
removed.
Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design
Arius
4 King Ave
Frederick, MD 21701-3110
301-682-7772 Voice
301-682-7666 FAX
Internet URL http://www.arius.com
--
Subject: Re: Random sboxes... real info
From: tomstd <[EMAIL PROTECTED]>
Date: Mon, 19 Jun 2000 13:16:31 -0700
[EMAIL PROTECTED] (SCOTT19U.ZIP_GUY) wrote:
> The point is Mr BS and Mr Wagner have written posts attacking
my
>SCOTT19U as snake OIL and he even bragged I was incapable of
makeing
>a safe cipher. They made fun of my cash contest which lasted
much longer
>than the BS contest. They gloat how they feel no ameuter can
wrote a
>good cipher. Yet the cont
Cryptography-Digest Digest #64
Cryptography-Digest Digest #64, Volume #12 Mon, 19 Jun 00 16:13:00 EDT
Contents:
Re: XOR versur MOD ("Tony T. Warnock")
Re: GeekPress: Will Cyber Criminals Run the World? ([EMAIL PROTECTED])
Re: Random sboxes... real info (James Felling)
Re: Cipher design a fading field? (James Felling)
Extended Euclidean Algorithm (Simon Johnson)
Re: Random sboxes... real info (SCOTT19U.ZIP_GUY)
Re: Cryptographic voting ([EMAIL PROTECTED])
Re: small subgroups in Blum Blum Shub (Mok-Kong Shen)
Re: software protection schemes (Sundial Services)
Re: How RSA SecurID tokens work? (James Felling)
Re: Forgot ZIP File password. (Sundial Services)
From: "Tony T. Warnock" <[EMAIL PROTECTED]>
Subject: Re: XOR versur MOD
Date: Mon, 19 Jun 2000 13:15:30 -0600
Reply-To: [EMAIL PROTECTED]
The operands are in order, these are the result tables
XOR for 2 bits ADD for 2 bits
00 01 10 11 00 01 10 11
01 00 11 10 01 10 11 00
10 11 00 01 10 11 00 01
11 10 01 11 11 00 01 10
Each row and each column each table is a permutation of the
corresponding row or column of the other table. Both tables are latin
squares. For larger bit strings, the tables look even more different
from each other.
--
From: [EMAIL PROTECTED]
Subject: Re: GeekPress: Will Cyber Criminals Run the World?
Date: Mon, 19 Jun 2000 19:14:25 GMT
In article <[EMAIL PROTECTED]>,
Mike Rosing <[EMAIL PROTECTED]> wrote:
> zapzing wrote:
> > Hmmm ... $10K? Well I was thinking more in
> > the range of 100-200 dollars. I don't
> > need to do several Mbits per second, only
> > say about 1/100 of that.
>
> It's pretty reasonabl price for IP. You can probably put it into
> $5 chips. It's $7.5k for DES, and $10k for 3DES. The cost per
> chip works out to 10k + n*5 = n*C. For an effective cost of $10/chip
> you need 2000 chips. Most markets are larger than that. Maybe
> you can piggy back off of someone else?
If he wants to use a HDL based design, there are several free DES
cores available. Off the top of my head, there's one at
http://www.free-ip.com, and another in the book describing the EFF DES
cracker.
Pete
Sent via Deja.com http://www.deja.com/
Before you buy.
--
From: James Felling <[EMAIL PROTECTED]>
Subject: Re: Random sboxes... real info
Date: Mon, 19 Jun 2000 14:24:13 -0500
"SCOTT19U.ZIP_GUY" wrote:
> [EMAIL PROTECTED] (Tim Tyler) wrote in <[EMAIL PROTECTED]>:
>
> >David A. Wagner <[EMAIL PROTECTED]> wrote:
> >
> >: Nope, I stand by my statement.
> >
> >Yes. Drat ;-) It turns out it was me who was dreaming :-|
> >
> >I should obviously have realised this myself the first time around.
> >
> >I'll have to mentally mark this area as one where my intuition is
> >likely to lead me astray unless I am cautious.
> >
> >My apologies for exposing everyone to what turns out to have been pretty
> >mindless blathering on the subject.
>
> Tim that shows your more of a man than "David A. Wagner" who falsely
> stated his "Slide Attack" has destroyed scott16u.zip and later only
> vagley admitted that he could not be really bothered to look at the
> C code when people tried to find a weakness in my method amd it was not
> there when they tried to use his weak methods.
> I assime you would also state that you are wrong about 1-1 compression
> if you ever saw that it was bad. But Mr wagner is so full of it, That
> he falsely assumes that there is no advantage to 1-1 compression since
> I seem to be the first one to right about it and he like so many people
> with an over inflated ego think they no everything. So don't worry about
> this one point learn from it and go on. But it least no that Wagner lacks
> a lot of what you know about compression.
>
> http://members.xoom.com/ecil
Umm.. As someone who saw that exchange what he said was that "From what he
had seen of your algorithim, it looked like a slide attack would work against
it. He upon closer examination realized that the algo had structure in it
that would prevent the attack and retracted his statement.
--
From: James Felling <[EMAIL PROTECTED]>
Subject: Re: Cipher design a fading field?
Date: Mon, 19 Jun 2000 14:34:43 -0500
Yep. We can show the existence of a program that could do what we need to
do, but showing it exists, is kind of like saying given this finite OTP
encoded message we can decode it guarantably, as we simply list all
possible n-bit messages. While this is true, the problem that exists is
plucking the apropriate program from the pool of possible programs. I
postulate that this selection process will be impossible given a
sulficiently robust language submited to our UTM.
Alan Braggins wrote:
> "Douglas A. Gwyn" <[EMAIL PROTECTED]> writes:
> > for any given example program P there is a deterministic method M
> > that cre
Cryptography-Digest Digest #63
Cryptography-Digest Digest #63, Volume #12 Mon, 19 Jun 00 15:13:01 EDT
Contents:
Re: test prog !! (Mark Wooding)
Re: Comments/analysis requested: stream cipher derived from hash function (SHA-1)
(Lon Willett)
Re: Mathematical formula (Darren New)
Re: GF Math problems (mulinv) (Mike Rosing)
Re: Mathematical formula (Simon Johnson)
Re: small subgroups in Blum Blum Shub (Terry Ritter)
Re: XOR versur MOD (Mok-Kong Shen)
Re: Flattening of frequency distributions (Mok-Kong Shen)
Re: Online Text Encryption (Terry Ritter)
Re: Newbie: germans please: field == Koerper ? (math) (Christof Paar)
Re: GF Math problems (mulinv) (tomstd)
Re: software protection schemes ("John E. Kuslich")
Re: Weight of Digital Signatures (Paul Koning)
From: [EMAIL PROTECTED] (Mark Wooding)
Subject: Re: test prog !!
Date: 19 Jun 2000 16:46:06 GMT
[EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> i seek also maurers test prog in c if possible or executable msdos !!!
Catacomb 2.0.0pre1 has code for doing Maurer's test (maurer.c). I
implemented from the description in Menezes, van Oorshott and Vanstone's
Handbook of Applied Cryptography.
I'm not *entirely* convinced it's working right. I occasionally get
*very* badly skewed results -- I've seen some as far off as seven
standard deviations! -- for 2- and especially 1-bit blocks, even with
generators I'd expect to be good, such as the BBS.
Hmm. Does anyone have some good test vectors for Maurer's test using
single bits, giving the final ought-to-be-distributed-according-to-
N(0, 1) variable Z_u?
-- [mdw]
--
From: Lon Willett <[EMAIL PROTECTED]>
Crossposted-To: sci.crypt.random-numbers
Subject: Re: Comments/analysis requested: stream cipher derived from hash function
(SHA-1)
Date: Mon, 19 Jun 2000 16:58:26 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> In sci.crypt.random-numbers Lon Willett <[EMAIL PROTECTED]> wrote:
>
> :> I removed the XOR of the output with H[i+1], because it allows
state
> :> following attacks (what you called iterative guessing attacks
above)
> :> if each H value is of low entropy, and all E values are of zero
entropy.
> :> If you're concerned with this type of attack, it's better to mix in
> :> entropy only in fairly large chunks.
>
> : Good point. But a very tricky situation, and I'm not sure that I
got it
> : wrong. In order to know how many "H" values one should collect
before
> : mixing them in, one has to have a reasonable estimate of the entropy
> : that they contain. If the hardware RNG is working correctly, then
my
> : approach is fine. If it is defective or sabotaged, how can one
estimate
> : the entropy they contain? The safest assumption is that they
contain
> : zero entropy. And in that case, nothing is lost by mixing them in
> : immediately.
>
> This sounds dubious to me - though I'm not sure I'm following it all
> correctly ;-)
>
> I don't think you should not assume H contains zero entropy. If it
> contains zero entropy, once the state is learned, it's known for all
time
> (determinism).
>
> OTOH, if H contains a small quantity of entropy, you can /potentially/
> defeat an attacker who has learned the state by accumulating the
entropy -
> and then performing the infamous "catastrophic reseeding".
>
> If you dripple the entropy into the system as you go along then the
> attacker can perform the "state following" attack to maintain his
> knowledge of the internal state by repeated guesswork.
>
> The problem of estimating the entropy of the inputs is a significant
one
> - but the idea that the solution is to assume they have zero entropy -
> and not bother with entropy accumulation methods - on the grounds that
> you never know for certain when you have enough entropy - seems very
> questionable.
> --
> __ Lotus Artificial Life http://alife.co.uk/ [EMAIL PROTECTED]
> |im |yler The Mandala Centre http://mandala.co.uk/ I'm pink :.
I'm spam
>
I probably shouldn't have put the "H" values in at all; they are
irrelevant to the questions I'm interested in. :-(
But to continue on this tangent...
This discussion has made me think about it more, and I'm still
convinced that the hardware RNG output should have special handling
(along the lines of what I am doing).
What you seem to be misunderstanding, is that the "H" values are not
the sole source of entropy; they are entropy from some special
hardware RNG. I have "E" values which are the more typical (portable)
miscellaneous sources of entropy. Everything you said is valid for
the "E" values. I specifically avoid introducing them until they are
believed to have accumulated sufficient (160+ bits) entropy. And
indeed, getting these values and estimating their entropy is the
hardest part of writing a decent RNG.
As for my separate handling of "H" and "E", consider the nature of a
hardware RNG. When one has a hardware RNG, an
Cryptography-Digest Digest #62
Cryptography-Digest Digest #62, Volume #12 Mon, 19 Jun 00 12:13:00 EDT
Contents:
Re: Flattening of frequency distributions (Stefan Schlott)
Re: Flattening of frequency distributions (Stefan Schlott)
Re: AWFUL PUN (was: Why the golden ratio?) (John Savard)
Re: Comments please: A protocol for Digital voting (Roadkill)
Re: Observer 4/6/2000: "Your privacy ends here" ("Anarchist Lemming")
Re: XOR versur MOD ("Tony T. Warnock")
Re: Mixing Xor and Addition ("Tony T. Warnock")
Re: Mixing Xor and Addition ("Tony T. Warnock")
Re: AWFUL PUN (was: Why the golden ratio?) ("Tony T. Warnock")
Re: Equally like bit-flips in a Gray code? ("Tony T. Warnock")
Re: New Hash Function (Runu Knips)
Re: Random sboxes... real info (Runu Knips)
Re: New Hash Function (tomstd)
Re: Random sboxes... real info (John Myre)
Newbie: germans please: field == Koerper ? (math) (Runu Knips)
Re: AWFUL PUN (was: Why the golden ratio?) (Richard Carr)
Re: New Hash Function (Runu Knips)
Re: Extending LFSR.. ("Trevor L. Jackson, III")
Re: Online Text Encryption ("Trevor L. Jackson, III")
Re: New Hash Function (tomstd)
Re: Crypto patentability (Paul Koning)
From: [EMAIL PROTECTED] (Stefan Schlott)
Subject: Re: Flattening of frequency distributions
Reply-To: [EMAIL PROTECTED] (Stefan Schlott)
Date: 19 Jun 2000 15:23:12 +0100
On Sat, 17 Jun 2000 12:24:02 -0700,
tomstd <[EMAIL PROTECTED]> wrote:
>>What about compression? Compression algorithms replace common
>>symbols with a short, and rare symbols with a long notation.
>>This should flatten your distributions (and reduce the amount
>>of data to be encrypted).
>You didn't solve the problem, just moved it. Biases in
>relatively high entropy messages that your codec can't compress
>will still show thru.
True. This case will depend on the codec used and the size of the compression
window.
The original posting referred to "natural language", so imho most common
compression codecs should do the trick. If you want to process high entropy
data, you will have to use a cryptographically strong prng. If you keep the
prng seed in secret, you have an encryption of its own :-)
Stefan.
--
From: [EMAIL PROTECTED] (Stefan Schlott)
Subject: Re: Flattening of frequency distributions
Reply-To: [EMAIL PROTECTED] (Stefan Schlott)
Date: 19 Jun 2000 15:23:13 +0100
On Sun, 18 Jun 2000 01:48:41 +0200,
Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
>> What about compression? Compression algorithms replace common
>> symbols with a short, and rare symbols with a long notation.
>> This should flatten your distributions (and reduce the amount
>A normal compression algorithm doesn't have a secret key, thus
>the opponent can decompress just as well as the legitimate
>receiver.
That's what the following encryption process is for.
>Thus it adds practically nothing to the difficulty of his
>task.What we want is flattening that he can't (or with difficulty)
>figure out how to undo in order to recover the original plaintext.
You asked for a way to flatten distributions in natural language,
because exploiting uneven distributions are a classic tool of crypt-
analysis.
Compressing your text before encrypting it will do that. You might
run into trouble with data which cannot be compressed with the codec
in use. Further (as I already mentioned), special care should be given
when storing the data necessary for decompression; when not done
properly, this will lead to known-plaintext attacks.
Stefan.
--
From: [EMAIL PROTECTED] (John Savard)
Crossposted-To: sci.math
Subject: Re: AWFUL PUN (was: Why the golden ratio?)
Date: Mon, 19 Jun 2000 13:23:11 GMT
On Mon, 19 Jun 2000 08:05:42 -0400, "G. A. Edgar"
<[EMAIL PROTECTED]> wrote, in part:
>Well, perhaps if you had meant G. H. Hardy we sould have got it.
Actually, that's what I originally thought, but I had seen the other
initials in an article on Ramanujan, and so I thought that perhaps G.
H. Hardy was a mystery writer or something...or, perhaps I am all wet,
and Ramanujan was discovered, and "A Mathematician's Apology" was
written, by two different mathematicians (perhaps father and son).
Somehow, I doubt that.
John Savard (teneerf <-)
http://www.ecn.ab.ca/~jsavard/
--
Date: 19 Jun 2000 13:48:41 -
From: Roadkill <[EMAIL PROTECTED]>
Subject: Re: Comments please: A protocol for Digital voting
=BEGIN PGP SIGNED MESSAGE=
zzapzing wrote:
> I have also noticed that this protocol is unnecessarily
> complex in at least one aspect. That is, the multiple
> validations that are done by a long string of remailers, in
> order to eventually get I validated. Let me explain a simpler
> way to do this.
I figured that there should be a few bits reserved for a checksum in I
because otherwise check(v(I)) would just result in unverifyable random
bits. It isn't so that each remai
Cryptography-Digest Digest #61
Cryptography-Digest Digest #61, Volume #12 Mon, 19 Jun 00 09:13:01 EDT
Contents:
Re: Q: Equally like bit-flips in a Gray code? (Tim Tyler)
Re: Extending LFSR.. (Tim Tyler)
Re: Extending LFSR.. (Tim Tyler)
Re: Comments please: A protocol for Digital voting (Roadkill)
Re: XOR versur MOD (Zulfikar Ramzan)
Re: AWFUL PUN (was: Why the golden ratio?) (anonymous)
Re: XOR versur MOD (Runu Knips)
Re: XOR versur MOD (tomstd)
Re: Online Text Encryption ("Dan Coyle")
Re: Mixing Xor and Addition ("Al Grant")
Re: Random sboxes... real info (Roger Carbol)
Re: Logical attack on RSA (DJohn37050)
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Q: Equally like bit-flips in a Gray code?
Reply-To: [EMAIL PROTECTED]
Date: Mon, 19 Jun 2000 11:24:13 GMT
Guy Macon <[EMAIL PROTECTED]> wrote:
: M Joonas Pihlaja wrote:
:>I'm trying to find a Gray code in which each bit is 'equally
:>likely' to change between adjacent code words. Well, more likely
:>than in the the usual (ix+1)^(ix>>1) code at least. [...]
: Here is how to get as close as you can get for a 0 to 9 code.
: [1] Some random bit sequence = 0
: [2] Flip a random bit.
: Result = 1
: [3] Flip a random bit.
: Discard and repeat if result is already in use.
: Result = 2
: (Repeat until you reach 9)
Surely there's no reason to think that this will produce an equal
frequency (or as near to this as is possible) of bit-flips.
I suspect this only works at all because it 0-9 doesn't completely fill up
a 4-bit space.
For longer sequences - or where there's less wasted space - there doesn't
appear to be a guarantee that this process will terminate.
--
__ Lotus Artificial Life http://alife.co.uk/ [EMAIL PROTECTED]
|im |yler The Mandala Centre http://mandala.co.uk/ Breast is best.
--
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Extending LFSR..
Reply-To: [EMAIL PROTECTED]
Date: Mon, 19 Jun 2000 11:29:39 GMT
Simon Johnson <[EMAIL PROTECTED]> wrote:
: Since i am no longer working in GF(2) but in some GF(p). I could
: use primes as the exponents, provided they are smaller than the
: new modulo. For example:
: x^31 + x^17 + x^13 + x^7 + x^3 + x^2 mod 257
: Would be primitive, and once converted to a LFSR would result in
: a period which is the maximum allowed?
: Instinct tell me this period is 257^31?
This won't be the period. LFSRs never completely span the possible state
space - since they always omit the all-zero state.
--
__ Lotus Artificial Life http://alife.co.uk/ [EMAIL PROTECTED]
|im |yler The Mandala Centre http://mandala.co.uk/ Goodbye cool world.
--
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Extending LFSR..
Reply-To: [EMAIL PROTECTED]
Date: Mon, 19 Jun 2000 11:35:05 GMT
Brian McKeever <[EMAIL PROTECTED]> wrote:
[Re: Any thoughts about the period?]
: All the theorems still apply - primitive polynomial implies a period of
: p^n -1 (and the zero fixed point).
Indeed. From "Shift Register Sequences", p.36:
``Anywhere in this chapter where "mod 2" has been used, a similar
discussion applies to the more general "mod m" case. [...]
Such a shift register will have a period of m^r - 1 or less.''
--
__ Lotus Artificial Life http://alife.co.uk/ [EMAIL PROTECTED]
|im |yler The Mandala Centre http://mandala.co.uk/ I'm pink :. I'm spam
--
Date: 19 Jun 2000 12:18:55 -
From: Roadkill <[EMAIL PROTECTED]>
Subject: Re: Comments please: A protocol for Digital voting
=BEGIN PGP SIGNED MESSAGE=
Mok-Kong Shen wrote:
>
> Roadkill wrote:
>
> > First, secure random numbers are generated and (securely) distributed
> > among voters. These numbers are your ticket into the voting booth and
> > they must be large enough to ensure that they can't be guessed by
> > cheaters (like 256 bits, that's a snowflakes chance in hell to guess
> > correctly, even if there are more than 6.000.000.000 or about 2^32
> > voters). Software ensures that noone is given the same number as
> > somebody else. (Not quite unlike the 'token' in www.Freedom.net)
>
> I have a bunch of questions:
> How do you actually distribute the numbers to the people? Via normal
> post or other means? Are you sure that the way from you to the voter
> is absolutely secure? What happens, if the voter stores the number at
> a not absolutely secure place and someone gets a copy? Do you
> check that the person getting a number is a legitimate voter? How?
> How do you ensure that nobody gets two numbers and every legitimate
> voter gets one?
First I want to apologize for the late reply. I'm relatively new to nym
servers and something went wrong with my original reply. I format these
messages by hand and I lost the original message. Yesterday I had a
family happening (very nice), so here is my second try ;-)
What I think must h
Cryptography-Digest Digest #60
Cryptography-Digest Digest #60, Volume #12 Mon, 19 Jun 00 08:13:01 EDT
Contents:
Re: LSFR, a character twist (Simon Johnson)
Re: Observer 4/6/2000: "Your privacy ends here" (Peter G. Strangman)
Re: small subgroups in Blum Blum Shub (Mok-Kong Shen)
Re: Weight of Digital Signatures (Mok-Kong Shen)
On utilizing entropy in natural language texts (Mok-Kong Shen)
Re: Equally like bit-flips in a Gray code? (Mok-Kong Shen)
Re: On using compression as proper means of encryption (Mok-Kong Shen)
Forgot ZIP File password. (Pranshu Singhal)
Re: Forgot ZIP File password. (JPeschel)
BeeCrypt 1.0.1 released. (Bob Deblier)
Re: Cipher design a fading field? (Alan Braggins)
Re: small subgroups in Blum Blum Shub (Mark Wooding)
Re: How RSA SecurID tokens work? (Daniel James)
Re: Observer 4/6/2000: "Your privacy ends here" ("Anarchist Lemming")
Re: XOR versur MOD (Mark Wooding)
Re: Observer 4/6/2000: "Your privacy ends here" (Therion Ware)
Re: AWFUL PUN (was: Why the golden ratio?) ("G. A. Edgar")
Subject: Re: LSFR, a character twist
From: Simon Johnson <[EMAIL PROTECTED]>
Date: Mon, 19 Jun 2000 01:34:22 -0700
Before Tom kills you, be sure to use *LFSR* instead of _LSFR_.
Don't worry, i have also comitted such a sin.
Got questions? Get answers over the phone at Keen.com.
Up to 100 minutes free!
http://www.keen.com
--
From: Peter G. Strangman <[EMAIL PROTECTED]>
Crossposted-To:
uk.media.newspapers,uk.legal,alt.security.pgp,alt.privacy,uk.politics.parliament,uk.politics.crime,talk.politics.crypto,alt.ph.uk,alt.conspiracy.spy,alt.security.scramdisk,uk.telecom
Subject: Re: Observer 4/6/2000: "Your privacy ends here"
Date: Mon, 19 Jun 2000 09:35:21 +0100
Reply-To: [EMAIL PROTECTED]
On Fri, 16 Jun 2000 12:03:48 +0100, "Darren Rhodes"
<[EMAIL PROTECTED]> wrote:
> I tried to access the Shayler web site listed below but could not. This was
> said to be due to an HTTP error 403 - Forbidden.
> Has anyone had a similar experience?
> Is this due to my ISP Globalnet?
"403 forbidden" means precisely that. It also means that
the client should not retry the URL and that trying with
a password will not help.
It is NOT an error. It is a specific return code indicating,
VERY clearly, that the client is not allowed access.
--
Peter G. Strangman | Leser, wie gefall ich dir?
[EMAIL PROTECTED] | Leser, wie gefaellst du mir?
http://www.adelheid.demon.co.uk | (Friedrich von Logau)
XLIV-VII-DCCCII-CCXII-DCCCXXXI |
--
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: small subgroups in Blum Blum Shub
Date: Mon, 19 Jun 2000 10:56:15 +0200
Terry Ritter wrote:
> [EMAIL PROTECTED] (David A. Wagner) wrote:
>
> >You can never rule out the chance that the attacker gets lucky and guesses
> >your private key correctly. It's simply unavoidable.
>
> Fine, but the issue here is weakness *beyond* guessing the key. It is
> the (theoretical) possibility that a stream cipher is using a
> generator with a short cycle. It is the possibility that, having
> deciphered only the short cycle, the attacker can now run that
> repeating sequence through the end of the message without further
> work.
I am not commenting on the chance of using a 'weak key' but like
to mention that for a sequence from a non-linear generator there
is normally an initial segment (which could be long) followed by
a loop, so that the chance of getting problems due to the loop is
likely to be higher if one uses longer sequences from the generator.
M. K. Shen
--
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Weight of Digital Signatures
Date: Mon, 19 Jun 2000 10:56:20 +0200
Lyalc wrote:
> The subtext of many of the press reports is that 'equally binding' implies a
> similar level of supporting infrastructure is required to allow relying
> parties to have a similar level of confidence in the received data.
>
> A single technology, on it's one, has never provided a secure solution, nor
> a reliable one.
I think that a technology's usefulness depends on a wide range of
factors, including risk, which at least partly involves one's subjective
reasoning. With time, the implementations get improved, but then the
users' (unsatiable) expections grow also. Economy seems to be the
principle governing issue. Often competing (parallel) technologies can
co-exist but users' preference could also be influenced by psychology
or other non-technical, sometimes even quite irrational, reasons.
M. K. Shen
--
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: On utilizing entropy in natural language texts
Date: Mon, 19 Jun 2000 10:56:52 +0200
As stated in Schneir's AC, an ASCII message that is nothing
more than printed English has 1.3 bits of information per
byte of message. This implies that, if one appropriately
concentrates the
Cryptography-Digest Digest #59
Cryptography-Digest Digest #59, Volume #12 Mon, 19 Jun 00 04:13:01 EDT
Contents:
Re: Comments please: A protocol for Digital voting (zzapzing)
Re: Is Gretchen down? (Patrick Farrell)
Mathematical formula ("Yuriy Stul")
Re: Extending LFSR.. (Simon Johnson)
Re: Extending LFSR.. (Simon Johnson)
Re: Mathematical formula (Mack)
Re: XOR versur MOD (Mack)
Question about lja1 (Benjamin Goldberg)
Re: XOR versur MOD (Simon Johnson)
Re: Extending LFSR.. (Simon Johnson)
Re: Mathematical formula ("Douglas A. Gwyn")
Re: Mathematical formula (Simon Johnson)
Re: small subgroups in Blum Blum Shub (David A. Wagner)
Re: Encryption routine anyone? (Bob Deblier)
Re: Logical attack on RSA ("Michael Brown")
Re: software protection schemes (wtshaw)
Re: LSFR, a character twist (wtshaw)
Subject: Re: Comments please: A protocol for Digital voting
From: zzapzing <[EMAIL PROTECTED]>
Date: Sun, 18 Jun 2000 20:37:39 -0700
Let's call the random number generated by the validator V
and the random string generated by the individual voter I.
I have noticed a few more "aspects" of your protocol which
might be considered weaknesses. First of all the
validator can disenfranchize anyone he pleases by refusing
to recognize his value of V as valid, or by sending him
some random numbers instead of a validation of I. The
disenfranchized voter will not be able to prove that he was
disenfranchized. Also the validator could disenfranchize a
voter after the vote is cast by refusing to publish the
voters vote in the list of valid votes. The voter would of
course be aware that this had occured but would not ba able
to prove it to anyone else without sacrificing his anonymity.
and noone else would ever suspect that it occured if he did
not object. These acould be problems which could not possibly
be overcome, its true, but the potential weaknesses of any
protocol should be made apparent (in other words, nothing
personal).
I have also noticed that this protocol is unnecessarily
complex in at least one aspect. That is, the multiple
validations that are done by a long string of remailers, in
order to eventually get I validated. Let me explain a simpler
way to do this.
First of all, each voter puts his individual string, I into
an electronic envelope. Let e(I) denote this. This is the
same as your protocol. Next, the voter sends, through
anonymous broadcast, the pair V,e(I) to the validator. the
validator checks V against his list and then validates e(I)
inside its electronic envelope. Call the result of this
v(e(I)). the validator publishes a list of all the values of
V along with their corresponding values of v(e(I)). The
voters find their V values in this list and read off their
corresponding v(e(I)) value, from which they calculate their
individual value of v(I) (by removing the elctronic envelope).
The voters send in their votes along with their v(I). I
believe this would result in less traffic and computation but
have the same security features as the procedure you proposed.
that said, the protocol could possibly be used for a very
large number of voters, Not all voting protocols can do more
than, say 100 people with present technology.
Got questions? Get answers over the phone at Keen.com.
Up to 100 minutes free!
http://www.keen.com
--
From: Patrick Farrell <[EMAIL PROTECTED]>
Crossposted-To:
alt.security.pgp,comp.security.firewalls,alt.privacy.anon-server,alt.privacy
Subject: Re: Is Gretchen down?
Date: Mon, 19 Jun 2000 00:00:57 -0500
Reply-To: [EMAIL PROTECTED]
It would in theory show up in the trace routes if you did that however.
Patrick
"Trevor L. Jackson, III" wrote:
>
> I still think you have the difficulty ordering backward. "...slap another set of
>wires on
> ..." is a non-trivial operation when you are dealing with trans-oceanic wires. Yet
>in the
> digital world setting up another virtual circuit is no big deal.
>
> Patrick Farrell wrote:
>
> > Perhaps I grossly misunderstand the way a telegraph worked, but in my opinion
> > your comparing hooking up 2 phones on an analog phone system to 2 on a digital
> > system. In the first case, you just slap another set of wires on, in the
> > second, you can't. (Can't as in just hooking it up won't work)
> >
> > Patrick
> >
> > "Trevor L. Jackson, III" wrote:
> > >
> > > Patrick Farrell wrote:
> > >
> > > > A telegraph signal does not fall into the same category as a high speed network
> > > > device.
> > >
> > > Correct.
> > > Duplicating telegrams required a massive amount of human effort. Rerouting or
>T'ing a
> > > high speed network can be done without a man in the loop, so it's drastically
>easier.
> > >
> > > > Hell if you add a little impedance to a 100baseT cable it will fail,
> > > > yet I saw someone stick 2 computers back to back with arcnet cards in them and
> > > > put a coat hanger in between and netw
