Cryptography-Digest Digest #732, Volume #12 Thu, 21 Sep 00 11:13:00 EDT
Contents:
Re: One-way encryption (Tim Tyler)
Re: Tying Up Loose Ends - Correction (John Savard)
Re: Tying Up Loose Ends - Correction (John Savard)
Re: t (John Savard)
Re: Tying Up Loose Ends - Correction (SCOTT19U.ZIP_GUY)
Re: t (John Savard)
Re: Dr Mike's "Implementing Elliptic Curve Cryptography" - reader comment
(DJohn37050)
decrypt ("Aurelien")
Re: Double Encryption Illegal? (John Myre)
Re: Even-Mansour extension? (Doug Kuhlman)
Re: Double Encryption Illegal? (Bob Silverman)
Re: Tying Up Loose Ends - Correction (SCOTT19U.ZIP_GUY)
Re: Software patents are evil. (Padgett 0sirius)
Re: Tying Up Loose Ends - Correction ("Trevor L. Jackson, III")
----------------------------------------------------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: One-way encryption
Reply-To: [EMAIL PROTECTED]
Date: Thu, 21 Sep 2000 13:11:10 GMT
[EMAIL PROTECTED] wrote:
: Tim Tyler <[EMAIL PROTECTED]> wrote:
:> : On the other hand, MD5 and SHA-1 are both standard portions of the
:> : Java 2 platform, so the task of encrypting passwords with either of
:> : them is even easier.
:> SHA-1 is included in the JCE - but not in the JDK, or in the JRE, AFAIK.
: It is in fact in the JDK, although perhaps undocumented. [...]
You're right (and I learned something) - java.security.messageDigest
contains implementations of SHA-1 and MD5.
:> According to http://java.sun.com/products/jce/jce12_faq.html
:> ``JCE 1.2 is export-restricted, meaning that it can be downloaded only
:> from within the U.S. or Canada.''
: AFAIK, however, the JCE is no longer an "extension" but a standard
: part of the Java 2 platform (jdk 1.2+) as I wrote above. That doesn't
: mean that you don't need external providers for ciphers, just that the
: standard framework is part of the platform. I could be wrong about
: that though, since I have yet to find anyplace it's not available,
: I'm not prone to dig up the specs.
I don't think it's part of the J2SE, J2EE, the JDK, or the JRE downloads.
All the java.security classes are there, but none of the javax.crypto ones.
--
__________ Lotus Artificial Life http://alife.co.uk/ [EMAIL PROTECTED]
|im |yler The Mandala Centre http://mandala.co.uk/ Namaste.
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Tying Up Loose Ends - Correction
Date: Thu, 21 Sep 2000 13:21:48 GMT
On Wed, 20 Sep 2000 15:03:10 GMT, Tim Tyler <[EMAIL PROTECTED]> wrote, in
part:
>An alternative - which I've not seen discussed on this forum - would be
>to use an encryption device which is capable of encrypting variable length
>bitstrings, and is not confined to multiples of 8 bits. I attribute this
>idea to David Scott.
No, don't.
Actually, encrypting that way is the 'default' idea. Otherwise, for
example, the arrangement illustrated in Bruce Schneier's _Applied
Cryptography_ called "ciphertext stealing" would never have been
proposed, people would just encipher the last 64 bits (or the last
eight bytes) of the message in normal order as a block after
encryption on 64-bit boundaries was concluded.
I believe that PGP does it that way, although as David Scott was the
first to point out to my knowledge, it didn't use CBC as claimed in
its documentation, but instead uses CFB mode, I suppose one can't
trust the documentation.
John Savard
http://home.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Tying Up Loose Ends - Correction
Date: Thu, 21 Sep 2000 13:24:57 GMT
On Wed, 20 Sep 2000 15:03:10 GMT, Tim Tyler <[EMAIL PROTECTED]> wrote, in
part:
>After the compresssed file is encrypted, it can be safely padded out with
>zeros, to a byte boundary without any security concerns.
True.
>If you want to
>obscure the length of the file from your adversary, as much random padding
>as you like can be used at this stage.
False. If padding is added *after* encryption, one has to (unless one
is using a stream cipher of the sort vulnerable to bit-flipping,
or...) indicate where the padding starts in the clear so that
decryption will act on the right bits.
If the padding is genuinely random, adding it before encryption won't
cause a security problem: and does avoid the kinds of problem I was
concerned with - the teensy bit of redundancy left in by a scheme
aimed precisely at getting the last little teensy bit out.
John Savard
http://home.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: t
Date: Thu, 21 Sep 2000 13:26:28 GMT
On Thu, 21 Sep 2000 00:31:51 -0400, "Douglas A. Gwyn"
<[EMAIL PROTECTED]> wrote, in part:
>lala wrote:
>> t
>Yes, indeed. In fact that (although in upper case) was the
>entire content of the first page of an experimental book I
>once wrote, which explored how much communication might be
>developed between agents that could perceive the symbols but
>had utterly different modes of thought and no a priori shared
>knowledge. The second page was
> NNT
>The third was
> NF
>You get the idea (maybe).
Ah, yes. T and F stand for themselves, and N stands for ~.
John Savard
http://home.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Tying Up Loose Ends - Correction
Date: 21 Sep 2000 13:34:18 GMT
[EMAIL PROTECTED] (Tim Tyler) wrote in <[EMAIL PROTECTED]>:
>SCOTT19U.ZIP_GUY <[EMAIL PROTECTED]> wrote:
>: [EMAIL PROTECTED] (Tim Tyler) wrote in <[EMAIL PROTECTED]>:
>:>Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
>
>:>: If my message is over one hundred bytes, do you think
>:>: that I need to care about wasting 5 bits?? [...]
>:>
>:>At worst, this can reduce the size of keyspace by a factor of 32.
>:>
>:>It might make the difference between an analyst looking at 32
>:>different possible messages, and one unique one.
>:>
>:>Of course, whether you consider this sort of thing to be potentially
>:>important is up to you.
>
>: Tim as a thought experiment I tried to do a very simple calulation
>: that seems to round to zero on my HP 15C suppose one is writting
>: a random file with only 255 character types. make the file 65,636
>: bytes long. And use the 256th character type as a EOF marker. One
>: could view MoK problem like this. The file I was statically compress
>: ing has each symbol occurring the same number of times. so the tree
>: reduce to the one where all lengths 8 bits. WHat are the odds if one
>: encrypts this string that when one uses a false key that it could be
>: a valid string witch could have been compressed. Well it would have to
>: be a file that does not contain the 256th charter in all but the last
>: byte. looking at only the last byte you eliminate all but 1 out 256
>: weaking the key by 8 bits. But what is the chance that the 256th bit
>: EOF marker will not appear in the first 65,636 bytes. It is (
>: 255/256)**(65,636) which is "ZERO". Well it can't be zero but I think
>: you will agree it will weaken the key so that if an AES candidate was
>: used the only key that fits is the one used for the encryption.
>
>While these sums are correct there are other methods of ending Huffman
>symbol strings that don't necessitate using an EOF marker, that don't
>go as far as your 1-1 method.
>
>All you need is to make sure that some 8-bit-or-greater length symbols
>remain in the Huffman tree. If there are any objects with a frequency
>of < 1/256, this is going to be the case anyway. Then just stick
>a partial symbol at the end of the file as a terminator (if the exact
>EOF has not been reached).
>
>This isn't ever going to reduce the keyspace by more than 8 bits.
This is a lot better than using's Mok EOF symbol. I think for
most cases you could safely use this for compression before encryption
but there are a few rare cases that can sneak by. Example you compress
a file and enemy guesses a key and tries to uncompress. If he gets a
strange tree where 2 symbols have a length of say 24 bits. And the last
symbol is finished 2 bytes earler and yet not at end of tree, You scheme
is only using the last 1 to 7 bits as padding. If a symbol is being
decoded that spans more than a few bytes and the file ends. The attacker
can throw that key out since the file he is exaiming could not have come
from your compression method. But I agress this is a rare case and
maybe you don't have to worry about 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: [EMAIL PROTECTED] (John Savard)
Subject: Re: t
Date: Thu, 21 Sep 2000 13:39:42 GMT
On Thu, 21 Sep 2000 00:31:51 -0400, "Douglas A. Gwyn"
<[EMAIL PROTECTED]> wrote, in part:
>lala wrote:
>> t
>Yes, indeed. In fact that (although in upper case) was the
>entire content of the first page of an experimental book I
>once wrote, which explored how much communication might be
>developed between agents that could perceive the symbols but
>had utterly different modes of thought and no a priori shared
>knowledge. The second page was
> NNT
>The third was
> NF
>You get the idea (maybe).
But the plot is cliched. I can guess how the book begins. Something
like:
T
NNT
NF
TOT
TOF
FOT
TIT
FIT
FIF
TET
FEF
TAT
LTR
LNNTR
LNFR
LTOTR
LTOFR
LFOTR
LTITR
LFITR
LFIFR
LTETR
LFEFR
LTATR
TALFOTR
NLLTAFROTR
NLFOFR
NLTIFR
NLTEFR
NLFETR
NLTAFR
NLFATR
NLFAFR
At least it deserves to be filed in the non-fiction section.
John Savard
http://home.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: [EMAIL PROTECTED] (DJohn37050)
Date: 21 Sep 2000 14:17:36 GMT
Subject: Re: Dr Mike's "Implementing Elliptic Curve Cryptography" - reader comment
NO, NIST recommendation is NOT to add a few hundred bits when using a binary
field. In fact there smallest recommended curve is over a binary field.
Don Johnson
------------------------------
From: "Aurelien" <[EMAIL PROTECTED]>
Subject: decrypt
Date: Thu, 21 Sep 2000 14:18:39 GMT
Could someone decrypts that and explain me how he did ?
The public key is (143;7)
The spaces dont matter
Mes_crypt1 =BNC5({E A H({CTRL-H
Mes_crypt2 =SYS
Mes_crypt3 =31h1CTRL-H 61CTRL-H BSINFIN { CTRL-H
Mes_crypt4 ={C1 B6A|{1 ES|(6(H1 CTRL-P{S
Mes_crypt5 =H({#({E CTRL-H F({ CTRL-H
Mes_crypt6 =AYY{1S661 1C
Mes_crypt7 =|AEACHS CTRL-H CTRL-H ACH {C1 B(CC1
Mes_crypt8 =1CH1CH1
Thanx !
------------------------------
From: John Myre <[EMAIL PROTECTED]>
Subject: Re: Double Encryption Illegal?
Date: Thu, 21 Sep 2000 08:21:54 -0600
Guy Macon wrote:
<snip>
> Oh, *real* clever, Arturo. Did you think that nobody would notice
> you double encrypting your post using ROT13? Well *I* noticed, and
> I double DEcrypted it with ROT13 bnefor replying. So there!
"bnefor"?
I think there is a bug in your ROT13 implementation.
JM
------------------------------
From: Doug Kuhlman <[EMAIL PROTECTED]>
Subject: Re: Even-Mansour extension?
Date: Thu, 21 Sep 2000 08:57:29 -0500
"David A. Wagner" wrote:
>
> Doug Kuhlman <[EMAIL PROTECTED]> wrote:
> > Idea #1: ciphertext = P(m ^ k) ^ (k~) where (k~) is k with the bit order reversed.
>
> The sliding attack works against the general Even-Mansour scheme,
> c = P(m^k) ^ k', where k,k' are arbitrary pieces of key material,
> so yes, it works against the case where k' = k~, too. The attack
> complexity, as in the original Even-Mansour scheme, is 2^{n/2} texts
> and 2^{n/2} time for the analysis, for a n-bit permutation P.
>
I obviously didn't understand as well as I thought I did....
Is this the "sliding with a twist" you describe in your paper? I think
I'm finally starting to understand. Maybe it's the "talking to the
teacher" phenemenon at work.
> > Idea #2: ciphertext = P(P(m ^ k) ^ k) ^k
>
> Hmm. I don't think this helps -- I think it is no more secure than
> Even-Mansour. The slide attack can be extended to break this scheme,
> with similar complexity to the original attack against Even-Mansour.
>
> The trick is to set up a slide relation as depicted here:
> k
> P
> k k
> P P
> k k
> P
> k
> The left-hand column represents an encryption of message m to ciphertext c;
> the right-hand represents encryption of m' to c'. To form a slid pair,
> we hope that m' = P(m^k); when this is true, we will have c' = P(c)^k.
>
> Thus, if we let Q denote the inverse of the permutation P, we have
> Q(m') ^ c' = (m^k) ^ (P(c)^k) = m ^ P(c)
> for a slid pair.
>
> Consequently, we may store Q(m')^c' in a lookup table for each known text
> (p',c'), and store m^P(c) for each text (p,c), and look for collisions as
> in the original slide attack. Each such collision discloses a possible
> slid pair, and each slid pair discloses the key k.
>
> The total complexity is 2^{n/2} known texts and 2^{n/2} time for the analysis.
Wow! This makes so much sense. I couldn't quite make that leap when
just reading your paper and fiddling around on my own.
I get lost at the next stage, though, where I combine these two ideas
into idea 3:
c=P(P(m ^ k1) ^ k2) ^ k3
I couldn't figure out how to directly address this with sliding with a
twist. My thought was to make Pk2P into one step called Ek2 (encryption
with k2). Then I set up a twisted slid pair
k1
Ek2
k3 k3
Dk2
k1
where Dk2 is the inverse of Ek2. Call the left side m->c and right side
c'->m' and I get a slide pair k1=m ^ Dk2(c')=m' ^ Dk2(c).
This is where I falter. It seems like computing Dk2(c) would require
brute force across k2, which in the DESX case is only 56 bits but in
mine is the full length of the key. Any hope here? Or have I made a
fatal mistake along the line?
Thanks again for the help!
Doug
------------------------------
From: Bob Silverman <[EMAIL PROTECTED]>
Crossposted-To: comp.databases.oracle
Subject: Re: Double Encryption Illegal?
Date: Thu, 21 Sep 2000 14:33:33 GMT
In article <8pvejh$g03$[EMAIL PROTECTED]>,
"PRdO" <[EMAIL PROTECTED]> wrote:
> IMHO double encryption *does not* add security, i.e., double
encryption in
> 128-bit doesn't equal better encryption.
> (since encryption uses random keys, "randoming" again the data would
not
> lead to more secure data).
This post looks very much like a troll, but I will answer it anyway...
Fortunately, for people who bother to think, cryptographic methods are
not confirmed or discarded by popular opinion. What matters is
analysis, and under this rubrik, your opinion isn't worth very much.
This is especially true since the way you pose your remarks
(i.e. "randoming" the data) indicates that precision of thought and
you have not yet met.
--
Bob Silverman
"You can lead a horse's ass to knowledge, but you can't make him think"
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Tying Up Loose Ends - Correction
Date: 21 Sep 2000 14:31:11 GMT
[EMAIL PROTECTED] (John Savard) wrote in
<[EMAIL PROTECTED]>:
>On Wed, 20 Sep 2000 15:03:10 GMT, Tim Tyler <[EMAIL PROTECTED]> wrote, in
>part:
>
>>An alternative - which I've not seen discussed on this forum - would be
>>to use an encryption device which is capable of encrypting variable
>>length bitstrings, and is not confined to multiples of 8 bits. I
>>attribute this idea to David Scott.
>
>No, don't.
>
>Actually, encrypting that way is the 'default' idea. Otherwise, for
>example, the arrangement illustrated in Bruce Schneier's _Applied
>Cryptography_ called "ciphertext stealing" would never have been
>proposed, people would just encipher the last 64 bits (or the last
>eight bytes) of the message in normal order as a block after
>encryption on 64-bit boundaries was concluded.
You mean to tell me the article talks about compressing to
a finitely odd file and then using the last "one" to mark the
end of the useful data. Or does it refer to whole bytes going
into something like an 8 byte encryption block.
>
>I believe that PGP does it that way, although as David Scott was the
>first to point out to my knowledge, it didn't use CBC as claimed in
>its documentation, but instead uses CFB mode, I suppose one can't
>trust the documentation.
>
>John Savard
>http://home.ecn.ab.ca/~jsavard/crypto.htm
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] (Padgett 0sirius)
Subject: Re: Software patents are evil.
Date: Wed, 20 Sep 2000 21:34:28
Personal opinion: Patents in the US tend to stifle technology rather than
encourage it. Software is more properly protected by Copyright than patent.
For just one example see the Selden patent and the ALAM.
Think part of the problem with patents is that 20 years is far too long.
It may have been appropriate in 1800 but not in 2000 with obsolecence
averaging three years.
UDA.
A. Padgett Peterson, P.E. CISSP: Cybernetic Psychophysicist
http://www.freivald.org/~padgett/index.html
to avoid antispam use mailto:[EMAIL PROTECTED] PGP 6.5 Public Key Available
------------------------------
Date: Thu, 21 Sep 2000 11:05:11 -0400
From: "Trevor L. Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: Tying Up Loose Ends - Correction
Tim Tyler wrote:
> Trevor L. Jackson, III <[EMAIL PROTECTED]> wrote:
> : Tim Tyler wrote:
> :> John Savard <[EMAIL PROTECTED]> wrote:
>
> [sorry about all the quoting]
>
> :> : I think that trying to remove redundancy as far as possible is a good
> :> : idea. While I disagree with Mr. Scott on one detail on his 1-1 scheme []
> :>
> :> It seems that any technique which takes a bitstreams and converts them
> :> reversibly to files of 8-bit bytes will exhibit some statistical
> :> anomolies, of the type I believe you're objecting to.
> :>
> :> Any system which attempts to avoid such artefacts completely seems
> :> obliged to use some sort of random padding.
> :>
> :> John's scheme proposes adding such padding after coompressing, and before
> :> encryption.
> :>
> :> An alternative - which I've not seen discussed on this forum - would be
> :> to use an encryption device which is capable of encrypting variable length
> :> bitstrings, and is not confined to multiples of 8 bits. I attribute this
> :> idea to David Scott.
> :>
> :> Indeed - if dealing with the output of an arithmetic compressor, files
> :> of a fractional number of bits in length are also possible - i.e. a
> :> message may be 10.5 bits long.
> :>
> :> After the compresssed file is encrypted, it can be safely padded out with
> :> zeros, to a byte boundary without any security concerns. If you want to
> :> obscure the length of the file from your adversary, as much random padding
> :> as you like can be used at this stage.
>
> : The fails to meet his criteria that any bitstream be both plain and
> : compressed text.
>
> I presume you refer to David Scott's criteria?
Yes.
>
> I think we're on different tracks here. David's criteriaon (if I
> interpret this reference correctly) was intended to apply to the
> output of compression programs.
As I understand it his criteria is that a non-leaking compression is one that
uniquely encodes a given bitstream into a compressed form and uniquely decodes
that same bitstream into an uncompressed form. (The "compressed" and
"uncompressed" forms are not necessarily smaller and larger respectively than the
given bitstream).
Artifacts introduced by the quantization of the bitstream (byte boundaries) are
distinct from the reversible uniqueness requirement.
>
> The type of compression employed above was deliberately not specified.
> If a suitable compressor was used, it's output would indeed fulfill
> David's criterion.
First, if random padding were used to fuzz the length of the bitstream (it cannot
be obscured completely) the uniqueness property is lost. Second, decompression
of an arbitrary bitstream is not guaranteed to provide a unique result unless
consideration is given to that issue. It appears that the description you gave
above may not enforce that requirement.
> Your objection seems ambiguous. I can't see how it applies to the
> system described above.
Yeah, it was too terse. Sorry.
>
> If there's a problem with theprocess described, it seems to be that I
> didn't specify how to distinguish any random padding from the data.
> This is not an issue I feel inclined to go into at this juncture.
OK, then it remains outstanding.
------------------------------
** 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
******************************
