Cryptography-Digest Digest #159

2001-04-16 Thread Digestifier

Cryptography-Digest Digest #159, Volume #14  Mon, 16 Apr 01 12:13:01 EDT

Contents:
  Re: Data dependent arcfour via sbox feedback
  Re: Password tool! (those who know me have no need of my name)
  Re: Data dependent arcfour via sbox feedback
  Re: Reusing A One Time Pad ("Mark G Wolf")
  Re: LFSR Security ("Scott Fluhrer")
  Re: NSA is funding stegano detection ([EMAIL PROTECTED])
  Re: NSA is funding stegano detection (Walter Roberson)
  P1363 draft ("Full Name")
  Re: Reusing A One Time Pad ([EMAIL PROTECTED])
  Re: NSA is funding stegano detection ([EMAIL PROTECTED])
  Re: C Encryption (Steve Portly)



From: [EMAIL PROTECTED]
Subject: Re: Data dependent arcfour via sbox feedback
Date: Mon, 16 Apr 2001 10:32:55 -0400

I tried to read this thread and related topics, but there are too many
posts for me. Does Ritter say anywhere whether or not he has tested his
broad position in court? I don't think his broad interpretation would
hold. Lets see what he does if a wealthy company like IBM (deep pockets
in the legal dept.) implements something similar to that described in
this thread.

"Bryan Olson" "nospam"@"nonsuch.org" wrote in message
7FdC6.1$D_.85@interramp...
Terry Ritter wrote:

Bryan Olson wrote:

Terry Ritter wrote:

On Sat, 07 Apr 2001 06:24:00 GMT, in 4oyz6.6$4G.143@interramp, in
sci.crypt "nospam"@"nonsuch.org" ("Bryan Olson") wrote:

In article [EMAIL PROTECTED], Terry Ritter wrote:

On Wed, 04 Apr 2001 19:53:09 -0700, in
[EMAIL PROTECTED], in sci.crypt Bryan Olson
[EMAIL PROTECTED] wrote:

Bryan Olson wrote:
  Terry Ritter wrote:

  The "second data source" is modified by said "result data"
before use,
  but no part of the claims excludes that possibility.
 
  The word "source" excludes the possibility.  The sequence of
  y values is in fact a _product_ of the substitution process,
  not a source. If unclear of the interpretation of "source",
  just read the background and look at the diagrams in the
  patent.

 Any sequence of data values is "a source."  We can see this
 throughout the patent, including:  "A first data source and
 a second data source are combined into a complex
 intermediate form or result. . . ."  Note the lack of
 description about the "ultimate" origin of any data sequence
 treated as a "source."

It may be any sequence of values, but it must be a source,
not a product.  Neither does the ultimate origin matter;
just that it comes in from the outside.

The ultimate origin is of course outside *the* *combiner*, but not
necessarily outside the system containing the combiner.

The source in question is produced _from_ the table as the
"combiner" updates it.

That's fine with me.  The Dynamic Substitution claims place no
limitations on the source of these values.

Right.  But it's not a source.  It's a product of the same
table.

No problem.  It *becomes* a source.

By the simple process of ignoring what "source" means.


When you present a system which is more than just the combiner, I
am
free to select what signals there are and try to match them to a
claim.  You don't get to decide what signals I select.  You can
add
whatever you want around an invention in an attempt to obscure
which
parts actually constitute the invention, but the invention is
still
there somewhere, and I get to find it.

Exactly.  The sequence _you_ chose depends upon the dynamic
update of the table.  It is necessarily a function of the
combiner, and cannot be outside.

I have no idea what your point may be.  The claims do not specify a
particular origin for the sequences.

It's not a combiner of data sources.  It's producing one
from state alone.

It is combining two parts of that RNG state.

And not two data sources, as the term is used in the patent.


 But, if you don't like the word "source," perhaps you would
 prefer the word "value": [...]

Which is not the word in the claim at issue.

It only takes one claim.  Any claim counts.

