Cryptography-Digest Digest #840, Volume #8 Mon, 4 Jan 99 20:13:04 EST
Contents:
Re: Opinions on S/MIME (Brad Aisa)
Re: DS5002FP Secure Micro Crypted Buses (Ken Keys)
Re: Encryption questions..... ("Sam Simpson")
Re: Help: a logical difficulty (KRamsay)
Talk at UMBC - "How to run a crypto company" by Meir Zorea ("Dr. Alan Sherman")
Fwd: Meganet's Deterministic Polyomial Time Primality Test (Paul Rubin)
Re: CD Rom Encryption (David R Brooks)
Re: Help: a logical difficulty (Jonah Thomas)
Re: CTS a la Schneier, Rivest (Frank Gifford)
Re: CTS a la Schneier, Rivest (Jon Becker)
----------------------------------------------------------------------------
From: Brad Aisa <[EMAIL PROTECTED]>
Subject: Re: Opinions on S/MIME
Date: Tue, 29 Dec 1998 17:39:28 -0500
This is a cryptographically signed message in MIME format.
==============ms5880AF4A87242567B235E69C
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sam,
Thanks for your detailed and instructive response. The thing that most
disturbed me (apart from the 1024-bit key limit), was this:
Sam Simpson wrote:
> One of the S/Mime standard documents [PKIX98] describes a "feature" of
> S/Mime called "Proof of Possession of Private Key". This is a mechanism
> whereby end users private keys are deposited with the CA when certification
> is requested. This is a very worrying inclusion and makes the
> implementation of mandatory key escrow a trivial matter. The PGP draft
> standard contains no such references to key recovery technology.
Does this mean that when I obtained a certificate from Thawte, that my
*private key* was transmitted to them???
Please tell me it ain't so...
--
Brad Aisa
[EMAIL PROTECTED]
S/MIME signed using freemail ID from www.thawte.com
"Laissez faire."
==============ms5880AF4A87242567B235E69C
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature
MIIIWQYJKoZIhvcNAQcCoIIISjCCCEYCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC
BgYwggLFMIICLqADAgECAgJc1zANBgkqhkiG9w0BAQQFADCBuTELMAkGA1UEBhMCWkExFTAT
BgNVBAgTDFdlc3Rlcm4gQ2FwZTEUMBIGA1UEBxMLRHVyYmFudmlsbGUxGjAYBgNVBAoTEVRo
YXd0ZSBDb25zdWx0aW5nMSkwJwYDVQQLEyBUaGF3dGUgUEYgUlNBIElLIDE5OTguOS4xNiAx
Nzo1NTE2MDQGA1UEAxMtVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIFJTQSBJc3N1ZXIgMTk5
OC45LjE2MB4XDTk4MTIyNTIyNDk0M1oXDTk5MTIyNTIyNDk0M1owQDEfMB0GA1UEAxMWVGhh
d3RlIEZyZWVtYWlsIE1lbWJlcjEdMBsGCSqGSIb3DQEJARYOYmFpc2FAaXN0YXIuY2EwgZ8w
DQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALALier07xXR24pdrjirnceHsJyUOXwz/FUSMvJq
2rlWW8axn95Q/TQxP6g23b8vnWWmwJaF5Z9tDoXkHvwcdn/QEADlTSLZA59S9/huPjT5Busm
9yJNbSScatnmlSN+9yG+OSoTUzxjm+X1il0LkxQHVmJrLjh0etMfO5xs8MRLAgMBAAGjVDBS
MBEGCWCGSAGG+EIBAQQEAwIFoDAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAfBgNV
HSMEGDAWgBT+PmCca4wPsNgzxsrGHliwcTi14DANBgkqhkiG9w0BAQQFAAOBgQAcN95/wDDZ
vp2s5SA4GEw7zPwJKKEJbmJj3SH0dzXgHUbpinujkcrJ9bnJCBQ+EHDxW1gIRkpJT5rV9Azp
S5zXWUY0WPbjl564TjoyIFjefGKu6+GWQZ6jQ7DL9DNyeocSFjYCCyqFypAEcZiRL0x6HzfF
gSIIj5+9dEu+Xz0yWjCCAzkwggKioAMCAQICAQowDQYJKoZIhvcNAQEEBQAwgdExCzAJBgNV
BAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgG
A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2Vydmlj
ZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkG
CSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw05ODA5MTYxNzU1
MzRaFw0wMDA5MTUxNzU1MzRaMIG5MQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBD
YXBlMRQwEgYDVQQHEwtEdXJiYW52aWxsZTEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcx
KTAnBgNVBAsTIFRoYXd0ZSBQRiBSU0EgSUsgMTk5OC45LjE2IDE3OjU1MTYwNAYDVQQDEy1U
aGF3dGUgUGVyc29uYWwgRnJlZW1haWwgUlNBIElzc3VlciAxOTk4LjkuMTYwgZ8wDQYJKoZI
hvcNAQEBBQADgY0AMIGJAoGBAMSl5dTU0F8IAu4HIX0kv6trjh7rIAcCFYRrj9CTJB8bne5o
srksT+mTZxcQFx6h+UNBI7kwqnaXu/Pn/YHAtTGL9qZQJlTylSjrGaQelx6w4ribwQSaMtA8
CWxP5DVP8Ha/ABMDT0UIYPP8tNCQAYoSyZy6f1LqKpM1Njw85DUvAgMBAAGjNzA1MBIGA1Ud
EwEB/wQIMAYBAf8CAQAwHwYDVR0jBBgwFoAUcknCczTGVfQLdnKBfnf0h+fGsg4wDQYJKoZI
hvcNAQEEBQADgYEALMeCHwFDPgeP7mlcqWSC+MCWrZMry5tQ10CagcK6pnadPJVA3FXB4VWC
easKKabVDOFXKD6P+bvV3w2TWKpbLYuPM+TdWBU1dnIVKb1C9FqSC3dfnSfbmi1OG4IGjtKN
VruV3tsMZQXelZ4C3VMXvr78a8MaInoUK2G9wp9eeloxggIbMIICFwIBATCBwDCBuTELMAkG
A1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTEUMBIGA1UEBxMLRHVyYmFudmlsbGUx
GjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSkwJwYDVQQLEyBUaGF3dGUgUEYgUlNBIElL
IDE5OTguOS4xNiAxNzo1NTE2MDQGA1UEAxMtVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIFJT
QSBJc3N1ZXIgMTk5OC45LjE2AgJc1zAJBgUrDgMCGgUAoIGxMBgGCSqGSIb3DQEJAzELBgkq
hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTk4MTIyOTIyMzkyOFowIwYJKoZIhvcNAQkEMRYE
FAOI5RgQFVkSUlML2BBkGl6gRi/qMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYI
KoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEoMA0G
CSqGSIb3DQEBAQUABIGAZYywpCtXYbM9B2HCtDxEDDyZgUzi/44do7WN6u3DP47MeytE13ug
NFfRFnlam4j/YsnPr7fccrPXLejDOJQ4o+RL2hcpyrJsOzusWoE9moph6RNEQcHsrsn08lia
IHAwuogbjxc6sbFE+mzzuE+wa3phAb3EiLFQxAuxUGeRITg=
==============ms5880AF4A87242567B235E69C==
------------------------------
From: Ken Keys <[EMAIL PROTECTED]>
Crossposted-To:
alt.security,alt.technology.smartcards,comp.arch.embedded,comp.arch,comp.security.misc
Subject: Re: DS5002FP Secure Micro Crypted Buses
Date: Mon, 04 Jan 1999 12:53:47 -0700
Andy Glew wrote:
> (1) if probing the internal chip structure is simply a matter of
> popping something like an EEPROM lid off and applying probes,
> well, pretty much anyone can do it.
>
> (2) if probing the internal chip structure involves having to
> grind off the back of the chip, and/or etch off masking layers
> that get in the ways of probes, then you have probably cut
> down by several orders of magnitude the number of people
> who can do it.
Applying probes? This is way outside my field of expertise, but I was
under the distinct impression that electron microscopes were used for
such games and that it was within the capabilities of most Universities
and just about any commercial lab that can do failure analysis.
KLK
------------------------------
From: "Sam Simpson" <[EMAIL PROTECTED]>
Crossposted-To: alt.sources.crypto
Subject: Re: Encryption questions.....
Date: Mon, 4 Jan 1999 12:47:32 -0000
If you are looking at buying a book, then I would consider:
Privacy on the Line - The Politics of Wiretapping and Encryption, W.Diffie &
S.Landau, 1998.
ISBN: 0-262-04167-7
Excellent, balanced discussion of the national security/law enforcement vs.
personal privacy debate.
Also contains a brief intro to crypto....
Sam Simpson
Comms Analyst
-- http://www.hertreg.ac.uk/ss/ for ScramDisk hard-drive encryption & Delphi
Crypto Components. PGP Keys available at the same site.
lordstar wrote in message <[EMAIL PROTECTED]>...
>I'm writing a term paper on how encryption could be the key to privacy.
>I'm looking for info on the basic on encryption.
>
>
------------------------------
From: [EMAIL PROTECTED] (KRamsay)
Subject: Re: Help: a logical difficulty
Date: 04 Jan 1999 22:29:55 GMT
In article <[EMAIL PROTECTED]>,
Mok-Kong Shen <[EMAIL PROTECTED]> writes:
|Since there does not exist an algorithm to deliver the shortest
|string to describe an arbitrarily given random number sequence,
|couldn't one say that the problem of determining the shortest
|description of a sequence is undecidable? If so, the measure of
|complexity is not a well-defined quantity. It follows then that
|arguments based on the use of such a measure are also not
|well-defined.
Some of the arguments are nonconstructive, but that isn't the same as
their being "not well-defined". In mainstream mathematics, common use
is made of the law of excluded middle, which has the effect of saying
that for any proposition P, the integer n defined by n=1 if P is true
and n=0 if P is false, exists. This is assumed, regardless of whether
we have a way of determining whether P is true. It's built into logic
("classical" logic).
This sort of feature isn't particular to the theory of algorithms;
it's pervasive in mathematics. When we say that a real number always
has a decimal expansion, it's in this nonconstructive sense of
existence; decimals can't always be computed. To understand
nonconstructive mathematics, you just have to get used to existence,
in this case of the complexity of a string, not meaning that one can
find the complexity or anything like that.
Nonconstructive arguments generally can be reinterpreted in a
constructive way, however. For example, one theorem says that there is
a uniform upper bound on the number of minimum-length programs which
generate any given string. That there is such a thing as "the number
of shortest programs..." is nonconstructive, but it's only a sort of
superficial nonconstructivity; the proof shows, constructively, that
if we have more than a certain number of programs of the same length
which generate the same string, we can use them to get a shorter
program which generates the same string.
Keith Ramsay
------------------------------
From: "Dr. Alan Sherman" <[EMAIL PROTECTED]>
Subject: Talk at UMBC - "How to run a crypto company" by Meir Zorea
Date: 4 Jan 1999 18:00:46 -0500
The UMBC Security Technology Research Group presents
A Story of What It's Like to Run a Cryptographic Company
Meir Zorea
President & CEO, Aliroo America Inc.
McLean, VA
10-11am
Friday, January 8, 1999
ECS Room 210i (CSEE seminar room)
Host: Dr. Alan T. Sherman, [EMAIL PROTECTED]
http://www.cs.umbc.edu/www/crypto/
ABOUT THE SPEAKER:
Meir Zorea
President & CEO
Aliroo America Inc.
7921 Jones Branch Drive
Suite 300
McLean, VA 22102
[EMAIL PROTECTED] WEB: www.aliroo.com
Phone: 703-917-0778 Fax: 703-917-1449 C: 703-623-3689
PrivaWall - The No. 1 server software for automatic and transparent E-Mail
traffic encryption.
NEW - PrivaWall supports Firewall-1 of Check Point
Contact us TODAY to get more details.
===========================================================================
Dr. Alan T. Sherman
Associate Professor, Computer Science Faculty Advisor
Tele: (410) 455-2666 UMBC Chess Club
Fax: (410) 455-3969 Club tele: (410) 455-8499
www.csee.umbc.edu/~sherman www.umbc.edu/chess
Office: Room ECS 225j [EMAIL PROTECTED]
Department of Computer Science and Electrical Engineering
University of Maryland, Baltimore County
1000 Hilltop Circle
Baltimore, MD 21250
USA
Directions: Take Exit 47B off I95 and follow signs to UMBC. During
business hours, park in visitor's lot; at other times park in Lot 16 or 9.
===========================================================================
------------------------------
From: [EMAIL PROTECTED] (Paul Rubin)
Subject: Fwd: Meganet's Deterministic Polyomial Time Primality Test
Date: Tue, 5 Jan 1999 00:02:40 GMT
This is a crosspost from sci.math.research since readers here on
sci.crypt might enjoy the humor. Meganet's antics are of course
familiar to many of us here, as are the facts that P-time primality
tests have been available for many years and that the probabilistic
tests in most cryptography programs are reliable and quite fast.
================================================================
In article <[EMAIL PROTECTED]>,
MikeAt1140 <[EMAIL PROTECTED]> wrote:
>Meagnet announced the test indicated in the Subject (See below). Has this test
>been independently confirmed ?
>
>______________________________________________________
>>Major Worldwide Mathematical Breakthrough Meganet Corporation DevelopedFast
>100% Deterministic Prime Number Testing
>
>
>It is the Only Deterministic Algorithm in the World to
>
>Work in Polynomial Time.
>
>TARZANA, Calif., Dec. 30 /PRNewswire/ -- Meganet Corporation, who
>challenged Microsoft, Intel, Dell, AT&T, NCR and many other high tech
>companies with their unbreakable Virtual Matrix Encryption, have
>announced today the result of 13 years of Research & Development in
>the prime number testing area -- the world's first and only
>POLYNOMIAL TIME, 100% DETERMINISTIC PRIMALITY TESTING. It is NOT a
>probabilistic test like the other algorithms in the market, but 100%
>deterministic. The algorithm is in POLYNOMIAL TIME, therefore much
>faster than even the probabilistic algorithms. Meganet Corporation
>have implemented the algorithm in an ANSI C application running on a
>single CPU 450 MHz PC Computer. Some sample results:
>
>1,000 bits primality test -- 0.5 Sec
>
>2,000 bits primality test -- 1 Sec
>
>3,000 bits primality test -- 3 Sec
>
>4,000 bits primality test -- 8 Sec
>
>5,000 bits primality test -- 15 Sec
>
>6,000 bits primality test -- 26 Sec
>
>7,000 bits primality test -- 41 Sec
>
>8,000 bits primality test -- 1:01 Min
>
>9,000 bits primality test -- 1:27 Min
>
>10,000 bits primality test -- 1:58 Min
>
>Those results are unheard of. The 1,000 bits test on a Sparc II workstation
>takes 5 Minutes and it is still only PROBABILISTIC. The gap in time is much
>greater for larger bit sizes.
>
>The major breakthrough is solving a 400 year old mathematical problem
>-- how to positively identify a prime number without spending
>exponential time in dividing the number by all the primes up to its
>root. The solution Meganet Corporation have developed is based on a
>newly designed Mathematical Sequence called the T-Sequence. Once a
>number is transformed to the T-Sequence, its quadratic residue has
>definitive characteristics if it's a prime number that can be easily
>determined in polynomial time by performing a binary decomposition.
>
>Meganet Corporation would like to emphasize that there is a 100%
>mathematical proof behind their T-Sequence, and further, it is a
>complete working product tested successfully on over 1.3 million
>numbers without a single mistake.
>
>Meganet Corporation is seeking for companies interested in this
>algorithm which generates large industrial grade prime numbers at
>record speeds, and would be glad to demonstrate the technology to any
>interested party on request.
>
>This latest development further establishes the status of Meganet
>Corporation as a leader in the Data Security & Encryption field.
>Meganet Corporation is the developer of Virtual Matrix Encryption,
>which is the strongest available encryption product in the market,
>including the PROVEN unbreakable Virtual Matrix Algorithm and a 1
>MILLION BIT SYMMETRIC KEY. The retail product is sold nationwide for
>over 8 months now, and the ongoing $1,200,000.00 challenge to break
>VME is at it's 8th month with no challenger. The challenges
>emphasizes Meganet Corporation's confidence that VME is an
>unbreakable algorithm.
>
>More information about Meganet Corporation and the Virtual Matrix Encryption
>can be found at: http://www.meganet.com.
>
>SOURCE Meganet Corporation
>
>CO: Meganet Corporation
>
>ST: California
>
>IN: CPR
>
>SU: PDT
>
>12/30/98 10:00 EST http://www.prnewswire.com
>
>
>Professor Michael Anshel
>Department of Computer Sciences R8/206
>The City College of New York
>New York,New York 10031
------------------------------
From: [EMAIL PROTECTED] (David R Brooks)
Crossposted-To: alt.binaries.cracks.encrypted
Subject: Re: CD Rom Encryption
Date: Tue, 05 Jan 1999 00:00:06 GMT
"K1LL5W17CH" <[EMAIL PROTECTED]> wrote:
:I need to encrypt some folders containing documents and pictures and also
:several programs on a Cd rom.
:I am searching for a strong and fast encryption software if possible a
:shareware.
:Can anyone help me please?
:...I have not much time and it's really important...
In a similar situation some time ago, I simply used PGP 2.6, in
"conventional" encryption mode. Give it a passphrase, and your file is
encrypted. Now burn the CD.
Since PGP 2.6 is purely DOS command-line, you can use the DOS "FOR"
command to automate encryption of several files (or write a Perl
script!).
-- Dave Brooks <http://www.iinet.net.au/~daveb>
PGP public key via <http://www.iinet.net.au/~daveb/crypto.html>, or servers
------------------------------
From: Jonah Thomas <[EMAIL PROTECTED]>
Subject: Re: Help: a logical difficulty
Date: Mon, 04 Jan 1999 23:15:28 GMT
Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
>Recently there were some discussions in this group on true randomness,
>Komolgorov complexity, etc. I have a little bit of difficulty with
>the logic (or rather meta-logic) thereby involved. My throught
>problem is as follows:
>Since there does not exist an algorithm to deliver the shortest
>string to describe an arbitrarily given random number sequence,
>couldn't one say that the problem of determining the shortest
>description of a sequence is undecidable? If so, the measure of
>complexity is not a well-defined quantity. It follows then that
>arguments based on the use of such a measure are also not
>well-defined.
>What is the flaw in the above. Would experts please help? Thanks.
It's possible to do this if you accept certain arbitrary ideas.
For example, you could define a turing machine in a particular way,
and then for any particular finite sequence you could find the
minimum program for that machine that would produce that sequence.
Since you can find a program that produces the sequence, by
exhaustive search you could look at all the shorter programs to
find the shortest one that produces the sequence in question. You
could then call the length of that program the measure of
complexity of that sequence.
But a different machine will give different results.
In reality we describe our sequences using outside information
that we hide from ourselves, that we don't overtly put into the
description. So for example you could turn _War and Peace_ into
a zip file and reduce its redundancy, making it considerably
shorter. But you could also describe it as "the text of _War
and Peace_". You could make short descriptions of similar texts
similarly. "The text of _War and Peace_ 5th Bantam edition with
the following typo: char 152 on page 97 from e to u."
Similarly, you could take the turing machine programs and
describe many of them in a shorter way. "The 15th program that
requires 697 steps." If you can generate all the programs and
you have a way to order them, the labels can be shorter than the
programs themselves just like the name of _War and Peace_ is
shorter than the novel. And people know what you mean from their
common background. Without a common background they wouldn't
know what you meant by an even number or a prime number or a
turing machine either -- it's hard to even be sure what outside
information you're including.
So the complexity of a sequence depends on how you look at it.
There may be a trick to looking at it that makes a complex
sequence look simple. You can define the complexity using an
arbitrary academic measurement system, but cryptographers might
use common knowledge to hide simplicity.
However, you can say the following: If a message has only 5
bits total, then there are a maximum of 32 different things it
can say. If it has only 16 bits total then there are a maximum
of 65536 different things it can say, not counting the additional
information presented by the fact that there are 16 bits instead
of 15 or 17, and not counting the fact that the message arrived
when it did instead of some other time. Whether the message is
decrypted by choosing one of the first 65536 words in _War and
Peace_ or one of 4096 messages in one of 16 codebooks, still there
are limits to what can be said in that space.
------------------------------
From: [EMAIL PROTECTED] (Frank Gifford)
Subject: Re: CTS a la Schneier, Rivest
Date: 4 Jan 1999 18:41:46 -0500
In article <76riib$mq8$[EMAIL PROTECTED]>,
Jon Becker <[EMAIL PROTECTED]> wrote:
>In article <[EMAIL PROTECTED]>,
>John Savard <[EMAIL PROTECTED]> wrote:
>>[EMAIL PROTECTED] (Jon Becker) wrote, in part:
>>
>>>In both documents, however, the descriptions assume the existence of a
>>>second-to-last block of full size. My question is, how does one use
>>>CTS to generate the ciphertext for a plaintext message which is less
>>>than the cipher's block size (so that the aforementioned assumption
>>>doesn't hold)?
>>
>>There is no method to encipher a message of less than the blocksize in
>>length, using ECB mode, to produce an enciphered message of the same
>>length.
Take the last complete encrypted block and encrypt that again. Then do
an XOR with an equal number of bytes from that result and the final bytes
of the message. There is a potential problem of the encryption of
two messages which differ only in those bytes, however, so this is more
of a "here's a way to do it" situation. In many cases, padding is added
to bring the message to a block size.
If you want to encrypt a message which has a smaller blocksize than your
cipher, you can tack on 0 bits to the beginning, encrypt that, chop off
the first several bits and send the answer. Your recipient then can try
decrypting all possible starting bit values and which have the sent message
as the remainder. When he gets a decryption starting with all zero bits,
he knows he has the right answer. [This example is a little far fetched,
I know - it's just for illustration.]
-Giff
--
[EMAIL PROTECTED] Too busy for a .sig
------------------------------
From: [EMAIL PROTECTED] (Jon Becker)
Subject: Re: CTS a la Schneier, Rivest
Date: 4 Jan 1999 23:23:55 GMT
In article <[EMAIL PROTECTED]>,
John Savard <[EMAIL PROTECTED]> wrote:
>[EMAIL PROTECTED] (Jon Becker) wrote, in part:
>
>>In both documents, however, the descriptions assume the existence of a
>>second-to-last block of full size. My question is, how does one use
>>CTS to generate the ciphertext for a plaintext message which is less
>>than the cipher's block size (so that the aforementioned assumption
>>doesn't hold)?
>
>There is no method to encipher a message of less than the blocksize in
>length, using ECB mode, to produce an enciphered message of the same
>length.
>
>Thus, while one could still use the block cipher, either by padding
>the message to a full block, or by using a stream cipher mode such as
>counter mode, no technique that sufficiently resembles "ciphertext
>stealing" to be called a case of it is applicable to such short
>messages.
>
>Essentially, the only difference between the complicated-looking
>"ciphertext stealing" technique depicted in AC and simply enciphering
>each complete block of the message, and then, if an incomplete block
>is left unenciphered, enciphering the last 64 bits (or whatever the
>blocksize is) of the message is that the ciphertext stealing technique
>avoids alignment problems.
>
>(Myself, I would tend to encipher the last 8 bytes - and use the
>ciphertext stealing technique only to fill out the last byte if
>incomplete.)
>
>Clearly, you can't encipher the 'first 64 bits' and the 'last 64 bits'
>of something less than 64 bits long.
Yes, clearly. So we have a conundrum. According to RFC 2040:
This mode handles any length of plaintext and produces
ciphertext whose length matches the plaintext length.
So what is one to make of that? Is it just a mistake?
-Jon
------------------------------
** 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
******************************
