Cryptography-Digest Digest #361, Volume #11 Sat, 18 Mar 00 20:13:01 EST
Contents:
Re: new Echelon article (JimD)
Re: Card shuffling (JimD)
Re: new Echelon article ("Andy Culp")
Big Float: square root (Mike Rosing)
SHA-1 as a stream cipher (Michael K)
Re: Card shuffling (Tim Tyler)
Re: 64-bit Permutations (Tim Tyler)
Re: Public timestamping servers (Helger Lipmaa)
Re: Enigma encryption updated (Adam D) (David Hopwood)
Re: SALT with RC4, where do I store the SALT? (Guy Macon)
Re: 64-bit Permutations ([EMAIL PROTECTED])
Re: SHA-1 as a stream cipher ("Scott Fluhrer")
Re: Big Float: square root (Mok-Kong Shen)
Re: Help needed on peculiar use of cryptography
([EMAIL PROTECTED])
Re: Cipher Contest ("Adam Durana")
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (JimD)
Crossposted-To:
alt.politics.org.cia,alt.politics.org.nsa,talk.politics.crypto,alt.journalism.print,alt.journalism.newspapers
Subject: Re: new Echelon article
Reply-To: JimD
Date: Sat, 18 Mar 2000 20:28:20 GMT
On Sat, 18 Mar 2000 15:01:58 GMT, [EMAIL PROTECTED] wrote:
>On Sat, 18 Mar 2000 09:33:08 GMT, "Douglas A. Gwyn" <[EMAIL PROTECTED]>
>wrote:
>
>>Jos Horikx wrote:
>>> Another interesting echelon-article on:
>>> http://cryptome.org/echelon-cia2.htm
>>
>>Thanks; that was a refreshing change from Duncan-Campbellism.
>
>Made even more interesting in that Mr. Woolsey is defending himself
>and his methods of industrial espionage against accusations not yet
>cast.
>
>Mr. Woolsey claims in that Wall Street Journal opinion that the EU
>report accuses the CIA/NSA of using Echelon to steal technology from
>non-U.S. companies. While I don't doubt that technology theft occurs,
>the report by Duncan Campbell -- from my reading of it -- concerned
>itself with asserting the U.S. might be using this eavesdropping
>network to help specific companies _win contracts_.
Well of course they do! Isn't '...the economic well-being of the
United States.' part of the NSA's mission statement?
They ALL do it...Britain, France, Germany, Israel, Russia, China...
New focus to justify their existence post Cold-War, and it helps
to maintain the funding.
--
Jim Dunnett.
dynastic at cwcom.net
Exiled in Somerset
Right at the heart of England's BSE Industry.
------------------------------
From: [EMAIL PROTECTED] (JimD)
Subject: Re: Card shuffling
Reply-To: JimD
Date: Sat, 18 Mar 2000 20:28:21 GMT
On Sat, 18 Mar 2000 10:58:24 +0100, Mok-Kong Shen <[EMAIL PROTECTED]>
wrote:
>Although I have never played a card game, I do know the action of
>shuffling. Evidently a veteran player shuffles (nearly) perfectly,
>while a novice often does less well and a kid maybe very poorly.
>Does there exist any objective means to determine (or help to
>determine) the relative quality of shuffling or is one left to
>rely on pure subjectivity in deciding on that issue?
To talk of perfection in shuffling cards is like talking about
a perfect series of random numbers.
--
Jim Dunnett.
dynastic at cwcom.net
Exiled in Somerset
Right at the heart of England's BSE Industry.
------------------------------
From: "Andy Culp" <[EMAIL PROTECTED]>
Crossposted-To:
alt.politics.org.cia,alt.politics.org.nsa,talk.politics.crypto,alt.journalism.print,alt.journalism.newspapers
Subject: Re: new Echelon article
Date: Sat, 18 Mar 2000 15:54:27 -0600
>New focus to justify their existence post Cold-War, and it helps
>to maintain the funding.
>
I think that makes perfect sense, why would the government have them if they
weren't worth their money? The NSA obviously has to do something useful or
all of the billions of dollars in funding would be put somewhere else.
~Andy Culp
------------------------------
From: Mike Rosing <[EMAIL PROTECTED]>
Subject: Big Float: square root
Date: Sat, 18 Mar 2000 21:53:34 GMT
Fixed a bunch of bugs and added one more basic function. Turns out that
the division algorithm in Knuth does not work, so I switched to one that
does. There seems to be a bug in the ascii_to_float routine for very
small numbers, it spews out tons of zeros before giving any value.
Further!
Patience, persistence, truth,
Dr. mike
------------------------------
From: Michael K <[EMAIL PROTECTED]>
Subject: SHA-1 as a stream cipher
Date: Sat, 18 Mar 2000 17:01:10 -0500
Does anyone have any thoughts on using SHA-1 as a stream cipher?
I'll clarify...
Lets say you have a block of data to encrtypt....
D = data to encrypt
K = hash of user input password
DO
-------------------------------------------
xor the next 160 bytes of D with K (one byte at a time)
-------------------------------------------
then...
K = hash of K
LOOP (until data is completely encoded)
Any thoughts/ideas would be great.
Thanks,
Mike K
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Card shuffling
Reply-To: [EMAIL PROTECTED]
Date: Sat, 18 Mar 2000 22:00:50 GMT
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Card shuffling
Newsgroups: sci.crypt
References: <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
Organization:
Reply-To: [EMAIL PROTECTED]
Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
: The new problem is now how to 'measure' randomness and that
: involves further the (difficult) problem of defining 'randomness'.
: Of course, we want something that is 'practical' not the stuffs of
: the pedantic people who demand (absolute) perfectness. But I am
: yet ignorant of anything that could be useful in that direction.
Knuth made serious attempts to both formally define randomness, and to
present statistical tests that attempted to measure deviations from it,
in TAOCP v.2.
These seem applicable to shuffling - since a good shuffle represents a
sequence where at any point the next card in the deck is chosen at random
from those not yet dealt.
There are various ways of turning the information in a shuffled pack into
a what would be a genuinely random sequence - *if* the shuffle was a
random permutation in the first place.
: If we can have a 'measure' of randomness, then we could determine
: how well a deck gets shuffled, I suppose. At least we can then
: say that one deck is better shuffled than the other. So the central
: problem is to obtain such a 'measure'. Does anyone have suggestions?
Diehard? ENT?
--
__________
|im |yler The Mandala Centre http://www.mandala.co.uk/ [EMAIL PROTECTED]
The more I learn about people, the more I like my cat.
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: 64-bit Permutations
Reply-To: [EMAIL PROTECTED]
Date: Sat, 18 Mar 2000 22:12:40 GMT
[EMAIL PROTECTED] wrote:
: A non-repetitive sequence of all 2^64 elements in the set of 64 bit
: sequences is 64*(2^64) bits long. I am then talking of a permution of 64-bit
: _values_.
How could you /possibly/ use that as a cypher?!
The LUT required to describe a permutation of 64 bit *values* would
normally be factorial(64) in size.
--
__________
|im |yler The Mandala Centre http://www.mandala.co.uk/ [EMAIL PROTECTED]
The only time I open my mouth is to change feet.
------------------------------
From: Helger Lipmaa <[EMAIL PROTECTED]>
Subject: Re: Public timestamping servers
Date: Sun, 19 Mar 2000 00:32:36 +0200
Logi Ragnarsson wrote:
> Hi!
>
> I have written a simple time stamping server which returns the usual
> signed timestamp of a short string you supply (should be a hash normally)
> and with some features to allow third-party authentication of the logs.
>
> Are there already servers like this on the 'net? Is this something that
> is worth actually putting up?
Our research group has been working on time-stamping a lot during the latest
years, including several innovative secure and efficient time-stamping
schemes. See http://home.cyber.ee/helger/cuculus for more information,
including publications and link to a functioning time-stamping service, but
also time-stamping links.
Helger Lipmaa
http://home.cyber.ee/helger
------------------------------
Date: Sat, 18 Mar 2000 13:00:53 +0000
From: David Hopwood <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: Enigma encryption updated (Adam D)
=====BEGIN PGP SIGNED MESSAGE=====
Nemo psj wrote:
[...]
> 'Generate Keybyte k
> k = s((s(i) + s(j)) Mod 255)
> 'Plaintextbyte xor Keybyte
> cipherby = Asc(Mid$(plaintxt, a, 1)) Xor k
> ' Inserting fix for ch(0) bite
> If Chr(cipherby) = Chr(0) Then
> cipherby = 1
> Else:
> End If
> cipher = cipher & Chr(cipherby)
This can't even be unambiguously decrypted (the lowest bit will be
wrong for 1 in 256 characters).
If VB strings can't include zero bytes, then the ciphertext can't be
represented as a string, period. Don't try to kludge around this, fix
it properly (by using some other type that can represent zero bytes,
or possibly more productively, by not using VB).
- --
David Hopwood <[EMAIL PROTECTED]>
PGP public key: http://www.users.zetnet.co.uk/hopwood/public.asc
RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5 0F 69 8C D4 FA 66 15 01
=====BEGIN PGP SIGNATURE=====
Version: 2.6.3i
Charset: noconv
iQEVAwUBONN9yjkCAxeYt5gVAQELHwf7B1PpCQQn6EZ0fkCEZ81X2Hr5JF8Y2yNE
ym6OSisAH5QmSikI40YBkuIKJ/rCGtQ+3r9w25MJ0Syzy0wQE64vgXuKYdizGybk
jmtOsViFDGiW+epuS0Bzi/r/S/Eiy0UWlb19zhWfGqVbXdZu0UltOPRzrJCq8lTv
PUSShuhM+Y3BQsZVdhOYZRTZ61YpCzFebUUWqLyIuAJ0E2ekbUV5q1lVcroes7pM
YCvx76ghTXZHCbtSz1Xbf/doVgLSgoMiBp6cMxb1RrLk3vmbCID7g+nNIppOKGSq
3esJKHq6rrbwRL3rPTyb9m3tO+8Z8dXnpAfH4s0SepBDs1rcTX6arg==
=yJt4
=====END PGP SIGNATURE=====
------------------------------
From: [EMAIL PROTECTED] (Guy Macon)
Subject: Re: SALT with RC4, where do I store the SALT?
Date: 18 Mar 2000 17:59:09 EST
In article <8b0i34$te$[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Bill Unruh)
wrote:
>
>In <8avf6t$[EMAIL PROTECTED]> [EMAIL PROTECTED] (Guy Macon) writes:
>]>The suggestion is that you pretend encrypt or decrypt so many bytes of
>]>ether, before beginning encryption or decryption of your data. The
>]>reason is that the RC4 algorithm has been shown to have some
>]>weaknesses in its key preparation routine. This action stirs up the
>]>key state to get past that weakness.
>
I didn't write that. I am the clueless newbie asking intelligent
questions, not the voice of experience who provides the answers.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: 64-bit Permutations
Date: 18 Mar 2000 23:11:01 GMT
You are in fact restating the point I was trying to make to begin with. ;-)
..and to answer your question, I could possibly use that as a cipher at the
time when computers can store and process such amounts of data (but by then
it would also be useless as a cipher).
In a previous article, Tim Tyler <[EMAIL PROTECTED]> writes:
>[EMAIL PROTECTED] wrote:
>
>: A non-repetitive sequence of all 2^64 elements in the set of 64 bit
>: sequences is 64*(2^64) bits long. I am then talking of a permution of
64-bit
>: _values_.
>
>How could you /possibly/ use that as a cypher?!
>
>The LUT required to describe a permutation of 64 bit *values* would
>normally be factorial(64) in size.
>--
>__________
> |im |yler The Mandala Centre http://www.mandala.co.uk/ [EMAIL PROTECTED]
>
>The only time I open my mouth is to change feet.
----- Posted via NewsOne.Net: Free Usenet News via the Web -----
----- http://newsone.net/ -- Discussions on every subject. -----
NewsOne.Net prohibits users from posting spam. If this or other posts
made through NewsOne.Net violate posting guidelines, email [EMAIL PROTECTED]
------------------------------
From: "Scott Fluhrer" <[EMAIL PROTECTED]>
Subject: Re: SHA-1 as a stream cipher
Date: Sat, 18 Mar 2000 15:25:31 -0800
Michael K <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Does anyone have any thoughts on using SHA-1 as a stream cipher?
>
> I'll clarify...
>
> Lets say you have a block of data to encrtypt....
>
> D = data to encrypt
> K = hash of user input password
>
> DO
> -------------------------------------------
> xor the next 160 bytes of D with K (one byte at a time)
I assume you mean 160 bits...
> -------------------------------------------
>
> then...
>
> K = hash of K
>
> LOOP (until data is completely encoded)
>
> Any thoughts/ideas would be great.
Problem: if you attacker guesses the value of K at any point (that is, he
got a matched plaintext/ciphertext pair for a 160 bit block), then he knows
the keystream beyond that point.
--
poncho
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Big Float: square root
Date: Sun, 19 Mar 2000 01:21:50 +0100
Mike Rosing wrote:
>
> Fixed a bunch of bugs and added one more basic function. Turns out that
> the division algorithm in Knuth does not work, so I switched to one that
> does. There seems to be a bug in the ascii_to_float routine for very
> small numbers, it spews out tons of zeros before giving any value.
I am rather surprised by this, since Knuth's books are sort of
bible in CS. Could you please supply some more information about the
presumed trouble, giving the exact locations in the text, etc?
Thanks.
M. K. Shen
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Help needed on peculiar use of cryptography
Date: Sun, 19 Mar 2000 00:43:10 GMT
The solution to this is not one way hashes, cryptography etc, etc.
Simply generate a table of unique (ie reject repeats) random numbers
where the numbers are several orders of magnitude greater than the
total number of records, and which has as many entries in the table as
there are SSN you wish to replace. Append the random numbers one per
SSN record in the order they are generated. Sort the records on the
random numbers. Append a new sequential record id to the sorted
records. Delete the SSNs and the random numbers.
I have assumed that there is one record per SSN, but only trivial mods
are required if not.
In fact simply assigning the random numbers and deleting the SSNs is
enough, but assigning a shorter sequential UID reduces the ID field
size, and has some advantages for record handling.
Also I note that elsewhere in the thread people have discounted the
issue of collisions. For your purposes, being collision free (ie
avoiding false duplicates) is a MUST, since you are doing this for the
purposes of record linkage to be used in a legal situation. The last
thing you want is some clever lawyer casting doubt on your findings
because they may be due to a collision rather than a true match.
cheers
On 28 Jan 2000 21:27:34 GMT, [EMAIL PROTECTED] (Sgwbutcher)
wrote:
>Dear forum,
>
>I am an economist and in the course of my work, I often have access to
>sensitive information. For example, in a discrimination case, I may have access
>to personnel records covering several years for all the employees of a company.
>Because I often have to match records across different payperiods, months and
>years, a unique identifier is required for each record, often the social
>security number. Because of various laws and company policies about the use of
>social security numbers or any other identifier, I always sign a
>confidentiality agreement with regard to the disclosure of this information.
>However, sometimes companies are unwilling to part with information even in the
>case of confidentiality agreements.
>
>My question is "is there a way that encryption or a specific use or kind of
>encryption can be used so that, say, a social security number can be encrypted
>so that the informational value of the cyphertext can be retained but the
>plaintext cannot be recovered? and is the code for this method accessible as
>the actual implementation may be, depending on the case, in Excel, SAS, C/C++,
>Perl or Java?"
>
>I think the most important points are (1) this is permanent encryption--is no
>"legitimate" reason why the cyphertext would ever be decrypted and (2) the
>domain of the plaintext is very small, 0-9 and short length cyphertext and (3)
>the information value of the cyphertext should be the same as the plaintext,
>that is, if plaintext A identifies a particular record over 5 years, then
>cyphertext A should reference the same records and no others.
>
>One obvious solution is to come up with a new identifier scheme, the problem is
>that many IT/DP departments are unwilling to invest the effort and the
>databases can be quite large and there may be multiple identifiers.
>Additionally, in the case of employee numbers, a simple start at 1001 and go on
>approach is how they got their employee numbers to begin with so although you
>don't have necessarily the employee number you're looking for, you do have
>someone's employee number. This is why I'm looking for something a little more
>algorithmic.
>
>Any possible help/suggestions you might be able to provide would be
>appreciated.
>
>Thanks,
>
>Steve
>
>--------------------------------------------------------------------------
>------
>Stephyn G. W. Butcher
>Consultant in Labor Economics and Statistics
>1760 Euclid St. NW Suite 306
>Washington, DC 20009
>(202) 745-0114 fax: (202) 745-0446
>[EMAIL PROTECTED]
------------------------------
From: "Adam Durana" <[EMAIL PROTECTED]>
Subject: Re: Cipher Contest
Date: Sat, 18 Mar 2000 20:01:56 -0500
> It would be easy to change my cipher to fight 512 bits. since one only
> has to treat each block as a small file. But I see no reson to limit the
key
> size to such a small space. IF you make rules I can see you saying it
could
> support keys of some fixed small size but it should not be eliminated just
> becasue it would allow a user to use keys that are thousands of times
longer
> you could just use for testing and the contest a subset of the true key
space.
> One thing you have not mentioned but should be addressed is how do you
wish
> the encryption package to handle files that donot mesh with the 512 bit
block
> size. Or for the purpose of your contest do you wish to limit input files
to
> nice lengths.
I didn't mean ciphers that supported key lengths or block lengths greater
than the requirements would be removed, I meant the version of the cipher
that would be analyzed/entered in the contest, would be limited by the
requirements. I think having certain limitations would make entries easier
to analyze. But perhaps we should just do away with all restrictions, the
more people bring up doing away with all restrictions the more viable it
seems. Well except one restriction, the type of cipher should be a block
cipher. Since this will still be a contest of sorts I think we still need
to have the ciphers be of the same type.
As for files' last block being too short I say people should just pad it, or
use "cipher text stealing". Or if the algorithm provides some sort of
solution to it that would be fine too. So the solution to this problem
would be up to the designer/submitter.
Well one more thing, I think the resource requirements for a cipher that is
submitted should be reasonable, or justifiable.
So ...
Requirements:
Block Cipher
Reasonable/Justifiable resource usage.
Anyone have a problem with those?
- Adam
------------------------------
** 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
******************************
