Cryptography-Digest Digest #31, Volume #10 Wed, 11 Aug 99 20:13:03 EDT
Contents:
Re: Pls help me wade through the terminology (John Savard)
Re: Between Silk & Cyanide - two questions (Sundial Services)
Re: Depth of Two ([EMAIL PROTECTED])
Re: Crypto 99 shock - the chosen conference attack! (John Savard)
Re: NIST AES FInalists are.... ([EMAIL PROTECTED])
Re: NIST AES FInalists are.... ([EMAIL PROTECTED])
Re: Pls help me wade through the terminology (Sundial Services)
Re: brute force crackers unethical? (Keith A Monahan)
Re: Pls help me wade through the terminology (David A Molnar)
Re: Pls help me wade through the terminology ([EMAIL PROTECTED])
Re: Power analysis of AES candidates (DJohn37050)
Re: language confusion, would it work? ("JvA Networks (DK)")
Re: Cipher-Feedback Mode ([EMAIL PROTECTED])
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Pls help me wade through the terminology
Date: Wed, 11 Aug 1999 22:42:13 GMT
Cliff Bowman <[EMAIL PROTECTED]> wrote, in part:
>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.
This is what is called a "challenge-response protocol".
The pass code should depend on the seed number, and on a secret key in the ECU.
(If the ECU contains a serial number, it wouldn't hurt to use that also.)
One method of doing this would be to encrypt the seed number via DES with your
secret key, and then XOR the result with the seed number so that what you had
was a _keyed_ hash of the seed number.
You could use a simpler algorithm than DES, of course, for this kind of purpose,
because some attacks are not available.
John Savard ( teneerf<- )
http://www.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
Date: Wed, 11 Aug 1999 16:06:06 -0700
From: Sundial Services <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: Between Silk & Cyanide - two questions
Jim Gillogly wrote:
>
> Phoeper wrote:
> > 2. In the appendix on charting the 'fist' of WT operators, what do the graphs
> > indicate? The axes are not labelled and it is not clear (to me, anyway) what
> > they mean.
>
> I can't tell either, but I'll hazard a guess. The main elements of
> "fist" are the length of the elements (dots and dashes), the
> intra-character spacing of the elements, and the inter-character
> spaces. I'm guessing the charts show the first two.
>
> Perhaps Harry I's A is composed of a dit that's much shorter than
> average for this speed, an intra-character space that's a little
> longer than average, and a dash that's spot on the average. I'm
> guessing the bold dots on the graph are the relative length of the
> element, and the non-dot points are the relative length of the
> intra-character gaps.
>
> If this is correct, then Harry II sounds much different, with
> consistently relatively very short gaps between Morse elements.
>
It looks to me like they simply hooked the key to a chart-recorder, so
that the needle continues to rise while the key is held down and drops
when it is released. It's much easier to judge the slope of a slanted
line than the length of a dashed line.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Depth of Two
Date: Wed, 11 Aug 1999 23:10:44 GMT
In article <[EMAIL PROTECTED]>,
"Douglas A. Gwyn" <[EMAIL PROTECTED]> wrote:
<< There is a copy (actually two) in the US National Archives II. >>
I paid a visit to the NARA website, but their NAIL search engine
apparently doesn't have a complete list of the archives. Is "Friedman
Squares" the actual name of the paper?
<< It isn't very cost-effective, but it's a relaxing hobby. >>
I have several hobbies like that myself.
-- Jeff Hill
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Crypto 99 shock - the chosen conference attack!
Date: Wed, 11 Aug 1999 22:57:05 GMT
[EMAIL PROTECTED] (wtshaw) wrote, in part:
>In article <[EMAIL PROTECTED]>,
>[EMAIL PROTECTED] (John Savard) wrote:
>> Hence, this is not an attack on Crypto '99 (even if their conference also uses
>> the apostrophe...)
>Reuse of well traveled names in not something foreign to those in cryptoland.
Ah, yes...as I think of when I see a water purifier by National Safety
Associates, a Canadian company, or pass by the price tag for the No Sugar Added
canned fruit (NSA PEACHES)...
and let's not forget Cascading Style Sheets, shall we?
John Savard ( teneerf<- )
http://www.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: NIST AES FInalists are....
Date: Wed, 11 Aug 1999 23:17:28 GMT
In article <7orvmq$1em2$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (SCOTT19U.ZIP_GUY) wrote:
> Rest assured that if there was an entry that the NSA felt to strong
> for it to attack it would never be allowed to see the light of day in
the
> AES game. The AES is all about getting exposure for weak methods
> that the NSA can break. Do you think any of this stuff will be
approved
> for US government TOP SECRET messages. Hell no this code will be
> hyped for use by the average person. Why do you think the US is still
> trying to prevent the free sending of crypto source out of the US. The
> US government has a vested interest in getting people to foolishly use
> weak crypto.
If you feel so strongly about the 'weakness' of ALL AES algorithms, why
don't you do something positive and design your own algorithm.
Something that encrypts at under 25 cycles a byte (on a 586), takes
under 4KB of ram, and can schedule a key in under 10000 cycles (same
586). Cause if you don't meet those criterions then what's the point?
Oh BTW, the algorithm also has to work in hardware and smartcards (2kb
rom, 1kb ram max), posses no iterative attacks (known) and be
completely described and illustrated.
Just a thought.
Tom
--
PGP 6.0.2i Key
http://mypage.goplay.com/tomstdenis/key.pgp
PGP 2.6.2 Key
http://mypage.goplay.com/tomstdenis/key_rsa.pgp
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: NIST AES FInalists are....
Date: Wed, 11 Aug 1999 23:22:45 GMT
In article <7osee8$jpa$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> Those three words are an outstandingly poor attempt at
> justifying your position. Please, tell us: what is this
> criteria for an estimate of security to be "soundly based"
> such that all the public work fails it but the mere fact
> that it comes from the NSA means we can get it? Be
> careful to avoid drawing conclusions from reputation,
> since you specifically ridiculed that criteria in the
> case of public analysis.
You don't have to be a member of the NSA to write good crypto
algorithms. Look at DES, CAST, RC5 and Blowfish. I think a fair level
of 'trust' has to be put into the AES designers.
If the AES designers can find no attack at all (or feasible ones)
against the chosen AES cipher(s) then I would trust it. Really because
I don't think the NSA will have the time to read every message, because
strong crypto is not the only thing in strong systems, and because I
only want AES to protect me from others such as lowly hackers and
theives. If AES can protect my private email, my ATM transactions and
my OHIP records then I am all set and happy. If the NSA can read my
letters so be it (or the Canadian counterparts ...).
Tom
--
PGP 6.0.2i Key
http://mypage.goplay.com/tomstdenis/key.pgp
PGP 2.6.2 Key
http://mypage.goplay.com/tomstdenis/key_rsa.pgp
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
Date: Wed, 11 Aug 1999 16:21:13 -0700
From: Sundial Services <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: Pls help me wade through the terminology
John Savard wrote:
>
> Cliff Bowman <[EMAIL PROTECTED]> wrote, in part:
>
> >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.
>
> This is what is called a "challenge-response protocol".
>
> The pass code should depend on the seed number, and on a secret key in the ECU.
> (If the ECU contains a serial number, it wouldn't hurt to use that also.)
>
> One method of doing this would be to encrypt the seed number via DES with your
> secret key, and then XOR the result with the seed number so that what you had
> was a _keyed_ hash of the seed number.
>
> You could use a simpler algorithm than DES, of course, for this kind of purpose,
> because some attacks are not available.
Many attacks would not be available, I'd think... including tearing open
one of the units, deciphering the programming in the chip inside, and
finding out too much about the algorithm. This does not strike me as a
high-security problem.
It seems that almost any hash of the number, multiplying by this,
dividing by that, would serve this purpose well enough. As long as
technicians (if they actually wanted to take the time to do so) could
not perceive a pattern in the challenge and response, then there would
be a "1 in N chance" of getting it right, and the objective would be
fulfilled.
This strikes me as a situation where some noise would be useful, too.
Inject a purely pseudo-random component into the seed-number that the
device produces; yet enable the recipient to verify that the number,
less the noise, is plausible. This makes the number unpredictable....
non-deterministic.
Similarly, inject some noise into the correct-response. Now there are
literally thousands of "right answers," and the noise (which the
technician could not separate from the real data) will cover for an
otherwise simple and deterministic algorithm quite easily.
------------------------------
From: [EMAIL PROTECTED] (Keith A Monahan)
Subject: Re: brute force crackers unethical?
Date: 11 Aug 1999 23:34:55 GMT
Andrew,
Andrew Whalan ([EMAIL PROTECTED]) wrote:
: I just recently lost a tutoring job at a university, in a nutshell, for
: writing a brute force cracker for the Unix crypt function as a student and
: then demonstrating it whilst holding the position of a tutor (although not
: tutoring at that point in time) to a fellow data security student.
This doesn't surprise me at all. Many universities are filled with people
that don't understand the technology. Including the administrators that
run the networks. People don't like their weaknesses to be revealed, because
then, they have to spend time (read: effort) on fixing the problem. There
is such a hacker witch-hunt mentality out there.
Chances are, it came out like this. "Andrew is trying to hack our network,
think we should fire him?" (that comes from retarded sysadmin) Management
says, "You mean he's trying to break in and get access to stuff he's not
allowed? Yeah, Fire him."
: I can understand loosing the position over the alleged breach in conditions
: of use of computer systems on campus but one of the biggest arguments was
: that what I did was unethical and as such I should not be tutoring a subject
: on ethics.
Ethical, do they even know what is considered ethical in the computer field?
Do they have a computer ethics policy? And how is it worded?? Almost
all those policies define INTENT as part of the definition. I find it hard
as hell to believe they have found that you had INTENT to get unauthorized
access.
If you didn't login using someone else's password, and you didn't exceed
your authority using your account(ie gaining higher privs), then your
actions IMHO weren't unethical. Now, I'm assuming you didn't run your
password cracker for like two weeks and didn't get a hit. Keep in mind,
I'm not saying, only if you succeed has there been an ethics violation - even
failed attempts count there.
: Whilst my program never did reverse any passwords (not even my own) it did,
: given enough time, have to power to reverse the crypt() function. However,
: due to the machine it was running on it would have been lucky to attempt
: 4000 permutations a second ... hardly likely to find a match for even a 4
: character (case sens. alphanumeric) in reasonable time (6 months for 4
: characters).
: Anyhow, in a nutshell, I would just like to be reassured that I am not
: acting in an unethical fashion to write a brute force cracker, as IMHO at
: least, it is a valid (but annoyingly time consuming) method of
: cryptanalysis.
I don't see how writing a brute force cracker could possibly be construed
as unethical. I mean, in the eyes of an intelligent American who understands
the need for freedom. Would the department had fired you if you published
an article on why you feel abortion is right?
See everyone for years and years and years have been able to determine
what's right and what's wrong. That's because our actions have been
primarily physical, and of a relatively simply nature. Things like
murder, rape, adultery, robbery, etc are easy to say that is RIGHT, or that
is WRONG or that is unethical, etc. But especially with the internet becoming
popular, there becomes HUGE gray areas where more definition is required
to nail down what is right and what is wrong.
Let's take mail for instance.
If I send you an email, my mail client may (if setup to do so), contact your
mailserver directly, send the "HELO", "RCPT TO:", "MAIL FROM:" commands
to the server. Now, I could modify my mail program, or even telnet directly
to your mailserver, port 25, and type MAIL FROM:[EMAIL PROTECTED] and
now my actions are possibly illegal, or at least unethical.
The problem is we have nontechnical people making decisions on ethical problems
that they don't even understand. They don't understand the language - and
they don't understand how the online society differs from 'regular' society.
And it's these people who are writing our laws.
The people at EFF.org may be interested in hearing your story...
Keith
: Andrew
------------------------------
From: David A Molnar <[EMAIL PROTECTED]>
Subject: Re: Pls help me wade through the terminology
Date: 11 Aug 1999 22:53:34 GMT
Cliff Bowman <[EMAIL PROTECTED]> wrote:
> 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.
This sounds like an authentication / login problem. One way to do this is
the method found in S/KEY and OPIE -- both sides have a secret password
which is repeatedly hashed to get a "one-time-password" used for that
login. In your terminology, the "security algorithm" would consist of
hashing the password so many times at both the manufacturer's end and the
ECU's end, then giving the result to the technician as the "pass code."
Please note that this is subject to off-line guessing attacks. If an
adversary obtains one of the one-time passwords + how many times its been
hashed, it can guess passwords and compare them to the known one-time
password. Methods like Encrypted Key Exchange (EKE), SPEKE, and SRP resist
such attacks. I'm pretty sure EKE is in _Applied Cryptogaphy_, not sure
about the other two.
In general, I suggest you look at "zero-knowledge proofs of identity" and
"challenge-response protocols." Papers on both of them are at
www.IntegritySciences.com
> 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.
The "one-time password" solution has the advantage that it only requires a
strongly collision-resistant hash function. SHA-1 is conjectured to be
such a function; it's definitely in _Applied Cryptography_. It's certainly
integer-based, how fast it can be is up to you -- on paper I count about
760 bit operations per block, though. With some work, it can probably be
made small, especially if you are on a processor with 32-bit registers.
Again, note that this solution is vulnerable to guessing attacks. Please
consider how much of a problem that is for you (and look at the
alternatives) before implementing.
Thanks,
-David Molnar
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Pls help me wade through the terminology
Date: Wed, 11 Aug 1999 23:13:28 GMT
In article <[EMAIL PROTECTED]>,
Cliff Bowman <[EMAIL PROTECTED]> wrote:
> 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.
What you need then is a zero knowledge proof system. Where the
technician has to prove he knows a secret. Look up in Applied Crypto
for some good examples.
You could also perform another simple check
1. Host increments a counter and sends it 'I' to the user
2. User sends H(K || I) back
3. Host verifies ...
H is a hash algorithm, K is a secret key. If you are using SHA for
example you could make the key K 384 bits and I 64 bits and it would
fit in a SHA message block (it has to be 64 bits short of 512 bits).
It's true that you only need to capture 2^64 logins to 'easily' break
this system but that would take much too long.
If the hash algorithm is strong this method should work fine. As long
as I never repeats (although if the attacker has control over the host
it's seems any protocal can fall).
Tom
--
PGP 6.0.2i Key
http://mypage.goplay.com/tomstdenis/key.pgp
PGP 2.6.2 Key
http://mypage.goplay.com/tomstdenis/key_rsa.pgp
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED] (DJohn37050)
Subject: Re: Power analysis of AES candidates
Date: 10 Aug 1999 21:28:53 GMT
I suggest writing the author of the NIST paper and asking him specifically. Or
send an official comment to NIST asking the question.
Don Johnson
------------------------------
From: "JvA Networks (DK)" <[EMAIL PROTECTED]>
Subject: Re: language confusion, would it work?
Date: Thu, 12 Aug 1999 01:09:05 +0200
John Savard skrev i meddelelsen <[EMAIL PROTECTED]>...
>Since the resulting text would still have much of the redundancy of a
natural
>language, so a simple encryption method could still be attacked. The
computer's
>model of normal text would still find an alternation of consonants and
vowels,
>for example. Then your code would still have to be solved; if you replace
nouns
>with nouns, verbs with verbs, and so on, that also makes it easier.
Well, the point of nouns to nouns was to fool the computer: if the computer
was unaware that the text was encrypted further it should think that it was
done, when it had a good match for a plaintext even though this plaintext
wasn't the original. It would probably work better with Danish plaintext,
converted into grammatically correct English nonsense, since most decryption
programs would expect the English text to be the plaintext and not search
for a hidden Danish plaintext.
Of course you would be better off with a 168 bit algorithm and several very
long prime number keys, but I thought of building this dictionary feature
into a simple encryption program for private users. I should basicly handle
text-documents sent by e-mail, and have a security level just high enough
for most amateurs to be unable to break it within a matter of weeks. PGP
works of course, but I'd like to do it, just as an exercise :-)
- Jesper
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Cipher-Feedback Mode
Date: Wed, 11 Aug 1999 23:08:01 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (John Savard) wrote:
> CFB works this way:
>
> To encipher a block of plaintext,
>
> take the previous block of ciphertext, encipher it in your block
cipher, and XOR
> the result with that current block of plaintext.
That's CBC isn't it. I thought CFB works by
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.
So you get
1. C = P xor (IV >> (m - n))
2. IV = Ek((IV << n) or C)
3. Goto 1 as required
(m = block length, n = output length, both in bits).
Tom
--
PGP 6.0.2i Key
http://mypage.goplay.com/tomstdenis/key.pgp
PGP 2.6.2 Key
http://mypage.goplay.com/tomstdenis/key_rsa.pgp
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
** 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
******************************