The one you had cited is claim 1.  If you want to instead go
through claim 15, note that it's not only a "value" it's an
"input value".  Claim 15 also states one output, and if you
use that value for the output, the cipher cannot function.

I *think* the intent here is to recall an argument made earlier that
"the cipher" has an XOR combiner, so "the" combiner obviously is not
DynSub.

Not really.  You tried to show claim 1 fit; then when I
argued it didn't, you appealed to the wording of a different
claim.

When the question is whether the patent covers whatever, any claim
counts.

What happened here is that you appealed to the wording of
claim 15 since the statement of claim 1 doesn't fit.  Yes
any claim counts, but claim 1 with ce

Cryptography-Digest Digest #159

2000-11-14 Thread Digestifier

Cryptography-Digest Digest #159, Volume #13  Tue, 14 Nov 00 18:13:01 EST

Contents:
  Re: The SHAs (David Crick)
  Re: The SHAs (David Crick)
  Re: On an idea of John Savard (Mok-Kong Shen)
  Re: The SHAs (David Crick)
  Re: "Secrets and Lies" at 50% off (James Felling)
  Re: On an idea of John Savard (James Felling)
  Re: The ultimate cipher (James Felling)
  Re: On an idea of John Savard (David Schwartz)
  Easy Way To Financial Success (Gerry)
  Re: Thoughts on the sci.crypt cipher contest (Paul Crowley)



From: David Crick [EMAIL PROTECTED]
Subject: Re: The SHAs
Date: Tue, 14 Nov 2000 22:29:35 +

[EMAIL PROTECTED] wrote:
 
  I have coded the three SHA algorithms (SHA256, SHA384, SHA512) in
 assembly language, and the programs perform properly on the NIST test
 files. Can anyone verify the results below on the file of 1,000,000
 'a's?
 -
 M:\sha256 abytes.1m
 
 3903B510 4E2E785A 000FDFF8 9D6CEF49 F867B5B5 5276FA66 2064B15A 248F3EF8
 
 M:\sha384 abytes.1m
 
 AC5D0302 132C906A 202B6CBD 175CC0AE 75DB16DD A37146D1 1EF70BB1 745677CD
 952B53D5 10B3656F 1A3E80ED B742DB5D
 
 M:\sha512 abytes.1m
 
 C247359F CCF33404 F0B5447C DD9B0A39 50A0D444 D3E8BF58 3733373B 21947B0C
 6C8F4B69 F267E3FE 1ABBF083 CA1DD28E 43CD187C 45F098AF 0174D756 EE6F9904

There were three C programs written shortly after the new SHA specs
came out. It's these I'm testing your code against; I've downloaded
the assembly from your site (but see later).

The Sha256 code matches:

Yours:

CDC76E5C 9914FB92 81A1C7E2 84D73E67 F1809A48 A497200E 046D39CC C7112CD0

C ver: 

cdc76e5c 9914fb92 81a1c7e2 84d73e67 f1809a48 a497200e 046d39cc c7112cd0

BUT THE ONE IN YOUR POST ABOVE IS DIFFERENT!


The Sha384.zip file I downloaded from your site was corrupt. However,
comparing what you posted:

 M:\sha384 abytes.1m
 
 AC5D0302 132C906A 202B6CBD 175CC0AE 75DB16DD A37146D1 1EF70BB1 745677CD
 952B53D5 10B3656F 1A3E80ED B742DB5D

C ver:

9d0e1809716474cb 086e834e310a4a1c ed149e9c00f24852 7972cec5704c2a5b
07b8b3dc38ecc4eb ae97ddd87f3d8985

These disagree.

As does the Sha512 output. Again, the .COM I extracted from
your site differs from what you posted too!

 M:\sha512 abytes.1m
 
 C247359F CCF33404 F0B5447C DD9B0A39 50A0D444 D3E8BF58 3733373B 21947B0C
 6C8F4B69 F267E3FE 1ABBF083 CA1DD28E 43CD187C 45F098AF 0174D756 EE6F9904

Yours:

