Cryptography-Digest Digest #750, Volume #13 Mon, 26 Feb 01 05:13:01 EST
Contents:
Re: OverWrite freeware completely removes unwanted files from harddrive (Darren New)
Re: CipherText ActiveX OCX available ("Prichard, Chuck")
Re: CipherText ActiveX OCX available ("Prichard, Chuck")
Re: Improved stream cipher? (was: Re: Simple, possibly flawed, stream cipher)
("Scott Fluhrer")
Arcfour in Ada ("Julian Morrison")
Re: Simple, possibly flawed, stream cipher ("Scott Fluhrer")
Re: Simple, possibly flawed, stream cipher ("Scott Fluhrer")
Again on key expansion. ("Cristiano")
Re: Simple, possibly flawed, stream cipher ("Henrick Hellström")
how long can one Arcfour key be used?? ("Julian Morrison")
Re: The Key Vanishes (fwd) (Mok-Kong Shen)
Re: How to find a huge prime(1024 bit?) (Anonymous)
----------------------------------------------------------------------------
From: Darren New <[EMAIL PROTECTED]>
Crossposted-To: alt.hacker
Subject: Re: OverWrite freeware completely removes unwanted files from harddrive
Date: Mon, 26 Feb 2001 02:23:57 GMT
Benjamin Goldberg wrote:
> Curiously, on some unixes, there's a command called "sync" which is
> supposed to make the disk driver write out any buffers it has cached.
Actually, it often merely schedules the disks for immediate writes, and
returns before the data is physically written out.
> There isn't, however, any such command or function in dos/win.
Of course there is.
http://www.sysinternals.com/ntw2k/utilities.shtml
--
Darren New / Senior MTS & Free Radical / Invisible Worlds Inc.
San Diego, CA, USA (PST). Cryptokeys on demand.
"San Diego already has the hilltop villages.
We're just missing the midieval towers."
------------------------------
From: "Prichard, Chuck" <[EMAIL PROTECTED]>
Subject: Re: CipherText ActiveX OCX available
Date: Mon, 26 Feb 2001 02:27:09 GMT
A CipherText Active X (OCX) control and DLL implementation is now
available for BETA testing.
Recent enhancements to the CipherText algorithm affect the PGP mode which
now supports use of alphabetic keys and the consequent offset. A single
pass will apply the key using a simple XOR and the offset.
The algorithm also has an enhanced mode that uses a double cipher,
applying the root key and then a modified key, which may or may not also
contain some mask values rather than those of the root key. This
enhancement improves message integrity when using a restricted (numeric
values only) key domain. No offset is applied, and all output is within
the true 7-bit ASCII domain.
A patent is still pending on the algorithm which claims that the use of a
key attribute to articulate the rotation of the modified key is
innovative.
For information and the Active X implementation contact:
C. Prichard
[EMAIL PROTECTED]
http://greentv.crosswalkcentral.com (PWS query string encryption
demonstration.)
------------------------------
From: "Prichard, Chuck" <[EMAIL PROTECTED]>
Subject: Re: CipherText ActiveX OCX available
Date: Mon, 26 Feb 2001 02:35:35 GMT
It should be noted that the OCX is just 36kb, while the Java class
implementation is much less about 10kb.
------------------------------
From: "Scott Fluhrer" <[EMAIL PROTECTED]>
Subject: Re: Improved stream cipher? (was: Re: Simple, possibly flawed, stream cipher)
Date: Sun, 25 Feb 2001 19:11:10 -0800
David Wagner <[EMAIL PROTECTED]> wrote in message
news:97ca74$dta$[EMAIL PROTECTED]...
> Henrick Hellström wrote:
> >Here is a similar cipher that shouldn't be vulnerable to Scott Fuhler's
> >attack. These are the changes:
> >
> >* Instead of initializing x to 1, x is initialized to state[7].
> >* Instead of adding either 0 or 1 to state[i] depending on a single bit
of
> >x, x is added to state[i].
> >* In order to prevent attacks that exploit differential relations on
> >state[i], the state array is shifted up one byte and state[0] is set to
the
> >value of the cipher text.
>
> I'm still left wondering about a comment I made earlier.
> It appears that such a cipher requires at least 8 table
> lookups per byte of output (as well as a few other very
> simple operations).
>
> How does this cipher compare in speed to, say, RC4 or
> SEAL? Does anyone have any performance measurements?
>
> If this is slower than RC4 and SEAL, is it worth spending
> a lot of time on?
Well, I suspect that the OP was thinking optimizing for hardware. There,
you can pipeline each state variable independently (as there is no feedback
backwards), and so pipelined each byte output would take one sbox lookup,
one xor and one conditional increment (or add). And, software can do just
as well, assuming you have a CPU with 24 or 32 execution units...
--
poncho
------------------------------
From: "Julian Morrison" <[EMAIL PROTECTED]>
Crossposted-To: comp.lang.ada
Subject: Arcfour in Ada
Date: Mon, 26 Feb 2001 03:27:26 +0000
http://download.sourceforge.net/fling/arcfour-ada-1.0.0.tar.gz
This code has been created for use with the Fling project
(http://fling.sourceforge.net/).
This is ArcFour (Alleged RC4), CipherSaber variant, capable of
CipherSaber-1 and CipherSaber-2. It is coded in Ada, and is dependent on
AUnit and Formatted_Output (available via the AdaPower site). It's
probably pretty GNAT-dependent too, since I've had no need to compile it
anywhere else. If you want fixes, send patches and/or bug reports via
Fling's SourceForge patch tracker.
This code has been placed in the public domain by its author.
Release notes: first full release, all unit tests pass, but it may be
implementation dependant.
------------------------------
From: "Scott Fluhrer" <[EMAIL PROTECTED]>
Subject: Re: Simple, possibly flawed, stream cipher
Date: Sun, 25 Feb 2001 19:44:18 -0800
Henrick Hellström <[EMAIL PROTECTED]> wrote in message
news:97bms4$idh$[EMAIL PROTECTED]...
> "Scott Fluhrer" <[EMAIL PROTECTED]> skrev i meddelandet
> news:97bhlf$7ql$[EMAIL PROTECTED]...
> > However, from it appeared what you were doing, well, it didn't appear to
> be
> > exactly what I was thinking of. Some comments about what those
variables
> > were would definitely help. Perhaps I'll throw together my own analysis
> > program.
Well, I put together my own program, and at 1024 outputs, the program
correctly identified the initial state[0] value 62% of the time. Given the
correct value of state[0], it then correctly identified state[1] 80% of the
time, and it worked for state[2] and higher virtually all the time. If
you're interested, I'll email you the program.
>
>
> Here are some comments:
>
> * By convention, arguments of functions and procedures are prefixed with
the
> letter 'A' to distinguish them from constants and local and global
> variables.
> * IBox is the "inverse" of the function f(s) = (SBox[s] xor SBox[s+1]),
or,
> rather, IBox[x] contains the solutions s to the equation x = (SBox[s] xor
> SBox[s+1]).
> * Key is the initial value of State. It is only kept for display purposes.
> * Guess is the result of the attack, i.e. the guessed value of Key.
> * I count the frequencies of solutions s to the equation (x xor y) =
> (SBox[offset + s] xor SBox[offset + s+1]), where x is the present adjusted
> output value (the impact of lower state values is eliminated), y is the
> previous adjusted output value, and offset is the offset from the initial
> value of state[i]. If there is no solution, the event is not counted.
> Otherwise the frequency of each solution is incremented by 1/count, where
> count is the number of solutions.
That's basically what my version does except, in my version, the frequency
of each solution is incremented by 1.
> * Dev is the deviation of the most frequent solution. It is only
calculated
> for display purposes.
>
> BTW I detected one error in the procedure Analyze1, but it seems as if it
> did not have any major impact on the success rate. The correct code should
> be:
>
> procedure Analyze1(const AOutput: TOutputArray;
> const ASBox: TSBox;
> const AState: TStateArray;
> const Index: Integer;
> const AIBox: TInverseSBox;
> var AFreq: TFrequencies);
> var
> i, j, k, count, offset: Integer;
> s: TStateArray;
> x, y, dx: Byte;
> df: Real;
> yval: Boolean;
> begin
> (* Transfer the known initial values of State[i] to a local variable: *)
> for i := 0 to Index - 1 do
> s[i] := AState[i];
> (* We don't know the initial value of State[Index], of course, but we will
> calculate the offset from the initial value: *)
> s[Index] := 0;
> (* We don't have any previous adjusted value yet: *)
> yval := False;
>
> for j := 0 to HighOutput do begin
> x := 1;
> (* Step through the state update procedure, up to Index: *)
> for i := 0 to Index-1 do begin
> if Odd(x shr i) then s[i] := (s[i] + 1) mod 256;
> x := x xor ASBox[s[i]];
> end;
> (* Do we have a possibly valid hit? *)
> if Odd(x shr Index) then begin
> s[Index] := (s[Index] + 1) mod 256;
> (* Calculate the offset from the initial value of State[Index]: *)
> Offset := 256 - s[Index];
> (* Adjust the output value: *)
> x := x xor AOutput[j];
> (* Do we have a previous adjusted output value? *)
> if yval then begin
> dx := x xor y;
> count := AIBox[dx,0];
> (* Do we have any solutions to the equation? *)
> if count > 0 then begin
> for i := 1 to count do begin
> (* k is a possible initial value of State[Index]. *)
> k := (AIBox[dx,i] + offset) mod 256;
> Freq[k] := Freq[k] + 1/count;
> end;
> end;
> end;
> end else
> x := x xor AOutput[j];
>
> (* Store the value of x, so that we might calculate dx at the next
position:
> *)
> y := x;
> (* We have an adjusted output value: *)
> yval := True;
> end;
> end;
>
> --
> Henrick Hellström [EMAIL PROTECTED]
> StreamSec HB http://www.streamsec.com
>
>
------------------------------
From: "Scott Fluhrer" <[EMAIL PROTECTED]>
Subject: Re: Simple, possibly flawed, stream cipher
Date: Sun, 25 Feb 2001 20:07:50 -0800
David Wagner <[EMAIL PROTECTED]> wrote in message
news:97c9ik$dta$[EMAIL PROTECTED]...
> Henrick Hellström wrote:
> >Self-synchronizing does not work the way David Wagner describes it. Since
x
> >is always initialized to 1, state[0] is always incremented. This means
that
> >the value of state[0] is predetermined by it's initial value and the
> >position in the stream - it will never be synchronized.
>
> Yes, you're absolutely right. There was a bug in my post. Glad you
> caught that!
>
> But, unless I am mistaken, the attack does still work.
> (albeit with complexity 256 times larger than I originally stated)
>
> You have to guess the initial value of state[0] properly. But if you get
> this guess right, then with good probability (modelling the S-box as a
random
> function), we will have the self-synchronizing property.
I don't think so. It appears to me that the nextstate function is
invertable, and hence two distinct states can never synchronize.
>
> Thus, after about 4000 or so outputs, the keystream will be independent of
> all but the first byte of the key. (assuming the S-box is not degenerate)
To be sure, I tested it. With a random (permutation) S-box, I generated two
outputs from two (random) states with the same state[0]. After 2**20
outputs, the states were still not synchronized.
--
poncho
------------------------------
From: "Cristiano" <[EMAIL PROTECTED]>
Subject: Again on key expansion.
Date: Mon, 26 Feb 2001 08:12:35 +0100
This is my question:
> > I have a password constituted from few characters and I want to expand
it
> > (to at least 128 bits) for use it like session (secret) key for an
algorithm
> > to symmetrical key (e.g. rijndael). How could I do?
Paul Crowly answer:
> It's best to apply key stretching: read
> http://www.counterpane.com/low-entropy.html
In this paper it seems that for expand a key of 64 bits to 128 bits are
nedeed 2^(128-64) iterations with SHA-1 (do I have understood well?).
With my pc 2^20 itarations takes 9.6 seconds, thus 2^64 iterations will
takes about 5 millions of years!
I think that this is not a practical method!
Thank you
Cristiano
------------------------------
From: "Henrick Hellström" <[EMAIL PROTECTED]>
Subject: Re: Simple, possibly flawed, stream cipher
Date: Mon, 26 Feb 2001 09:02:29 +0100
David Wagner is right that if the SBox is a random function - not
necessarily bijective - then it is probable that the stream will be
synchronized. But I interpreted Benjamin Goldberg's top message in this
thread as if the SBox was supposed to be fixed, and the major question was
how to selected it. Clearly, it should be selected as a bijective function,
since the key stream would otherwise be synchronized. (Not that it really
matters after Scott Fluhrer's attack.)
--
Henrick Hellström [EMAIL PROTECTED]
StreamSec HB http://www.streamsec.com
"David Wagner" <[EMAIL PROTECTED]> skrev i meddelandet
news:97c9ik$dta$[EMAIL PROTECTED]...
> Henrick Hellström wrote:
> >Self-synchronizing does not work the way David Wagner describes it. Since
x
> >is always initialized to 1, state[0] is always incremented. This means
that
> >the value of state[0] is predetermined by it's initial value and the
> >position in the stream - it will never be synchronized.
>
> Yes, you're absolutely right. There was a bug in my post. Glad you
> caught that!
>
> But, unless I am mistaken, the attack does still work.
> (albeit with complexity 256 times larger than I originally stated)
>
> You have to guess the initial value of state[0] properly. But if you get
> this guess right, then with good probability (modelling the S-box as a
random
> function), we will have the self-synchronizing property.
>
> Thus, after about 4000 or so outputs, the keystream will be independent of
> all but the first byte of the key. (assuming the S-box is not degenerate)
>
> I overlooked the fact that state[0] is special and doesn't
self-synchronize.
> Thank you very much for the correction.
>
> Yes, you're right that there are special S-boxes for which this attack
> doesn't work, but I don't think this should be viewed as a particularly
> reassuring defense. Such S-boxes are very rare, and I suspect they may
> introduce other attacks. It seems that the basic structure of the
> state-update function is seriously lacking in avalanche, which worries me.
------------------------------
From: "Julian Morrison" <[EMAIL PROTECTED]>
Subject: how long can one Arcfour key be used??
Date: Mon, 26 Feb 2001 08:26:22 +0000
How much info is it safe to encode with the one key in Arcfour? Assuming
one is using the full 256 bytes possible as key+IV.
One of my intended designs involves DH exchanging a key, building an
Arcfour state at both ends from it, and then using that to exchange data.
In other words, not starting from Arcfour key setup every time, but just
picking up the state where it left off. I assume there's some limit how
long I can go on doing this before it gets insecure and I need to exchange
keys again, hence my question above.
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: The Key Vanishes (fwd)
Date: Mon, 26 Feb 2001 10:15:28 +0100
[Note: The following is an e-mail from Roger Fleming. I
personally agree with all what he wrote, though with one
tiny comment: If an agency could coax me to reveal the
key, then it probably could also gain access to the
secret in virtually the same manner. M. K. Shen ]
Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
[...]
>On the whole, I surmise that it was the journalism of
>the NY Times that has created a flare/claim of (absolute)
>'unbreakability' of the scheme and has consequently
>caused much unnecessary discussions/misinterpretations.
OK, possibly the NY Times article has created misinterpretations,
but this is largely because of people not understanding the
background, rather than inaccuracy. So, some background:
1. For many years, the only cipher for which we had a _proof_ of
security was the OTP. In fact, cryptology as a science had an
embarrassing lack of actual proofs of any kind.
2. More recently, lots of useful proofs have arisen. Generally,
they take the form: "Assuming block cipher B behaves like a
random permutation, then the Matyas-Meyer-Oseas construction
on B is collision resistant." These sorts of proofs make us
feel all warm and fuzzy about Matyas-Meyer-Oseas or whatever,
and also make us feel like we're really starting to get
somewhere with the science of cryptology. Problem: no block
cipher _really_ behaves like a random permutation, it's just
that they're close enough it's really hard to tell the
difference.
3. Some proofs, however, are absolute proofs: giving some
restriction on the adversary (of computational resources,
memory, intercepted texts, whatever) we can _prove_ that he
cannot break some system. Unfortunately, with the possible
exception of OTP, all such schemes were horribly impractical.
(Some would claim that OTP is also not practical). They did,
at least, put the lie to that annoying old saw, "The OTP is
the only provably secure cipher".
4. What has been done in this case is to take one of these
provable, but grossly impractical ciphers (in particular, one
which limits the opponent to having no more memory available
than the total amount ever created on earth), and invent a
very simple and efficient way to make it many orders of
magnitude more practical. Whether this makes it actually
usable is a matter of opinion, but most would say not.
5. The sense in which the key "vanishes" is this: suppose my
key index generator works by, say, using SHA-1 in OFB mode on
the concatenation of the time, and some barely adequate
passphrase. The Chinese intelligence services record all of
my messages, and later come round to my house and tickle me
until I reveal my passphrase. I tell them, but it doesn't do
them a bit of good; they still can't decrypt my messages,
because they weren't able to record enough of the public,
random keystream. Now it's true I could achieve something
similar by using some key exchange protocol to create a
session key that is discarded immediately after use, but in
that case *they can try cracking* the key exchange protocol
OR the bulk encryption cipher. In this case, it is PROVABLE
they can do nothing provided only they have less than, say,
100 billion GB of storage.
[...]
>An argument of the scheme is, as you pointed out, that
>the opponent doesn't have the very huge storage capacity.
>But this is an argument of availability of 'practical'
>resources. I don't see that it differs in 'nature' from
>the infeasibility of brute-forcing, e.g. 128 bits of key,
Of course it differs. Firstly, you don't know that brute
forcing 128 bits of key is the fastest way to crack any given
block cipher; in this case, we can PROVE that if they don't
have the gigabytes, they can't solve the problem. Secondly, a
work factor limit is an argument about solving the problem
NOW. If they record my ciphertexts, and in ten years time
someone invents a practical quantum computer that can try
2^128 trial keys in 5 minutes, my secrets are out - better
hope they're worthless in 10 years. But with this system, if
they couldn't crack it last week, they NEVER will be able to.
It doesn't matter if 10 seconds later, someone invents
holocrystal storage that stores 10^^23 bytes per chip; it's
already too late. Thirdly, it is in practice much more
difficult to estimate upper limits to computational power,
than memory. We can only really guess at the speed of special
purpose cracking machines used by signals intelligence
agencies. But I would cheerfully bet my life none of them has
100 billion GB of storage.
Cheers,
Roger
(emailed only 'coz newsfeed is playing up; feel free to use
in Usenet)
Cheers,
Roger Fleming
ICQ# 76612923
http://www.beenzsf.com/roger
PGP keyIDs: 0x14D0BF22, 0xC9863367
Don't grok PGP? Try http://www.hushmail.com
--
www.tasmail.com
------------------------------
Date: Mon, 26 Feb 2001 10:43:02 +0100
From: Anonymous <[EMAIL PROTECTED]>
Subject: Re: How to find a huge prime(1024 bit?)
Crossposted-To: alt.security.pgp
On Mon, 26 Feb 2001, Thomas Boschloo <[EMAIL PROTECTED]> wrote:
>
>If you use your proposed algorithm (and I sure as hell hope that PGP
>2.6.3i doesn't use this methode), you will be more likely to hit the
>first prime after a large space without primes, than you will be to hit
>the prime just after that. Thus you (radically?!) reduce the maximum
>ammount of primes you are likely to find.
>
>The correct implementation would be to just generate a *new* prime from
>scratch, preferably with (some) new entropy added to your pool
Why would this reduce the maximum ammount of primes I would find?
It shouldn't matter if I increase the number (by 2) and test it for primality
each time, or to generate a new random value each time and to test
that.. only that the later will much slower.
Read PGP 2.6.3i's genprime.c, starting line about 560. Note the mp_inc(p); mp_inc(p);
where it increases the number that has failed the previous primality test by 2 (only
odd numbers) and then tests for primality again until a prime number has been found
or pdelta > range.
Correct me if I am wrong, but this seems just like how it is searching for primes
too.
------------------------------
** 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
******************************
