Cryptography-Digest Digest #413, Volume #14 Tue, 22 May 01 22:13:00 EDT
Contents:
Re: Apology to Cloakware (open letter) (wtshaw)
Re: ECB plus padding instead of CBC? ("Julian Morrison")
Re: ECB plus padding instead of CBC? ("Tom St Denis")
Re: "computationally impossible" and cryptographic hashs (wtshaw)
decorrelated bitsliced cipher ("Tom St Denis")
Re: Apology to Cloakware (open letter) (Anne & Lynn Wheeler)
Re: ECB plus padding instead of CBC? ("Julian Morrison")
Re: ECB plus padding instead of CBC? ("Joseph Ashwood")
Re: taking your PC in for repair? WARNING: What will they (Jim Turner)
Re: truth+integrity=sore losers (wtshaw)
Re: ECB plus padding instead of CBC? ("Julian Morrison")
Re: ON-topic - UK crime statistics (was Re: Best, Strongest Algorithm)
([EMAIL PROTECTED])
Re: ECB plus padding instead of CBC? ("Scott Fluhrer")
Re: ECB plus padding instead of CBC? ("Julian Morrison")
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: Apology to Cloakware (open letter)
Date: Tue, 22 May 2001 17:42:01 -0600
In article <[EMAIL PROTECTED]>, Anne & Lynn Wheeler
<[EMAIL PROTECTED]> wrote:
> "Douglas A. Gwyn" <[EMAIL PROTECTED]> writes:
>
> i remember as a kid (out west) seeing the track maintenance crews
> going thru every summer ... replacing ties.
>
> after graduation, i took a job on the east coast. there were ties you
> could stick your finger into. people complained that sections they
> remember as having train speed limits of 60-80 mph were down to
> 15. there was one section that was called the box-car grave yard where
> the freight train speed limit was 5 mph (and there were still regular
> derailments). It had been 20 years or more since the tracks had any
> PM.
>
> i seem to remember reading an article a year or so ago in ?? (possibly
> SJMN) about how the california PUCC was doing a tremendous job for the
> consumer by preventing the electronic companies from signing any
> long-term power supply contracts; that the PUCC had forced the
> california companies into only signing short-term contracts (in effect
> forcing them into the spot market). This worked well when there was a
> large surplus on the spot-market.
>
> One problem was that it (at least) eliminated incentive for power
> produces to build new power production facilities (in part, much
> easier to get construction loans &/or float bonds for major power
> plant contruction projects if you have long term contracts in your
> hand that demonstrate demand for the new facilities).
>
Short term gain can bring long term loss, of cook your books to please
speculators, season with lack of maintenance, and see a corporate death
spiral like the Penn Central had. Good management is not spur of the
momment or you may find yourself on a dead end siding.
This has all to do with computer security, a requirement for good crypto;
when we see less than inspired planning, dead end programming makes patch
after patch necessary and the result is a shambles no one can effectively
manage or depend on.
--
Suppose California quit sending food back East.
Would Gerorge be ready to barter with energy?
------------------------------
From: "Julian Morrison" <[EMAIL PROTECTED]>
Subject: Re: ECB plus padding instead of CBC?
Date: Wed, 23 May 2001 00:57:49 +0100
"Tom St Denis" <[EMAIL PROTECTED]> wrote:
>> This is what I'm saying: I can't just *assume* a count like I could in
>> TCP; were that the case I could do as you suggest, just ship the data
>> after XOR, zero wastage. My problem is that chunks may be permanently
>> dropped or arrive out of order - perhaps *very* out of order such that
>> a mere incrementing search for the counter would be annoyingly slow. So
>> I must ship the count *with every block*, such that each one can be
>> decrypted in short order as soon as recieved.
>
> I don't see that as a problem. The binary counter will most likely only
> be 32-bits anyways... so four bytes overhead is little ...
Nah, this is for very-long-duration streams so I'd likely need to use the
full 128 bits, packed down. For brief streams a 1-byte count-length,
n-byte count would actually be shorter. It would become equal after 65536
packets and longer after 16777216 of 'em.
> heck you
> could use the # as the counter... (just mult that by the number of
> blocks per packet).
>
> i.e if your packets are 64 blocks long (i.e 1024 bytes) then you mult
> the packet # by 64 and use 64# thru 64# + 63 for the counter number for
> each block.
Probably packets would be very small, maybe even only one block, so as to
slip through everyone's MTU without fragmenting. Although the protocol
will probably try to grow them after it can do path MTU discovery.
--
I like e-gold. Digital currency based 100% in real physical gold.
This link ( http://www.e-gold.com/e-gold.asp?cid=281798 ) takes you to
their site and shows me as the introducer if you open an account.
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: ECB plus padding instead of CBC?
Date: Wed, 23 May 2001 00:02:41 GMT
"Julian Morrison" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> "Tom St Denis" <[EMAIL PROTECTED]> wrote:
>
> >> This is what I'm saying: I can't just *assume* a count like I could in
> >> TCP; were that the case I could do as you suggest, just ship the data
> >> after XOR, zero wastage. My problem is that chunks may be permanently
> >> dropped or arrive out of order - perhaps *very* out of order such that
> >> a mere incrementing search for the counter would be annoyingly slow. So
> >> I must ship the count *with every block*, such that each one can be
> >> decrypted in short order as soon as recieved.
> >
> > I don't see that as a problem. The binary counter will most likely only
> > be 32-bits anyways... so four bytes overhead is little ...
>
> Nah, this is for very-long-duration streams so I'd likely need to use the
> full 128 bits, packed down. For brief streams a 1-byte count-length,
> n-byte count would actually be shorter. It would become equal after 65536
> packets and longer after 16777216 of 'em.
>
> > heck you
> > could use the # as the counter... (just mult that by the number of
> > blocks per packet).
> >
> > i.e if your packets are 64 blocks long (i.e 1024 bytes) then you mult
> > the packet # by 64 and use 64# thru 64# + 63 for the counter number for
> > each block.
>
> Probably packets would be very small, maybe even only one block, so as to
> slip through everyone's MTU without fragmenting. Although the protocol
> will probably try to grow them after it can do path MTU discovery.
The problem with sending a single block at a time is that it's only 16 bytes
(i can't imagine that's at all fast, although I only know about the inet
from a winsock programming aspect) so you need to send the counter with each
block so the space wasted is 100%.
Tom
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: "computationally impossible" and cryptographic hashs
Date: Tue, 22 May 2001 17:49:22 -0600
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Daniel
Graf) wrote:
> Looking at the sci.crypt faq I found in section 7.1 something
> which says:
>
> For some one-way hash functions it's also computationally
> impossible to determine two messages which produce the
> same hash.
>
> Does "computationally impossible" mean literally that such a
> thing cannot happen?
>
No, to be a hash requires some collision or it is just encryption that may
or may not be easy to decrypt. For a good hash, two message may
improbably produce the same hash, but the shorter the hash and longer the
source, more collisions are ineviable.
--
Suppose California quit sending food back East.
Would Gerorge be ready to barter with energy?
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: decorrelated bitsliced cipher
Date: Wed, 23 May 2001 00:31:18 GMT
Wouldn't a decorrelated bitsliced cipher be kinda neat?
The idea is todo a GF mult using word registers movements instead of bit
shifts...
i.e take something like
unsigned long gf_mul(unsigned long a, unsigned long b)
{
unsigned long result = 0;
while (a) {
if (a & 1)
result ^= b;
a >>= 1;
if (b & 0x80000000ul)
b = (b << 1) ^ 0xd59c382dul;
else
b <<= 1;
}
return result;
}
We change the if statements to logical stuff... i.e
result[0..n-1] ^= b[0..n-1] & a[0]
a[0] = a[1], a[1] = a[2], ...
c = b[n-1]
shift b[n-1] = b[n-2], b[n-2] = b[n-3], ...
b[0..n-1] ^= polynomial[0..n-1] & c
The idea is that the GF mult takes the same time regardless of the operand.
We could use this todo GF mults in GF(2^4)/p(x) where p(x) is some
irreducible polynomial mod 2. That way the best differential accross the
sbox would have a prob of 1/15 of occuring.
The security would be based on the wide-trail design but the immunity to
differnetial and linear cryptanalysis would be much much higher since the DP
bound is 1/15 not 1/4 over all keys.
Of course this brings up the idea of using GF(2^8)/p(x) and get a bound of
1/255 but requires larger sboxes... (or no sboxes and use some linear mixing
that doesn't commute with GF(2)).
This cipher could be fast. In fact cool idea. Make a 64-bit block cipher
using eight bytes and doing GF mults in GF(2^8) and some linear transform
that would rotate and shift the bytes around.
What do you guys/gals think?
Tom
------------------------------
Subject: Re: Apology to Cloakware (open letter)
Reply-To: Anne & Lynn Wheeler <[EMAIL PROTECTED]>
From: Anne & Lynn Wheeler <[EMAIL PROTECTED]>
Date: Wed, 23 May 2001 00:31:26 GMT
[EMAIL PROTECTED] (wtshaw) writes:
> This has all to do with computer security, a requirement for good crypto;
> when we see less than inspired planning, dead end programming makes patch
> after patch necessary and the result is a shambles no one can effectively
> manage or depend on.
and/or at least good authentication and information security
random ref ... "The thread between risk management and information security"
http://www.garlic.com/~lynn/aepay3.htm#riskm
http://www.garlic.com/~lynn/aepay3.htm#riskaads
from above, the power thing still pails in comparison to the S&L.
""To date the last reported dollars I have seen for each one of us to
perform our refunding of the banks and S&L's exceeds 100K per
person. Whether you like it or not, in a rather benign interest rate
environment you will pay over 100K in your lifetime of taxpayer
dollars to pay for this bailout. The dollars are so high that they
are carried as an off balance sheet number so as not to capsize the US
budget or cause attention. At one point they exceeded $ 1
trillion. This is what I mean when I say that ALL of the moneys gained
by individuals in the asset appreciation (real estate) of the 70' &
the 80's went in one pocket and the pay-out of the costs for the S&L
industry came out of the other. The result - a zero, if not negative,
sum game. The horrifying part of all of this was that it happened over
a very benign interest rate cycle. Institutions were toast overnight
because of a short term rate spike. Today prevention and anticipation
are the order of the day and the keys to good regulations.""
--
Anne & Lynn Wheeler | [EMAIL PROTECTED] - http://www.garlic.com/~lynn/
------------------------------
From: "Julian Morrison" <[EMAIL PROTECTED]>
Subject: Re: ECB plus padding instead of CBC?
Date: Wed, 23 May 2001 01:34:43 +0100
"Tom St Denis" <[EMAIL PROTECTED]> wrote:
> The problem with sending a single block at a time is that it's only 16
> bytes (i can't imagine that's at all fast, although I only know about
> the inet from a winsock programming aspect)
It wouldn't be fast, but it would be a good way to "slow start" and work
up to the maximum line speed. The packet itself would have other cruft in
there (stream ID, pseudo-port etc) but it could still be guaranteed to
slip untouched though pretty much any MTU.
> so you need to send the
> counter with each block so the space wasted is 100%.
No the space wasted would be one byte for the first message: 00, zero
significant bytes of count - then two bytes: 01 01, one significant byte
of count, count equals 1, three for the 257th: 02 01 FF and so forth.
--
I like e-gold. Digital currency based 100% in real physical gold.
This link ( http://www.e-gold.com/e-gold.asp?cid=281798 ) takes you to
their site and shows me as the introducer if you open an account.
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: ECB plus padding instead of CBC?
Date: Tue, 22 May 2001 17:10:34 -0700
I'm just starting a new sub-thread because I can't find a useful place to
split it.
Your method will work, and may have some desirable properties, because one
can prove than an injection of pure random data into the system cannot be a
bad thing. The only downside is the loss of space, 25% of the space to be
exact. If you're values are going to fit in the 96-bits remaining, then it
is a fairly ideal solution, so it certainly bears examination.
In terms of comparing it to CBC there are certain things that each gives
that the other does not. CBC will work better for strongly ordered
information, where a loss of 1 bit can justify the loss of 2 blocks, and the
overhead of an extra block per stream is acceptable. You scheme offers
reduced overhead if there are fewer than 4 encrypted blocks being sent, and
may offer some very valid advantages to security of your system.
Counter mode is a third option, and I think you've failed to completely
understand how it works (judging from what was said with regards to tom's
suggestion). However if you have to be able to survive the loss of an
unknown number of blocks Counter mode will simply not have any remaining
advantages over your mode or CBC. Given this I think Tom's recommendation of
Counter mode can be safely ignored.
Assuming that you are looking at datagrams of no more than 4 Rijndael blocks
at a time, I believe your mode to be the best for your situation. Since you
expressed that you need to know what the number of the block was you might
instead consider changing the last 32-bits (or however many bits you would
need) to a counter, or you might want to use a portion for an actual length,
whetever. The weak link will not be the encryption, you will not be
sacrificing any measurable amount of strength, and if it saves you space in
this case then it is a suitable solution.
Joe
"Julian Morrison" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Will this work? I have a block cypher, say Rijndael, which has an input of
> 16 bytes. I use the first 12 of those bytes for data and fill the last
> four from /dev/urandom.
>
> The intent is to avoid CBC, so that any 16 byte data chunk can be
> separately decoded despite missing data chunks.
>
> Is this a good approach? What security do I lose from this (if any)?
>
> --
> I like e-gold. Digital currency based 100% in real physical gold.
> This link ( http://www.e-gold.com/e-gold.asp?cid=281798 ) takes you to
> their site and shows me as the introducer if you open an account.
------------------------------
From: [EMAIL PROTECTED] (Jim Turner)
Crossposted-To: alt.privacy,alt.privacy.anon-server
Subject: Re: taking your PC in for repair? WARNING: What will they
Reply-To: [EMAIL PROTECTED]
Date: Wed, 23 May 2001 00:41:49 GMT
On Tue, 22 May 2001 17:16:39 +0200, Martin Schultz
<[EMAIL PROTECTED]> wrote:
>On Mon, 21 May 2001 14:11:41 GMT, [EMAIL PROTECTED] (Eric Lee Green)
>wrote:
>[SNIP]
>>I've been thinking about it myself, but I'm a Unix programmer, not a
>>Windows programmer. Hmm, hold on, I have some spare time right now,
>>maybe I'll go learn the Windows API's... hmm, I don't have a C++ compiler
>>for Windows, I guess I'll look at Cygwin (the Windows port of the
>>GNU C++ compiler)... certainly beats working on the EE_Support_Eliminator
>>(which randomly spams the security newsgroups :-).
>[SNIP
>
>Hmm for windows I would recomment the free borland c++ compiler that
>you can download from www.borland.com (only its not opensource)
>
Two others to look at are LCC, which has a decent IDE, and MINGW,
which is based on GNU but uses standard windows DLLs instead of a unix
emulation DLL. There is also the DEV-C++ package which adds an IDE to
MINGW or Cygwin.
JT
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: truth+integrity=sore losers
Date: Tue, 22 May 2001 18:18:56 -0600
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Tom St Denis) wrote:
> [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY) wrote in message
news:<[EMAIL PROTECTED]>...
> > Don't sweat if you don't get canned or piss people off
> > now and then youd be nothing but a wimp.
>
> Now I am a non-wimp who is unemployed. Somehow my values seem less
> important...
Better that your reach exceeds your grasp.
When things are too easy, Clinton and government, looking for something
hard to grasp, so to speak, can get you into trouble. But if things are
two hard, Bush and goverment, inappropriate action can confirm suspected
limpness, and predict no firm cleasing and resolving climax to current
problems.
In your own situation, do not be overly concerned about the long and short
of it prematurely.
> >
> > Yes even the government thinks one a fool for telling the truth.
> > To keep most jobs you have to learn the unwritten rules. Bosses
> > seldom like to really hear the truth.
>
> This I know first hand.
Keeping quiet while withdrawing makes others question their grasp of the
situation and suspect that your priorities may be more intelligent than
theirs.
--
Suppose California quit sending food back East.
Would Gerorge be ready to barter with energy?
------------------------------
From: "Julian Morrison" <[EMAIL PROTECTED]>
Subject: Re: ECB plus padding instead of CBC?
Date: Wed, 23 May 2001 02:10:12 +0100
"Joseph Ashwood" <[EMAIL PROTECTED]> wrote:
> Counter mode is a third option, and I think you've failed to completely
> understand how it works (judging from what was said with regards to
> tom's suggestion). However if you have to be able to survive the loss of
> an unknown number of blocks Counter mode will simply not have any
> remaining advantages over your mode or CBC. Given this I think Tom's
> recommendation of Counter mode can be safely ignored.
Count mode if I understand it is:
(crypt(block-count as 16 byte bignum)) xor (crypt(16 byte data-chunk))
As a reciever-stateless datagram, that's:
- 1 byte: number of significant bytes in the count (after trimming all
left-side 00 bytes)
- 0..16 bytes: count, as many bytes as the preceding byte indicated.
- 16 bytes: encrypted data chunk
This would be able to survive block loss. It would be computationally much
slower than just cruft-padding each block and ECB-ing (one encrypt,
versus two encrypts, an xor, and a bignum increment)
> Assuming that you are looking at datagrams of no more than 4 Rijndael
> blocks at a time, I believe your mode to be the best for your situation.
Where did "no more than 4 Rijndael blocks" come from?
> Since you expressed that you need to know what the number of the block
> was you might instead consider changing the last 32-bits (or however
> many bits you would need) to a counter,
Actually this built in counter effect is a big plus for the count mode.
But you couldn't turn the cruft-padding into count-padding, that way it
would be predictable and hence useless or at least very much weaker.
--
I like e-gold. Digital currency based 100% in real physical gold.
This link ( http://www.e-gold.com/e-gold.asp?cid=281798 ) takes you to
their site and shows me as the introducer if you open an account.
------------------------------
Subject: Re: ON-topic - UK crime statistics (was Re: Best, Strongest Algorithm)
From: [EMAIL PROTECTED]
Date: 22 May 2001 21:12:41 -0400
[EMAIL PROTECTED] (Richard Herring) writes:
> Douglas A. Gwyn ([EMAIL PROTECTED]) wrote:
>
>> It's the most direct explanation for the observed correlations,
>
> Granted; but correlation isn't causation.
Granted, but it's the right place to look.
>> and is supported by interviews with professional criminals.
>
> Who naturally always tell the truth.
Right. Actually, criminals spread the lie that guns are a
deterrent because they really WANT their victims to be armed,
because...because...okay, I give. Why?
Len.
--
We select our marketable equity securities in much the same way we would
evaluate a business for acquisition in its entirety.
-- Warren Buffett, 1977
------------------------------
From: "Scott Fluhrer" <[EMAIL PROTECTED]>
Subject: Re: ECB plus padding instead of CBC?
Date: Tue, 22 May 2001 18:35:46 -0700
Julian Morrison <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> "Joseph Ashwood" <[EMAIL PROTECTED]> wrote:
>
> > Counter mode is a third option, and I think you've failed to completely
> > understand how it works (judging from what was said with regards to
> > tom's suggestion). However if you have to be able to survive the loss of
> > an unknown number of blocks Counter mode will simply not have any
> > remaining advantages over your mode or CBC. Given this I think Tom's
> > recommendation of Counter mode can be safely ignored.
>
> Count mode if I understand it is:
>
> (crypt(block-count as 16 byte bignum)) xor (crypt(16 byte data-chunk))
>
> As a reciever-stateless datagram, that's:
>
> - 1 byte: number of significant bytes in the count (after trimming all
> left-side 00 bytes)
>
> - 0..16 bytes: count, as many bytes as the preceding byte indicated.
>
> - 16 bytes: encrypted data chunk
>
> This would be able to survive block loss. It would be computationally much
> slower than just cruft-padding each block and ECB-ing (one encrypt,
> versus two encrypts, an xor, and a bignum increment)
>
> > Assuming that you are looking at datagrams of no more than 4 Rijndael
> > blocks at a time, I believe your mode to be the best for your situation.
>
> Where did "no more than 4 Rijndael blocks" come from?
>
> > Since you expressed that you need to know what the number of the block
> > was you might instead consider changing the last 32-bits (or however
> > many bits you would need) to a counter,
>
> Actually this built in counter effect is a big plus for the count mode.
> But you couldn't turn the cruft-padding into count-padding, that way it
> would be predictable and hence useless or at least very much weaker.
I'm not quite sure what problem are you intend to solve. You say that this
is to protect an unreliable stream of packets (essentially the same problem
that IPSec solves). However, in the unreliable packet based network
protocols I know about, you don't have to worry about individual blocks
within a packet getting through -- either the entire packet gets through, or
none of it does. If this is the case in the protocol you're protecting, you
really don't need an individual counter for each block -- one per packet
should be sufficient. The counter would be implicitly incremented for each
block of the packet that is encrypted. This does mean that a partial packet
may not be properly decrypted (say, if the counter was missing), but then
again, partial packets should fail the authentication mechanism (you are
using a MAC or other authentication mechanism, aren't you???), and so you
wouldn't accept them anyways.
--
poncho
------------------------------
From: "Julian Morrison" <[EMAIL PROTECTED]>
Subject: Re: ECB plus padding instead of CBC?
Date: Wed, 23 May 2001 03:03:40 +0100
"Scott Fluhrer" <[EMAIL PROTECTED]> wrote:
> I'm not quite sure what problem are you intend to solve. You say that
> this is to protect an unreliable stream of packets (essentially the same
> problem that IPSec solves).
Yeah, at this level they're rather similar; the difference (at this low
level) is that this is a protocol encoded inside UDP and so requires no
special kernel assistance. There are more significant higher level
differences though. They just aren't topical to this group.
> However, in the unreliable packet based network protocols I know about,
> you don't have to worry about individual blocks within a packet getting
> through -- either the entire packet gets through, or none of it does. If
> this is the case in the protocol you're protecting, you really don't
> need an individual counter for each block -- one per packet should be
> sufficient.
Never meant to say otherwise - except in the context that the first packet
through is likely to only *be* one block, so as to be short and slip
through all the MTUs.
> The counter would be implicitly incremented for each block of the packet
> that is encrypted. This does mean that a partial packet may not be
> properly decrypted (say, if the counter was missing), but then again,
> partial packets should fail the authentication mechanism (you are using
> a MAC or other authentication mechanism, aren't you???), and so you
> wouldn't accept them anyways.
Yup there will be a MAC. I might try other sneakiness too adaptively if the
packets start getting scrambled - for example interlacing XORs between
bytes as an error correction mechanism.
--
I like e-gold. Digital currency based 100% in real physical gold.
This link ( http://www.e-gold.com/e-gold.asp?cid=281798 ) takes you to
their site and shows me as the introducer if you open an account.
------------------------------
** 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 by posting to sci.crypt.
End of Cryptography-Digest Digest
******************************
