Cryptography-Digest Digest #38, Volume #10 Fri, 13 Aug 99 01:13:03 EDT
Contents:
Re: Why does MS-Visual C++ ABSOLUTELY REQUIRE . . . ("Rosimildo DaSilva")
IEEE Computer: Staying with the Herd (Terry Ritter)
Re: Future Cryptology ([EMAIL PROTECTED])
Re: Future Cryptology (SCOTT19U.ZIP_GUY)
Re: Future Cryptology ("Douglas A. Gwyn")
Re: Pls help me wade through the terminology (Jim Felling)
Re: NIST AES FInalists are.... ("Douglas A. Gwyn")
Re: NIST AES FInalists are.... ([EMAIL PROTECTED])
Re: About Algorithm M ("Douglas A. Gwyn")
Digital simulation (Christy Fulcher)
Re: NIST AES FInalists are.... ([EMAIL PROTECTED])
Digital simulation (Christy Fulcher)
Digital simulation (Christy Fulcher)
Digital simulation (Christy Fulcher)
Re: IDEA in AES (Hideo Shimizu)
Re: How to keep crypto DLLs Secure? ("John E. Kuslich")
Re: IEEE Computer: Staying with the Herd (David A Molnar)
Re: Future Cryptology (David A Molnar)
Re: About Algorithm M
Re: Depth of Two
Re: Cipher-Feedback Mode
----------------------------------------------------------------------------
From: "Rosimildo DaSilva" <[EMAIL PROTECTED]>
Crossposted-To: comp.lang.c++
Subject: Re: Why does MS-Visual C++ ABSOLUTELY REQUIRE . . .
Date: Thu, 12 Aug 1999 20:44:32 -0500
>
>I'm sorry but the DevStudio debugger is superior to windbg in so many
>ways. Ever try to look at the members of a class in windbg? Doesn't
>mean DevStudio debugger is perfect -- far from it. But it's the best
>debugger I've seen.
>
Ok, What else have you used ?
WinDbg and SoftICE are a lot more powerful.
You probably meant to say that VC++ debugger is more user-friendly,
not more powerful.
Rosimildo.
------------------------------
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: IEEE Computer: Staying with the Herd
Date: Fri, 13 Aug 1999 01:56:04 GMT
I have just had an article published in the current (August, 1999)
IEEE Computer magazine, titled "Cryptography: Is Staying with the
Herd Really Best?" The general theme goes like this:
The idea that older ciphers are more secure than newer ones is false.
We do not know the strength of any cipher until it is broken, and even
then know only a transient upper bound instead of the "real" strength.
We cannot measure strength, and it is a delusion to imagine that
passing many tests and examinations tells us *anything* about "real"
strength. We have no knowledge of cipher strength, and comparisons
between values we do not know are laughable.
Assuming our ciphers are secure is fantasy. We do not know whether or
not our ciphers keep our data secure. We *can* not know because the
interaction of interest occurs between the ciphertext and The
Opponent, in private. Cipher strength is thus contextual, with a
context for each possible Opponent. To simply *believe* in the
strength of our ciphers is to deliver ourselves into the hands of our
Opponents, just as happened to Germany and Japan in WWII. We can
choose to learn from history, or to repeat it.
The cipher situation is far worse than the apparently similar
situation that we have in software, which we cannot prove bug-free,
but is useful anyway. The difference is that we can in a general
sense measure what we want from software; bugs which interfere with
what we want are thus largely visible and can be worked around. But
failure of our ciphers is unlikely to be apparent. We simply cannot
expect to know whether or not our ciphers are keeping our secrets.
We have options beyond bemoaning our fate or ignorantly accepting
delusion as opposed to harsh reality. Options include multi-ciphering
as standard practice, using a wide variety of ciphers, choosing
ciphers dynamically, and having an expanding set of ciphers to choose
from. Contrary to the conventional wisdom, some of these alternatives
benefit from having many new ciphers instead of just using old ones.
A design alternative is to produce scalable designs which can be
better investigated than any of our conventional large ciphers.
Because of my current situation I am probably not going to be able to
participate in a discussion, but the article (actually, a guest
column) is published whether I am ready or not.
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Future Cryptology
Date: Thu, 12 Aug 1999 11:23:42 -0400
[EMAIL PROTECTED] wrote:
> IDEA is not really popular anymore. Most people have PGP 5 or greater
> and use other ciphers such as 3DES and CAST.
>
> Here is a good question, do you want a or b?
>
> a) NSA hackers to read your private medical/banking transactions
>
> OR
>
> b) Stop thieves and pesky hackers from stealing the information and
> making your life a living hell.
>
Sorry, this really isn't the place for another holy war, but the appropriate
term would be "crackers", not hackers.
> If you can answer the question (either A or B, and 'neither' is not a
> good answer) then you know what you are talking about.
>
> Believe it or not, the NSA is NOT out to get you. However there are
> millions of other criminals who ARE out to get you.
Well, this brings up an interesting point. They may not be out to get YOU,
but how do you know they don't deem certain people as a risk? I mean if you
think about it, if you have all that techonlogy and man power, why not
follow the potential trouble makers too? I'm a prime candidate for that.
Late teens, above average IQ (153), very skilled with a computer (been using
dos since 8, and UNIX since 10), a white hat hacker, programmer, and uses
encryption for EVERYTHING (including simple personal messages). They may
not be out to get you, but they might be out to get me. =)
> Really we have the ciphers we need to make strong systems, we just lack
> good implementations of secure systems. Most people use ad hoc designs
> and call them secure. That is where the trouble starts. Even with
> IDEA or CAST (or any other good cipher) strong systems can fall
> with 'slight' bugs.
>
> My point is, it's not enough to say 'can the NSA crack IDEA?', but more
> like 'can people break system X remotely, discretely and
> efficiently?'. If one person writes software to break a system, a
> million people could be using it in under a year ...
I must say, that is exactly right. If a cracker can effectivly bypass all
security methods and/or encryption, then we are in trouble. That is more
dangerous than the NSA could ever be....
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Future Cryptology
Date: Fri, 13 Aug 1999 03:28:24 GMT
In article <[EMAIL PROTECTED]>, "Douglas A. Gwyn" <[EMAIL PROTECTED]> wrote:
>[EMAIL PROTECTED] wrote:
>> Well, this brings up an interesting point. They may not be out to get YOU,
>> but how do you know they don't deem certain people as a risk? I mean if you
>> think about it, if you have all that techonlogy and man power, why not
>> follow the potential trouble makers too?
>
>Several reasons, including
> (1) It's against the law and their charter to spy on citizens
> within the US;
There actuall charter is classifed and from there history are you
really foolish enough to belive they would honor what you think
is the law of the land. The NSA is above the common law of the
land. Even the FBI routinely has violated the law. Look what it did
in recent foulups of DNA evidence and the Dr. King.
> (2) They don't have resources to waste on such low-return spying.
The total amount of there resources is classifed but it is known to be
in the several billions. So yes they have the time money and expertise
to waste on just about anything.
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
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Future Cryptology
Date: Fri, 13 Aug 1999 02:27:23 GMT
Lee Winter wrote:
> In short, I question your sincerity. You are full of shit.
You can question it all you want, but people who know me better
know you're off base.
------------------------------
From: Jim Felling <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: Pls help me wade through the terminology
Date: Thu, 12 Aug 1999 10:33:43 -0500
Cliff Bowman wrote:
> Two days of web searches, flipping through _Applied Cryptography_,
> and reading this newsgroup tells me that my question will be merely
> tedious to the readers of this group, but I need to make progress
> on this project so I'm going to ask...
>
> What kind of algorithm do I need if I'm required to generate a
> secure "passcode" given a known "seed number"? In my application,
> an authorized technician wishes to make a modification to the
> internal programming of an automobile ECU. The ECU performs an
> authentication proceedure wherein the technician is given a "seed
> number" (based on the internal clock) and must input a corresponding
> "pass code." The technician gets the pass code by calling the
> manufacturer with the seed number, and the manufacturer uses a
> security algorithm to generate the pass code. The ECU runs the
> same security algorithm and checks for a match, thus completing
> the authentication.
>
> My problem is that I can find a lot of really cool information on
> stream ciphers, eliptic curve algorithms, one-time pads, and so
> forth, but they really address a different kind of problem. What
> I need is something small (this is an embedded application), fast,
> and integer-based. Out of desperation, I've written a little C
> function that "seems to work," but I don't have any
> way to evaluate its performance systematically. Any and all
> help would be greatly appreciated.
>
> --Cliff
If you are looking for a simple method(fast, compact, not hugely secure,
but will stop the casual duffer)
how about this:
1) Generate a random number R in a short(few bytes -- easily searchable
range), append this to the serial number S. Hash this using a
reasonably fast and secure hash.(Depending on your need for
security/speed, anything from a CRC hash(fast, but not very resistant to
determined attack), to SHA or MD5(slower, but very secure)) this will
yield a value V. Then send as a seed code send S and V in. At the
company they brute force this hash to determine R. This should take a
comparatively short time(esp if they have this implemented on a faster
pc than the car chip, or in HW) then they send back R.The chip then
unlocks when R is input
To make this secure against tampering( I.e. brute force on the mechanic
end, do not allow the system to take more than say 3 wrong guesses
before generating a new R, and also taking say 1 minute before setting
the status to unlocked or reporting a failed attempt. This makes
guessing R a real pain, and prevents the keep resetting it until the
password matches the one we have on file by requiring on average (number
of possible R's)/2 minutes to arrange such a coincidence, and prevents
analysts from generating data in quantity without devoting a serious
amount of time to gathering the data to do so.
Advantages:
Short R is very easy to remember by mechanic say 5 characters long 32
possibilities per character(1-9, 23 letters) gives 2^25 possible R's
and can be easily written down a scrap of paper. This will mean 2^24
minutes to arrange a coincidence, and to get a reasonable amount of
plaintext for analisys will still take several days of determined
effort.
Disadvantages. S and V are very sensitive to operator error on input --
maybe include a checksum digit(s) to make this error obvious to the
operator on data entry. minute
Computation intensive on makers side, on average 2^24 hash ops will be
requited.( maybe 5 minutes worst case to generate per requested unlock
code with modern PC devoted to it full time).
Just a thought.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: NIST AES FInalists are....
Date: Fri, 13 Aug 1999 02:25:26 GMT
[EMAIL PROTECTED] wrote:
> ... I believe everybody's security and wellbeing would increase if
> NSA were allowed to make public their state of the art knowledge.
NSA does share some of its accomplishments, via technology transfer
programs, especially through the ISSO. But of course the main
constraint is that the eavesdropping mission would be hampered if
the people responsible for the security flaws being exploited had
those flaws pointed out to them. So long as NSA was responsible for
the protection of our own secrets as well as the exploitation of the
secrets of others, it could balance the contrasting requirements.
But when non-defense industry (perhaps with the aid of NIST) takes
over the protection function, there is an imbalance that is hard
to address.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: NIST AES FInalists are....
Date: Fri, 13 Aug 1999 02:25:48 GMT
Douglas A. Gwyn wrote:
> They're not an "attempt at justifying my position", they're
> a contradiction of what you said. I *do* have a basis, but
> security rules (OPSEC etc.) prohibit me from providing details.
How convenient for you that the rules allow you
to flaunt how much you know on Usenet and to
belittle the skill of respected cryptologists in
comparison to what you know about the NSA, but
don't allow you to back up what you claim with
any facts.
People who talk about knowing secret stuff don't.
--Bryan
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: About Algorithm M
Date: Fri, 13 Aug 1999 02:31:00 GMT
[EMAIL PROTECTED] wrote:
> 1) I know Algorithm M is simple to describe but ...
Maybe you should describe it, then. Are we supposed to know what
you mean by "Algorithm M"? It's not a standard term.
------------------------------
From: Christy Fulcher <[EMAIL PROTECTED]>
Subject: Digital simulation
Date: Fri, 13 Aug 1999 13:10:48 +1000
Im am looking for a way to simulate an encryption algorithm in
electronic workbench
(or similar), for a project in electronics. My knowledge so far consists
of simple
circuits like and, not, xor etc. Could anyone help me in suggesting an
algorithm that can
be implemented using these tools.
Any help would be much appreciated.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: NIST AES FInalists are....
Date: Fri, 13 Aug 1999 02:43:39 GMT
Douglas A. Gwyn wrote:
> [EMAIL PROTECTED] wrote:
> > ... Is the bar so high the best efforts of
> > superb cryptologists are insufficient, or so low that
> > a spy agency about which we know next to nothing
> > automatically clears it?
>
> (a) I assume by "superb cryptologists" you mean the people who
> contributed AES candidates, participated in AES conferences, etc.
> It is to be expected that they would highly "rate" cryptosystems
> similar to the ones they themselves design, regardless of whether
> or not the systems are really secure.
Then what you expect is false, since a number of the
candidates were excluded for security flaws. In the
case of Magenta, flaws discovered during its
presentation at the conference. A cipher will fail to
rate for even a hint of weakness, like the impractical
weak-key attack on Frog.
> What would be reassuring
> would be for *demonstrably superb cryptanalysts* to have attacked
> the AES candidates and have rated them according to their
> withstanding the attacks. But few if any of the evaluators
> appear to have ever successfully cryptanalyzed *any* difficult
> real-world cryptosystem, so what use are their ratings, anyhow?
Are the AES candidates real-world? What qualifies as
difficult? How many is few?
Many of the participants in the AES process are, without
question, superb cryptologists. You can look up their
papers for the demonstration.
> (b) I know for a fact that NSA cryptanalysts are capable of
> successfully cryptanalyzing many difficult real-world systems,
> so they *are* demonstrably superb cryptanalysts whose ratings
> would bear some relationship to reality.
And we'll just have to take your word for it, right?
Once more, please spare us.
--Bryan
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: Christy Fulcher <[EMAIL PROTECTED]>
Subject: Digital simulation
Date: Fri, 13 Aug 1999 13:09:31 +1000
Im am looking for a way to simulate an encryption algorithm in
electronic workbench
(or similar), for a project in electronics. My knowledge so far consists
of simple
circuits like and, not, xor etc. Could anyone help me in suggesting an
algorithm that can
be implemented using these tools.
Any help would be much appreciated.
------------------------------
From: Christy Fulcher <[EMAIL PROTECTED]>
Subject: Digital simulation
Date: Fri, 13 Aug 1999 13:06:09 +1000
Im am looking for a way to simulate an encrytption algorithm in
electronic workbench
(or similar), for a project in electronics. My knowledge so far consists
of simple
circuits like and, not, xor etc. Could anyone help me in suggesting an
algorithm that can
be implemented using these tools.
Any help would be much appreciated.
------------------------------
From: Christy Fulcher <[EMAIL PROTECTED]>
Subject: Digital simulation
Date: Fri, 13 Aug 1999 13:04:56 +1000
Im am looking for a way to simulate an encrytption algorithm in
electronic workbench
(or similar), for a project in electronics. My knowledge so far consists
of simple
circuits like and, not, xor etc. Could anyone help me in suggesting an
algorithm that can
be implemented using these tools.
Any help would be much appreciated.
------------------------------
From: Hideo Shimizu <[EMAIL PROTECTED]>
Subject: Re: IDEA in AES
Date: Fri, 13 Aug 1999 13:13:30 +0900
[EMAIL PROTECTED] wrote:
>
> In article <[EMAIL PROTECTED]>,
> Anssi Bragge <[EMAIL PROTECTED]> wrote:
> > I was just about to ask the same... :)
>
> http://www.funet.fi/~bande/docs/crypt/analysis/idea.ps.gz
>
> Reduced to 3 or 3.5 rounds. I think there is an attack against 4
> rounds already.
At FSE'99 Biham et.al. attack 4.5 rounds of reduced version of IDEA
using impossible defferential technique.
I don't know where can I get this paper on-line.
Hideo Shimizu
------------------------------
From: "John E. Kuslich" <[EMAIL PROTECTED]>
Subject: Re: How to keep crypto DLLs Secure?
Date: Thu, 12 Aug 1999 08:53:35 -0700
Nope!
This is easily defeated by altering the CRC value sought by the exe.
Software is not secure on the PC. Whatever can be written in software can be
unwritten in software.
Powerful tools exist today for devining the inner workings of ccode on the PC.
For some examples of how these tools are exploited, please visit
http://www.crak.com
JK
Martijn van der Kooij wrote:
> > The only sure way to have moderate crypto security is to have the crypto
> > directly inside the compiled EXE, and not within the DLL. I would
> > appreciate comments.
> >
>
> One way to be sure the dll is not replaced is to use a hash or crc on the
> dll. Store the CRC value in the exe and when loading the dll compare its crc
> with this value. You maybe need a few different values if there are
> different versions of the dll.
>
> Martijn van der Kooij
------------------------------
From: David A Molnar <[EMAIL PROTECTED]>
Subject: Re: IEEE Computer: Staying with the Herd
Date: 13 Aug 1999 03:59:38 GMT
Terry Ritter <[EMAIL PROTECTED]> wrote:
> I have just had an article published in the current (August, 1999)
> IEEE Computer magazine, titled "Cryptography: Is Staying with the
> Herd Really Best?" The general theme goes like this:
[snip concise summary]
Thanks for the heads up. I just joined the IEEE Computer Society; good to
know that such an article is coming. Will be interesting to see what the
response in the next issues is like.
Thanks,
-David Molnar
------------------------------
From: David A Molnar <[EMAIL PROTECTED]>
Subject: Re: Future Cryptology
Date: 13 Aug 1999 04:16:36 GMT
[EMAIL PROTECTED] wrote:
> follow the potential trouble makers too? I'm a prime candidate for that.
> Late teens, above average IQ (153), very skilled with a computer (been using
> dos since 8, and UNIX since 10), a white hat hacker, programmer, and uses
> encryption for EVERYTHING (including simple personal messages). They may
> not be out to get you, but they might be out to get me. =)
^^^^^^^^^^^^^^^^^^^^^^^^
With all due respect, the reports on Echelon suggest that "they" are out
to get all of us, with some minimal level of effort. I'd want to know more
about just what you're handing in your white hat hacking before
speculating fruitlessly on just how much more effort the NSA is expending
on you. :->
Seen any strange vans on your kerb lately ?
-David (started with a mac at 3, for what it happens to be worth)
------------------------------
From: [EMAIL PROTECTED] ()
Subject: Re: About Algorithm M
Date: 13 Aug 99 03:57:01 GMT
Douglas A. Gwyn ([EMAIL PROTECTED]) wrote:
: [EMAIL PROTECTED] wrote:
: > 1) I know Algorithm M is simple to describe but ...
: Maybe you should describe it, then. Are we supposed to know what
: you mean by "Algorithm M"? It's not a standard term.
I was going to make a similar comment: I often do when posters make this
particular error (as witness the "Cryptanalysis of R250" thread), but I
have this vague feeling I've seen the term "Algorithm M" somewhere before,
if not in AC then somewhere similar.
A few hints, even, about what Algorithm M is like, an example of a book or
other place where the term is used, would have been immesurably helpful.
John Savard
------------------------------
From: [EMAIL PROTECTED] ()
Subject: Re: Depth of Two
Date: 13 Aug 99 04:03:44 GMT
Jim Gillogly ([EMAIL PROTECTED]) wrote:
: I notice also that in this square the columns do contain the full
: alphabet. I suppose we should verify that this property sticks
: around if the duplicate diagonals are doctored.
No, it wouldn't.
A square like that is the table of what a single rotor in a rotor machine,
with the other rotors motionless, produces in the way of alphabets.
Provided the rows and columns are in the correct order. If a wire takes
the letter at position 5 to position 14, then when the rotor moves one
space, it will take the letter at position 6 to position 15. So if the
plain and cipher alphabets are correctly sequenced, the next letter in the
cipher alphabet occurs in the next position of the wheel as the substitute
for the next letter in the plain alphabet (which is why the alphabets are
on diagonals).
John Savard
------------------------------
From: [EMAIL PROTECTED] ()
Subject: Re: Cipher-Feedback Mode
Date: 13 Aug 99 03:58:58 GMT
[EMAIL PROTECTED] wrote:
: take the top n bits of the IV, xor it against the plaintext text, shift
: the IV n bits to the left, place the ciphertext bits in the lsbs, and
: encrypt the IV.
I should have noted, though, that you're right that CFB can be performed
with different numbers of bits per encipherment; I only mentioned the
simplest variant, 64-bit (or full-width, for block ciphers with different
block sizes than DES) CFB.
John Savard
------------------------------
** 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
******************************
