Cryptography-Digest Digest #107, Volume #11 Sat, 12 Feb 00 16:13:02 EST
Contents:
Re: YACM - Yet Another Chaining Mode ("Scott Fluhrer")
Re: Message to SCOTT19U.ZIP_GUY (Tim Tyler)
Re: Compression cannot prevent plaintext recognition (was Re: is signing a
signature with RSA risky?) (Tim Tyler)
Re: Block chaining (Tim Tyler)
Re: Period of cycles in OFB mode (David Wagner)
Re: Period of cycles in OFB mode (David Wagner)
Re: Block chaining (David Wagner)
Re: Latin Squares (was Re: Reversibly combining two bytes?) (Tim Tyler)
Re: Period of cycles in OFB mode (Tim Tyler)
Re: Message to SCOTT19U.ZIP_GUY ([EMAIL PROTECTED])
Re: Persistent vs Non-Per DH for Voice ([EMAIL PROTECTED])
Re: Period of cycles in OFB mode (Tim Tyler)
Re: Twofish vs. Blowfish (Michael Sierchio)
Re: Court cases on DVD hacking is a problem for all of us ([EMAIL PROTECTED])
Re: Have you watched the movie "PI" (actually a mathematical symbol PI) of a
mathematical genius .. breaking the code .. ("Joe Cool")
Re: Does the NSA have ALL Possible PGP keys? (Jim)
Re: Period of cycles in OFB mode (Tim Tyler)
Re: Period of cycles in OFB mode (David Wagner)
Freeware Uploads (Erick Stevenson)
Re: Guaranteed Public Key Exchanges (lcs Mixmaster Remailer)
Re: Period of cycles in OFB mode (David Wagner)
Re: Court cases on DVD hacking is a problem for all of us (David Wagner)
Re: Message to SCOTT19U.ZIP_GUY (Tim Tyler)
Re: RFC: Reconstruction of XORd data (Tim Tyler)
Re: Freeware Uploads (Ralph Hilton)
----------------------------------------------------------------------------
From: "Scott Fluhrer" <[EMAIL PROTECTED]>
Subject: Re: YACM - Yet Another Chaining Mode
Date: Sat, 12 Feb 2000 10:23:05 -0800
Sander Vesik <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Yet Another Chaning Mode - CfBC
>
> Probably mainly of interest to anybody collecting various non-defective
> chaining modes. It 'hides' plaintext structure somewhat better than
> CBC, while requiring more work on encryptionm and decryption.
>
> Let:
> P_n - n-th plaintext to be enciphered
> C_n - n-th ciphertext
> IV_n - n-th 'derivate' of the initalisation vector
> E_k - encryption with key k
> D_k - decryption with key k
>
> Encryption:
> IV_0=E_k(IV)
> IV_n=E_k(IV_(n-1))
> C_n=E_k(P_n ^ IV_n)
>
> Decryption:
> IV_0=E_k(IV)
> IV_n=E_k(IV_(n-1))
> P_n=D_k(C_n) ^ IV_n
>
> Propeties:
>
> DRAWBACK - divulges cyphertext at double rate.
Do you mean that it requires two encryptions per block?
>
> 1) hides plaintext structure well
> 2) blocks are chained, blocks cannot be inserted by a 3rd party in the
middle
> of the stream even if that party knows the key
... unless the actacker can adjust all the following blocks accordingly, of
course
> 3) in hardware can be implemented in parrallel, requiring about twice the
> resources for no speed-down, in software runs at half the speed of an
> interleaved implemetation
> 4) adds an additional tiny amount of security above just plaintext
structure
> hiding.
This is just OFB followed by ECB (so it's not really all that new). Someone
(Shamir?) went through all the possible 2 and 3 concatinations of the
various
chaining modes, and gave strength estimates -- you may want to look up that
paper (sorry I can't remember more details, I'm sure someone around here
will)
BTW: this scheme doesn't get much extra strength if you let the OFB stage
have separate keys from the ECB stage, a choosen-ciphertext attack allows
you to break it with a constant work factor of what it takes to break the
underlying block cipher. If you care, write me for details.
--
poncho
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Message to SCOTT19U.ZIP_GUY
Reply-To: [EMAIL PROTECTED]
Date: Sat, 12 Feb 2000 18:06:40 GMT
Tom St Denis <[EMAIL PROTECTED]> wrote:
: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY) wrote:
:> They could be the same compressors as long as they
:> are one-one compressors. And even better if they can reverse the
:> byte order of the file.
: Why?
I think David's already explained both these points a number of times.
: Ok buckeroo, if the underlying cipher [such as AES] is so weak [in
: your point of view] that a kid with an atari 2600 can 'break' it in 20
: seconds, then adding a million passes will only make it a million times
: harder. I think I have said this before.
Encrypting something twice does not double the time to break. Speaking
*very* roughly, if anything, it squares it.
Following this logic, if the time to break with an atari 2600 is "s"
seconds, a million multiple encryptions will increase the time to
s^1,000,000 - probably a stupendous number.
By this point the effective key size will be gigantic compared to the size
of the message - and will probably decrypt every possible plaintext, like
an OTP.
Perhaps you mean something else. I've tried - but have not found any way
to parse your objection so that it makes the slightest sense :-(
--
__________
|im |yler The Mandala Centre http://www.mandala.co.uk/ [EMAIL PROTECTED]
This fortune invokes Satan, Lord of Evil.
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Compression cannot prevent plaintext recognition (was Re: is signing a
signature with RSA risky?)
Reply-To: [EMAIL PROTECTED]
Date: Sat, 12 Feb 2000 18:21:49 GMT
Anton Stiglic <[EMAIL PROTECTED]> wrote:
: Tim Tyler wrote:
:> Anton Stiglic <[EMAIL PROTECTED]> wrote:
[can compression defeat brute force?]
:> What if all x (such that x = U(f) for some f) have the headers the
:> attacker is looking for?
:>
:> I.e. what if the information about message content available to the
:> analyst is the same as the information about message content which was
:> available to the author of the compressor - and the latter designed a
:> scheme to correctly exploit it?
: Ah well that would be great! I'd want to be the first one to use it!
Good.
: But this is no longer a problem about compression functions, this turns out
: to be a problem of picking a function that only works on a specified subset
: of a larger set, this is sounding to be more like an NP-complete problem??
I called it a compressor, since it normally acts to reversibly transform
a larger message into a smaller one, when the message is from some target
set.
Building such a compressor is relatively simple for some types of traffic
- and absurdly difficult for others.
--
__________
|im |yler The Mandala Centre http://www.mandala.co.uk/ [EMAIL PROTECTED]
A hangover is the wrath of grapes.
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Block chaining
Reply-To: [EMAIL PROTECTED]
Date: Sat, 12 Feb 2000 18:27:46 GMT
zapzing wrote:
: You know I , personally, have
: always wondered why people bother to do
: block chaining at all. If you had a
: good block size, say 256 bits, you
: could make half the block be random
: numbers and half be plaintext. [...]
: Also you could use parallel processing to
: encrypt the message, something to think
: about for the future.
Note that you can use parallel processing with some chaining modes anyway.
OFB mode even allows you to do the bulk of the encryption while the
message is being entered.
--
__________
|im |yler The Mandala Centre http://www.mandala.co.uk/ [EMAIL PROTECTED]
Black holes are where God divided by zero.
------------------------------
From: [EMAIL PROTECTED] (David Wagner)
Subject: Re: Period of cycles in OFB mode
Date: 12 Feb 2000 10:40:06 -0800
In article <[EMAIL PROTECTED]>, Terry Ritter <[EMAIL PROTECTED]> wrote:
> Clearly, an arithmetic count sequence is very regular: The lsb
> changes every time; the next higher bit half as often, and then only
> when the lsb changes to zero. That is a lot of statistical
> bit-position information which may be amenable to frequency and phase
> detection techniques.
>
> Now, if the block cipher is perfect in practice, all this should not
> be a problem. But practical block ciphers may not wrap one edge to
> the other, and bit-diffusion from an edge of the block may not be as
> good as we would expect elsewhere. The extremely strong counter
> signal may thus expose cipher problems which would otherwise be
> hidden.
Good point.
For instance, if there are good differential attacks, counter
mode is skating on thin ice.
> It seems to me that this is yet another way of asking for trouble,
> especially since a fairly easy alternative exists: Simply use a
> polynomial counter rather than arithmetic counting.
Do you mean using a LFSR to drive the block cipher?
That sounds like a good idea, if it was what you meant.
------------------------------
From: [EMAIL PROTECTED] (David Wagner)
Subject: Re: Period of cycles in OFB mode
Date: 12 Feb 2000 10:42:56 -0800
In article <[EMAIL PROTECTED]>,
Paul Crowley <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] (David Wagner) writes:
> > > It also has the nice property that you can
> > > parallelize it for higher speed.
> >
> > Yup. From my point of view, this is the big win of counter mode.
>
> But if you're going to go this far, why not go the whole hog and use a
> native stream cipher like Panama?
I guess the only reason is to retain the existing analysis on
ciphers with a long history, e.g., DES and Triple-DES.
But I do agree, and have felt for some time, that in principle
a stream cipher ought to be able to provide substantially better
performance (particularly if used in a mode with no cipher- or
plaintext feedback). The only problem is that, today, the open
community seems to have a much better understanding of how to
build secure block ciphers than it does for stream ciphers. I'm
not sure why or how that came to be, but there you have it.
------------------------------
From: [EMAIL PROTECTED] (David Wagner)
Subject: Re: Block chaining
Date: 12 Feb 2000 10:48:45 -0800
In article <[EMAIL PROTECTED]>, Tim Tyler <[EMAIL PROTECTED]> wrote:
> Note that you can use parallel processing with some chaining modes anyway.
Apart from counter mode, which ones let you do parallel processing
in the encryption direction? Not OFB, not CBC, not CFB. Which ones
did I forget?
> OFB mode even allows you to do the bulk of the encryption while the
> message is being entered.
Yeah, but that's different from parallelism. OFB lets you use
pre-computation, but it is inherently sequential and does not allow
parallel processing.
(The only way to get parallelism with OFB mode -- and most of the
other modes -- is to simultaneously process multiple independent messages.)
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Latin Squares (was Re: Reversibly combining two bytes?)
Reply-To: [EMAIL PROTECTED]
Date: Sat, 12 Feb 2000 18:42:53 GMT
Michael Wojcik <[EMAIL PROTECTED]> wrote:
: The relatively small number of order-256 squares that are PRT squares
: (the "PRT penalty", so to speak) may not be an issue in practice,
: since there are still around 10^1520 or 2^5051 PRT squares of order
: 256. Other weaknesses may certainly exist, but at least that's a
: large enough space to make searching prohibitive. [...]
If there /are/ significant weaknesses, they are likely to be caused by
"structure" in the table (resulting in spurious conserved quantities and
the like) - rather than a lack of possible tables - IMO.
--
__________
|im |yler The Mandala Centre http://www.mandala.co.uk/ [EMAIL PROTECTED]
As scarce as the truth is, the supply has always been in excess of demand.
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Period of cycles in OFB mode
Reply-To: [EMAIL PROTECTED]
Date: Sat, 12 Feb 2000 18:58:07 GMT
David Wagner <[EMAIL PROTECTED]> wrote:
: John Savard <[EMAIL PROTECTED]> wrote:
:> However, I would have thought the
:> Birthday Paradox would make it even lower than 2^(m-1).
: Nope. The Birthday Paradox doesn't apply here.
: (It would only apply if DES were a pseudorandom function; but DES
: has extra structure -- it is a permutation (bijective).)
: If we replace DES with a permutation chosen uniformly at random,
: there are classical results which say the average cycle length (if you
: start at a random place) is -- if I remember correctly -- (2^n + 1)/2;
This is all exactly correct.
For those who asked why this is true, there's a sketch of the proof at:
http://www.alife.co.uk/random/reversibility/#random
--
__________
|im |yler The Mandala Centre http://www.mandala.co.uk/ [EMAIL PROTECTED]
Save the whales. Collect the whole set.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Message to SCOTT19U.ZIP_GUY
Date: Sat, 12 Feb 2000 18:56:06 GMT
> >
> >Then to decrypt:
> >Decrypt with Cipher C (kC)
> >Decompress with Compressor C
> >Decrypt with Cipher B
> >Decompress with Compressor B
> >Decrypt with Cipher A
> >Decompress with Cipher A
> >
> >
> >Hopefully you are back where you started ??? Right???
> That would be nice since that is what is hoped for.
> >
> >
> >And what about the Compressors A, B,C
> >
> >Is it the same Compressor?
> They could be the same compressors as long as they
> are one-one compressors. And even better if they can reverse the
> byte order of the file.
> >
DOES your Compressor have a switch ...same module does
Compression-Decompression????
> Better yet learn how to do "wrapped PCBC" in which case just compress
> intially and do at least 3 passes of the "wrapped PCBC chainning
useing
> your choice of AES block ciphers with independent keys.
What is "wrapped PCBC" How does that work???
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Persistent vs Non-Per DH for Voice
Date: Sat, 12 Feb 2000 19:02:01 GMT
> Not widely, but it's used in some secure phones. Doing a MITM with RF
> in real time is pretty hard.
>
Which secure phones are you refering to?
Not many that use DH and symetric ciphers.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Period of cycles in OFB mode
Reply-To: [EMAIL PROTECTED]
Date: Sat, 12 Feb 2000 19:02:54 GMT
David Wagner <[EMAIL PROTECTED]> wrote:
: Paul Koning <[EMAIL PROTECTED]> wrote:
:> [Counter mode] has the nice property that you can parallelize it [...]
: Yup. From my point of view, this is the big win of counter mode.
You appear to be best known as an analyst, though.
Consequently, I'm not sure how to take this ;-)
--
__________
|im |yler The Mandala Centre http://www.mandala.co.uk/ [EMAIL PROTECTED]
Hey! That's not ANSI 9660 - that's DREADFUL.DOS!
------------------------------
From: Michael Sierchio <[EMAIL PROTECTED]>
Subject: Re: Twofish vs. Blowfish
Date: Sat, 12 Feb 2000 11:33:09 -0800
"Douglas A. Gwyn" wrote:
> You have no right to make such accusations without evidence.
> It is easy enough to talk to the developers of said software;
> have you done that? What did they say? Why would we believe
> your wild accusations over the word of those developers?
The person you are responding to is at least one burrito short
of a combination platter. I tend to treat anything he writes as
the sort of remark that is expected after a baked bean dinner.
Aside from being illiterate, and an assassin of the English language,
he is selling a homeopathic dilution of snake oil, a tincture of brown
soil through which a snake may or may not at one time have slithered.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Court cases on DVD hacking is a problem for all of us
Date: Sat, 12 Feb 2000 19:25:22 GMT
In article <[EMAIL PROTECTED]>,
Alan Braggins <[EMAIL PROTECTED]> wrote:
> This scenario might be a legitimate concern for the copyright holders.
> Or they might be bloodsucking leeches attempting to artificially boost
> profits by differential regional pricing and blocking fair use of
> legally purchased DVDs. (Or they might have a legitimate concern and
> be overreacting by attempting to block fair use of purchased DVDs).
Or perhaps they're trying to protect a mechanism they intend to use in
a future (undisclosed) agenda. An unhacked CSS would be of major
importance to a system that only permitted 'pay per view' DVD's don't
you think...?
It would simply be a matter of taking region control one step further.
Regards all.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: "Joe Cool" <[EMAIL PROTECTED]>
Crossposted-To:
alt.politics.org.cia,soc.culture.russian,soc.culture.israel,alt.math,alt.2600
Subject: Re: Have you watched the movie "PI" (actually a mathematical symbol PI) of a
mathematical genius .. breaking the code ..
Date: Sat, 12 Feb 2000 01:12:37 -0500
Didn't they drill holes in their heads in scanners, too? is this on
topic?
( DUH, YEAH, THINK SO?)
SINCERELY........THEM. (were watching ya know)
------------------------------
From: [EMAIL PROTECTED] (Jim)
Subject: Re: Does the NSA have ALL Possible PGP keys?
Date: Sat, 12 Feb 2000 19:49:38 GMT
Reply-To: [EMAIL PROTECTED]
On 12 Feb 2000 16:26:20 GMT, Sander Vesik <[EMAIL PROTECTED]> wrote:
>Douglas A. Gwyn <[EMAIL PROTECTED]> wrote:
>> Highdesertman wrote:
>>> I'm sure somebody will correct me if I'm wrong, but isn't that one of
>>> the mandates that the NSA is tasked with in the first place?
>
>> Which? You posted a lot of stuff.
>
>> You can read about NSA's mission on their Web page. Basically,
>> it is to protect US government communications and to obtain
>> intelligence by analyzing signals of foreign governments.
>> They definitely are not tasked with listening to every telephone
>> conversation.
>
>Hah. So how do the known cases of business intelligence (against
>companies of allied nations) as outlined in the various EU documents
>qualify?
The French, the Chinese, the Russians, the Israelis are all doing
just that. Hardly surprising that the NSA is as well.
Hopefully they all cancel each other out.
(NSA is not permitted to monitor internal US communications, at least
from within the US. Everyone else if fair game).
--
Jim,
nordland at lineone.net
amadeus at netcomuk.co.uk
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Period of cycles in OFB mode
Reply-To: [EMAIL PROTECTED]
Date: Sat, 12 Feb 2000 19:59:37 GMT
David Wagner <[EMAIL PROTECTED]> wrote:
: Terry Ritter <[EMAIL PROTECTED]> wrote:
:> It seems to me that this is yet another way of asking for trouble,
:> especially since a fairly easy alternative exists: Simply use a
:> polynomial counter rather than arithmetic counting.
: Do you mean using a LFSR to drive the block cipher?
: That sounds like a good idea, if it was what you meant.
Use of an LFSR would lose the ability to parallelise the process properly.
I think this can be retained - while maintaining a guaranteed large
period, and keeping at bay strong bitwise relationships between the
source of consecutive blocks.
--
__________
|im |yler The Mandala Centre http://www.mandala.co.uk/ [EMAIL PROTECTED]
Atheism is a non-prophet organisation.
------------------------------
From: [EMAIL PROTECTED] (David Wagner)
Subject: Re: Period of cycles in OFB mode
Date: 12 Feb 2000 12:14:21 -0800
In article <[EMAIL PROTECTED]>, Tim Tyler <[EMAIL PROTECTED]> wrote:
> Use of an LFSR would lose the ability to parallelise the process properly.
Umm... I forgot about that.
Maybe there are ways around it, though. Fast-forwarding through
a LFSR just amounts to an exponentiate-and-multiply in GF(2^n) at
setup time, so I'm guessing that should still be fast enough to
not cause noticeable overhead.
But I suppose the only way to be sure is to implement and measure.
------------------------------
From: Erick Stevenson <[EMAIL PROTECTED]>
Subject: Freeware Uploads
Date: Sat, 12 Feb 2000 20:19:25 GMT
Hello:
Can anyone tell me how I can upload a freeware encryption system (file,
email, ftp, messenging) without a domain site of my own?
Thanks for your help.
------------------------------
Date: 12 Feb 2000 20:20:02 -0000
From: lcs Mixmaster Remailer <[EMAIL PROTECTED]>
Subject: Re: Guaranteed Public Key Exchanges
There is an idea from Ron Rivest, called the Interlock Protocol. It
was discussed online several years ago and may have gone something
like this:
Alice and Bob communicate using a pair of public keys. Embedded
openly in each message is information about the fingerprint of the key
each is encrypting to. A MITM must have forced each one to use a
different public key, so he has to alter each message.
To make this more difficult, before sending every message, Alice writes
it and then sends a hash of the message she is about to send. Because the
MITM is going to alter the message, her hash will not work on the altered
message. The MITM has to intercept her hash and send a different one.
But since he doesn't know what she is about to say, he can't come up with
a message that is like hers but just has the key fingerprint changed.
He would have to make a message up out of whole cloth. He is no longer
really a MITM, he is simply a guy having two separate conversations with
Alice and Bob, neither conversation having much relation to the other.
Now the MITM has a countermeasure, which is to delay sending the hash
until Alice has sent her second message, the one which was hashed. Now
he can make his alteration to her message, send the resulting hash,
delay, and then send the altered second message.
Alice and Bob can try to defeat this by having Bob wait until Alice
sends her hash, and then send some kind of acknowledgement, like, "OK,
I got your hash, go ahead and send the message." But if acknowledgement
messages are simple like this, the MITM can anticipate this and produce
a fake one from Bob. He holds the hash message, gives Alice a fake
acknowledgement message, and gets the real message from Alice, then
sends the altered hash and message to Bob.
The final solution is the interlock or ping-pong protocol. Alice and
Bob have two somewhat independent conversations, interlocked. They both
send a first message, then they both send a second message where they
respond to the previous first message and include new information, then
they both send a third message, etc. Each message "crosses in the mail".
Sometimes in the olden days you saw this with lovers communicating by
mail, so sad to be apart that they sent new messages every day.
With this approach, each message exchange is preceded by a hash exchange.
The "acknowledgement message" above is the actual message sent by Alice
and Bob in that phase. So there are two parts to each message exchange:
phase 1, send the hash; phase 2, wait to receive the hash from the other,
and send the message.
Now the MITM can no longer hold up the hash and forge an acknowledgement,
because the ack messages are the hash messages. Since he doesn't know
what Alice and Bob are going to say, he is once again forced to make
up their messages from whole cloth, and the two sides will likely get
badly out of sync with each other.
This does not totally defeat the MITM, as he is still pretending to each
side to be the other. But he is not successful in monitoring a conversation
that the two sides have with each other. It requires him to take a much
more active role, and the conversation will not end up being the same as
if he had not intervened. It at least makes his job more difficult.
------------------------------
From: [EMAIL PROTECTED] (David Wagner)
Subject: Re: Period of cycles in OFB mode
Date: 12 Feb 2000 12:20:08 -0800
In article <[EMAIL PROTECTED]>, Tim Tyler <[EMAIL PROTECTED]> wrote:
> You appear to be best known as an analyst, though.
>
> Consequently, I'm not sure how to take this ;-)
Take it the same way you ought to be taking everything else anyone says,
namely, as a starting point for discussion, not as gospel truth handed
down from the heavens.
Don't believe technical claims just because of who said it: use your
critical thinking skills, assess independently, and by all means complain
when the logic seems bogus!
------------------------------
From: [EMAIL PROTECTED] (David Wagner)
Subject: Re: Court cases on DVD hacking is a problem for all of us
Date: 12 Feb 2000 12:23:21 -0800
In article <884c30$fb1$[EMAIL PROTECTED]>, <[EMAIL PROTECTED]> wrote:
> Or perhaps they're trying to protect a mechanism they intend to use in
> a future (undisclosed) agenda. An unhacked CSS would be of major
> importance to a system that only permitted 'pay per view' DVD's don't
> you think...?
It's a fascinating idea, but I must admit I haven't yet been able to
imagine how a secure CSS replacement would make pay-per-view style
systems secure. Probably I'm being dense. Could you elaborate
a little? What threat would it defend against? How would it help
prevent bit-for-bit copying?
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Message to SCOTT19U.ZIP_GUY
Reply-To: [EMAIL PROTECTED]
Date: Sat, 12 Feb 2000 20:24:44 GMT
[EMAIL PROTECTED] wrote:
:> >And what about the Compressors A, B,C
:> >
:> >Is it the same Compressor?
:>
:> They could be the same compressors as long as they
:> are one-one compressors. And even better if they can reverse the
:> byte order of the file.
: DOES your Compressor have a switch ...same module does
: Compression-Decompression????
I don't think so.
:> Better yet learn how to do "wrapped PCBC" in which case just compress
:> intially and do at least 3 passes of the "wrapped PCBC chainning
:> useing your choice of AES block ciphers with independent keys.
: What is "wrapped PCBC" How does that work???
PCBC stands for "Plain & Cipher Block Chaining".
The "&" is sometimes omitted.
To quote from http://www.mit.edu:8008/menelaus.mit.edu/kprot/23
``PCBC was intended to propagate ciphertext changes indefinitely in the
resulting plaintext. Each block of plaintext to be enciphered using
CBC is first xored with the preceding plaintext block. On decryption,
after the block has been decrypted using CBC it is then xored again
with the preceding plaintext block. The idea is that a change in the
ciphertext will cause the resulting plaintext for the modified block
to be garbage, and that the garbage would propagate to later plaintext
blocks since each successive block would be xored with the incorrect
plaintext for the preceding block.''
--
__________
|im |yler The Mandala Centre http://www.mandala.co.uk/ [EMAIL PROTECTED]
Ignore previous tagline.
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: RFC: Reconstruction of XORd data
Reply-To: [EMAIL PROTECTED]
Date: Sat, 12 Feb 2000 20:36:54 GMT
Rick Braddam <[EMAIL PROTECTED]> wrote:
: What do you think of this, David? I came up with it to spread out the
: bit changes in ASCII text. [...]
: The description is in terms of x86 assembler, because the carry bit (cy)
: can be used to hold bits shifted out of a source register(src1, src2),
: and supply bits shifted into a destination register (dest1, dest2).
I'd have thought that readability and comprehensibility are important to
anyone evaluating an algorithm. x86 assembler is a curious choice in
these terms, IMO.
--
__________
|im |yler The Mandala Centre http://www.mandala.co.uk/ [EMAIL PROTECTED]
Taxes are not levied for the benefit of the taxed.
------------------------------
From: Ralph Hilton <[EMAIL PROTECTED]>
Subject: Re: Freeware Uploads
Date: Sat, 12 Feb 2000 21:44:40 +0100
Reply-To: [EMAIL PROTECTED]
On Sat, 12 Feb 2000 20:19:25 GMT, Erick Stevenson <[EMAIL PROTECTED]> wrote:
>Hello:
>
>Can anyone tell me how I can upload a freeware encryption system (file,
>email, ftp, messenging) without a domain site of my own?
http://www.tripod.lycos.com/ would host it free up to 11Mb.
------------------------------
** 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
******************************
