Cryptography-Digest Digest #489, Volume #12 Sun, 20 Aug 00 03:13:01 EDT
Contents:
Re: How many bits of strength does the ZIP encryption have? ("Seeker")
Re: How Many? ([EMAIL PROTECTED])
Re: How strong is this algorithm? ("Scott Fluhrer")
Stream Cipher/PRBG idea. (Benjamin Goldberg)
Re: How many bits of strength does the ZIP encryption have? (JPeschel)
Re: Breaking Simple XOR Encryption (Matthew Skala)
Re: Intermittent stream cipher? (John Savard)
Re: How Many? ("John A. Malley")
Re: How Many? (wtshaw)
Re: Stream Cipher/PRBG idea. ("almis")
Re: Stream Cipher/PRBG idea. (David A. Wagner)
Re: How Many? ("Douglas A. Gwyn")
Re: The quick brown fox... (wtshaw)
Windows EFS (Mack)
----------------------------------------------------------------------------
From: "Seeker" <[EMAIL PROTECTED]>
Subject: Re: How many bits of strength does the ZIP encryption have?
Date: Sun, 20 Aug 2000 02:17:45 GMT
> You need 13 bytes of plaintext/ciphertxt and about an hour.
>
If, for instance, the archive consisted of .jpg files could one use the .jpg
header information as plaintext somehow?
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: How Many?
Date: Sun, 20 Aug 2000 02:15:48 GMT
In article <[EMAIL PROTECTED]>,
"Douglas A. Gwyn" <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] wrote:
> > What you are thinking about are called constructs or primitives.
Such
> > as substitutions and linear transforms which are the only two real
> > primitives anyways.
>
> That's nonsense. One could equally well (or better) say that
> the only "real" primitive is NAND, since the entire digital
> system could be constructed using just that one operator.
>
> However, this sort of microanalytical approach is doomed,
> because in most cases the real *meaning* can only be dealt
> with at higher levels of structure. One should work at an
> appropriate level for best effect.
Actually when attacking rotations thinking of it as a 37x32
substitution (for example) is actually a good idea.
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: "Scott Fluhrer" <[EMAIL PROTECTED]>
Subject: Re: How strong is this algorithm?
Date: Sat, 19 Aug 2000 19:31:53 -0700
Jeff Davies <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Scott Fluhrer wrote:
>
> > Jeff Davies <[EMAIL PROTECTED]> wrote in message
> > news:[EMAIL PROTECTED]...
> > > I have an idea for a non-profit electronic cash system (a bank)
> > > for which I have devised I think a new algorithm.
> > Why? What's wrong with 3DES, Serpent or AES? Seriously: the banking
> > industry currently uses (I believe) 3DES, Serpent was designed by
someone in
> > the banking industry (Ross Anderson), and AES (which might turn out to
be
> > Serpent) is considered "good enough" for the US government uses. Why
should
> > I trust my money to a bank that uses home-brew crypto?
> >
>
> The idea is that all IP is free (in Gnu public licence way) including the
> crypto.Is 3DES, Serpent or AES?
Yes. DES (and hence 3DES) and Serpent are public domain (which, for my
money, is even better than Gnu public licence). AES will be as well, once
NIST decides what it will be.
>
> > If each key is used to transmit a single message, it looks safe, if
rather
> > crude. If it is used to transmit multiple messages (and that includes
> > multiple messages from the same "transaction"), then it looks easy
enough to
> > break (or at least, give the attacker enough idea about the messages to
know
> > which bits to manipulate). And, not putting in any sort of MAC allows
bored
> > attackers to have fun flipping random bits, and seeing what happens...
> >
>
> I did miss out the fact (I thought it was obvious I suppose) that a secret
it
> sent inside theencrypted part of the message, and all fields are
checksummed.
> The bits, randomly dispersed
> in the background noise of the larger packet are also randomly inverted by
the
> key.
BTW: if you are doing that, why aren't you using OTP (One Time Pad)? What
advantage does your approach have over that? As far as I can tell, your
scheme uses strictly more keybits, and it is certainly no more secure than
OTP...
> What does MAC mean?
Message Authentication Code. This is an algorithm that detects (with high
probability) changes by anyone which doesn't have the private key. One
simplistic way of looking at it is as a "keyed checksum".
If I may be free to submit a totally frank opinion: someone as ignorant of
cryptography as you should not be designing new cryptosystems to secure
banking transactions.
> Maybe I don't need to say it but the keys are hashed by a phrase so that
they
> aren't totally
> open to someone opening your snailmail etc..
Actually, yes, you do need to say everything your system does, if you expect
any sort of coherent analysis of it.
>
> > So, if someone manages to grab the smartcode out of the mailbox, he will
be
> > able to impersonate you, and withdraw all your funds from the bank?
> >
>
> As far as I can tell, this impersonation is easy in any case where your
client
> is compromisedregardless of security system employed.
> i.e. just about any Microsoft OS.
However, I thought the whole idea of the key cards was to try to prevent
client subversion -- if it doesn't do that, then why not drop the whole idea
of key cards, and use public key crypto, which doesn't need the bother of
monthly mailings...
>
> > Oh, and what do you do if someone's a bit busy, and needs to exchange
more
> > than 2048 messages with the bank in a month?
> >
>
> Then you get the "platinum service" of 4096 keys per card. Or perhaps,
like a
> chequebook, youget another sent out when you're 50% through the last one.
(or
> when you order one).
Order one? I thought this whole service was free (except for not giving
interest on money in the account, which my local bank is happy to do...)
--
poncho
------------------------------
From: Benjamin Goldberg <[EMAIL PROTECTED]>
Subject: Stream Cipher/PRBG idea.
Date: Sun, 20 Aug 2000 03:02:03 GMT
I've a new idea for a stream cipher (Psuedo Random Bit Generator).
L : 4 integers, { 211, 223, 227, 229 }
N : 4 bitstrings, which can be considered constants, or long term keys.
N[i] : a string of L[i] bits
N[i][j] : the jth bit of N[i]
K : the [short term] key.
K[i] : a number in the range 0..(L[i]-1)
X : the keystream / psuedo-random-bit-stream
X[j] = sum( i=0..3, N[i][ (j+K[i]) mod L[i] ] ) mod 2
I realize that the [short term] key space is too small to avoid being
brute forced, but I can't see any other real flaws in the system --
especially since N is much too large to avoid being brute forced.
Assume the attacker knows L for all the following questions.
If the attacker knows N and some part of X for some message, what
methods other than brute force allow him to find K, and how much X is
needed?
If the attacker knows K and some part of X for some messages, how can he
find N? How long does X from those messages have to be?
If the attacker has X for multiple messages, but not N or K, what can he
do? How much X is needed to perform any attack?
Assuming that N has (sum(i=0..3,L[i])) bits of entropy, how much X is
needed to distinguish from random?
--
"There's a mathematical reason not to trust Christians... The Buddhists
believe that human lives repeat. The atheists believe that human lives
terminate. That means that the Christians must believe that humans are
irrational."
- Matt Katinas
"Not necessarily... they could think that humans are imaginary."
- Rob Pease, in response to the above
"Of course Christians think humans are irrational: They believe humans
are transcendental, and all transcendentals are irrational. I suppose
that all we can be certain of is that humans are complex."
- Me, in response the the above
------------------------------
From: [EMAIL PROTECTED] (JPeschel)
Subject: Re: How many bits of strength does the ZIP encryption have?
Date: 20 Aug 2000 03:18:33 GMT
[EMAIL PROTECTED] writes:
>If, for instance, the archive consisted of .jpg files could one use the .jpg
>header information as plaintext somehow?
Yes, but, as Conrad (the Pkcrack author) notes, you need
to know "a reasonably long header." If the plaintext is less
than 100 bytes, Pkcrack, Conrad says, will probably take a
lot longer than an hour to crack a file.
Joe
__________________________________________
Joe Peschel
D.O.E. SysWorks
http://members.aol.com/jpeschel/index.htm
__________________________________________
------------------------------
From: [EMAIL PROTECTED] (Matthew Skala)
Subject: Re: Breaking Simple XOR Encryption
Date: 19 Aug 2000 20:19:18 -0700
In article <[EMAIL PROTECTED]>,
Douglas A. Gwyn <[EMAIL PROTECTED]> wrote:
>> the one where you take the key as a string of bytes, repeat it enough
>> times to make it the length of the message, and XOR the two together.
>
>That's a periodic additive binary cipher.
>
>The use of XOR (noncarrying binary addition)
>is not the most essential feature and should
>not be dominant in a name for the system.
I didn't say it was necessarily a *good* name for it, but my experience
has been that people who use the phrase "simple XOR" to refer to a
specific algorithm, always mean that one.
--
Matthew Skala
[EMAIL PROTECTED] I'm recording the boycott industry!
http://www.islandnet.com/~mskala/
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Intermittent stream cipher?
Date: Sun, 20 Aug 2000 04:04:08 GMT
On Sat, 19 Aug 2000 10:21:46 -0600, [EMAIL PROTECTED] (wtshaw) wrote,
in part:
>From the problem that replaced data might not be the same length as its
>repacement,
Although in my first post, I thought of a it as a database
application, the part I quoted here shows that I reconsidered, after
more carefully reading what he said.
If he is _logging_ information, then we have a file that only grows at
the end intermittently, but nothing within it is changed.
John Savard
http://home.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: "John A. Malley" <[EMAIL PROTECTED]>
Subject: Re: How Many?
Date: Sat, 19 Aug 2000 21:05:24 -0700
"Douglas A. Gwyn" wrote:
>
> "John A. Malley" wrote:
> > ... Transposition preserves the frequencies of occurrence of
> > plaintext symbols in the ciphertext. And that helps cryptanalysis.
>
> Well, no, in general transposition hinders cryptanalysis.
> Would you rather cryptanalyze system A or system T*A where
> T is an unknown transposition?
> It is true that transposition has no further effect on the
> uniliteral frequencies (letters being a name for the units
> of the transposition), and in cryptanalysis that property
> can sometimes be exploited, but the problem as a whole is
> usually made harder by the transposition.
Agreed. I'd rather take on System A than T*A. Transposition ciphers can
be much, much harder to solve than substitution ciphers.
What I tried to convey is the idea that when faced with a transposition
cipher system, the cryptanalyst knows the frequencies of symbols
occurring in the ciphertext is the same as the frequencies of occurrence
for those symbols in the plaintext, and that fact can aid cryptanalysis.
Statistics of the plaintext language should be present in the ciphertext
(i.e. relative abundance of particular digraphs, trigraphs in
conjunction with some insight into probable words in the plaintext.) I
wasn't comparing the relative difficulty of cryptanalyzing transposition
verses substitution ciphers.
>
> Transposition can be *thought of* as substitution in a
> very large space, but that isn't a *useful* way of looking
> at things.
Agreed. I am puzzled by this comment since I thought in the post I
explained transposition as something other than substitution.
Transposition is just a reordering of the original sequential order of
symbols in the plaintext into a new sequential order, a permutation of
position. I see it like swapping contents - what is in the first
position goes to the last position, what is in the second position goes
to the first position, and so on. There may be an n by n square or a
grid or some table or other rearranging "aid" to map the permutation.
This is not a good way to think of it?
John A. Malley
[EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: How Many?
Date: Sat, 19 Aug 2000 21:45:03 -0600
In article <[EMAIL PROTECTED]>, "Douglas A. Gwyn"
<[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] wrote:
> > What you are thinking about are called constructs or primitives. Such
> > as substitutions and linear transforms which are the only two real
> > primitives anyways.
>
> That's nonsense. One could equally well (or better) say that
> the only "real" primitive is NAND, since the entire digital
> system could be constructed using just that one operator.
>
> However, this sort of microanalytical approach is doomed,
> because in most cases the real *meaning* can only be dealt
> with at higher levels of structure. One should work at an
> appropriate level for best effect.
Different approaches to crypto are merely that. Regardless of where you
start, you can touch on the whole spectrum of the field if you don't mind
crossing fences others have installed to define what they see as useful
areas of which to refer. You can view crypto as having only a few to
dozens of primatives.
--
Problem: Politics as Usual Rx: RN
------------------------------
From: "almis" <[EMAIL PROTECTED]>
Subject: Re: Stream Cipher/PRBG idea.
Date: Sat, 19 Aug 2000 23:22:29 -0500
Benjamin Goldberg <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> I've a new idea for a stream cipher (Psuedo Random Bit Generator).
>
> L : 4 integers, { 211, 223, 227, 229 }
> N : 4 bitstrings, which can be considered constants, or long term keys.
> N[i] : a string of L[i] bits
> N[i][j] : the jth bit of N[i]
> K : the [short term] key.
> K[i] : a number in the range 0..(L[i]-1)
>
> X : the keystream / psuedo-random-bit-stream
> X[j] = sum( i=0..3, N[i][ (j+K[i]) mod L[i] ] ) mod 2
>
> I realize that the [short term] key space is too small to avoid being
> brute forced, but I can't see any other real flaws in the system --
> especially since N is much too large to avoid being brute forced.
>
> Assume the attacker knows L for all the following questions.
>
> If the attacker knows N and some part of X for some message, what
> methods other than brute force allow him to find K, and how much X is
> needed?
>
> If the attacker knows K and some part of X for some messages, how can he
> find N? How long does X from those messages have to be?
>
> If the attacker has X for multiple messages, but not N or K, what can he
> do? How much X is needed to perform any attack?
>
> Assuming that N has (sum(i=0..3,L[i])) bits of entropy, how much X is
> needed to distinguish from random?
>
> --
> "There's a mathematical reason not to trust Christians... The Buddhists
> believe that human lives repeat. The atheists believe that human lives
> terminate. That means that the Christians must believe that humans are
> irrational."
> - Matt Katinas
> "Not necessarily... they could think that humans are imaginary."
> - Rob Pease, in response to the above
> "Of course Christians think humans are irrational: They believe humans
> are transcendental, and all transcendentals are irrational. I suppose
> that all we can be certain of is that humans are complex."
> - Me, in response the the above
I believe the composite key length is LCM(L)
The effective OTP length is the longest L (i.e. 229)
And K makes no difference.
...al
------------------------------
From: [EMAIL PROTECTED] (David A. Wagner)
Subject: Re: Stream Cipher/PRBG idea.
Date: 19 Aug 2000 21:35:37 -0700
This is a four-loop Vigenere system, with periods 211, 223, 227, and 229.
It is well-known that such a system can be cracked using on the order of
211+223+227+229 bits of known keystream, using efficient techniques (e.g.,
linear algebra). Consequently, the proposed system should be considered
extremely insecure.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: How Many?
Date: Sun, 20 Aug 2000 01:09:09 -0400
"John A. Malley" wrote:
> What I tried to convey is the idea that when faced with a transposition
> cipher system, the cryptanalyst knows the frequencies of symbols
> occurring in the ciphertext is the same as the frequencies of occurrence
> for those symbols in the plaintext, and that fact can aid cryptanalysis.
Yes, if what is transposed has a distinctly non-flat distribution.
Thus, if transposition is the *only* tranformation in the cipher,
the underlying uniliteral frequencies of the plaintext shine through.
Another use for transposition historically was on top of a book code,
and that did not alter the frequencies of the characters of the code
groups. In general, though, transposition *does* alter the "contact"
frequencies, e.g. the digraph distribution.
> > Transposition can be *thought of* as substitution in a
> > very large space, but that isn't a *useful* way of looking
> > at things.
> Agreed. I am puzzled by this comment since I thought in the post I
> explained transposition as something other than substitution.
That remark wasn't aimed specifically at you, but rather at an
earlier idea in the thread.
Transpositions are permutations, but usually they have more
structure than just being an arbitrary permutation. That extra
structure helps in cryptanalysis. E.g. columnar transpositions
are solved by reconstructing the columns then trying to align
them in the right order.
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: The quick brown fox...
Date: Sat, 19 Aug 2000 22:18:19 -0600
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> Here is my collection, gathered piecemeal over the course of many years,
> the original sources long since forgotten.....
Again, thanks for all who have responded.
In a search for passwords, it seems that distilling down such a sentence
to 26 different characters is one way of generating long but memorable
strings. A permutation of 26 characters is from a keyspace equivalent to
more than 88 bits.
Surely we know that all sequences would be difficult to generate in this
way, but a sequence could be caesar shifted, and/or displaced in the ascii
set to increase possibilities.
Anyway, having asked, here are some sentences I did myself today. Never
having tried seriously before to do this sort of thing, I learned it is
habit forming:
Broach five lumpy quahogs with a junked zax.
Quiz forgiven lads who jump back over your fix.
Young frogs jump back quickly if zapped with six volts.
Vigorously eat quixotic zweibacks, fresh jam, and prunes.
--
Problem: Politics as Usual Rx: RN
------------------------------
From: [EMAIL PROTECTED] (Mack)
Subject: Windows EFS
Date: 20 Aug 2000 06:37:08 GMT
After reading over the literature on
Windows EFS I found that it uses
DESX. Does it use any chaining?
Aditionally it mentions that it distills
the key to 40 bits then expands it
to 128 bits. If so then that would
mean it is still only using 40 bits.
Am I missing something?
Mack
Remove njunk123 from name to reply by e-mail
------------------------------
** 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
******************************
