Cryptography-Digest Digest #868, Volume #12 Sat, 7 Oct 00 22:13:01 EDT
Contents:
Re: i should have finished high school (Scott Craver)
Re: Serial number scheme using DSA variant ("Lyalc")
Re: NSA quote on AES (John Savard)
Re: Rijndael (John Savard)
Re: Why wasn't MARS chosen as AES? (John Savard)
Re: NSA quote on AES (John Savard)
Re: It's Rijndael (John Savard)
Re: Pencil and paper cipher. (John Savard)
Re: Could NSA help vigilance? (John Savard)
Re: Looking Closely at Rijndael, the new AES (John Savard)
Re: NSA quote on AES (John Savard)
Re: It's Rijndael (John Savard)
Re: My Theory... (John Savard)
Re: NSA quote on AES (John Savard)
Re: Rijndael Coverage Improved on Web Site (John Savard)
Re: Why trust root CAs ? ("Lyalc")
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Scott Craver)
Crossposted-To: sci.astro,sci.physics.relativity,sci.math
Subject: Re: i should have finished high school
Date: 8 Oct 2000 01:12:28 GMT
Paul Lutus <[EMAIL PROTECTED]> wrote:
>
>The lighthouse effect is not an FTL effect. Not apparent, not real. Imagine
>the water coming out of a swinging hose. None of the water travels at
>greater than the basic stream velocity. It's the same with light.
Right. This guy is basically suggesting that random-access
of data happens at "faster than light" speeds if serial access
of that same data requires faster-than-light travel.
For instance, a terabyte stored on one roll of paper tape
(quick, somebody start planting trees) would probably require
FTL travel to shuttle to a random byte in less than 1 second.
-S
>
>--
>
>Paul Lutus
>www.arachnoid.com
>
>
>
>
------------------------------
From: "Lyalc" <[EMAIL PROTECTED]>
Subject: Re: Serial number scheme using DSA variant
Date: Sun, 8 Oct 2000 12:28:56 +1000
Why don't you use the simple process used in ATMs and EFTPOS globally today?
In essence, encrypt the data with a DES key in CBC, and keep only 32 bits
from the last 8 bytes of result. Including the serial number on the
encrypted data will help ensure uniqueness of the result to the serial
number and the data.
Change the key every message if you want, but for the criteria you've
outlined, a single key may be sufficient.
With RSA, DSA or DES (or anything else using crypto), there are identical
key storage security issues.
Lyal
[EMAIL PROTECTED] wrote in message <8ro2fb$o4b$[EMAIL PROTECTED]>...
>Hi!
>
>First of all thanks for your help regarding short signatures.
>
>After a while I came up with a scheme which could be the solution for
>my problem.
>
>I will sum up the requirements first so you can see for yourself if the
>scheme meets those criteria.
>
>This scheme will be used for secure serial numbers secure meaning that
>no one else is able to forge serial numbers i.e. serial numbers can
>only be given out by someone knowing the private key.
>
>Requirements:
> - serial numbers must be short (40 base32 characters at the most)
> - serial numbers can be verified in reasonable time in the software
> - no one should be able to generate serial numbers but me
> (Security equal to cracking DES is secure enough)
> - Only 16384 unique serial number required
>
>Scheme:
>
>I want to employ a DSA variant using only 128 bits for q instead of
>160. The part of the signature for all possible messages (16384) which
>is not dependant on the message is deployed with the software (the r
>part in DSA). Therefore the application needs to store 16384*128 bits =
>256 kbytes. The serial number will be delivered as
>
>unique serial number|signature (s part)
>
>thus taking up exactly 142 bits = 29 base-32 characters.
>On runtime this serial number
>
>Do you think this is secure? Any objections to this design?
>
>As I understand it I do not need to hash the unique serial number
>(otherwise I could use MD5 for example). Is this correct?
>
>Thanks for your help...
>
>kryps
>
>
>Sent via Deja.com http://www.deja.com/
>Before you buy.
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: NSA quote on AES
Date: Sat, 07 Oct 2000 17:16:33 GMT
On Sat, 7 Oct 2000 11:17:39 +0100, "Brian Gladman"
<[EMAIL PROTECTED]> wrote, in part:
>"David Schwartz" <[EMAIL PROTECTED]> wrote in message
>news:[EMAIL PROTECTED]...
>> When a statement appears to be carefully crafted, I assume it means
>> exactly and only what it says. I disregard all implications. I think
>> this is the correct way to read NSA statements.
>In principle I agree with this approach and I believe that it leads to a
>sensible conclusion in this case. Unfortunately, however, very few
>statements of any length in english are devoid of the need for
>interpretation of some kind so the approach does not always produce the
>right answer (if there ever is such a thing).
Since it is seldom the practice of people to craft their statements
carefully, when someone does do so, it is naturally regarded as
suspicious.
However, in the case of this particular statement, I think we can
safely conclude that there is only *one* sinister agenda behind it:
it is aimed at dispelling any suspicion that the NSA would stoop to
things like bureaucratic infighting and protecting its turf, simply
because NIST has dared to get into the cipher business.
John Savard
http://home.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Rijndael
Date: Sat, 07 Oct 2000 10:42:00 GMT
On Sat, 07 Oct 2000 03:45:07 GMT, [EMAIL PROTECTED] wrote, in part:
>Hi. I'm pretty new to learning about the Rijndael algorithm. I have
>looked over TwoFish and RC6 and haven't had many problems. I have a
>question that I was hoping someone could help me with. On page 5 of the
>"Rijndael Block Cipher" guide, it talk about division or the polynomial
>modulo m(x). How do I divide polynomials?
Think of "x" as the base of the number system, like 10 is for ordinary
numbers. The only difference is that there are no carries...but the
digits are independently modulo 2 in this case. (Thus, XOR is both
addition and subtraction.)
So, if 101101 represents 1 x^5 + 0 x^4 + 1 x^3 + 1 x^2 + 0 x + 1, or
simply x^5 + x^3 + x^2 + 1, then you divide it by x + 1 (or 11) like
this:
11 11
__________
11 ) 101101 |
11 |
-------|
11101 |
11 |
-------|
101 |
110 |
-------}
11 |
11 |
-------|
1
so in this case, 101101 is 11011 times 11, with no remainder.
John Savard
http://home.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Why wasn't MARS chosen as AES?
Date: Sat, 07 Oct 2000 10:31:27 GMT
On 07 Oct 2000 03:41:54 GMT, [EMAIL PROTECTED] (UBCHI2) wrote, in
part:
>Why wasn't MARS chosen as AES?
Rijndael was smaller and faster.
John Savard
http://home.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: NSA quote on AES
Date: Sat, 07 Oct 2000 18:36:36 GMT
On Sat, 7 Oct 2000 09:27:41 +0100, "Brian Gladman"
<[EMAIL PROTECTED]> wrote, in part:
>And perhaps you would like to confirm that you would believe such a
>statement if they made it.
Touche!
However, while I missed out on the fun last time...
I just never *could* hear the Satanic messages that were supposed to
be in the DES S-boxes if you played them backwards...
(Tip: for a convenient way to hear what a record sounds like
backwards, tape it on a two-track reel-to-reel tape recorder, and play
the tape back on a four-track reel-to-reel tape recorder)
but I see by the Rijndael paper that indeed if you ask for a 224-bit
key, it is *specified* that 13 rounds will be performed.
The number of 32-bit words in a 224-bit key is 7, which is relatively
prime to 4, the number of 32-bit words in a 128-bit block. This may
help the key schedule a bit, which has been noted as somewhat
problematic, for example in that recent paper from Counterpane.
In Rijndael with 13 rounds, actually only 12 full rounds (including
the Mix Column step) are performed, allowing each bytes in the even
rows to influence each byte in the odd rows an equal number of times,
and vice versa. (Originally, I attached a bit too much importance to
this symmetry, since the Shift Rows step is more like permutation P
from DES in function than swapping halves, so this point is not as
vital as I thought it was, but I still think it likely to improve
matters for some differential attacks.)
Thus, a 224-bit key is a sort of "sweet spot" for the security of
Rijndael, at least from a _naive_ point of view.
Thus, a conspiracy theorist (who might also note that one advantage of
selecting an algorithm from a non-US person is that the NSA *can* tap
his phone, and so on) now has a ready-made theory of a "backdoor" in
Rijndael: it is flawed with all the standard key sizes, but even the
NSA *can* still use it...they'll just secretly use the 224-bit key
size which makes it work properly.
John Savard
http://home.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: It's Rijndael
Date: Sat, 07 Oct 2000 10:44:32 GMT
On Sat, 07 Oct 2000 00:01:36 +0000, Jim Gillogly <[EMAIL PROTECTED]> wrote,
in part:
>Interesting use of "product", but OK. If you're building your own
>Secure-IRC client and want it to interoperate with somebody else's
>Secure-IRC server,
All he is saying is that, for example, an SET client won't
interoperate with an SSL server, even if both use Rijndael as their
symmetric cipher.
Surely that is both true, and does not involve any nostandard uses of
words.
John Savard
http://home.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Pencil and paper cipher.
Date: Sat, 07 Oct 2000 10:34:34 GMT
On Sat, 07 Oct 2000 01:59:23 GMT, Benjamin Goldberg
<[EMAIL PROTECTED]> wrote, in part:
>3) Move the first digit to the end of the message.
>4) Convert digit pairs back to letters. See a and b in step 2.
That basic principle was mentioned in David Kahn's "The Codebreakers"
as a common amateur system. If the only key is the code for converting
letters to digits and back again, one attack is to treat the message
as a homophonic cipher in which letter pairs represent letters, as
noted in "Decrypted Secrets" by Bauer.
John Savard
http://home.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Could NSA help vigilance?
Date: Sat, 07 Oct 2000 19:29:52 GMT
On 07 Oct 2000 11:23:26 -0700, Andru Luvisi <[EMAIL PROTECTED]>
wrote, in part:
>If we *knew* that the NSA could not break something, how many people
>would forget about all the agencies of foreign governments, all the
>researchers in private corporations and universities, and figure that
>it *must* be secure?
Although I feel that there are very good reasons to consider that the
NSA *is* Number One as far as the ability to break any cipher is
concerned (their resources compared to any private group, or any other
governmental agency, and the unsurpassed techonlogical lead of the
U.S.), this still raises interesting questions.
I think there *is* one other threat to ciphers that goes beyond the
NSA today.
The NSA - and everybody else - tomorrow. That is what we could forget
about if we trusted a cipher because we were sure that even the NSA
could not break it today.
Both new discoveries in mathematics, and the ever-increasing power of
computers, mean that the cipher that is secure today might be as
obsolete tomorrow as an 8088-based or 80286-based PC is today.
John Savard
http://home.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Looking Closely at Rijndael, the new AES
Date: Sat, 07 Oct 2000 22:20:01 GMT
On Tue, 03 Oct 2000 13:10:07 GMT, [EMAIL PROTECTED]
(John Savard) wrote, in part:
>As it happens, because of attacks faster than brute force, increasing
>the number of Rijndael rounds as the length of the key increases was
>needed. But also in general, it makes more sense to leave the number
>of rounds fixed with changes to the key size - but it is _vitally
>necessary_ to increase the number of rounds if the block size
>increases.
Although I had forgotten it at the time I posted this, and saw my
mistake from the Rijndael spec, at least my *web* page was correct all
along: the number of rounds in Rijndael varies based on the greater of
the key size and the block size.
John Savard
http://home.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: NSA quote on AES
Date: Sat, 07 Oct 2000 18:24:50 GMT
On 7 Oct 2000 01:35:01 GMT, [EMAIL PROTECTED] (Bill Unruh) wrote,
in part:
>Well, I also see it as a statement like the famous reference
>"You will be fortunate indeed to get this person to work for you."
Oh, dear. That's a really *old* joke.
John Savard
http://home.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: It's Rijndael
Date: Sat, 07 Oct 2000 14:55:50 GMT
On Wed, 04 Oct 2000 18:19:51 +0000, Jim Gillogly <[EMAIL PROTECTED]> wrote,
in part:
>In short, I think picking a specific number makes good sense,
>even though I'm not sure what that number should be.
I know: let's use 128-bit blocks (or 192-bit blocks, I'm happy either
way, but if we're deciding on one standard, that won't be it) and 224
bit keys.
That way, instead of 10, 12, or 14 rounds, we can finally use 13
rounds. This way, the number of "real" rounds will be 12, which is
evenly divisible by 4 (or 6).
While I was wrong about this being a *fatal* weakness in Rijndael, it
is still a possible source of problems, so why not choose a standard
that avoids it?
A nice touch is that the number of 32-bit words in 224 bits is 7,
which is relatively prime to 4, also improving the key schedule.
John Savard
http://home.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: My Theory...
Date: Sat, 07 Oct 2000 22:22:45 GMT
On Sat, 7 Oct 2000 14:10:04 -0700, "Scott Fluhrer"
<[EMAIL PROTECTED]> wrote, in part:
>Well, (for the record) the work was done by John Worley, Bill Worley, Tom
>Christian and Christopher Worley of Hewlett Packard Labs, which I rather
>suspect Intel has heard of. They did state that:
> "Lacking IA-64 hardware, we employeed three different types of
>simulators... final timings used fully simulated RTL designs of the Merced
>(now Itanium) and McKinley chips. This approach was extremely slow, and our
>results often varied from day to day, as engineers improved their designs."
>(Quote from AES Finalists on PA-RISC and IA-64: Implementation &
>Performance, presented at AES3 by the above authors).
>Apparently, the Itanium design was not finalized when they were actually
>doing the analysis...
And, of course, Hewlett-Packard is Intel's partner in designing the
Itanium, so if they couldn't get an IA-64 chip, even the NSA might
have had a problem getting one back then.
John Savard
http://home.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: NSA quote on AES
Date: Sat, 07 Oct 2000 18:23:11 GMT
On 06 Oct 2000 20:30:12 -0700, Eric Smith
<[EMAIL PROTECTED]> wrote, in part:
>[EMAIL PROTECTED] (Mack) writes:
>> After the Skipjack fiasco the NSA is being much more careful.
>What Skipjack fiasco is that?
Perhaps he means the Clipper Chip controversy. (No, AFAIK, SKIPJACK
hasn't been cracked.)
John Savard
http://home.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Rijndael Coverage Improved on Web Site
Date: Sun, 08 Oct 2000 00:35:06 GMT
On Fri, 06 Oct 2000 03:28:57 GMT, [EMAIL PROTECTED]
(John Savard) wrote, in part:
>On Thu, 05 Oct 2000 11:27:59 GMT, [EMAIL PROTECTED]
>(John Savard) wrote, in part:
>>As befits Rijndael's status as the new AES, I've extended the
>>description of it on my web page.
>Now, I've even added a diagram - a three-dimensional view (isometric)
>in color - of a round of Rijndael to that page.
In addition to making minor modifications to the diagram, I've added
the values of the round constants in the key schedule, and the inverse
Mix Column matrix - I verified it by hand, which was a good thing, as
the values I saw were in reverse order. Also, I have a table showing
the "ideal" key sizes for the various block sizes, for those who share
my slight concerns about the appropriate symmetries for a cipher like
Rijndael.
John Savard
http://home.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: "Lyalc" <[EMAIL PROTECTED]>
Subject: Re: Why trust root CAs ?
Date: Sun, 8 Oct 2000 12:45:33 +1000
I've just got to comment on this.
1. In the smartcard scenario described below, a symmetric key does the
exact same job (card+PIN = proof of identity)
2. The bank does have a liability to the customer when it enrols the
customer and issues the card for an acocunt. The terms and conditions
contratually oblige the bank to act on the account holders instructions (or
an authorised proxy - usually demmed someone who knows the PIN and has the
full card details). No one else's. An Acquirer bank (ie anyone who
acquires a payment message for clearing and settlement, which may be a bank)
has little liability, except to the issuer largely, who expects the acquirer
to transport the transaction and authentication information securely and
with integrity.
Confidence with electronic payments today comes from trusting your bank, the
merchant's bank, and the merchant. Adding a CA to this process means
everyone has to trust more elements - the Issuer's CA, the Merchant CA, the
Acquirers CA, and any CAs these entities trust.
None (exactly none) of these can be trusted without extensive technology and
oeprations overheds which are not releated to certificates and public key.
Smartcards, tamper resistant readers (with keypads), tamper resistant
servers, manual ID registration processes, security audits, legal contracts
for every use of the certificate/digital signature - the list goes on quite
a way yet.
In most of the world, ATM-like security processes are pretty reliable, to
the tune of tens of billions of operations annually. Failures, though very
rare, have affected individual trust relationships, not every participant or
potential participant. I suspect this sort of reasoning contributed to
Schneier's comments
If you already trust each other, do you need to prove it from scratch (with
the entire CA process from registration to digital signature) or just
provide a relaible short form reference to that trust relationship?
Of course, with credit card rules, banks pretty much have to imdemnify
losses, because they've given up their trust relationship to the card
schemes and the tech payment processing companies.
Lyal
Daniel James wrote in message ...
>In article <[EMAIL PROTECTED]>, Bruce Stephens wrote:
>> > Bruce Schneier's new book, "Secrets and Lies", has an interesting
section
>> > on certificates and such where, if I understand him correctly, he
concludes
>> > that the real security in B2C web transactions comes from the credit
card
>> > company and it's limits on personal liability and not the CA.
>> >
>> > If had the book I'd give the page,
>>
>> pp.238-239.
>>
>> "Digital certificates provide no actual security for electronic
>> commerce; it's a complete sham."
>
>Yes, Bruce likes saying that - he comes across as very sceptical of any
benefits
>claimed for PKIs and certificates.
>
>As things stand today he's right - certificates are used as a guarantee of
a
>party's identity, and not a very good guarantee at that. It doesn't have to
be
>this way.
>
>Imagine, if your bank gave you a smartcard as a credit card, and that card
>contained a private key you could use to sign messages, a certificate for
that
>key signed by the bank, and the bank's CA certificate. The bank could then
say
>that they wouldn't accept any payment made by you unless it was signed with
your
>key, and that any correctly signed payment *must* have come from you so
your
>card account would be debited even if you denied making the payment. The
only
>way that could be done is if someone obtained your card and your PIN (or
broke
>the digital signature algorithm used by the card). This would provide good
>security for the bank, because they would be able to say with a high degree
of
>justification that any correctly signed payment must have come from you or
from
>someone else acting on your behalf (with your card AND your PIN) - but it
>doesn't provide any protection for the customers that they're not getting
at the
>moment from the banks' and credit card companies' policy of refunding
payments
>that are made fraudulently.
>
>The point here is that the banks aren't under any obligation to provide
that
>protection. They do so because they make money on every transaction, and so
it's
>financially to their advantage to keep the transaction count high, and so
they
>encourage their customers to use their cards online by offering to
indemnify
>them against fraud (and by insuring against part of the cost of doing so).
It
>wouldn't take much of an increase in the level of fraud, or of the cost of
>insuring against it, to change this.
>
>A bank could also offer a service whereby it would issue identity
certificates
>to online traders signed with its own CA key (whose certificate is on your
smart
>credit card). You still don't know with absolute certainty what the
identity of
>that trader is, but you do know with a high degree of certainty who your
bank
>thinks that trader is. This - from the point of view of someone trying to
make
>an online purchse from that trader using funds from that bank is all that
really
>matters.
>
>Digital certificates and PKIs provide a means whereby trust, once
established,
>can be shared and can be communicated between parties who trust on another.
None
>of this plays much part in eCommerce security today because the banks see
it as
>in their interest to indemnify their customers against loss, so their
customers
>don't actually have to care too much about trust. This state of affairs
should
>not be expected to last.
>
>Cheers,
> Daniel.
>
>
------------------------------
** 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
******************************
