Cryptography-Digest Digest #565
Cryptography-Digest Digest #565, Volume #13 Sat, 27 Jan 01 02:13:00 EST
Contents:
Re: Between Silk and Cyanide ([EMAIL PROTECTED])
Re: Dynamic Transposition Revisited (long) (John Savard)
Re: Dynamic Transposition Revisited (long) ("Matt Timmermans")
Re: Steak Stream Cipher ([EMAIL PROTECTED])
32768-bit cryptography, updated ("lemaymd")
Re: Dynamic Transposition Revisited (long) (Terry Ritter)
Re: Dynamic Transposition Revisited (long) (Terry Ritter)
Re: 32768-bit cryptography, updated ("Scott Fluhrer")
Re: Dynamic Transposition Revisited (long) (Terry Ritter)
Re: Dynamic Transposition Revisited (long) (John Savard)
Re: 32768-bit cryptography, updated ("Matt Timmermans")
no joke (adam)
From: [EMAIL PROTECTED]
Subject: Re: Between Silk and Cyanide
Date: Sat, 27 Jan 2001 02:11:56 GMT
In article <_Kic6.67331$[EMAIL PROTECTED]>,
"Roger Peniston-Bird" <[EMAIL PROTECTED]> wrote:
<< For instance, what happened to Giskes, who captured so many agents
sent to the Netherlands? Did he survive the war? >>
Giskes not only survived the war, he wrote a book about the whole
affair. An English translation was published in 1953 by British Book
Centre, Inc. and by William Kimber and Co, in London. It was reprinted
in paperback by Bantam Books in 1982 under the title, London Calling
North Pole.
I found it odd that Marks never mentions Giskes' book. There was an
investigation in the Netherlands after the war, which seems to have
drawn considerable publicity in both the Netherlands and England, and I
suspect that the publication of Giskes' book was due entirely to the
controversy stirred up by this investigation, yet Marks takes no notice
of this in his book.
-- Jeff Hill
Sent via Deja.com
http://www.deja.com/
--
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Dynamic Transposition Revisited (long)
Date: Sat, 27 Jan 2001 02:11:54 GMT
On Sat, 27 Jan 2001 01:20:23 GMT, [EMAIL PROTECTED] (Terry Ritter) wrote,
in part:
>There is simply no hope of being able to reach every possible
>conventional block cipher substitution "table" in the same way that
>Dynamic Transposition can reach every possible permutation.
Absolutely! I agree with that 100%.
But what I'm on about is that that's a comparison between apples and
oranges.
Two rounds of DES with independent subkeys can produce 2^32 different
substitutions which will take any plaintext block P to any ciphertext
block C.
Similarly, "every possible permutation" can produce, for every N-bit
balanced block P, every possible N-bit balanced block C, in
(N/2)!(N/2)! different ways.
However, DES cannot produce every possible overall substitution, every
possible table C(0),C(1),C(2^64-1) of output ciphertext blocks
from input plaintext blocks.
And transposition, period, also cannot produce every possible overall
substitution, every possible table C()
C() where the 12870 possible balanced 16-bit blocks,
(for N=16) are assigned, as ciphertext outputs, to the 12870 possible
balanced 16-bit blocks as inputs.
Transposition of balanced blocks is "better than XOR", because there
is more than one way to get from a particular P to a particular C, but
it does not have the sort of exhaustiveness that you are demanding a
substitution-based polyalphabetic block cipher have in order to be
comparable to Dynamic Transposition. The exhaustiveness it does have,
"all possible transpositions", is not equivalent.
Maybe it seems so because 'transposition' is treated as a class of
encipherment in itself, comparable to 'substitution'; this isn't a
semantic problem, it's a conceptual problem; I think you may be a
victim of the Whorf hypothesis, that language limits how we can think.
John Savard
http://home.ecn.ab.ca/~jsavard/crypto.htm
--
From: "Matt Timmermans" <[EMAIL PROTECTED]>
Subject: Re: Dynamic Transposition Revisited (long)
Date: Sat, 27 Jan 2001 02:28:25 GMT
"AllanW" <[EMAIL PROTECTED]> wrote in message
news:94sl80$alu$[EMAIL PROTECTED]...
> I think I missed one of my classes when I learned programming.
> Could you please show me the code corresponding to "generate a
> photon?" Use any well-known computer language -- ADA, APL,
> BASIC, C, C++, COBOL, FORTRAN, PASCAL -- whatever you feel
> comfortable with. I just need to see the basic algorithm for
> "generate a photon."
It sounds more like you missed the drunken argument in the college bar about
the feasibility of strong AI, the limits of simulation, the possibility that
that nature can support useful modes of super-Turing computation, who that
girl in the corner is _really_ checking out, and whether or not Bob tries to
coerce his partners into cheating at Euchre.
--
From: [EMAIL PROTECTED]
Subject: Re: Steak Stream Cipher
Date: Sat, 27 Jan 2001 02:33:08 GMT
In article <94t6g3$qai$[E
Cryptography-Digest Digest #564
Cryptography-Digest Digest #564, Volume #13 Fri, 26 Jan 01 21:13:00 EST
Contents:
Last revision ("lemaymd")
Re: solving simultaneous equations in modulo arithmetic ("Matt Timmermans")
Re: RSA Source code ("Adam Smith")
Re: Decode Algorythim ("Yeah")
Re: Steak Stream Cipher (Bryan Olson)
Random Number Generator ([EMAIL PROTECTED])
Re: Dynamic Transposition Revisited (long) (Terry Ritter)
Re: Paranoia ("Douglas A. Gwyn")
Re: Dynamic Transposition Revisited (long) (Terry Ritter)
Re: Random Number Generator ("Douglas A. Gwyn")
Re: Dynamic Transposition Revisited (long) ("Douglas A. Gwyn")
From: "lemaymd" <[EMAIL PROTECTED]>
Subject: Last revision
Date: Fri, 26 Jan 2001 18:31:18 -0600
Thanks for those final pieces of advice! I've modified my algorithm for
hopefully the last time using your suggestion and Joseph Ashwood's. He said
as I understand it that having eight encryption rounds doesn't do much
except slow my algorithm down. So without further ado, here it is:(an
excerpt from my documentation)
3. Description of algorithm
a. Key mutation
Encryption using the Bermuda Triangle 2.1 algorithm consists of several
steps consisting of XOR, rotate and addition operations, involving three key
derived values. It operates with 32768-bit plaintext and ciphertext blocks
controlled by a 32768-bit key, referred to as K0. The principal advantage
of this algorithm is the requirement that the entire key be known before any
decipherment can take place. This is insured by two key mutations,
described here.
The first key derivative is created by loading the first byte of K0, storing
it in a register and to memory, loading the next byte and XORing it against
the register containing the first byte, storing the register contents to the
next memory location and loading each subsequent byte in this manner, XORing
it against this register and storing it to memory. This key derivative is
referred to as K1. The original key, once again, is referred to as K0.
To form the second key derivative the entire key is loaded one byte at a
time from the end of the key to its beginning, stored to a register, XORed
and stored to a memory location as for K1. Note: the last byte in this
memory area will always equal the original key data. This key is referred
to as K2. These keys are now ready to be used in the encryption and
decryption processes.
b. Encryption
The actual encryption process involves one round of twelve XOR, addition and
bitwise rotation operations involving the three key mutations described
earlier and the original plaintext. The identification tag described in
section 2 is placed in the first twelve bytes of this file.
The steps involved are illustrated in this pseudocode segment:
Variables:
C Ciphertext
Kx Key "x"
P Plaintext
X Current byte position
Y Current key offset
Z General purpose register
C[x] = ( ( ( ( ( ( ( ( ( ( ( (
^ K2[y] ) + K1[y] ) >>> K0[y] )
^ K1[y] ) + K2[y] ) >>> K1[y] )
P[x] ^ Z ) + Z ) <<< Z{5lsbits} )
^ K0[y] ) + K0[y] ) >>> K2[y] )
Z = (Z^P[x])
Legend:
^ XOR
+ addition
<<< rotate left
>>> rotate right
"Scott Fluhrer" <[EMAIL PROTECTED]> wrote in message
news:94lo0p$j71$[EMAIL PROTECTED]...
>
> lemaymd <[EMAIL PROTECTED]> wrote in message
> news:94l9ds$k2m$[EMAIL PROTECTED]...
> > Poncho,
> > From what you've written, it's looks as though simplicity is not
this
> > cipher's weakness. What path would you suggest to strengthen it? I
> don't
> > truly understand how you would retrieve a completely random key (which
of
> > course it's not, but for simplicity let's say it is) when you have only
> the
> > ciphertext. Theoretically, as is the case with the true stream cipher,
> one
> > XOR operation between the key and data should be sufficient to make an
> > entirely impossible to crack piece of ciphertext. Because of the huge
> size
> > of the key utilized by this algorithm, it almost qualifies as a stream
> > cipher itself. Thanks for your valuable input! : - )
> If an attacker had only one block of unknown plaintext, that would likely
be
> the case. It would appear to be difficult to retrieve either the key or
the
> plaintext, and it would obviously be totally impossible for an XOR
> operation. However, if the attacker has multiple blocks encrypted under
the
> same key, that changes radically. If you look at my suggested attack, you
> use one block to guess key bits, and another block (or more likely,
several
> blocks) to verify the guess.
>
> As for what this cipher's weakness, it would appear to me caused by
several
> things:
>
> - Lack of diffusion between plaintext bits -- the value of one byte never
> affects the value of another byte. This means (for example) if the
attacker
> leaves that a plaintext "W" at offset 27 encrypts into the byte 0xf3, then
> he knows that, for any other block, a ciphertext byte 0xf3 at offset 27
> implies that the plainte
Cryptography-Digest Digest #563
Cryptography-Digest Digest #563, Volume #13 Fri, 26 Jan 01 20:13:01 EST
Contents:
Re: Dynamic Transposition Revisited (long) (John Savard)
Re: What do you do with broken crypto hardware? (Paul Rubin)
Re: Cryptographic Camouflage (Thomas Wu)
Re: What do you do with broken crypto hardware? (David Schwartz)
Re: Why Microsoft's Product Activation Stinks (Splaat23)
RSA Source code ("Adam Smith")
Re: Mr Szopa's encryption (was Why Microsoft's Product Activation Stinks) (Alan
Mackenzie)
Re: Why Microsoft's Product Activation Stinks (Splaat23)
Re: Why Microsoft's Product Activation Stinks (Splaat23)
Re: RSA Source code (Paul Rubin)
Re: RSA Source code ("Joseph Ashwood")
Re: Dynamic Transposition Revisited (long) (Terry Ritter)
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Dynamic Transposition Revisited (long)
Date: Fri, 26 Jan 2001 23:30:36 GMT
On Fri, 26 Jan 2001 21:48:40 GMT, [EMAIL PROTECTED] (Terry Ritter) wrote,
in part:
>The DES keyspace is 56 bits, a value 2 bits long.
>Let's see: A value 10**21 bits long compared to a value 2 bits long.
>Yeah, I'd say "some" were impossible to reach.
Actually, 56 is a 6-bit-long binary number. And DES doesn't have 56
different keys, it has 2^56 different keys, as noted below.
>The DES keyspace is such a tiny fragment of the potential keyspace
>that there is no assurance at all that it retains the smooth
>theoretical properties of distribution for which we might hope.
quoting me:
>>Well, by shuffling, I can't reach a total overall pairing of bit
>>balanced inputs to bit balanced outputs such that
>>
>> ->
>>
>>and
>>
>>00101011 ->
>
>Why not? What does that mean? Are you criticizing the balancing
>algorithm? Fine, use another.
This has nothing to do with the balancing algorithm.
This is about Dynamic Transposition itself.
All possible N! transpositions of an N-bit block may be effected.
However, 16! is also a tiny fraction of 12870!, just as 2^56 (not 56)
is a tiny fraction of (2^64)!.
If our PRTG - pseudorandom transposition generator - generates the
transposition
9 12 14 16 15 11 10 13 3 5 1 2 7 6 4 8
then if the plaintext was
the ciphertext will be
000
and if the plaintext was
00101011
the ciphertext would be instead
11011000
note that just as we have switched two bits in our plaintext, we have
switched two bits in our ciphertext.
A substitution cannot be reached by means of any transposition that
will at the same time take
to
and take
00101011
to
since we are inverting a different number of bits in the plaintext and
the ciphertext.
Thus, as with DES, some total overall mappings, considering the whole
ensemble of (plaintext, ciphertext) pairs generated at a single point
in the process, are unreachable.
This is not so much a criticism of Dynamic Transposition itself as of
your claim that it is vastly superior to DES with
stream-cipher-generated subkeys.
John Savard
http://home.ecn.ab.ca/~jsavard/crypto.htm
--
From: Paul Rubin <[EMAIL PROTECTED]>
Subject: Re: What do you do with broken crypto hardware?
Date: 26 Jan 2001 15:48:42 -0800
Nicol So <[EMAIL PROTECTED]> writes:
> > Maybe I'm overly paranoid but the encrypted external keys are in disk
> > files on the application host, and I'm going by the assumption that
> > the online application host is completely insecure.
>
> I'm not familiar with your application, but it sounds dangerous if the
> application host is completely insecure.
To clarify: we do all the usual things to make the host secure, but
despite this I assume there's a chance it can be compromised, and
that's what the module is supposed to protect against.
--
From: Thomas Wu <[EMAIL PROTECTED]>
Subject: Re: Cryptographic Camouflage
Date: 26 Jan 2001 15:50:23 -0800
Mok-Kong Shen <[EMAIL PROTECTED]> writes:
> Thomas Wu wrote:
> >
> > Mok-Kong Shen <[EMAIL PROTECTED]> writes:
> >
> > > Darren New wrote:
> > > >
> > > > I.e., it looks like it's protecting against offline searches of passwords
> > > > you can only truely verify online.
> > > >
> > > > Of course, that's just my interpretation. Read the actual patent for what
> > > > they're actually covering.
> > >
> > > Thank you very much. For, trusting that you are right, I don't
> > > think I would spend time to study the detailed document.
> > >
> > > So it seems that it is virtually the 'employment' of a checksum
> > > that gets patented. When I was in school, solving some systems
> >
> > Huh? It's just the opposite. Having a checksum (MAC, etc.) that
> > validates a password guess is exactly what camouflage avoids.
> > By removing this checksum, and doing some other cleverness, you
> > get a blob of data that leaks no info
Cryptography-Digest Digest #562
Cryptography-Digest Digest #562, Volume #13 Fri, 26 Jan 01 19:13:01 EST
Contents:
Re: Producing "bit-balanced" strings efficiently for Dynamic ("Tony T. Warnock")
Re: Dynamic Transposition Revisited (long) (Terry Ritter)
Re: Dynamic Transposition Revisited (long) (Terry Ritter)
Re: Dynamic Transposition Revisited (long) (Mok-Kong Shen)
Encoded serial number:Help! (Giannikol)
Q: solving simultaneous equations in modulo arithmetic (G. Ralph Kuntz, MD)
Re: Some Enigma Questions (Neil Sluman)
Re: Random stream testing. (long) ("Joseph Ashwood")
Re: Some Enigma Questions (John Savard)
Re: Some Enigma Questions (John Savard)
Re: Producing "bit-balanced" strings efficiently for Dynamic Transposition (Terry
Ritter)
Re: Dynamic Transposition Revisited (long) (Terry Ritter)
Re: Dynamic Transposition Revisited (long) (John Savard)
Re: Why Microsoft's Product Activation Stinks (Lord Running Clam)
Re: Dynamic Transposition Revisited (long) ("Paul Pires")
From: "Tony T. Warnock" <[EMAIL PROTECTED]>
Subject: Re: Producing "bit-balanced" strings efficiently for Dynamic
Date: Fri, 26 Jan 2001 15:19:06 -0700
Reply-To: [EMAIL PROTECTED]
Arbitrary 37 bit strings will fit into 40 bits. 2**37 is just larger
than 40!/20!**2. I didn't check to see if the suggested algorithm would
actually work.
--
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: Dynamic Transposition Revisited (long)
Date: Fri, 26 Jan 2001 22:21:52 GMT
On Fri, 26 Jan 2001 09:07:03 -0800, in
<[EMAIL PROTECTED]>, in sci.crypt "Paul Pires"
<[EMAIL PROTECTED]> wrote:
>[...]
>I also am not clear on the goal. Yes there needs to be bit balancing so that
>a bias in the input is not recognizable in the output but by doing this
>hiding,
>don't you sacrafice another valuable property? Seems like the output would
>fail a taylored randomness test. You are going to get data that has a
>prefect
>distribution of zero's and ones within a block and something else if the
>block
>reference is displaced. Right?
It is not necessary for strength or security that a cipher to produce
random-like output. Most ciphers do so, but such is not necessary.
Here I think the possible output codes do appear with equal
probability.
This is a characteristic which represents the inefficiency of balanced
coding. But since that is a plaintext coding, and is known by both
designer and opponent, it does not seem particularly worrisome.
>Seems like what you'd want would be a method where the transposition
>works on a pile that is "Probably" balanced but where the deviation from
>perfect is not correlated to the input or output. I could be screwy here.
I have mentioned the possibility of a statistical or "almost" balance,
which could be very effective. But it seems like that analysis would
be much more complicated. We would have to talk about the
distribution of balance, and how strength changes accordingly, which
seems beyond what can now be done.
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
--
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: Dynamic Transposition Revisited (long)
Date: Fri, 26 Jan 2001 22:25:04 GMT
On Fri, 26 Jan 2001 12:07:40 -0700, in
<[EMAIL PROTECTED]>, in sci.crypt "Tony T. Warnock"
<[EMAIL PROTECTED]> wrote:
>I have a suggestion for the initial statistical-balance step (to reduce
>the later balance extensions.) XOR the input with a DeBruijn sequence.
>For example a simple method would be to XOR the sequence 0101010101
>Better would be 001100110011 and even better 0001011100010111 In
>the latter case, the XORing sequence is one byte long so one might
>improve things by rotating this sequence between bytes. Longer
>sequences are possible 10011010 could be used on pairs of
>bytes--with rotation.
If we are going to process plaintext with a known sequence, why should
any particular balanced sequence be better than any other? It seems
like there will always be some plaintext that will not be helped, or
would in fact be made worse.
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
--
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Dynamic Transposition Revisited (long)
Date: Fri, 26 Jan 2001 23:26:55 +0100
Terry Ritter wrote:
>
> Mok-Kong Shen<[EMAIL PROTECTED]> wrote:
> >After some re-thinking, I do like to elaborate a little
> >a previous point of mine concerning the question of
> >perfectness of DT.
> >
> >Suppose we have block size of n and we agree not to use
> >the non-balanced groups of bits but only the balanced
> >ones to transmit informations (in other words, we have
> >an 'alphabet' of a certain size m that is less than n). This
> >serves to separate out the
Cryptography-Digest Digest #561
Cryptography-Digest Digest #561, Volume #13 Fri, 26 Jan 01 17:13:01 EST
Contents:
Re: Dynamic Transposition Revisited (long) (AllanW)
Re: Dynamic Transposition Revisited (long) ("Tony T. Warnock")
Re: Dynamic Transposition Revisited (long) (Terry Ritter)
Re: Dynamic Transposition Revisited (long) (Terry Ritter)
Re: Some Enigma Questions (JimD)
Re: Echelon in Asia. (JimD)
Re: Dynamic Transposition Revisited (long) (John Savard)
Re: Fitting Dynamic Transposition into a Binary World (Terry Ritter)
From: AllanW <[EMAIL PROTECTED]>
Subject: Re: Dynamic Transposition Revisited (long)
Date: Fri, 26 Jan 2001 20:49:45 GMT
> AllanW <[EMAIL PROTECTED]> wrote:
> >As I understood the filler bits to work, the data would
> >look like this before the transposition begins: if the
> >data had more 0-bits than 1-bits, it would take the form
> >XXXX 00..00 11..11
> >where X bits represent the data, and then there are 1-8
> >0-bits followed by 1 or more 1-bits.
I see now that I should have said, 1-7 0-bits and then
1 or more 1-bits.
> >If the data has
> >more 1-bits than 0-bits, simply reverse the filler:
> >XXXX 11..11 00..00
> >this time using 1-8 1-bits and then 1 or more 0-bits.
And here I should have said: 1-7 1-bits and then 1 or
more 0-bits.
> >[EMAIL PROTECTED] (Terry Ritter) wrote:
> That does not seem to be the way I did it.
That's what I got out of it. Not word-for-word, of course.
> I don't understand having both 0's and 1's balancing bytes.
Surely you do...? It is so that we can always remove the balancing
bytes without removing any meaningful data.
What if the block has 16 more 0-bits than 1-bits, but the last byte
of plaintext is 0x0F? You could balance the block by adding 2 more
bytes of 0xFF, but then after decryption we could not identify the
first byte of filler (as you say below: the mixed byte must be
mixed to be a flag).
> If we have an excess of 0's, we want any full balancing bytes to
> be all 1's, with the mixed byte being what it needs to be. Since
> the mixed byte must be mixed to be a flag, it cannot balance a
> full 8 bits, but at most 6 (1000 is an excess of 6 0's).
Yes, exactly. And then following this, we have bytes with all
1-bits.
I suppose that what I wrote above (1-7 0-bits, followed by 1 or more
1-bits) was stronger than absolutely needed. The mixed byte could be
randomly mixed as well, so instead of using 1000- we could just
as easily have used 0001-. Is there any reason to do this
randomly? If not, then my description fits the same pattern but is
easier to describe.
> >Another way to say this is to show what the filler
> >would look like for various imbalances. Here I'll
> >assume that the data has more 0-bits than 1-bits; use
> >the complement if the opposite is true.
> >
> > If there are B more 0-bits than 1-bits, then the
> > filler looks like (in hex):
> >
> > B=0 0F
> > B=2 1F
> > B=4 3F
> > B=6 7F
> > B=8 0FFF
> > B=10. 1FFF
> > B=12. 3FFF
> > B=14. 7FFF
> > B=16. 0F
> > B=18. 1F
> > B=20. 3F
> > B=22. 7F
> > B=24. 0FFF
> >...and so on.
>
> Looks right.
Good, because in every case the first balance byte starts
with 1-4 0-bits followed by 1-7 1-bits.
--
[EMAIL PROTECTED] is a "Spam Magnet," never read.
Please reply in newsgroups only, sorry.
Sent via Deja.com
http://www.deja.com/
--
From: "Tony T. Warnock" <[EMAIL PROTECTED]>
Subject: Re: Dynamic Transposition Revisited (long)
Date: Fri, 26 Jan 2001 14:08:19 -0700
Reply-To: [EMAIL PROTECTED]
The efficiency of the balanced pre-substitutions can be improved by
taking more bits. Of course a table-lookup gets too big rather quickly.
Output Input
Size Length Expansion
6 450.0%
8 6 33.3%
10 7 42.9%
12 9 33.3%
14 11 27.3%
16 13 23.1%
18 15 20.0%
20 17 17.6%
22 19 15.8%
24 21 14.3%
26 23 13.0%
28 25 12.0%
30 27 11.1%
32 29 10.3%
64 60 6.7%
128 124 3.2%
256 251 2.0%
512
Cryptography-Digest Digest #560
Cryptography-Digest Digest #560, Volume #13 Fri, 26 Jan 01 16:13:01 EST
Contents:
Re: Dynamic Transposition Revisited (long) (AllanW)
Re: What do you do with broken crypto hardware? (David Schwartz)
Re: What do you do with broken crypto hardware? (David Schwartz)
Re: Dynamic Transposition Revisited (long) (AllanW)
Re: Paranoia (William Hugh Murray)
Re: Encryption Program (Richard Heathfield)
Re: Q: File Extension .$#! - Which Encryption Program?!? (Jim Gillogly)
Re: History Question: signatures in nuclear test ban verification? (Doug Stell)
Re: Dynamic Transposition Revisited (long) (Richard Heathfield)
Re: Encryption Program ("Joseph Ashwood")
Re: Steak Stream Cipher ([EMAIL PROTECTED])
Re: Dynamic Transposition Revisited (long) (John Savard)
Re: Dynamic Transposition Revisited (long) (John Savard)
Re: Dynamic Transposition Revisited (long) (John Savard)
Re: Dynamic Transposition Revisited (long) (John Savard)
Re: Random stream testing. (long) ("Paul Pires")
Re: Q: File Extension .$#! - Which Encryption Program?!? (Thomas Propst)
From: AllanW <[EMAIL PROTECTED]>
Subject: Re: Dynamic Transposition Revisited (long)
Date: Fri, 26 Jan 2001 20:04:24 GMT
"Matt Timmermans" <[EMAIL PROTECTED]> wrote:
> In all likelyhood, that would be a very practical generator for OTP
keys,
> and it would be reasonably easy to purposely underestimate the amount
of
> entropy you're getting. If you want proof, though, you should do
something
> different. For instance:
>
> Generate a photon, and polarize it vertically. Then measure its
> polarization at 45 degrees from the vertical. Repeat.
>
> By measuring the transparency of your optics, the sensitivity of your
> photomultipliers, and the orientation of your polarizers, you can
place a
> very confident lower bound on the rate of real randomness.
I think I missed one of my classes when I learned programming.
Could you please show me the code corresponding to "generate a
photon?" Use any well-known computer language -- ADA, APL,
BASIC, C, C++, COBOL, FORTRAN, PASCAL -- whatever you feel
comfortable with. I just need to see the basic algorithm for
"generate a photon."
Wait, I think I see a photon now -- no, it's gone. I probably
just imagined it.
--
[EMAIL PROTECTED] is a "Spam Magnet," never read.
Please reply in newsgroups only, sorry.
Sent via Deja.com
http://www.deja.com/
--
From: David Schwartz <[EMAIL PROTECTED]>
Subject: Re: What do you do with broken crypto hardware?
Date: Fri, 26 Jan 2001 12:19:48 -0800
Nicol So wrote:
> I'm not familiar with your application, but it sounds dangerous if the
> application host is completely insecure. Besides preventing someone from
> extracting secrets from the security module, don't you want to control
> how the module's functions are exercised, and who can exercise it? I
> suspect that you need to provide some level of security to the host
> anyway.
I think you're missing the entire point of having a secure module. The
point of the module is to isolate failures. That is, with a secure
module, the worst case scenario for a compromised host is supposed to be
that they can perform encryptions and decryptions for as long as the
host is compromised. If the keys themselves are accessible through a
compromised host, then a compromised host equals a compromised key. That
defeats the purpose of having the module.
> Let's assume that the encrypted keys are fairly well protected so that
> there's a low but non-zero probability that an adversary can get to it,
> but without physical access it is impossible to extract the secrets from
> the security module. For adversaries coming in from a network, their
> lives are not made easier. For insiders such as bad admins, their
> attacks are not made harder, but not easier either. For the module
> manufacturer as an adversary, who's best positioned to defeat/bypass the
> module's physical security, they now have an additional barrier to
> overcome. That may be an improvement.
That's a big step down in security from what the module is supposed to
provide.
DS
--
From: David Schwartz <[EMAIL PROTECTED]>
Subject: Re: What do you do with broken crypto hardware?
Date: Fri, 26 Jan 2001 12:17:11 -0800
Paul Rubin wrote:
> This doesn't make sense--the whole point of the tamper resistant
> module is to securely store keys internally. Any keys stored outside
> the module are vulnerable to copying and therefore must be encrypted;
> but then in order to load them into the module, the decryption key
> must be stored inside the module. So if the module is sent back to
> the manufacturer, all the keys are potentially compromised.
Yes, you can't have it both ways. If the module can decrypt the keys,
then you're not safe from anyone who has both the module and the
encrypted keys. If you are assum
Cryptography-Digest Digest #559
Cryptography-Digest Digest #559, Volume #13 Fri, 26 Jan 01 15:13:01 EST
Contents:
Re: Dynamic Transposition Revisited (long) (AllanW)
Re: Snake Oil (SCOTT19U.ZIP_GUY)
Re: Knots, knots, and more knots (Matthew Montchalin)
Re: Decode Algorythim ("Joseph Ashwood")
Re: Steak Stream Cipher ("Joseph Ashwood")
Re: Mr Szopa's encryption (was Why Microsoft's Product Activation Stinks) ("Joseph
Ashwood")
Re: Why Microsoft's Product Activation Stinks (Anthony Stephen Szopa)
Encryption Program (Benjamin)
Re: What do you do with broken crypto hardware? (Bill Unruh)
Q: File Extension .$#! - Which Encryption Program?!? (Thomas Propst)
From: AllanW <[EMAIL PROTECTED]>
Subject: Re: Dynamic Transposition Revisited (long)
Date: Fri, 26 Jan 2001 19:33:06 GMT
[EMAIL PROTECTED] (Terry Ritter) wrote:
>
> On Tue, 23 Jan 2001 08:29:16 -0800, in
> <[EMAIL PROTECTED]>, in sci.crypt "John A. Malley"
> <[EMAIL PROTECTED]> wrote:
>
> >Terry Ritter wrote:
> >>
> >[snip]
> >
> >> >This may be a good place to continue the cryptanalysis of the
strength
> >> >of the DT cipher. A PRNG with N! states to make every
permutation of
> >> >the bits in an N bit block can only generate some of the possible
> >> >sequences of permutations. There are (N!)! possible sequences of
> >> >permutations.
> >>
> >> There are (N!)**S possible sequences of permutations, of sequence
> >> length S.
> >
> >Please help - where did I go wrong in calculating the total number of
> >possible sequences of the N! total possible permutations?
> >
> >Here's my reasoning -
> >
> >Given N bits there are N! different, unique ways to permute those
bits -
> >the N! unique permutations. They make a set P.
> >
> >I number the permutations in the set from 1 to N!. How many
different
> >ways can I sequence the members of the set of permutations? Or in
other
> >words, how many different ways can I write down (list) the elements
of
> >P? Let the number of elements in P be M, so
> >M = N!. The number of unique listing sequences of the M elements is
the
> >number of permutations of the M elements of P, which is M!. Since M =
> >N!, then M = (N!)!.
> >
> >So that's how I derived the number of ways the individual elements of
> >the set of permutations of an N bit block can be listed out as a
> >sequence.
>
> OK, I had no idea what you were doing. Of course, I still have no
> idea where you are going. Do you have any idea how big (N!)! is?
> Even 128! is 3.85620482e+215, and the factorial of that is some number
> which is about 2.75610295e+218 bits long. (From
>
>http://www.io.com/~ritter/JAVASCRP/PERMCOMB.HTM#Factorials
>
> ).
>
> Surely, there is no reason to imagine that permutations must all occur
> before repeating. In fact, that would be a weakness.
>
> The design goal is to allow the very same permutation to occur on the
> next block, and then rely on the almost infinitesimal probability of
> any particular permutation occurring to be assured that it will almost
> never happen. The goal is to make the permutation selection for each
> and every block independent, with equal probabilities.
>
> We can see the selected permutation as a "value," in a sequence of
> values, exactly the same way we get random values from an RNG, or the
> way we think of sequences as some number of symbols, each one chosen
> from a set. It is a weakness for a random generator to produce a
> value which will not then re-occur until the generator recycles.
>
> >> >AFAIK it's safe to say the PRNG generates N! sequences
> >> >(assuming the set of seed values is equal to the set of possible
outputs
> >> >of the PRNG, both sets are of order N!.) Only N!/ (N!)! of the
sequences
> >> >can ever be seen.
> >>
> >> ??
> >
> >There are M! ways to list the M values from 1 - M.
>
> These are called permutations.
>
> >A PRNG outputs lists
> >(sequences) of the values between 1-M.
>
> Some RNG's are like that. Don't do that.
>
> >The PRNG starts from a seed
> >value s and makes a list of the M values. Each list is different.
The
> >PRNG can only make as many unique lists of the M values are there are
> >unique seeds s. Let the order of the set S of seed values be K.
Then
> >the PRNG can only make K out of M! listings (sequences) of the M
values
> >from 1 - M. So the PRNG only produces a fraction K / M! of the total
> >possible sequences of the M values.
>
> Internally, there is some concept of a huge cycle which is shuffled by
> an RNG -- the internal state -- but that concept is not necessarily
> the output value. Surely, when we have a huge internal state, we do
> not imagine that we must take the whole amount of that state as the
> RNG result. When we do not, any particular value can re-occur on the
> very next RNG step.
>
> The Additive RNG is discussed in Knuth II. And even though those are
> tiny, it should be clear that, in an Additive RNG, values can and do
> repeat. The intent is to
Cryptography-Digest Digest #557
Cryptography-Digest Digest #557, Volume #13 Fri, 26 Jan 01 15:13:01 EST
Contents:
Re: Why Microsoft's Product Activation Stinks ("David C. Barber")
Between Silk and Cyanide ("Roger Peniston-Bird")
Re: Why Microsoft's Product Activation Stinks (Lord Running Clam)
Re: Why Microsoft's Product Activation Stinks ("Paul Pires")
Re: Why Microsoft's Product Activation Stinks ("Joe Green")
Re: Decode Algorythim (Mike Rosing)
Re: Dynamic Transposition Revisited (long) ("Tony T. Warnock")
Re: finding inverses and factoring (Bryan Olson)
Re: Paranoia (digiboy | marcus)
Re: How many bits of security can a password give? ("Joseph Ashwood")
Re: RC4 Security ("Joseph Ashwood")
Re: Random stream testing. (long) ("Joseph Ashwood")
Re: TSEPRNG, a secure RNG ? ("Joseph Ashwood")
Re: Cryptographic Camouflage ("Joseph Ashwood")
From: "David C. Barber" <[EMAIL PROTECTED]>
Crossposted-To: or.politics,talk.politics.crypto,misc.survivalism
Subject: Re: Why Microsoft's Product Activation Stinks
Date: Fri, 26 Jan 2001 10:42:15 -0700
"Richard Heathfield" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Yes, indeed. I think it sums up one of the points nicely. If Microsoft
> want copy protection to actually work, they need to do it in hardware.
> That way, the cost of making a copy is likely to exceed the cost of
> buying one in the shops. Of course, I'm not convinced that anyone's
> going to buy any Microsoft hardware more complicated than a mouse, but
> that's for each user (or IT dept) to decide, of course.
Now there's a thought. Include unlock information in a MS mouse making it a
combination mouse/dongle. The cost of the extra mouse h/w would likely be
more than recovered by increased revenues due to the reduction in piracy.
This is MY idea, published here. You must PAY ME to use it, and quote it as
Prior Art in any patent application. :^)
*David Barber*
--
From: "Roger Peniston-Bird" <[EMAIL PROTECTED]>
Subject: Between Silk and Cyanide
Date: Fri, 26 Jan 2001 17:47:38 GMT
I happened to be rereading Leo Marks' book when I heard the sad news of his
death.
It's a fascinating book, sad, funny, moving, exasperating, deep, flippant...
and frustrating that it raises a lot of questions that it does not answer,
For instance, what happened to Giskes, who captured so many agents sent to
the Netherlands? Did he survive the war? What was the system whereby
Pandarus could pass on security checks to other agents without being able to
remember them himself?
It also appears from Silk and Cyanide that 'indecipherables' were tackled by
SOE's FANYs with no more sophisticated equipment than squared paper, whilst
Bletchley was using 'bombes', punched tape, etc. True or false? And did
anyone think of trying to use ULTRA material to check whether the Dutch
network was compromised? What did Marks know of ULTRA?
However, what frustrated me most was chapter 5, in which Marks shows how to
crack messages in the poem code 'with a depth of two'.
For a start, the initial crib uses a (deliberate) misprint... a misspelling
of the name 'Ozanne'. ( In practice this would be like trying to crack a
cypher by using "De Gaullle" as a crib instead of "De Gaulle"). And then,
comparing the coded messages (p. 46 in the paperback) with the original ones
(p54) one discovers there is an F in the original first message and none in
the scrambled version, i.e. pair No.42 on page 54 is not to be found on
p.46. And conversely pair No.53 on p.46 does not occur on P 54.
When he has cracked the cyphers, Marks breaks the news to Ozanne that if one
can determine the process that results in the original letters changing
their positions between the original message and its encipherment, one would
be in possession of the transposition key by which both messages had been
encoded and hence be able to decrypt any other message based on the same
key, "The mathematics involved would be basic but fiddling, and I asked
Ozanne if he would like to see the process for himself or accept my word
that within a very short time we could mathematically construct the entire
transposition key... My word was instantly accepted."
So, alas, we are not enlightened as to how the transposition key was
reconstructed, but are simply told it starts 1,16,17, 23 etc.
In chapter 3 (p32-3) Marks tells us all messages were encoded on a pair of
transposition keys. Once he had encoded his message using the first one, the
agent had to reencode it using a second transposition key based on another
five words from his poem."The agent used his transposition keys to put his
clear text through a series of complex convolutions.." but that if the
Germans had broken one of his messages they could mathematically
reconstruct the words of the poem the agent used as the basis for his
initial transposition."
At this point I am left wondering how, g
Cryptography-Digest Digest #558
Cryptography-Digest Digest #558, Volume #13 Fri, 26 Jan 01 15:13:01 EST Contents: Re: Windows encryption: API and file system (Ray Dillinger) Re: Dynamic Transposition Revisited (long) (Mok-Kong Shen) Re: Dynamic Transposition Revisited (long) (AllanW) Re: Why Microsoft's Product Activation Stinks (Anthony Stephen Szopa) Re: Dynamic Transposition Revisited (long) (AllanW) Re: Why Microsoft's Product Activation Stinks (Anthony Stephen Szopa) Re: Dynamic Transposition Revisited (long) (Mok-Kong Shen) From: Ray Dillinger <[EMAIL PROTECTED]> Subject: Re: Windows encryption: API and file system Date: Fri, 26 Jan 2001 19:13:22 GMT It's not merely sloppy engineering... Think about it. It would have been just as easy to create the temporary file as an encrypted file in the first place, then copy it back over the file being encrypted, and *then* delete it. To call this "sloppy" is to believe that the engineer selected these operations and then didn't think *at all* about what order to apply them in. Which, I guess, you may believe if you care to, but I don't think anyone that flatout stupid can be an engineer in the first place. I don't think Microsoft is in the security business at all. I think that they are in the business of providing the *illusion* of security while still selling out ^H^H^H^H^H^H^H^H uh, "providing for the legitimate needs of law enforcement and data theives". Real security scares the bejabbers out of them and they're fighting it every step of the way. Bear Ben Newman <[EMAIL PROTECTED]> wrote: : This is an excellent start. I was hoping for a more detailed discussion of : how an OS can secure files, and how Windows has implemented their encryption : protocol. : This bug is just plain sloppy engineering! : --ben : "Bryan Mongeau" <[EMAIL PROTECTED]> wrote in message : news:VUYb6.6219$[EMAIL PROTECTED]... :> Ben Newman wrote: :> :> > I'd like to learn more about criticisms of the Windows cryptography :> > implementation. In response to an earlier post, someone characterized it :> > as "practically useless." This seems like a particularly important issue :> > given the amount of knowledge your average Windows user has about : crypto. :> > :> > --ben :> > :> > :> :> I don't know if this what you mean but I saw this on Bugtraq :> a few days ago: :> :> -- :> BugTraq: EFS Win 2000 flaw :> From: Rickard Berglind <[EMAIL PROTECTED]> :> To: [EMAIL PROTECTED] :> Date: Fri, 19 Jan 2001 12:29:50 +0100 :> :> :> I have found a major problem with the encrypted filesystem :> ( EFS ) in Windows 2000 which shows that encrypted files :> are still very available for a thief or attacker. :> :> :> The problem comes from how EFS works when the encryption :> is done. When a user marks a file for encryption a :> backup-file, called efs0.tmp, will be created. When :> the copy is in place the orginal file will be deleted :> and then recreated, now encrypted, from the efs0.tmp- :> file. :> And finally, when the new encrypted file is succesfully :> created, the temporary-file ( which will never be shown :> in the user interface ) will be deleted as well. :> :> So far, so good. The only file remaining is the one :> which is encrypted. :> :> :> But the flaw is this: the temporary-file is deleted :> in the same way any other file is "deleted" - i.e. :> the entry in the $mft is marked as empty and the clusters :> where the file was stored will be marked in the $Bitmap :> as available, but the psysical file and the information it :> contains will NOT be deleted. The information in the :> file which the user have encrypted will be left in the backup :> file efs0.tmp in total plaintext on the surface of the disk. :> :> When new files are added to the partition will they :> gradually overwrite the secret information, but if :> the encrypted file was large - the information could :> be left for months. :> :> So how can this be exploited ? If someone steals :> a laptop or have psysical access to the disk it will :> be easy to use any low level disk editor to search :> for the information. For example, the Microsoft :> Support Tool "dskprobe.exe" works fine for locating :> old efs0.tmp-files and read information, in plain-text, :> that the user thought was safe. :> :> In my opinion there should be a function in the EFS :> which physically overwrites the efs0.tmp at least once :> to make it a lot harder for an attacker to gain control :> over secret information. :> :> :> :> Here is a description how to test this : :> :> Use any version of Windows 2000. :> Install the Support Tools from the Win2000 CD. :> :> For demonstrating purposes - create a new partition with :> the size of 7 MB. :> Choose to format with NTFS. :> Create a new small file ( easier to find ) with Notepad :> and put some text in it. Save this file in the root of the :>
Cryptography-Digest Digest #556
Cryptography-Digest Digest #556, Volume #13 Fri, 26 Jan 01 12:13:01 EST
Contents:
Re: Windows encryption: API and file system ("Ben Newman")
Re: Some Enigma Questions (Jim Reeds)
Weak DES keys/Weak Plaintexts ([EMAIL PROTECTED])
Re: Why Microsoft's Product Activation Stinks (Lord Running Clam)
Re: Barrett modular reduction ([EMAIL PROTECTED])
Re: Producing "bit-balanced" strings efficiently for Dynamic Transposition (John
Savard)
History Question: signatures in nuclear test ban verification? (Gerard Tel)
Re: Fitting Dynamic Transposition into a Binary World (John Savard)
Re: Dynamic Transposition Revisited (long) (John Savard)
Re: Paranoia (JCA)
Re: Why Microsoft's Product Activation Stinks (Richard Heathfield)
ICCIT2001 (CFP) ([EMAIL PROTECTED])
Re: What do you do with broken crypto hardware? (John Savard)
Re: What do you do with broken crypto hardware? (John Savard)
Re: Dynamic Transposition Revisited (long) ("Paul Pires")
From: "Ben Newman" <[EMAIL PROTECTED]>
Subject: Re: Windows encryption: API and file system
Date: Fri, 26 Jan 2001 14:41:34 GMT
Good point. I do think that they should at least zero out the sectors on
disk that contain the temporary file.
> Isn't it more a question of what kinds of attacks this encryption is
> supposed to defend against? Surely if the user's login record / password /
> whatever is used to encrypt the files, and no passphrase is needed for
> accessing an encrypted file, stealing the disk will give you all the
> information you need to decrypt the encrypted files anyway, yes?
>
> What kinds of attacks does Microsoft think this defends against? Theft of
> backup materials, maybe? Reading of files by administrators?
>
--
From: [EMAIL PROTECTED] (Jim Reeds)
Subject: Re: Some Enigma Questions
Date: Fri, 26 Jan 2001 14:52:52 GMT
In article <[EMAIL PROTECTED]>, "Yeah" <[EMAIL PROTECTED]> writes:
|> Didn't the British Government invent the worlds first programmable computer
|> to crak the enigma code. (Suck that America, IBM more precisely)
|> I think i once heard the lead designer on TV commenting that it too about 5
|> minutes to crack the code on their computer and that he once got the paper
|> reel spinning at 3 times the RPM of usual before it broke.
No.
You are thinking of the "Colossus", an electronic special
purpose calculator designed by Tommy Flowers of the British
Post Office labs to break a different German cipher. Colossus
used vacuum tubes and high speed (5,000 characters per
second) punched tape, but it was not programmable in the modern
sense of the word. (One had to set switches and plug plugboards
to change the parameters of a run.) It was definitely the
most technologically advanced instance of use of digital logic,
large-scale use of vacuum tubes, etc, at its time, but was (I
think) matched in conception by several contemporary computing
projects in America and Germany.
I suspect, but have no evidence, that the special purpose
number theoretical calculators built by D. H. Lehmer in the
1930s in California were a kind of mental jumping off point
for the Colossus team. The team that used Colossus, and
which commissioned Flowers to design and build it,
was full of pure mathematicians, who would have known of
Lehmer's machines.
--
Jim Reeds, AT&T Labs - Research
Shannon Laboratory, Room C229, Building 103
180 Park Avenue, Florham Park, NJ 07932-0971, USA
[EMAIL PROTECTED], phone: +1 973 360 8414, fax: +1 973 360 8178
--
From: [EMAIL PROTECTED]
Subject: Weak DES keys/Weak Plaintexts
Date: Fri, 26 Jan 2001 10:01:12 -0500
I know that DES has some weak keys that make plaintext recovery easy.
Q. Are there weak DES plaintext that make key recovery easier?
Example: I control the plaintext, someone else does a single
des_ecb_encrypt(), and I receive the cyphertext. Is there a
particularly weak plaintext I could select to be encrypted to make the
unknown key be recovered eaiser?
Thanks for the help.
Please Reply or CC' me if possible, since I have limited newsgroup
access.
- Aaron
==
Disclaimer:
The views and opinions are soley mine and not my companies.
--
Date: Fri, 26 Jan 2001 09:25:33 -0600
From: Lord Running Clam
Subject: Re: Why Microsoft's Product Activation Stinks
Crossposted-To: or.politics,talk.politics.crypto,misc.survivalism
=BEGIN PGP SIGNED MESSAGE=
On Fri, 26 Jan 2001, Richard Heathfield <[EMAIL PROTECTED]> wrote:
>Anthony Stephen Szopa wrote:
>>
>> Pointless program where to stop software piracy could increase
>> revenues by tens of billions of dollars each year? Pointless?
>
>Pretty much, yes. It's like trying to protect Pythagoras' Theorem.
>Counter-productive.
Excuse me, but is this little piece from alt.security.pgp relevant to your
flamewar?
http://www.deja.com/[ST_rn=ps]/getdoc.xp?AN=720256016&fmt
Cryptography-Digest Digest #555
Cryptography-Digest Digest #555, Volume #13 Fri, 26 Jan 01 09:13:01 EST Contents: Re: William's P+1 (Bob Silverman) Re: Dynamic Transposition Revisited (long) (Mok-Kong Shen) Re: William's P+1 ([EMAIL PROTECTED]) Re: What do you do with broken crypto hardware? (John Veldhuis) Re: Dynamic Transposition Revisited (long) (Mok-Kong Shen) Re: What do you do with broken crypto hardware? (Paul Rubin) Re: Paranoia ([EMAIL PROTECTED]) Re: Cryptographic Camouflage (Mok-Kong Shen) Re: Dynamic Transposition Revisited (long) (Rob Warnock) Re: Fitting Dynamic Transposition into a Binary World (Rob Warnock) Re: What do you do with broken crypto hardware? (John Veldhuis) Re: Why Microsoft's Product Activation Stinks (Richard Heathfield) Re: Producing "bit-balanced" strings efficiently for Dynamic Transposition (Rob Warnock) From: Bob Silverman <[EMAIL PROTECTED]> Subject: Re: William's P+1 Date: Fri, 26 Jan 2001 12:39:25 GMT In article <94n6eq$lhj$[EMAIL PROTECTED]>, "The Death" <[EMAIL PROTECTED]> wrote: > I saw several websites, and they all mentioned this algorithm but didn't > have any info about it. Can any1 give me information about this algorithm? It finds a factor p dividing n if p+1 only has small prime factors. It only works 1/2 the time even when p has the required property. (you choose a Lucas sequence. It succeeeds iff the discriminant is a non-residue mod p) It is obsolete. What more would you like? -- Bob Silverman "You can lead a horse's ass to knowledge, but you can't make him think" Sent via Deja.com http://www.deja.com/ -- From: Mok-Kong Shen <[EMAIL PROTECTED]> Subject: Re: Dynamic Transposition Revisited (long) Date: Fri, 26 Jan 2001 13:56:11 +0100 Mok-Kong Shen wrote: > > Terry Ritter wrote: > > [snip] > My knowledge is too meager to enable me to offer more > points than I have already done. However, it is my > impression that your arguments todate somehow (I have > no definite idea of that) need strenthening, if DT is > to be accepted as on a par with the theoretical OTP > (which seems to be your goal), in particular by the > academics, assuming DT has in fact that property. > (Apology, if my open words are inappropriate in some > way.) After some re-thinking, I do like to elaborate a little a previous point of mine concerning the question of perfectness of DT. Suppose we have block size of n and we agree not to use the non-balanced groups of bits but only the balanced ones to transmit informations (in other words, we have an 'alphabet' of a certain size m that is less than n). This serves to separate out the issue of bit balancing in order to simpify the argumentation below. Now what we have is the following: Given an information block, we do permutations of its bits to produce an enciphered block with the help of a PRNG. A PRNG never provides a perfect bit sequence in the sense used in the context of the theoretical OTP. How can it be that this imperfectness does not manifest itself in some form (possibly in certain very much reduced, practically entirely negligible, intensity) AT ALL in our encryption result? Let's order all the distinct balanced bit groups into a sequence S and feed repetitions of S into our algorithm. This input is evidently perfectly predictable. Can the output be perfectly unpredictable? It certainly cannot. For the PRNG has a finite period and hence the ciphertext must cycle ultimately. This shows that, while DT could be practically very secure (an issue that certainly merits careful study before its being used in practice), it cannot offer perfect security that pertains to the theoretical OTP. M. K. Shen === http://home.t-online.de/home/mok-kong.shen -- From: [EMAIL PROTECTED] Subject: Re: William's P+1 Date: Fri, 26 Jan 2001 12:45:54 GMT In article <94n6eq$lhj$[EMAIL PROTECTED]>, "The Death" <[EMAIL PROTECTED]> wrote: > I saw several websites, and they all mentioned this algorithm but didn't > have any info about it. Can any1 give me information about this algorithm? > > There's a description in "A Survey of Modern Integer Factorization Algorithms" CWI Quarterly, v.7 (4), 1994, pp. 337 - 365, by Peter Montgomery which is available here: http://ftp.cwi.nl/ftp/CWIQuarterly/1994/7.4/Montgomery.ps.Z Chris Sent via Deja.com http://www.deja.com/ -- From: John Veldhuis <[EMAIL PROTECTED]> Subject: Re: What do you do with broken crypto hardware? Date: Fri, 26 Jan 2001 13:01:33 GMT Paul Rubin wrote: > = > I'm wondering if anyone else here is using crypto hardware modules for > key management. What do you do if one malfunctions? Throw it into a > blast furnace? Send it back to the manufacturer for warranty > repair/replacement, with your secret keys inside? I just send it back to the manufacturer. The moment it
Cryptography-Digest Digest #554
Cryptography-Digest Digest #554, Volume #13 Fri, 26 Jan 01 07:13:00 EST
Contents:
Re: Why Microsoft's Product Activation Stinks (Anthony Stephen Szopa)
Re: What do you do with broken crypto hardware? (Paul Rubin)
Re: What do you do with broken crypto hardware? (Nicol So)
Re: Durstenfeld Transpositions & ARC4 (Benjamin Goldberg)
Re: Durstenfeld Transpositions & ARC4 (Mok-Kong Shen)
Decode Algorythim ("Yeah")
Re: Some Enigma Questions ("Yeah")
Re: Steak Stream Cipher ([EMAIL PROTECTED])
Re: Durstenfeld Transpositions & ARC4 (Mok-Kong Shen)
Paranoia (Simon Jenkins)
From: Anthony Stephen Szopa <[EMAIL PROTECTED]>
Crossposted-To: or.politics,talk.politics.crypto,misc.survivalism
Subject: Re: Why Microsoft's Product Activation Stinks
Date: Fri, 26 Jan 2001 00:10:54 -0800
Splaat23 wrote:
>
> He doesn't consider XORing two files together to be significant. That's
> easy! He considers XORing two files together, one of which happens to
> be generated by a PRNG to be significant. Innovation, what a sight! I
> wish I had his foresight to create a slow, unwieldy stream cipher that
> has no market to acquire and no use.
>
> He was not stupid for showing it to Microsoft. He's stupid for
> believing that not a soul could think it up independently! I love his
> lack of understanding of the laws of causation: "I sent my [simple,
> bad] program [that could be thought up by any 9-year old reading _AC_]
> to Microsoft, and years later they come out with something remotely
> similiar, therefore they are liars and thieves!"
>
> Note, I think Microsoft's patenting of this, if that's what they really
> intend to do, is silly, like most tech patents, but that's OT.
>
> Enough bashing of Mr. Szopa. From his past posting history (which I had
> the urge to view and regret my stupidity), Mr. Szopa will disregard
> anything we say here and continue to believe his own superiority over
> us mere mortals.
>
> - Andrew
>
> In article <[EMAIL PROTECTED]>,
> Richard Heathfield <[EMAIL PROTECTED]> wrote:
> > [Sorry to reply to Joe's post when I'm really addressing the issues
> > raised by Mr Szopa. Mr Szopa's article hasn't hit my newsfeed yet and
> > may not do so for some time...]
> >
> > > "Anthony Stephen Szopa" <[EMAIL PROTECTED]> wrote in message
> > > news:[EMAIL PROTECTED]...
> > > > Richard Heathfield wrote:
> > > > >
> > > > > Anthony Stephen Szopa wrote:
> > > > > >
> > > > >
> > > > > >
> > > > > > So that's all I have to say for a while.
> > > > >
> > > > > Is that a promise?
> > > >
> > > >
> > > > Here is a guy who spits on the souls of anyone for no damned
> reason.
> >
> > I guess it wasn't a promise after all. (sigh)
> >
> > > >
> > > > I told you that I am the inventor that will save people tens or
> > > > hundreds of billions of dollars in lost revenue and you verbally
> > > > shit on me with your sarcasm.
> >
> > You do a good line in invective. Perhaps you should switch from crypto
> > to politics.
> >
> > > > Did you develope an anti-piracy computer software module that will
> > > > prevent perhaps half at a minimum of the illegal copying of
> > > > computer software in the world?
> >
> > Certainly not. I wouldn't dream of writing such a pointless program.
> >
> > > > Do you know how important a contribution this is?
> >
> > It's completely insignificant to those who have already realised that
> MS
> > has, for years, been using the very best copy protection of all - i.e.
> > products that don't work, products that corrupt files, products that
> > hang the machine... Why would anyone with the slightest semblance of
> > common sense *want* to copy programs like that?
> >
> > > > I can prove that I did this. And if I eventually do prove it
> > > > publicly everyone will know you are a fool. But most importantly
> > > > you will know. I think you probably already know you are a fool.
> >
> > If you really were conned by MS, I sympathise (like Joe), but am
> stunned
> > by your naivete.
> >
> > 1) Copy protection doesn't work. sci.crypt already knows this. Why
> don't
> > you?
> > 2) Microsoft is well-known for exploiting anything it can exploit.
> >
> > > > I am certainly one of a very very few and perhaps the only person
> in
> > > > the world who can prove that they did it before MS.
> >
> > You're the guy with the proprietary no-source-code-provided technique
> > for XORing two files together, yes? The one with the front end that
> > looks like something the cat dragged in? The one you said was so
> > innovative?
> >
> > > > I am not going
> > > > to divulge my thought processes here or my plans or my actions
> > > > regarding the implications of this situation at this time, as I
> have
> > > > said.
> >
> > Excellent.
> >
> > > > I am actively pursuing my interests.
> > > >
> > > > I think I read that there is about $50 billion dollars worth of
> > > > computer software piracy going on every year.
> >
