Cryptography-Digest Digest #554, Volume #11 Sat, 15 Apr 00 19:13:00 EDT
Contents:
Re: Encode Book? (Diet NSA)
Re: Miami Herald article about ATM ripoffs (Armo Linkey)
Re: ? Backdoor in Microsoft web server ? (Roger)
Re: $100 Code Challenge ("Adam Durana")
GOST with sbox? (Tom St Denis)
Re: GOST with sbox? (stanislav shalunov)
Re: GOST with sbox? (Tom St Denis)
Re: Magnetic Remenance on hard drives. (Guy Macon)
Re: GSM A5/1 Encryption (Guy Macon)
Re: CLOSE Encryption ("MeneLaus")
Re: GOST with sbox? (lordcow77)
Re: Q: Entropy (Bryan Olson)
Re: CLOSE Encryption (Tom St Denis)
Re: Regulation of Investigatory Powers Bill ("Scotty")
Re: GOST with sbox? (Paul Rubin)
Re: ___SPEED of HARDWARE Crypto Processors (Gisle S�lensminde)
Re: GOST with sbox? (Tom St Denis)
----------------------------------------------------------------------------
Subject: Re: Encode Book?
From: Diet NSA <[EMAIL PROTECTED]>
Date: Sat, 15 Apr 2000 11:52:11 -0700
In article <[EMAIL PROTECTED]>, Jim Gillogly
<[EMAIL PROTECTED]> wrote:
>Face it -- there's somebody somewhere who's smarter than you --
except
>for one of you, of course...
Human intelligence is difficult to define and whether someone is
smarter may not be important. For many tasks, we will *all* end
up being slow & stupid compared to machine (or artificial)- based
intelligence. The business world is racing to make IT easier for
people to use, but it might be more significant to make IT easier
for other IT to use.
Long live the machines !
"I feel like there's a constant Cuban Missile Crisis in my pants."
- President Clinton commenting on the Elian Gonzalez situation
=======================================================================
* Sent from RemarQ http://www.remarq.com The Internet's Discussion Network *
The fastest and easiest way to search and participate in Usenet - Free!
------------------------------
From: [EMAIL PROTECTED] (Armo Linkey)
Subject: Re: Miami Herald article about ATM ripoffs
Date: Sat, 15 Apr 2000 19:43:16 GMT
"Mark McCarthy" <[EMAIL PROTECTED]> wrote:
>I don't know how much of this is proprietary so I won't go too deep.
Why not? What country do you live in? What are you afraid of?
------------------------------
From: Roger <[EMAIL PROTECTED]>
Subject: Re: ? Backdoor in Microsoft web server ?
Date: Sat, 15 Apr 2000 13:28:46 -0700
Jim Gillogly wrote:
> You're both mistaken. Thompson's paper described placing the back door
> to login in a separate version of the Unix C compiler, not in the original
> code nor in any shipping version of it. Thompson confirmed later that he
> did indeed perform this experiment, and it spread to another in-house lab
> before he blew the gaffe -- it was not merely theoretical. His exposition
> has been posted here before.
Here is Thompson's paper.
http://www.cs.umsl.edu/~sanjiv/sys_sec/security/thompson/hack.html
------------------------------
From: "Adam Durana" <[EMAIL PROTECTED]>
Subject: Re: $100 Code Challenge
Date: Sat, 15 Apr 2000 16:28:26 -0400
> You know, it's people like you who have no clue how to even begin
> Cryptanalysis. You know, why don't you try to do something other than make
> stupid comments. I think his challenge is valid. Just as mine was. In fact
> I'm suprised you didn't knock my challenge.
No, the thing is you are asking people to spare their time to work on
something you cannot do on your own. The more time your task requires from
people the less likely it is someone will work on it. Since you are
basically asking people to do you a favor, even with a $100 reward it is
still a favor, you should at least give them all the information possible so
they don't waste any more of their time than necessary. Its people who
don't understand some of the basic rules of cryptography that make these
sort of challenges. One of these basic rules is, the security of an
algorithm should not rely on the algorithm remaining secret. So if you want
anyone to take your challenges seriously, either offer a lot of money as a
reward, or include the algorithm along with ciphertext in your challenge.
- Adam
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: GOST with sbox?
Date: Sat, 15 Apr 2000 20:30:31 GMT
Any good analyzed Sboxes for GOST? Will the ones from DES or Serpent
do?
BTW: I recently copied some ref source of blowfish so it's upto the
standard now...
Tom
------------------------------
Subject: Re: GOST with sbox?
From: stanislav shalunov <[EMAIL PROTECTED]>
Date: Sat, 15 Apr 2000 20:43:14 GMT
Tom St Denis <[EMAIL PROTECTED]> writes:
> Any good analyzed Sboxes for GOST?
_Applied Cryptography_ has a set of S-boxes (that were at one point
allegedly) used at Russian Federation's Centrobank. When people just
say ``GOST block cipher,'' they usually mean those S-boxes.
> Will the ones from DES or Serpent do?
I don't think so.
--
stanislav shalunov | Speaking only for myself.
My address in From: is correct; if yours isn't, I don't want to hear from you.
Try to reply in newsgroup. I don't need courtesy copies.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: GOST with sbox?
Date: Sat, 15 Apr 2000 20:46:53 GMT
stanislav shalunov wrote:
>
> Tom St Denis <[EMAIL PROTECTED]> writes:
>
> > Any good analyzed Sboxes for GOST?
>
> _Applied Cryptography_ has a set of S-boxes (that were at one point
> allegedly) used at Russian Federation's Centrobank. When people just
> say ``GOST block cipher,'' they usually mean those S-boxes.
Are those sboxes ok to use? (I lent out my copy of AC, so can someone
please post them here?)
> > Will the ones from DES or Serpent do?
>
> I don't think so.
Why not? Has there been any analysis of gost? I know there is a
related key type thing by Counterpane.... What else?
Tom
------------------------------
From: [EMAIL PROTECTED] (Guy Macon)
Subject: Re: Magnetic Remenance on hard drives.
Date: 15 Apr 2000 16:50:43 EDT
zapzing <[EMAIL PROTECTED]> wrote:
>[EMAIL PROTECTED] (Guy Macon) wrote:
>
>>[EMAIL PROTECTED] (jungle) wrote:
>>
>> >any names & links of shops that will accept & recover data
>> >multi pass wiped by pgp software ?
>>
>> Absence of evidence is not evidence of absence.
>>
>> It could very well be that such techniques exist and are classified.
>> The fact that the US military does not approve a multi pass wipe by
>> pgp software as being sufficient is indirect evidence (but not proof)
>> of this theory.
>>
>
>That's exactly what they want you to think.
>
That doesn't make sense. Assuming that there is a disinformation
campaign, it would seem that "they" would want you to think that
"they" can't recover the data when "they" actually can. This would
lull you into a false sense of security and allow "them" to get to
your data that you thought was safely erased. Why would "they"
want you to think that "they" can recover the data when "they"
actually can't? What purpose would such deception serve? If anyone
in this conversation is passing on disinformation, it is those who
say that your erased data is unrecoverable. As for me, I only save
sensitive data to a floppy disk, and I toss the floppy in the
fireplace to "erase" my data.
------------------------------
From: [EMAIL PROTECTED] (Guy Macon)
Subject: Re: GSM A5/1 Encryption
Date: 15 Apr 2000 16:51:29 EDT
[EMAIL PROTECTED] (David A. Wagner) wrote:
>You're right, GSM is a poor choice for sending high-bandwidth messages.
Please don't say that I am write when quoting something I didn't say.
I said that if GSMs bandwidth requirements grows exponentially with the
message size (a concept that I suspect to be false but is derived from
your previous posts), then GSM is a poor choice for sending long messages.
>For reference, GSM uses frames that are 200 and some odd bits long.
>Prepending and appending (say) 16 random bits would increase the frame
>length by something like 15% (and decrease the overall bandwidth by
>a similar fraction). This is a huge number for such a small benefit.
>The GSM designers would scream, and rightly so.
I think that you need to spend more time reading what folks write to you.
I advocated adding random data to the beginning and end of the plaintext
before encryption. The idea that I have ever advocated any change to the
internals of any well analyzed crypto method is pure fantasy. That would
be stupid - how would I know that I hadn't compromised something that I
don't fully understand?
>Sure, it might not be so costly in other systems (not GSM). If you
>weren't talking about GSM, next time you might do better at avoiding
>confusion by saying so. (After all, the subject line on your note reads
>"Re: GSM A5/1 Encryption".) Just a suggestion...
In newsgroups, I like to lurk for a long time and learn the culture before
participating. In some newsgroups, subject lines are changed as the
discussion drifts, but in sci.crypt, they tend not to, so I follow that
convention even though it leads to subject/content mismatches. As for the
question of whether we are discussing just GSM or ciphers in general, I
again followed your lead, as evidenced in the following post:
| From: [EMAIL PROTECTED] (David A. Wagner)
| Subject: Re: GSM A5/1 Encryption
| Date: 08 Apr 2000 00:00:00 GMT
| Message-ID: <8cnq2j$kjs$[EMAIL PROTECTED]>
| References: <8cbkbm$i12$[EMAIL PROTECTED]> <8cimfj$cod$[EMAIL PROTECTED]>
|<8cj9me$ild$[EMAIL PROTECTED]> <8clt2n$skh$[EMAIL PROTECTED]>
| X-Complaints-To: [EMAIL PROTECTED]
| X-Trace: agate.berkeley.edu 955217140 16030 128.32.37.122 (8 Apr 2000 18:05:40 GMT)
| Organization: A poorly-installed InterNetNews site
| NNTP-Posting-Date: 8 Apr 2000 18:05:40 GMT
| Newsgroups: sci.crypt
|
| In article <8clt2n$skh$[EMAIL PROTECTED]>, <[EMAIL PROTECTED]> wrote:
| > A Silent Frame is a Silent Frame regardless if the cipher is strong or
| > week, and will provide plaintext to the cryptoanalyst....My question
| > was, how to avoid that?
|
| With a (modern) strong cipher, there's no need to avoid it,
| because (modern) strong ciphers are supposed to remain unbreakable
| even if the adversary has some known plaintext.
*You* said that we were talking about "a (modern) strong cipher",
not just "GSM A5/1 Encryption".
I read your posts carefully and pay careful attention to what you say and
to what you don't say. I would much appreciate it if you would begin
to do the same with my posts. I am still waiting for that apology that
you owe me, by the way.
------------------------------
From: "MeneLaus" <[EMAIL PROTECTED]>
Subject: Re: CLOSE Encryption
Date: Sat, 15 Apr 2000 22:12:21 +0100
Thanks for the feedback,
I have just created a substitution function for the algorithm, i have also
rearranged the order of some of the processes so that it has the whitener
towards the end of the round.
Suppose it's better than the old 'KIA' algorithm i wrote. (you proberbly
never even heard of that)
Oh, and Tom St Davis, I downloaded a copy of your PB3, i just want to tell
you that the file encrypt feature isn't quite working yet, is this just
because it is a beta? email me when you have fixed it or post a mess on the
CL board. Thanks!
MeneLaus
http://members.xoom.com/menelaus_/
------------------------------
Subject: Re: GOST with sbox?
From: lordcow77 <[EMAIL PROTECTED]>
Date: Sat, 15 Apr 2000 14:35:46 -0700
My [very cursory] observation of the supposed GOST S-boxes as
given in Applied Cryptography reveals nothing especially unique
about them; the biases of their linear approximations don't
appear unusually low. I would think that the substituting the
Serpent S-boxes should have no major detremental security
effects on the overall algorithm, however, as always one much
examine the structure of the entire algorithm and how individual
components interact with one another.
* Sent from RemarQ http://www.remarq.com The Internet's Discussion Network *
The fastest and easiest way to search and participate in Usenet - Free!
------------------------------
From: Bryan Olson <[EMAIL PROTECTED]>
Subject: Re: Q: Entropy
Date: Sat, 15 Apr 2000 21:46:30 GMT
Mok-Kong Shen wrote:
> Bryan Olson wrote:
> > Here the input y is written as a program for M_i. Absent
> > reference to the specific machine, the definition does not
> > define which of two strings has greater complexity. In fact
> > for _any_ two finite strings x and x', there are two
> > machines M_i and M_j such that
> >
> > K_i(x) < K_i(x') and K_j(x) > K_j(x').
> >
> > Kolmogorov complexity also defines a language-independent
> > metric. It defines complexity to within some additive
> > constant, so it does not describe individual finite strings.
>
> Do I correctly understand that means that the concrete metrics
> differ from one another by 'constants'?
No. They are *within* some constant.
That is, if M_i and M_j are universal Turing machines,
then there exists some constant c such that for all
strings x, |K_i(x) - K_j(x)| <= c.
The consequent (i.e. everything after "then") may also
be stated: K_i(x) = K_j(x) + O(1)
(There are slight variations in how Turing machines
are defined. I'm assuming the end of input is marked
in constant space, which I believe is the common
definition, but my references are not handy.)
> If that is indeed the
> case, then I think the matter would be simple: For two strings
> s1 and s2, if we have in one metric K1 and K2, then we would have
> in the other K1+C and K2+C and comparision of complexity would be
> unambiguious. Is that right?
Nope. "f(x) = g(x) + O(1)" tells us nothing about
the sign or magnitude of f(x) - g(x) at any
particular value of x.
--Bryan
--
email: bolson at certicom dot com
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: CLOSE Encryption
Date: Sat, 15 Apr 2000 22:04:28 GMT
MeneLaus wrote:
>
> Thanks for the feedback,
>
> I have just created a substitution function for the algorithm, i have also
> rearranged the order of some of the processes so that it has the whitener
> towards the end of the round.
>
> Suppose it's better than the old 'KIA' algorithm i wrote. (you proberbly
> never even heard of that)
>
> Oh, and Tom St Davis, I downloaded a copy of your PB3, i just want to tell
> you that the file encrypt feature isn't quite working yet, is this just
> because it is a beta? email me when you have fixed it or post a mess on the
> CL board. Thanks!
I actually am re-writing pb3 from scratch. This is because I have/am
fixing numerous bugs in CB (http://24.42.86.123/cb.html). A copy of pb3
should be available sometime soon. In the meantime you can use pb2 if
you like.
Tom
------------------------------
From: "Scotty" <[EMAIL PROTECTED]>
Crossposted-To: alt.security.scramdisk,alt.computer.security
Subject: Re: Regulation of Investigatory Powers Bill
Date: Sat, 15 Apr 2000 22:15:48 +0100
Your Name wrote in message <7QRJ4.224$[EMAIL PROTECTED]>...
>In article <[EMAIL PROTECTED]>,
>[EMAIL PROTECTED] says...
>>
>>-----BEGIN PGP SIGNED MESSAGE-----
>>Hash: SHA1
>>
>>There's little point, the first time a case comes to the courts, then
>>it will fall flat on it's face. If you have encrypted data on your
>>hard disk, and refuse to decrypt, the the law says that you can be
>>imprisoned.
>>
>>What this basically means is that they are removing the right of
>>indivduals in a criminal court to be tried as innocent until proven
>>guilty. This is a breach of at least the European Declaration of
>>human rights, and probably the Universal Declaration of Human Rights.
This is not quite correct. There was a very slight change of emphasis in the
RIP bill compared to its previous incarnation in the e-commerce bill.
Whereas the e-commerce bill was going to put the burden of proof on you to
show that you didn't have a decryption key, the new RIP bill changes the
test to one of balance of probabilities. So its gone from 'guilty till
proven innocent' to 'balance of probabilities'. In that respect any evidence
of keeping random files is useful. As a gesture of support for human rights
in this country, (I believe this is a HR issue), everyone (in the UK) should
be encouraged to donate some disk space to such files. These are extremely
easy to create, just make any scramdisk volume and give it a random key.
Then, using a hex editor, randomly change 30 or so bytes in the first block
so the random key won't work. Every so often go into the file and make
another random change, just a single one byte change will be enough. [The
reason for this is that Scramdisk has the unfortunate feature of updating
the last access date and time, [Aman: can this be changed], so its important
to mimic this in any dummy file, otherwise it can be ruled out - remember
you want a random file which looks for all the world like an active
encrypted file but crucially, has no key which is known to you, only that
way will this anti-encryption law be rendered worthless].
------------------------------
From: [EMAIL PROTECTED] (Paul Rubin)
Subject: Re: GOST with sbox?
Date: 15 Apr 2000 22:32:58 GMT
In article <[EMAIL PROTECTED]>,
Tom St Denis <[EMAIL PROTECTED]> wrote:
>Any good analyzed Sboxes for GOST?
Yes there's some article by an Australian cryptanalyst using
the boxes from AC2. Try a web search.
>Will the ones from DES or Serpent do?
Of course not. GOST uses 4x4 S-boxes where each box is supposed to
be a permutation on the 16 values. DES and Serpent S-boxes won't fit.
------------------------------
From: [EMAIL PROTECTED] (Gisle S�lensminde)
Subject: Re: ___SPEED of HARDWARE Crypto Processors
Date: 16 Apr 2000 00:41:52 +0200
In article <[EMAIL PROTECTED]>, kctang wrote:
>___SPEED of HARDWARE Crypto Processors
>
>Dear all,
>
>I am looking for information on the
>SPEED of HARDWARE Crypto Processor.
>
>Either DES, RC5; RSA, ECC crypto schemes are of interest.
>Either VLSI, VHDL, FPGA designs are of interest.
>
>Thanks and bye, kctang
NSA submited a paper to AES3 about the hardware speed of the
AES candidates. I have a kind of feeling that these guys have access to
state the art chip technology. They talk about speeds
up to 8 Gbit/s for pipelined versions. There are also other
papers on hardware design there. The paper can be found at the
bottom of the AES3 submission page.
http://csrc.nist.gov/encryption/aes/round2/conf3/aes3papers.html
--
Gisle S�lensminde ( [EMAIL PROTECTED] )
ln -s /dev/null ~/.netscape/cookies
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: GOST with sbox?
Date: Sat, 15 Apr 2000 22:51:43 GMT
Paul Rubin wrote:
>
> In article <[EMAIL PROTECTED]>,
> Tom St Denis <[EMAIL PROTECTED]> wrote:
> >Any good analyzed Sboxes for GOST?
>
> Yes there's some article by an Australian cryptanalyst using
> the boxes from AC2. Try a web search.
Will look.
>
> >Will the ones from DES or Serpent do?
>
> Of course not. GOST uses 4x4 S-boxes where each box is supposed to
> be a permutation on the 16 values. DES and Serpent S-boxes won't fit.
Hmm? Both serpent and the basic DES sboxes are 4x4 sboxes. Well in des
it's 6x4, but it's actually designed as four 4x4 sboxes per 6 bits in.
Serpent uses explicitly 4x4 sboxes...... So are they just not suited or
what?
Tom
------------------------------
** 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
******************************
