Cryptography-Digest Digest #962, Volume #12 Thu, 19 Oct 00 21:13:01 EDT
Contents:
Re: old factoring tricks (Tom St Denis)
Re: Enigma: Stolen German Code Machine Turns Up in BBC Mailroom (David Schwartz)
Re: Encrypting large blocks with Rijndael (John Myre)
Re: Encrypting large blocks with Rijndael (David Crick)
Re: Encrypting large blocks with Rijndael (Tom St Denis)
Re: old factoring tricks (Tom St Denis)
Re: BIOS password, will it protect PC with PGPDisk against tampering ? ("Jonathan")
Re: srp-1.6.0 released (Thomas Wu)
Re: Encrypting large blocks with Rijndael (John Myre)
Re: Encrypting large blocks with Rijndael (John Myre)
10/21/2000 4 pm Computer History Lecture: Anthony Sale on Computer Conservation &
the Rebuild of Colossus (Eugene Miya)
Re: old factoring tricks ("bubba")
Re: Encrypting large blocks with Rijndael (Tom St Denis)
Re: What is desCDMF? (Tom St Denis)
Re: ---- As I study Rinjdael... (Eric Lee Green)
Re: What is desCDMF? ([EMAIL PROTECTED])
Re: ---- As I study Rinjdael... (Sundial Services)
----------------------------------------------------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: old factoring tricks
Date: Thu, 19 Oct 2000 21:57:11 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> Pollard rho works on the cycles of N. If N=PQ then cycles mod P and
mod
> Q are important. Roughly these are about Sqrt(P) or Sqrt(Q)
respectively
> (with some constants), or approximately N**(1/4).
>
> For 79 bits, you should need about 2^20 cycles.
>
> Are you sure you meant 79 bits and not 79 digits?
Eerr.. ya 79 bits... on my Celeron 400 it took 251 seconds to factor...
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: David Schwartz <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto
Subject: Re: Enigma: Stolen German Code Machine Turns Up in BBC Mailroom
Date: Thu, 19 Oct 2000 15:05:47 -0700
David Schwartz wrote:
> Try to brute force the machine. Remember, for each of the 26^4 possible
> keys, you have (26!)^4 possible rotor hookups. Break, yes. Brute force,
> no. As far as I know, the rotor wirings were never made public.
It has come to my attention that the rotor wirings of this machine have
in fact been made public in their entirety. So stealing the machine
would yield no information that would assist you in breaking any
messages encoded with it. With or without the machine, you could easily
brute force any key in under 2^19 operations.
DS
------------------------------
From: John Myre <[EMAIL PROTECTED]>
Subject: Re: Encrypting large blocks with Rijndael
Date: Thu, 19 Oct 2000 16:12:00 -0600
John Myre wrote:
>
> Rijndael is defined (almost*) to work on blocks of any
<snip>
I meant to note that the ShiftRow constants would have
to be defined for larger sizes.
JM
------------------------------
From: David Crick <[EMAIL PROTECTED]>
Subject: Re: Encrypting large blocks with Rijndael
Date: Thu, 19 Oct 2000 23:27:17 +0100
John Myre wrote:
>
> (Each round does work proportional to the block size,
> which cancels out the advantage gained by encrypting
> fewer blocks.)
[..]
> Under what circumstances would one be willing to pay
> this speed penalty?
Security.
If I remember correctly, the increase in number of rounds
in proportion to the key or block size is due to the fact
that with larger key/blocks the diffusion is slower.
Hence the increase in rounds - to increase the diffusion,
or at least, to maintain the same amount of diffusion at
larger sizes.
--
+-------------------------------------------------------------------+
| David A. Crick <[EMAIL PROTECTED]> PGP: (OCT-2000 KEY) 0xE0F73D98 |
| Damon Hill Tribute Site: http://www.geocities.com/MotorCity/4236/ |
| M. Brundle Quotes: http://members.tripod.com/~vidcad/martin_b.htm |
+-------------------------------------------------------------------+
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: Encrypting large blocks with Rijndael
Date: Thu, 19 Oct 2000 22:17:35 GMT
In article <[EMAIL PROTECTED]>,
John Myre <[EMAIL PROTECTED]> wrote:
>
> Rijndael is defined (almost*) to work on blocks of any
> size that is a multiple of 32 bits. However, the rule
> for the number of rounds based on the block size means
> that encrypting a single large block is much slower than
> encrypting it piecewise with one of the standard modes.
>
> (Each round does work proportional to the block size,
> which cancels out the advantage gained by encrypting
> fewer blocks.)
>
> For example, encrypting 256 bits at a time instead of
> 128 would require 14 rounds instead of 10, and so it
> would be 40% slower.
It's not that easy. In the 14 rounds of 256-bit block Rijndael you are
handling more information... thus it's not 40% slower...
> Similarly, (if I did my arithmetic right) encrypting a
> 512 byte block in a single call would be 13.4 times slower
> than encrypting it with 32 calls to 128-bit Rijndael.
>
> Under what circumstances would one be willing to pay
> this speed penalty? Is it at all reasonable to extend
> the rule the about number of rounds this far?
Um I dunno, but remember that only the AES version of rijndael has
received the most attention.
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: old factoring tricks
Date: Thu, 19 Oct 2000 22:24:30 GMT
In article <hJJH5.9241$[EMAIL PROTECTED]>,
"Michael Scott" <[EMAIL PROTECTED]> wrote:
> Try ftp://ftp.compapp.dcu.ie/pub/crypto/factor.exe
How can I force this program to only try a few ECM curves? I wanted to
try a 256-bit RSA composite and it tried 400 or so ECM curves...
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: "Jonathan" <[EMAIL PROTECTED]>
Subject: Re: BIOS password, will it protect PC with PGPDisk against tampering ?
Date: Fri, 20 Oct 2000 08:37:57 +1000
How about strong encrypt the whole system drive with something like safeboot
www.controlbreak.nl or safeguard http://www.utimaco.com . With these
utilities you can't get acces to the drive period. (even if you try ntfsdos
or bios tricks.)
"nemo outis" <[EMAIL PROTECTED]> wrote in message
news:EdGH5.24720$[EMAIL PROTECTED]...
> I might point out that there may be a *lot* of work to do to get the
initial
> "known-good" state.
>
> It's best is if you install everything onto a newly formatted drive using
> trusted sources (e.g., original-issue manufacturers' CDs, although it is
> possible that even these have back-doors available to three-letter-acronym
> (TLA) opponents).
>
> It is much more difficult if you "inherit" a machine with software already
> preloaded. It may be possible to verify file hashes for popular software
> with signatures derived from a machine in a different environment (e.g., a
> friend's at a different company). Checking for software keyloggers, etc.
> requires some power-user or even hacking skills. In general your
verification
> will be partial and your security thus very limited.
>
> And you must do a full case-and-keyboard-open hardware check.
>
> Regards,
>
>
>
> In article , [EMAIL PROTECTED] (nemo outis) wrote:
> >If you cannot keep a computer (or at least its hard disk) physically
secure at
> >all times (perhaps in a work environment) then here are some suggestions:
> >
> ..snip...
>
> >Regards,
> >
------------------------------
From: Thomas Wu <[EMAIL PROTECTED]>
Subject: Re: srp-1.6.0 released
Date: 19 Oct 2000 15:36:35 -0700
Philip MacKenzie <[EMAIL PROTECTED]> writes:
>
> 1. ssh is only vulnerable the first time you connect to a server
> from a particular machine. After that, the server's public
> key is stored on the user's machine.
I've always wondered how safe this really is. After all, if we
honestly believed in it, why bother with certs? Just have the
browser store "www.amazon.com"'s public key for the next session.
I think if we really examine why this model was rejected by
e-commerce, we'll see why it makes people uncomfortable in ssh.
> 2. When ssh receives a new public key from a server, it
> informs the user that it has received an untrusted public key,
> and so the user has some warning about a possible vulnerability.
But since keys are supposed to change (in fact, required to by some
servers), the user will get this warning sufficiently often from legit
servers that ignoring this message will be necessary to get anything
done. At least with SSL/TLS you can look at the cert...
> In SRP 1.5.2, there is no warning, at least not an explicit one.
>
> In fairness, SRP 1.5.2 does have the advantage that the spoofing
> server still has to run an offline dictionary attack on the password
> info, whereas in ssh, the spoofing server obtains the password
> directly.
An upgrade to 1.6.0 is definitely recommended. I believe the new
parameter checking is clean enough that it imposes no penalty for
existing users in return for the security improvement.
--
Tom Wu * finger -l [EMAIL PROTECTED] for PGP key *
E-mail: [EMAIL PROTECTED] "Those who would give up their freedoms in
Phone: (650) 723-1565 exchange for security deserve neither."
http://www-cs-students.stanford.edu/~tjw/ http://srp.stanford.edu/srp/
------------------------------
From: John Myre <[EMAIL PROTECTED]>
Subject: Re: Encrypting large blocks with Rijndael
Date: Thu, 19 Oct 2000 16:59:48 -0600
David Crick wrote:
>
> John Myre wrote:
<snip>
> > Under what circumstances would one be willing to pay
> > this speed penalty?
>
> Security.
<snip>
Do you mean to say that encrypting with larger blocks
is more secure? (If not, why not go with smaller blocks?)
JM
------------------------------
From: John Myre <[EMAIL PROTECTED]>
Subject: Re: Encrypting large blocks with Rijndael
Date: Thu, 19 Oct 2000 16:56:33 -0600
Tom St Denis wrote:
<snip>
> It's not that easy. In the 14 rounds of 256-bit block Rijndael you are
> handling more information... thus it's not 40% slower...
<snip>
Tell you what, why don't you implement it, and tell
us what you find? Is it clear we want the speed per
unit data encrypted? (Per byte, say.)
JM
------------------------------
Crossposted-To: ba.seminars,alt.folklore.computers
Subject: 10/21/2000 4 pm Computer History Lecture: Anthony Sale on Computer
Conservation & the Rebuild of Colossus
From: [EMAIL PROTECTED] (Eugene Miya)
Date: 19 Oct 2000 17:02:04 -0800
[--enm: sorry for the delay, we are reorging news at work,
while it might be too late for foreign nationals in the SF Bay Area,
there might be a few locals who still might want to attend.
This is a very special seminar.]
==========
NOTICE: PLEASE SEE SPECIAL INVITATION AT BOTTOM OF THIS E-MAIL
==========
The Computer Museum History Center
Fall 2000 History Lecture Series
Anthony E. Sale
Honorary Fellow of the British Computer Society and
Former Director of the Colossus Rebuild Project, Bletchley Park
will speak on
UK Computer Conservation & the Rebuild of Colossus,
the WW II Code-Breaking Computer
Saturday, October 21, 4:00 p.m.
at the NASA Ames Main Auditorium, Building N-201,
Moffett Federal Airfield, Mountain View, CA
Advance reservations are required in order to be admitted to Moffett
Federal Airfield.
RSVP by Thursday, October 19, 2000 to Wendy Ann Francis, +1 650-604-5205 or
[EMAIL PROTECTED]
[A tiny bit of lee-way... to Oct. 20, noon.]
Event URL: http://www.computerhistory.org/events/lectures/sale_10212000
Abstract of Talk:
Tony Sale will discuss his work in rebuilding the wartime Colossus
codebreaking computer and the development of the Museums at Bletchley Park
to present to the public its outstanding codebreaking technologies. He
will also address the importance of computer conservation and restoration
activities in the United Kingdom.
Background on the Speaker:
Tony Sale was the first Museums Director in Bletchley Park, from 1993 to
1999. He set up the Museums to commemorate the World War II codebreaking
work which significantly helped the Allied war effort. His varied careers
include electronics, intelligence with MI5, running a software company for
12 years and working at the Science Museum in London for four years
restoring early computers. All this experience came together in the
rebuilding of the wartime Colossus codebreaking computer.
Tony Sale is an Honorary Fellow of the British Computer Society and was the
Society's Technical Director from 1986 to 1989. Named Comdex IT personality
of the year in 1997, Sale has lectured widely in the UK, Europe and the USA
and appeared in TV in documentaries and the "Station X" series. He gave
the London Royal Institution Lecture in 1997 and was the keynote speaker at
Eurocrypt 2000, Cambridge Crypto Workshop, Oxford Crypto Seminar.
==========
SPECIAL INVITATION:
The Computer Museum History Center offers you the opportunity to
participate in a special "Members-Only" event and pre-reception with our
1620 restoration team, just before the lecture by Tony Sale.
If you are not already a member, this is a great time to consider becoming
a supporter of the Museum. Help preserve the history of computing. Help
safeguard the artifacts and stories of the information age. Help sustain
the lecture program you have enjoyed over the years.
In addition, all members receive our quarterly publication, CORE, as well
as invitations to other special events and access to our extensive library
and other research resources.
It's easy! Just call me at +1 650 604 2575, or send an email to
[EMAIL PROTECTED] before Thursday, October 19th.
We look forward to welcoming you.
Eleanor Weber Dickman
Vice President of Development and Public Relations
------------------------------
From: "bubba" <[EMAIL PROTECTED]>
Subject: Re: old factoring tricks
Date: Fri, 20 Oct 2000 00:06:44 GMT
Tom,
I was able to build factor.exe from source a while back without
too much difficulty. You could do that and tweak it easily.
"Tom St Denis" <[EMAIL PROTECTED]> wrote in message
news:8snsan$poo$[EMAIL PROTECTED]...
> In article <hJJH5.9241$[EMAIL PROTECTED]>,
> "Michael Scott" <[EMAIL PROTECTED]> wrote:
> > Try ftp://ftp.compapp.dcu.ie/pub/crypto/factor.exe
>
> How can I force this program to only try a few ECM curves? I wanted to
> try a 256-bit RSA composite and it tried 400 or so ECM curves...
>
> Tom
>
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: Encrypting large blocks with Rijndael
Date: Fri, 20 Oct 2000 00:00:50 GMT
In article <[EMAIL PROTECTED]>,
John Myre <[EMAIL PROTECTED]> wrote:
> Tom St Denis wrote:
> <snip>
> > It's not that easy. In the 14 rounds of 256-bit block Rijndael you
are
> > handling more information... thus it's not 40% slower...
> <snip>
>
> Tell you what, why don't you implement it, and tell
> us what you find? Is it clear we want the speed per
> unit data encrypted? (Per byte, say.)
See the problem is three fold.
1. I don't care.
2. I have other things on my mind (work, school, my paper for CHES)
3. I bet Brian Gladman (right name?) could do an implementation much
better then I could...
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: What is desCDMF?
Date: Fri, 20 Oct 2000 00:02:28 GMT
In article <_cKH5.64775$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> Tom St Denis <[EMAIL PROTECTED]> wrote:
> >> > Why the heck would you use a 40-bit key? That's like asking "can
> > you >> > steal my messages". Why not just not use a key at all?
> >>
> >> I can think of three reasons without particularly trying:
> >>
>
> And, let's not forget the obvious one. You're the worlds largest
> provider of computing solutions and want to export systems
> overseas. To do that, you need a way to reduce the DES key to 40 bits.
>
> CDMF shortening allowed IBM to leverage all of the work they did in
> their CCA for use in the exportable version, simply by "dialing in" a
> smaller keysize.
While being technically accurate this has no bearings on the world
*today*.
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Eric Lee Green <[EMAIL PROTECTED]>
Subject: Re: ---- As I study Rinjdael...
Date: Thu, 19 Oct 2000 17:20:52 -0700
[EMAIL PROTECTED] wrote:
> That narrows the choice to a) use Rijndael, and provide advesaries
> with complete documentation of the algorithm, and test vectors. Or b)
> use an equally strong system and make advesaries guess the algorithm.
Or c), say nothing, and make adversaries guess as to what algorithm they're
using. Could you tell, just by looking at a file, whether it was encrypted via
Rijndael, 3DES, IDEA, or NSA256?
--
Eric Lee Green [EMAIL PROTECTED]
Software Engineer "The BRU Guys"
Enhanced Software Technologies, Inc. http://www.estinc.com/
(602) 470-1115 voice (602) 470-1116 fax
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: What is desCDMF?
Date: Fri, 20 Oct 2000 00:28:33 GMT
Tom St Denis <[EMAIL PROTECTED]> wrote:
>> And, let's not forget the obvious one. You're the worlds largest
>> provider of computing solutions and want to export systems
>> overseas. To do that, you need a way to reduce the DES key to 40 bits.
>>
>> CDMF shortening allowed IBM to leverage all of the work they did in
>> their CCA for use in the exportable version, simply by "dialing in" a
>> smaller keysize.
> While being technically accurate this has no bearings on the world
> *today*.
Right, but the question I meant to address was:
Why the heck would you use a 40-bit key? That's like asking
"can you steal my messages." Why not just not use a key at
all.
That's rather like looking back at the 17th century and asking, Why
the heck would you ride a horse, cars are much faster? You may as well
walk.
--
Matt Gauthier <[EMAIL PROTECTED]>
------------------------------
Date: Thu, 19 Oct 2000 17:40:43 -0700
From: Sundial Services <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: ---- As I study Rinjdael...
The assumption that is traditionally made in cryptography is that your
opponent has already broken into your office and stolen a replica of
your machine. He knows everything about what you are doing -- except
for your private key.
This assumption "may or may not be correct in real life," but it is the
assumption that assumes that the opponent is in the most advantaged
position that he could possibly be -without- knowledge of the key. With
this assumption, "the crypto algorithm stands alone."
You see, "secrecy is a false security," because secrecy can be broken
-and- you will never know (ahh, "it's a secret .. from you!") that your
secret has been broken! Any crypto analysis must therefore choose to
assume that there is no secrecy: that the crypto algorithm, if it be
secure at all, must be secure entirely on its own.
>Eric Lee Green wrote:
>
> [EMAIL PROTECTED] wrote:
> > That narrows the choice to a) use Rijndael, and provide advesaries
> > with complete documentation of the algorithm, and test vectors. Or b)
> > use an equally strong system and make advesaries guess the algorithm.
>
> Or c), say nothing, and make adversaries guess as to what algorithm they're
> using. Could you tell, just by looking at a file, whether it was encrypted via
> Rijndael, 3DES, IDEA, or NSA256?
------------------------------
** 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
******************************