28B21DE0 CA078958 18C3359A 799E471B 78CF0A3C 9166C4E6 16E40285 5E3131B0
F5AC5933 E20DBA9F 87288A79 063FA05B 76CA9A29 493F285D 204A88E7 419ADCBA

C Ver:

e718483d0ce76964 4e2e42c7bc15b463 8e1f98b13b204428 5632a803afa973eb
de0ff244877ea60a 4cb0432ce577c31b eb009c5c2c49aa2e 4eadb217ad8cc09b


Looks like all these results need looking at again!

-- 
+---+
| David A Crick [EMAIL PROTECTED]  PGP: (NOV-2000 KEY) 0x710254FA |
| Damon Hill Tribute Site: http://www.geocities.com/MotorCity/4236/ |
| M. Brundle Quotes: http://members.tripod.com/~vidcad/martin_b.htm |
+---+

--

From: David Crick [EMAIL PROTECTED]
Subject: Re: The SHAs
Date: Tue, 14 Nov 2000 22:31:34 +

If it helps, the Sha-1 sum of the million-a file I'm using is:

milliona.txt: 34AA 973C D4C4 DAA4 F61E  EB2B DBAD 2731 6534 016F

If someone can confirm this Sha-1 result then I know I've got a
good file to be testing against!

-- 
+---+
| David A Crick [EMAIL PROTECTED]  PGP: (NOV-2000 KEY) 0x710254FA |
| Damon Hill Tribute Site: http://www.geocities.com/MotorCity/4236/ |
| M. Brundle Quotes: http://members.tripod.com/~vidcad/martin_b.htm |
+---+

--

From: Mok-Kong Shen [EMAIL PROTECTED]
Subject: Re: On an idea of John Savard
Date: Tue, 14 Nov 2000 23:34:30 +0100



David Schwartz wrote:
 
 Mok-Kong Shen wrote:
 
  If you increase a common block cipher from its standar
  number of rounds to a higher number of rounds, do you
  think that you would thereby weaken it?
 
 Perhaps. If, for example, one side was doing X rounds and the other
 side was doing X+1 rounds, there might be imaginable compromises.

I am afraid there is some misunderstanding between us.
What do you mean by 'side'? Do you mean the communication
partners? Of course they have to use the same algorithm.
If you mean that a DES-like cipher one round treats only
one half block, then one has to substitute 'cylce',
i.e. two rounds, for what I meant above, for e.g. a
17 round DES is not very good, though I suppose it
should still be stronger than the 16 round one.

M. K. Shen

--

From: David Crick [EMAIL PROTECTED]
Subject: Re: The SHAs
Date: Tue, 14 Nov 2000 22:37:16 +

David Crick wrote:
 
 If it helps, the Sha-1 sum of the million-a file I'm using is:
 
 milliona

Cryptography-Digest Digest #159

2000-02-19 Thread Digestifier

Cryptography-Digest Digest #159, Volume #11  Sat, 19 Feb 00 16:13:01 EST

Contents:
  Re: NIST publishes AES source code on web (wtshaw)
  Re: NIST publishes AES source code on web (Samuel Paik)
  Re: NIST publishes AES source code on web (wtshaw)
  Is Phi perfect? (Frank the_root)
  Re: Is Phi perfect? (Mike Andrews)
  Re: Q: Division in GF(2^n) (Mike Andrews)
  Re: UK publishes 'impossible' decryption law (Jim)
  Re: EOF in cipher??? (Albert P. Belle Isle)
  Re: EOF in cipher??? ("Trevor Jackson, III")
  Re: Question about OTPs (Anthony Stephen Szopa)
  Re: EOF in cipher??? ("Trevor Jackson, III")
  Re: EOF in cipher??? ("Joseph Ashwood")
  Re: Guaranteed Public Key Exchanges (Darren New)
  Re: EOF in cipher??? ("Trevor Jackson, III")
  Re: Is Phi perfect? ("Scott Fluhrer")



From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: NIST publishes AES source code on web
Date: Sat, 19 Feb 2000 12:23:07 -0600

In article [EMAIL PROTECTED], Mok-Kong Shen
[EMAIL PROTECTED] wrote:

