Cryptography-Digest Digest #300, Volume #12 Thu, 27 Jul 00 17:13:01 EDT
Contents:
Re: On using compression as proper means of encryption (Anton Stiglic)
Re: How is the security of Outlook Express encryption ? (Shawn Willden)
Re: How is the security of Outlook Express encryption ? (Shawn Willden)
Re: The Purple Cipher (World War II) (Sundial Services)
Re: Enigma (Sundial Services)
Re: Elliptic Curves encryption (Steve Weis)
Re: Enigma (JPeschel)
Re: BassOmatic symmetric block cipher, any help ? (Paul Rubin)
Re: MD5 Expansion (John Myre)
Re: The Purple Cipher (World War II) (JimD)
Re: Elliptic Curves encryption (Jerry Coffin)
Re: MD5 algorithm questions (Bill Unruh)
Re: Database encryption (Mok-Kong Shen)
Re: MD5 Expansion (Bill Unruh)
Re: Selecting cipher - which one to use? (Helger Lipmaa)
Re: MD5 Expansion (Daniel Leonard)
Re: PGP US Versions Broken,no good?? (Edward A. Falk)
----------------------------------------------------------------------------
From: Anton Stiglic <[EMAIL PROTECTED]>
Subject: Re: On using compression as proper means of encryption
Date: Thu, 27 Jul 2000 13:59:59 -0400
"Douglas A. Gwyn" wrote:
>
> Here is a compromise suggestion: When initiating a new topic,
> start by stating the theme without any historical or technical
> elaboration, then skip a line and begin to elaborate. E.g.
>
> Has anybody looked into the connection between Good transforms
> and Fast Fourier transforms?
>
> The Good transform was invented ...
>
> The trick that both transforms use to short-cut computation ...
This for example would considerably please me. An abstract, as
Guy Macon suggested (which is different from an introduction).
Your posts are very interesting (this is why I even bothered posting
my suggestion). The only problem is that I don't have time to study
all parts of cryptography (since it spans allot!), and I'm interested
in reading only stuff in which I have worked on or know something about.
Regards,
Anton
------------------------------
Subject: Re: How is the security of Outlook Express encryption ?
From: Shawn Willden <[EMAIL PROTECTED]>
Date: 27 Jul 2000 12:10:41 -0600
[EMAIL PROTECTED] (Sébastien SAUVAGE) writes:
> The protocols used for email (SMTP and POP3) are NOT encrypted.
Correct, but not relevant. It doesn't matter that the e-mail
protocols are unencrypted, as long as the contents of the messages
they're moving are encrypted, unless, of course you're concerned about
traffic analysis, in which case you'd better look into anonymous
remailers.
> Thus your ISP can read all your emails.
Only if the messages were sent unencrypted.
> Outlook downloads these messages in clear, and then encrypts them
> before writing them to disk.
I wasn't aware that Outlook encrypts local files.
Outlook does have the ability to digitally sign and encrypt messages
before sending. To do this it uses 1024-bit RSA and 168-bit 3DES.
Assuming that Microsoft hasn't done anything stupid or malicious in
the implementation and assuming that the machines of the sender and
recipient are not hacked by an attacker, the security should be
perfectly adequate.
Of course, if your messages are such that they really require high
security, you'd better assume that your opponent will be willing to
hack your machine.
> If you want to encrypt your message so that your ISP cannot read them,
> you will have to use PGP (using private/public key cryptosystem.)
> PGP 6.5.1i is free. http://www.pgpi.org.
That works as well, but is somewhat less convenient to use.
Shawn.
------------------------------
Subject: Re: How is the security of Outlook Express encryption ?
From: Shawn Willden <[EMAIL PROTECTED]>
Date: 27 Jul 2000 12:18:05 -0600
[EMAIL PROTECTED] (Guy Macon) writes:
> Sébastien SAUVAGE wrote:
> >[EMAIL PROTECTED] (???) wrote:
> >> How about PGP ? Does it suffer form the attack of DLL interception ?
> >Every single program (Windows Explorer, Outlook, PGP, your browser,
> >your very own firewall, your antivirus, games...) can be hooked.
> Almost correct, but not quite. I have systems with ROMDOS and other
> systems with Embedded NT in EPROM. Those can't be hooked.
Almost correct, but not quite. Those are harder to hook. The
attacker may still be able to subvert the system by loading software
in RAM and tricking the system into executing it instead of the ROM
code.
And, of course, the attacker can replace the ROM with a, err,
customized version.
Shawn.
------------------------------
Date: Thu, 27 Jul 2000 11:50:53 -0700
From: Sundial Services <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: The Purple Cipher (World War II)
Purple and Enigma were entirely different machines with entirely
different techniques for solution. I don't know how one would answer
the question about which one was harder except possibly to dig up Mr.
Friedman himself and ask him. ;-)
>Charles Blair wrote:
> I am curious about the comparison between purple and enigma. Were
> the techniques for breaking similar? Were the projects done completely
> independently of one another? Is it possible to say which break was
> intellectually more difficult?
------------------------------
Date: Thu, 27 Jul 2000 11:58:01 -0700
From: Sundial Services <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: Enigma
> Matthew S wrote:
> Does anyone know where I can get source code or PC executable for an
> Enigma machine? I have only found source for a 1 rotor machine when I'd
> like 3 or 4.
You should be able to expand the program you have to include multiple
rotors and it will serve you well to try.
Envision the rotor as a 26-element array (let's say the indexes are
0..25) which contains elements also in the range 0-25. So each entry is
the output-position of that particular "wire."
A separate variable (again, values 0..25) points to the "A"-position of
the rotor. Represent the letter that you're dealing with now as another
number, A=0..Z=25.
Now get familiar with modular arithmetic. (aPosition + letter) mod 26
gives you the position of the desired table entry. The number in this
entry in the table, "plus aPosition, modulo 26," gives you the
corresponding output letter. This is now used as input to the next
rotor. "Stepping the rotor" is done by incrementing the "A"-position
variable ... once again, modulo 26.
The "reverse path back through the rotor" is most easily handled by
creating another rotor-table that is a mirror-image of the first and
presumably created from the first, such that if "x[n] = c," then "y[c] =
n."
And so on. Writing this code and debugging it will be much more
valuable than lifting it and working from there.
------------------------------
From: Steve Weis <[EMAIL PROTECTED]>
Subject: Re: Elliptic Curves encryption
Date: Thu, 27 Jul 2000 12:03:56 -0700
Mike Rosing wrote:
> ECC uses fewer resources than RSA, so it's cheaper to implement in
> hardware. The keys are also much smaller for the same strength, so
> it uses less bandwidth. For many commercial applications this is
> important. For many other applications, it isn't important at all.
> So the crypto to use for any particular situation depends on a lot
> of external factors, not just the math used.
In my experience with ECC over GF(p) or GF(2^n), it has slower
verfication performance vs. RSA by an order of magnitude. ECC has shown
faster signing performance and appears to scale to larger key lengths
much better.
I am curious to how implementing ECC over optimal extension fields
affects performance. Has anyone had any experience with this?
------------------------------
From: [EMAIL PROTECTED] (JPeschel)
Subject: Re: Enigma
Date: 27 Jul 2000 19:07:02 GMT
Matthew S writes, in part:
>Does anyone know where I can get source code or PC executable for an
>Enigma machine?
You can find Enigma source code and executables, as well
as Enigma links on the "Historical" page of my web site.
You'll also find Jim Gillogly's paper describing his ciphertext-
only attack on Enigma.
Joe
__________________________________________
Joe Peschel
D.O.E. SysWorks
http://members.aol.com/jpeschel/index.htm
__________________________________________
------------------------------
From: [EMAIL PROTECTED] (Paul Rubin)
Crossposted-To: alt.security.pgp
Subject: Re: BassOmatic symmetric block cipher, any help ?
Date: 27 Jul 2000 19:13:57 GMT
In article <[EMAIL PROTECTED]>, jungle <[EMAIL PROTECTED]> wrote:
>any help on the BassOmatic symmetric block cipher ?
>
>it has been used with 256 byte [ ??? ] block size for the plaintext and the
>ciphertext ...
>the key size of up to 256 bytes [ ??? ] was used to & CFB mode ...
>
>I have difficulties to find any info & reviews about it ...
>
>has it been compromised ?
Hee hee, see Simson Garfinkel's book on PGP, or the PGP 2.x or later docs
for more info about this.
Basically Phil went to a cryptography conference and asked Eli Biham
during lunch in the cafeteria to look at BassoMatic. Biham pretty
much shredded it in less than ten minutes. Phil switched to IDEA for
PGP 2.x and "got religion" about cipher design, swearing off designing
his own ciphers from then on.
------------------------------
From: John Myre <[EMAIL PROTECTED]>
Subject: Re: MD5 Expansion
Date: Thu, 27 Jul 2000 13:26:02 -0600
Anton Stiglic wrote:
<snip>
> I would think that to get 320-bit security, you'd have to redesign the
> hash function from scratch. (?)
> Maybe a more flexible hash function (similar to Blowifish, RC4/5 are
> compared to DES in the block cipher world), who's *internals* can be
> easily modified to produce different size outputs, would be a good idea?
<snip>
In that regard, have you ever looked at Panama? It's designed in the
first place to create a 256-bit hash, but the mechanics of its operation
mean that you can output a hash as long as you like. This is because,
using the same algorithm, the designers claim you can use the output as
a stream cipher (keystream).
The designers give arguments why the construction ought to be secure,
but don't go so far as claim that the hash is really 256 bits strong,
or any other number. There is a big internal state (8736 bits), so
at least there can be enough entropy for a bigger hash output. As
usual, though, nobody really knows how good it is.
JM
------------------------------
From: [EMAIL PROTECTED] (JimD)
Subject: Re: The Purple Cipher (World War II)
Reply-To: JimD
Date: Thu, 27 Jul 2000 18:51:18 GMT
On Thu, 27 Jul 2000 12:24:06 GMT, [EMAIL PROTECTED] (Charles Blair) wrote:
> I am curious about the comparison between purple and enigma. Were
>the techniques for breaking similar? Were the projects done completely
>independently of one another? Is it possible to say which break was
>intellectually more difficult?
The Purple was a different animal altogether. Unless I'm mistaken
it was enciphered code and not a cipher.
They were independent. Purple was broken before Pearl Harbour.
Difficult to say. Purple was in a Japanese telegraphic language
and there weren't many Americans who were familiar with it. It
must have been quite a intellectual feat in many ways.
Enigma seems to have been more of a mathematical problem as it
was a cipher. There were plenty German linguists available.
--
__________________________
Jim Dunnett.
g4rga at thersgb.net
------------------------------
From: Jerry Coffin <[EMAIL PROTECTED]>
Subject: Re: Elliptic Curves encryption
Date: Thu, 27 Jul 2000 13:54:18 -0600
In article <[EMAIL PROTECTED]>, djohn37050
@aol.com says...
> Also, ECC CAN be used to transfer/encrypt data/keys. Think of ECC and RSA
> having the "same" public key magic potential; the differences lie in the
> externals, size of keys, ease and performance of operations, etc.
True -- people have come up with forms of encryption based on modular
exponentiation that can encrypt data as well even though the original
Diffie-Hellman was only for passwords.
IOW, all three of the fundamental types of PK encryption _can_ be
used to encrypt data. OTOH, there are very few situations in which I
can imagine doing so. One possibility would be if you were simply
encrypting only a VERY small amount of data (on the same general
order as the size of a useful key for a symmetric algorithm).
Another possibility would be if you just didn't have enough code
space for both a PK and a symmetric algorithm, and the performance of
the PK algorithm was sufficient for the job at hand.
Another possibility would be if you consider the strength of a PK
algorithm more dependable than the strength of a symmetric algorithm.
The problems underlying the PK algorithms have been studied enough
that in most cases we have at least some idea of a lower bound on the
complexity of a solution. In most symmetric algorithms, that's
really not the case -- there's always the theoretical possibility of
a "back door" or some catastrophic break. I'll grant you that I
don't honestly think those exist for most symmetric algorithms, but I
know one guy who's still convinced that there's a "back door" built
into DES...
--
Later,
Jerry.
The universe is a figment of its own imagination.
------------------------------
From: [EMAIL PROTECTED] (Bill Unruh)
Crossposted-To: comp.security.unix,alt.computer.security
Subject: Re: MD5 algorithm questions
Date: 27 Jul 2000 19:58:00 GMT
In <OKXbsx19$GA.233@cpmsnbbsa07> "Joseph Ashwood" <[EMAIL PROTECTED]> writes:
]I was mostly pointing out that by including all the sizes less than 64 bit
]he was effectively doubling the samples. But if your equation is correct (I
]haven't taken the time to remember it yet), then I should change my
]statement from "the odds are significantly higher" to "you're gonna have a
]collision." That's certainly not a pedantic observation (IMO).
] Joe
]> <Pedantic on>
]> The number of numbers of length n bits is 2^(n+1)-1. However, the
]> "birthday" probability is
]> exp(- (r*(r+1)/2N) where is the number of trials, and N is the total
]> number of numbers (2^128 in his case). This equals 1/2 when
]> (r(r+1)/2N=.69, or r=-1 +sqrt(1+4(.69)2N)) \approx 2.34 sqrt(N) \approx
]> 1.17*2^65
]> <Pedantic off>
Ah, yes, if one gets pedantic, one should get the numbers right. The
solution of a quadratic clearly has a 2 in the denominator. Thus the
solution is approx 1.17 sqrt(N). or 1.17 2^64 for the 50% level. For
2^65 possibilities ( all numbers with up to 64 bits) the probability
rises to about 87%.
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Database encryption
Date: Thu, 27 Jul 2000 22:20:08 +0200
ganges wrote:
> Runu Knips <[EMAIL PROTECTED]> wrote:
> > Paul Rubin wrote:
> > > So in general, one should not use cryptography software to secure
> > > highly sensitive data. It's simply too easy for keys to escape by
> > > accident or on purpose. If the software crashes and leaves a core
> > > dump, the keys may be in it. If the computer gets a virus, that
> might
> > > scan memory and find the keys. And so on. Sensitive data should be
> > > secured by hardware.
> >
> > But if you can steal the disc, you can steal the hardware with the
> > keys, too ? I don't understand the advantage here.
> >
> Not true, with many hardware encryption boxes, the casing is tamper
> proof. So, if the box is pried open, or disturbed in any way the
> encryption keys are automatically deleted.
Is is correct that there will be installed alongside the computer and
the disks (where the database resides) a temper-proof box that
accepts different keys of the users and do the encryptions of the
data entered by the users and pass the encrypted stuffs to the
database program? If we have worried so much, then I suppose
there is one attack that should also be considered: How does one
guarantee that part of the database wouldn't be altered or deleted?
Or how does one know that the database system has not been
infected by viruses? We need a hemetic protection for the whole,
including computer, discs, database software and data input devices,
as well as tempest shielding of the computing room and a rigorous
control of persons entering it, don't we?
M. K. Shen
------------------------------
From: [EMAIL PROTECTED] (Bill Unruh)
Subject: Re: MD5 Expansion
Date: 27 Jul 2000 20:06:55 GMT
In <[EMAIL PROTECTED]> Anton Stiglic <[EMAIL PROTECTED]> writes:
]"David A. Wagner" wrote:
]>
]> Anton Stiglic <[EMAIL PROTECTED]> wrote:
]> > So a provable way of extending the output of a secure hash
]> > function h is to simply split the input m into two equal halves
]> > am and bm (such that m = am || bm, || is concatenation) and output
]> > h(am) || h(bm).
]>
]> Be careful. This can't make collisions any easier to find, but the
]> `secrecy properties' get worse, because the construction can make
]> dictionary attacks easier.
An easy way to see this is to extend it so that you split the input into
single bytes, and hash each input byte. The output will be 128 bits
times the total number of bytes you fed in. However this hash is
completely trivial to break (ie, know the text from the hash)
while being completely resistant to collisions.
------------------------------
From: Helger Lipmaa <[EMAIL PROTECTED]>
Subject: Re: Selecting cipher - which one to use?
Date: Fri, 28 Jul 2000 01:14:17 +0300
Runu Knips wrote:
> Mok-Kong Shen wrote:
> > Runu Knips wrote:
> > > (a) Don't use IDEA. It uses only 64-bit blocks, uses multiplications and
> > > even worse it is PATENTED and you'll have to pay (much !) money for using
> > > it.
> >
> > I understand what you said except 'multiplications'. What's inherently
> > wrong with using multiplications? Thanks.
>
> Well, nothing, except that they're expensive, slow (except
> if you give them many gates of course), and can be used for
> timing attacks.
IDEA is actually very fast on the Pentium III. See
http://www.tml.hut.fi/~helger/fastaes/. The idea is that you can implement four
IDEAs in parallel, using the MMX technology. Then use a counter mode upon it
(which would also satisfy your requirements for piecewise decryption),
and the resulting cipher is faster on P3 than RC6.
Helger
------------------------------
From: Daniel Leonard <[EMAIL PROTECTED]>
Subject: Re: MD5 Expansion
Date: Thu, 27 Jul 2000 20:38:13 GMT
On 27 Jul 2000, Bill Unruh wrote:
> In <[EMAIL PROTECTED]> Anton Stiglic <[EMAIL PROTECTED]> writes:
>=20
> ]"David A. Wagner" wrote:
> ]>=20
> ]> Anton Stiglic <[EMAIL PROTECTED]> wrote:
> ]> > So a provable way of extending the output of a secure hash
> ]> > function h is to simply split the input m into two equal halves
> ]> > am and bm (such that m =3D am || bm, || is concatenation) and output
> ]> > h(am) || h(bm).
> ]>=20
> ]> Be careful. This can't make collisions any easier to find, but the
> ]> `secrecy properties' get worse, because the construction can make
> ]> dictionary attacks easier.
>=20
> An easy way to see this is to extend it so that you split the input into
> single bytes, and hash each input byte. The output will be 128 bits
> times the total number of bytes you fed in. However this hash is
> completely trivial to break (ie, know the text from the hash)=20
> while being completely resistant to collisions.
>=20
Well, you could modify MD5 the same way RIPEMD128 was modified to give
RIPEMD256, but that would be recoding it.
==========
Daniel L=E9onard
OGMP Informatics Division E-Mail: [EMAIL PROTECTED]
D=E9partement de Biochimie Tel : (514) 343-6111 ext 5149
Universit=E9 de Montr=E9al Fax : (514) 343-2210
Montr=E9al, Quebec Office: Pavillon Principal G-312
Canada H3C 3J7 WWW :
------------------------------
From: [EMAIL PROTECTED] (Edward A. Falk)
Crossposted-To: alt.security.pgp
Subject: Re: PGP US Versions Broken,no good??
Date: 27 Jul 2000 20:47:30 GMT
In article <[EMAIL PROTECTED]>,
Florian Weimer <[EMAIL PROTECTED]> wrote:
>[EMAIL PROTECTED] (Edward A. Falk) writes:
>
>> Many of these are minor, but some send a chill down my spine. Please
>> tell me the official version of pgp doesn't ship with these warnings.
>
>The 6.5x Windows GUI has a problem with long user IDs (read: it
>crashes in some key selection dialogs). I don't know if this is
>exploitable, but it certainly doesn't make me more confident in NAI
>products.
>
>> This is all kind of beside the point though, since 5.0i is kind of
>> obsolete. Where is the best, most current version of pgp for Unix
>> nowadays?
>
>GnuPG (http://www.gnupg.org/).
Thanx for the pointer. Using it would mean losing compatibility
with PGP 2.6 though.
--
-ed falk, [EMAIL PROTECTED] See *********************#*************#*
http://www.rahul.net/falk/whatToDo.html #**************F******!******!*!!****
and read 12 Simple Things You Can Do ******!***************************#**
to Save the Internet **#******#*********!**WW*W**WW****
------------------------------
** 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
******************************
