Cryptography-Digest Digest #242, Volume #12 Tue, 18 Jul 00 06:13:00 EDT
Contents:
Re: RC4-- repetition length? (Runu Knips)
Re: Efficient Arithmetic Coding (Tim Tyler)
Re: key dependent s-boxes (Tim Tyler)
Re: News about quantum computer (Mok-Kong Shen)
Re: Q: Hadamard transform (Tim Tyler)
Re: Carnivore and Man-in-the-middle (Nomen Nescio)
Re: News about quantum computer (Runu Knips)
Re: Carnivore and Man-in-the-middle ("dlk")
Re: SECURITY CLEAN freeware text editor in win95 ? (Runu Knips)
Re: Crypto analyze tool. (=?iso-8859-1?Q?H=E5vard?= Raddum)
Re: mirror bit !! (Runu Knips)
Re: News about quantum computer (Runu Knips)
Re: Questions!!!! (Mark Wooding)
Re: Info about non-repudiation as it relates to cryptographic mathematics
([EMAIL PROTECTED])
Re: RC4-- repetition length? (Simon Johnson)
"standalone" java implementation of blowfish or twofish ([EMAIL PROTECTED])
Good free stream cipher ? (Runu Knips)
Re: "standalone" java implementation of blowfish or twofish (Runu Knips)
----------------------------------------------------------------------------
Date: Tue, 18 Jul 2000 10:13:37 +0200
From: Runu Knips <[EMAIL PROTECTED]>
Subject: Re: RC4-- repetition length?
Guy Macon wrote:
> RC4 is an algorithm, not an implementation.
Where is the difference ??? If RC4 is an algorithm, every
implementation of RC4 implements exactly that algorithm,
or it isn't RC4.
> If I write two implementations, one of which uses
> 7 bit ASCII for input and output, and another which
> uses hexadecimal, the imlementations will give me
> different results when I try to encrypt a plaintext of
> A28753B2087D23465C with a passphrase of AF5F97D0.
What are you talking about ?????? Hexadecimal and 7 bit
ASCII are nothing but representations of data. Neither
the algorithm nor the implementation nor the data changes
if you display the data as characters or hexadecimal.
> [..] the implementation is more than just the
> implementation of the algorithm - it's the implementation
> of the algorithm plus the I/O.
The I/O is _NOT_ the part of the algorithm, or the
implementation of the algorithm. It is of course
part of the final program; but it can't change the
data (except doing things like base64 encode etc).
> In the case of ciphersaber, the I/O section adds an
> itialization vector to your passphrase so that
> you can use one passphrase again and again without the
> key repeating.
Adding a initialization vector is NOT part of I/O. It
is another algorithm commonly used with any cipher,
wheter block or stream.
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Efficient Arithmetic Coding
Reply-To: [EMAIL PROTECTED]
Date: Tue, 18 Jul 2000 07:53:17 GMT
SCOTT19U.ZIP_GUY <[EMAIL PROTECTED]> wrote:
: Actually it was a thread about efficient Arithmetic Coders in
: C or C++. What Matt has is a nice Arithmetic Coder in C++
: so it was on post. I don't remeber has web address but my
: compression pages have pointers to it. [...]
"Bijective Arithmetic Encoding with Optimal End Treatment" - Matt Timmermans
http://www3.sympatico.ca/mtimmerm/biacode/biacode.html
--
__________ Lotus Artificial Life http://alife.co.uk/ [EMAIL PROTECTED]
|im |yler The Mandala Centre http://mandala.co.uk/ UART what UEAT.
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: key dependent s-boxes
Reply-To: [EMAIL PROTECTED]
Date: Tue, 18 Jul 2000 08:01:23 GMT
Hideo Shimizu <[EMAIL PROTECTED]> wrote:
: Generally, key dependent s-boxes can not be guarantee strength.
: This is why many encryption algorithm avoid key dependent one.
It's *harder* to figure out if you've got a strong set of boxes if you
have to use an automated process and do it in real time, at any rate.
You can't normally offer much of a guarantee of strength using static
s-boxes either.
Key-dependent s-boxes generally have a good reputation, at least in terms
of strength. *If* there are good reasons for not using them, I think they
are likely to be that they bulk-up hardware implementations, slow down
the re-keying process, and introduce additional complication.
--
__________ Lotus Artificial Life http://alife.co.uk/ [EMAIL PROTECTED]
|im |yler The Mandala Centre http://mandala.co.uk/ Be good, do good.
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: News about quantum computer
Date: Tue, 18 Jul 2000 10:33:13 +0200
Bill Unruh wrote:
> Mok-Kong Shen <[EMAIL PROTECTED]> writes:
>
> >The German newspaper Computer Zeitung reported in its 13 July
> >issue that a team consisting of US and German researchers
> >has succeeded to synthesize a molecule that can store 5 qubits,
> >while the best previous result was 3 qubits.
>
> ??? I do not know what this means. The record is 7 bits for an NMR
> system.
Could you give a reference? I would with that write a letter to the editor
of the newpaper.
M. K. Shen
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Q: Hadamard transform
Reply-To: [EMAIL PROTECTED]
Date: Tue, 18 Jul 2000 08:05:17 GMT
Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
: Tim Tyler wrote:
:> One thing to note is (I believe) that the linearity properties of the
:> Fourier Transform mean that the order of application is of little
:> relevance. This may not be so for other transforms.
: One maybe odd question I would like to know is whether one
: would get something inherently different in quality, if, instead of
: doing 1-D Hadamard transform of n^2 values, one fills these
: into a matrix of n*n and process that with a 2-D transform.
With 1D and 2D FFTs the results appear pretty qualitatively different -
at least upon visual inspection.
Perhaps whether the results are different in quality will depend on which
quality you're looking at.
--
__________ Lotus Artificial Life http://alife.co.uk/ [EMAIL PROTECTED]
|im |yler The Mandala Centre http://mandala.co.uk/ VIPAR GAMMA GUPPY.
------------------------------
From: Nomen Nescio <[EMAIL PROTECTED]>
Subject: Re: Carnivore and Man-in-the-middle
Date: Tue, 18 Jul 2000 10:40:03 +0200 (CEST)
>> As most of you already know, the FBI has announced its intention to
>> install the "Carnivore" packet-sniffing system in every ISP's data path,
>> such that all traffic passing through that ISP can be sniffed by some
>> Carnivore system. The stated purpose of this system is to snoop on the
>> contents of suspected criminals' emails when permitted by judicial
>> wiretap order.
>
> As I understand it, they intend to place it at particular ISPs when
> they have a court order to intercept mail.
I wonder if an ISP so-tagged would have the cojones to post a notice to
that effect on its home page. Probably not. The feds would simple slap
a gag-order on it similar to Britian's RIP.
And so another Orwellian shoe drops. Ours is the last generation that will
even have a memory of what privacy used to be.
>> Reading about it made me think about the "Man in the Middle" attack
>> against public key cryptosystems. In order for "Man in the Middle" to
>> work, the adversary must be able to intercept any communication between
>> any two users of the cryptosystem and replace that communication with
>> their own selected data.
>
> Subsituting packets would be feasible (I wouldn't say trivial), but
> defeating the underlying encryption schemes would be impractical.
Use strong encryption (while you still can).
Use anonymous remailers (ditto).
It's a mighty bleak world outside.
------------------------------
Date: Tue, 18 Jul 2000 10:40:09 +0200
From: Runu Knips <[EMAIL PROTECTED]>
Subject: Re: News about quantum computer
Mok-Kong Shen wrote:
> The German newspaper Computer Zeitung reported in its 13 July
> issue that a team consisting of US and German researchers
> has succeeded to synthesize a molecule that can store 5 qubits,
> while the best previous result was 3 qubits.
According to c't 15/2000, p. 40, the best previous result was
8 qubits, using rydberg-states (hope they have this name in
english), while nobody has realized a quantum processor with
5 qubits before.
------------------------------
From: "dlk" <[EMAIL PROTECTED]>
Subject: Re: Carnivore and Man-in-the-middle
Date: Tue, 18 Jul 2000 08:45:59 GMT
[EMAIL PROTECTED] wrote in message ...
<snip>
>Subsituting packets would be feasible (I wouldn't say trivial), but
>defeating the underlying encryption schemes would be impractical.
Why? Or rather, who says that the Carnivore sys would have to
perform the processing? *Assuming* that it can function as an
interceptor (vs a simple monitoring tap), why not do a "hold and
re-direct" method: send the stored stream (from a specific node)
to some other nice and fast machine for processing, receive the
altered result and then transmit that? Depends upon the 'strength'
of the crypto used but methinks <56 bit symmetric or "flawed"
implementations of >56 bsym might just be "doable",
not in honest-to-goodness real time of course, but I don't
think we'd be talking days of delay either.
Dave Keever
------------------------------
Date: Tue, 18 Jul 2000 10:52:59 +0200
From: Runu Knips <[EMAIL PROTECTED]>
Crossposted-To: alt.privacy
Subject: Re: SECURITY CLEAN freeware text editor in win95 ?
Runu Knips wrote:
> Vim can also encrypt your files.
AAAAAAAAAAAAAAAAAAAAAAAAAARG !!!!!!!!!!!!!!!!!!!!!!!!
For I've stated that, I got interested which way they
actually do that encryption - they use the PKZIP
ENCRYPTION ALGORITHM to encrypt files .... !!!!!
In other words: crap.
------------------------------
From: =?iso-8859-1?Q?H=E5vard?= Raddum <[EMAIL PROTECTED]>
Subject: Re: Crypto analyze tool.
Date: Tue, 18 Jul 2000 11:08:02 +0200
JPeschel wrote:
> "Joseph Ashwood" [EMAIL PROTECTED] writes, in part:
>
> > Just to give you
> >some idea of the complexities of analysis of ciphers, judging them on rounds
> >doesn't work (RSA is secure with 1 round, DES takes several), you can't
> >judge them on size (a Vigenere cipher can be gigabytes in size and still be
> >weak...
>
> What do you mean by "a Vigenere cipher can be gigabytes in size:" the
> Vigenere key? How do you propose breaking a Viggy that uses a key
> of that size?
Known plaintext attack?
>
>
> >(the gigabyte+ Vigenere
> >would certainly not be bruteforcable), on the final operation (RC4 uses XOR
> >on the output of the pRNG, so does a vigenere).
>
> No, a classical Vigenere doesn't use XOR.
>
> Joe
>
>
>
> __________________________________________
>
> Joe Peschel
> D.O.E. SysWorks
> http://members.aol.com/jpeschel/index.htm
> __________________________________________
------------------------------
Date: Tue, 18 Jul 2000 11:13:21 +0200
From: Runu Knips <[EMAIL PROTECTED]>
Subject: Re: mirror bit !!
[EMAIL PROTECTED] wrote:
> (2) Mirroring. This also has levels similar to swapping. At the first
> level, the bits of the word referenced are exchanged by mirroring about
> the central axis. At the second level, the mirroring is done separately
> on each half of the word. Analogously for the higher levels.
>
> could you give me some example please with 32 bit number !!!
1.) [descriptive]
Bit 0 becomes Bit 31 of the result, and vice versa.
Bit 1 becomes Bit 30 of the result, and vice versa.
Bit 2 becomes Bit 29 of the result, and vice versa.
....
Bit 15 becomes Bit 16 of the result, and vice versa.
2.) [picture]
nnnn nnnn nnnn nnnn nnnn nnnn nnnn nnnn
|<----------------------------------->|
|<--------------------------------->|
|<------------------------------->|
|<----------------------------->|
| ............. |
(etc)
3.) Or, in my beloved BRT operations:
BRT1 reg1, reg1, 1
BRTL2 reg1, reg1, 2
BRTL3 reg1, reg1, 4
BRTL4 reg1, reg1, 8
ROTL reg1, reg1, 16
------------------------------
Date: Tue, 18 Jul 2000 11:17:23 +0200
From: Runu Knips <[EMAIL PROTECTED]>
Subject: Re: News about quantum computer
Mok-Kong Shen wrote:
>
> Bill Unruh wrote:
>
> > Mok-Kong Shen <[EMAIL PROTECTED]> writes:
> >
> > >The German newspaper Computer Zeitung reported in its 13 July
> > >issue that a team consisting of US and German researchers
> > >has succeeded to synthesize a molecule that can store 5 qubits,
> > >while the best previous result was 3 qubits.
> >
> > ??? I do not know what this means. The record is 7 bits for an NMR
> > system.
>
> Could you give a reference? I would with that write a letter to the editor
> of the newpaper.
>
> M. K. Shen
Hmm I've written a news to the newsgroup, but unfortunatley it seems
that it has been lost.
In the german computer magazine c't, issue 15/2000 (from this monday),
page 40 they say that the current record is 8 qubits, implemented with
rydberg states of a single atom.
------------------------------
From: [EMAIL PROTECTED] (Mark Wooding)
Subject: Re: Questions!!!!
Date: 18 Jul 2000 09:28:42 GMT
Vladimir Castro Alves <[EMAIL PROTECTED]> wrote:
> I found your answer interesting.
Oh, good. Despite the remark at the end of my reply, your questions
showed a refreshing depth of thought and I hoped to give a response that
such questions deserve.
> Do you think that key dependent S-boxes can improve the robustness
> of a given Feistel network ? Why?
Ooh. This sounds like the history exam questions I used to have to
answer. But more interesting. ;-) However, I think I'm going to sit on
the fence here and just present arguments from both sides. At least,
until I have an opinion of my own.
I'm not sure that the Feistel structure has much to do with it, except
that its a construction that allows a block cipher to be constructed
from a nonbijective function. However, the Massey-Lai structure, as
used in IDEA, can also do this[1].
As one of the Twofish team (John Kelsey, I think) wrote, there's no such
thing as a secret key-dependent S-box: they're just (possibly) horrible
key-dependent functions. If they're sufficiently horrible (e.g., in
Blowfish) then our analyst will prefer to model them as being random and
unknown rather than looking at the construction. Twofish treads a fine
line here, since it can't afford a long key setup time to turn the
S-boxes into truly horrible functions. For the moment, let's assume
that they're too horrible, and think of them as random secret tables.
We know that not all S-boxes are created equal. If a box is known, we
can identify linear and differential characteristics with various
probabilities, and (perhaps) exploit these in our analysis of the
cipher.
If a box is key-dependent, we can actually make some headway by guessing
that it has some given property, which it will with a given probability.
(Rivest and Robshaw mention this in one of their AES comments; I think
they overstate their case a bit, actually.) If the probability that our
property holds is pretty similar to the probability that it holds in a
real random S-box (with the various requirements imposed by the design,
such as perhaps bijectivity) then that's OK, and we've done about as
well as we can. If the probability is unusually high for some property
which is cryptanalytically useful then we have a class of weak keys,
which we need to worry about.
I suspect that the benefits of key-dependent substitutions outweigh the
problems, but (like everything else) they don't solve the whole problem
and don't obviate the need for plenty of careful analysis.
[1] Let a, b, c, d be four n-bit values, and let F(x) be a function on
2n-bit values with a 2n-bit output. Then let (u, v) = F(a XOR c, b
XOR d), and let a' = a XOR u, b' = b XOR v, c' = c XOR u, d' = d XOR
v be the outputs of (one round of) the construction. Now note that
a' XOR c' = a XOR u XOR c XOR u = a XOR c and similarly b' XOR d' =
b XOR d, so we can recover the inputs to F, and hence u and v and
finally the original inputs a, b, c, d. Thus, the construction is
invertible, even if F isn't. Serge Vaudenay analysed this
construction, and produced one of his decorrelated cipher designs
with a silly name, WALNUT, based on it.
My reading of the IDEA patent suggests that the Massey-Lai cipher
structure isn't actually claimed. Does anyone know whether this is
correct? If so, that's good news because the structure is
potentially the most interesting part of the cipher.
-- [mdw]
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Info about non-repudiation as it relates to cryptographic mathematics
Date: Tue, 18 Jul 2000 09:31:06 GMT
> I am looking for a detailed reference that describe information about
> non-repudiation as it relates to cryptographic mathematics.
Secure digital time stamping is the solution to avoid repudiation
> Any reference, paper, URL is greatly appreciated.
There is a doctoral thesis on 'Non Repudiation` by Zhou
http://homex.coolconnect.com/user/jyzhou/publications.html
and you can have a look on several references on time stamping from
Helger Lipmaa`s page on Crypto
http://moomin.ee/~helger/crypto/
regards
/Venkat
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
Subject: Re: RC4-- repetition length?
From: Simon Johnson <[EMAIL PROTECTED]>
Date: Tue, 18 Jul 2000 02:37:52 -0700
Lets side step,
I've read on this forum that RC4 is distinquishable from random
data after 4Tb. Though this is a large figure, its still just a
tiny fraction of the amount of data it could encrypt securely if
it used all the possible permutations. In terms of security,
this make the cycle length meaingless (providing of course, that
the cycle length is greater than 4 Tb.)
Just some food for thought........
Simon J
===========================================================
Got questions? Get answers over the phone at Keen.com.
Up to 100 minutes free!
http://www.keen.com
------------------------------
From: [EMAIL PROTECTED]
Crossposted-To: comp.lang.java.security,comp.security.misc
Subject: "standalone" java implementation of blowfish or twofish
Date: Tue, 18 Jul 2000 09:35:02 GMT
Hello,
I am writng a java applet which will be able to encrypt files
either using blowfish or twofish. I have found (through
counterpane.com) java implementations of both encryption algorithms,
and would like to use them in my applet.
However, the implementations are raw in the sense that no padding or
CBC is applied. I need to have this added functionality, and am
looking for a complete "standalone" java implementation of padding and
CBC which I can use with the encryption algorithms.
I cannot use a complete library such as "cryptix" because the code
needs to be embedded in an applet and hence needs a small footprint,
but cryptix is a very large package.
Does anyone know where I could locate a *small" java program which
implements CBC and some kind of padding? Any hints or links would be
greatly appreciated.
many thanks
Bruce Sams
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
Date: Tue, 18 Jul 2000 11:53:18 +0200
From: Runu Knips <[EMAIL PROTECTED]>
Subject: Good free stream cipher ?
I'm looking for a good & free stream cipher algorithm.
Does anybody have a suggestion ?
------------------------------
Date: Tue, 18 Jul 2000 11:56:30 +0200
From: Runu Knips <[EMAIL PROTECTED]>
Crossposted-To: comp.lang.java.security,comp.security.misc
Subject: Re: "standalone" java implementation of blowfish or twofish
[EMAIL PROTECTED] wrote:
> Does anyone know where I could locate a *small" java program which
> implements CBC and some kind of padding? Any hints or links would be
> greatly appreciated.
But implementing CBC is absolutely trivial ??? The only problem is
to get a good IV, but Java has some buildin classes for
cryptographically strong random (even if the main requirement for
IV's is their uniqueness, not their randomness).
------------------------------
** FOR YOUR REFERENCE **
The service address, to which questions about the list itself and requests
to be added to or deleted from it should be directed, is:
Internet: [EMAIL PROTECTED]
You can send mail to the entire list (and sci.crypt) via:
Internet: [EMAIL PROTECTED]
End of Cryptography-Digest Digest
******************************