... Here strong cryptos designed by common people are to be
 restricted or prohibited from export, while those promoted/supported
 by authorities are to be wide-spread (through official publications,
 among other means). Since my above said impression is obviously
 or highly probably wrong, I must logically conclude that AES is 
 in fact NOT a strong crypto.
 
If you use position to collect lots of people with adequate smarts, it is
easy to presume that no one can compete, or that you will discourage
and/or frustrate cthose you cannot directly control, or buy-out controling
interests in products you want to handle, or somehow classify speech you
don't like as illegal, or make black-bag jobs and secret courts
acceptable.  You would try to knock down crypto that you don't like by any
means possible.

As long as you can control something like AES, even stating at each level
that you have the last word, it is certain that a good but deficient
algorithm will result.
-- 
Let's all sit back an watch the inhabitants of the political zoo 
perform in three rings.  It's more exciting than soap operas.  Then 
vote out anyone who has been in long enough to abuse things.  

--

From: Samuel Paik [EMAIL PROTECTED]
Subject: Re: NIST publishes AES source code on web
Date: Sat, 19 Feb 2000 19:22:50 GMT

Mok-Kong Shen wrote:
 Tim Tyler wrote:
  It is non-commercial, with public source code.  This bit seems to apply:
 
  ``encryption source code that would be publicly available (and posting to
the Internet itself would make it publicly available), and which is not
subject to an express agreement for the payment of a licensing fee or
royalty for the commercial production or sale of any product developed
using the source code, would be eligible under License Exception TSU for
"unrestricted" source code. Under this policy, the software may be
exported without prior submission to the government for technical review
(although concurrent notification of the export is required). In
addition, software exported under this exception may be posted to the
Internet without restriction and would not be subject to any requirement
to screen for access. Also, such posting would not constitute knowledge
of an export to a prohibited destination under the EAR, including one of
the seven terrorist states. ''
 
 If this is indeed true,

DISCLAIMER: I am not a lawyer and this is not a legal opinion.

It is a summary of Section 740.13 (e) "TECHNOLOGY AND SOFTWARE - UNRESTRICTED
(TSU)" / "Unrestricted encryption source code of the new proposed final EAR
(published in the Federal Registrar Jan 14, 2000)  Here is the exact
wording; note numbers in brackets inserted.:


(e) Unrestricted encryption source code

 (1) Encryption source code controlled under 5D002, [1] which would be
 considered publicly available under §734.3(b)(3) [2] and which is
 not subject to an express agreement for the payment of a licensing
 fee or royalty for commercial production or sale of any product
 developed with the source code, is released from "EI" [3] controls
 and may be exported or reexported without review under License
 Exception TSU, provided you have submitted written notification
 to BXA of the Internet location (e.g., URL or Internet address)
 or a copy of the source code by the time of export. Submit the
 notification to BXA and send a copy to ENC Encryption Request
 Coordinator (see §740.17(g)(5) for mailing addresses). [4]
 Intellectual property protection (e.g., copyright, patent or
 trademark) will not, by itself, be construed as an express
 agreement for the payment of a licensing fee or royalty for
 commercial production or sale of any product developed using
 the source code.

 (2) You may not

Cryptography-Digest Digest #159

1999-09-02 Thread Digestifier

Cryptography-Digest Digest #159, Volume #10   Thu, 2 Sep 99 05:13:03 EDT

Contents:
  CIA Vigenere END-TIMES (Vigenere2.jpg) [1/3] ("collomb")



From: "collomb" [EMAIL PROTECTED]
Subject: CIA Vigenere END-TIMES (Vigenere2.jpg) [1/3]
Date: 2 Sep 1999 08:48:27 GMT

The CIA Vigenere End-times

