Cryptography-Digest Digest #403, Volume #14 Mon, 21 May 01 13:13:01 EDT
Contents:
Re: taking your PC in for repair? WARNING: What will they (Eric Lee Green)
Re: CIA Kryptos last 97 characters (Gary Warzin)
Who do I trust? (Razadook)
Re: TC15 improvement bigtime (Vincent Quesnoit)
Re: Who do I trust? (P.Dulles)
Re: What about SDD? ("Harris Georgiou")
Re: What about SDD? ("Harris Georgiou")
Re: Single-cycle sbox question (David Wagner)
free/open source cryptography vs closed source FAQ ("Titan")
Re: Who do I trust? ("Simon Finnigan")
Re: free/open source cryptography vs closed source FAQ (Mark Wooding)
Re: Single-cycle sbox question (SCOTT19U.ZIP_GUY)
How do you measure the power of a chipher? (Adam)
Re: free/open source cryptography vs closed source FAQ (SCOTT19U.ZIP_GUY)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Eric Lee Green)
Crossposted-To: alt.privacy,alt.privacy.anon-server
Subject: Re: taking your PC in for repair? WARNING: What will they
Reply-To: [EMAIL PROTECTED]
Date: Mon, 21 May 2001 14:11:41 GMT
=====BEGIN PGP SIGNED MESSAGE=====
Hash: SHA1
On Mon, 21 May 2001 14:26:01 +0200, Anonymous <[EMAIL PROTECTED]>
wrote:
>On Mon, 21 May 2001 06:42, [EMAIL PROTECTED] (Eric Lee Green) wrote..
>>EE Support wrote:
>>>Eric Lee Green is exposed for posting blatant lies about Evidence
>>>Eliminator.
>
>>Yawn. Yet more spam from the spamming copyright violating criminal.
>
>Ok..
>
>So who has sufficient knowledge of assembly?
Sufficient knowledge of assembly is not needed. EE is written in Visual
BASIC, for cryin' out loud. All that's needed is a good C++ compiler.
You would do everything, including the filename zapping that the EE guys
claims requires dropping back to DOS, by ripping the VFAT support out of
the Linux kernel and adapting it to use the disk defrag API for its block
read/write. The same could be done to write a real overwriter for NTFS
(which EE won't do).
I've been thinking about it myself, but I'm a Unix programmer, not a
Windows programmer. Hmm, hold on, I have some spare time right now,
maybe I'll go learn the Windows API's... hmm, I don't have a C++ compiler
for Windows, I guess I'll look at Cygwin (the Windows port of the
GNU C++ compiler)... certainly beats working on the EE_Support_Eliminator
(which randomly spams the security newsgroups :-).
=====BEGIN PGP SIGNATURE=====
Version: GnuPG v1.0.5 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iD8DBQE7CSEW3DrrK1kMA04RAuppAJ9QPSGhKNBawXU+s1Ci/uP7/8KtAQCgpKSM
+OtPRxVbyt/bMTxZh/3Kbhs=
=RTcO
=====END PGP SIGNATURE=====
------------------------------
Subject: Re: CIA Kryptos last 97 characters
From: [EMAIL PROTECTED] (Gary Warzin)
Date: Mon, 21 May 2001 14:16:40 GMT
In article <t_SN6.14754$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] says...
>
>now it looks a little bit more "standard"; but i've still some doubts:
>1- about the "palimpsest": the KR combination appears also in the first row,
> but it is not dut to the palimpsest peeking through.
> So do OS, TO, and other combinations that can be easily found in the
>second and
> third parts.
You're right, KR and other combinations will naturally appear throughout the
text and not be part of the underlying table. What makes those at the end of
the lines in part four significant is that they:
1) are at the end of the lines.
2) the YP has exactly the right offset from the KR to fit a table.
3) the leading characters of the first three lines of the portion of the table
under part 4 work out to be WXZ (which is exactly what you would expect if the
last line was then the abcd.. coordinates.
4) Part 4 is the only section in which all the lines are the same length.
It seems quite unlikely that ALL these things happened by chance. This then
leads me to the belief that the real text is 93 characters (leaving out the KR
and YP) - which also helps explain why no one has yet solved it with 4 bogus
letters in the text.
>2- The rows containing errors (IQLUSION, etc) have NOT the same length,
> so, how do they map onto the Quagmire table ? In fact, the table
>contains
> only equal-length rows.
In "real life" the parts that show through in a palimpsest are either those
parts not fully erased, or those that the new message doesn't obliterate. In
this case, the parts that show through are those deemed necessary by Sanborn.
So, those would be:
1) the end of each line on part 4. (Showing the ends of the lines in earlier
sections would only accomplish one of two things, make it too obvious that
there is a underlying table, or, just the opposite, make it too hard to solve
the earlier sections.)
2) the intentional "errors". For this to happen there is no particular
requirement that the lines be the same length. Characters within the line show
through where they are. Characters in the table extending beyond the line of
message text and just considered as being fully erased.
Showing the table lines at full length under part 4 is our hint.
>3- The Q after CANYOUSEEANITHINGQ? was not taken into account. WHY ?
> It does NOT map correctly onto your underlying palimpsest.
The Q is not an error. It is a fill character to make the columns work out for
the transposition. However I was more concerned with the "X". It seems
strange to use an X as a sentence division when none was used elsewhere in this
section. Maybe it is a paragraph break? I thought that maybe the Q stood for
quote - in the original that last sentence was in quotes. Then maybe the X was
the mistake and it should be a Q as well. But, that didn't map to the table
either. My assumption at this point is that the X is a paragraph break and he
got to the end and need fill.
>
>What i meant was:
>yes, the second face of the sculpture gave us the cipher used for the
>first and second part, BUT not for the third part, that is completely
>different,
>and you have absolutely NO cribs for the third part.
Maybe he did when he said "ID by rows". That does fit in with a columnar
transposition.
>Also if i'm not yet convinced, i'll try my programs to find a KEY of 13
>chars
>on your 93 characters.
>(as i've told you before, i've benn working on KRYPTOS for 2 years, and i've
>tried any key from 1 to 14 chars onto the 97 chars, but i got NO results).
>
I have found an error in my thinking that eliminates the "A" line in the table.
This is explained in a new posting (update #2) on my web site
www.iquest.net/~gwarzin. This does mean that the "A" line no longer serves to
set the key length. However I did run an index of coincidence and found that
the most likely key length is indeed 13, followed by 11, 10, and 4. It is
interesting to note that the CI is higher using the 93 characters than it is
using all 97. I would think that this helps support the idea that the KR and
YP are bogus characters. (I will admit that the usefulness of the underlying
table in solving part four is still up for debated.)
------------------------------
From: [EMAIL PROTECTED] (Razadook)
Crossposted-To: alt.privacy,alt.privacy.anon-server
Subject: Who do I trust?
Date: Mon, 21 May 2001 14:22:47 -0000
As a complete outsider here, I have to say EE really really baffle me.
They have a product. Why couldn't they sell it a reasonable price at sit
back and watch the sales grow? I'm competely bamboozled by their weird
tactics. It's absolute madness. Commercial suicide.
------------------------------
From: Vincent Quesnoit <[EMAIL PROTECTED]>
Subject: Re: TC15 improvement bigtime
Date: Mon, 21 May 2001 16:15:29 +0200
Reply-To: [EMAIL PROTECTED]
What I meant was that in the case of a multiplication by three, the adder can be
simplified compared to what a standard adder does when the same bits are not
repeated, ie in B xor C+CD, the repetition of C suggest that some
simplifications can be done in the overall boolean expresion that computes a
bit, and even more so when you move towards more significant bits. This may lead
to expressions that do not need to wait for the carry to propagate over 29 bits.
In the multiplion by 9, you would get an expression like F xor I +GJ which does
not show the same kind of simplification.
VIncent
Tom St Denis a �crit :
> "Vincent Quesnoit" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]...
> > Though I am not an hardware specialist, I think it is very likely that in
> > hardware adding a number to itself shifted by 1 can be faster than adding
> it to
> > "any" number.
> > Consider carry and bit evaluation for B+C when doing
> > ABCDEFGHIJ
> > +ABCDEFGHIJ0
> > The fact that C is present twice in BC+CD+Carry simplifies the boolean
> equations
> > a lot since the carry from C+D depends on C.
> > IMHO there should be no surprise that you can implement this with a lower
> > latency than
> > ABCDEFGHIJ
> > + ABCDEFGHIJ000
> > where e.g. C+F depends in a more complicated way on D,G,E,H,F and J
>
> I am not entirely sure, but at the least you can get away with less code. A
> mult by 9 is really a shift and 29-bit addition (of course the shift is
> free). So we are doing something like (mult by 3)
>
> ABCD
> ABCD0
> --------
> D,C xor D,B xor C + CD, etc...
------------------------------
From: P.Dulles <*@*.com>
Crossposted-To: alt.privacy,alt.privacy.anon-server
Subject: Re: Who do I trust?
Date: Mon, 21 May 2001 11:14:39 -0400
Reply-To: *@*.com
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] says...
>: As a complete outsider here, I have to say EE really really baffle me.
>: They have a product. Why couldn't they sell it a reasonable price at sit
>: back and watch the sales grow? I'm competely bamboozled by their weird
>: tactics. It's absolute madness. Commercial suicide.
You'd think, but there is an old marketing rule "There is no such thing
as bad publicity, as long as they spell the name right." EE makes a big
deal about how many hits they get on their web site, and the curiousity
inspired by the debates and controversy draws more hits.
That's why I initially purchased it, I had an extra $40 and wanted to
check it out myself - this was, of course, before their associates
started spamming usenet. And before EE started getting very snotty with
their critics (called "stooges" by EE, or a "liar" in the case of Eric
Lee Green) and refuses to answer direct questions or provide any
documentation/proof that their product works.
Their marketing baffles me as well. It goes against all marketing
education I have - I think they just want their product to be
controversial, and their recent responses are inflammatory which can
only be designed to draw more criticism - which means they have more
opportunities to respond with the "party line" - or, as suggested,
perhaps an auto-responder with canned answers.
My guess is that they want to make as much money as possible and then
abandon the program - or perhaps sell it off. They have indicated no
intention of making their program NTFS compatible, even though within a
couple of years, most computers will be using the NTFS drives. Another
clue - when have you heard of a software program/company that offers
"free upgrades for life?" This indicates to me they don't plan on being
around very long because once a substantial customer base is
established, they will be sending out far more free updates than new
programs at an outrageous price; meaning their expenses would far
outweigh their income. This is not good business.
The owners of Robin Hood Software are two kids (by kids, I mean in early
20's which are "kids" from the perspective of one in his late 40's) who
seem to work from a home and have no legitimate business listings in the
local phone directories. This is itself is odd, I think.
Their constant attacks on Eric Lee Green are reminiscent of the attacks
of the Church of $cientology on anyone who critises them by calling them
"liars." Those they can't identify, like me, are referred to as
"stooges" but apparently unworthy of receiving answers to direct and
simple questions I've put forth to them.
One thing I am going to do is write a letter to a friend of mine who is
a columnist at a major PC magazine and see if he will do an in-depth
review of this product and the company. It would be very interesting to
see how that turns out.
--
Loki
"Joan of Arc heard voices too!"
------------------------------
From: "Harris Georgiou" <[EMAIL PROTECTED]>
Subject: Re: What about SDD?
Date: Mon, 21 May 2001 17:53:48 +0300
> As far as I am aware, spread spectrum techniques, also
> in connection with the issue of jamming, have been
> applied for quite a time. On the more primitive level
> of the idea, i.e. multiplexing the texts (bytes/bits) of
> several messages streams, which can be done with simple
> programming techniques, there were some mentions in the
> past in the group. (See the thread 'Use of multiplexing'
> of 17 Dec 2001.)
>
> M. K. Shen
Thanks, will take a look :-)
--
Harris
- 'Malo e lelei ki he pongipongi!'
------------------------------
From: "Harris Georgiou" <[EMAIL PROTECTED]>
Subject: Re: What about SDD?
Date: Mon, 21 May 2001 18:04:51 +0300
� David Wagner <[EMAIL PROTECTED]> ������ ��� ������ ���������:
9e9pve$8b1$[EMAIL PROTECTED]
> Harris Georgiou wrote:
> >Because any encryption scheme can eventually be broken with or without
the
> >knowledge of the sender or receiver.
> >[...] And like any other technical mean they are doomed to be broken
> >by a group of people - we just try to make this group as small as
possible.
>
> That sounds like an defeatist attitude, one that is incidentally not
> supported by my experience with cryptography. What's your evidence?
No "defeatist" attitute at all - my job is trying to prevent these kinds of
holes in security, and I know that there is always someone that will try to
discover new ones (which of course are always there and some will be in the
future).
> Anyway, I agree that some analogue of frequency-hopping might be useful
> in conjunction with traditional crypto as a "belt-and-suspenders"
> defense-in-depth technique for increasing assurance.
My point exactly. Encryption and random data distribution are not comparable
but equally useful.
> But a replacement
> for encryption? No way. Encryption is far better understood (in the
> open world), and doesn't require funny assumptions about multiplicity
> of data channels available (an assumption which isn't very well met on,
> e.g., the Internet).
I can think of one convincing reason (at least regarding to cost):
encryption requires specialized DSP hardware in high-speed comms (for
central nodes) or at least robust software implementations (for user-level
apps), while multiplexing is merely a matter of some switches along the
routing path (h/w or s/w) for which the end user doesn't even have to know
their existance.
PS: No intention to argue with anyone here, I just wish to hear what other
have to say ;-)
--
Harris
- 'Malo e lelei ki he pongipongi!'
------------------------------
From: [EMAIL PROTECTED] (David Wagner)
Subject: Re: Single-cycle sbox question
Date: 21 May 2001 15:28:53 GMT
Henrick Hellstr�m wrote:
>But pseudo random uniform distribution is not good enough in many case.
>Regardless of the structure of sigma, the probability might be unacceptable
>that there are different pi_0 and pi_1 such that
>
>pi_0 o sigma o pi_0^-1 = pi_1 o sigma o pi_1^-1
>
>if the set from which pi is selected is large enough. For instance, the set
>of single cycle 8-bit permutations is only 1/256 as large as the set of all
>8-bit permutations, and the set of single cycle permutations is the largest
>subset of permutations with the same cyclic structure.
The problem is not with the algorithm for generating such permutations,
but with the problem statement! If you want to avoid collisions, then
asking for single-cycle permutations on (say) 10 symbols is asking for
trouble, no matter how you generate those permutations. You've got to
fix the problem statement before even thinking about algorithms.
By the way, with 8-bit values, the chances of collision are exceedingly
low. There are 256! 8-bit permutations, and 255! single-cycle
permutations, and sqrt(255!) is very large.
------------------------------
Reply-To: "Titan" <[EMAIL PROTECTED]>
From: "Titan" <[EMAIL PROTECTED]>
Subject: free/open source cryptography vs closed source FAQ
Date: Mon, 21 May 2001 15:37:18 GMT
I was under the impression that for things needing the best
encryption possible it was better to go with some sort of open
source implementation than a closed source one as the open
source one is less likely to have any implementation bugs that
could compromise it.
Is this true or just a rumor?
------------------------------
From: "Simon Finnigan" <[EMAIL PROTECTED]>
Crossposted-To: alt.privacy,alt.privacy.anon-server
Subject: Re: Who do I trust?
Date: Mon, 21 May 2001 16:30:17 +0100
"Razadook" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> As a complete outsider here, I have to say EE really really baffle me.
> They have a product. Why couldn't they sell it a reasonable price at sit
> back and watch the sales grow? I'm competely bamboozled by their weird
> tactics. It's absolute madness. Commercial suicide.
To answer the question - "Who do I trust?" just use common sense. Who is asking
questions? Who is refusing to answer simple questions about the product they
sell? They refuse to prove that their product does what they claim - the put
the onus on YOU to prove that it doesn`t work. Are you likely to have access to
the technology required? I do have access to some of the equipment that would
be used (not a clue how to use it, and I`ve got no chance of convincing the
owners to let me have a play to try and figure it out :-) ) and it`s very large
and very expensive.
If EE are so sure of their product they could sit back and let word of mouth do
the job for them. Instead they accuse people of lying when they are asking
reasonable questions about their product. I know who I trust - someone who is
willing to release the source code for their program so that I can prove to
myself that there are no backdoors in it.
------------------------------
From: [EMAIL PROTECTED] (Mark Wooding)
Subject: Re: free/open source cryptography vs closed source FAQ
Date: 21 May 2001 16:21:04 GMT
Titan <[EMAIL PROTECTED]> wrote:
> I was under the impression that for things needing the best encryption
> possible it was better to go with some sort of open source
> implementation than a closed source one as the open source one is less
> likely to have any implementation bugs that could compromise it.
No, I don't think this is actually true. If you pick a really
well-known piece of free software, you'll get a trustworthiness benefit;
otherwise, you're probably at the mercy of someone you've never met and
nobody will have reviewed it. For example, I don't know of anyone
who's ever done a security review of my crypto library, and I do find
security bugs in it every now and then.
However:
* I think that free software is less likely to have deliberate holes
and back doors in it. The risks of someone digging through the
source code and finding your back door are much higher.
* Free software types tend to be better at reacting to security
problems when they notice them. We're much more into the full-
disclosure thing.
-- [mdw]
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Single-cycle sbox question
Date: 21 May 2001 16:17:08 GMT
A fast way to create all single cycle permutaions
is first to genreate a set of what I call remainder tables
Example you want to create any possible permuatiation for
256 values. crete a series of unform random integers such
that first one is 0-254 then next is 0-253 and so on to
you get 0-1. When you get there you apply the algorithm in
scott16u.zip it builds the unique single cycle table from
this set of remainder values quite fast.
There is a one-one mapping from this set of remainder table
values to the set of single cycle permutations. If you wish
to use an integer value for each possible permutaion.
M = 254!Rnd(254) +253!Rnd(253) ... +3!Rnd(3) +2!Rnd(2) +1!Rnd(1) +0!Rnd(0)
Where Rnd(N) is a randum integer from 0 to N.
Example 3 symbols ABC
remainder table 1 0-1 so only one table
so only 2 single cycle permutations
A -> B -> C -> A
or
A -> C -> B -> A
if there are only 3 symbols
so M either 0 or 1
if there are only 2 symbols
there is only one single cycle permution possible.
and only value of M is 0
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE "OLD VERSIOM"
http://www.jim.com/jamesd/Kong/scott19u.zip
My website http://members.nbci.com/ecil/index.htm
My crypto code http://radiusnet.net/crypto/archive/scott/
MY Compression Page http://members.nbci.com/ecil/compress.htm
**NOTE FOR EMAIL drop the roman "five" ***
Disclaimer:I am in no way responsible for any of the statements
made in the above text. For all I know I might be drugged or
something..
No I'm not paranoid. You all think I'm paranoid, don't you!
------------------------------
Date: Mon, 21 May 2001 18:32:49 +0200
From: Adam <[EMAIL PROTECTED]>
Subject: How do you measure the power of a chipher?
When you hear about RSA crypto it is said to be in 56 bits or 128 bits.
What do that mean? Is it the length of the public or private key or the
two big primenumbers you multiply, or?
/Adam
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: free/open source cryptography vs closed source FAQ
Date: 21 May 2001 16:50:01 GMT
[EMAIL PROTECTED] (Titan) wrote in
<OCaO6.269755$[EMAIL PROTECTED]>:
>I was under the impression that for things needing the best
>encryption possible it was better to go with some sort of open
>source implementation than a closed source one as the open
>source one is less likely to have any implementation bugs that
>could compromise it.
>
>Is this true or just a rumor?
>
>
>
Its true its best to go with open source. But I think the
average person will be tricked into using a poor unsafe version.
However there are things one can do to minimize the chance of
getting a unsecrue encryption. One way would be to use 2 encryptions
methods in series that add no information during the encryption.
There are very few open source encryption methods that don't
add information during encryption. If you belive the hype about
Rijndael being safe. Then about the only version of it that does
not add infomation is BICOM by matt Timmermans.
You can test the feature that no information is added by
seeing if the method is fully bijective. That is if the
method can treat anyfile as an encrypted file or not.
You can take any file and decrypted it with and key in BICOM
and then take that resultant file and encyrpted back to same
start file. Try that with any other program. IF you do
find such another program than it my be worth do it in series
with BICOM
Of couse you can use scott16u or scoutt19u but as they stand
they don't handle short files. But can easily be in a batch
stream where impedance matching code allow for full bijectiveity.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE "OLD VERSIOM"
http://www.jim.com/jamesd/Kong/scott19u.zip
My website http://members.nbci.com/ecil/index.htm
My crypto code http://radiusnet.net/crypto/archive/scott/
MY Compression Page http://members.nbci.com/ecil/compress.htm
**NOTE FOR EMAIL drop the roman "five" ***
Disclaimer:I am in no way responsible for any of the statements
made in the above text. For all I know I might be drugged or
something..
No I'm not paranoid. You all think I'm paranoid, don't you!
------------------------------
** 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 by posting to sci.crypt.
End of Cryptography-Digest Digest
******************************
