Cryptography-Digest Digest #84, Volume #11 Wed, 9 Feb 00 20:13:01 EST
Contents:
Free web space ("finecrypt")
Re: Student security columnist wanted for ACM Crossroads ("Douglas A. Gwyn")
*** Puzzle for the most persistant of hackers *** (serialno23)
Re: new standart for encryption software... ("finecrypt")
Re: ("Douglas A. Gwyn")
Re: I'm returning the Dr Dobbs CDROM ("Douglas A. Gwyn")
Re: I'm returning the Dr Dobbs CDROM ("Douglas A. Gwyn")
Re: NIST, AES at RSA conference ("Douglas A. Gwyn")
Re: New standart for encryption software. ("Douglas A. Gwyn")
Re: Language Challenge 2000 ("Douglas A. Gwyn")
Re: Actually you can see me here .. with your RealPlayer ... ("Douglas A. Gwyn")
Re: new standart for encryption software... (Eric Lee Green)
Re: New standart for encryption software (Paul Schlyter)
Re: Anybody know about this flaw? (Paul Schlyter)
Re: New standart for encryption software. (David Wagner)
Re: DVD crypt Q (Bryan Olson)
Re: Latin Squares (was Re: Reversibly combining two bytes?) ("r.e.s.")
Re: New standart for encryption software (Johnny Bravo)
----------------------------------------------------------------------------
From: "finecrypt" <[EMAIL PROTECTED]>
Subject: Free web space
Date: Thu, 10 Feb 2000 01:59:56 +0300
Free web space for homepages (up to 30 Mb per one homepage) with
cryptography related contents. Homepage will have address
www.finecrypt.com/yourname. Email to [EMAIL PROTECTED] ready HTML pages
and within 1-2 days they will be placed on site.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Student security columnist wanted for ACM Crossroads
Date: Wed, 09 Feb 2000 23:25:53 GMT
Eric Lee Green wrote:
> A co-worker of mine was on the original ANSI "C" committee, mostly made
> up of the same academics as those who are involved with ACM activities.
> He said that on one night in 1985 he simply had enough. They were
> squabbling over some esoteric BS, not getting anything done, and finally
> he said "Look, are you interested in creating a 'C' standard, or are you
> interested in staking out academic turf? Because if you're interested in
> creating a 'C' standard, this isn't going to do it."
> There was a long silence, and finally everybody hung up.
> The next morning, his supervisor called and told him that the chair
> of the "C" committee had called, and his services were no longer
> required.
> It took close to seven more years before the "C" standard was really
> standardized, though by that time most compilers already implemented the
> worthwhile bits (and left out the esoteric academic BS... RMS, in
> particular, was apopoleptic about some of the misfeatures and swore
> they'd never make it into the GNU "C" compiler, though browsing the info
> page I see at least one of the misfeatures is available via a special
> "--ansi" flag). ...
That is almost completely false! I have been a member of the C
standards committee for some 15 years now, and participated from the
sidelines before that. While a small fraction of the C committee have
had an essentially "academic" outlook, for example suggesting formal
semantics instead of English (and in the light of experience I am much
more sympathetic to that idea), the vast majority of committee members
have always been C programmers and implementors of C compilers and
libraries. I'm not aware of *any* who have been particularly involved
with ACM activities, although some of us are certainly *members* of
the ACM -- what is supposed to be wrong with that, anyway?
The first C standard was finalized in 1988 (it wasn't ratified
until 1989, but no changes occurred during after 1988), not 1992.
Your friend might possibly have been involved somewhere along the
line, but from what you report he said, it appears that he has some
axe to grind and is fabricating an imaginary history to rationalize
his point of view. It could well be that he was wildly disruptive
at a meeting and that this was discussed with his supervisor, but
I don't know of anything resembling that. It's hard to imagine
anyone beating P.J. Plauger (you may have heard of him) in the
area of strongly expressing his opinion at meetings, but nobody
conspired to oust him! In fact, the C committee members have been
exceptionally respectful of each other's divergent points of view.
The GNU C compiler, like nearly all commercial C compilers,
attempts to fully conform to the C standard when invoked with a
full-conformance flag; in order to support their own perceptions
of their existing customer base, most C compilers default to some
not quite fully-conforming mode. (For example, spurious symbols
may be defined in <stdio.h> and <math.h>, since that's what UNIX
traditionally did and a lot of existing code made use of that.)
But it is ironic that you bring up complaints from the GCC project,
since they themselves have tended to be "academic" (in the
perjorative sense), giving the impression "it is obvious to *me*
what to do, so if X3J11 disagrees they must be stupid or malevolent".
Note that the GCC developers didn't choose to participate in the
process, although that didn't keep some of them from sniping at
it from the shadows.
The C standard underwent *several* lengthy public reviews, and
*every* comment submitted was studied by several committee members,
often by the entire committee when the response wasn't obvious from
previous decisions. Many changes resulted in the process of
considering these public comments. (Plauger and I edited the
response documents.) In order to arrive at consensus, we had to
balance numerous conflicting requirements, demands, and practical
factors. To imply that there was some academic cabal forcing an
inferior standard on the public is simply not in accordance with
reality.
> ... it appears that most academics get tenure via knowing whose
> rears to kiss, not on the basis of ability. It may be "publish or
> perish", but department heads have often been out of the trenches
> for so long that they couldn't tell a good paper from bleeding edge
> research. (Not to mention the mediocre types who are great at
> wheedling funds out of the NSF, DARPA, etc., who tend to get tenure
> simply because they pay everybody else's salaries at the place!).
Spoken like someone who is jealous of success.
There is undoubtedly room for improvement in academia, as elsewhere.
But what sort of research do you think gets done in the absence of
funding? If you really cared about research, you'd be happy that
effective obtainers of funding are retained on staff.
------------------------------
From: serialno23 <[EMAIL PROTECTED]>
Subject: *** Puzzle for the most persistant of hackers ***
Date: Wed, 09 Feb 2000 18:26:08 -0500
Does anyone know how to break this code (or have any ideas):
It was enciphered using a polyalphabetic substitution cipher (of key
length 4) by one of the foremost security experts in the country. There
will be monetary compensation involved. Pls. RSVP if you know how to do
it. We have tried the basic things like frequency analysis, Kasiski
method. Thanx.
The message starts now:
bpivm mdznk azfkw lexpl urqjf wsejm deopd gqeg. qnwju clsjn lcwea
zfwpy vkdnw emzfk wlaew xohpy kpxzj xlhcm sjyer r,mxz cflco rgijr
jlaji xqbjj m,urf mixjc puqqj o,pdg tjmwq epufw lcaky ajbfi jrtyo
apcoe mvmmu gopuy olvjm kdfxj svfkw l.pdz nkazf jiewc scqcg pkmxz
cflco rgior fvxrt jvbjj m,llf krvxp grval ldmij yrsvf flcjj duhme
pemnj rmgio glyjr p,qcu zcvld voprx rliop ujabf rnmsu ox.cg mmjum
ilmpx vdpgj rikuf peuwf dgoes cqcuc gmqzv krewc rrxbs jabfr bpddm
pxvdp gvwcs dvbpx vfsru bwgqg ,rnpe bqbpc gmjyw fgwyb sztlk yqlc,
qcuzr ejsop gcgmq rvbtj vrjhc mdznk azfkw lqxur tksvw cs.
------------------------------
From: "finecrypt" <[EMAIL PROTECTED]>
Subject: Re: new standart for encryption software...
Date: Thu, 10 Feb 2000 02:13:33 +0300
>> You can read about how FineCrypt generates keys in program's online help.
>Sorry, I don't do Windows.
Eric Lee Green,
this is a copy-past from online help:
"FineCrypt provides a method for producing a secure highly random key. To
generate the key FineCrypt scans your system to get random data that is
being hashed during the scan cycle. This cycle is repeated 1000 times by
FineCrypt. As a result, FineCrypt receives a highly random sequence of
bytes; the user key and initial vector are formed on the base of this
sequence."
Pseudo-random data that has been retrieved from system during key generation
includes 17 various values such as milliseconds since Windows started,
cursor pos.for last message, types of events in input queue, 1 ms time for
last message and so on.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re:
Date: Wed, 09 Feb 2000 23:29:59 GMT
Anthony Stephen Szopa wrote:
> "C. Prichard" wrote:
> > I prefer to think that a large number of NSA employees are
> > infiltrating internet CHAT groups to intercept secret information
> > as it is being exchanged.
> If you use secure encryption none of this matters: The NSA / CIA
> cannot decrypt it to see any "watermark(s)."
First of all, NSA is enjoined from spying on US citizens (with
certain rare exceptions), and there are mechanisms and watchdogs
in place to enforce that.
But on a technical note, if the chat groups are open ones, then
encryption cannot be used without also making it available to
any spies who might be participating in the groups.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: I'm returning the Dr Dobbs CDROM
Date: Wed, 09 Feb 2000 23:33:55 GMT
Victor Zandy wrote:
> For example, to print chapter 1 of the Stinson book (44 pages) Adobe
> acroread (x86/Solaris 2.6) creates a 500MB postscript file. I cannot
> print this file directly, probably because it is too big.
You don't have to print all pages at once!
> I don't know how the PDF files on the CDROM were prepared, but
> they look like they were scanned from physical book pages.
Probably bitmap images from scanning. PDF allows embedding of
several kinds, including bitmap images as well as more encoding
along the lines of word processors.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: I'm returning the Dr Dobbs CDROM
Date: Wed, 09 Feb 2000 23:36:11 GMT
wtshaw wrote:
> I suppose that text is TOO compact a format to use these days.
No, but to capture formatting one needs more than just character
codes. In the case under discussion, apparently the hardcopy was
simply scanned directly into bitmap images, which captures every
aspect of the printed format (with scanning resolution) in a
simple way, at the cost of size. Raster images tend to be large
compared to their useful information content.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: NIST, AES at RSA conference
Date: Wed, 09 Feb 2000 23:40:02 GMT
Terry Ritter wrote:
> ... if someone can convince me that there is an actual
> *contradiction* in my belief that multiciphering (with non-groupy
> ciphers) must increase strength at least by the amount of
> processing effort, that will, of course, change my belief.
Well, besides having refined your original claim (which people
objected to), you have also set yourself up to be able to simply
claim that any counterexample is "groupy". In other words,
whatever remains of the original "provably stronger" claim
has no real force at this point.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: New standart for encryption software.
Date: Wed, 09 Feb 2000 23:41:40 GMT
finecrypt wrote:
> First and sole program, which you can test with test vectors.
Hardly!
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Language Challenge 2000
Date: Wed, 09 Feb 2000 23:50:57 GMT
[EMAIL PROTECTED] wrote:
> mx" + Dcos(alfa) = 0
> my" + Dsin(alfa) + mg = 0
> D = .5*Cd*A*rho(y)*v^2 alfa = atan(y'/x')
m can be folded into rho, thereby factoring out of the equations.
I hope you realize that solution is almost trivial in a good
general-purpose simulation language, even in Mathematica.
Why was this challenge posted to sci.crypt? I see no connection
with cryptology.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Crossposted-To: alt.politics.org.cia,soc.culture.russian,soc.culture.israel
Subject: Re: Actually you can see me here .. with your RealPlayer ...
Date: Thu, 10 Feb 2000 00:01:15 GMT
Nick wrote:
> How do you do "kill file"?
Many mail- and news-reading interfaces include support for
"filtering" incoming messages. Often, one can automatically
route messages matching certain criteria (such as containing
certain words in the Subject header) to special mailboxes,
forward, or simply delete. Automatic deletion on the basis
of From or Reply-to header information is known as "adding
the sender to one's kill file". Some interfaces apparently
support *only* the "kill file" aspect of filtering. Whatever
applies to your particular interface should be documented,
or easily discoverable by browing the various option menus.
------------------------------
From: Eric Lee Green <[EMAIL PROTECTED]>
Subject: Re: new standart for encryption software...
Date: Wed, 09 Feb 2000 17:06:14 -0700
finecrypt wrote:
> >> You can read about how FineCrypt generates keys in program's online help.
>
> >Sorry, I don't do Windows.
> "FineCrypt provides a method for producing a secure highly random key. To
> generate the key FineCrypt scans your system to get random data that is
> being hashed during the scan cycle. This cycle is repeated 1000 times by
> FineCrypt. As a result, FineCrypt receives a highly random sequence of
> bytes; the user key and initial vector are formed on the base of this
> sequence."
Sounds like what I do to initialize Ocotillo. However, I suspect you are
overestimating the amount of available entropy. Repeating the sequence 1,000
times is not going to add 1,000 bits of entropy. In fact, it may not add any
entropy at all, if nothing happens to be changing on your system at that
moment in time. Not to mention that it is *SLOW*.
I suggest you go to http://www.counterpane.com and read Bruce's 'Yarrow'
paper. It references dozens of other papers on RNG and PRNG design which are
also useful. Design of a cryptographic-quality source of random and
pseudo-random numbers is NOT easy, and takes more work than the rather
amateurish statement that you posted above. Attacks upon the source of random
numbers are nothing new, by the way. Some German 'one time pads' were
compromised during WWII because the Germans used an easily-predicted
(mechanical) PRNG, for example. Similarly, some British one-time-pads were
compromised because, while the ladies were supposed to be pulling numbers out
of the tumbler while blindfolded, putting the number back in, and then
rotating the bingo tumbler several turns to re-randomize the number pool
before picking the next number, it turns out that some didn't understand why
they had to do all that work and kept the number out of the pool and didn't
re-tumble, they just put their hands in again and pulled another number out,
and if they didn't like the number, they would put it back and get another
number. The net result was a sequence of numbers for the one-time pad that had
certain statistical properties that made them easy to predict with the very
slightest known-plaintext that revealed a few numbers in the pad.
Note: Above stories may or may not be true. The Brits, in particular, still
have a lot of their old stuff classified, 60 years later :-).
--
Eric Lee Green [EMAIL PROTECTED]
Software Engineer Visit our Web page:
Enhanced Software Technologies, Inc. http://www.estinc.com/
(602) 470-1115 voice (602) 470-1116 fax
------------------------------
From: [EMAIL PROTECTED] (Paul Schlyter)
Subject: Re: New standart for encryption software
Date: 9 Feb 2000 23:36:23 +0100
In article <87rpfn$b7m$[EMAIL PROTECTED]>, <[EMAIL PROTECTED]> wrote:
> Jonny...while I agree with you that the claims of Finecrypt are a bit
> odd..
>
> Key ID...but that was with PGP 2.x what is it exactly they have
> patented?
>
> No Back Doors....How can they prove that?
>
> OK....But here is my question:
>
> Are you saying every Crypto vendor has to release their source code for
> examination:
If they want Jonny as a customer - yes.
> I wonder if Entrust, Verisign, Data Fellows ...are going to comply with
> your request or suggestion.
Probably not -- instead they'll look for other, more gullible, customers.
And they'll find them. And Jonny will be using free encryption software
with sourcecode available -- e.g. PGP.
> I would like some input on this....
Jonny is right: if you are to be able to form your own opinion about
the security of a product, this cannot be done properly unless you
have the source code available. If the source code isn't available
you have two choices: trust someone's claim about the security of a
product, or don't use the product. There have been a large number
of crypto product where the claimed security didn't hold.
This situation isn't much different from many other areas in society:
we frequently have to trust claims by others of the safetyl, security,
or reliability of some product we want to use. We cannot check them
all ourselves, so we have to trust others -- or avoid the products.
--
================================================================
Paul Schlyter, Swedish Amateur Astronomer's Society (SAAF)
Grev Turegatan 40, S-114 38 Stockholm, SWEDEN
e-mail: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
WWW: http://hotel04.ausys.se/pausch http://welcome.to/pausch
------------------------------
From: [EMAIL PROTECTED] (Paul Schlyter)
Subject: Re: Anybody know about this flaw?
Date: 9 Feb 2000 23:36:51 +0100
In article <[EMAIL PROTECTED]>,
No Brainer <[EMAIL PROTECTED]> wrote:
> I was wondering if anyone knows of a secure way to exchange public keys
Why would you want to do that? The keys are public, aren't they?
For public keys, no security is needed.
> between two people via Internet e-mail without using any other form of
> communication?
>
> Also, would the proposed system work if "someone unbeknownst to us" was
> intercepting and modifying the key exchanges?
If you want to agree upon a secret key with someone else, when
communicating over some tapped communication medium (telephone,
email, snailmail, whatever - assuming an eavesdropper is listening to
everything you communicate), you could use the algorithm of
Diffie-Hellman.
Or you could use RSA: send the other person your public key, and have
him encrypt the secret data with you public key and send it to you.
To decrypt these data, your secret key, known only by you, will be
needed. Now you have a secret session key, and you can use that to
exchange whatever data you want, with whatever encryption algorithm
you want.
--
================================================================
Paul Schlyter, Swedish Amateur Astronomer's Society (SAAF)
Grev Turegatan 40, S-114 38 Stockholm, SWEDEN
e-mail: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
WWW: http://hotel04.ausys.se/pausch http://welcome.to/pausch
------------------------------
From: [EMAIL PROTECTED] (David Wagner)
Subject: Re: New standart for encryption software.
Date: 9 Feb 2000 16:27:22 -0800
In article <[EMAIL PROTECTED]>,
Albert P. Belle Isle <[EMAIL PROTECTED]> wrote:
> I'm having difficulty identifying what "flawed reasoning" it is of
> which you think me/us guilty. ??
>
> Are you saying that the source code we make available for review might
> be fraudulently different from that which we compile in some newby
> error manner, as opposed to being fraudulently different in an
> intentional (spiking)
No, I'm saying your programmers may well have introduced unintenional bugs
into the system. (There's no great shame in that -- many excellent coders
have been known to make mistakes.) By making your source code available,
it becomes possible for third parties to review your code for these types
of mistakes. The goal is not to "verify" that you haven't spiked the code;
that's impossible. Instead, the goal is to increase confidence that the
programmers and system architects haven't created any inadvertent weaknesses.
For instance, take the attack on the Netscape key generator described here:
http://www.ddj.com/articles/1996/9601/9601h/9601h.htm
See especially the "Future Impact" discussion. The problem wasn't that
Netscape employees maliciously "trojaned" the source code; it was just that
they didn't know any better. Fortunately, the bug (in this case a rather
obvious one) was found by the good guys relatively quickly, through
reverse-engineering, but there are other examples where weaknesses like this
remained unknown (to the good guys!) for many years due to lack of published
details on the system.
------------------------------
From: Bryan Olson <[EMAIL PROTECTED]>
Crossposted-To: rec.video.dvd.tech
Subject: Re: DVD crypt Q
Date: Thu, 10 Feb 2000 00:23:25 GMT
Stephen Lee asked:
> I have a question about the crypto used on DVD. I have read articles
> on the web but there are some points not clear to me. This is
> regarding a PC/Mac with a DVD-ROM connected.
You may want more specific detail than I know, but I'll
explain how I understand the system to work - or rather
how it was supposed to work.
I'll use the terms "disk", "drive" and "decoder". I find
"DVD-ROM" and "player" ambiguous.
> From <http://www.dvddemystified.com/dvdfaq.html>:
>
> On the computer side, DVD decoder hardware and software must
> include a CSS decryption module. All DVD-ROM drives have extra
> firmware to exchange authentication and decryption keys with the
> CSS module in the computer.
>
> 1) I understand DVDs use the UDF filesystem. Is a Video DVD just a
> DVD-ROM with specific files on it?
Basically.
> 2) Why is authentication neccessary? I remember (maybe wrong)
> someone mentioning that some part of a DVD is not readable until the
> user authenticate with the drive. Is this true?
Suppose for a moment that the CSS title-encryption cipher
were the only content protection on an encrypted DVD. Even
without breaking the cipher, a user could simply read the
encrypted data from a DVD, and write it - still encrypted -
to other media. The copy would be just as good as the
original since all the decoders know how to decrypt.
So the system has this other layer. The decoders will only
decrypt CSS-encrypted data after (attempting to) verify that
it was read off the original disk. How can the decoder
verify the media? Well it can't really, but it tries using
the combination of drive authentication and a special area
of the disk that you mention below.
> 3) Why would the DVD-ROM need decryption key when decryption is done
> by separate hardware/software? Maybe I am misunderstanding, but if
> decryption is done by the drive, then wouldn't something like DeCSS be
> unneccessary?
If the decryption were in the drive alone, then the drive
would have to pass the decrypted compressed data across the
bus. Once a user has the decrypted compressed data, he can
simply write it to a non-encrypted DVD or other media (which
is what DeCSS does).
The way the system works, the decoder and the drive
negotiate a session key, and drive returns data encrypted
with the session key in response to read requests. Thus the
data crossing the bus is only useful in the current session.
Recording it and later feeding it a decoder will not work
because of the session encryption.
> 4) I also read that DVD-Video Disc has some special part that stores
> the decryption keys and this part is blanked on recordable DVDs.
>
> 4a) Is this true?
Yes. Remember that the system will only decrypt encrypted
titles if it reads the data from the original media. This
special part is there so the drive can distinguish the
original media from a copy. Consumer DVD-writers will not be
able to write these sectors.
> 4b) Why does the Disc need to have the key? I thought the player has
> 1 key and the Disc has its content scrambled (encrypted?) by ~400
keys?
Encrypting under 400 keys would take 400 times the space.
The data is encrypted under one master key, and the master
key encrypted under each of the 400 decoder keys. Each
decoder has one of the 400 keys.
The idea was that if one key were exposed, future movie
disks would encrypt their title key under the other 399.
That one model of decoder would fail on future disks, and
all the copying utilities using that one key would fail, but
the rest of the worlds players would be fine. A cryptologic
mistake in CSS allowed all the keys to be broken.
> 5) Where does regional code come into the picture? Where is the
> regional code stored on a disc and how is it checked? I heard newer
> DVD-ROMs has the check built in, does it mean that older drives
> hasn't and it is checked somewhere else?
It's stored somewhere in the special sectors, and
transferred to the decoder along with the session key
negotiation. As you said, newer drives enforce it (by
refusing to transfer data), and this is addition to the
enforcement required of all decoders.
--Bryan
--
email: bolson at certicom dot com
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: "r.e.s." <[EMAIL PROTECTED]>
Subject: Re: Latin Squares (was Re: Reversibly combining two bytes?)
Date: Wed, 9 Feb 2000 16:31:17 -0800
"zapzing" <[EMAIL PROTECTED]> wrote ...
: "r.e.s." <[EMAIL PROTECTED]> wrote:
: > "Tony T. Warnock" <[EMAIL PROTECTED]> wrote ...
: > : All combiners will have to be Latin squares.
: >
: > The Latin Square combiners appear to be a subset of all
: > possible combiners, corresponding to "balanced" rows &
: > columns in the table; so a combiner that's an Lsquare
: > might be *better* than one that's not, in some context,
: > but not all combiners need be Lsquares, as far as I can
: > see in common usage of the term. (But it does seem that
: > to be a combiner it must allow for later recovery of the
: > message -- resulting in N!^N possible NxN combiners.)
: >
: > To take the most extreme example:
: > If row corresponds to enciphering-symbol and column
: > corresponds to message-symbol, then for an alphabet of
: > 4 symbols even the square
: >
: > 0123
: > 0123
: > 0123
: > 0123
: >
: > yields a combiner -- but not a good one, since a given message
: > symbol will result in an output independent of enciphering
: > symbol. Whether less-extreme non-balanced (i.e. non-Lsquare)
: > combiners are ever desirable -- that would seem to be another
: > question.
: >
:
: OK, I posted about this before but apparently
: I just did not make myself clear, or something,
: so I will try again (assuming that the
: moderators will be patient with my lack of
: communication skills).
I missed your earlier posting. We're in total agreement
that a combiner need not be a Latin Square -- that's the
point I was making, after all. (I have the feeling that
your remarks are really intended for Tony, to whom I had
replied in a similar vein.)
(btw, this ng is unmoderated)
: You do *not* need a latin square,
: because what you refer to as the
: encyphering symbol never needs to be
: recovered. The only thing you ever really
: need to do is recover the message symbol
: from the combined symbol.
: I will give an example which is hopefully
: better explained. Suppose we have two bit bytes,
: then coinsider the combining function given
: by the table:
:
: m= 0123
: ----
: e=0 3102
: e=1 2130
: e=2 0231
: e=3 1320
:
: Now if you had the encyphering symbol
: and the combined symbol then you could
: recover the message symbol, but you
: could not recover the encyphering symbol
: from the combined symbol and the message
: symbol, but that's OK, because you never
: need to do that anyway.
:
: This sort of combining function would
: be much easier to do than making a
: latin square, and there are more
: possibilities also, so why would you
: need a latin square? That was not
: a rhetorical question , I really
: do want to know why, if you would
: be so kind as to clue me in.
Again, although your reply is to my posting, I'll
assume the "you" in the above sentence is generic,
since I didn't say that a Latin Square is needed--
I said that one is *not* needed, and that it's
a separate issue as to whether a non-LatinSquare
combiner would be "good" in a given context.
My 2-cents about the general situation, though, is
that if a column is not a permutation of the entire
output symbol alphabet, then some output symbols
may tend to be more/less frequent than others when
enciphering the same message symbol, and that might
well be a weakness wrt frequency anaysis.
--
r.e.s.
[EMAIL PROTECTED]
------------------------------
From: Johnny Bravo <[EMAIL PROTECTED]>
Subject: Re: New standart for encryption software
Date: Wed, 09 Feb 2000 19:38:36 +0000
On Wed, 9 Feb 2000 17:56:08 +0300, "finecrypt" <[EMAIL PROTECTED]>
wrote:
>>No Back Doors....How can they prove that?
>
>Yes, we can prove it. Read online help topic "How to test FineCrypt with
>test vectors?" about of how you can get a guarantie of reliable encryption.
You can't prove it, despite your unproven assertion to the contrary.
The only way you can prove that your test vectors are the same code used
for encryption is to release the source, and you don't seem willing. Thus
your product won't be trusted, get used to it. The alternatives are free,
and come with source code. Why should we bother to pay for an inferior
product?
Your website is rather uninformative as to even what your product does,
and I'm not about to download and install your software just to find out.
>From what I can determine it encrypts files (and maybe folders), big deal.
Johnny Bravo
------------------------------
** 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
******************************