I am going to explain why the square Vigenere of Kryptos
comprised 4 columns in excess on the right and an additional line on the
bottom.
Why?
Those who consulted my site web :
http://calvaweb.calvacom.fr/collomb /
know that the solution of the puzzle of Kryptos comprises word GOD
written diagonally.
Curiously there is a possibility of revealing GOD diagonally in the
Vigenere-Kryptos square and only one.
Up to G of the seventh line, trace a diagonal line to D, placed in the
bottom on the right of the last line.  This line passes automatically by
the O of Kryptos of the
sixteenth line.
We delimit two squares thus.
A first one, starting from G, formed of 22 X 22 characters, a second one
starting
from the O of Kryptos made of 13 X 13 characters.  see the attached
drawing 
Those who know my method of decoding are in a known land.
22 and 13 lead obviously to a chapter and a verse of the Revelation
to John.
Rev 22-13 : I am the Alpha and the Omega, the first and the last, the
beginning 
and the end. 
The first is the first character of the great square is G, the last  is
the final character of small square D. To go from one character to the
other
one passes by the O of KryptOs.
To obtain this result the cryptographer has obligatorily to add 4 columns
on the right and a line in bottom, so that appears at the end of this
last line,  the character D, last character of word GOD.
This word GOD is written diagonally, as in the final solution published on
my
site web. We understand now why there is a shifting of one box at each line
in the Vigenere-Kryptos, system what makes appear the diagonals.
Regards
[EMAIL PROTECTED]

