Cryptography-Digest Digest #403, Volume #10 Tue, 12 Oct 99 22:13:02 EDT
Contents:
Re: Kryptos info (Derek Bell)
Re: Are small block sizes less secure? (Paul Koning)
Re: where to put the trust (Tom St Denis)
Re: where to put the trust (Tom St Denis)
old crypto (Syed Ali)
Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
(DJohn37050)
Re: Layperson Q: how long to crack 32-bit RSA? (jerome)
Re: Layperson Q: how long to crack 32-bit RSA? ("Matthew Sullivan")
Re: Should RC4 be free? (Paul Koning)
Re: where to put the trust (Tom St Denis)
Re: where to put the trust (Tom St Denis)
Re: Cryptix Blowfish (Tom St Denis)
Re: old crypto (John Savard)
Re: How vulnerable is... (Rebus777)
Re: Should RC4 be free? (Bill Unruh)
----------------------------------------------------------------------------
From: Derek Bell <[EMAIL PROTECTED]>
Subject: Re: Kryptos info
Date: 12 Oct 1999 20:26:26 +0100
Bill <[EMAIL PROTECTED]> wrote:
: Hi. Looking for info on the Kryptos sculpture. Specifically how the
: known passages were translated, and the full text of those
: translations. Can anyone out there help?
There's some information here:
http://www.und.nodak.edu/org/crypto/crypto/general.crypt.info/Kryptos/
Derek
--
Derek Bell [EMAIL PROTECTED] | Socrates would have loved
WWW: http://www.maths.tcd.ie/~dbell/index.html| usenet.
PGP: http://www.maths.tcd.ie/~dbell/key.asc | - [EMAIL PROTECTED]
------------------------------
From: Paul Koning <[EMAIL PROTECTED]>
Subject: Re: Are small block sizes less secure?
Date: Tue, 12 Oct 1999 15:35:40 -0400
wtshaw wrote:
>
> In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
> (Bruce Schneier) wrote:
>
> ...
> >
> > On the other hand, it is harder to create a secure algorithm for a
> > larger block than it is for a smaller block. At a very abstract
> > level, most of the modern statistical attacks against ciphers exploit
> > relationships between plaintext bitx, ciphertext bits, key bits, and
> > bits internal to the cipher. As the block gets larger, there are
> > exponentially more possible bit combinations to exploit, and hence
> > exponentially more bit combinations to ensure are secure against
> > attack. For a fixed performance requirement, it is easier to make a
> > secure 128-bit cipher than a secure 256-bit cipher.
> >
> > Block sizes should be as small as possible, but no smaller.
> >
> > Bruce
> >
> Rules should not be based on such lack of understanding, and being dead
> wrong as a rule. Many ciphers are scalable; saying that minimum sizes are
> best is for convenience of testing the virtues of the algorithms. There
> are too many examples of strength scaling with size to consider your
> statement seriously, but maybe some will buy it, unfortunate for them.
>
> While it is true that number systems have surprises, those characteristic
> to one may have no relationship in another as there are resonances, peaks,
> valleys, and other weirdnesses dictated by individual information units
> personalities, bits being only one....
I'm trying to figure out whether you're agreeing with
Bruce, or disagreeing, or just writing words. It's not
clear.
If disagreeing, could you explain why? Bruce gave a
(rather terse) argument why strength doesn't scale up
with block size; if you feel that it does, why?
paul
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: where to put the trust
Date: Tue, 12 Oct 1999 20:06:26 GMT
In article <[EMAIL PROTECTED]>,
"Trevor Jackson, III" <[EMAIL PROTECTED]> wrote:
> One of the most important differences is that you usually tell when a
> doctor or engineer fails. You may not be able to tell when a cipher
> designer fails because the people who profit by the failure profit by
> keeping it secret.
Hidenburg disaster. Nuff said.
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: where to put the trust
Date: Tue, 12 Oct 1999 20:11:07 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Terry Ritter) wrote:
> And I think you are fooling yourself.
>
> Cryptography is different from the areas in which we trust expertise
> because in cryptography there is no way for anyone to know whether any
> particular approach is successful.
>
> Would you really trust a doctor who could not know whether the
> patients, having been treated, were alive or dead? Would you trust a
> computer if you knew there was no way to check the results? Would you
> drive on bridges if you did not know that bridges generally stay up?
>
> Bridges generally stay up precisely because engineers can unarguably
> distinguish between a bridge which falls and one that does not.
> Without this, there is no way to measure prediction, and no way to
> develop the knowledge to make predictions correspond to reality.
>
> There are many predictions in cryptography, but no similarly apparent
> result. There simply is no way to know when cryptography keeps things
> secret from opponents who are themselves secret. There is thus no way
> to judge risk, and similarly no way to judge expertise. In a very
> essential way, there can be no real experts on cryptographic strength.
So what you are saying is that no mistakes have ever been made in any other
field known to man? Who is fooling who?
Just because cryptography is a relatively new field (as is space travel)
there are experts in the field. Most of whom have been in it since the
beginning of the modern era.
> And that is the same sort of argument that led Germany and Japan to
> assume their codes were secure in WWII. They were both wrong.
And that the titanic would not sink...
It's an all or nothing. With your arguement no experts exist in any fields
at all because people tend to be wrong once in a while. Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Syed Ali <[EMAIL PROTECTED]>
Subject: old crypto
Date: Tue, 12 Oct 1999 22:12:26 +0100
Hi,
I'm looking for a description of the Enigma Machine from a
electronic/electro-mechanical point of view.
Any help would be most appreciated.
------------------------------
From: [EMAIL PROTECTED] (DJohn37050)
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: 12 Oct 1999 21:16:41 GMT
All right!!!!!
And if you want to see my thoughts on future resiliency from an asymmetric
algorithm viewpoint, see my presentation and paper made at PKS '99 at
www.certicom.com
Don Johnson
------------------------------
From: [EMAIL PROTECTED] (jerome)
Subject: Re: Layperson Q: how long to crack 32-bit RSA?
Reply-To: [EMAIL PROTECTED]
Date: Tue, 12 Oct 1999 21:13:12 GMT
On Tue, 12 Oct 1999 18:27:02 GMT, Roy Pardee wrote:
>
>Interestingly, this info is supposed to apply to versions from access
>1.0 up through access 95--I couldn't find any update on it applicable
>to access 97.
>
>So... does this change your assessments any?
yes, but it is still far from secure. Now the attacker needs more than a
pocket calculator, it need a real computer during a few days :)
It is enougth if it is to protect your diary against your 10years old
sister but not against a 14 years old geek who know the basics of
cryptography.
up to you to identify your potential attacker.
------------------------------
From: "Matthew Sullivan" <[EMAIL PROTECTED]>
Subject: Re: Layperson Q: how long to crack 32-bit RSA?
Date: Tue, 12 Oct 1999 16:51:52 -0500
A 550 Mhz PIII can do an equivilent piece of RC5- 64bit keyspace in under an
hour, 32bit RC4 should take less time.
Roy Pardee <[EMAIL PROTECTED]> wrote in message
news:7tvuh2$5ni$[EMAIL PROTECTED]...
> Many thanks for all the helpful responses.
>
> It turns out Joe is right--I mischaracterized the encryption scheme.
> Here is what microsoft has to say about the encryption:
>
> Microsoft Access uses an RC4 encryption algorithm with a 32-
> bit key from RSA Data Security Incorporated. If you are
> creating an international application, this algorithm is
> acceptable for export outside of the United States (according
> United States export laws) because the key is less than 40-
> bits.
>
> When you encrypt a database, all objects (tables, forms,
> queries, indexes, and so on) are affected because encryption
> is implemented at the page- level and not at the data-level.
> Microsoft Access encrypts a database in 2K (kilobyte) pages,
> regardless of the data stored in a page. Each encrypted page
> is assigned a unique 32-bit key.
>
>
> (That's from KB article:
> http://support.microsoft.com/support/kb/articles/Q140/4/06.ASP)
>
> Interestingly, this info is supposed to apply to versions from access
> 1.0 up through access 95--I couldn't find any update on it applicable
> to access 97.
>
> So... does this change your assessments any?
>
> Thanks again!
>
> -Roy
>
> In article <[EMAIL PROTECTED]>,
> [EMAIL PROTECTED] (JPeschel) wrote:
> > Roy Pardee <[EMAIL PROTECTED]> writes:
> >
> > >I've got a database app that I'd like to use for a multi-site medical
> > >study. My app relies on microsoft Access 97 replication, which sends
> > >32-bit RSA encrypted 'message files' via anonymous ftp.
> >
> > Don't you mean one of RSA's RC-n ciphers?
> > A 32-bit RSA number can be easily factored, a 32-bit RC-n
> > encrypted message brute-forced.
> >
> > Joe
> >
> > __________________________________________
> >
> > Joe Peschel
> > D.O.E. SysWorks
> > http://members.aol.com/jpeschel/index.htm
> > __________________________________________
> >
> >
>
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.
------------------------------
From: Paul Koning <[EMAIL PROTECTED]>
Subject: Re: Should RC4 be free?
Date: Tue, 12 Oct 1999 17:47:07 -0400
Gabriel Belingueres wrote:
>
> Hi,
>
> I was wondering how much time will pass until RSA Data Security give up
> with the RC4 (TM). If somebody writes an algorithm that given an input I
> spit out an output O, and I and O are the same that a patented
> algorithm, then that algorithm couldn't be called RC4...well almost.
> The IETF's Internet-Draft that describes such an algorithm called it
> "ArcFour" or something alike.
I haven't heard any claims that RC-4 is patented, just
that the name is a trademark. And perhaps at one time
the algorithm was a trade secret, but that's clearly
no longer the case.
> Of course, I don't deny that the method to "discover" the RC4-compatible
> algorithm are totally illegal.
Maybe it was, maybe it wasn't. That depends on how it was done.
Do you know for sure that it was done an illegal way?
> When that ArcFour draft became a RFC, then how much time will pass
> until big companies stop using RC4 to favor ArcFour?
I don't think anyone has ever claimed that the two
are different. What's described in the RFC is, as far
as I can tell, RC-4. The strange name is to avoid a
trademark issue, but that doesn't affect the algorithm
itself.
> I think that the best move RSA could do is to standardize RC4, in the
> same way that did it with RC2.
Where was that? MD-5 was made public, don't remember RC-2.
> Or at least acknowledge that "Arcfour" == RC4, because this will improve
> their image and integrity as a company committed to develop good
> security products (witch it is already).
Yes, that would be good...
paul
--
!-----------------------------------------------------------------------
! Paul Koning, NI1D, D-20853
! Xedia Corporation, 50 Nagog Park, Acton, MA 01720, USA
! phone: +1 978 263 0060 ext 115, fax: +1 978 263 8386
! email: [EMAIL PROTECTED]
! Pgp: 27 81 A9 73 A6 0B B3 BE 18 A3 BF DD 1A 59 51 75
!-----------------------------------------------------------------------
! "The only purpose for which power can be rightfully exercised over
! any member of a civilized community, against his will, is to prevent
! harm to others. His own good, either physical or moral, is not
! a sufficient warrant." -- John Stuart Mill, "On Liberty" 1859
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: where to put the trust
Date: Tue, 12 Oct 1999 22:34:13 GMT
In article <WcLM3.145$[EMAIL PROTECTED]>,
"Adam Durana" <[EMAIL PROTECTED]> wrote:
> No matter how refined a design is there is always possiblities for mistakes.
> And in this field a tiny mistake can reduce a cipher's strength to nothing.
> And this tiny mistake can go unnoticed for a very long time, say until its
> been worked into numerous amounts of hardware and software. You think then
> if the creator found the mistake, he or she would come running to the public
> telling them that all the money and time they spent on integrating this
> cipher into thier products was wasted because of a mistake the creator made?
>
> > It's only thru trial and error that most experts learn anything, including
> > medicine.
>
> With medicine if you make an error you pay for it big time, and its in your
> best interest to correct things as soon as you realize you have made an
> error. In cryptography if you make an error and you happen to realize it,
> its probally in your best interest to keep it a secret and let someone else
> discover it, if they ever do. Thats if you are directly profiting from it.
So you are saying doctors have never made a mistake? So keep putting that
butter on your burns, um what else... I dunno I wasn't alive 30 years ago...
someone help out here.... Basically anyone could tell you that many things
have changed in the past few decades.... This includes medicin,
transportation, etc...
> Okay, this is even worse than before. Not only are you going to blindly
> have faith in these people's work, you are letting the media decide who you
> consider an expert?
Well I know those people thru their works as well. I only mentioned them
because they are well known gurus. There are plenty others. I would for
example be a novice 'cryptographer'. I know enough to be dangerous (ala
peekboo) but not enough to really break any real systems or to invent new
ones.
> I don't see anything being said that will change your view. You seem to be
> saying I'll take what the experts give me and assume its good and I'll keep
> using it until an expert tells me its not safe any more.
>
> I'm not saying you need to do a full study of every cipher before you use
> it. For example AES, if the government was not so involved with the
> selection process, I would accept the cipher as most likely secure by
> today's standards. Since the candidates will be reviewed by many people. I
> would review the method to see how it worked, but I would not spend weeks
> studying it. I would also look at papers on the cipher before I passed my
> final judgement on the cipher.
So you are basically a hypocrite. You will accept AES because someone
reviews it. But you don't think there are experts in the field. So who do
you want examining AES? 12 year old kids?
BTW so do you work in an office, see a doctor, drive on bridges ???
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: where to put the trust
Date: Tue, 12 Oct 1999 22:37:13 GMT
In article <fqMM3.203$[EMAIL PROTECTED]>,
"Adam Durana" <[EMAIL PROTECTED]> wrote:
> All you really have to do is think about it. If a doctor makes a mistake
> and never realizes or admits the mistake the consequences will be far worse
> than if the doctor realizes the mistake admits it and works to correct it.
>
> As for 'snake oil' in medicine we currently have the FDA and other agencies
> to prevent such products or treatments from getting sold. But guess what?
> Theres no such thing for cryptography.
You really believe that? Oh go take your fat trapper, echinchea, diet magic
pills, reverse negative ion rings and etc......
There is a lot of hyped up magicall drugs out there. You apparently are
oblivious to them. The bottled water I buy from time to time has been
processed thru 'reverse osmosis'.... now think about that for a while.
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: Cryptix Blowfish
Date: Tue, 12 Oct 1999 22:41:17 GMT
Encrypting the sboxes/pboxes occurs in the key schedule. You can check out
http://www.cell2000.net/security/peekboo/cdll.zip
which contains source for twofish, blowfish, sha and I think RC6 as well
(it's a win32 dll with source). At any rate you can check the source for
what you need.
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: old crypto
Date: Tue, 12 Oct 1999 23:21:31 GMT
Syed Ali <[EMAIL PROTECTED]> wrote, in part:
>I'm looking for a description of the Enigma Machine from a
>electronic/electro-mechanical point of view.
My site describes it from a logical point of view, but it has links to
other sites, such as Frode Weierud's, which may be of assistance.
John Savard ( teneerf<- )
http://www.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: [EMAIL PROTECTED] (Rebus777)
Subject: Re: How vulnerable is...
Date: 12 Oct 1999 23:30:29 GMT
>Rebus777 wrote:
>>
>> How vulnerable is the "average encrypted binary"?,
>>
>> with all the different software implementations of DES
>> that are all somewhat different, because of slight
>> programing changes to the algo, different kinds of feedback,
>> chaining and header setups. Some don't even have headers or
>> the headers are encrypted and therefore leave no tell.
>
>sundialservices.com replied:
>
>Well, is this encrypted-binary something that, when I try to run it, it
>actually runs? Or is it a file of data which you have encrypted by some
>absolutely one-of-a-kind secret means?
>
What I was thinking of was a file encrypted with one of the 70 or so programs
that I have collected from various places on the internet. These programs are
not really secret but many of them give away very little or nothing about
themselves when they encrypt a file. Of course some of them have the program
name and version at the begining of the header. Tiny Idea leaves no trace of
itself in an encrypted file.
-RSC
------------------------------
From: [EMAIL PROTECTED] (Bill Unruh)
Subject: Re: Should RC4 be free?
Date: 13 Oct 1999 00:15:32 GMT
In <7tvnns$9p$[EMAIL PROTECTED]> Gabriel Belingueres <[EMAIL PROTECTED]> writes:
]I was wondering how much time will pass until RSA Data Security give up
]with the RC4 (TM). If somebody writes an algorithm that given an input I
]spit out an output O, and I and O are the same that a patented
]algorithm, then that algorithm couldn't be called RC4...well almost.
]The IETF's Internet-Draft that describes such an algorithm called it
]"ArcFour" or something alike.
Why should they give up? They are selling their reputation.
]Of course, I don't deny that the method to "discover" the RC4-compatible
]algorithm are totally illegal. But what is illegal is the WAY of
Sorry, why was it illegal? There is nothing illegal about reverse
engineering something which is out in the public. If the person who
posted it signed a non-disclosure agreement, then you might have an
argument.
]doing the discovering, not the TECHNOLOGY discovered per se... But now
]the damage is done already...
When a trade secret is no longer secret, it is also not a trade secret.
...
]When that ArcFour draft became a RFC, then how much time will pass
]until big companies stop using RC4 to favor ArcFour?
Depends. Some companies like to have themselves supplied by someone they
trust. Afterall Redhat has absolutely no proprietary claim on what they
sell, yet they continue to sell.
]Companies have to convince their customers that they use "secure,
]proven,
]standard and interoperable software". Customers with a minimal
]investment in security will recognize the support of an IETF standard,
]not a proprietary algorithm.
]I think that the best move RSA could do is to standardize RC4, in the
]same way that did it with RC2.
]Or at least acknowledge that "Arcfour" == RC4, because this will improve
]their image and integrity as a company committed to develop good
]security products (witch it is already).
I see no advantage to them to doing so.
------------------------------
** 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
******************************
