Cryptography-Digest Digest #872, Volume #12 Sun, 8 Oct 00 11:13:00 EDT
Contents:
Re: It's Rijndael (Mack)
Re: Why trust root CAs ? (Anne & Lynn Wheeler)
SDMI challenge (Mack)
Re: Storing an Integer on a stream (Andras Erdei)
Re: SDMI challenge (Mack)
Re: It's Rijndael (John Savard)
Re: Apologies for a faulty memory (John Savard)
Re: Why trust root CAs ? (Daniel James)
Re: Why trust root CAs ? (Daniel James)
Re: Why trust root CAs ? (Daniel James)
Re: Why trust root CAs ? (Timothy M. Metzinger)
Re: It's Rijndael (John Savard)
Re: SDMI challenge (Mack)
WEP (Ichinin)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Mack)
Subject: Re: It's Rijndael
Date: 08 Oct 2000 13:16:00 GMT
>Not a flame
>Does someone know if the Rijndael key to encript
> ****RIJNDAEL**** to *AES*WINNER*AES*
>does exist? Thought it wouls be a nice test vector.
> -will-
>
If rijndael is secure then it is impossible
to find that key. However, the plsintext
with *AES*WINNER*AES* as the key
and ****Rjindael**** as the ciphertext
is trivial to find ;)
Mack
Remove njunk123 from name to reply by e-mail
------------------------------
Subject: Re: Why trust root CAs ?
Reply-To: Anne & Lynn Wheeler <[EMAIL PROTECTED]>
From: Anne & Lynn Wheeler <[EMAIL PROTECTED]>
Date: Sun, 08 Oct 2000 13:19:47 GMT
[EMAIL PROTECTED] writes:
> OK, so you're off to do some e-shopping. You click on the padlock and
> it says "this certificate belongs to bogus.com" and
> "this certificate was issued by snakeoil CA" (no I don't mean
> the CA generated by OpenSSL, I mean one of the "normal" ones
> like verisign or thawte...).
as an aside ... the content validation done by a client of a server
SSL certificate is to compare the server's domain name with the domain
name in the server SSL certificate. One of the supposed claims for
this feature is weaknesses in the domain name infrastructure.
When a server registers for a domain name SSL certificate ... the CA
has to authenticate the domain name request with the domain name
infrastructure (as the authoritative source for domain names) as to
the owner of the domain name (i.e. does the requester of the
certificate actually have rights to the domain name being specified).
In other words, the CA infrastructure is dependent on the same domain
name infrastructure that is supposedly the thing that the whole
process is attempting to fix.
Now one of the methods to improve the integrity of the domain name
system (so that CA's can rely on them ... and minimize things like
domain name hijacking ... where I could hijack a domain name and then
obtain a certificate for that domain name) is to register public key
along with the domain name.
However, if public keys are registered (along with the domain name),
the existing domain name infrastructure could return the public key in
addition to other information.
This creates something of a catch-22 for ca infrastructure ... fixing
the domain name integrity (with public keys) so that CAs can rely on
domain name integrity as the authoritative source for domain names
... also creates the avenue making the domain name certificates
redudant and superfulous.
random refs:
http://www.garlic.com/~lynn/aepay5.htm#rfc2931
http://www.garlic.com/~lynn/aepay5.htm#rfc2915
http://www.garlic.com/~lynn/aepay4.htm
http://www.garlic.com/~lynn/aadsmore.htm#client1
http://www.garlic.com/~lynn/aadsmore.htm#client2
http://www.garlic.com/~lynn/aadsmore.htm#client3
http://www.garlic.com/~lynn/aadsmore.htm#client4
--
Anne & Lynn Wheeler | [EMAIL PROTECTED]
http://www.garlic.com/~lynn/
------------------------------
From: [EMAIL PROTECTED] (Mack)
Date: 08 Oct 2000 13:33:08 GMT
Subject: SDMI challenge
With the samples provided in hand I was
able to determin that the files used for sample
1a and 2a and 1b and 2b are the same music.
While samples 3a and 3b are different. It is
interesting to note that the 1 and 2 versions
have a high static component. This static
component appears to have been inserted
to thwart analysis
Mack
Remove njunk123 from name to reply by e-mail
------------------------------
From: Andras Erdei <[EMAIL PROTECTED]>
Crossposted-To: comp.compression
Subject: Re: Storing an Integer on a stream
Date: Sun, 08 Oct 2000 13:40:17 GMT
Benjamin Goldberg <[EMAIL PROTECTED]> wrote:
>If I'm writing a file, whose format is a 64 bit file length, followed by
>some amount of data, followed by some [random] padding, which of the
>following is the best way to store that length value:
Elias wrote some texts on encoding arbitrary integers,
and analyzed them, e.g. in
INTERVAL AND RECENCY RANK SOURCE CODING:
TWO ON-LINE ADAPTIVE VARIABLE-LENGTH SCHEMES
ELIAS, P. (IEEE TRANS ON INF, VOL IT-33, NO 1, JAN 1987)
(I don't have the article here, but even if it isn't what you are
looking for, it surely has the right pointers.)
The method i like most is fibonacci coding:
- start with the largest fib number smaller than your integer
- if the current fib number is smaller than your number
substitute it and write down 1
else
write down 0
- take the next fib number
Example:
number: 15
fib: 1,1,2,3,5,8,13
encoding: 13+2 -> 0010001
This way you encoded your (arbitrarily big number) in a way that
there are *no consecutive 1s* in the encoding, and it ends with 1;
so you can append an additional 1 and thus make it a prefix code.
result: 00100011
IIRC this encoding is asimptotically optimal.
>1) 8 base-256 digits. With this format, we always use 8 bytes.
>2) Some number of base-255 digits, with leading 0 digits stripped,
>terminated by the value 255. With this format, we always use at least 1
>byte (for a value of 0, which is written as just the terminator (255)),
>but generally use 2..9 bytes.
>3) Some number of base-128 digits, with leading 0 digits stripped, all
>but the last prefixed by a 0 bit, and the last prefixed by a 1 bit.
>With this format, values 0..127 use 1 byte, 128..(128**2-1) uses 2
>bytes, etc, with 9 bytes being used for a 63 bit value, and 10 bytes
>used for a 64 bit value.
This is a frequently used approach, and IIRC also asimptotically
optimal (although it is usually done so that first there's the
number of digits encoded (your MSBs) and then the actual digits).
A more efficient approach can be that used by e.g. ZIP: if
you have some idea about the frequency distribution of the
lengths you'll have to encode, you can build a table of prefix
codes (e.g. by using Huffman encoding) for the *lengths of
the lengths* (or intervals). (You can even use the table built
into ZIP, as it was most likely created using extensive research :O)
> Does anyone have any comments? Both
> on space-efficiency and on difficulty of using it for trial decryptions.
You didn't mention what encryption are you planning to use,
so it's hard to tell whether it does matter that the file always
starts with some 0s.
Br,
Andras
------------------------------
From: [EMAIL PROTECTED] (Mack)
Subject: Re: SDMI challenge
Date: 08 Oct 2000 14:08:56 GMT
Technology A appears to use a slight frequency shift.
Although this could be an artifact.
Mack
Remove njunk123 from name to reply by e-mail
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: It's Rijndael
Date: Sun, 08 Oct 2000 14:16:57 GMT
On 08 Oct 2000 13:16:00 GMT, [EMAIL PROTECTED] (Mack) wrote, in
part:
>If rijndael is secure then it is impossible
>to find that key. However, the plsintext
>with *AES*WINNER*AES* as the key
>and ****Rjindael**** as the ciphertext
>is trivial to find ;)
Just a thought: while a key to do that would not be possible to find
if Rijndael is secure, a set of subkeys to do that is certainly
findable; it is trivial to change even the second-last subkey to make
a block encrypt to whatever you wish. (As the last subkey performs a
final XOR on output, achieving this by changing it is *too* trivial.)
Or one could choose a key (remember: the Rijndael key schedule begins
with the key itself) such that "Rijndael" becomes "AES Winner" in the
proposed format after the _first round_, although that requires a key
twice as long as the block.
John Savard
http://home.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Apologies for a faulty memory
Date: Sun, 08 Oct 2000 14:11:06 GMT
On Sun, 08 Oct 2000 14:57:21 +0200, Mok-Kong Shen
<[EMAIL PROTECTED]> wrote, in part:
>Sorry for not having followed the material. What are the
>main advantages of requiring odd multiples of 32 bits
>for key and block size? (Wouldn't that indicate some
>weakness of Rijndael's design style?) Thanks.
There are some _apparent_ weaknesses of Rijndael, at least from a
naive point of view. From the results people have had - so far, it
must be admitted - by actually carrying out differential and linear
cryptanalysis, however, Rijndael appears to be entirely satisfactory
in strength.
These apparent weaknesses are:
- In addition to using arithmetic in GF(2^8) in the Mix Column step,
the same representation of GF(2^8) is used to produce the round
constants in the key schedule, and to produce the S-box used in the
Byte Sub step (which S-box is also used in the key schedule).
- The number of true rounds, including the Mix Column step, in which
bytes influence each other, is, for the standard key and block sizes,
either 9, 11, or 13. In no case is one of these numbers a multiple of
the number of columns. Although the Shift Row step is more like
permutation P in DES than it is like swapping halves of a block (every
byte, not just half of them, goes through Byte Sub and Add Round Key,
and the influence of bytes on each other in Mix Column is two-way, not
one-way) still, from a naive point of view, just as having DES with an
odd number of rounds is a bad idea, this asymmetry or incompleteness
could conceivably be a minor weakness.
- The key schedule produces extents in the key schedule having the
same size as the original key. Since everything is in chunks of 32
bits, if the number of 32-bit words in the key were relatively prime
to the number of 32-bit words in the block, this might reduce the
impact of any weakness in the key schedule (and weaknesses have been
claimed).
As it happens, since the number of rounds increases by 1 for each 32
bits added to the size of the key once it is longer than the block,
using an odd multiple of 32 bits for the key in that case makes the
number of full rounds an even number, as well as the number of 32-bit
words in the key an odd number. So both (apparently) desirable
properties can often be achieved if a nonstandard key size is used
with a standard block size, thus addressing the last two of these
possible weaknesses.
A table giving the possibilities in more detail is now available
within my description of Rijndael:
http://home.ecn.ab.ca/~jsavard/crypto/co040801.htm
Incidentally, I've recently corrected an error in my pretty picture of
a Rijndael round (I forgot the order in which the bytes of the block
went into the rectangle); also, the proposed mod to MARS I included in
a Round 2 AES comment is now mentioned on the MARS page.
As well, a *few* tidbits on Galois Fields are on the page about
shift-register stream ciphers, including an explicit table of a
representation of GF(2^3).
John Savard
http://home.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: Daniel James <[EMAIL PROTECTED]>
Subject: Re: Why trust root CAs ?
Date: Sun, 08 Oct 2000 15:20:50 +0100
Reply-To: [EMAIL PROTECTED]
In article <1kQD5.22093$[EMAIL PROTECTED]>, Lyalc wrote:
> 1. In the smartcard scenario described below, a symmetric key does the
> exact same job (card+PIN = proof of identity)
If we state that the customer trusts the bank not to falsify payment
instructions, that there is no need for the veracity of the payment
instructions to be checked by any party other than the bank, and that there is
no desire to provide the customer with a signing key for any other purpose
than signing payment instructions that will be verified only at the bank then,
yes, you're quite right.
Using a public key system makes it possible for the trader (who can be made
aware of the customer's public key, but would not be aware of a secret key
used in a siilar way) to check the signature and reject bogus payments without
having to trouble the bank, using certificates makes it possible for the
trader to have confidence that the customer's public key has not been spoofed.
The system I have outlined also provides the customer with a public keyset
that can be used for other purposes (signing EMail, etc.) which I perceive as
a benefit that could not be derived from a secret key system.
> 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.
The terms and conditions offered by a bank are defined by the bank, and are
set when the customer and the bank enter into a contract. There isn't any
legal requirement for the bank to indemnify the customer against fraud and
there is no requirement for the bank to do so - unless/until such a contract
is signed. Banks can and do change the terms and conditions of credit card
accounts and the customer has the right to change banks if he doesn't like the
terms. As I said - it currently suits the banks to offer that indemnity as
part of their service, if that changes you can be sure that they will stop
offering it.
> 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.
Absolutely - and the credit card company, as well. What I should perhaps have
spelt out more clearly was that I was proposing that the bank - or, in fact,
the credit card company - should *BE* a CA. You express your trust in your
bank when you open an account and deposit your money with them, you need
express no greater degree of trust when you allow them to sign certificates
for keys that are to be used to authorize your manipulation of that account.
(It would require a bit more trust to then use the bank-certified keys for
other purposes, but youcan choose not to do that.)
> 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?
No. That's not what PKI buys you, though. If I trust my bank, and my bank
trusts your bank, and your bank trusts you, then I can feel that - at least as
far as banking is concerned - I can trust you. PKI provides a mechanism
whereby that trust can be communocated securely between all the parties
involved where there are more than 2 parties.
If you turn out not to be trustworthy I can turn to my bank and complain that
they represented you as trustworthy, they can turn to your bank and say the
same, and your bank knows who you are and can exact retribution.
If PKI were properly applied to eCommerce the customer would be required to
send a digitally signed order to the trader and the trader would be required
to send a digitally signed order acknowledgement back to the customer. Each of
these signatures could be verified by the receiving party and by the banks
concerned. In jurisdictions where digital signatures have legal force these
signed packets will constitute a contract for sale and the customer will have
/legally acceptable/ proof of the order's acceptance and /legal/ redress
against the trader if the order is not met. Trust is still involved, yes - all
parties concerned have to trust the financial institutions and the financial
instsutions have to trust each other - but this is nothing new, this is a
fundamental requirement for any sort of commerce and eCommerce doesn't change
a thing.
I do take your point that the technology has to work, too, and that there are
attacks that can be carried out to subvert digital signatures; but the same is
true for written signatures and, again, nothing is really new.
Going back to the original poster's question - "why trust root CAs?" - I
suppose my take on this is that there isn't any reason to trust a CA while
that CA is a disinterested party, so it's a good question. I do think, though,
that PKI technology has a lot to offer, and I think that what will make it
start to work in the real world is certificates being issued by insitutions -
like banks and credit card companies - who have a vested interest in providing
a secure environment for their own businesses, and with whom we all deal every
day of our lives.
Cheers,
Daniel.
------------------------------
From: Daniel James <[EMAIL PROTECTED]>
Subject: Re: Why trust root CAs ?
Date: Sun, 08 Oct 2000 15:20:51 +0100
Reply-To: [EMAIL PROTECTED]
In article <[EMAIL PROTECTED]>, David Hopwood wrote:
> > 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.
>
> In that case the certificate and the use of a CA are superfluous; the bank
> could just as easily store your public key in their database record for
> your account. That would be simpler, more efficient, and it would eliminate
> a number of potential failure modes (attacks against the certification
> standard, compromise of the bank's CA key, any problems in matching
> certificate attributes to database records, etc.) Remember that the bank
> already has to store a PIN for each card, so storing a public key instead
> (or as well) is a straightforward change. There is no advantage to the bank
> in using certificates.
If the signatures were to be checked only by the bank then you would be quite
right. The advantage of using certificates is that the trader can verify the
payment instruction before sending it to the bank. A trader would certainly
want to do this before issuing a signed receipt/order confirmation.
You're quite right to point out the existence of failure modes - compromise of
a bank's CA certificate would be disastrous - but these are technical problems
that can be overcome. Consider that banks already have to handle secret keys
whose compromise would be very expensive to their business (e.g. PIN
verification keys for ATM cards) and that they have equipment and procedures in
place to do this.
Cheers,
Daniel.
------------------------------
From: Daniel James <[EMAIL PROTECTED]>
Crossposted-To: comp.security.misc
Subject: Re: Why trust root CAs ?
Date: Sun, 08 Oct 2000 15:20:51 +0100
Reply-To: [EMAIL PROTECTED]
In article <[EMAIL PROTECTED]>, Alan J Rosenthal
wrote:
> Do I trust my bank? I don't know, but I do trust them with my PIN;
> really, it's theirs to begin with. My banking data and operations are
> not a secret from my bank.
>
> Do I trust the certificate authority which issues the SSL certificate which
> causes me to be able to contact my bank via SSL? No! I don't even know who
> that is. And I don't care. I just want to use SSL so that the connection
> is unsniffable.
Yes, this is the point I've suggested elsewhere in this thread - if the SSL
certificate were issued *by* your bank you would trust it as much as you trust
them to look after your money.
As you say: you just want to use SSL so that the connection to your bank is
"unsniffable"; the trouble is that you can't know that using SSL has that
effect unless you trust the certificate.
> Trust is not transitive, in computer
> security or in real life. If my friend says something strange, I might ask
> who told him that, and if he says it's Fred, I might say "ah, I don't believe
> anything Fred says". The trust is based on the source, not the last link.
> My friend might say "hey, Fred's a good chap, I trust him" and I trust my
> friend, but I still don't trust Fred.
That's a good point. In order to make trust useful, in some cases, we would
have to change the rules. To follow your analogy, if you wanted to make use of
the information your friend has passed on from Fred you would have to say "OK,
you believe Fred - will you accept responsibility for my taking Fred's
information at face value?". If Fred was lying you could sue your friend and he
could sue Fred (assuming all the communication was signed). Whether this would
be a good thing I'm not sure - it could be a quick way to lose friends!
Cheers,
Daniel.
------------------------------
From: [EMAIL PROTECTED] (Timothy M. Metzinger)
Date: 08 Oct 2000 14:33:37 GMT
Subject: Re: Why trust root CAs ?
In article <8rp4qj$qeb$[EMAIL PROTECTED]>, [EMAIL PROTECTED] (nospam)
writes:
>For the moment the goal is to only sign keys for people we know personally,
>which means the CA will only really be useful within our circle of friends,
>a relatively small community.
At least in the US, I don't think we will see a whole bunch of hierarchical
PKIs. Rather, we'll likely see a network of Bridge CAs and CAs based around
communities of interest, like the one described above.
The Bridge CAs will serve as methods of extending the chain of trust between
other CAs
Timothy Metzinger
Commercial Pilot - ASMEL - IA AOPA Project Pilot Mentor
'98 M20J - N1067W
Pipers, Cessnas, Tampicos, Tobagos, and Trinidads at FDK
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: It's Rijndael
Date: Sun, 08 Oct 2000 14:19:41 GMT
On Tue, 03 Oct 2000 14:28:46 -0700, David Schwartz
<[EMAIL PROTECTED]> wrote, in part:
> However that assumption was not stated, in fact David Hopwood
>specifically stated the opposite of that assumption. Finding a key that
>produces such an encryption is 2^128 easier than actually finding the
>correct key.
Yes, when there are 2^128 keys that will do it. Which means that only
2^128 operations are required, instead of 2^256 operations, to find a
_256-bit_ key to do it.
So finding a possible key is merely equivalent to cracking Rijndael
with 128-bit keys. At least, for any key significantly shorter than
the total amount of subkey material used.
John Savard
http://home.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: [EMAIL PROTECTED] (Mack)
Subject: Re: SDMI challenge
Date: 08 Oct 2000 15:01:07 GMT
>Technology A appears to use a slight frequency shift.
>Although this could be an artifact.
>
>
>Mack
>Remove njunk123 from name to reply by e-mail
>
This appears to start at 5B00 or shortly after. The files are basically
identical up to
that point.
Mack
Remove njunk123 from name to reply by e-mail
------------------------------
From: Ichinin <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: WEP
Date: Sun, 08 Oct 2000 05:06:05 +0200
Two questions:
802.11 states:
"WEP algorithm based on the RC4 PRNO algorithm"
(claimed to be developed by RSA.)
- Anyone have any details about this?
- Anyone have a link to the page that say that 40 bit RC4 was
bruteforced in an very short time?
Regards,
Glenn
------------------------------
** 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
******************************