begin 600 Vigenere2.jpg
M_]C_X `02D9)1@`!`@$`9 !D``#_[0$Z4AO=]S:]P(#,N, `X0DE-`^T`
M`! `9 $``@!D`0`".$))30/S```(``$X0DE-
M)Q ```H``0`".$))30/U``!(`"]F9@`!`QF9@`
M```!`"]F9@`!`*9F@!`#(!`%H```!`#4!
M`"T```!.$))300"```X0DE-! (```(``%!(550(
M-0``1 ``
M4$A55 @T```$
M`#A"24T$!@``!P`"`0$`__X`)T9I;4@=W)I='1E;B!B2!!9]B
M92!0:]T;W-H;W"H(#0N, #_[@`.061O8F4`9( !_]L`A `(!@8!@8(
M!@8(# @'" P."@@("@X0#0T.#0T0$0P,# P,#!$,# P,# P,# P,# P,# P,
M# P,# P,# P,# P,`0D(" D*"0L)"0L."PT+#A$.#@X.$1$,# P,#!$1# P,
M# P,$0P,# P,# P,# P,# P,# P,# P,# P,# P,# S_P `1" .!`S$#`2(`
M`A$!`Q$!_]T`! `T_\0!H@!`0$!`0``! 4#`@8!``("0H+
M`0`"`@,!`0$!`0`!``(#! 4!P@)"@L0``(!`P,"! (!P,$`@8"
MP$"`Q$$``4A$C%!408382)Q@10RD:$'%;%"(\%2T$S%F+P)'*"\25#-%.2
MHK)C\(U1"3H[,V%U1D=,/2X@@F@PD*!F$E$5I+16TU4HO+C\\34Y/1E
M=865I;7%U7U9G:EJ:VQM;F]C='5V=WAYGM\?7Y_X2%AH(B8J+C(V.CX
M*3E)66EYB9FING9Z?DJ.DI::GJ*FJJZRMKJ^A$``@(!`@,%!00%!@0(`P-M
M`0`"$0,$(1(Q0051$V$B!G!D3*AL? 4P='A(T(54F)R\3,D-$."%I)3):)C
MLL('](UXD2#%U23" D*!DF-D4:)V1T53?RH[/#*"G3X_.$E*2TQ-3D]5U
MA96EM75Y?55F9VAI:FML;6YO9'5V=WAYGM\?7Y_X2%AH(B8J+C(V.CX
M.4E9:7F)F:FYR=GI^2HZ2EIJHJ:JKK*VNKZ_]H`# ,!``(1`Q$`/P#O^;-F
MQ5V;-FQ5V;-FQ5V;-FQ5V;-FQ5V;-FQ5V;-FQ5V;-FQ5V;-FQ5V;-FQ5V;-F
MQ5V;-FQ5V;-FQ5V;-FQ5V;-FQ5V;-FQ5V;-FQ5V;-FQ5V;-FQ5V;-FQ5V;-F
MQ5V;-FQ5V;-FQ5V;-FQ5V;-FQ5V;-FQ5V;-FQ5V;-FQ5V;-FQ5V;-FQ5V;-F
MQ5V;-FQ5V;-FQ5V;-FQ5V;-FQ5V;-FQ5V;-FQ5V;-FQ5V;-FQ5V;-FQ5V;-F
MQ5V;-FQ5V;-FQ5V;-FQ5V;-FQ5V;-FQ5V;-FQ5V;-FQ5V;-FQ5V;-FQ5V;-F
MQ5V;-FQ5_]#O^;-FQ5V;-FQ5V;-FQ5V;-FQ5V;-FQ5V;-FQ5V;-FQ5V;-FQ5
MV;-FQ5V;-FQ5V;-FQ5V;-FQ5V;-FQ5V;-FQ5V;-FQ5V;-FQ5V;-FQ5V;-FQ5
MV;-FQ5V;-FQ5V;-FQ5V;-FQ5V;-FQ5V;-FQ5V;-FQ5V;-FQ5V;-FQ5V;-FQ5
MV;-FQ5V;-FQ5V;-FQ5V;-FQ5V;-FQ5V;-FQ5V;-FQ5V;-FQ5V;-FQ5V;-FQ5
MV;-FQ5V;-FQ5V;-FQ5V;-FQ5V;-FQ5V;-FQ5V;-FQ5V;-FQ5V;-FQ5V;-FQ5
MV;-FQ5V;-FQ5V;-FQ5V;-FQ5_]'O^;-FQ5V;-FQ5V;-FQ5V;-FQ5V;-FQ5V;
M-FQ5V;-FQ5V;-FQ5V;-FQ5V;-FQ5V;-FQ5V;-FQ5V;-FQ5V;-FQ5V;-FQ5V;
M-FQ5V;-FQ5V;-FQ5V;-FQ5V;-FQ5V;-FQ5V;-FQ5V;-FQ5V;-FQ5V;-FQ5V;
M-FQ5V;-FQ5V;-FQ5V;-FQ5V;-FQ5V;-FQ5V;-FQ5V;-FQ5V;-FQ5V;-FQ5V;
M-FQ5V;-FQ5V;-FQ5V;-FQ5V;-FQ5V;-FQ5V;-FQ5V;-FQ5V;-FQ5V;-FQ5V;
M-FQ5V;-FQ5V;-FQ5V;-FQ5V;-FQ5V;-FQ5V;-FQ5_]+O^;-FQ5V;-FQ5V;-F
MQ5V;-FQ5V;-FQ5V;-FQ5V;-FQ5V;-FQ5V;-FQ5V;-FQ5V;-FQ5V;-FQ5V;-F
MQ5V;-FQ5V;-FQ5V;-FQ5V;-FQ5V;-FQ5V;-FQ5V;-FQ5V;-FQ5V;-FQ5V;-F
MQ5V;-FQ5V;-FQ5V;-FQ5V;-FQ5V;-FQ5V;-FQ5V;-FQ5V;-FQ5V;-FQ5V;-F
MQ5V;-FQ5V;-FQ5V;-FQ5V;-FQ5V;-FQ5V;-FQ5V;-FQ5V;-FQ5V;-FQ5V;-F
MQ5V;-FQ5V;-FQ5V;-FQ5V;-FQ5V;-FQ5V;-FQ5V;-FQ5V;-FQ5V;-FQ5_]/O
M^;-FQ5V;-FQ5V;-FQ5V;-FQ5V;-FQ5V;-FQ5V;-FQ5V;-FQ5V;-FQ5V;-FQ5
MV;-FQ5V;-FQ5V;-FQ5V;-FQ5V;-FQ5V;-FQ5V;-FQ5V;-FQ5V;-FQ5V;-FQ5
MV;-FQ5V;-FQ5V;-FQ5V;-FQ5V;-FQ5V;-FQ5V;-