Cryptography-Digest Digest #62, Volume #13 Tue, 31 Oct 00 21:13:00 EST
Contents:
Re: how i decode this? (Simon Johnson)
Re: Is RSA provably secure under some conditions? (Simon Johnson)
Re: BENNY AND THE MTB? (SCOTT19U.ZIP_GUY)
Re: [PGP] Twofish, 256bit, and Usenet Posting (SCOTT19U.ZIP_GUY)
Re: On introducing non-interoperability (Mok-Kong Shen)
Re: Rijndael Key Schedule (Simon Johnson)
Re: Rijndael file encryption question. (SCOTT19U.ZIP_GUY)
Re: DATA PADDING FOR ENCRYPTION (SCOTT19U.ZIP_GUY)
Re: RSA Multiprime (Mok-Kong Shen)
Re: Psuedo-random number generator (David Schwartz)
Re: Is RSA provably secure under some conditions? (David Wagner)
Re: DATA PADDING FOR ENCRYPTION (John Savard)
Spanish Language Data ("ja")
Re: RSA Multiprime (Scott Contini)
Really Strong Cipher Idea? (John Savard)
Re: Padding scheme? (Tim Tyler)
Re: DATA PADDING FOR ENCRYPTION (Tim Tyler)
Re: Spanish Language Data (JPeschel)
Re: Give it up? (Tom St Denis)
----------------------------------------------------------------------------
From: Simon Johnson <[EMAIL PROTECTED]>
Subject: Re: how i decode this?
Date: Tue, 31 Oct 2000 23:55:20 GMT
In article <8tj5op$en1$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Paul Schlyter) wrote:
> In article <8th81h$f2r$[EMAIL PROTECTED]>,
> Simon Johnson <[EMAIL PROTECTED]> wrote:
>
> > In article <8tglmm$fa4$[EMAIL PROTECTED]>,
> > [EMAIL PROTECTED] (Paul Schlyter) wrote:
> >> In article <8teiah$ifv$[EMAIL PROTECTED]>,
> >> Simon Johnson <[EMAIL PROTECTED]> wrote:
> .........
> >>> *LOL*, But on a serious note:
> >>>
> >>> We can't be expected to even attempt to solve the encrypted cipher
> >>> text without knowledge of the algorithm.
> >>
> >> So you mean it's a good idea to use secret enryption algorithms?
> >
> > Hell no.
> >
> > If you write you're own algorithm, publish it. The reasons for this
are
> > simple. First off, you can determine the _REAL_ security of you're
> > algorithm. A little more complex, but equally as valid, If you keep
> > you're algorithm secret and an attacker discovers it, this could be
a
> > problem because you don't know you're security has been compromised.
> > Realsing you're algorithm immediatly makes sure that you can not be
> > ambushed.
> >
> > Another reason is more comercial. IF some company tells you they
> > have 'Unbreakble encryption', as the often do, and doesn't let u
look
> > at the algorithm its probably pants. Releasing an algorithm into the
> > public allows one to determine if you're product is worth buying.
>
> Doesn't this apply to the military as well? If they reveal
> their secret algorithms, then their customers (i.e. the public) can
> make a more informed decision on whether they want to pay them
> tax money or not..... :-))))
>
Personally, i think that should be the case. These services wouldn't
exist without a tax payer. The public should know what there buying.
--
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: Simon Johnson <[EMAIL PROTECTED]>
Subject: Re: Is RSA provably secure under some conditions?
Date: Wed, 01 Nov 2000 00:03:10 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (DJohn37050) wrote:
> Yes, it is at least concievable that low exponent RSA is insecure but
high
> exponent RSA is secure. You can show that low exponent RSA leaks a
lot of
> info, so in some sense is the worst case, if RSA is able to be
broken.
> Don Johnson
>
Its not really a matter of concievabitlity, because the attacks are
real. The CRT will work, and thus it is real weakness. RSA seems to
have a lot of nigling weaknesses, in order for to RSA be secure you
need a spot on implemenetion. I think 2 and 3 are really too lows
exponents and that say 17 or even 65537 is better.
I'm just wafling, so i'll stop there :-)
--
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: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: BENNY AND THE MTB?
Date: 1 Nov 2000 00:05:21 GMT
[EMAIL PROTECTED] wrote in <8tncsb$e7i$[EMAIL PROTECTED]>:
>In article <[EMAIL PROTECTED]>,
> [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY) wrote:
>
>Let's start with the obvious stupidities.
>1) A Rijndael block of "1 byte"
>Truth : Rijndael is a 128-bit block cipher, there is not way to make it
>generate a single byte output that is decryptable
That my friend is where your full of shit. Take a look
at Matts code or is it easyer to just spout you unknowledgeable
crap. Matt compresses and use Rijndael. THe individual blocks
that Rijndael are not one byte. But with proper use the input
or output of the combined compression encryption problem can.
LIke I said dunger head try it. You will find you are dead wrong.
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: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Crossposted-To: alt.security.pgp
Subject: Re: [PGP] Twofish, 256bit, and Usenet Posting
Date: 1 Nov 2000 00:08:24 GMT
[EMAIL PROTECTED] (Michael Young) wrote in
<8tnfis$a3o$[EMAIL PROTECTED]>:
>>could you also give us the current method of chaining the main ciphers
>>blocks, And does it still do a quick check to test if the key is correct
>>so that it doesn't have to decode the whole file before rejecting a
>>bad key.
>
>PGP uses a CFB variant. Using a cipher with block size B, and an
>input buffer size N (N<=B), generate the next N output bytes by
>applying the base cipher to the last B output bytes (or zeroes if
>there has been no output), XOR the first N resulting bytes with the
>input, and emit those N bytes.
>
>The data fed into this engine is as follows:
> one block-size buffer of random data (N=B);
> one buffer repeating just the last two *input* bytes (N=2);
> user input data, block-size buffered (N=B until the last, where N<=B).
>
>The first buffer effectively creates an IV. The second buffer provides
>the quick check you're looking for.
>
>A new format, introduced in PGP7, uses the same material, but
>always buffers it in block-sized units (N=B).
>
>All this is available in the OpenPGP specification (RFC2440, latest
>draft available at imc.org).
>
>
>
>
Thanks I wanted to see if that quick check of the password was
still in the code. I see you say it is. My question is why?
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: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: On introducing non-interoperability
Date: Wed, 01 Nov 2000 01:11:09 +0100
wtshaw wrote:
>
> Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
>
> > The idea is to obtain a system that differs from the
> > one the opponent has at hand. If the key scheduling
> > is modified, he wouldn't be able to do brute force,
> > for example.
> This depends on the real keyspace being greater than the utilized
> keyspace. Better use of keyspace is more efficient, i.e., more keys per
> size, but better is better potential keyspace to begin with.
As I expressed in my orignal post, it is meant as an
enhancement to a given cipher (that has already a fixed
key size).
BTW, one could even choose to dynamically change the Gi
values in a way analogous to block chaining.
M. K. Shen
------------------------------
From: Simon Johnson <[EMAIL PROTECTED]>
Subject: Re: Rijndael Key Schedule
Date: Wed, 01 Nov 2000 00:07:44 GMT
In article <8tmffc$23fo$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Trish Conway) wrote:
>
> In the Rijndael key schedule the first subkey is just a copy of the
userkey(for a 128 bit userkey). Could the following scenario be
interpreted as a weakness : Say the subkeys are generated in a black
box in hardware and an unauthorised person breaks into the black box
and obtains the subkeys. They now have the userkey and can go to
another black box and input the userkey and impersonate a legitimate
user(supposing that the userkey is distruted to a number of users all
using a central host).
>
>
What you've just realised is how block ciphers are attacked.
Differential and linear cryptanalysis works to recover a round-key(s)
and break the cipher that way. This isn't a weakness, since its generic
to every block-cipher, it can't really be avoidided.
--
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: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Rijndael file encryption question.
Date: 1 Nov 2000 00:11:02 GMT
[EMAIL PROTECTED] (mac) wrote in <8tngud$2gp9$[EMAIL PROTECTED]>:
>Hello!
>
> I have the same problem and I posted it with subject "Newbie about
>Rijndael" (10/31/00).
>I was directed to Matt Timermanns code which is great. There are some
>other, not so good but simpler methods. For example, if you have two
>byte string to encrypt (block size = 16b) you can fill the last two
>bytes of a block with your string and put the number of 'good' bytes
>(two in this example) in the first byte of a block. You can fill the
>bytes between(2-14)with '0' for example. When this block is decrypted
>you read the first byte and you know the length of the 'good' string
>from the end of the file.
> There are many different methods as there are many smart people out
>there. But the main point here is the question of standard. If 'Bob' who
>is encrypted data and the key being sent to, doesn't have the same
>implementation of Rijndael (and the problem we discuss is solved
>differently) he won't be able to decrypt parts of the text that didn't
>fit in the size of a block. So, I think we are looking for the standard
>technique (if there is some).
Get Bob a copy of Matts code.
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: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: DATA PADDING FOR ENCRYPTION
Date: 1 Nov 2000 00:20:41 GMT
[EMAIL PROTECTED] (Bryan Olson) wrote in
<8tni4q$j3b$[EMAIL PROTECTED]>:
>If you need to disable known or chosen plaintext attacks,
>then use a system that can do so. Bijective padding does
>not.
Actually none of the standard ciphers can be proven
to be a immune to plaintext attacks. So that is not so
easy.
>
>If we're intercepting these messages, an adversary supplies
>our plaintext. We have to expect not only known, but chosen
>plaintext attacks. Bijectively transforming chosen
>plaintext just means that the attacker can choose every
>bit of the post-padded message.
Ture but one can use my rotat to add random datat if that
makes you happy wiht DSC. The problem with many nobijective methods
is that an attacker does not even have to supply the plain text
as in a choosen plain text attack. He couls just look a the
encrypted messages alone and use the infomration adde by the
use of nobijective compression if thats part of the package as
in PGP.
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: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: RSA Multiprime
Date: Wed, 01 Nov 2000 01:36:29 +0100
Bob Silverman wrote:
>
> [EMAIL PROTECTED] (DJohn37050) wrote:
> > The original RSA patent that just expired mentioned the possibility
> of using
> > more than 2 primes. Draw your own conclusions about the Compaq
> multiprime
> > patent. Bob Silverman, RSA Labs, at the last ANSI X9F1 meeting said
> he thought
> > the Compaq patent would be declared invalid.
>
> I said no such thing. I did NOT say that it *would* be invalidated,
> I said that it *could* be easily challenged. Because of the way our
> laws work, one can't just go into court and say "I challenge this
> patent". One must VIOLATE the patent, then have the owner sue you over
> the violation. It is a protracted and messy and expensive process.
>
> Any challenge is almost certain to succeed. But one must weigh the cost
> of the challenge against the cost of licensing fees. This is true all
> the time. Many patents are easier to accede to than to fight.
This clearly indicates the disadvantage of not having
a public review period for US patents.
M. K. Shen
------------------------------
From: David Schwartz <[EMAIL PROTECTED]>
Subject: Re: Psuedo-random number generator
Date: Tue, 31 Oct 2000 16:38:32 -0800
By the way, you can find example code demonstrating this technique at
http://youknow.youwant.to/~djls/entropy.c
DS
------------------------------
From: [EMAIL PROTECTED] (David Wagner)
Subject: Re: Is RSA provably secure under some conditions?
Date: 1 Nov 2000 00:58:57 GMT
Reply-To: [EMAIL PROTECTED] (David Wagner)
Bryan Olson wrote:
>David Wagner wrote:
>> Roger Schlafly wrote:
>> >Which is why these folks shouldn't be claiming that they have proofs.
>>
>> Is it acceptable to claim you have a proof when what you really mean
>> is that you can prove it secure under the assumption that factoring is
>> hard?
>
>How about: "depends on the audience"? The goal is to
>communicate efficiently without deceiving people. When
>talking to cryptologists who are familiar with these
>reductions, "proof" is appropriate. If they want to know
>what problem was reduced to violating what security
>property, they'll ask.
That's a fair answer! I like that position.
And, I'd argue that the same principles should apply to
stating results in the random oracle model, as well.
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: DATA PADDING FOR ENCRYPTION
Date: Wed, 01 Nov 2000 01:00:27 GMT
On Tue, 31 Oct 2000 22:46:52 GMT, Bryan Olson <[EMAIL PROTECTED]>
wrote, in part:
>More importantly, it applies to the message as people
>actually send it. It makes no sense to say we must not
>provide known plaintext and then use a public-key cipher.
A very important point. Unless, of course, one is using a secure
public-key cipher to transmit a key for a much less secure (for speed
reasons) conventional cipher.
John Savard
http://home.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: "ja" <[EMAIL PROTECTED]>
Subject: Spanish Language Data
Date: Wed, 1 Nov 2000 09:10:44 +0800
Hi,
I am trying to solve a simple monoalphabetic substitution that has the
plain-text in Spanish.
Where can I get Spanish letter frequency, digram, trigram and contact info ?
Also, does anyone have some useful words to try as a crib.
Thanks
Jeremy
jeremy A T electrosilk D O T net
------------------------------
From: [EMAIL PROTECTED] (Scott Contini)
Subject: Re: RSA Multiprime
Date: 1 Nov 2000 01:19:31 GMT
In article <[EMAIL PROTECTED]>,
Francois Grieu <[EMAIL PROTECTED]> wrote:
>[EMAIL PROTECTED] (Scott Contini) wrote:
>
>> While (multiple primes) gives some speedups, it opens up the
>> (RSA) algorithm to possible new attacks: if a faster special
>> purpose algorithm than the elliptic curve method is invented,
>> then multi-prime RSA easily could become insecure.
>
>Well, GNFS and even MPQS are faster than ECM for pratical purpose,
>and all three are equaly efficient against two-prime and
>multi-prime RSA. The product of 2 random 288 bit primes is just
>as hard to factor as the product of 3 random 192 primes, and this
>situation has not evolved in the last 20 years. Yes, it is
>conceivable this could change, but it is also conceivable, and
>IMHO more likely, that some other breakthru will be made on
>factorisation or the discrete log problem over elliptic curves.
My point is that you're adding another possible avenue for attacking
the cryptosystem. I am very much against adding new possible avenues
for attacking cryptosystems in order to get speed improvements. I
have previously expressed similar concerns about using nonrandom
curves for ECC. My personal recommendation (for what its worth) is
to use what appears to be the strongest form of a particular type
of cryptosystem rather than using an apparently weaker version for
speed advantages when long term security is required.
>
>
>> (ECC enables) somewhat efficient operation on 8-bit processors
>> without a coprocessor. If you're concerned about the speed of
>> private key operations, my recommendation is to use ECC (for
>> security concerns, use a randomly generated curve)
>
>Have you any firm reference of ECC on 8 bits processors without a
>coprocessor ? Certicom once proposed this on the 68HC05, but it
>was apparently retracted. I do not know the reason, and still
>wonder if attacks have been found (on the special field used, or
>by power/timing attacks).
>
My judgement was based upon a smartcard that Certicom was showing
off I think during the 1999 RSA conference. It performed a digital
signature in something like 1 second without using a coprocessor.
I am not sure the details here are correct since I heard about it
by word of mouth. My guess is that it used a Koblitz curve,
which should be 4 times faster than a random curve. So even if
you could multiply the signature time by a factor of 4, this is
much faster than you would be able to do a signature with RSA
on a typical 8-bit smartcard CPU without a coprocessor according
to my experience. I am not an expert in this area so I am open
to hear from those with more experience. Thanks,
Scott
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Really Strong Cipher Idea?
Date: Wed, 01 Nov 2000 01:21:54 GMT
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.
Here is my idea for a cipher that is _merely_ strong, like an ordinary
symmetric cipher - but a bit stronger than most.
Two parties send messages in blocks of, say, 4,096 bytes.
They share a secret key which is perhaps 6,000 bytes in length.
When they communicate, they first send a public-key block which
contains perhaps eight 512-bit session keys, so they can send a
message which is up to eight blocks long.
The session key is used to encipher a block of plaintext like this:
Part of the session key is first used to encipher the 6,000 byte
secret key by means of transposition, and then another part encrypts
it using, say, a block cipher in CBC mode. (first block-sized piece of
transposed secret key used as IV, and not included in the 'encrypted'
key used later)
The other part of the session key enciphers the message itself. One
possibility is:
- encipher the message in ECB mode.
- XOR the message with the enciphered large secret key.
- encipher the message in CFB mode. (IV truly random)
No bit-flipping attack is possible, but the error-propagation
properties are quite good.
Since a secret key bigger than a message block is used, the
cryptanalyst has to compare more than one message block...but with
transposition preceding a block cipher encryption mode that propagates
forwards, it would seem very difficult to do anything useful.
One important step, though, can easily be added to significantly
improve the already high security. In addition to using the encrypted
large secret key to XOR with the message, also use part of it as the
key to encrypt the parts of the session key used for the ECB and CFB
stages before and after.
This increases security if the public-key part is compromised.
If the big secret key is compromised - obviously, it is only protected
by a pass-phrase containing much less entropy than it does, so access
to the key file definitely compromises it - but the session key is
secure, one can then do brute-force searching, but other cryptanalysis
seems to remain fairly hard.
I would think this sort of thing for encrypting one's E-mail would
indeed make hackers throw up their hands in despair. But once this is
modified to make it "practical" - somehow allowing the large secret
key to be distributed by ordinary encryption methods along the
Internet in advance - can any of its desirable security properties be
retained?
Perhaps using a secure hash function - or something like
Blum-Blum-Shub - to generate the 6,000 byte secret would be _part_ of
the answer, although it's clearly not the answer by itself.
Of course, if it's possible to calculate pi to one million digits
overnight on a PC, one could certainly use 20,000 bit Diffie-Hellman
prime moduli for setting up a connection...
John Savard
http://home.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Padding scheme?
Reply-To: [EMAIL PROTECTED]
Date: Wed, 1 Nov 2000 01:04:03 GMT
Benjamin Goldberg <[EMAIL PROTECTED]> wrote:
: Tim Tyler wrote:
:> Benjamin Goldberg <[EMAIL PROTECTED]> wrote:
:> :> [EMAIL PROTECTED] (Benjamin Goldberg) wrote:
:> :> >After having read some other recent stuff on this group discussing
:> :> >padding, I realize that a trojan horse type program could use the
:> :> >random padding as a subliminal channel. To avoid this, the
:> :> >padding should, instead of being random, be the first bytes and
:> :> >bits from a cryptographicly secure hash of the message. [...]
[snip]
:> : Although it's true that using bits from a hash, rather than bits
:> : from a TRBG, does create a bijective mapping from the set of
:> : messages whose lengths are multiples of 8 bits to the set of
:> : messages whose lengths are multiples of 128 bits [...]
:>
:> s/true/false/
:>
:> You've just added a redundant section to the message. A bit like
:> cutting the first few characters and pastuing them onto the end of the
:> file. No bijective map is likely to be found there.
: Note that the domain and range are not the same. The domain is the set
: of messages whose lengths are integral numbers of 8-bit bytes. The
: range is the set of messages whose lengths are integral numbers of
: 128-bit blocks. If the hash of the message is used as the source of
: 'random' padding bytes, then each message in the domain maps to
: precisely one message in the range. Furthermore, the inverse function,
: which strips padding, maps each message in the range of the padding
: function to one and only one message in the domain. Does not this
: padding scheme describe a mapping that is one-to-one and onto?
No. You're correct that each message in the domain maps onto one and only
one object in the range.
However you are not correct that each message in the range maps
onto one and only one message in the domain.
To illustrate this, I'll present an example, using a dumbed down,
trivialised version of your padding scheme (which will hopefully
nonetheless contain sufficient elements to illustrate the point).
Consider the mapping between:
[Message] and [Message|128 bit hash of the message] (where "|" indicates
a stratigtforwards appending of the data).
Is this mapping a bijection? No. Proof?
To recover the [message] from the combined [message|hash],one simply
strips off the last 128 bits.
Obviously this stripping is many to one operation.
101010011|1111100 gets mapped to 101010011.
101010011|0101010 *also * gets mapped to 101010011.
Your system is much the same. A number of 128-bit granular objects map to
the same original 8-bit file (or some of them don't map to anything and
do something like generate errors).
:> : there is no significant difference in security between the original
:> : 1-to-many mapping and the hash-based 1-to-1 mapping.
:>
:> You don't rate that ability to reject keys on the basis of their
:> having appended padding in the form of hash data (that doesn't
:> match the contents of the message) as a security risk?
: Consider that the entire message must be decrypted to be able to reject
: a key. There's a tradeoff... either use a RBG to create the padding,
: and risk the possibility of a subliminal channel being snuck in (a
: trojan horsed encryption program) by your opponent, or use hash bits,
: which allow rejection of keys. [...]
These are (more or less) the only options if you are using random padding.
There's an alternative (which David advocates) - which is not using any
padding at all and simply applying a bijective map between the set of
8-bit files and the set of 128-bit ones.
This method has a number of attractions - however, I believe it
has an imperfection of its own.
There's another alternative to padding - which is to use an encryption
algorithm that can cope with variable size messages, without padding them.
Cyphertext stealing is one such method of converting an ordinary block
cypher into such a variable-length device - though it too appears to have
an imperfection.
--
__________ http://alife.co.uk/ http://mandala.co.uk/
|im |yler [EMAIL PROTECTED] http://hex.org.uk/ http://atoms.org.uk/
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: DATA PADDING FOR ENCRYPTION
Reply-To: [EMAIL PROTECTED]
Date: Wed, 1 Nov 2000 01:17:42 GMT
SCOTT19U.ZIP_GUY <[EMAIL PROTECTED]> wrote:
: [EMAIL PROTECTED] (Tim Tyler) wrote in <[EMAIL PROTECTED]>:
:>It does makes files shorter - though I believe not by very much.
:
: But over many files it can add up to a lot.
True enough.
:>I suspect the files are "already" in this form. My only query was whether
:>it was worth tranforming the results to files of bytes, when the security
:>benefit is zero.
: I am not sure its zero. [...]
It probably isn't. Pretty damn close, though ;-)
:>: Like I have said to others this is not the end all. But I fill his
:>: implementions should be one of the ones most used people combine
:>: compression and encryption.
:>
:>It needs to be built into a program with a UI for most folk to use it.
: I think Matt did just that.
A command-line user interface? I meant a point-and-click user interface.
--
__________ http://alife.co.uk/ http://mandala.co.uk/
|im |yler [EMAIL PROTECTED] http://hex.org.uk/ http://atoms.org.uk/
------------------------------
From: [EMAIL PROTECTED] (JPeschel)
Subject: Re: Spanish Language Data
Date: 01 Nov 2000 01:59:14 GMT
"ja" [EMAIL PROTECTED] writes:
>Where can I get Spanish letter frequency, digram, trigram and contact info ?
Try:
http://members.fortunecity.com/jpeschel/lesson7.htm
Joe
__________________________________________
Joe Peschel
D.O.E. SysWorks
http://members.aol.com/jpeschel/index.htm
__________________________________________
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: Give it up?
Date: Wed, 01 Nov 2000 01:48:49 GMT
In article <[EMAIL PROTECTED]>,
Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
>
>
> Tom St Denis wrote:
> >
> > Here is all you need to know about communication topology.
> >
> > Secrecy -> Cipher
> > Efficiency -> Codec
> >
> > Codec != Cipher.
>
> Questions: (1) 'Topology' has a time-honoured and well-
> established meaning. How does the above conform to that?
> (2) Are you saying that one can't extremely increase the
> strength of a cipher and yet remain very efficient like
> one can't have a racing car at very low price, or do you
> want to express some other novel idea? Thanks.
Perhaps "topology" was the wrong word. But I just want to
stress "leave security to the components designed for security".
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
** 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
******************************
