Cryptography-Digest Digest #77, Volume #13 Thu, 2 Nov 00 17:13:01 EST
Contents:
RSA vs. Rabin (Jan Fedak)
Re: ECC choice of field and basis ([EMAIL PROTECTED])
Re: On introducing non-interoperability (wtshaw)
Re: Psuedo-random number generator (David Schwartz)
Re: Is RSA provably secure under some conditions? (Roger Schlafly)
Re: Is OPT the only encryption system that can be proved secure? ("Douglas A. Gwyn")
Re: quantum cryptography FAQ (Simon Johnson)
Re: is NIST just nuts? (Francois Grieu)
Re: Visual Basic ("Patterson Programming")
Re: F-Secure File Crypto uses ECB (Sami J. M�kinen)
Re: BENNY AND THE MTB? (SCOTT19U.ZIP_GUY)
Re: Is OPT the only encryption system that can be proved secure? ("Douglas A. Gwyn")
Re: Is OPT the only encryption system that can be proved secure? ("Douglas A. Gwyn")
Re: very large mult. div. ("Douglas A. Gwyn")
Re: how i decode this? ("Douglas A. Gwyn")
Re: RSA vs. Rabin (Tom St Denis)
Re: Really Strong Cipher Idea? (Simon Johnson)
Re: Ciphers and Unicode ("Douglas A. Gwyn")
Re: Rijndael file encryption question. (Bernd Lorbach)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Jan Fedak)
Subject: RSA vs. Rabin
Date: Thu, 2 Nov 2000 09:46:13 +0000 (UTC)
Hello.
1. There is a big similarity between RSA and Rabin.
Encryption in RSA: c = m^e (mod n)
Encryption in Rabin: c = m^2 (mod n)
But decryptions differ a lot:
In RSA: m = c^d (mod n)
In Rabin: complicated procedure and results are not unique (you have
to pick one of four possible results)
Why is this? Why can't I just compute d = 2^{-1} (mod (p-1)(q-1)) as
in RSA? And why don't I get a single result when in RSA it's
possible?
Is this little difference the reason why Rabin is provably as secure
as factorization?
2. RSA with low exponents is found insecure today. Therefore, Rabin
should be insecure too?
Doesn't it contradict with the proof that you have to factor the
integer?
Or is it provably secure only under some conditions I've overlooked
(for example attacker must have only one message to work on or
something?)
Thanks for help, I really start getting lost in it :)
Jan
--
Jan Fedak talk:[EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED]
Linux - the ultimate NT Service Pack.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: ECC choice of field and basis
Date: Thu, 02 Nov 2000 20:08:05 GMT
Hello,
Thank you all for your answers. Dr. Rosing, I have ordered a copy of
your book (before your post actually!), but I haven't received it yet.
It must be a stupid question but what are the reasons for the fields
GF(p^m) to be disregarded when p>2? Is it a question of security,
efficiency or lack of knowledge of the EC group structure associated?
Mike, on the site of IEEE I have found the page about P1363
(http://www.manta.ieee.org/groups/1363/P1363/draft.html) but when I try
to download the draft I am prompted to enter my password. Is the
standard (freely) available somewhere else?
What are the differences between standards like ANSI X9.62 and IEEE
P1363 (and ISO 14999-3 and FIPS 186-2 and ...)? Why are there so many?
Are they in competition or collaborating?
Thanks again.
J. Rostand (AirBete)
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: On introducing non-interoperability
Date: Thu, 02 Nov 2000 13:33:35 -0600
In article <[EMAIL PROTECTED]>, Mok-Kong Shen
<[EMAIL PROTECTED]> wrote:
> The simple modification of the keyscheduling as given above
> evidently cannot effect the keyspace, since the round keys
> only change their positions not their values.
>
> M. K. Shen
Is not a permutation of the round keys something to do with keyspace?
--
Pangram: Move zingy, jinxed products; hawk benign quality fixes.
------------------------------
From: David Schwartz <[EMAIL PROTECTED]>
Subject: Re: Psuedo-random number generator
Date: Thu, 02 Nov 2000 12:19:04 -0800
Alan Rouse wrote:
>
> In article <[EMAIL PROTECTED]>,
> David Schwartz <[EMAIL PROTECTED]> wrote:
> > Who said anything about being balanced or having exactly maximal
> > entropy? I'm talking about having sufficient entropy for cryptographic
> > purposes, nothing more, nothing less
>
> How much entropy is sufficient? Enough to support the design criteria
> of the encryption. Presumably a cryptosystem designer would select the
> key size, such that the size of the brute force attack would be
> sufficiently large--that is, above some design threshold.
Exactly.
> Assuming a brute force attack on a key consisting of n truly random
> bits (each bit being an independent event, having exactly equal chances
> of being 1 or zero), the expected number of trials is n/2. But if the
> key doesn't meet those criteria, the expected number of trials may be
> less. An attacker who understands the weakness in the randomness of
> the key generation process can optimize his search by trying the most
> likely values first, which will lower the expected number of trials
> below n/2.
Precisely. That's why you must ensure that your source of randomness
has enough entropy that it doesn't become the weak link.
> Obviously hashing has no impact on the expected number of trials. If
> there are only x (x < n) possible seed values, then there will be only
> x possible outputs from the hash function, and only those x hash values
> must be searched by the attacker.
The purpose of hashing is not to increase entropy. It's to concentrate
or distribute entropy.
For example, a bit string a billion bits long with one in every
thousand bits set to zero has quite a bit of entropy. But it's not
immediately obvious how to use it to generate a 128-bit random key. You
could concoct a special method for dealing with this particular input
stream, but it would produce sub-optimal results if, for example, the
odds a zero bit weren't exactly one in a thousand. Hashing (with an
appropriately chosen hash, of course) is a good way to ensure that you
can concentrate the entropy where you need it.
DS
------------------------------
From: Roger Schlafly <[EMAIL PROTECTED]>
Subject: Re: Is RSA provably secure under some conditions?
Date: Thu, 02 Nov 2000 12:41:06 -0800
Philip MacKenzie wrote:
> All proof statements are of the form "If some assumptions are true,
> then some result is true". The statement of one-time pad
> security is something like "If two parties share a perfectly
> random string of bits of size n, then one can encrypt a
> single message of size n for the other, with the
> encryption being information-theoretically secure"
> (OK, that's a horrible statement of the theorem, but you
> get the idea.)
>
> So my point is, I'm not sure why you disparage my use
> of the word proof. It's a completely accurate description
> of many results--in a certain model and assuming certain
> functions are hard to compute, a certain scheme is
> _provably_ hard to break.
Perhaps you missed by other post, but what bugs me the most is
not just that you have an unverified hypothesis, but that you
have an unverifiable hypothesis.
Factoring may indeed be hard, in the sense of complexity theory.
But SHA-1 will never be proved to be a good instantiation of a
random oracle, because there is no theory that tells us what is
or is not a good instantiation.
It is not that you have proved something secure under assumptions.
You have proved it secure in some other universe that may not
have any relation to the real universe.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Is OPT the only encryption system that can be proved secure?
Date: Thu, 2 Nov 2000 19:56:50 GMT
"SCOTT19U.ZIP_GUY" wrote:
> ... I learned years ago testing is the way to check ones code to
> see if it works. Not blindly worrying about warnings that get in
> your way.
There are any number of good books on reliable programming, in C
or in general. Anyone who is concerned with this area should
read some of them. There are many things that can be done to
improve the portability and reliability of one's code; among
them are: modular design for high cohesion and low coupling,
familiarity with and strict conformance with relevant standards,
unit acceptance testing, structured walkthroughs, etc. *Not*
included are: testing on a single platform. The point of the
compiler warnings as Richard and other experienced programmers
use them is essentially the same as UNIX "lint": the programmer
intends to write code that does not depend on specifics of one
C implementation but will work on all (standard-conforming)
implementations; the compiler or "lint" tells him when there
is a potential portability problem; ideally, *every* such
warning indicates some oversight that the programmer needs to
remedy for his code to be maximally portable, and if in practice
there are a few spurious warnings about usages that are actually
not going to be portability problems (e.g. "assignment to
narrower integral type may be truncated" when the programmer
knows for sure that the range of values cannot overflow the
destination), it is a small price to pay for the assurance
checking. I routinely turn on every possible form of checking
at compile time, and rarely see spurious warnings; however, if
I had no clue about programming portably, there would be tons
of *genuine* warnings.
In the case of 19-bit data types, one should define such a
type and its operations (modularity!) as Richard and I did,
not wire details of 19-bit access into the structure of the
application algorithm. Done properly, the gain in clarity is
remarkable, which bodes well for improved maintainability,
portability, and reliability.
------------------------------
From: Simon Johnson <[EMAIL PROTECTED]>
Subject: Re: quantum cryptography FAQ
Date: Thu, 02 Nov 2000 20:42:18 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> On Sun, 29 Oct 2000 11:40:54 +0100, Mok-Kong Shen <mok-kong.shen@t-
online.de> wrote:
> >
> >
> >Daniel Bachofen wrote:
> >>
> >> I have some newbi-questions about quantum cryptography, but I
could not
> >> find any FAQ related to that topic.
> >> I already read the cryptography-faq/part01-part10.
> >>
> >> If anyone could give me a hint, to such a FAQ or a related
newsgroup??
> >
> >I believe that the best is to search for some books on
> >that topic, if you are really interested in that new
> >field.
>
> new field? Not quite so, definitely much older than most of the
> cryptography that is in active use today. Iirc papers about it were
> published since the 70's.
>
> Bye
> Richard
>
yup, its new, compared to the 10,000 years of history that surround
conventional cryptography
--
Hi, i'm the signuture virus,
help me spread by copying me into Signiture File
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Francois Grieu <[EMAIL PROTECTED]>
Subject: Re: is NIST just nuts?
Date: Thu, 02 Nov 2000 21:57:11 +0100
Shawn Willden <[EMAIL PROTECTED]> wrote :
> AES will not be implemented in hardware on smart cards, just as DES
> is not. For Smart Cards the relevant question is how an algorithm
> performs in software on simple 8-bit architectures.
I can't predict the future for AES, but for the present hardware DES
is becoming standard on new 8-bit Smart Card ICs from STM, Infineon,
and others. Reasons include
- DPA attacks,
- move to triple-DES,
- increasing data volume,
- general desire for speed.
Francois Grieu
------------------------------
From: "Patterson Programming" <[EMAIL PROTECTED]>
Subject: Re: Visual Basic
Date: Thu, 2 Nov 2000 16:05:10 -0800
Ichinin wrote in message <[EMAIL PROTECTED]>...
>Paul Schlyter wrote:
>> Ouch !!!!!!!!!!!!!!!!!!!!!!!!!!
>>
>> Aren't there any static initialization of arrays in VB?
>> I guess not... :-(
>
>Jomenvisst:
>
>Stuff = Array(1, 2, 3, ... , N)
>
>For X 1 to (N)
> Debug.print Stuff(x)
>Next X
>
>Regards,
>Ichinin
Ichinin, your syntax uses a 'variant' data type. There is a risk that VB
would move/copy the data in dynamic memory. That makes 'burning' the key
material unreliable. I prefer to use static numeric arrays for such
purposes.
Also, performance is at least as high using my implementation.
JP
------------------------------
Subject: Re: F-Secure File Crypto uses ECB
From: [EMAIL PROTECTED] (Sami J. M�kinen)
Date: Thu, 02 Nov 2000 21:04:14 GMT
[EMAIL PROTECTED] (Markku-Juhani Saarinen) wrote in
<8trtg7$ro3$[EMAIL PROTECTED]>:
>From a reliable source:
> The File Crypto product ( http://www.f-secure.com/products/filecrypto/ )
> from F-Secure apparently uses the electronic code book (ECB) mode of
> operation to encrypt files.
> This obviously makes encrypted low-entropy data (e.g. uncompressed
> bitmaps or sound files, plain ascii text) vulnerable to codebook attacks
> regardless of key size or encryption algorithm used.
I think people in this NG aren't interested in this product in the
first place, at least after they have read the PDF documents avaible
in the web site.
The most incredible part is that this isn't the only weak part
of the product. Also, the source (leading the design team) doesn't
understand what's so weak in the product.
Those who understand Finnish-language can check this out the comments
in sfnet.atk.turvallisuus.
Regards,
Sami J. M�kinen / [EMAIL PROTECTED]
--
SBC Archiver homepage: www.geocities.com/sbcarchiver/
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: BENNY AND THE MTB?
Date: 2 Nov 2000 21:04:40 GMT
[EMAIL PROTECTED] (Bryan Olson) wrote in
<8tsgb7$l65$[EMAIL PROTECTED]>:
>Tim Tyler wrote
>> [EMAIL PROTECTED] wrote:
>
>> : The argument is fairly simple. If you chop all but 8-bits of
>> : a Rijndael block, the decryption is one of 2^120 possibilities.
>> : Therefore is Matt's version of "Rijndael" can in fact encrypt
>> : to a block of 8 bits (more importantly decrypt that block)
>> : there is no possible way for it to be the Rijndael that was
>> : reviewed as a part of the AES process, unless he has found a
>> : major flaw in Rijndael.
>>
>> Well, putting it like that the argument is indeed fairly simple.
>>
>> As is it's refutation: your premise is wrong - Matt does *not*
>> "chop all but 8 bits" from a Rijndael block.
>
>Though in the case in Dave's story, that is what the program
>did. That's about a one in 2^120 chance, barring a major flaw
>in Rijndael.
The program stayed consistant with the fact of being bijective.
However the fact is he would use at least one full Rijndeal block
for a encryption. All his encryption is done with full blocks.
However it is bjective and for any given key. When you apply the
optimal end handlings you should get for any key exactly 256 that
map to a single byte.
>
>Of course really what Dave did was fake the example: he
>defined his plaintext's "secret code format" to be what the
>decryption program put out for a given short ciphertext and
>key. He tells the story in the other direction, as if had has
>the codebook before he decided to use this encryption program.
>
>
You conclude this only becasue you know that if a single
Rijndael block is used most of the output messages would happen
to be approxiamtaly the same size. But you can't be sure what
I did since any particular pattern is equally possible. I may
have got lucky. But I did find an example to write the story
around since it makes a strong point about Matts code. Something
I think most crypto people gloss over. And it honestly uses Matts
program. And I hope causes people to check it out for themselves
instead of so called knowledgeable people shouting how impossible
this it. My god TEST IT.
If you don't like the stroy format. Do you think it better
when I shout and call everyone who fails to see it an asshole.
Especailly when all they have to do is test it.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
Scott famous encryption website **now all allowed**
http://members.xoom.com/ecil/index.htm
Scott LATEST UPDATED source for scott*u.zip
http://radiusnet.net/crypto/ then look for
sub directory scott after pressing CRYPTO
Scott famous Compression Page
http://members.xoom.com/ecil/compress.htm
**NOTE EMAIL address is for SPAMERS***
I leave you with this final thought from President Bill Clinton:
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Is OPT the only encryption system that can be proved secure?
Date: Thu, 2 Nov 2000 20:07:14 GMT
Richard Heathfield wrote:
> "SCOTT19U.ZIP_GUY" wrote:
> > I have seen comments affect the running of code in old
> > Fortan compliers.
> C compilers never even /see/ comments, because they're stripped out by
> the preprocessor.
Actually, the Reiser preprocessor (used on UNIX and thus many
ports of C to other systems) for a long time had a bug (caused
by structural problems akin to scott19u) that misparsed comments
if one aligned just so (as I recall, it was with the closing * and /
characters split across an internal buffer boundary), resulting
in some subsequent chunk of code being erroneously included in
the comment (until the next */ combination). However, when I
discovered this it was obvious to everybody that this was a bug,
and we fixed it in the preprocessor. The main purpose of a
language standard is to make it clear what is expected from both
the language implementation (compiler, library, etc.) and the
programmer; it's a "treaty" between those parties. Enforcement
of the treaty is sometimes necessary, but imagine how hard that
would be if there were no documentation of the terms of the
treaty (as in an informal or oral agreement).
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Is OPT the only encryption system that can be proved secure?
Date: Thu, 2 Nov 2000 20:18:18 GMT
"SCOTT19U.ZIP_GUY" wrote:
> Doug I'm glad you though of it but. SCOTT19U needs to be able
> to go through the file in two different directions so I am not
> sure the stream idea is useful because I have to travel up the
> stream and down the stream unless I revese the file each time.
> Unless there is come tricky way to start at back of a file and
> wirte the backend first.
I was working from an indication that the entire message would
be stored in memory, in which case the C array has the right
properties. Unless you require that for the reverse pass the
19-bit alignment needs to be against the end of file (padding
at the front), which makes a difference for 18/19 of all files.
Since for 1/19 of all files the alignment is the same either
way, you cannot reasonably be relying on it for security, so
I'd suggest using beginning-of-file alignment for both pass
directions.
The alternative of not buffering the file internally forces
the program to try to read "backwards", i.e. use fseek() to
backspace through the whole file, which will be horribly slow
unless large buffers are used. Anyway, the backward-reading
functionality should likewise be isolated into a separate
module that specializes in just that and nothing else, then
it can be used with functions similar to the ones I posted to
accomplish a 19-bit chunking in the reverse direction. The
essential idea, regardless of exactly what kind of I/O is being
done, is to use a module that performs native-byte to 19-bit
chunking (and the reverse transformation) independently of how
the resulting data is to be used.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: very large mult. div.
Date: Thu, 2 Nov 2000 20:21:01 GMT
Richard Heathfield wrote:
> The third volume is on sorting and searching, and is absolutely
> fascinating. (I find the first two fascinating too.) How you can find
> sorting and searching to be boring is beyond me.
Maybe he missed the centerfold!
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: how i decode this?
Date: Thu, 2 Nov 2000 20:30:02 GMT
Eduardo Hernandez wrote:
> how i decode or decrypt this kind of messages???
> MQ'(E<H8.=8"AKS*7C$$KTGXXF_-D:M+&![;'PY61C0<B$-?E1B.^XKPMT,:T
> MI38V9-JN7+H/[C2^9*R1&X`4;HUTLE$7D4D].B7JPZMTA2Z?;U9,^N$C8_C8
> ME?!/K?>7ZBM]H\OAPIPI+OR<S>::]>K<ESP$9RULS>)*[[@DAV:#LU\;+:'C
> MQH#&RZW06I'F7I^>QHD[!(_\_?DPX%&I`Y@NV9MZ!\%JD)8#%&YML5L>VG[6
> MCL^M[2!5+;[U\[?&[R%KO^T/&=V9,OV6-VI7G`K-Z&<-,.6_$VJZ&[#XE"6`
> M`:G/;Q3+T]+K8Q3^+KYQGEU-.2@A\IM6_E9Y)+&G!QO<];U:5P4/OC,E$TU]
> M`*@:H4DZVY?`B!&5%^OL_'O039X;>T[&K/U^7;E"&QPS$[.8R:[R:NI&)>/>
You should discuss it with whoever created the messages.
Note that these all start with M and use a limited character
set. Probably it's a base-64 encoding similar to what MIME
and uuencode use.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: RSA vs. Rabin
Date: Thu, 02 Nov 2000 21:10:22 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Jan Fedak) wrote:
>
> Hello.
>
> 1. There is a big similarity between RSA and Rabin.
> Encryption in RSA: c = m^e (mod n)
> Encryption in Rabin: c = m^2 (mod n)
> But decryptions differ a lot:
> In RSA: m = c^d (mod n)
> In Rabin: complicated procedure and results are not unique (you
have
> to pick one of four possible results)
>
> Why is this? Why can't I just compute d = 2^{-1} (mod (p-1)(q-1))
as
> in RSA? And why don't I get a single result when in RSA it's
> possible?
Because there is no multiplicative inverse for 2 modulo (p-1)(q-1) when
p and q are odd primes (think about that for a second, it should be
obvious).
> Is this little difference the reason why Rabin is provably as
secure
> as factorization?
Yes. If you can find square roots, i.e a^2 = b^2 mod N (a != b) then
you can factor N. Thus solving the square root (well I think this is
how the proof goes, of course Bob will correct me) is as difficult as
factoring.
The question remains: Is factoring hard?
> 2. RSA with low exponents is found insecure today. Therefore, Rabin
> should be insecure too?
>
> Doesn't it contradict with the proof that you have to factor the
> integer?
Rabin is insecure for various other reasons I would imagine. Factoring
is still a hard problem, thus solving the square root is still hard.
RSA is more convenient as well. You can easily perform either
operation and you can do signatures, etc..
> Or is it provably secure only under some conditions I've overlooked
> (for example attacker must have only one message to work on or
> something?)
RSA is conjectured to be as hard as taking the discrete logarithm
modulo a composite (and with sufficient twisting as hard as factoring).
However, there is no proof that you need to factor to solve the RSA
problem. In the case of Rabin it has been proven that you need to
factor to take the square root.
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Simon Johnson <[EMAIL PROTECTED]>
Subject: Re: Really Strong Cipher Idea?
Date: Thu, 02 Nov 2000 21:13:56 GMT
In article <[EMAIL PROTECTED]>,
Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
>
>
> John Savard wrote:
> >
> > A One-Time-Pad is not considered terribly practical, since one has
to
> > exchange a large key beforehand, its use is strictly limited, and
the
> > key must be kept secure for a long time.
> >
> > I tend to agree with this, even if it is the ideal case of
> > information-theoretic security.
> [snip]
>
> I like to take this opportunity to elicit some discussions
> about security. If I have 256 truly random bits, I can use
> it as OTP to process 256 bits of plaintext and obtain
> perfect security as defined by Shannon. If I use the same
> 256 truly random bits as key to AES to process a few million
> blocks of plaintext, how much diminution in security do I
> have? Since there is yet no rigorous quantitative measure
> of security, one can't exactly answer that question. But
> at least intuitively there is essential diminution.
> Conversely, if I do multiple encryption with a few other
> comparable block ciphers and corresponding number of sets
> of 256-bit keys, how much enhancement in security do I have?
> I have the feeling that that could be increasing sort of
> exponentially with the number of ciphers involved.
>
> M. K. Shen
>
256-bit keys are likely to be secure from brute-force for of this time
the universe has to run. A counter can be cycled through all 217-bit
permutations using the total energy output from the sun in a year.
Mutliply this by roughly one trillion, and you have the energy required
to cycle through all 256-bit permuatations.
Its unlikely that a 256-bit cipher will ever be broken in this
universe, but it may be with highly parrelled processors across
universes in some obsecure time in the future :P
--
Hi, i'm the signuture virus,
help me spread by copying me into Signiture File
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Ciphers and Unicode
Date: Thu, 2 Nov 2000 20:35:30 GMT
Mok-Kong Shen wrote:
> Thanks. I understand this to mean that, if one occasionally
> inserts a few Chinese ideographs in a stream of English
> characters, then one has to spend 3 bytes for each, but that
> for entire paragraphs of Chinese one can switch to another
> encoding under Unicode that codes each ideograph to two bytes.
No, the point of an encoding is to have a single uniform
translation rule. If you want to mix-and-match you can
do it, but it breaks standard encoding translation tools.
A 50% storage penalty for all-Chinese text seems a small
price to pay for the vastly improved user interface that
supports absolutely any character set with no special
effort, and the ease of coding applications that handle
any character set in a simple, uniform way.
------------------------------
From: Bernd Lorbach <[EMAIL PROTECTED]>
Subject: Re: Rijndael file encryption question.
Date: Thu, 02 Nov 2000 21:49:12 +0000
ajd wrote:
>
> Hi,
>
> I've written a rijndael implementation (128 bit key, 10 rounds) and got it
> working with the test vectors. I now am trying to encrypt files with it.
>
> Say I have a text file msg.txt conatining:
>
> oh I do like to be beside the seaside.
> Oh I do like to be beside the sea.
> where the brass band pl
>
> This file is 99 bytes long. I want to encrypt it but the Rijndael block
> cipher requires blocks of 16 bytes, so I append the final block with
> gibberish (lets call this gibberish the 'carry'). Running this through my
> encryption algorithm gives an encrypted file of 112 bytes.
>
> Now here I could either
A standard method for encrypting files of arbitrary length with a
block cipher like rijndale is called "code stealing", which does
a special treatmend of the last two blocks, if the last block is
less then 16 Bytes. I'll try to describe:
Let's say the last two blocks are Y and Z, with Z is the
last (incomplete) block consisting of only 3 bytes.
First, of couse, you encrypt all the other blocks and
writes the encrypted blocks out. Then you encrypt block
Y, but only writes the first 3 bytes of the encrypted block.
then you fill up the incomplete block Z with the other 13 bytes
of the encrypted block from Y, encrypt this and write this out.
It is like this (upper case letters denote plain text,
and I have shortened blocks to 8 to save space):
Inputt: AAAAAAAA BBBBBBBB ... YYYYYYYY ZZZ
\------/ \------/ \------/ | |
(ENCR) (ENCR) (ENCR) | |
/------\ /------\ /------\ | |
aaaaaaaa bbbbbbbb ... yyyyyyyy | |
| | | | | |\ \ | |
| | | | | | \ \| |
| | | | | | yyyyyZZZ
| | | | | | \------/
| | | | | | (ENCR)
| | | | | | /------\
Output: aaaaaaaa bbbbbbbb ... yyy zzzzzzzz
NOTE1:
you can save some copy operations, if you don't
encrypt "yyyyyZZZ" but "ZZZyyyyy", and it might
be easier to decrypt, if you write "zzzzzzzz"
before "yyy" (you may save an other copy operation
and need less buffer, but that depends on the
impelmentatin).
NOTE2: You can (and should) CBC-Mode or something like
this for all encryption, even for the last two blocks.
On decryption, you have to think very carefully where
to place the XOR.
greetings, /Bernd L.
------------------------------
** 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
******************************
