Cryptography-Digest Digest #84, Volume #10 Fri, 20 Aug 99 14:13:02 EDT
Contents:
Cryptomathic Denamrk ("Bartek Z.")
How does Sybase encrypt SQL Anywhere? (Michael Heumann)
Re: *2nd* trusted arbitrator's name?? (John Myre)
Re: What's wrong with Mr. Scott? (Stephan Eisvogel)
Re: CRYPTO DESIGN MY VIEW (SCOTT19U.ZIP_GUY)
Re: What is the New "Relativity" encryption technique by Dr. Kent in current
Physical Review Letters (John Bailey)
Re: CRYPTO DESIGN MY VIEW (SCOTT19U.ZIP_GUY)
Re: NIST AES FInalists are.... (John Savard)
Re: DoD & ITU under attack ? (Paul Koning)
Re: Decrypted International Crypto inside the US (Paul Koning)
Re: I need strongest weak elliptic curve... (Medical Electronics Lab)
Re: Decrypted International Crypto inside the US ("Douglas A. Gwyn")
Re: I need strongest weak elliptic curve... ("Douglas A. Gwyn")
Re: New encryption algorithm ("Douglas A. Gwyn")
Crypto for PALM III? (grimm)
Re: New encryption algorithm ("Douglas A. Gwyn")
Re: bias of boolean expressions ("Douglas A. Gwyn")
Re: PRNG Stream cipher questions (James Andrews)
Re: compress then encrypt? (Anton Stiglic)
----------------------------------------------------------------------------
From: "Bartek Z." <[EMAIL PROTECTED]>
Subject: Cryptomathic Denamrk
Date: Fri, 20 Aug 1999 13:54:31 GMT
Hi,
Have You ever heard of Cryptomathic (Denmark) company? I mean if their
product are widely known and good or what?
Regards,
bartek
------------------------------
From: Michael Heumann <[EMAIL PROTECTED]>
Subject: How does Sybase encrypt SQL Anywhere?
Date: Fri, 20 Aug 1999 13:57:50 GMT
Hi,
I wonder how Sybase encrypt their SQL Anywhere 6 databases. There is an
option for "encrypted". I wasn't able to get any comment from Sybase
neither in their newsgroup nor through email to their site. I guess
this is not a very good sign.
Is it proprietary? I read a speculation about 40-bit keys.
Does anyone know something? Or else, how could I find out?
Thanks,
Michael.
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: John Myre <[EMAIL PROTECTED]>
Subject: Re: *2nd* trusted arbitrator's name??
Date: Fri, 20 Aug 1999 08:10:58 -0600
Jerry Coffin wrote:
>
> In article <[EMAIL PROTECTED]>,
> [EMAIL PROTECTED] says...
>
> [ ... ]
>
> > Does the phrase "Trojan Horse" ring any bells ?
> >
> > Perhaps we should save the name "Troy" to represent an "trusted
> > arbitrator" of the less than perfect sort ?
>
> Keeping in mind that the Trojans were the people in the city who were
> betrayed by accepting the horse. The Greeks were the ones who
> couldn't be trusted. (This is the source of the line about not
> trusting Greeks, even when bearing gifts...)
So would Troy be honest but insecure?
John M.
P.S.
I liked Tracy and Tria better, although the point about
using different initial letters in another post was
well taken; how about Uri (as long as it doesn't start
with "Un"...).
------------------------------
From: Stephan Eisvogel <[EMAIL PROTECTED]>
Subject: Re: What's wrong with Mr. Scott?
Date: Fri, 20 Aug 1999 16:44:36 +0200
"SCOTT19U.ZIP_GUY" wrote:
> [..] I think I treat all people
> the same. Well I have been pissed at a few people [..]
*chuckle*
--se
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: CRYPTO DESIGN MY VIEW
Date: Fri, 20 Aug 1999 16:42:02 GMT
In article <[EMAIL PROTECTED]>, Mok-Kong Shen
<[EMAIL PROTECTED]> wrote:
>SCOTT19U.ZIP_GUY wrote:
>>
>
>> >John Savard wrote:
>> >>
>> >
>> >> For example, in compressing English text with word spacing, it is
>> >> better not to include a symbol for the space character in the same
>> >> Huffman code as the letters of the alphabet. Instead, have one Huffman
>> >> code for the alphabet, and a separate one based on the distribution of
>> >> the lengths of words, and alternate between the two codes.
>> >
>> >Could you explain a bit? Suppose I have the string 'ab cde', what will
>> >be output, if H(a) is the Huffman code of a?
>> >
>> >M. K. Shen
>
>>
>> I know you did not want this but you at least you where kind enough to
>> give John an example. In my adaptive huffman coding method.
>> the "a" since one of 256 bit unknowns. would be 8 bits in length.
>> the next letter the "b" could be represented by 8 to 9 bits. It
>> all depends on where the symbol ends up in the huffman tree.
>> If it ended up with eight bits it would be the next byte out. In which
>> case it is the same size. If it ends up being nine bits in lenght and the
>> last bit is a "one" only the first 8 bits are written out. If is nine bits
>> and the last bit is a 0 then 2 bytes written out. So to sum this up
>> for a 2 characters input file my code would output 2 or 3 bytes for
>> the compressed file. However if you use a hex editor and change
>> that 2 or 3 byte file to anything. And then decompress it. No matter
>> what file you get call it "X". When you recompress "X" you get back
>> the hex edited file exactly as you left it changed.
>
>Indeed you haven't dealt with the question that I was addressing
>to Savard. He was using besides the Huffman encoding another
>coding scheme to represent the inter-word spaces. My question was
>how these two different codes can be mixed in one stream and what
>the nature of that another coding stream is.
>
Your other message got dropped but here was the response to
that one!
First of all the proof is in the working program. Find an example
od where a file that when being decompressed and then compressed
again does not back to the same and you haev found a error
the file ... xxxxxxxy yyyyyyyy would decompress to what I guess
you want.
the file xxxxxxxxy and the last byte gone would decompress to
something different. But when you compress the file you got from
decompressing you get a file that ends with xxxxxxxy
The coding is such that xxxxxxxy yyyyyyyy and xxxxxxxy yyyyyyyy
can not decompress to the same file since the compression decompression
all map "one to one"
now that being said if y = "0" then since it started after the last string
it would mark the end of file in the short version. If Y='"1" in the
short version then the last symbol decompressed would be 1111... up to at most
8 1's tell a valid symbol is decoded.
It is that simple.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
http://members.xoom.com/ecil/index.htm
NOTE EMAIL address is for SPAMERS
------------------------------
From: [EMAIL PROTECTED] (John Bailey)
Subject: Re: What is the New "Relativity" encryption technique by Dr. Kent in current
Physical Review Letters
Date: Fri, 20 Aug 1999 15:49:24 GMT
On Fri, 20 Aug 1999 05:42:06 GMT, [EMAIL PROTECTED] (Vero D'
Monopolia) wrote:
>Anybody got any more details than this lame CNN blurb at
>http://www.cnn.com/NATURE/9908/17/science.cryptography.reut/
>
I found Kent's article in the August 16 issue of Physics Letters. (vol
83, number 7)
Here is a rough summary. Really rough. I wanted to spend more time
and get it closer to right but this is close enough to right as to
allow someone to determine whether they want to dig further. There
are lots of holes and inconsistencies but take it for what its worth.
The process requires two separated stations for each of the two
participants. In other words four stations: A, A', B, B'. It relies on
the time delay between the stations to insure that A cannot know what
A' received from B' and then returned before B knows, etc. The
protocol is based on one party selecting from a tagged pair of numbers
to commit to a bit. Each transmission requires a follow-up
transmission which commits the bits needed to encode the numbers of
the preceding transmission. Thus the number of pre-agreed number
pairs used grows exponentially for as long as the original bit
committment remains hidden.
The exchange begins after A selects a long list of tagged number pairs
to be used to indicate B's bit committments Then A sends a pair to B
who selects one of the pair, adds a random value to it and returns it
to A. When B reveals the random number, A will know B's bit
committment, but A must be sure B cannot manipulate the answer after
the fact. So B must now commit to the bits which comprise the random
value added in the previous transmission. Let m be the number of bits
needed to represent the random value added. A sends m pairs of numbers
to B, who selects one of the pair for each of the m digits. This
process must be repeated and maintained for as long as the bit
committment is not unveiled. When it is to be unveiled, all the
undisclosed data (the random values) are returned to A who can verify
that all transmissions were valid.
I hope this is enough to give a general idea of the protocol. The
bulk of the article discusses attacks to which quantum bit committment
is vulnerable, the critical times and how this protocol circumvents
these attacks.
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: CRYPTO DESIGN MY VIEW
Date: Fri, 20 Aug 1999 16:43:58 GMT
In article <[EMAIL PROTECTED]>, Mok-Kong Shen
<[EMAIL PROTECTED]> wrote:
>SCOTT19U.ZIP_GUY wrote:
>>
>> IT work one time I designed code to align data from various sources.
>> A common tho easy to solve problem. I came up with a closed form
>> soultion. It was easy enough that even a lazy Phd type could follow it.
>> While during the documentation phase this guy who was also suspose
>> to be an expert in fortran was tasked with looking at my code to see if
>> it really followed the closed form solution. He said the program was to
>> short and the coding to unorganized that it could not possible do
>> what I said it did. I told my boss the guy was full of shit. He tried to
>> make up cases where it failed. He could not make it fail.
>
>If you have a 'closed form' solution, that means you can express
>that in a mathematical form conveniently. That implies you can
>express it in texts together perhaps with some English. This shows
>once again that abstract description is always to be preferred and
>C codes and the like are not!
>
This may show it to you. But no way in hell does this
show it to me. It just means we don't agree period.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
http://members.xoom.com/ecil/index.htm
NOTE EMAIL address is for SPAMERS
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: NIST AES FInalists are....
Date: Fri, 20 Aug 1999 16:02:31 GMT
[EMAIL PROTECTED] (David Wagner) wrote, in part:
>I think it takes great skill to construct this type of an algorithm.
>Academics probably aren't capable of this. (Most academic constructions
>follow the ``overkill'' approach: add a 2x margin of error, for safety.)
And then there are amateurs like myself who, not being as
knowledgeable as the Eli Bihams, Don Coppersmiths - or David Wagners -
of this world, who allow 100x safety margins. (When in need of a good
chuckle, take a peek at my Quadibloc III algorithm...)
John Savard ( teneerf<- )
http://www.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: Paul Koning <[EMAIL PROTECTED]>
Subject: Re: DoD & ITU under attack ?
Date: Fri, 20 Aug 1999 11:40:03 -0400
Medical Electronics Lab wrote:
>
> Padgett 0sirius wrote:
> >...
> > Recently pressure is being put on the ITU to relax this requirement and
> > permit on-line servers which hold user's private keys. I suspect this
> > pressure is from vendors whose products require online KMS machines.
> >
> > Given the current state of COTS servers, I feel this would be a
> > serious mistake and that key generation should always be done either offline
> > or by a machine on an MLS protected subnet behind an evaluated guard.
> >...
>
> Why use systems which require holding user's private keys? Change
> the requirements so that no private keys are held anywhere, let the
> user regenerate it each time. You _could_ escrow the keys with a
> CA key, but that too should be off line.
>
> Anything that holds user's private keys and is accessable to the
> net will be attacked.
I agree.
Having private keys held by third parties is a Bad Idea.
Having those third parties keep the keys on-line is an ABSURD idea.
Especially given that most machines run MS software, which was never
designed with even the slightest concept of security anywhere.
paul
------------------------------
From: Paul Koning <[EMAIL PROTECTED]>
Subject: Re: Decrypted International Crypto inside the US
Date: Fri, 20 Aug 1999 11:36:57 -0400
"SCOTT19U.ZIP_GUY" wrote:
>
> In article <[EMAIL PROTECTED]>, Paul Koning <[EMAIL PROTECTED]> wrote:
> >The regulation says that you may not use any "codes or ciphers" whose
> >purpose is to conceal the meaning of the message. Encodings
> >whose specs are public, such as various modulation schemes
> >even if quite complex, are explicitly allowed (97.113(a)(4)).
> >
> And who decides if the specs are "public"
Well, I suppose if it's published then it's public. Post it on a
website that everyone has access to. Send out the code under GPL.
Stuff like that.
> >There's also one exception which shows lack of understanding:
> >in command links for amateur satellites, encryption may be
> >used (97.211(b)). Of course, that's silly; encryption is neither
> >necessary nor sufficient, what's needed is authentication & data
> >integrity with replay prevention.
> >
> Well I think that the word encryption here is valid. It is just that
> your obessed with making encryption on the bands illegael but
> they realized that in some cases "like commands to a stellite"
> that it is needed. You are just trying to side step the issue by
> hiding behind other wrods. Authentication of a mesasge can
> only occur if that message was using something encyrpted.
Well, you're wrong. You're completely wrong. Encryption has
never been necessary (nor sufficient) to do authentication,
as anyone with basic understanding of the field knows. A signed
hash will give you data integrity, and a sequence number or time
stamp as part of that signed data will let you do replay prevention.
Apart from that, you insist on writing personal insults
when all I'm doing is describing FCC regulations. You have
absolutely no basis to assert that I'm "obessed [sic] with making
encryption on the bands illegael [sic]". I have never said anything
that might let you make valid guesses about what my politics are
in this area. But if I had (assuming you have the brains to
parse what I say, which is extremely unlikely) you would know
better.
paul
PS. Does anyone here know how to set up a killfile in
the Netscape news reader?
------------------------------
From: Medical Electronics Lab <[EMAIL PROTECTED]>
Subject: Re: I need strongest weak elliptic curve...
Date: Fri, 20 Aug 1999 12:14:44 -0500
Doug Stell wrote:
> I was told last week that the U.S. has not yet aligned its rules with
> the Wassenaar agreement. It's still ITAR, CJs, IVLs as ususal for
> crypto products.
So the US drove everyone to create this thing, and then they
don't use it themselves. I shouldn't be supprised.
I suspect that as long as it falls into the catagory of "junk",
nobody will waste their time bothering a site that has crypto
on it. But if there's any sales, then they'll have to go after
the junk cases too, since that's an obvious violation of the
rules.
Patience, persistence, truth,
Dr. mike
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Decrypted International Crypto inside the US
Date: Fri, 20 Aug 1999 15:03:20 GMT
Jim Dunnett wrote:
>
> On Thu, 19 Aug 1999 01:12:31 GMT, [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
> wrote:
> ... radio experimentation. Why would Amateurs require any sort of crypto?
There are many possible reasons, including experimentation with
ways to combine encryption and error correction in a practical
setting.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: I need strongest weak elliptic curve...
Date: Fri, 20 Aug 1999 14:59:34 GMT
Doug Stell wrote:
> On Thu, 19 Aug 1999 19:27:52 GMT, Greg <[EMAIL PROTECTED]> wrote:
> >Actually, I posted this while I was waiting for NSA's response to the
> >same question. They say that 163 bit and less is exportable without a
> >license but requires a one time review none the less.
> I'm glad that they have established a policy for ECC, but am surprised
> at the key length.
I suspect now we're going to hear debate about what that implies.
Does it have anything to do with 164 being the smallest Hildegger
number? :-)
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: New encryption algorithm
Date: Fri, 20 Aug 1999 14:42:59 GMT
"SCOTT19U.ZIP_GUY" wrote:
> I am not declinging but still want the apology first.
You must realize that that is not likely to happen,
especially if your theories about those people are true,
because they would then would be helping you to get your
ideas published.
So it sounds very much like a rationalization for not
making the attempt to publish your method in a form
that can be widely understood and, yes, criticized.
------------------------------
From: grimm <[EMAIL PROTECTED]>
Subject: Crypto for PALM III?
Date: Fri, 20 Aug 1999 13:16:36 -0400
greetings,
Like many others, I'm finding myself using my PALM III
a great deal, but I would really like to know what you
guys have to say about encryption programs for the
palm III. I have tried a few and seen many which have
already been cracked.
I have also seen many supposed 128 bit encryption
programs which don't even bother masking the password
entry box.
There must be someone out here who has some suggestions
on advanced crypto packages for the palm III. When is
Palm PGP coming out? <grin>.
[EMAIL PROTECTED]
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: New encryption algorithm
Date: Fri, 20 Aug 1999 14:37:45 GMT
"SCOTT19U.ZIP_GUY" wrote:
> Also I have afeeling that they would not publish my stuff
So long as it was an interesting article, they would.
I know some of the editorial and publishing staff of
such magazines personally, and none of them strike me
as likely to bow to pressure to suppress lawful articles.
I think the main obstacle in your case would be in
getting help in editorial/typographic matters and in
resisting the urge to give a "soapbox" speech. So it
might be best to assist somebody else who does the bulk
of the writing.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: bias of boolean expressions
Date: Fri, 20 Aug 1999 15:19:02 GMT
Tom St Denis wrote:
> What is the generic algorithm to find the bias towards 0 (or 1) in an
> expression?
> Can we use F(a,b,c) = ((a and b) or (a and c) or (b and c)) as an
> example? (or just ((a or b) and c)) ...
I'm not sure what you mean by "bias in an expression".
If you mean, for uniformly distributed (a,b,c) in [0,1]x[0,1]x[0,1],
what is twice the difference between the expected value of F(a,b,c)
and 0.5, that's easy: Average the values of F(a,b,c) for the 2x2x2
possible combinations of (a,b,c), subtract 0.5, multiply by 2.
Another interesting thing to compute is F(0,5,0.5,0.5) where
a AND b => a*b
NOT a => 1-a
a OR b => a+b-a*b
etc.
There are also ways to compare a set of (a,b,c) samples against
the theoretical function F(a,b,c), and a measure of the best
possible linear approximation to an arbitrary Boolean function.
------------------------------
From: James Andrews <[EMAIL PROTECTED]>
Subject: Re: PRNG Stream cipher questions
Date: Fri, 20 Aug 1999 17:24:51 +0000
Reply-To: [EMAIL PROTECTED]
> Sounds like you're reinventing the transposition cipher. They way it
> worked was you would break up the text into n character strings and line
> them up in rows, something like this:
>
> abcdef
> ghijkl
> mn opq
>
> The key is used to reorder the columns. In our example, if the key was
> 253641, the ciphertext would look like this:
>
> becfda
> hkiljg
> np qom
>
> You would then concatenate the rows so it looks like garbled text. This
> is an old manual encryption method that was used. As far as I know, no
> modern encryption algorithm does this in any form, but I could be wrong.
>
> Casey
Your description is similar to what I had in mind, but a very simplistic
form thereof. The thinking behind what I intend is that many of the
clues left by an encryption process are probably due to certain range
limitations imposed by the actual programmers methods. What I intend is
a transposition cipher, but rather than basing it on byte boundaries or
arbitrarily sized byte-multiple blocks, allowing the PRNG to specify
block transpositions on bit boundaries, and of sizes denoted in bits,
this way shuffling the data at the lowest level. If a PRNG stream
cipher method were performed on the resultant blocks, the results would
surely illicit very little, if any, direct relationship between the PRNG
and the plaintext used, without the seed. Again, as with all of my
posts, I dont pretend to be an expert, just an interested party, if this
has been done before/proven fallible etc, please let me know. Below is
the complete breakdown of how I'd like to implement this algorithm.
The algorithm requires 5 seeds (32 bit integers) for the random number
generators.
Each PRNG returns 32 bit unsigned integers.
All bitwise descriptions assume big-endian style.
The first PRNG, PRNG1, is used to break the data stream into blocks.
Each block is between 1 and 32 bits in length.
The first number generated by PRNG1 is logically anded with 0xf and
added to 16 to create a number between 16 and 31. This is the writeback
buffer length.
block block
size weight
5 bits 27 bits
/----\/-----------------------------\
[------------- 32 bits ---------------]
The blocks are stored in a linked list, by weight, the lowest weight
first. Once the buffer either contains the entire file to be encrypted,
or reaches the writeback buffer length, the lowest numbered blocks start
being processed.
The processing requires the remaining 4 PRNGs. The first of which is
used to decide what processing will be required.
PRNG2 control integer:
bits 0-2, stream order control
000 : A->B->C
001 : B->C->A
010 : C->A->B
011 : A->C->B
100 : C->B->A
101 : B->A->C
110 : A->!B->C
111 : C->B->!A
bits 3-4, stream usage control
00 : a, b, c
01 : a, b
10 : b, c
11 : a, c
bits 5-6, stream a operator control
00 : addition
01 : subtraction
10 : exclusive or
11 : logical shift
The data for the operations is provided by each of the 3 remaining
streams, PRNG3, PRNG4, PRNG5.
After the information has been processed using the above stream cipher,
it is written back in the weighted order.
This process is relatively simple to reverse, but can cause you to feel
like a pig shat in your head if you try to work it out. I think I'll
call it (unimaginative mode on) CM26b, there is a reason for the
naming. If anyone can spot any glaring problems, please, please let me
know before I start implementing it. Any thoughts? Thanks in advance,
James
------------------------------
From: Anton Stiglic <[EMAIL PROTECTED]>
Subject: Re: compress then encrypt?
Date: Fri, 20 Aug 1999 14:04:27 -0400
One little note: it is impossible to compress uniformely random data.
That is, say you have a (suposevly good) compression function
C:X -> Y, where you compute elements (x) that are uniform-
randomly choosen from X, then your function could reduce the size
of some outputs, but will blow up for others (that is , instead of
compressing, you expand your input). Compression algo. rely on
the fact that they are not used for all x in X, or mostly, there is heigher
probability of choosing x in S, where S is a subset of X. English texts,
for example, form a small subset of the sets of all finit strings of letters.
Code written in Java is another example.
One conclusion, if you want your encryption algo to produce stuff that
looks like random, then yes, it is a good test to try compressing it with
different algos... it should not compress to much, some entries should
blow up.
anton
------------------------------
** 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
******************************
