Cryptography-Digest Digest #609, Volume #10 Mon, 22 Nov 99 20:13:05 EST
Contents:
Re: High Speed (1GBit/s) 3DES Processor (Chris Eilbeck)
Sarah Flannery (Jim Haynes)
Re: PGP (CoyoteRed)
Re: AES cyphers leak information like sieves (Tim Tyler)
Re: AES cyphers leak information like sieves (Tim Tyler)
Re: Halting condition for brute force cracking (SCOTT19U.ZIP_GUY)
Re: Halting condition for brute force cracking (Bill Unruh)
Re: Modified DH - ok? - This thread ends now. ([EMAIL PROTECTED])
2nd RFD: sci.misc.random-numbers (Scott Nelson)
Re: How ScramDisk will recover >> My test in container file ... (Paul Koning)
Re: AES cyphers leak information like sieves (Volker Hetzer)
Re: RC4 in Kremlin US version 2.21 to tom st denis ("Douglas A. Gwyn")
Re: Codebook examples on Web? ("Douglas A. Gwyn")
----------------------------------------------------------------------------
From: Chris Eilbeck <[EMAIL PROTECTED]>
Crossposted-To: comp.dcom.vpn,comp.security.firewalls
Subject: Re: High Speed (1GBit/s) 3DES Processor
Date: 22 Nov 1999 20:32:54 +0000
[EMAIL PROTECTED] writes:
> We have developed a prototype Encryption system which runs 3DES at 1
> GBits/sec (this is not just processing but with real IO at 1 GBit/sec).
> Are there any commercial applications for this type of technology? It
> would be interesting to get some feedback. Possibly bulk encryption with
> ATM switches etc? It should also be possible to multiplex multiple high
> speed inputs into our system.
>
> If you are a manufacturer of high speed switches, or have general interest
> in this area or a venture capitalist, you can contac us at:
>
> [EMAIL PROTECTED]
Or you could just download and use my DES core and use it three times
in series to achieve more than 1.7GBps in a big Xilinx FPGA.
See http://www.yordas.demon.co.uk/crypto
Chris
--
Chris Eilbeck mailto:[EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED] (Jim Haynes)
Subject: Sarah Flannery
Date: 22 Nov 1999 20:44:06 GMT
Reply-To: [EMAIL PROTECTED]
The Irish girl who invented a new crypto algorithm - in the current issue of
comp.risks digest are some pointers to URLs with information about this
topic.
------------------------------
From: [EMAIL PROTECTED] (CoyoteRed)
Subject: Re: PGP
Date: Mon, 22 Nov 1999 20:48:52 GMT
Reply-To: this news group unless otherwise instructed!
Markku J. Saarelainen said...
> personally I would not use pgp, but I would use another method for
> encrypting my email messages ....
Like..?
--
CoyoteRed
CoyoteRed <at> bigfoot <dot> com
http://go.to/CoyoteRed
PGP key ID: 0xA60C12D1 at ldap://certserver.pgp.com
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: AES cyphers leak information like sieves
Reply-To: [EMAIL PROTECTED]
Date: Mon, 22 Nov 1999 20:52:29 GMT
Jerry Coffin <[EMAIL PROTECTED]> wrote:
: In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] says...
: [ ... ]
:> I agree that error recovery is not present in CFB. However it is not
:> clear to me that this implies that very much diffusion of information
:> is going on.
: It's irrelevant -- if you look back at the comments to which I was
: replying (the ones David Scott made) they were not directed at the
: diffusion or lack thereof: his comments were aimed specifically at
: showing that the error recovery capability in CBC isn't useful.
: His attempt in this direction was fatally flawed in at least two
: obvious ways. First his example was unrelated, second the conclusion
: he drew from his example would have been wrong even if the example
: itself had been correct.
It appears from David's recent comments that he genuinely thinks that
error recovery is possible with CFB mode.
To quote hin: "CFB suffers from the same faults as CBC. Namely you
can hex edit the middle of an encrypted file that used CFB and
only a small portion where the editing occurs will be in error."
This explains why he made the comment about error recovery and PGP.
Until now I have been under the impression that you are correct,
and the CFB mode allows no error recovery. This is what I have
been told.
However, looking at the algorithm, CFB encrypts the previous cyphertext
block again and combines it with the current plaintext block, using XOR.
/Why/ you cannot undo this XOR with the re-encrypted version of the
previous cyphertext block seems not to be clear to me.
I next tried an internet search:
I came up with this statement: ``With CFB mode and full (64-bit) feedback,
when two ciphertext blocks are identical, the outputs from the block
cipher operation at the next step are also identical. This allows
information about plaintext blocks to leak.''
This statement appears to verify that information required to
decrypt is not spread through the file, and that decryption
(assuming the key is known) is a local process.
Then there's this:
`` cfb Ciphertext feeback mode
c[i] = f1(K, c[i-1]) ^ p[i]
p[i] = f1(K, c[i-1]) ^ c[i]
This is good at preventing information leakage. A one bit error in the
ciphertext causes a one bit error in the plain text => good for use in
high noise environments where error detection and correction is
(inexplicably) not used and tamper detection is not as critical.''
I'm not sure about that "1-bit" error - what about the next block!? - but
David is not the only person who thinks CFB mode recovers from errors.
On the other hand there's this: ``OFB (output feedback) is comparable to
CFB, but can be used in applications where error propagation cannot be
tolerated.''
This clearly implies CFB "propagates errors".
Next: ``There are also two widely used modes for block ciphers:
cipher-feedback (CFB) and output-feedback (OFB) modes. The first one
tries to implement a block cipher as a self-synchronising stream
cipher wile the second runs a block cipher as a synchronous stream
cipher.''
CFB tries to be "self-synchronising"? Doesn't that mean it recovers
from errors?
Sorry if I'm not quoting my sources for all these - use Altavista if
you really need the originals.
Anyway, quotes aside, from my brief look at the algorithm, it would
/appear/ that David is correct.
Perhaps someone can sort this source of confusion out with some facts.
As for the error recovery being useful, for the owner of a
system which already is likely to be diffusing somewhat during a
compression phase, error recovery is unlikely to be of much practical
use.
/Perhaps/ David was guilty of exaggerating this uselessness for effect -
but I hardly see that as any sort of henious crime.
:> I have difficulty in imagining a useful compressor that output in
:> discrete, non-interacting n-bit chunks, though. If n=128, say, there's
:> not much scope for compression, it seems to me.
: If you were using something like LZ* compression, you'd be right:
: you'd have to work with substantially larger blocks to get good enough
: compression to care about.
: OTOH, using Huffman compression is a different story. Here you're
: just encoding each byte in fewer bits than you did to start with.
I beleieve Huffman coding can use elaborate models of the preceeding text
to influence the representation of the next symbol. Huffman coding is
merely the name given to the representation of the symbols - not how
those symbols translate into their decompressed equivalents.
I grant the general point anyway - some types of coding schemes which
don't use information from the rest of the file will still manage to do
some compression.
:> Generally I'd say that effective compression and confinement of errors
:> were constarints that often pull in different directions - and that
:> you can't generally have them both at the same time.
: There's no real question that providing error recovery capability will
: reduce your compression somewhat. It appears to me, however, that the
: effect is really quite minimal. [...]
In the case of a static Huffman coding scheme, with no large-scale
document model, anyway. Of course this would produce pretty
sub-optimal compression on most text documents in the first place.
Look at an adaptive dictionary-based compression scheme instead and a
completely different picture would emerge.
--
__________
|im |yler The Mandala Centre http://www.mandala.co.uk/ [EMAIL PROTECTED]
The early worm gets the bird.
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: AES cyphers leak information like sieves
Reply-To: [EMAIL PROTECTED]
Date: Mon, 22 Nov 1999 20:58:38 GMT
Lincoln Yeoh <[EMAIL PROTECTED]> wrote:
: Using an all or nothing crypto algo is perfectly fine if you don't mind
: waiting for the whole message before you read it.
: It's not so good if you need to read it in real time - e.g.
: voice/video/real time control.
This is a fine point.
Tangling everything with everything else would (it seems to me) be good
for email messages - but bad for HTML pages - as the latter may be
downloaded and displayed progressively.
--
__________
|im |yler The Mandala Centre http://www.mandala.co.uk/ [EMAIL PROTECTED]
Rebel without a clue.
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Halting condition for brute force cracking
Date: Mon, 22 Nov 1999 21:56:20 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (John Savard) wrote:
>[EMAIL PROTECTED] (Guy Macon) wrote, in part:
>
>>Let's say that I set my computer to doing such a series of guesses
>>on some encypted data. How, exactly, does the computer identify
>>sucess?
>
>In theoretical terms, a cipher is considered insecure even if it is
>vulnerable to a _known plaintext_ attack (or, for that matter, an
>adaptive chosen plaintext attack).
>
>Thus, while (for example) highly efficient methods of text compression
>would frustrate, or render more difficult, a brute-force attack on an
>encrypted message, this isn't considered to provide a "real"
>improvement in security; thus, compression, if it takes place, must
>take place prior to encryption, but its purpose is held to be
>primarily the resulting bandwith savings.
>
>I am not entirely wedded to the conventional wisdom - in that I think
>that compression _is_ worth a degree of attention, and should be
>without headers, and designed to avoid leaving repetitive patterns
>behind (thus, instead of using a Huffman code for text with space as a
>symbol, I advocate Huffman-coding word lengths, and having a separate
>state for the lengths and the letters) - but I do agree that certain
>*extraordinary* attempts to obtain slight improvements in compression
>are not worth it (such as David A. Scott's "one-to-one compression").
>
>John Savard (don't snooze, don't snore)
I understand why you think that my compression is not worth it.
You still foolishly think that PGP uses CBC chaining. I guess the fact
that if a user is encyprting a file of unknow structure but is useing
normal compression that there is enough information in the stucture
of the resluting compressed file that it could well be the only valid file.
resulting from the crypto system. I guess you feel safe in knowing that
the only possible valid soultion form a set of encrypted text is the one
that you are trying to hide. I feel this is foolharty.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
Scott famous encryption website NOT FOR WIMPS
http://members.xoom.com/ecil/index.htm
Scott rejected paper for the ACM
http://members.xoom.com/ecil/dspaper.htm
Scott famous Compression Page WIMPS allowed
http://members.xoom.com/ecil/compress.htm
**NOTE EMAIL address is for SPAMERS***
------------------------------
From: [EMAIL PROTECTED] (Bill Unruh)
Subject: Re: Halting condition for brute force cracking
Date: 22 Nov 1999 21:06:33 GMT
In <81bio1$[EMAIL PROTECTED]> [EMAIL PROTECTED] (Guy Macon) writes:
]I have always wondered about the mechanism for the various "try every
]permutation" methods that are discussed (usually in the context of
]comparing the time required with the age of the universe!).
]Let's say that I set my computer to doing such a series of guesses
]on some encypted data. How, exactly, does the computer identify
]sucess? Does it look for words that are in a dictionaryor that
It needs some knowledge of the plain text. Eg, that the plain text is
all ascii (so the 7th bit is always zero.) With no knowledge of the
plain text, this exhaustive search does not work.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Modified DH - ok? - This thread ends now.
Date: Mon, 22 Nov 1999 20:56:07 GMT
[EMAIL PROTECTED] wrote:
> The Problem in the Low level language (VBA) is that
> when i try something as x ^ y mod z - it overflows.
That seems strange - it should have overflowed
before that. Of course even if you implement
large integers, you will not be able to compute
g^x mod N by first computing g^x and then
reducing mod N.
--Bryan
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Scott Nelson <[EMAIL PROTECTED]>
Crossposted-To:
news.announce.newgroups,news.groups,sci.math,sci.physics,sci.electronics.misc,sci.engr,sci.stat.math
Subject: 2nd RFD: sci.misc.random-numbers
Date: Mon, 22 Nov 1999 21:19:46 GMT
REQUEST FOR DISCUSSION (RFD)
unmoderated group sci.misc.random-numbers
This is a formal Request For Discussion (RFD) for the creation of a
world-wide unmoderated Usenet newsgroup sci.misc.random-numbers.
This is not a Call for Votes (CFV); you cannot vote at this time.
Procedural details are below.
CHANGES from previous RFD:
The name (location) was changed from sci.crypt.random-numbers to
sci.misc.random-numbers. "and" was replaced with "or" in the charter.
Newsgroup line:
sci.misc.random-numbers Random numbers and their creation.
RATIONALE: sci.misc.random-numbers
There is no appropriate newsgroup for the discussion of random numbers
and their generation. Such discussions currently takes place in
several different groups, and generally annoys the majority of those
groups readerships. Because of the broad nature of the topic, this
group doesn't fit well into any of the existing hierarchies hence it's
placement under sci.misc.
sci.math.random-numbers seems inappropriate because the discussion of
how to build hardware to collect random-numbers isn't a "math" topic.
sci.crypt is where most of the discussion of this topic had taken
place, but random-numbers aren't limited to cryptography. In
particular, new psuedo random numbers are rarely cryptographically
secure, but of interest.
sci.random-numbers seems inappropriate since the expected volume of
traffic doesn't warrent a top-level hierarchy.
CHARTER: sci.misc.random-numbers
sci.misc.random-numbers is for the discussion of random number
generators, both "true" (hardware) and "pseudo" (software), or
anything else related to the science of randomness. Fit topics
include but are not limited to; New designs and questions about
hardware or software random number generators. Questions about the
nature of randomness or the definition of randomness. This is NOT a
place to post lists of random-numbers.
END CHARTER.
PROCEDURE:
This is a request for discussion, not a call for votes. In this phase
of the process, any potential problems with the proposed newsgroups
should be raised and resolved. The discussion period will continue
for a minimum of 21 days (starting from 14 Nov 1999 23:49:55 GMT, when
the first RFD for this proposal was posted to
news.announce.newgroups), after which a Call For Votes (CFV) may be
posted by a neutral vote taker if the discussion warrants it. Please
do not attempt to vote until this happens.
All discussion of this proposal should be posted to news.groups.
This RFD attempts to comply fully with the Usenet newsgroup creation
guidelines outlined in "How to Create a New Usenet Newsgroup" and "How
to Format and Submit a New Group Proposal". Please refer to these
documents (available in news.announce.newgroups) if you have any
questions about the process.
DISTRIBUTION:
Newsgroups: news.announce.newgroups,news.groups,sci.crypt,sci.math,sci.physics,
sci.electronics.misc,sci.engr,sci.stat.math
Proponent: Scott Nelson <[EMAIL PROTECTED]>
------------------------------
From: Paul Koning <[EMAIL PROTECTED]>
Crossposted-To:
alt.security.pgp,comp.security.pgp.discuss,alt.security.scramdisk,comp.security.pgp.tech
Subject: Re: How ScramDisk will recover >> My test in container file ...
Date: Mon, 22 Nov 1999 16:48:47 -0500
[EMAIL PROTECTED] wrote:
>
> How Scramdisk will recover from say :
>
> PC power down with file/s open in container >> power down with container mounted
> + open files in container ?
No problem.
> How 1 bit / 1 byte corruption in container file will affect container >> can
> container be mounted / used ?
>
> What is the smallest damage in container that will make container useless [
> container can not be mounted = password not accepted ] ?
Same as for unencrypted volumes: one bit. But that's a
"golden beebee" error. :-)
If you clobber any bit of the data that's involved in password
checking and keying, you're totally hosed.
Similarly, on any FAT disk, encrypted or not, if you lose the
right (wrong?) bits of the boot sector, you're hosed, because
that's what the file system uses to recognize the volume as
having a FAT, and to find where the FAT is.
The difference is that the latter can be repaired by sufficient
skill and/or the right tools.
> How to make sure that container file, say 640 MB will not create any reliability
> problems ? >> the conventional drive of this capacity, 640 MB can have say 5,000
> files, when 1 file of this 5,000 files will be totally corrupted the rest of the
> storage will be very likely not corrupted. How this scenario apply to container
> file of 5,000 files in 640 MB ?
> How corruption of 1 in 5,000 files in container will render mounting possibility
> of this 640 MB od disk space ?
Use backups.
> My test in container file, by corrupting 1 byte of random data made my container
> USELESS [ could not mount it + did not recognized password ] >> this makes
> reliability of container very controversial issue >> corrupting 1 byte affected
> 640 MB of disk space !!!
Depends on which bit. I think you'll find there are a few (2? 4?)
sectors that control whether the password is accepted. Those are
critical. And then there are some more sectors that are critical
for the file system. Anything beyond that is just going to hurt
one data sector.
I don't think this makes Scramdisk useless, but you'll have to
evaluate the risks yourself. How likely is it that there
will be a data error in just those few unlucky sectors?
I've only once had a FAT file system outage, and that one
was due to Windows creating a bad partition table with
the C partition ending past the start of the D partition, so
it wrote over the D boot sector and (first) FAT. Repaired it
manually, with help from Linux tools and source code.
paul
------------------------------
From: Volker Hetzer <[EMAIL PROTECTED]>
Subject: Re: AES cyphers leak information like sieves
Date: Mon, 22 Nov 1999 13:23:22 +0100
Tim Tyler wrote:
>
> Volker Hetzer <[EMAIL PROTECTED]> wrote:
> : Tim Tyler wrote:
>
> :> I would say that (at least in the case of CBC mode chaining) it does
> :> change the security. The failure to distribute the information in the
> :> plaintext throughout the cyphertext allows types of analysis which would
> :> otherwise be impossible. For example, a partial plaintext may offer
> :> complete knowledge about a number of blocks of cyphertext. This would
> :> never happen if proper diffusion had taken place - unless the entire
> :> plaintext were known.
>
> : Okay, let's try a different approach:
> : Assume CBC.
>
> OK.
>
> : Assume, the best way to find the key, given a plaintext/ciphertext pair
> : is brute forcing the underlying block cipher.
>
> Why on earth would I want to assume such a thing?
Because you claim that a mode of chaining weakens the security of the system.
Independent of the security of the underlying block cipher.
Let's go back another level:
We assume there's a block cipher.
This block cipher transforms plaintext blocks into ciphertext blocks.
When used in ECB mode each block is independent of any other block.
Block length is 128Bit as is the Keylength.
We assume further. Given a plaintext block and the corresponding
ciphertext block, you (yes YOU personally) know of no better way
to get at the key than trying every possible key until you find
a match.
Now, given a message of n blocks encrypted in CBC and n-1
blocks of message text (you chose which blocks), do you know
of a way to get at the unknown plaintext block, that does
involve less effort than brute forcing the key from a given
tripel {plaintext,ciphertext,previous ciphertext}?
Does possessing several messages, plaintext and ciphertext,
encrypted using different IV's but the same key help you in
any way?
Greetings!
Volker
--
Hi! I'm a signature virus! Copy me into your signature file to help me spread!
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: RC4 in Kremlin US version 2.21 to tom st denis
Date: Mon, 22 Nov 1999 22:19:38 GMT
lordcow77 wrote:
> Self-synchronizing stream ciphers where the output is a complex
> function of the key and the last n ciphertext bits.
Yes, basically. The classical feedback-shift-register encryptor
is of this general type, which can be considered a form of autokey
cipher.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Codebook examples on Web?
Date: Mon, 22 Nov 1999 22:10:30 GMT
John Savard wrote:
> "Douglas A. Gwyn" <[EMAIL PROTECTED]> wrote, in part:
> >... A "one-time pad" is a pad of key that is used just one time.
> I really don't agree, though, that there is any body of established
> usage that allows "one-time pad" to mean something other than an
> "ideal one-time pad" or at least an _attempt_ at one.
It's just ordinary English language, and as a cryptologic phrase
has been in common use practically since the idea was first invented.
*Of course* every one-time pad system *tries* to provide random
key. It's a OTP even though the attempt isn't fully successful.
------------------------------
** 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
******************************
