Cryptography-Digest Digest #833, Volume #13 Thu, 8 Mar 01 01:13:01 EST
Contents:
Really simple stream cipher ("Henrick Hellstr�m")
Re: Really simple stream cipher ("Tom St Denis")
Re: hardwire prime & generator in Diffie-Hellman? ("Tom St Denis")
Re: The Foolish Dozen or so in This News Group (Benjamin Goldberg)
Re: Voting (Benjamin Goldberg)
Re: The Foolish Dozen or so in This News Group ("Tom St Denis")
Re: PKI and Non-repudiation practicalities ("Lyalc")
Re: Really simple stream cipher ("Scott Fluhrer")
Re: Super strong crypto (David Wagner)
Re: The Foolish Dozen or so in This News Group ("Doom the Mostly Harmless")
Re: The Foolish Dozen or so in This News Group (Eric Lee Green)
Re: Monty Hall problem (was Re: philosophical question?) (Virgil)
Re: => FBI easily cracks encryption ...? ("Mxsmanic")
----------------------------------------------------------------------------
From: "Henrick Hellstr�m" <[EMAIL PROTECTED]>
Subject: Really simple stream cipher
Date: Thu, 8 Mar 2001 04:12:18 +0100
The stream cipher described below has some interesting properties. Firstly,
AEnc is infinitely error propagating past a single error. Secondly, BEnc is
such that for any value of any triplet of the parameters V,K,P,C, there is
value of the fourth parameter such that the relation BEnc(V,K,P,C) is valid.
Thirdly, CEnc is a trivial implementation of Douglas A Gwyn's recent
proposal.
As far as I can tell, CEnc is provably secure against almost any attack from
a computationally unbounded adversary. A known or chosen plain text will not
recover the key, provided that the RNG function is completely unpredictable.
A chosen plain text attack against a single 128-bit block will set off error
propagation, and the probability that the vector V will recover is equal to
2**-64 per each 128-bit cipher text block (due to the possibility that the
error in the key K transmitted as part of that block will put the vector V
back on track).
There is probably something I haven't thought of. The cipher is so simple I
am sure someone is willing to enlighten me. ;-)
Algo AEnc:
Input qword V, K; dword P
Output qword V, dword C
1. V[1] := V[1] + V[0]
2. V := V xor K
3. C := P xor V[0]
4. V[0] := V[1]; V[1] := C
Algo BEnc:
Input qword V,K,P
Output qword V,C
1. AEnc(V,K,P[0],C[0])
2. AEnc(V,K,P[1],C[1])
Algo CEnc:
Input qword V,K,P
Output qword V,K; 128-bit value C
1. BEnc(V,K,P,C[1]|C[0])
2. qword R := RNG
3. BEnc(V,K,R,C[3]|C[2])
4. K := R
--
Henrick Hellstr�m [EMAIL PROTECTED]
StreamSec HB http://www.streamsec.com
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: Really simple stream cipher
Date: Thu, 08 Mar 2001 03:15:27 GMT
"Henrick Hellstr�m" <[EMAIL PROTECTED]> wrote in message
news:986t9e$7v4$[EMAIL PROTECTED]...
> The stream cipher described below has some interesting properties.
Firstly,
> AEnc is infinitely error propagating past a single error. Secondly, BEnc
is
> such that for any value of any triplet of the parameters V,K,P,C, there is
> value of the fourth parameter such that the relation BEnc(V,K,P,C) is
valid.
> Thirdly, CEnc is a trivial implementation of Douglas A Gwyn's recent
> proposal.
>
> As far as I can tell, CEnc is provably secure against almost any attack
from
> a computationally unbounded adversary. A known or chosen plain text will
not
> recover the key, provided that the RNG function is completely
unpredictable.
> A chosen plain text attack against a single 128-bit block will set off
error
> propagation, and the probability that the vector V will recover is equal
to
> 2**-64 per each 128-bit cipher text block (due to the possibility that the
> error in the key K transmitted as part of that block will put the vector V
> back on track).
>
> There is probably something I haven't thought of. The cipher is so simple
I
> am sure someone is willing to enlighten me. ;-)
>
>
> Algo AEnc:
>
> Input qword V, K; dword P
> Output qword V, dword C
>
> 1. V[1] := V[1] + V[0]
> 2. V := V xor K
> 3. C := P xor V[0]
> 4. V[0] := V[1]; V[1] := C
This is wholly linear and weak to differential and linear attacks.
>
> Algo BEnc:
>
> Input qword V,K,P
> Output qword V,C
>
> 1. AEnc(V,K,P[0],C[0])
> 2. AEnc(V,K,P[1],C[1])
So is this.
> Algo CEnc:
>
> Input qword V,K,P
> Output qword V,K; 128-bit value C
>
> 1. BEnc(V,K,P,C[1]|C[0])
> 2. qword R := RNG
> 3. BEnc(V,K,R,C[3]|C[2])
> 4. K := R
And so is this.
Tom
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: hardwire prime & generator in Diffie-Hellman?
Date: Thu, 08 Mar 2001 03:17:15 GMT
"Julian Morrison" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> "Tom St Denis" <[EMAIL PROTECTED]> wrote:
>
> > No per key you generate.
>
> Right, and so essentially if I set it to re-negotiate after one less than
> sqrt((p-1)/2) uses of a given key, it's safe?
Actually I made up sqrt((p-1)/2) I wanted to see if anyone would notice.
Typically you can't make enough keys to find a collision if your prime is
big enough.
> As I'm planning it, each key is only ever used once, to seed Arcfour. From
> then on, the Arcfour state persists at both ends (that is, I don't re-key
> it each time, I just pick it up where it left off).
Ok then it's not likely to be an issue. But I would want to fix a private
key for each user...
Tom
------------------------------
From: Benjamin Goldberg <[EMAIL PROTECTED]>
Crossposted-To: alt.hacker
Subject: Re: The Foolish Dozen or so in This News Group
Date: Thu, 08 Mar 2001 03:29:18 GMT
Anthony Stephen Szopa wrote:
[snip]
> Here is a test that I just carried out.
>
> I took a blank floppy and I copied one file that was 859KB to it
> then I copied another file to this same floppy that was 322KB.
> Then I created an OverChk2.txt file to flag the process after just
> two passes. This should be enough to prove my points.
Considering that write-behind is only done on the hdd, not on floppies,
I don't see what this is supposed to prove.
> Then I ran the original OverWrite Program Version 1.0 and overwrote
> the larger 859KB file. After the second pass the OverChk2 flag file
> was detected and the process ended.
Let's pretend you were doing this on a hdd. How do you know that when
you've "detected" the OverChk2 file, it actually exists on the hdd, not
just in the computer's cache?
> I did a file compare on the 322KB file with its original file and
> there were no differences.
Write-behind is always handled so that it is totally invisible to the
user, except for speed. It should be impossible to detect that your
requested writes are only being done in memory, and not on the drive
(unless you pull the plug, and see after reboot that the write which you
/thought/ you did, didn't actually occur yet).
> I then used the Read Utility from the OAP-L3 (OAR-L3) software and
> the file was overwritten completely with binary 170 just as it should
> be after two overwrite passes.
How do you know that you aren't merely reading the memory buffers,
rather than the disk? Well, actually, since write-behind is only done
on the hdd, not the floppy, you do know that it's being read from the
floppy, so never mind this question.
> Once the OverWrite program was loaded there were no hard drive
> accesses. There were only continuous floppy drive accesses. You
> could see the access light and hear the drive writing all the while.
> You could even hear the distinct sound when the write head had to
> track back to the beginning of the file to begin the second pass.
As I said, the floppy doesn't do write behind.
> What does this show: the OS had no need to work in secondary cache
> as evidenced from there being no hard drive accesses.
Lack of hdd accesses has nothing to do with cache. Lack of hdd access
DOES show that no access to swap is made. Don't get those two confused.
Your computer has multiple levels of cache: L1 cache (small, fast,
physically on the cpu), L2 cache (larger, slower (but still fast), also
on the cpu), main memory (various cards plugged into the bus), and swap
(this is on the hdd).
The lack of hdd accesses when using OverWrite on a floppy shows that the
entire program fits into main memory, without any of it needing to go
into swap space. This has nothing whatsoever to do with io buffering.
> The OS did not utilize any cache because you could see and hear that
> the floppy write process was continuous for two write passes.
Write-behind is not done on removable media. When write through is
done, io buffers may remain in main memory for up to 30 seconds (IIRC),
and write-behind were done with floppies, someone might eject it after
the write() operation completed but before it was actually written.
Since you can't eject your hdd, write-behind is safe.
[snip nonsense]
> Do any of you dispute this floppy drive test?
Yes. It only shows that your program appears to work on floppies, where
no write-behind actually occurs. Also, floppies are cheap enough that
if you want to securely destroy data on one, you can simply run it
through a shredder, or burn it.
--
The difference between theory and practice is that in theory, theory and
practice are identical, but in practice, they are not.
------------------------------
From: Benjamin Goldberg <[EMAIL PROTECTED]>
Subject: Re: Voting
Date: Thu, 08 Mar 2001 03:38:06 GMT
Paul Rubin wrote:
>
> Benjamin Goldberg <[EMAIL PROTECTED]> writes:
> > The voting machines in NY, while a bit old, fit this requirement
> > quite well. However, I will admit that there are some ways
> > improvements could be made. The NY machines have (IIRC) a
> > mechanical counter, which has an odometer-like display.
>
> I bet by mounting a small hidden microphone on or near one of those
> machines, you could tell who was being voted for, because the internal
> levers make different sounds. So much for the secret ballot.
Is that so different from someone mounting a TEMPEST type attack?
Or what about inserting a snoop program into the digital component of a
fully electronic voting booth.
Yes, attacks exist, but we can protect against them. If the gearing of
all the levers is nearly identical, except for position, then there is
little or no distinction between the sounds they make.
How about this: The voting booth is wholly electronic, and you push a
button for whichever candidate you want. A light goes on to show you
that you actually pushed the button. What keeps someone from inserting
a transmitter in the circuit with the light? Nothing, except
inspections and emmissions shielding.
Or to put it all much more simply, "Ok, so someone sticks in a mic. How
does it send a signal out past the anti-TEMPEST shielding?"
--
The difference between theory and practice is that in theory, theory and
practice are identical, but in practice, they are not.
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Crossposted-To: alt.hacker
Subject: Re: The Foolish Dozen or so in This News Group
Date: Thu, 08 Mar 2001 04:01:15 GMT
"Anthony Stephen Szopa" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> I believe some of you know but were not talking. That's fine.
>
> The issue is the time duration between a write and fclose code
> sequence and an immediately following write and fclose code sequence.
>
> If the time duration is too short then the physical write to the
> hard disk may not take place.
>
> But if sufficient time elapses before the subsequent write fclose
> code sequence then the physical write will take place.
>
> This is the issue's jugular.
>
> I did not find an equivalent sync or fsync in c/c++ or Visual Basic
> yet.
>
> But there is one function and one method in c/c++ to deal with this.
> And there is one component and one method to deal with this is Visual
> Basic.
>
> Although I am not talking either, I did define the specific problem
> for you. Work on it yourself if you are so inclined.
>
> There is an update for Ciphile Software's OverWrite Security Utility
> Version 1.11 available now from the web site. I have also added a
> "NOTE" to the instructions stating in effect that this is only a
> windows program and not suitable to use in a multitasking environment
> or with SCSI drives. Etc.
>
> On one of my systems you can see the hard drive LED light up 27 times
> and hear the grinding of the hard drive as it writes to the disk each
> time.
27 times?
Hmm even if 27 = # of passes the LED would light more than that unless the
file is small.
Still there is no portable way to wipe files.
And do you provide source code so others can verify it?
Tom
------------------------------
From: "Lyalc" <[EMAIL PROTECTED]>
Subject: Re: PKI and Non-repudiation practicalities
Date: Thu, 8 Mar 2001 15:33:40 +1100
>eliminating shared-secrets was the point of the discussion ... and
That challenge PKI faces is translates the shared secret risk ( which is one
to 1) into a shared trust (many to many) situation. Trust in the CA, and
trust you have the real CA certificate in particular are the low hanging
fruit on the PKI trust tree there are others in the infrastructure part of
PKI..
And all of this is a bigger, more expensive challenge than initially
thought, by many orders of magnitude.
Lyal
------------------------------
From: "Scott Fluhrer" <[EMAIL PROTECTED]>
Subject: Re: Really simple stream cipher
Date: Wed, 7 Mar 2001 20:28:40 -0800
Henrick Hellstr�m <[EMAIL PROTECTED]> wrote in message
news:986t9e$7v4$[EMAIL PROTECTED]...
> The stream cipher described below has some interesting properties.
Firstly,
> AEnc is infinitely error propagating past a single error. Secondly, BEnc
is
> such that for any value of any triplet of the parameters V,K,P,C, there is
> value of the fourth parameter such that the relation BEnc(V,K,P,C) is
valid.
> Thirdly, CEnc is a trivial implementation of Douglas A Gwyn's recent
> proposal.
>
> As far as I can tell, CEnc is provably secure against almost any attack
from
> a computationally unbounded adversary. A known or chosen plain text will
not
> recover the key, provided that the RNG function is completely
unpredictable.
> A chosen plain text attack against a single 128-bit block will set off
error
> propagation, and the probability that the vector V will recover is equal
to
> 2**-64 per each 128-bit cipher text block (due to the possibility that the
> error in the key K transmitted as part of that block will put the vector V
> back on track).
Here's how to break this cipher, using a ciphertext-only attack by a
computationally bounded adversary:
- The attacker guesses the lsbits of the initial values of V[0], V[1], K[0],
K[1]. Note that there are only 16 possible guesses.
- For each of these 16 possible guesses, decrypt the ciphertext and produce
the lsbits of the plaintext (looking at the plaintext/ciphertext as a
sequence of 32 bit values). Note that, because the cipher lacks any
diffusion whatsoever from the higher order bits to the lower order bits, he
can do this ambiguously, using essentially the same algorithm as the
intended receiver does.
- Examine the 16 possible sequences of plaintext lsbits, and decide which
one looks most like the lsbits of real plaintext. Note that this is usually
possible, in that the lsbits of a plaintext message usually don't look
particularly random
- Now that you have a good guess at the lsbits of the initial values of
V[0], V[1], K[0], K[1], start in on the second lsbit.
- Repeat until you have all the bits.
Moral of the story: diffusion is a *really* good idea...
>
> There is probably something I haven't thought of. The cipher is so simple
I
> am sure someone is willing to enlighten me. ;-)
>
>
> Algo AEnc:
>
> Input qword V, K; dword P
> Output qword V, dword C
BTW: you really should define "dword" and "qword". They're not standard
terminology. I assume that they're 32 bit and 64 bit values.
>
> 1. V[1] := V[1] + V[0]
> 2. V := V xor K
> 3. C := P xor V[0]
> 4. V[0] := V[1]; V[1] := C
>
>
> Algo BEnc:
>
> Input qword V,K,P
> Output qword V,C
>
> 1. AEnc(V,K,P[0],C[0])
> 2. AEnc(V,K,P[1],C[1])
>
>
> Algo CEnc:
>
> Input qword V,K,P
> Output qword V,K; 128-bit value C
>
> 1. BEnc(V,K,P,C[1]|C[0])
> 2. qword R := RNG
> 3. BEnc(V,K,R,C[3]|C[2])
> 4. K := R
--
poncho
------------------------------
From: [EMAIL PROTECTED] (David Wagner)
Subject: Re: Super strong crypto
Date: 8 Mar 2001 04:42:12 GMT
Reply-To: [EMAIL PROTECTED] (David Wagner)
Douglas A. Gwyn wrote:
>It was never my intent to apply this new mode of operation to
>inherently crappy block encryptions; the idea was to take a
>"fairly good" system [...]
Ok. To help me understand, can you define "fairly good" more precisely,
then? For instance, does "fairly good" imply that the cipher is secure
against all attacks where the adversary knows just a single block of
known-text?
------------------------------
From: "Doom the Mostly Harmless" <[EMAIL PROTECTED]>
Crossposted-To: alt.hacker
Subject: Re: The Foolish Dozen or so in This News Group
Date: Thu, 08 Mar 2001 04:55:27 GMT
> There is an update for Ciphile Software's OverWrite Security Utility
> Version 1.11 available now from the web site. I have also added a
> "NOTE" to the instructions stating in effect that this is only a
> windows program and not suitable to use in a multitasking environment
> or with SCSI drives. Etc.
And there I was trying to multitask in windows the whole time. My bad.
--
To air is human....
--Doom.
------------------------------
From: [EMAIL PROTECTED] (Eric Lee Green)
Crossposted-To: alt.hacker
Subject: Re: The Foolish Dozen or so in This News Group
Reply-To: [EMAIL PROTECTED]
Date: 7 Mar 2001 23:21:54 -0600
On Wed, 07 Mar 2001 19:06:57 -0800, Anthony Stephen Szopa <anthony@ciphile.
com> wrote:
>The issue is the time duration between a write and fclose code
>sequence and an immediately following write and fclose code sequence.
>
>If the time duration is too short then the physical write to the
>hard disk may not take place.
>
>But if sufficient time elapses before the subsequent write fclose
>code sequence then the physical write will take place.
That was another possibility that I thought about. The problem is that
"sufficient time" may be as much as one minute on a machine with a large
amount of memory (the more memory you have, the more Windows will use for
buffer cache). I could not figure any way for a program to *GUARANTEE* that
the write took place.
For floppies, waiting for one full rotation of the floppy drive will
probably suffice to have the controller write out its internal track
buffer. Somebody else will have to remind me what the rotation speed
of a floppy drive is. For IDE hard drives, most IDE hard drives have a
very small buffer. Thus they may only buffer one track of data. Once the
OS has flushed its buffers,
Windows has something similar to 'fsync'. It is a Win32 call, *NOT* a
C++ or "C" function. Check MSDN (msdn.microsoft.com) to see what it
is. My mouse is not working or I'd go do your homework for you (using
a browser without a mouse is excrutiatingly painful, and my mouse is
not going to come back until I reboot the system -- I just rearranged
all my computer equipment without turning anything off, sigh, and my
mousy did not like being unplugged then plugged back in!)
--
Eric Lee Green [EMAIL PROTECTED] http://www.badtux.org
AVOID EVIDENCE ELIMINATOR -- for details, see
http://badtux.org/eric/editorial/scumbags.html
====== Posted via Newsfeeds.Com, Uncensored Usenet News ======
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
======= Over 80,000 Newsgroups = 16 Different Servers! ======
------------------------------
From: Virgil <[EMAIL PROTECTED]>
Crossposted-To: sci.crypt.random-numbers,de.sci.informatik.misc,sci.math
Subject: Re: Monty Hall problem (was Re: philosophical question?)
Date: Wed, 07 Mar 2001 22:34:42 -0700
In article <[EMAIL PROTECTED]>,
Adam Stephanides <[EMAIL PROTECTED]> wrote:
> Another way of putting it is that the standard argument depends upon the
> fact that Monty's opening a door provides no information about whether or
> not the car is behind the door you picked. If assumption 4 does not hold,
> this is no longer true.
>
> --Adam
I disagree.
------------------------------
From: "Mxsmanic" <[EMAIL PROTECTED]>
Crossposted-To: alt.security.pgp,talk.politics.crypto
Subject: Re: => FBI easily cracks encryption ...?
Date: Thu, 08 Mar 2001 05:44:56 GMT
"Matthew Montchalin" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> What is the easiest way to screen yourself (that
> is, your screen) from this sort of unwanted eavesdropping?
Put all your equipment in a metallic, grounded enclosure. Make sure
there are no openings in the encloser larger than half the wavelength of
the shortest wavelength of emanations from your equipment. Simple.
> If you have lots of screens turned on, and lots
> of phone lines going, how can they tell which one
> you are doing stuff with?
By selecting specific frequencies with an antenna that can be aimed; at
least that is one method that comes immediately to mind.
------------------------------
** 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 by posting to sci.crypt.
End of Cryptography-Digest Digest
******************************
