Cryptography-Digest Digest #997, Volume #12 Tue, 24 Oct 00 23:13:01 EDT
Contents:
Re: idea for spam free email ("G. Orme")
Re: Why trust root CAs ? ("Tor Rustad")
Re: idea for spam free email (jungle)
Re: On block encryption processing with intermediate permutations (Bryan Olson)
Re: IEEE P1363 Meeting Announcement (Mack)
Re: Efficient software LFSRs ("Trevor L. Jackson, III")
Re: Visual Basic ("Phillip Jones")
Re: Efficient software LFSRs ("Trevor L. Jackson, III")
Re: Efficient software LFSRs (Tom St Denis)
Re: Steganography books (wtshaw)
----------------------------------------------------------------------------
From: "G. Orme" <[EMAIL PROTECTED]>
Subject: Re: idea for spam free email
Date: Wed, 25 Oct 2000 01:09:57 GMT
"Ben Clifford" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> On Sat, 21 Oct 2000 10:39:01 GMT, G. Orme <[EMAIL PROTECTED]> wrote:
>
> >G. This is a good point because the system could be rendered worthless. I
> >would propose to stop this by every month people download a small update
to
> >their software. The server would be set to not accept emails from people
who
> >didn't have this update. Hackers would then have to crack the software
once
> >a month to keep sending advertising which is a lot of work for a small
> >return. In a variation of this the update is emailed to each person once
a
> >month to make it easier for them.
>
> But equally, someone would have to put effort into rewriting the code
> every month, in such a way that it cannot be automatically hacked at
> the other end. For example, if you just change some string constant in
> your program, it should be pretty easy to automatically find
> that constant. So a hacker only needs to make a program once, which will
> hack the code every month automatically.
G. The code could include a kind of checksum of the size of certain files
that is sent with emails, and if it is wrong the emails are not accepted. A
hacker couldn't know what the checksum was.
>
> Maybe some form of varying obfuscation?
>
> >system is easily done. Say you want to send an email to someone who has a
> >protected email address as described. One would send the email as before,
> >but this would be diverted to an administrator who would send them a
message
> >that they must download the program to send the email. In a few minutes
they
> >can be logged on to the system and sending emails. One might have
additional
> >safeguards such as proof of ID, but if someone did spam then they would
be
> >automatically cut off on a complaint from a customer.
>
> That is still too inconvenient.
G. It only has to be done the first time, and then once a month. It depends
whether it is more or less convenient than getting spam.
>
> For example,
> If you want me to give you help for my globe applet, you do it on my
> terms, which means give me an e-mail address that I can correspond
> to.
G. Once you join the network you correspond perfectly freely, no
restricitons except you agree not to send spam.
> You don't have to do that, I don't have to communicate with you - it is
> you who wants me to help you, and I am not going to help you if I have
> to download code to decrypt your messages.
G. The messages aren't encrypted, just the email address. Of course someone
can have two email addresses, one for the people who won't use the system,
and a hmmm folder. Once the system is set up it would be exactly the same as
normal email, completely transparent. Think of the monthly upgrade as like
downloading small upgrades for e.g. flash which people do automatically
already.
> So ultimately you lose out.
> You either get no support for my globe applet, or you give me your
> real address, in which case I sell it to my local spam factory for
> 1 eurodollarpoundmark.
>
>
> --
> http://www.hawaga.org.uk/ben/
> GPG key 30F06950 on key servers & my web page. You are encouraged to use
it!
> Visit my page for benno.globe - rotating world map applet.
------------------------------
From: "Tor Rustad" <[EMAIL PROTECTED]>
Subject: Re: Why trust root CAs ?
Date: Tue, 24 Oct 2000 12:58:15 +0200
"Anne & Lynn Wheeler" <[EMAIL PROTECTED]> wrote in message
>
> "Tor Rustad" <[EMAIL PROTECTED]> writes:
> > I'm reading your posts with interest, and will look into some of your
links
> > on this matter. I must admit that I have not paid attention to X9.59. In
> > SET, the ISO8583 mapping is implemented already, why do we need another
way
> > to do this? To open up for on-line debet card transactions?
> >
> > As long as the card companies allow no security via credit cards, and
the
> > banks earn more mony (in some countries) on credit card transactions,
the
> > business case for implementing X9.59 doesn't look good. Also, _if_ X9.59
> > mandates new messages at the ASN.1 level, this will be expensive to
> > implement. Futhermore, some of us are starting to get really fed up with
all
> > these PKI standards...
>
> there is existing fraud ... even w/o the internet.
Well, w/o internet its close to zero in some countries, insignificant number
of credit card transactions anyway...ca. 1%
IF the card companies doesn't push harder soon, they take a risk. How long
do you think we can wait before we implement a on-line national solution? We
have the means and the ability, then it will be close to zero credit card
transactions left. For now, people doesn't trust internet, so they stay away
and everyone is loosing mony.
> SET didn't provide end-to-end authentication. It truncated
> authentication at the SET payment gateway and then generated an
> acquiring financial infrastructure transaction with a flag indicating
> authentication ... which eventually got to the customer's issueing
> financial institution.
That was not the problem with SET. We have been ready to roll out cardholder
SET certificates at large scale for years, so far we have only issued SET
certificates to merchants. The hole system has been tested all the way, and
just sits waiting for someone to say go. The problem is that no one wants to
roll out SET wallets, its too complicated (for the cardholders). Also
implementing SET at the merchants has been difficult.
> Two years ago, somebody from VISA gave a presentation at an ISO
> meeting regarding the number of (SET) transactions coming into
> consumer issuing financial institutions with the SET authenticated
> flag turned on ... and they could show that there was no SET
> technology involved in the transaction (issue crops up in security
> infrastructures when there isn't end-to-end authentication and
> end-to-end integrity).
So what? Who will use a complicated security infrastructure if someone else
take the risk, and allow less security at the same cost?
Unless the credit card companies start charging less secure transactions
different from the more secure ones, it will never be used. I don't think
VISA/MC has been pushing the SET technology much so far.
<snip>
> Standard business case applies to X9.59 ... benefits outweight the
> costs. Done as part of normal business, the technology, development,
> and deployment costs of X9.59 can be managed into the noise range. As
> cited in previous postings ... those costs however are totally dwarfed
> by costs of deploying real live customer call center support for new
> kinds of technology transactions.
Sorry, I still don't see why we need X9.59. We have so far supported SET,
and will not jump on another wagon easly, not at least by just doing the
same thing in another way.
> One of the issues with X9.59 is that it has been defined as part of
> the industry financial standards process ... for implementation as
> part of standard production operation. In order to achieve end-to-end
> integrity, it doesn't define toy pilots that might be do'able for $50k
We are not used to toy pilots, as one of the first VISA/MC certified PGW,
MCA and CCA SET providers, that was very much the real thing. The security
problem is not at the back-end...there is no fraud at the back-end, securing
transactions on the front-end (into the PGW) is what is needed.
<snip>
> So what are compelling business issues for end-to-end authentication
> and integrity ... along with fraud & risk reduction?
More transactions. More trust from people.
--
Tor
------------------------------
From: jungle <[EMAIL PROTECTED]>
Subject: Re: idea for spam free email
Date: Tue, 24 Oct 2000 21:27:14 -0400
"G. Orme" wrote:
===
> Of course whoever
> uses the program must agree as part of the license not to send advertising
> by email anyway.
and you call this spam free idea ?
------------------------------
From: Bryan Olson <[EMAIL PROTECTED]>
Subject: Re: On block encryption processing with intermediate permutations
Date: Wed, 25 Oct 2000 01:34:02 GMT
Mok-Kong Shen wrote:
> Thanks. I think that I now understand your frequency argument.
> Following your three cycle (2 permutation) example, I'll
> have the following. Please check whether I am right.
>
> Input of first cycle (u, v, u, v)
>
> Output of first cycle (w, x, w, x)
>
> First permutation, preserving block equality, leading
> to two possible outcomes (w, x, w, x) and (x, w, x, w)
>
> Output of second cycle (l, m, l, m) and (j, k, j, k)
>
> Second (last) permutation, arbitrary, giving rise to 6
> each, of equal frequency, totalling 12, namely
> (l, m, l, m) (j, k, j, k)
> (l, m, m, l) (j, k, k, j)
> (l, l, m, m) (j, j, k, k)
> (m, l, l, m) (k, j, j, k)
> (m, l, m, l) (k, j, k, j)
> (m, m, l, l) (k, k, j, j)
>
> Output of third cycle: (Ai, Bi, Ci, Di) and (Ei, Fi, Gi, Hi),
> (1<=i<=6) totalling 12. This is the ciphertext.
>
> Now please help again:
>
> How am I going to set up the functional relations that are
> useful for gaining information of the key? Can I simply
> pick for this purpose any one of the 12 possible outcomes
> of the ciphertext or only some particular ones? A previous
> post of yours seems to require picking particular ones, but
> I don't know how to recognize these, since all 12 are of
> equal frequency.
The attacker recognizes these by comparing their blocks to the
results of encrypting the single-block plaintext (u, v).
Let's look at how the possible outputs of the last permutation
get encrypted by the last cipher-cycle. Call the last
permutation input (j, k, j, k) and suppose the cipher-cycle
maps:
(j, k) -> (a, b)
(k, j) -> (c, d)
(j, j) -> (e, f)
(k, k) -> (g, h)
Then we can get the following final outputs. The texts to the
right of the "->" are what the attack actually gets to see.
(j, k, j, k) -> (a, b, a, b)
(j, k, k, j) -> (a, b, c, d)
(j, j, k, k) -> (e, f, g, h)
(k, j, j, k) -> (c, d, a, b)
(k, j, k, j) -> (c, d, c, d)
(k, k, j, j) -> (g, h, e, f)
The blocks (a, b) and (c, d) are in the set of outputs for
input (u, v). So here's how it works, (assuming a Feistel
cipher):
(a, b, a, b)
(c, d, c, d) - Not useful
(a, b, c, d)
(c, d, a, b) - Two blocks that are in the set of single-block
outputs frequently appear together. That means (a, b) and (c, d)
are sibling pairs. 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)
(e, f, g, h)
(g, h, e, f) - Two blocks not in the set of single-block outputs
frequently appear together. That means (e, f) and (g, h) are
repeated-word outputs. There exist words y and z such that
e = y ^ F(k15, y)
f = y ^ F(k16, e)
g = z ^ F(k15, z)
h = z ^ F(k16, g)
Now the enhancement (specific to Feistel ciphers) that I added
a few days ago: In our example j = w = y and k = x = z, but
of course the attacker doesn't know that (yet). Looking over
the high-frequency outputs, the attacker can note:
a ^ c = e ^ g
This only way this is likely to happen is if,
(w, x) = (y, z) OR (w, x) = (z, y)
Whichever side of the OR is true, we have
a ^ e = w ^ x = y ^ z
That lets us isolate the last round. The equations we have
for k16 are:
b = x ^ F(k16, a)
d = w ^ F(k16, c)
f = y ^ F(k16, e)
h = z ^ F(k16, g)
Using x = a ^ e ^ w and z = a ^ e ^ y we reduce to,
b = a ^ e ^ w ^ F(k16, a)
d = w ^ F(k16, c)
f = y ^ F(k16, e)
h = a ^ e ^ y ^ F(k16, g)
Solving as far as possible:
F(k16, a) ^ F(k16, c) = a ^ b ^ d ^ e
F(k16, e) ^ F(k16, g) = a ^ e ^ f ^ h
I can now simply guess-and-check k16, or parts of it. In the
case of DES, I can guess each 6-bit s-box input individually.
As a final check on the round-key, I can find w, x, y and z,
and check that {w, x} = {y, z}.
The enhancement is so efficient on DES or similar ciphers that
we should probably not bother finding which two-word outputs
are high frequency. We just find most of the one-block
encryptions of (u, v) and all the pair-wise XORs of their
first words. We then repeatedly encrypt (u, v, u, v), call
the output (p, q, r, s) and check whether p ^ r matches one of
the XORs (and does not contain any of the single-block
outputs). If it does, then there's a good chance that the two
single-block outputs that we XOR'ed are a sibling pair, and
(p, q, r, s) is the corresponding repeated-word output, so we
can quickly solve for the last round-key. We'll get
false-hits, but then we'll quickly fail to solve for a
round-key and move on.
--Bryan
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (Mack)
Subject: Re: IEEE P1363 Meeting Announcement
Date: 25 Oct 2000 01:46:49 GMT
>
>Study Group for Future Public-Key Cryptography Standards
>
>IEEE P1363 Working Group:
> Standard Specifications for Public-Key Cryptography
>
>
> MEETING NOTICE
>
> Wednesday, November 15, 2000, 8:30 am - 5:30 pm (study group and
>new working group projects)
> Thursday, November 16, 2000, 8:30 am - 5:30 pm (working group)
> Friday, November 17, 2000, 8:30am - 5:30pm (working group)
>
> National Security Agency
> Fort Meade, Maryland
>
>These meetings of the Study Group for Future Public-Key Cryptography
>Standards
>and P1363 working group are open to the public.
>
Those are some bad dates if there ever were any since the NESSIE
conference is on the 13th and 14th in Lueven Belgium.
Oh, wait the NSA is hosting it.
>At the study group meeting, we will primarily discuss the P1363
>Public-Key Techniques Registry. Hopefully a consensus can be
>reached on whether the group wants to propose this project or not.
>The group will entertain further presentations on future standards
>work as needed and discuss the operation of the study group for
>its lifetime. All attendees of this meeting are considered to be
>full voting members of the study group.
>
>At the P1363 working group meeting, we will review the latest draft of
>P1363a in detail and work towards the completion of the draft standard.
>The group will spend a fair amount of time attempting to address some
>of the more difficult unresolved issues. We will discuss future plans
>with P1363a, and directly related activities including starting work on
>P1363b. The group will entertain presentations and discussions about
>topics considered for P1363b and discuss the next steps for starting
>that project. Please see the IEEE P1363 working group bylaws for
>membership and voting procedures for the working group.
>(http://grouper.ieee.org/groups/1363/)
>
>The meeting will be hosted by the National Security Agency.
>
>AGENDA
>
>WEDNESDAY, NOVEMBER 15, 2000 8:30 am - 5:30 pm
>Study Group for Future Public-Key Cryptography Standards and IEEE P1363
>Working Group
>
>1. Approval of study group agenda
>2. Approval of August study group minutes
>3. Discussion about P1363 Public-Key Registry
>4. Discussion about other potential projects
>5. Plan future work of the study group
>6. Adjourn study group
>
>1. Approval of working group agenda
>2. Approval of August minutes
>3. Officer reports
>4. Update on status of new projects
>5. New presentation to the working group (TBD)
>6. Discussion about P1363.1 (outline, content, new format, timeline)
>
>THURSDAY, AUGUST 24, 2000 8:30 am - 5:30 pm
>Study Group for Future Public-Key Cryptography Standards and IEEE P1363
>Working Group
>
>NOTE: On Thursday morning, 9:00-10:30am, there will be a guided tour of
>the
>National Cryptologic Museum, which is adjacent to the meeting room.
>
>6. Discussion about P1363.1 (cont’ as needed)
>7. Discussion about P1363.2 (outline, content, timeline)
>8. Update on P1363a document
>9. Update on related standards activities
>10. Review of P1363a timeline
>11. Discussion about major issues with P1363a
>12. Detailed review of P1363a draft
>
>FRIDAY, AUGUST 25, 2000 8:30 am - 5:00 pm
>IEEE P1363 Working Group
>
>12. Detailed review of P1363a draft (continued)
>13. Discussion of continuing work on P1363b
>14. Discussion of future activities of P1363 working group
>15. Adjourn
>
These dates don't correspond to the above dates in the heading.
>MEETING FEE
>
>There will be a meeting fee, which will be an IEEE fee of $10 per
>half-day and an additional catering fee that will be split between
>all attending (probably less than $20 per person). (subject to change)
>
>MEETING LOCATION
>
>The meeting will be hosted by the NSA at Fort Meade in Maryland.
>Fort Meade is about 10 miles south of Baltimore Washington International
>(BWI) Airport. Nearby hotels include:
>
>Ramada Inn - BWI Airport
>7253 Parkway Drive
>Hanover, MD 21076
>(410) 712-4300 or (800) 2-Ramada
>
>Comfort Inn Airport
>6921 Baltimore-Annapolis Blvd.
>Baltimore, MD 21225
>(410) 789-9100
>
>Sheraton BWI Airport
>Elm Rd.
>(410) 859-3300
>
>Columbia Inn
>Wincopin Circle,
>Columbia, MD
>(410) 730-3900
>
>REGISTRATION
>
>Formal registration is not required. For planning purposes, please
>RSVP to Ari Singer via e-mail at [EMAIL PROTECTED] or by phone at
>(781) 221-1306 or to Jerry Solinas at [EMAIL PROTECTED]
>
Mack
Remove njunk123 from name to reply by e-mail
------------------------------
Date: Tue, 24 Oct 2000 22:10:23 -0400
From: "Trevor L. Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: Efficient software LFSRs
Tom St Denis wrote:
> In article <[EMAIL PROTECTED]>,
> "Trevor L. Jackson, III" <[EMAIL PROTECTED]> wrote:
> > This is a brief summary of a technique for implementing efficient
> LFSRs
> > in software. The mechanism involves generating successor states a
> word
> > at a time rather than a bit at a time. In order to accomplish this
> > parallelism inter-tap dependencies must be eliminated.
>
> <snip>
>
> Have any source code to show off your implementation?
Sure. I posted this a month or so ago. It implements a 31-bit LFSR with
taps at bits 2 and 30. It's a bit careless about the sign bit, but with
appropriate seeding it's not a problem. The first assignment statement
creates three new output bits in positions 28-30. The second assignment
statement creates 28 new output bits in positions 0-27. These output
bits are the same as those created by a Fibbonacci implementation. The
period is, of course, 2^31-1.
Compare the efficiency with an equivalent Galois implementation of a
trinomial LFSR.
static long seed = __LINE__; // non-zero init
extern long random( void )
{
assert( seed > 0 );
seed ^= ( seed & 7 ) << 28;
seed ^= seed >> 3;
assert( seed > 0 );
return( seed );
}
Tom, See if you can extend this to registers larger than a single
machine word. If you have trouble I'll post the code for a 521-bit
version.
------------------------------
From: "Phillip Jones" <[EMAIL PROTECTED]>
Subject: Re: Visual Basic
Date: Wed, 25 Oct 2000 02:20:55 GMT
doesn't the navaho lock software use microsoft encryption dll's that come
with the system.
maybe you could use vb to access some of its methods as well..
"binary digit" <[EMAIL PROTECTED]> wrote in message
news:ISmI5.126052$[EMAIL PROTECTED]...
> Anyone know where I can find some encryption algorithms that have been
coded
> in Vb and have good documentation on them?
>
>
------------------------------
Date: Tue, 24 Oct 2000 22:27:06 -0400
From: "Trevor L. Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: Efficient software LFSRs
Rob Warnock wrote:
> Trevor L. Jackson, III <[EMAIL PROTECTED]> wrote:
> +---------------
> | This is a brief summary of a technique for implementing efficient LFSRs
> | in software. The mechanism involves generating successor states a word
> | at a time rather than a bit at a time. In order to accomplish this
> | parallelism inter-tap dependencies must be eliminated.
> +---------------
>
> I'm not sure what you mean by "inter-tap dependencies" here.
In a fully parallel LFSR inter-tap dependencies appear when a tap is upstream
of the half-way point of the register. Consider a register with two taps at
the extreme ends of the register. There is no parallelism possible because the
state of each bit is dependent on the state of the bit immediately downstream
of it.
Then consider a two-tap register with both taps adjacent to the downstream
end. In this case all but one bit of the register can be updated immediately,
the single exceptional bit requires an input that is the output of the first
step. In general, when all the taps are downstream of the halfway point at
least half of the register can be updated in parallel and then the remainder
updated with a second step.
When the register is large with respect to the machine word size the limit on
tap dependencies allows taps at all positions except the upper half of the
upstream word of the register.
> The code at
> <URL:http://www.landfield.com/faqs/compression-faq/part1/section-26.html>
> will work with *any* set of feedback bits using the Galois arrangement, in
> which the XOR gates (for the non-zero polynomial coefficients) are between
> the register stages. [Note that the Fibonacci configuration has to have
> a single huge N-input XOR, which is a lot slower in both hardware *and*
> software (unless you have a single-cycle pop-count instruction) for dense
> polynomials than the Galois configuration.]
I'm familiar with both kinds of implementation. They are slow, especially in
larger registers.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: Efficient software LFSRs
Date: Wed, 25 Oct 2000 02:38:05 GMT
In article <[EMAIL PROTECTED]>,
"Trevor L. Jackson, III" <[EMAIL PROTECTED]> wrote:
> Tom St Denis wrote:
>
> > In article <[EMAIL PROTECTED]>,
> > "Trevor L. Jackson, III" <[EMAIL PROTECTED]> wrote:
> > > This is a brief summary of a technique for implementing efficient
> > LFSRs
> > > in software. The mechanism involves generating successor states
a
> > word
> > > at a time rather than a bit at a time. In order to accomplish
this
> > > parallelism inter-tap dependencies must be eliminated.
> >
> > <snip>
> >
> > Have any source code to show off your implementation?
>
> Sure. I posted this a month or so ago. It implements a 31-bit LFSR
with
> taps at bits 2 and 30. It's a bit careless about the sign bit, but
with
> appropriate seeding it's not a problem. The first assignment
statement
> creates three new output bits in positions 28-30. The second
assignment
> statement creates 28 new output bits in positions 0-27. These output
> bits are the same as those created by a Fibbonacci implementation.
The
> period is, of course, 2^31-1.
>
> Compare the efficiency with an equivalent Galois implementation of a
> trinomial LFSR.
>
> static long seed = __LINE__; // non-zero init
>
> extern long random( void )
> {
> assert( seed > 0 );
>
> seed ^= ( seed & 7 ) << 28;
> seed ^= seed >> 3;
>
> assert( seed > 0 );
>
> return( seed );
> }
>
> Tom, See if you can extend this to registers larger than a single
> machine word. If you have trouble I'll post the code for a 521-bit
> version.
It's a neat trick, I am afraid that i am preoccupied with my CHES
submission...
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: Steganography books
Date: Tue, 24 Oct 2000 20:30:34 -0600
In article <8t4ttd$r3o$[EMAIL PROTECTED]>, zapzing <[EMAIL PROTECTED]> wrote:
> Couldn't you just specify a standardized
> light source?
>
The usefulness of some of this is knowing what off-the-shelf has ready for
you to use. I'm starting to see some interesting data...stay tuned.
--
52) *Part of job is making whimsical, zippy, and vexing key sequences.
------------------------------
** 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
******************************
