Cryptography-Digest Digest #880, Volume #11 Sun, 28 May 00 17:13:00 EDT
Contents:
Re: list of prime numbers (Jerry Coffin)
TC1a (oops) (tomstd)
Re: RIP Bill 3rd Reading in Parliament TODAY 8th May (Adrian Kennard)
On dynamic random selection of encryption algorithms (Mok-Kong Shen)
Re: Hill's algorithm (Mok-Kong Shen)
Re: Another sci.crypt Cipher (David A. Wagner)
Re: Plain simple (?) question (Alain CULOS)
Re: Crypto patentability (zapzing)
Re: Traffic Analysis Capabilities (zapzing)
Re: PGP wipe how good is it versus hardware recovery of HD? (zapzing)
Re: Retail distributors of DES chips? (zapzing)
Re: No-Key Encryption (zapzing)
My simple cipher ([EMAIL PROTECTED])
Re: No-Key Encryption (Guy Macon)
Re: PGP wipe how good is it versus hardware recovery of HD? (Guy Macon)
Re: Traffic Analysis Capabilities (Guy Macon)
Re: Traffic Analysis Capabilities (Mok-Kong Shen)
Re: No-Key Encryption (Mok-Kong Shen)
----------------------------------------------------------------------------
From: Jerry Coffin <[EMAIL PROTECTED]>
Subject: Re: list of prime numbers
Date: Sun, 28 May 2000 11:16:54 -0600
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] says...
[ ... ]
> If one has a large number (say 150 digits), what are the ways to try
> and break this up into its factors? Where does one start? I think
> that there can only be a limited list of possible prime numbers which
> will actually (when multiplied) come up with the correct public
> modulus.
Yes, it's _very_ limited -- in fact it's limited to exactly the same
pair of numbers that were originally multiplied to produce the number
to start with.
Unfortunately, while those two or three (or whatever) numbers are
drawn from a set that's limited in the theoretical sense (i.e. it's
not an infinite set) it's set so many that a list of all the
possibilties would be FAR too large to store -- even if every atom of
the earth could store a number and you could convert all the matter
in the earthh into such storage, you'd still be WAY short of storing
the whole list. Change "earth" to "solar system" and you're not much
closer. Change it to "milky way galaxy" and you're still only able
to store a TINY fraction of the list...
--
Later,
Jerry.
The universe is a figment of its own imagination.
------------------------------
Subject: TC1a (oops)
From: tomstd <[EMAIL PROTECTED]>
Date: Sun, 28 May 2000 10:17:22 -0700
I found a problem with the original TC1a permutation that bit 29
goes to bit 29. I found another permutation with the following
diff chars. Tommorow I will write a second paper on TC1a
including marks findings on the original TC1.
If anyone has hints onto linear cryptanalysis I would appreciate
it...
It can be found at http://www.tomstdenis.com/tc1ref.c
16r: none
15r: 2^-63.66, 19[0] -> 01[3] p=1/64, 01[3] -> 04[0] p=1/64, 1d
[0] -> 01[3], p=6/256
14r: 2^-62.00, 02[0] -> 05[2] p=1/128, 05[2] -> 02[0] p=1/128
14r: 2^-58.00, 12[0] -> 01[2] p=1/64, 01[2] -> 12[0] p=1/128
14r: 2^-57.66, 19[0] -> 01[3] p=1/64, 01[3] -> 04[0] p=1/64, 1d
[0] -> 01[3] p=6/256
13r: 2^-52.00, 12[0] -> 01[2] p=1/64, 01[2] -> 12[0] p=1/128
* 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: Adrian Kennard <[EMAIL PROTECTED]>
Crossposted-To:
uk.media.newspapers,uk.legal,alt.security.pgp,alt.privacy,uk.politics.parliament,uk.politics.crime,talk.politics.crypto,alt.ph.uk,alt.conspiracy.spy,alt.politics.uk,uk.telecom
Subject: Re: RIP Bill 3rd Reading in Parliament TODAY 8th May
Date: Sun, 28 May 2000 18:21:52 +0100
A_Customer_at_an_easyEverything_Cybercafe wrote:
>
> On Mon, 8 May 2000 14:31:20 +0100, "NoSpam" <[EMAIL PROTECTED]>
> wrote:
>
> >plans were already far advanced for a law that would stop ILOVEYOU ever
> >happening again. Yes, it's that darn RIP bill, still struggling to find
> >supporters in the real world"
>
> If they want to stop I Love you virii, why dont they just get
> everybody to use a secure mail reader? surely it wouldnt cost them a
> lot to switch to somerthing secure, like pine, or any other *nix mail
> reader, or even some windows readers are not too bad. Why spent money
> on a bill that restricts human rights when you could have abetter
> solution for all for free?
I though there were already laws against the ILOVEYOU virus - the
Computer Misue Act for one. I cant see how any law can "stop it
happening", they can simply help ensure the guilty party is punished.
--
_ Andrews & Arnold Ltd, 01344 400 000 http://aa.nu/
(_) _| _ . _ _ Professional Voice and Data Systems for Business.
( )(_|( |(_|| ) Gold Certified Alchemists, BT ISDN/ADSL Resellers
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: On dynamic random selection of encryption algorithms
Date: Sun, 28 May 2000 20:03:46 +0200
I should very much appreciate obtaining critiques and
comments on the following (essentially simple) ideas:
Let there be a set of n block ciphers that are deemed
appropriate for being used in multiple encryptions with
m constituent ciphers (m1 <= m <= m2). Let a PRNG be
chosen by the communication partners and a secret session
key be given. We'll use the key as the seed to the PRNG
to generate pseudo-random number sequences required below.
For each block of plaintext to be encrypted, first
generate a random number m in [m1, m2]. Then randomly
choose m algorithms from the available set of n
algorithms. Subsequently perform a random permutation
of the ordering of these to determine the sequential order
with which the m algorithms are to be placed in the stack
(eventually avoiding, if desired, the case that two
consecutive algorithms in the stack are the same). Finally
generate m keys that are required by these algoritms to do
the encryption of the given block of plaintext.
Note:
1. The block sizes of the algorithms forming a stack need
to be compatible (commensurable) but successive blocks
of the entire scheme (i.e. of the plaintext) need
neither be the same nor commensurable.
2. The special case n = m = 1 reduces to my previous
proposal to use variable keys for block ciphers to defeat
differential analysis and other sophisticated techniques
of attack that rely on the availability of huge amounts
of materials processed by the same key of a block cipher.
3. The scheme effectively forces the opponent to brute force
the seed of the PRNG, which, however, could be made to
be arbitrarily long.
4. The ideas here described are in some sense related to the
one where a PRNG is tightly incorporated (built-in) with a
block cipher. See my humble WEAK-EX series of algorithms.
5. Inferior speed performance could under circumstances be a
disadvantage of the scheme.
M. K. Shen
================================
http://home.t-online.de/home/mok-kong.shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Hill's algorithm
Date: Sun, 28 May 2000 20:15:09 +0200
Mark Wooding wrote:
> You're likely to be plagued by weak keys here. For example,
>
> [ a 0 0 0 ]
> [ 0 b 0 0 ]
> [ 0 0 c 0 ]
> [ 0 0 0 d ]
It is albeit normally understood that a Hill matrix is full.
M. K. Shen
------------------------------
From: [EMAIL PROTECTED] (David A. Wagner)
Subject: Re: Another sci.crypt Cipher
Date: 28 May 2000 11:13:31 -0700
In article <[EMAIL PROTECTED]>,
tomstd <[EMAIL PROTECTED]> wrote:
> I think it's funny that I counted active sboxes upto seven
> compositions of F yet you still found a break for it past that.
> What did I do wrong?
I think you looked for differential characteristics of
F(k1^F(k2^F(k3^F(..F(k7^x)..)))). This need not bear any
relation to differential characteristics of a 7-round Feistel
network using F() as it's F-function.
------------------------------
From: Alain CULOS <[EMAIL PROTECTED]>
Subject: Re: Plain simple (?) question
Date: Sun, 28 May 2000 19:32:44 +0100
Reply-To: [EMAIL PROTECTED]
Ok, lads, I sorta guessed that'd be a dead end. I'm pretty sure this data is
just a hoax anyway (not intended to be actually informative for an investigative
reader).
tomstd wrote:
<snip>
------------------------------
From: zapzing <[EMAIL PROTECTED]>
Subject: Re: Crypto patentability
Date: Sun, 28 May 2000 19:00:46 GMT
In article <[EMAIL PROTECTED]>,
Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
>
>
> Mok-Kong Shen wrote:
>
> > I suppose that our group, as the largest (as far as I
> > am aware) public crypto community, should form certain
> > unified standpoint as to what is and what is not
> > patentable in crypto in our conviction, so as to
> > (hopefully) influence the future patent policy in the
> > same way as in fields of e.g. human gene sequencing.
>
> While it is very depressing and frustrating to reflect on the
> current miserable status of patent granting in the field of
> software/crypto in general and on the Hitachi vs AES affair
> (see also Science, p. 1161-1163) in particular, it probably
> helps to get a glimpse of hope nevertheless through reading
> what is happening in another branch of science:
>
> ''Greens persuade Europe to revoke patent on neem
> tree ... '', Nature, 18 May 2000, p.266-267.
>
> Joint effort and work is definitely needed. Otherwise there can
> be no chance of any improvements, quite evidently.
>
> M. K. Shen
But here in the United States it is universally
recognized that political action takes both time
and *Money* . Anyone who could affort to mount
such an attack would *Necessarily* have an
economic stake on doing so, and would therefore
be susceptible to the argument that they were
doing it "for the money".
--
If you know about a retail source of
inexpensive DES chips, please let
me know, thanks.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: zapzing <[EMAIL PROTECTED]>
Subject: Re: Traffic Analysis Capabilities
Date: Sun, 28 May 2000 19:07:32 GMT
In article <[EMAIL PROTECTED]>,
Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
>
>
> zapzing wrote:
>
> > If you access this site, your name will automatically
> > be entered into the FBI's troublemaker file.
> > Come to think of it, your name is probably there already.
>
> If the site is publically accessible, the materials there cannot be
> classified ones. If you are not sure, you have the option of taking
> some refreshments in an internet cafe.
>
> M. K. Shzen
Those are awfully hard to come by if you
don't live in a big city.
--
If you know about a retail source of
inexpensive DES chips, please let
me know, thanks.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: zapzing <[EMAIL PROTECTED]>
Subject: Re: PGP wipe how good is it versus hardware recovery of HD?
Date: Sun, 28 May 2000 19:23:12 GMT
In article <[EMAIL PROTECTED]>,
"Trevor L. Jackson, III" <[EMAIL PROTECTED]> wrote:
(snip)
>
> This is not true. Thermal variations alone will induce track
positioning and
> width variations.
>
> Further you can look up "head settle time". It doesn't end when the
head is
> perfectly still, it ends when the head is stable enough to avoid
overwriting
> adjacent tracks. In fact the head never settles perfectly because it
flies just
> above the surface of the recording medium, and air turbulence
continually
> disturbs it. In fact this air turbulence produces an effect so
distinctive that
> it is a proposed source of entropy for hardware RNGs. It the head is
moving
> with laterally respect to the track then there will be traces of the
previous
> flight path where it does not match the current flight path.
>
> Variations in the timing flux changes also provides an avenue of
recovery of
> previously written data both because overwriting does not completely
erase the
> previous state and because variations in rotational speed make it
impossible to
> put the new flux change exactly on opt of an old flux change even when
you write
> exactly the same data.
In fact, I have come to the conclusion that you
should never put anything on a hard disk unless
you would also be willing to post it to the net.
That means hardware encryption of your
entire hard disk. Use key managenment, and the
mere act of cancelling a certain key will "wipe
out" all the information encoded by that key.
No multi pass overwriting required.
--
If you know about a retail source of
inexpensive DES chips, please let
me know, thanks.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: zapzing <[EMAIL PROTECTED]>
Subject: Re: Retail distributors of DES chips?
Date: Sun, 28 May 2000 19:37:58 GMT
In article <8gqjuu$i8k$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Jonathan Thornburg) wrote:
> In article <8gn7gu$3at$[EMAIL PROTECTED]>, zapzing
<[EMAIL PROTECTED]> asked
> >But if I go with
> >software encryption then how can I be certain that
> >DES was actually used, and not some less
> >powerful algorithm?
>
> Ultimately you, or people you trust, have to carefully study each and
> every line of the source code. And the source code for the compiler,
> linker, and every other piece of software in the toolchain. And that
> of the OS (and all the toolchain used to build it). Ditto for the CAD
> software used to design the microprocessor. Etc etc.
>
> This is what people who are really serious about their crypto, i.e.
the
> spooks, do: they manufacture a fair bit of hardware in-house, and
contract
> the rest to "trusted" companies. Similarly for software.
>
> If you can't afford that level of parania, then using widely-studied
free
> software can be a fairly good approximation: You may have not
personally
> examined all of the approximately 1 million source code lines in GCC,
> but enough other people -- and people from many different
organizations
> who are not plausibly all in a monster conspiracy -- have worked and
> are working on the GCC code base, that we can be fairly confident that
> any trojan horses planted there would soon be discovered.
>
> As for hardware bugs, well, one could certainly imagine trojan horses
> planted in (say) Pentium chips... but it's much harder to keep this
sort
> of thing secret in the commercial world than in spook-land. Besides,
> while Ken Thompson showed a long time ago how to trojan-horse a
compiler
> ( http://www.acm.org/classics/sep95/ , also available at
> http://www.cs.umsl.edu/~sanjiv/sys_sec/security/thompson/hack.html
),
> this relied on being able to pattern-recognize a particular pattern of
> code. It's certainly possible for (say) Intel to trojan-horse the
PIII
> to pattern-recognize a particular byte sequence in the instruction
stream,
> but [outside the Microsoft word] this fails when we have many
different
> pieces of crypto software, compiled by many different compilers.
>
It would seem that the only safe places are at the
extremes: either use software that is obfuscated,
or use your own hardware. I know you believe in
"well examined" software, But I don't, because
well examined software is usually not obfuscated
(well not after it is publicized it isn't).
So even though the source may be perfect, and
even perhaps the object code is perfect also,
there is no guarantee that the OS will actuall
do what you want it to do.
One thing I think can be done, though I'm not
even close to working out all the details, is
to "split" a plaintext into two secrets, using
only your own hardware made from discrete
components. Once its split it can be cleaned
up with ICs. What this can be used for I'm
not quite sure either, except it would
make it harder to recognize the difference
between a trick question and an actual
encryption.
In other words, I'm not giving up just yet.
--
If you know about a retail source of
inexpensive DES chips, please let
me know, thanks.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: zapzing <[EMAIL PROTECTED]>
Subject: Re: No-Key Encryption
Date: Sun, 28 May 2000 19:57:43 GMT
In article <[EMAIL PROTECTED]>,
Michael Pellaton <[EMAIL PROTECTED]> wrote:
> In the literature about cryptography I often read about the three
> different types of encryption - symmentric, asymmetric and Nop-Key
> encryption. I found plenty implementations of the symmetric and the
> asymmetric methode. Is there any implementation of no-key ecnryption
> available?
>
No-key encryption. Never heard of it. could
you be talking about a hash function?
Perhaps if you culd post some of the
"literature" in which this phrase appears,
it would be easier to find out what you mean.
--
If you know about a retail source of
inexpensive DES chips, please let
me know, thanks.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED]
Subject: My simple cipher
Date: 28 May 2000 20:28:09 GMT
Hi, I've been lurking a while and thought I'd post this for some peer review.
I came up with a simple cipher with some common characteristics to ARCFOUR,
and I was wondering have I done anything blatantly stupid <G>. The comparison
is on
< http://www.karma.tj/enc.html >
If anyone wants to have a look. It's not exactly clear though :/
Anyway, sorry to intrude, nice group btw.
--
Aaron
------------------------------
From: [EMAIL PROTECTED] (Guy Macon)
Subject: Re: No-Key Encryption
Date: 28 May 2000 16:33:06 EDT
No-key encryption is really fixed-key/single-key encryption. The
"Key" is often hardwired into the algorithm. In a keyed system,
knowing the algorithm isn't enough, because the same algorithm gives
different results with different keys. In a no-key system, security
through obscurity is employed.
Consider this thought experiment; take a strong cipher with separate
encryption and decryption keys. Change the algorithm so that the keys
are constants that are hardwired into the code. Instead of keeping
the keys (which you don't have anymore) secret, keep the algorithms
(with embedded keys) secret. The result is a no-key system that is
as resistant to cryptanalysis as the original keyed system was.
The possibility exists that there exist no-key algorithms with no
key equivalents, but it is obvious that there are no keyed algorithms
without no-key equivalents - just turn the key variable into a constant
to make one.
That being said, no-key systems are usually a Really Bad Idea.
You can memorize a key, but you have to store a program somewhere.
------------------------------
From: [EMAIL PROTECTED] (Guy Macon)
Subject: Re: PGP wipe how good is it versus hardware recovery of HD?
Date: 28 May 2000 16:35:44 EDT
In article <8grrml$30e$[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote:
>In fact, I have come to the conclusion that you
>should never put anything on a hard disk unless
>you would also be willing to post it to the net.
>That means hardware encryption of your
>entire hard disk. Use key managenment, and the
>mere act of cancelling a certain key will "wipe
>out" all the information encoded by that key.
>No multi pass overwriting required.
>
>--
>If you know about a retail source of
>inexpensive DES chips, please let
>me know, thanks.
Why do you believe that the encryption must be in
hardware? Why couldn't you use device driver software?
------------------------------
From: [EMAIL PROTECTED] (Guy Macon)
Subject: Re: Traffic Analysis Capabilities
Date: 28 May 2000 16:42:55 EDT
In article <8grcmc$p1t$[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote:
>
>In article <8gqsdf$[EMAIL PROTECTED]>,
>
> [EMAIL PROTECTED] (Guy Macon) wrote:
>>
>> This site led me to a GREAT one.
>>
>> http://astimage.daps.dla.mil/quicksearch/
>>
>> "direct access to nearly 100,000 full text DoD Specifications and
>> Standards available in the DoD master repository - does a not
>> require an account and password and makes documents available to
>> the public free of charge."
>
>If you access this site, your name will automatically
>be entered into the FBI's troublemaker file.
>Come to think of it, your name is probably there already.
>
>Never mind.
They will see a Quaker who claims to avoid being anonymous for
religious reasons but provides anonymity tools to others, also
forvreligious reasons, an EE who currently designs electronic
toys, and a life that is an open book with nothing to hide.
Of course, I may or may not also be the Notorious <deleted>,
Anonymous Uberhacker who has escaped detection for all of these
years. I'm not saying that I am, and I am not saying that I am
not...
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Traffic Analysis Capabilities
Date: Sun, 28 May 2000 23:06:27 +0200
Concerning traffic analysis, I heard in a lecture the other day that
location and call of cellphones are being kept in Europe in
databases for certain purposes.
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: No-Key Encryption
Date: Sun, 28 May 2000 23:06:34 +0200
Boris Kazak wrote:
> Michael Pellaton wrote:
> >
> > In the literature about cryptography I often read about the three
> > different types of encryption - symmentric, asymmetric and no-key
> > encryption. I found plenty implementations of the symmetric and the
> > asymmetric methode. Is there any implementation of no-key ecnryption
> > available?
>
> Lots of these exist on the bookshelves on form of dictionaries
> (English/Greek, Russian/Spanish, French/Chinese, etc)
Well employed in WWII in the front. See Kahn's book. Employing
different dialects might also be helpful for ''voice encryption'' under
circumstances.
Frequently switching languages may indeed be a good idea
supplementary to frequently changing keys.
I learned that linguists are currently worrying about a number
of living languages going into extinction. Therefore cryptographers
of the world should unite to preserve them! Hopefully the work
load (and hence the efficiency) of Echelon and its less reknown
companions would thereby receive an agreeable significant
augmentation.
M. K. Shen
------------------------------
** 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
******************************
