Cryptography-Digest Digest #980, Volume #12 Sun, 22 Oct 00 18:13:01 EDT
Contents:
Re: Why trust root CAs ? ("David Thompson")
Re: On block encryption processing with intermediate permutations (Bryan Olson)
Re: Dense feedback polynomials for LFSR ("Trevor L. Jackson, III")
Re: Visual Basic (Paul Schlyter)
Re: Why trust root CAs ? ("Lyalc")
Re: Visual Basic (Sundial Services)
Re: Why trust root CAs ? (Anne & Lynn Wheeler)
Encrypting a file using Rijndael ("mac")
----------------------------------------------------------------------------
From: "David Thompson" <[EMAIL PROTECTED]>
Subject: Re: Why trust root CAs ?
Date: Sun, 22 Oct 2000 20:27:35 GMT
Lyalc <[EMAIL PROTECTED]> wrote :
>
> David Thompson wrote in message ...
> >Lyalc <[EMAIL PROTECTED]> wrote :
>
> >> Why does every sniffer and every server along the line need to see your
> name
> >> and address that is embodied in the certificate?
> >>
> >> Only you and the delivery agent need that information, yet certificates
> give
> >> it all away, every time the certificate is used. No ifs, no buts,
> >> privacy=zero.
> >>
> >Not necessarily. SET solves this -- for the cardholder --
> >by using as the cardholder identifier a keyed hash (HMAC)
> >of the account number by a secret opaquely agreed
> >between the cardholder (system) and the cardholder CA,
>
>
> This merely generates a 'fixed' alias, which the merchant is immediately
> able to link Buyer_ID to Cert_Alias.
> Now, how long before lists start cicrulating the Alias=Buyer_ID mapping?
> If merchant DB can't keep CC numbers safe, can they keep an Alias=Buyer_ID
> mapping safe for longer than a card expiry period?
>
Yes, if the merchant is abusive, or hacked, you have a problem
in any account-based scheme -- only anonymous "cash" solves
that. Or throwaway accounts kept confidential by the issuer;
or whose issuance is itself anonymous (but at present only
banks can do this and AFAICT they aren't willing to do so).
Or non-technical means like data-subject protection laws
that are enacted and enforced, but that's getting offtopic.
What the SET chUID scheme does protect against is
"every sniffer and server along the route", which is what
I was responding to.
...
> >(Or was; SET doesn't revoke cardholder, or merchant, certs,
...
> So the merchant is still no better off - they still have to wait for
> authorisation and clearing before they know is the transaction is valid (or
> not).
> Any picking, and packing is still at risk of either expired cert, revoked
> cert, insufficient funds, or misused private key.
> What does the cert add to this?
The merchant alone cannot fully verify the transaction, yes.
(He can and does check for expired certs, and (very unlikely)
revocations in the CA hierarchy, but that isn't enough.)
But the cert authenticates the cardholder to an _acquirer_
(who under the business model trusts CCAs, before you ask)
sufficiently that revocation and credit limits can be handled by
existing clearing systems without (expensive and long) changes.
As a result, depending on association policies, the acquirer may
accept liability against fraudulent SET transactions where they
won't for non-SET internet transactions. That's the benefit.
It does depend on the cardholder's key(s) being secure,
but so does any other cryptographic scheme where the
cardholder (or other ordinary consumer) is a full party.
--
- David.Thompson 1 now at worldnet.att.net
------------------------------
From: Bryan Olson <[EMAIL PROTECTED]>
Subject: Re: On block encryption processing with intermediate permutations
Date: Sun, 22 Oct 2000 20:18:52 GMT
Here are a couple errata and one enhancement to the attack
I wrote:
> The cipher is
> specified only as a Feistel cipher.
Actually, Shen did not restrict it Feistel ciphers, though
Feistel ciphers were specifically mentioned as candidates.
The basic attack method applies to other types. The
end-game of course depends upon the "cycle" structure of the
cipher.
[...]
> Now how do we determine which pairs of 1-block ciphertext
> descended from the same state before the last permutation?
> If the Feistel cipher allows for very efficient solution of
> the equations, we might just do it by exhaustive guessing.
> If not, then we use more chosen ciphertext.
Of course the last word there should be "plaintext", not
"ciphertext".
[...]
> There is exactly one other class of ciphertexts from our
> two-block plaintext with members as probable as the
> equal-blocks and the sibling pairs. They appear when the
> first five permutations preserve block equality, and the
> last takes (x, y, x, y) to (x, x, y, y) or (y, y, x, x). We
> can recognize these outputs by their frequency, and they
> give us an alternative set of equations with which to attack
> the last two rounds. Given that the output is (a, b, c, d),
> there are words x and y such that,
>
> a = x ^ f(k15, x), c = y ^ f(k15, y),
> b = x ^ f(k16, a), d = y ^ f(k16, y).
The last equation should be d = y ^ f(k16, c).
Now the enhancement. The attack so far finds "sibling
pairs" such as (a, b) and (c, d), where we know there exist
words w and x such that,
a = w ^ f(k15, x),
b = x ^ f(k16, a),
c = x ^ f(k15, w),
d = w ^ f(k16, c).
We also get outputs, say (e, f, g, h), where each of the
blocks (e, f) and (g, h) are the result of applying the last
double-round to a block composed of two equal words, (y, y,
z, z). I'll call this a "repeated- word" state.
e = y ^ f(k15, y)
f = y ^ f(k16, e)
g = z ^ f(k15, z)
h = z ^ f(k16, g)
The same pair of words appears as (w, x) in the equations
for a sibling pair, and as y and z in a repeated-word state.
We get 128 of each. The previous description did not tell
how to match up the sibling-pairs to the corresponding
repeated-word states. If we can match them up, then we have
more information with which to attack the last two rounds.
The cipher may allow us to do the matching, and in
particular, with a Feistel cipher matching them up is easy.
If w = y and x = z (also if w=z and x=y) then
w^f(k15, x) ^ x^f(k15, w) = y^f(k15, y) ^ z^f(k15, z),
a ^ c = e ^ g.
Thus we can match sibling pairs to repeated word states
by comparing the XORs. This tells us that either
(w, x) = (y, z) OR (w, x) = (z, y).
It does not tell us which side of the OR is true.
One useful equation it gives us is
a ^ e = w ^ x = y ^ z,
which we can use to eliminate one of the unknowns in our
system of equations for sibling pairs.
a = w ^ f(k15, x),
b = a ^ e ^ w ^ f(k16, a),
c = a ^ e ^ w ^ f(k15, w),
d = w ^ f(k16, c).
Likewise for repeated word states.
e = y ^ f(k15, y),
f = y ^ f(k16, e),
g = a ^ e ^ y ^ f(k15, z),
h = a ^ e ^ y ^ f(k16, g).
Now attacking the k16 (the last round-key) is even easier.
We have enough information to attack it without even
considering the second-to-last round.
b = a ^ e ^ w ^ f(k16, a),
d = w ^ f(k16, c),
f = y ^ f(k16, e),
h = a ^ e ^ y ^ f(k16, g).
Note that there are only three unknowns: w, y and k16.
Guessing k16 gives us values for w and y, and we have two
more equations with which to check the guess. Of course we
can get more sets of equations of this form (for the same
k16) if we need them, and checking that {w, x} = {y, z}
gives us further assurance.
For most Feistel ciphers, we don't have to guess k16 all at
once. For example, with DES, we can guess-and-check just
the six bits that effect one s-box input.
--Bryan
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
Date: Sun, 22 Oct 2000 16:42:14 -0400
From: "Trevor L. Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: Dense feedback polynomials for LFSR
Joaquim Southby wrote:
> In article <[EMAIL PROTECTED]> Trevor L. Jackson,
> [EMAIL PROTECTED] writes:
>
> >Think about LFSRs with inverters in the feedback. You'll find that only the
> >parity of the inverter count matters. You'll also find that the degenerate
> >cases are those with alternating bits 0xAAA... and 0x555.... That change
> >eliminates the bias of more ones than zeros that afflicts a normal,
> >non-inverted LFSR.
> >
> Ow, I can do sparse feedbacks on a normal LFSR in my head. This
> inversion thing is going to take some practice.
>
> The parity thing makes sense. Inverting pairs of taps (and by extension
> an even number of taps) would make no difference because you wouldn't be
> changing the parity of the argument to the feedback function. Inverting
> an odd number of taps on a maximal length LFSR does eliminate the +1 bias
> seen on the normal LFSR, but it simply replaces it with a +0 bias because
> the zero state would be allowable whereas the FFF... state would not.
Not quite.
If you invert the output (bit not state) of the register you get a sequence missing
the all ones run, but the initial state of all ones is still on the maximal cycle
and the all zeros initial case is still degenerate.
If you invert the output of the feedback mechanism, i.e., the value of the re-input
bit is inverted, then you have a system equivalent to one with an odd number of
inverted taps. In this situation the all zeros case is not degenerate. Since all
of the tap values are zero their XOR is zero, which inverts to one. So after the
first mini-step the state of the register has zeros in all but the fed-back bit,
which is a one. If there are two taps then after the first maxi-step (N mini-steps)
the register is filled with alternating runs of zeros and ones whose length is the
distance between the input bit and the closest (upstream) tap. This is far from
degenerate in that within the first N steps the register move from a value with
singular weight (unique within the state space) to a value with dominant weight
(most common weight within the state space). By this metric inverted LFSRs have
less "inertia".
Given an odd number of taps and inverted feedback (or odd tap inversion parity) the
alternating bit patterns are co-degenerate. This can be proven by the observation
that the tap layout reduces to some number of taps on even bit numbers and the rest
on odd bit numbers. One of those subsets has an even number of members, and has no
influence on the state of the register because their combination is always zero.
The other subset has an odd number of members, and those are either all zero or all
one. If they are all zero they produce a zero combination and a one input. If they
are all one they produce a one combination and a zero input
On the following mini-step all of the input to the taps change (because the register
is filled with alternating bits). The subset with an even number of taps still has
no effect. The subset with an odd number of taps now has the opposite input so
produces the opposite output. Thus the inputs bits alternate between one and zero.
Thus the initial states of alternating bits 0xAAA... and 0x555... are co-degenerate.
An LFSR with an odd number of taps always has two degenerate or co-degenerate
states, so the maximum possible period is 2^N-2. This present an obvious problem in
that the period is divisible by two, and thus not prime. But there are interesting
cases where primality is unnecessary and lack of bias is valuable.
>
>
> What did you mean by the alternating bits? Were you describing the
> register state? The tap sequence?
The register state.
------------------------------
From: [EMAIL PROTECTED] (Paul Schlyter)
Subject: Re: Visual Basic
Date: 22 Oct 2000 22:17:55 +0200
In article <8sv66l$[EMAIL PROTECTED]>,
Guy Macon <[EMAIL PROTECTED]> wrote:
> Paul Schlyter wrote:
>
>> VB is compiled too; however VB as a language is indeed unsuitable
>> for bit-twiddling.
>
> PowerBASIC, on the other had, is ideal for bit-twiddling.
> [ http://www.powerbasic.com ]. On the same subject, everyone
> who twiddles bits should know about [ http://www.basicx.com ].
Power Basic was once Borland's Turbo Basic. I see no reason why a
Borland dialect of Basic should be so much more suitable for bit
twiddling than a Microsoft dialect of Basic. Can you, for instance,
in Power Basic do a right shift and control whether it's to be an
arithmetic right shift or a logical right shift? (without resorting
to assembly language, that is). Yes, there's probalby some ugly
way to do it, but can it be done cleanly, in one operation?
BTW Power Basic shares one weakness with Visual Basic: it's a single
platform language, and it's hard to port such programs to other
platforms.
--
================================================================
Paul Schlyter, Swedish Amateur Astronomer's Society (SAAF)
Grev Turegatan 40, S-114 38 Stockholm, SWEDEN
e-mail: pausch at saaf dot se or paul.schlyter at ausys dot se
WWW: http://hotel04.ausys.se/pausch http://welcome.to/pausch
------------------------------
From: "Lyalc" <[EMAIL PROTECTED]>
Subject: Re: Why trust root CAs ?
Date: Mon, 23 Oct 2000 08:29:45 +1000
A couple of other things SET doesn't protect against:
1. The order and certificate can be transmitted without SSL protection,
allowing any "every sniffer and server along the route" to match
order/delivery details (such as name, address etc) with the cardholder cert
alias
2. The cert being revoked around the time of the transaction. SET has an
inherent "Originating party" liability model. The US Govt's PKI schema
requires Relying parties to validate certificates before relying upon the
digital signature as an electronic signature. In a large dispersed
environment, this is perhaps the only way cert validity can be managed with
any reasonable granularity, and the expense of very high bandwidth and
CA/Revocation server availabiltiy requirements (AFAICS, all workable CRL
models require very high bandwidth, and very high availability).
There are working, high volume, secure environments out there today which
don't require cardholder keys, but do require secure key management. For
certificate based schema to get to that level of security, low exposure and
reliability, they need to be implemented on ATM or EFTPOS -like devices.
Since this level of hardware protection is needed to make certificate
schemes even moderately secure, why use certs as the hardware already does
all the necessary security?
Keeping cert vendor share prices high seems to be the only reason to me.
Lyal
David Thompson wrote in message ...
>Lyalc <[EMAIL PROTECTED]> wrote :
>>
>> David Thompson wrote in message ...
>> >Lyalc <[EMAIL PROTECTED]> wrote :
>>
>> >> Why does every sniffer and every server along the line need to see
your
>> name
>> >> and address that is embodied in the certificate?
>> >>
>> >> Only you and the delivery agent need that information, yet
certificates
>> give
>> >> it all away, every time the certificate is used. No ifs, no buts,
>> >> privacy=zero.
>> >>
>> >Not necessarily. SET solves this -- for the cardholder --
>> >by using as the cardholder identifier a keyed hash (HMAC)
>> >of the account number by a secret opaquely agreed
>> >between the cardholder (system) and the cardholder CA,
>>
>>
>> This merely generates a 'fixed' alias, which the merchant is immediately
>> able to link Buyer_ID to Cert_Alias.
>> Now, how long before lists start cicrulating the Alias=Buyer_ID mapping?
>> If merchant DB can't keep CC numbers safe, can they keep an
Alias=Buyer_ID
>> mapping safe for longer than a card expiry period?
>>
>Yes, if the merchant is abusive, or hacked, you have a problem
>in any account-based scheme -- only anonymous "cash" solves
>that. Or throwaway accounts kept confidential by the issuer;
>or whose issuance is itself anonymous (but at present only
>banks can do this and AFAICT they aren't willing to do so).
>Or non-technical means like data-subject protection laws
>that are enacted and enforced, but that's getting offtopic.
>
>What the SET chUID scheme does protect against is
>"every sniffer and server along the route", which is what
>I was responding to.
>
>...
>> >(Or was; SET doesn't revoke cardholder, or merchant, certs,
>...
>> So the merchant is still no better off - they still have to wait for
>> authorisation and clearing before they know is the transaction is valid
(or
>> not).
>> Any picking, and packing is still at risk of either expired cert, revoked
>> cert, insufficient funds, or misused private key.
>> What does the cert add to this?
>
>The merchant alone cannot fully verify the transaction, yes.
>(He can and does check for expired certs, and (very unlikely)
>revocations in the CA hierarchy, but that isn't enough.)
>But the cert authenticates the cardholder to an _acquirer_
>(who under the business model trusts CCAs, before you ask)
>sufficiently that revocation and credit limits can be handled by
>existing clearing systems without (expensive and long) changes.
>As a result, depending on association policies, the acquirer may
>accept liability against fraudulent SET transactions where they
>won't for non-SET internet transactions. That's the benefit.
>
>It does depend on the cardholder's key(s) being secure,
>but so does any other cryptographic scheme where the
>cardholder (or other ordinary consumer) is a full party.
>
>--
>- David.Thompson 1 now at worldnet.att.net
>
>
>
>
>
------------------------------
Date: Sun, 22 Oct 2000 14:37:10 -0700
From: Sundial Services <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: Visual Basic
Actually, Paul, Borland's take on language-design has always been
different from Microsoft's and in many cases much more advanced.
However, the fact remains that the bit-twiddling required for fast and
effective cryptography (in most cases) is: (a) better done using a
different language; AND (b) probably ALREADY DONE.
My original suggestion was simply that "while you can do it, you won't
be able to do it as easily or as well and ... why do it, except as a
purely academic exercise?"
> > Actum Ne Agas
> "Do not do a thing already done"
> (unless it's homework) ;-)
>Paul Schlyter wrote:
>
> In article <8sv66l$[EMAIL PROTECTED]>,
> Guy Macon <[EMAIL PROTECTED]> wrote:
>
> > Paul Schlyter wrote:
> >
> >> VB is compiled too; however VB as a language is indeed unsuitable
> >> for bit-twiddling.
> >
> > PowerBASIC, on the other had, is ideal for bit-twiddling.
> > [ http://www.powerbasic.com ]. On the same subject, everyone
> > who twiddles bits should know about [ http://www.basicx.com ].
>
> Power Basic was once Borland's Turbo Basic. I see no reason why a
> Borland dialect of Basic should be so much more suitable for bit
> twiddling than a Microsoft dialect of Basic. Can you, for instance,
> in Power Basic do a right shift and control whether it's to be an
> arithmetic right shift or a logical right shift? (without resorting
> to assembly language, that is). Yes, there's probalby some ugly
> way to do it, but can it be done cleanly, in one operation?
>
> BTW Power Basic shares one weakness with Visual Basic: it's a single
> platform language, and it's hard to port such programs to other
> platforms.
>
> --
> ----------------------------------------------------------------
> Paul Schlyter, Swedish Amateur Astronomer's Society (SAAF)
> Grev Turegatan 40, S-114 38 Stockholm, SWEDEN
> e-mail: pausch at saaf dot se or paul.schlyter at ausys dot se
> WWW: http://hotel04.ausys.se/pausch http://welcome.to/pausch
--
==================================================================
Sundial Services :: Scottsdale, AZ (USA) :: (480) 946-8259
mailto:[EMAIL PROTECTED] (PGP public key available.)
> Fast(!), automatic table-repair with two clicks of the mouse!
> ChimneySweep(R): "Click click, it's fixed!" {tm}
> http://www.sundialservices.com/products/chimneysweep
------------------------------
Subject: Re: Why trust root CAs ?
Reply-To: Anne & Lynn Wheeler <[EMAIL PROTECTED]>
From: Anne & Lynn Wheeler <[EMAIL PROTECTED]>
Date: Sun, 22 Oct 2000 21:53:21 GMT
"David Thompson" <[EMAIL PROTECTED]> writes:
> Yes, if the merchant is abusive, or hacked, you have a problem
> in any account-based scheme -- only anonymous "cash" solves
> that. Or throwaway accounts kept confidential by the issuer;
> or whose issuance is itself anonymous (but at present only
> banks can do this and AFAICT they aren't willing to do so).
> Or non-technical means like data-subject protection laws
> that are enacted and enforced, but that's getting offtopic.
or authenticated account transactions as in X9.59 (financial industry
draft standard for all retail electronic account-based transactions).
x9 (financial industry standards org) overview at: http://www.x9.org
the nominal requirements given the x9a10 working group for x9.59 work
item was to preserve the integrity of the financial industry for all
retail electronic account-based transactions with just a digital
signature.
in effect only authenticated transactions are supported for these
account (numbers) ... i.e. non-authenticated transactions against
x9.59 account numbers may not be authorized (note today a financial
institution may map multiple different account numbers with different
characteristics to the same account ... so there is nothing precluding
having both authenticated account number and a non-authenticated
account number mapping to the same account ... and the authorization
risk rules can be different based on the transaction type).
misc. details on x9.59 at http://www.garlic.com/~lynn/
there is a mapping of x9.59 to iso8583 (i.e. payment cards, debit,
credit, etc)
http://www.garlic.com/~lynn/8583flow.htm
misc. other discussion (authenticated transactions, privacy,
name/address issues, etc)
http://www.garlic.com/~lynn/99.html#217
http://www.garlic.com/~lynn/aadsm2.htm#straw
http://www.garlic.com/~lynn/aadsm3.htm#cstech13
http://www.garlic.com/~lynn/ansiepay.htm#privacy
http://www.garlic.com/~lynn/aadsmore.htm#x959demo
http://www.garlic.com/~lynn/aepay3.htm#sslset2
http://www.garlic.com/~lynn/aepay3.htm#x959risk2
--
Anne & Lynn Wheeler | [EMAIL PROTECTED]
http://www.garlic.com/~lynn/
------------------------------
From: "mac" <[EMAIL PROTECTED]>
Subject: Encrypting a file using Rijndael
Date: Sun, 22 Oct 2000 23:55:40 +0200
Hello!
I've somehow managed to make an implementation of Rijndael in C++ that
encrypts a single string and would like to add an option of encrypting a
whole file. I don't know what's the standard for doing this. Is every null
terminated string in a file encrypted separatelly or do I treat the whole
file as one array of 8-bit bytes no matter of null-characters. Of course, it
is not the same and if someone else would try to decrypt it using the other
method, result wouldn't be the original plain text.
Thank you in advanced.
------------------------------
** 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
******************************
