Cryptography-Digest Digest #920, Volume #9 Wed, 21 Jul 99 16:13:02 EDT
Contents:
Re: Replacing IDEA with Blowfish ([EMAIL PROTECTED])
The best utility to restore PARADOX PASSWORDS (CryptoExplorations Lab.)
Re: Cluelessness Alert? I'm Not So Sure. (latest Crypto-Gram) (John Savard)
Re: NBE: Not crackable by brute force key search (John Savard)
Re: NBE: Not crackable by brute force key search (Volker Hetzer)
Re: NBE: Not crackable by brute force key search (Mickey McInnis)
SSL Implementation? ([EMAIL PROTECTED])
Re: Algorithm or Protocol? (John Myre)
Re: Length of public key in PGP? ([EMAIL PROTECTED])
Re: Crypt FAQ Comments : New Topics (Roger Carbol)
Turing's Treatise on Enigma (Frode Weierud)
Re: DES permutations ("David G. Koontz")
Re: Traffic flow confidentiality (David Wagner)
Re: Looking for RC4 alternative (Mark Leighton Fisher)
Re: How Big is a Byte? (was: New Encryption Product!) (Finder Keeper)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Replacing IDEA with Blowfish
Date: Wed, 21 Jul 1999 13:16:10 GMT
In article <7n2stc$220u$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (SCOTT19U.ZIP_GUY) wrote:
> In article <[EMAIL PROTECTED]>, Paul Koning
<[EMAIL PROTECTED]> wrote:
> >[EMAIL PROTECTED] wrote:
> >> ...
> >> 3) There are designs for Blowfish in hardware, I dunno if they
have
> >> been done yet or not. IDEA was designed for hardware and software
> >> (somewhat).
> >
> >"somewhat" is right. IDEA uses multiplication, which is expensive
> >in hardware (or slow). Feistel networks such as in Blowfish are
> >far cheaper. Then again, in the case of Blowfish the large size
> >of the key schedule hurts.
> >
> > paul
>
> actaully since IDEA use multiplicatiopn of a variable times a
constant
> each one of those could be repacled by a small 16X16 bit S table.
> which is not so expensive. Also one could could improve IDEA by
> usinging a larger class of functions instead of a lowly multiply which
> may make it more vulnerable to being broken.
Yes, and no. If you replace the multiplies that are done mod (2^16)+1,
it will work. However, if you change the internal multiplies, the ones
that are not done mod (2^16)+1, it will not work. I tried messing
around with that part of the cipher and nothing works. If you still
don't know which multiplies I'm talking about, just follow the key
schedule of IDEA. Only 18 of the 52 subkeys need inverses. Another 18
are used for the additions, leaving 16 subkeys which do not have to be
inverses for decryption. These 16 relate to the multiplies that you
can't change.
>
> David A. Scott
> --
> SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
> http://www.jim.com/jamesd/Kong/scott19u.zip
> http://members.xoom.com/ecil/index.htm
> NOTE EMAIL address is for SPAMERS
>
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: CryptoExplorations Lab. <[EMAIL PROTECTED]>
Subject: The best utility to restore PARADOX PASSWORDS
Date: Wed, 21 Jul 1999 13:46:02 GMT
Ultimate Paradox CryptoExplorer for Win9X/NT v1.7
Please visit us at http://cryptoexplorer.da.ru
- 100% guarantee that you can open and read an encrypted table or script
- Works with Paradox tables and scripts
- Supports any version of Paradox and BDE (Borland Database Engine)
which was used in Borland Delphi and Borland C++ Builder
- Allows you to check your version of Paradox/BDE for backdoors
(there are passwords which can open any encrypted object in some
versions)
- Shows you all the passwords which can open your table that helps you
find the original password (may be you need it for some reasons)
- You can also find a secret password used by Borland for a backdoor in
your version of Paradox/BDE
- Incredibly high speed much higher than in ordinary brute-force
algorithm
- You will have a working password in a few seconds
Copyright (C) 1999 CryptoExplorations Lab.
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Cluelessness Alert? I'm Not So Sure. (latest Crypto-Gram)
Date: Wed, 21 Jul 1999 15:10:29 GMT
[EMAIL PROTECTED] (Roger Fleming) wrote, in part:
>For example, there is no mention of validation and
>auditing of site updates by 'legitimate' webmasters. You need to give careful
>consideration to preventing a webmaster from accidentally uploading data he
>shouldn't. (This is very tricky indeed; I suspect there isn't yet any
>electronic means smart enough to cover all aspects of this). He might also do
>this maliciously, so you need to be able to prove exactly who performed any
>modification to the site, even if they are authorised to do so.
That certainly is an important point. There are probably many others
that I wouldn't have any idea about, but the need to have an audit
trail of authorized modifications is probably close to being a
standard security precaution. (Of course, someone might quibble that
once you've put a telephone on someone's desk, you've given him a way
to smuggle out information...)
Although the kind of precautions I've suggested are indeed excessive
for commercial sites, though, the main problem with them - the reason
they're so expensive and cumbersome - is that they require
_nonstandard_ hardware and software.
Imagine the following "excessive" virus protection scheme: my computer
has two hard drives; I put all my executables on the first drive;
except when I'm installing software, the write-enable switch for that
drive, on my computer's front panel, is *off*.
That won't work very well with today's operating systems...I don't
know how to tell Windows 98 not to put all my E-mail on drive C,
without installing another E-mail program, but obviously the cost of a
switch and two wires isn't that great.
I'm not going to attempt to write a textbook on security. Nor would I
even try to describe what kind of excesses would be required to allow
CGI scripts to run, safely, on a computer open to public web access,
and connected to an internal network containing secret information
vital to national security. Just thinking about them seems to me to
support my original point: that the military isn't that far off-base
in wanting to keep public web servers or other Internet points of
access for hackers disconnected from computers doing any kind of
sensitive work. (How about computers doing "real" work, period - any
kinds of calculations too valuable to endure a risk of downtime?)
John Savard ( teneerf<- )
http://www.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: NBE: Not crackable by brute force key search
Date: Wed, 21 Jul 1999 15:16:50 GMT
Volker Hetzer <[EMAIL PROTECTED]> wrote, in part:
>This is not all. Somehow you have to decide when you are finished.
>The OTP is the classical example where this part is the impossible one.
>If you can't make assumtions about the plaintext you cannot "beat"
>ANY algorithm.
Yes: i.e. if the plaintext is perfectly random, then any decipherment
- by any (conservative) method, even monalphabetic substitution -
yields a possible plaintext. This is the complement of the OTP where
all possible plaintexts (although they can be a subset of possible
character strings) remain possible.
John Savard ( teneerf<- )
http://www.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: Volker Hetzer <[EMAIL PROTECTED]>
Subject: Re: NBE: Not crackable by brute force key search
Date: Wed, 21 Jul 1999 16:42:50 +0200
James Andrews wrote:
>
> But surely, if any method of deciphering ends with the plaintext,
> regardless of how, the code itself is broken, even if only for this
> instance. Tom pointed out in an earlier discussion, any algorithm can be
> beaten by brute force, you just use the algorithm and churn the
> potential keys through it.
This is not all. Somehow you have to decide when you are finished.
The OTP is the classical example where this part is the impossible one.
If you can't make assumtions about the plaintext you cannot "beat"
ANY algorithm.
And getting one plaintext/ciphertext/key triple does not mean the code
is broken unless this triple helps you to fine other triples.
Greetings!
Volker
------------------------------
From: [EMAIL PROTECTED] (Mickey McInnis)
Subject: Re: NBE: Not crackable by brute force key search
Date: 21 Jul 1999 15:54:02 GMT
Reply-To: [EMAIL PROTECTED]
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
(John Savard) writes:
|> Volker Hetzer <[EMAIL PROTECTED]> wrote, in part:
|>
|> >This is not all. Somehow you have to decide when you are finished.
|> >The OTP is the classical example where this part is the impossible one.
|> >If you can't make assumtions about the plaintext you cannot "beat"
|> >ANY algorithm.
|>
|> Yes: i.e. if the plaintext is perfectly random, then any decipherment
|> - by any (conservative) method, even monalphabetic substitution -
|> yields a possible plaintext. This is the complement of the OTP where
|> all possible plaintexts (although they can be a subset of possible
|> character strings) remain possible.
|>
|> John Savard ( teneerf<- )
|> http://www.ecn.ab.ca/~jsavard/crypto.htm
Well, you could design a cryptosystem where this wasn't true, and there
might be reason to do so. One example would be a system that made a
hash of the orignal cleartext, appended the hash to the cleartext, and
then encrypts.
While this sounds like you've deliberately weakened your cryptosystem,
it's not necessarily a bad idea. You might want to have your
cryptosystem designed to verify that you've decrypted the correct
message. You also like to be sure that a cryptosystem is safe
from a known-plaintext or chosen-plaintext attack, in which case,
the "verifyability" of a trial decryption doesn't matter.
--
Mickey McInnis - [EMAIL PROTECTED]
--
All opinions expressed are my own opinions, not my company's opinions.
------------------------------
From: [EMAIL PROTECTED]
Subject: SSL Implementation?
Date: Wed, 21 Jul 1999 15:53:58 GMT
I am looking for information on the implemanation of SSL. I am not an
expert in RSA, but I understand it is used for this protocol. What I
need to know if how extensive is the algorithm for server
authentication, no client authentication. It is my understanding that
the use of the public key for authentication and encryption is not
extensive, it is when using the private key that requires a fast
processor. Specifically, can SSL be handled by a processor like a Z80?
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: John Myre <[EMAIL PROTECTED]>
Subject: Re: Algorithm or Protocol?
Date: Wed, 21 Jul 1999 10:08:37 -0600
wtshaw wrote:
<snip earlier posts...>
> I see a protocol as something that an user does, requiring a series of
> actions to follow through.
<snip...>
> However, a protocol put in streamlined form may be or become part of an
> algorithm in actuality.
<snip...>
Different people use the terms "algorithm" and "protocol" in different
ways, so there can be arguments about their definitions. They are
similar in that both refer to a well-defined sequence of steps. From
what I've seen, the big difference is that a "protocol" explicitly
involves more than one party. For example, there are communications
protocols like IP and TCP. Diplomatic protocols describe how people
should interact, such as how an "ambassador" should speak to a "king".
I suppose that, strictly speaking, any "protocol" that is well defined
is also an "algorithm". Thus, for example, we speak of the "Diffie
Hellman key exchange algorithm". Still, most of the time I see
"algorithm" it means a single party computation, so that protocols
use algorithms as components.
(And of course, on top of "protocols" we have "systems"...)
John M.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Length of public key in PGP?
Date: Wed, 21 Jul 1999 16:58:50 GMT
After you break the text into pieces and encrypt each, how do you
know the length of the each chunk in the ciphertext? You can use a
delimiter to indicate the separation of the chunks, but the problems are
1) It's not nice; 2) Can a hacker use that piece information?
Thanks in advance.
Weedlet
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> > P = 181 Q = 229 E = 7 D = 5863 PQ = 41449; If T = 33245,
then
> > ciphertext = 40140, decryptedtext = 33245. No problem.
>
> > P = 137 Q = 191 E = 3 D = 17227 PQ = 26167; If T =
332453243,
> > then ciphertext = 24661, decryptedtext = 1508. *** Problem ***
>
> When you have a plain text that is too large for the key, you break it
up
> into blocks like so:
>
> P = 137 Q = 191 E = 3 D = 17227 PQ = 26167:
> T = 33245 C = ???? Decrypted = 33245
> T = 3243 C = ???? Decrypted = 3243
> (Sorry, don't feel like doing calculations.)
>
> By breaking it up into blocks you fix the problem of T being bigger
than PQ.
>
>
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
Subject: Re: Crypt FAQ Comments : New Topics
From: Roger Carbol <[EMAIL PROTECTED]>
Date: Mon, 19 Jul 1999 15:28:12 GMT
David A Molnar <[EMAIL PROTECTED]> wrote:
> Here's some suggestions for possible new topics (or expansions of
> old ones) in the sci.crypt FAQ :
I have a hunch that the sorts of people to whom the FAQ would be
most useful might also have a few questions about Stephenson's
"Cryptonomicon". It's not quite on topic for sci.crypt, but I
suspect having at least a short entry on it would be helpful for
at least some of the FAQ's users.
Besides, I think Solitaire is neat enough to get squeezed into
the FAQ somehow.
.. Roger Carbol .. [EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED] (Frode Weierud)
Crossposted-To: sci.crypt.research
Subject: Turing's Treatise on Enigma
Date: 21 Jul 1999 18:52:57 -0000
I have just gone public with three chapters of Turing's Treatise on
Enigma. This is a joint effort of three members of the Crypto Simulation
Group who have entirely retyped the Treatise. The only publicly existing
copy, which is coming from NARA, is extremely poor in many places and
even if the complete text now has been retyped there is still a lot of
work left to get all the drawings and tables done correctly.
The three chapters which now have been released should be seen as
preliminary versions. We are working hard on preparing the other chapters
but it probably will still take a few months before we will do the next
release.
You can access the Web page with the Treatise from my Cryptology page at:
http://home.cern.ch/~frode/crypto/index.html
Please enjoy. It is interesting reading.
Frode
--
Frode Weierud Phone : +41 22 7674794
CERN, SL, CH-1211 Geneva 23, Fax : +41 22 7679185
Switzerland E-mail : [EMAIL PROTECTED]
WWW : wwwcn.cern.ch/~frode
------------------------------
From: "David G. Koontz" <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: DES permutations
Date: Wed, 21 Jul 1999 12:19:00 -0700
Paul Koning wrote:
>
> [EMAIL PROTECTED] wrote:
> > ...
> > But how does it make the wiring simpler? As far as I can see it only
> > makes it more complicated.
>
> I've been saying that too.
>
> Bruce Scheier mentioned that it does help in multi-chip implementations.
> I didn't realize any existed; the earliest I remember is a single
> chip one from AMD. If you had to do DES in technology that
> requires more than one chip, it seems plausible it would slightly
> simplify the input demux (which, in that sort of technology, would
> be a help).
The Initial Permutation
The Initial Permuation (IP) is a description of how a byte wide interface is
connected to a 64 bit block comprised of two 32 bit blocks (L and R).
Consider
a byte wide interface with the bits numbered 1-8. The event numbered bits
go to the L Block and the odd numbered bits go to the R block. Note that the
bit order is big endian, where bit 1 is most significant and bit 8 is least
least significant. The input block is typically loaded as 8 successive byte
loads:
Port MSB7 Input (LR) Left
Bit Bit Block (64 bits) Block (32 bits)
2------6-------58 50 42 34 26 18 10 2 1 2 3 4 5 6 7 8
4------4-------60 52 44 36 28 20 12 4 9 10 11 12 13 14 15 16
6------2-------62 54 46 38 30 22 14 6 17 18 19 20 21 22 23 24
8------0-------64 56 48 40 32 24 16 8 25 26 27 28 29 30 31 32
Right
Block (32 bits)
1------7-------57 49 41 33 25 17 9 1 1 2 3 4 5 6 7 8
3------5-------59 51 43 35 27 19 11 3 9 10 11 12 13 14 15 16
5------3-------61 53 45 37 29 21 13 5 17 18 19 20 21 22 23 24
7------1-------63 55 47 39 31 23 15 7 25 26 27 28 29 30 31 32
Input Byte 8 7 6 5 4 3 2 1
You end up with a byte wide interface for data (Inverse IP swaps odd
and even output byte bits). Each L,R register in the implementation can
be parallel loaded (round interation), serially loaded with plaintext or
ciphertext, or serially unloade with ciphertext or plaintext. This
yields flip flops in the L,R registers with 3 sources:
serial in
parallel in
hold
When you use a (gasp!) gated clock, you can implement the L,R registers
As off the shelf (at the time) Medium Scale Integration (MSI), universal
shift registers (in 4 bit pieces) - 7495s. Note only one shift direction
is needed.
If I recall correctly, Fairchild was the first company to offer a 16 bit
peripheral chip, followed by AMD. Peripherals were defacto 8 bit wide
when the DES was instituted. In any event wider inputs would mean
multiplexers for each input bit, and sequencer logic.
Permuted Choice 1
PC1 performs a similar function loading the C and D 28 bit registers
(comprised
of three 8 bit bidirectional shift register and 1 4 bit bidirectional shift
register, all with parallel outputs). The C and D registers can be serially
loaded (shifting right), or serially shifted left or right in a closed ring
for encryption or decryption.
Port MSB7
Bits Bits
Input (CD) C
Block, 64 bits Block (28 bits)
1--------7------57 49 41 33 25 17 9 1 MS 1 2 3 4 5 6 7 8
2--------6------58 50 42 34 26 18 10 2 9 10 11 12 13 14 15 16
3--------5------59 51 43 35 27 19 11 3 17 18 19 20 21 22 23 24
4--------4------60 52 44 36 ----------- (C(28)) 25 26 27 28
D
Block (28 bits)
7--------1------63 55 47 39 31 23 15 7 1 2 3 4 5 6 7 8
6--------2------62 54 46 38 30 22 14 6 9 10 11 12 13 14 15 16
5--------3------61 53 45 37 29 21 33 5 17 18 19 20 21 22 23 24
4-------(D(25)--------------28 20 12 4 25 26 27 28
8--------0------64 56 48 40 32 24 16 8 LS (parity)
Input Byte 8 7 6 5 4 3 2 1
Note that bit 4 is used as input for both C and D. This implies that C(28)
output is used as the serial input to D(25). The least significant bit is
used for odd parity.
The C,D registers can be implemented as shifting both left and right
for both encryption and decryption (C and D registers shift in opposite
directions as specified by PC2). They require parallel outputs for
Permuted Choice 2. The 7495s can shift in both directions.
The first released DES implementation was the Fairchild 9414 chip set
comprised of four 40 pin bipolar devices, identical except for mask
differentiated S Boxes. Each slice had 8 bits of L and R, two S boxes and
28 bits of C or D. The secound was an 8741 implementation from Intel
intended for point of sales implementations. The third was from Western
Digital. The fourth the AMD 9513 chip.
Interestingly enough, if the ROMs were available today - not to mention
DIP package MSI devices. A 1970s technology implementation would take
a PC board approximately 8 by 10 inches. Through packaging and PC board
tecnology advances alone, the same design could fit on a business card
(components mounted on both sides). If it were possible to do an ASIC
in a 16 pin DIP, a single port implementation would easily fit.
Understanding where the data really flows is extremely helpfull in FPGA
implementations. Think of it as conserving interconnect resources.
------------------------------
From: [EMAIL PROTECTED] (David Wagner)
Subject: Re: Traffic flow confidentiality
Date: 21 Jul 1999 12:08:01 -0700
In article <[EMAIL PROTECTED]>,
Thierry Moreau <[EMAIL PROTECTED]> wrote:
> Briefly, trafic flow confidentiality is a "security service" that would
> prevent someone from guessing even the level of traffic to/from a
> subnetwork or end systems.
I think we might be getting hung up on word games here.
There's a difference between trying to hide the contents of the web
page I'm viewing (`clickstream privacy'?) and trying to hide even the
amount of traffic transmitted (`bandwidth privacy'?). I agree that
providing bandwidth privacy is quite challenging.
However, SSL does not even provide clickstream privacy very reliably.
You can argue over whether SSL was intended to provide clickstream
privacy or not, but I would argue that many users (rightly or wrongly)
expect SSL to provide clickstream privacy, so there is either an
education problem or a technical problem.
In this respect, the lack of padding is relevant to the discussion.
(I don't know whether padding would actually provide clickstream privacy,
but I too am surprised that the standard doesn't even allow for the
possibility.)
Do you agree?
------------------------------
From: [EMAIL PROTECTED] (Mark Leighton Fisher)
Subject: Re: Looking for RC4 alternative
Date: Wed, 21 Jul 1999 13:39:11 -0500
In article <LiSk3.8$[EMAIL PROTECTED]>, [EMAIL PROTECTED] says...
> In our development environment we're using MD5 for hashing and RC4 as a
> stream cipher.
Also, you should at least look at SHA rather than MD5, as MD5 has been
shown to have at least theoretical weaknesses.
==========================================================
Mark Leighton Fisher Thomson Consumer Electronics
[email protected] Indianapolis, IN
"Browser Torture Specialist, First Class"
------------------------------
From: [EMAIL PROTECTED] (Finder Keeper)
Crossposted-To: alt.folklore.computers
Subject: Re: How Big is a Byte? (was: New Encryption Product!)
Date: 21 Jul 1999 20:00:03 GMT
Reply-To: REMOVE X AND Y <[EMAIL PROTECTED]>
But zero isn't the first number. It's the zero-th number.
Cheerio,
Vega
Michael D. ([EMAIL PROTECTED]) wrote:
: I think that a major problem that we all have is that our mothers, yes, mine
: as well as yours, taught us that the first number is one(1) rather than
: zero(0). It was cute when we were three(3), but now, as a result of that
: conditioning, we cannot do math in our heads.
: Michael D.
: [EMAIL PROTECTED]
: <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED]...
: > wtshaw wrote:
: > >
: > > In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
: wrote:
: > >
: > > >
: > > > The IBM 7074 was a decimal based machine. Ours had 10,000 ten digit
: > > > signed words. Each of the digits used five bits with a two-out-of-five
: > > > coding scheme.
: > > >
: > > > So perhaps God did mean for us to think in decimal....
: > > >
: > > Please try not to confuse IBM with God; on the other hand, God is not
: apt
: > > to be confused, just perplexed.
: > >
: > > Occasionally, people, individuals, families, have other then ten
: fingers;
: > > God allows options and gives all of them a chance.
: >
: > I'm having a real hard time working out base zero arithmetic.
: >
: > > --
: > > Most wrestlers and politicians seem to have pretty the same
: > > agenda, seek various kinds of by appearing to do things they are
: > > not doing, catering to specialty groups of supporters, and as a
: > > result of deals, learn to take falls when they know better. Those
: > > who do not go along tend to be excluded and punished.
--
Vega Paithankar
Remove X and Y before replying
------------------------------
** 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
******************************
