Cryptography-Digest Digest #662, Volume #10 Thu, 2 Dec 99 09:13:01 EST
Contents:
Re: One Round Block Cipher and 8-bit block Cipoher (Scott Fluhrer)
Re: Use of two separate 40 bit encryption schemes (Bill Unruh)
Re: Encrypting short blocks (Markus Peuhkuri)
Re: Elliptic Curve Public-Key Cryptography (Paul Rubin)
Re: Decyption proof cellphones in Europe? [x3] (Gurripato)
Re: One round or 8-bit block cipher (Thomas Pornin)
Re: A dangerous question (Guy Macon)
Re: more about the random number generator (CLSV)
Re: Random Noise Encryption Buffs (Look Here) (Anthony Stephen Szopa)
Re: The $10,000.00 contesta (Alan Braggins)
Re: been a while since I used pgp ("Julian LEWIS")
dictionary ("Olaf Dokter")
Will ScramDisk recover ? >> After another round of tests ... YES, it
([EMAIL PROTECTED])
----------------------------------------------------------------------------
From: Scott Fluhrer <[EMAIL PROTECTED]>
Subject: Re: One Round Block Cipher and 8-bit block Cipoher
Date: Thu, 02 Dec 1999 07:23:00 GMT
In article <[EMAIL PROTECTED]>,
Seongtaek Chee <[EMAIL PROTECTED]> wrote:
>(a) Suppose I use an 1-round block cipher
> with
> 1) 128-bit key addition
> 2) a large S-box(128 x 128, e.g., x^{-1} in GF(2^{64}),
> which can be calculated directly, even though very slow).
> Is it safe?
> Which attacks can be considered?
Is step 2 independent of the key? If so, then the attacker obtains a
single plaintext/ciphertext pair, and then applies the inverse of step
2 to the ciphertext. The difference between that and the plaintext is
the key.
Hint: there's very little point in doing key-independent operations
at the very front or at the very end of a block cipher.
>
>
> (b) Suppose I use a 64-round block cipher
> with
> 1) 128-bit key
> 2) 8-bit Input/Output size.
> Is it safe?
> Which attacks can be considered?
Well, the attack obtains several (say, 200 bytes worth) of known
plaintext/ciphertext. Then, for any unknown ciphertext, the
ciphertext blocks are likely to appear somewhere in the known text,
and so can be looked up. This is called a 'code-book' attack, and
is why serious block ciphers have blocks of at least 64 bit.
(Actually, for a block that small, the attacker might very well
attack it as a Caesarian cipher, without any known plaintext.
However, this attack doesn't generalize quite as well).
--
poncho
------------------------------
From: [EMAIL PROTECTED] (Bill Unruh)
Subject: Re: Use of two separate 40 bit encryption schemes
Date: 2 Dec 1999 07:48:39 GMT
>>as I do not live in the land of the free, I'm not permitted to have
>>more than 40 bit DES
By whom? Do you also not read Playboy since many countries around the
world ban it? Do you refuse to read about Tibet because China does not
like it? Why do you care what the USA thinks?
------------------------------
From: Markus Peuhkuri <[EMAIL PROTECTED]>
Subject: Re: Encrypting short blocks
Date: 02 Dec 1999 10:07:22 +0200
>>>>> "w" == wtshaw <[EMAIL PROTECTED]> writes:
Thanks for all who replied. One thing I didn't remember to
write up was thet stream cipher or OTPs are not suitable for
my application. As far I've understand there the result
depends on order of blocks (or data). While this is generally
desirable property of encryption, it is not in my case.
What I want is following property: given message M1 (length N
bits) produces same encrypted message E1 (length N bits) every
time run. Message M2 produces message E2, which is different
from E1 iff message M2 is different from M1. However, I'm
willing to accept some probability of collisions, less than
1/1000 (different messages M1 and M2 produce same result E1).
w> algorithm. When you change an algorithm, you have a different
I took look at blowfish, but I don't have knowledge if it is
possible to modify it to use shorter block lengths than 64
bits _without_ weakening security. Maybe I'll have try to
find out if it is technicaly feasible.
w> Pick a block length, pick a usable keylength, design a good
w> algorithm, case closed.
As I're read enough about poor implementations, I would not
risk spending two years of my life in restricted freedom.
I would like to make sure.
--
Markus Peuhkuri ! [EMAIL PROTECTED] ! http://www.iki.fi/puhuri/
========================================================================
Never underestimate the power of human stupidity
... and don't forget you are a human too.
------------------------------
From: [EMAIL PROTECTED] (Paul Rubin)
Subject: Re: Elliptic Curve Public-Key Cryptography
Date: 2 Dec 1999 08:41:31 GMT
In article <[EMAIL PROTECTED]>,
DJohn37050 <[EMAIL PROTECTED]> wrote:
>Regarding RW being shown to be equivalent to factoring, as shown by the recent
>breaks of ISO 9796 formatting, what this often means is that an attack that
>allows for ONE RSA signature forgery, totally breaks RW, as one RW signature
>forgery can be used to factor the RW modulus.
>
>That is, having RW equivalent to factoring seems to mean that a break in RW
>will often be a total break. Some advantage.
>Don Johnson
You're not thinking clearly. You're saying it's somehow an
*advantage* to potentially have two types of breaks, those which
factor the modulus and those which don't, instead of getting rid of
the second type without making the first any easier.
What about those speed figures? Maybe I'm wrong, but my instinct is
that you're making some surprising claims. So I'm still waiting to
see actual numbers (I couldn't find them on Certicom's web site).
Are they published somewhere? Can you post them?
Thanks.
------------------------------
From: [EMAIL PROTECTED]=NOSPAM (Gurripato)
Crossposted-To: alt.2600,alt.privacy
Subject: Re: Decyption proof cellphones in Europe? [x3]
Date: Thu, 02 Dec 1999 08:35:46 GMT
On 1 Dec 1999 17:15:44 GMT, [EMAIL PROTECTED] (Ian Goldberg) wrote:
>In article <[EMAIL PROTECTED]>,
>Gurripato <[EMAIL PROTECTED]=NOSPAM> wrote:
>> Well, the "amateurs" worked at Berkeley. But you�re right, I
>>heard the same. However, I just visited the Smartcard Developers�
>>Association, and they have just released a new A5/1 algorithm,
>>supposedly stronger; see it at http://www.scard.org/gsm/. Whether it
>>is really secure is still to be proven; at least they have released
>>the source code (learning from the past?).
>
>You're confusing a couple of things, here. The SDA didn't _make_ the
>A5/1 and A5/2 and COMP128 algorithms; they just reverse-engineerend and
>published the source (which the GSM people have been unwilling to do).
>We at Berkeley (David Wagner and myself) then cryptanalysed the
>algorithms.
Sorry about the confusion. I read "The Smartcard Developer
Association (SDA) and two U.C. Berkeley researchers release A5/1" at
scard.org, and assumed that you made the algorithm. BTW, excellent
job. Unfortunately, the general public seems to be paying little
attention.
------------------------------
From: [EMAIL PROTECTED] (Thomas Pornin)
Subject: Re: One round or 8-bit block cipher
Date: 2 Dec 1999 09:18:02 GMT
According to Seongtaek Chee <[EMAIL PROTECTED]>:
> 1) 128-bit key addition
> 2) a large S-box(128 x 128, e.g., x^{-1} in GF(2^{128}),
> which can be calculated directly, even though very slow).
> Is it safe?
No. The S-box is invertible, so, in ECB mode at least, it can be
reversed withouth any knowledge of the key or the plaintext. Therefore
your system is equivalent to a multi-times pad with a 128-bit key,
which is unsafe (and, moreover, your system is slower). If the S-box is
secrete, produced by the key, you might get something better; but any
statistic on the input (you encipher ascii english text for instance)
will begin to reveal many things on the S-box.
> 1) 128-bit key
> 2) 8-bit Input/Output size.
> Is it safe?
Neither. For a given key, each byte will be encrypted always the same
way. If the attacker guesses the beginning of the encrypted file, he
gets many clues about the rest of the file. A block cipher should use
64-bit blocks at least, so that it is unprobable that the same block is
used twice in the encrypted file, and so that it is not practical to
build a dictionary corresponding to the key, from the file.
However, if you want a cipher that operates on bytes, look at RC4. It
is an algorithm that generates a stream of bytes that can be xored
to the plaintext, from the secret key. No key must be used twice, so
the standard way is to use a composite key, half of which is random
or timestamp-generated and given in the encrypted file. RC4 uses any
length of key, from 1 to 1024 bits. RC4 is real fast on 8-bit processors
(including Pentium-III, which is somehow an extended 8-bit processor).
--Thomas Pornin
------------------------------
From: [EMAIL PROTECTED] (Guy Macon)
Subject: Re: A dangerous question
Date: 02 Dec 1999 04:50:11 EST
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Jim Nelson)
wrote:
>
>It's been a while since I read "Assassination Politics," but if my memory's
>right, the proposal was not an anonymous clearinghouse for hit man contracts.
>The idea was a sort of dead pool, where people anonymously bet on the day and
>time such-and-such public official would be killed. Everyone who guessed
>correctly would split the pot.
>
>The idea is that the assassin would place a "correct" guess -- he knows when
>he's going to act, presumably -- and collect the winnings. Thus, no contract
>was made, no conspiracy planned, and so on. Double-blind anonymity ensures no
>one knows who's collecting or who bet. The only one in the hot seat would be
>this dead pool's host, but I'm not sure what laws this person would be
>breaking.
>
The assumption in "Assassination Politics" is that it is indeed legal,
(questionable - he bases the belief on a reading of the law, not
on legal precedent) and that it will contiue to be so (almost certainly
false - start killing off politicians and they WILL make a law against it!)
------------------------------
From: CLSV <[EMAIL PROTECTED]>
Subject: Re: more about the random number generator
Date: Thu, 02 Dec 1999 10:16:23 +0000
"NFN NMI L." wrote:
>
> <<So a string
> of 95 million bits can be compressed to a TM-representation with
> just 6 states.>>
>
> What's that machine look like? And the 5 state machine that prints 1000-odd
From:
http://www.drb.insel.de/~heiner/BB/bb-list
With 6 states:
No A0 A1 B0 B1 C0 C1 D0 D1 E0 E1 F0 F1 ones
steps
1 B1L A1L C1R B1R F0R D1R A1L E0R A0L C1R E1L H1L 136612
13122572797
2 B1R A1R C1L B1L F0R D1L A1R E0L H1L F1L A0L C0L 95524079
8690333381690951
> states? At least the 4 state busy beaver is precisely known...
Probably the last one too.
Regards,
Coen Visser
------------------------------
From: Anthony Stephen Szopa <[EMAIL PROTECTED]>
Subject: Re: Random Noise Encryption Buffs (Look Here)
Date: Thu, 02 Dec 1999 02:44:56 -0800
Reply-To: [EMAIL PROTECTED]
Tom St Denis wrote:
> In article <[EMAIL PROTECTED]>,
> "Douglas A. Gwyn" <[EMAIL PROTECTED]> wrote:
> > Tom St Denis wrote:
> > > If I took two exact copies [leave the copying theory behind here] of
> > > an atom, and placed them in two exact same environments. Would they
> > > not decay the same way? If so, that's hardly random at all.
> >
> > The simple answer is, no, two identically prepared quantum systems,
> > constrained as tightly as nature allows, need not evolve along the
> > same path.
> >
>
> That's like saying each time you went back in time [the exact same
> time] you would observe a different state. Which means a atom can
> never be in one state at any time. Kinda like an omni-state..
>
> Tom
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.
That's correct.
The atom has all possible states until you observe it.
Thus it is the act of observing that produces the randomness.
And no two observations are exactly the same.
So, guess what?
You have just discovered true randomness.
------------------------------
From: Alan Braggins <[EMAIL PROTECTED]>
Subject: Re: The $10,000.00 contesta
Date: 02 Dec 1999 10:44:36 +0000
[EMAIL PROTECTED] (Johnny Bravo) writes:
> On Thu, 02 Dec 1999 00:47:33 GMT, [EMAIL PROTECTED] (Bruce
> Schneier) wrote:
>
> >It would be cool if someone could turn this into an attack.
>
> Wow, that's a hell of a lot of curiosity for you. You'd be happy
> seeing a successful attack on Twofish!
The abstract includes "it is shown that other block ciphers, notably
DES and Triple DES, achieve far less uniform subkey distributions than
Twofish over similarly constructed subsets of keys, but this fact has
never led to a known attack on these ciphers", which suggests that if
it did lead to an attack on Twofish, it might also lead to an attack
on DES and Triple DES. Which would be interesting.
------------------------------
From: "Julian LEWIS" <[EMAIL PROTECTED]>
Subject: Re: been a while since I used pgp
Date: Thu, 2 Dec 1999 11:54:29 +0100
> detail over on alt.security.pgp. I am a newbie lurker here in
> sci.crypt, and not an expert in crypto like the rest of these guys.
> This question probably gets asked a lot.
Ditto
> 5.0 and up. Major change for later versions have PGP aquiring their
> "random" seed without the user having to make random keystrokes.
>
This is a bit worrying, do you know how the seed is generated, an obvious
backdoor !!
------------------------------
From: "Olaf Dokter" <[EMAIL PROTECTED]>
Subject: dictionary
Date: Thu, 2 Dec 1999 10:58:42 +0100
hello !
i am searching dictionaries to download, because i want to write a programm
which generates my own statistics about letter-frequencies and so. the
preffered languages are german and english
thank you
olaf dokter
------------------------------
From: [EMAIL PROTECTED]
Crossposted-To:
alt.security.pgp,comp.security.pgp.discuss,alt.security.scramdisk,comp.security.pgp.tech
Subject: Will ScramDisk recover ? >> After another round of tests ... YES, it
Date: Thu, 02 Dec 1999 08:29:59 -0500
I'm recommending ScramDisk to all the users who have a need to hide and totally
secure private computer data as the best product on the market.
After another round of tests, this time with better hex editor, I did find that
ScramDisk is very difficult to corrupt [ when not at the beginning of container
file ]. My all attempts to porpousedly damage container by editing byte / bits
of data proved to be unsuccessful.
In my past test, I did lean to much of my trust on 2 editors for the changes
made. The past use editors made changes to the container file in other places
than my intention.
After both test made, I'm convinced that ScramDisk will recover [ will NOT HAVE
PROBLEM WITH MOUNT OPERATION ] after random bits / bytes are corrupted in
container file. The above hold true as long as corruption is not in the system
part of container.
I would like to apologies to all affected people by my past statements, that "1
byte corruption will render container of say 640 MB useless". The statement is
not valid to all location of corruption, not valid in generic term.
When the remaining corruption possibility will be removed in the future versions
by say [ back up of container system data ], this product will be the best and
the safest of all [ file / disk encryption ] products on the market,
undisputedly.
--
Thanks, Richard
=============================================================
Date: Sat, 27 Nov 1999 17:00:47 GMT
On Thu, 25 Nov 1999 10:02:17 -0500, [EMAIL PROTECTED] wrote:
>Alter 1 byte without increasing container file size.
>After altering, I could not mount container [ provided pass / correct pass / has
>not been accepted ].
Dunno, I tried it out, changed a single byte (81 to FF) and I could mount
it. I'm using 2.02c and blowfish.
I had stored a file inside, and only 9 bytes were changed. Hmm 72 bits
changed for 6 bits.
What program are you using to change the byte?
As long as you don't alter the first bunch of stuff you should be able to
mount it.
If you alter the part that happens to be the FAT or directory you may have
to run scandisk as well to fix things. But I'd recommend you make a backup
of the container first before you do scandisk, just in case scandisk does
something wrong.
I notice that a range of bytes from 0x2700-0x27FF changes. Not sure why..
Maybe it's the date.
Cheerio,
Link.
------------------------------
** 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
******************************
