Cryptography-Digest Digest #976, Volume #12 Sun, 22 Oct 00 07:13:00 EDT
Contents:
Re: Enigma: Stolen German Code Machine Turns Up in BBC Mailroom ("Douglas A. Gwyn")
Re: Quasi philosphical question regarding Index of Coincidence ("Douglas A. Gwyn")
Re: Storing an Integer on a stream (Tim Tyler)
Re: Storing an Integer on a stream (Tim Tyler)
Re: Storing an Integer on a stream (Tim Tyler)
Re: How to post absolutely anything on the Internet anonymously (Tim Tyler)
Re: idea for spam free email (Richard Heathfield)
Re: Huffman stream cipher. (Richard Heathfield)
Re: deterministic RSA key generation (Roger)
Re: Visual Basic (Paul Schlyter)
Re: Rijndael in Perl (Dido Sevilla)
Re: Storing an Integer on a stream ([EMAIL PROTECTED])
Re: My comments on AES (Rob Warnock)
----------------------------------------------------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Enigma: Stolen German Code Machine Turns Up in BBC Mailroom
Date: Sun, 22 Oct 2000 05:25:31 GMT
Sundial Services wrote:
> The "theory" that Nikolai Telsa had a secret for unlimited energy,
> and that these secrets were locked-away in a particular
> (secretly-different!) Enigma machine is one of those things that
> "cannot be disproved, just as it cannot [practically] be proved,"
Actually it can be disproved, to the extent that there are not
very many bits available in the settings of the machine
parameters (e.g. rotor wiring). It could be proved in other
ways too, such as in examining Tesla's lab notes (I have a copy).
Tesla was quite interested in the geoelectric properties of the
Earth, especially in allowing power to be broadcast through
standing waves to distant locations, and he performed experiments
along these lines (with some success). But he also became wackier
as he got older and most of his later ideas simply weren't feasible.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Quasi philosphical question regarding Index of Coincidence
Date: Sun, 22 Oct 2000 05:47:33 GMT
[EMAIL PROTECTED] wrote:
> "Douglas A. Gwyn" <[EMAIL PROTECTED]> wrote:
> > Index of Coincidence has nothing to do with case and everything
> > to do with correlation. What you need to do is to determine how
> > the I.C. is going to be *used*; generally it is used to detect a
> > deviation from a purely random (coincidental) behavior in some
> > specific test. When you study the situation it should become
> > obvious what to do.
> Sorry, but I don't follow you here.
> Granted the IC is used to detect deviation from randomness. But it seems
> to me that it may be the case that if the cipher scheme used upper and
> lower case (effectiviely at 52 character alphabet), butit was assumed to
> only be a 26 letter alphabet, the IC might give results that would lead
> one to believe two cipher alphabet were used.....I think.
You're making a start at identifying the *use* of the IC.
Apparently this particular use consists of a monographic IC
to estimate the number of alphabets used in a polyalphabetic
system. I don't see how you could have any doubt as to what
the ciphertext gamut of characters is from simple inspection:
if it doesn't involve more than 26 symbols, then obviously
the PT alphabet was not 52 characters. No need to use any
IC-based approach for this.
------------------------------
Crossposted-To: comp.compression
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Storing an Integer on a stream
Reply-To: [EMAIL PROTECTED]
Date: Sun, 22 Oct 2000 06:00:41 GMT
In sci.crypt Benjamin Goldberg <[EMAIL PROTECTED]> wrote:
: Tim Tyler wrote:
:> : Andras Erdei wrote:
:> :> The method i like most is fibonacci coding:
: [snip]
:> :> IIRC this encoding is asimptotically optimal.
:>
:> "Severly sub-optimal" is how I would describe it, especially in the
:> context of padding schemes.
: Asimptotically optimal means that as the value encoded increases, the
: method gets closer to the minimum number of bits needed to encode that
: number. The length an integer in base 2, not including the bits needed
: t store the length (ie, an EOF, or whatever), is O(log2(N)). For
: numbers approaching infinity, an asimtotically optimal encoding takes
: O(log2(N)) bits [...]
I see. The problem is that this runs in the fact of use of the term
optimal to imply "best". There are other encodings that beat the
fibonaci one at every stage (except the very early ones).
By this sort of definition an "asymtotically optimal" runner might always
come last in the race ;-/
: For pure base 2, we need to first write how many bits are written; To
: do that, we need to encode a number on the bitstream. To write the
: length of the binary number, what method would you suggest?
If it had been previously determined that this method worked better than
the self-terminating ones at the head of the thread, it would probably be
best to use of of those self-terminating methods (or similar) to
encode such a length.
:> Padding with a format that can't use repeated 1s could only ever be
:> anywhere near optimal for small values.
:>
:> Since when larger and larger values are used, methods which can use a
:> greater range of symbols will systematically trounce it, it's hard to
:> see how it could be described as "asymtotically optimal".
: What do you mean "a greater range of symbols?" There are only two
: different symbols at the bit level, 0 and 1. The integer 15 is stored
: as 8 bits, including the terminator.
Symbols which include the "...11..." sequence in their bodies are
excluded. Many systems allow a greater range of symbols in the body of
the representation of the value. One was given at the head of the thread
- use base 255 and use a 255 terminator. That way you get 255 symbols
available in each byte (out of a possible 256).
Of course there's a cost incurred at the end of the value of doing this.
However, the cost is fixed (in this case it's 8 bits). By contrast, the
cost of not allowing any "...11..." symbols is incurred through the
representation of the value - and thus grows with the value.
: As for byte level encodings, what method would you suggest as being
: best?
AFAIK, there is no single best method - which is best depends on the
expected size of the value.
I don't really know what's best when, instead I present some indications.
I believe using a self-terminating representation in base N with a N
terminator/divider is pretty good, though you can probably do better if
the expected distribution of values is non-uniform, or if the expected
range of values is known to be small.
To deal with N not being a power of 2 (and thus with the resultant
file not filling a whole number of bytes) one could use Matt Timmerman's
method of transforming the result to a finitely odd file, and then
applying his bijection between such data and 8-bit granular files.
I don't know what value of N would be best if the expected distribution
of values is uniform between 0 and 2^64-1.
Encoding in pure binary with a specified number of bits (which is encoded
as a self-terminating prefix in some way) may work more efficiently for
huge values (though I have not properly verified this).
It even seems possible that this process of replacing the self-terminating
value with a self-terminating length and a raw binary value could be
applied recursively - if the expected values are stupendously large.
--
__________ http://alife.co.uk/ http://mandala.co.uk/
|im |yler [EMAIL PROTECTED] http://hex.org.uk/ http://atoms.org.uk/
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Storing an Integer on a stream
Reply-To: [EMAIL PROTECTED]
Date: Sun, 22 Oct 2000 06:06:19 GMT
[EMAIL PROTECTED] wrote:
: Now this one seems absurdly obvious to me.
: If, let's say, the max padding you use is 65535 bytes, you only need to
: put the last 16 bits of the data length in the header. If it is, say,
: 65536 bytes, you need to put in the last 17 bits of the data length.
That (though 17 -> 16?) would work best if you padded with 0-65535
bytes, choosing the volume of padding uniformly at random.
The problem is in your premises, though - 65535 bytes of padding isn't
going to do much to disguise the length of multiple megabyte files.
The whole point of this discussion seems to be to accomodate variable
sized values.
--
__________ Lotus Artificial Life http://alife.co.uk/ [EMAIL PROTECTED]
|im |yler The Mandala Centre http://mandala.co.uk/ Free gift.
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Storing an Integer on a stream
Reply-To: [EMAIL PROTECTED]
Date: Sun, 22 Oct 2000 06:11:56 GMT
[EMAIL PROTECTED] wrote:
: Benjamin Goldberg <[EMAIL PROTECTED]> wrote:
:> If I'm writing a file, whose format is a 64 bit file length, followed
:> by some amount of data, followed by some [random] padding, which of the
:> following is the best way to store that length value:
: base 10 in BCD and use any non-decimal digit to end
Surely inferior to using base 15 with a 15 terminator. Calculating in
base 15 cannot be that much harder than calculating in base 10.
I don't see any good reason to introduce potential security problems
because of a lack of fingers ;-)
--
__________ Lotus Artificial Life http://alife.co.uk/ [EMAIL PROTECTED]
|im |yler The Mandala Centre http://mandala.co.uk/ Free gift.
------------------------------
Crossposted-To: talk.politics.crypto,alt.freespeech
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: How to post absolutely anything on the Internet anonymously
Reply-To: [EMAIL PROTECTED]
Date: Sun, 22 Oct 2000 06:23:09 GMT
In several places, Anthony Stephen Szopa <[EMAIL PROTECTED]> wrote:
: [...] this system actually posts the data to numerous internet
: servers where anyone can down load it while at the same time making
: it highly unlikely that anyone, including the government, could
: remove the information from all the servers.
: While also providing to make it impossible for the server owner to
: be held accountable since the server owner has no way of knowing
: what is on their server since this file is encrypted.
They could just make running Publis illegal. There will have to be some
ofther compelling use for - it besides cocking a snook at the government -
to prevent this strategy from being applied.
: I am not sure, but using an anonymous service may not be required
: but it does add another layer through which it will be very
: difficult to trace the poster through. It was suggested that a
: poster could use Publius while posting through a public host. This
: would certainly anonymize the poster.
Anonymity and privacy seem destined to go the way of the Dodo. When the
government's nano-scale spy robots are everywhere, escaping from their
view long enough to do anything in private will be very, very difficult.
--
__________ Lotus Artificial Life http://alife.co.uk/ [EMAIL PROTECTED]
|im |yler The Mandala Centre http://mandala.co.uk/ Surf against sewage.
------------------------------
Date: Sun, 22 Oct 2000 08:03:40 +0100
From: Richard Heathfield <[EMAIL PROTECTED]>
Subject: Re: idea for spam free email
"G. Orme" wrote:
>
> > Graceful Twerp wrote:
> > >
> > <snip>
> > >
> > > In my opinion, filters installed on the receiver's e-mail software are
> > > still the best way to eliminate spam. Your sistem seems to be designed
> > > so that you will receive e-mail only from a list of sources you have
> > > hand-picked. You can obtain the same result by writing a filter that
> > > lets in only e-mail originating from a list of approved addresses.
>
> G. Your idea is very good. The system I am proposing is designed to
> automatically do a similar thing so people using it don't need the hmmm
> folder.
I would not trust a system which automagically deleted emails based on
address or subject wildcards, without giving me the chance to yay or nay
them if I so chose.
--
Richard Heathfield
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
66 K&R Answers: http://users.powernet.co.uk/eton/kandr2/index.html (31
to go)
------------------------------
Date: Sun, 22 Oct 2000 08:15:12 +0100
From: Richard Heathfield <[EMAIL PROTECTED]>
Subject: Re: Huffman stream cipher.
"SCOTT19U.ZIP_GUY" wrote:
>
> [EMAIL PROTECTED] (Benjamin Goldberg) wrote in
> <[EMAIL PROTECTED]>:
>
> >SCOTT19U.ZIP_GUY wrote:
> >[snip]
> >> As for the fact a stream is not a file in one sense of the word
> >> you seemed to use it in other senses like in the case in adding
> >> an integer to a stream. In reading that problem I took it as a file
> >> and you did not object. Also I give you an example for that other
> >> thread. WHere you capaple of following it or what?
> >
> >I have not, and do not plan to, look at your DSC program. If you can
> >explain the algorithm in clear english, I would be happy, but I am not
> >going to look at your shitty source code.
>
> You sound like the kind of Jerk that is never happy so why
> pretend that if I did a little more FREE work for your lazy
> ass that you would be happy. I can see by your comment you
> obviously lacked the ability to even follow the simple example I
> did for you.
>
> ... rest of his nonsense dropped.
I had a quick look at your source code. He's right. It's hard to read,
it's non-portable (I'd guess it's for DJGPP, but that's just a guess)
and in at least one place it's incorrect. I couldn't look at it for long
because it was so tiring.
Why not get that king-sized chip off your shoulder? If you want people
to analyse (or use) your stuff, get it tidied up. And if you don't want
people to analyse (or use) your stuff, don't publish it.
--
Richard Heathfield
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
66 K&R Answers: http://users.powernet.co.uk/eton/kandr2/index.html (31
to go)
------------------------------
From: Roger <[EMAIL PROTECTED]>
Subject: Re: deterministic RSA key generation
Date: Sun, 22 Oct 2000 01:17:16 -0700
Francois Grieu wrote:
> > > One thing strikes me: it would often be usefull to use a
> > > deterministic, standardised method to generate an RSA key from
> > > a seed value, like a passphrase.
> > >
> > > Question: is there an established standard for something like
> > > (p, q) = F(passphrase, bit-size_of_pq, public_e) ?
>
> You may be thinking of Bob Silverman's fast sieving technique [1]
> to generate strong primes, which I think he proposed to ANSI X9.31
> (despite his own viewpoint strong primes are not useful).
> Though a step in this direction, it does not appear to be a fully
> specified passphrase-to-key transformation, for lack of a specified
> pseudo-random bit generator, of a procedure to generate integers
> in a given range from random bits, and a few other missing details.
Ok, I agree with you, that such a standard transformation would
be useful. I have implemented my own, and it is ad hoc. But
you talk to people about this subject, and it degenerates into
weird superstitions about how primes should be generated.
------------------------------
From: [EMAIL PROTECTED] (Paul Schlyter)
Subject: Re: Visual Basic
Date: 22 Oct 2000 10:57:56 +0200
In article <RusI5.7339$[EMAIL PROTECTED]>,
Adam Smith <[EMAIL PROTECTED]> wrote:
> "Sundial Services" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]...
>
>> binary digit wrote:
>>>
>>> Anyone know where I can find some encryption algorithms that have been
>>> coded in Vb and have good documentation on them?
>>
>> Yes, bit, they exist and someone has already posted one.
>>
>> What's more practical is to get (or buy) a cipher package that, ideally,
>> is packaged as an ActiveX (OCX) control. Then simply call its methods
>> appropriately. DLLs (dynamic link libraries) can also be called from VB
>> although it takes a little bit more work.
>>
>> Cipher algorithms usually require so much "bit twiddling" that it is
>> much more efficient for the cipher core to be done in a compiled
>> language. Visual Basic is simpler for the less compute-intensive tasks.
VB is compiled too; however VB as a language is indeed unsuitable
for bit-twiddling.
> I beg to differ...namely for programs that are to be released. I have
> always found that it is much simpler to incorporate someone's source code
> into your .exe that attach a .ocx and have all of the problems that come
> with registering
Is one command which must be issued once really that much trouble?
> and calling it!
Sorry, but even if you incorporate source code in your program you'll
have to call that too! So you cannot get away from the trouble of
having to call that crypto code.
Which route you should pick is of course dependent on what cipher you
want to implement. If a fairly simple cipher is enough, it's probably
feasible to do ot in VB. But if you would want an industrial strength
cipher, it would be MUCH HARDER to implement it efficiently -- or even
implement it at all! -- in VB than to write a few lines to call an
external DLL or OCX. Try for instance to implement the RSA algorithm,
with the necessary bignum arithmetic and all, in VB. It will be
messy but it may be doable -- now try to make it work efficiently....
Of course there's also a third option: include the source code of
these crypto routines in your program, but let that source code be in
another language (e.g. C, since there are tons and tons of C source
code for this). Writing multi-language programs is always an
interesting exercise :-) .... but in this case it will bring you two
advantages: all of your program will be one single .exe file, and you
have a good change of finding crypto code of high quality.
--
================================================================
Paul Schlyter, Swedish Amateur Astronomer's Society (SAAF)
Grev Turegatan 40, S-114 38 Stockholm, SWEDEN
e-mail: pausch at saaf dot se or paul.schlyter at ausys dot se
WWW: http://hotel04.ausys.se/pausch http://welcome.to/pausch
------------------------------
From: Dido Sevilla <[EMAIL PROTECTED]>
Crossposted-To: comp.lang.perl.misc
Subject: Re: Rijndael in Perl
Date: Sun, 22 Oct 2000 17:33:22 +0800
Sam Trenholme wrote:
>
> >http://home.pacific.net.ph/~dido/Crypt-Rijndael-0.01.tar.gz
>
> I noticed that a script called makertbls.pl is referred to in the code,
> but is not part of this archive.
>
> I would like to look at this script, so I can get a better picture of
> Rijndael in my mind. I am slowly but surely "getting" how it works.
>
Unfortunately, I no longer have this script on my hard disk. I have
sent you a similar script by private email which generates the tables
for encryption only. I'll leave the table generation for the decryption
tables to you. Read section 5.2.1 of the Rijndael spec.
--
Rafael R. Sevilla <[EMAIL PROTECTED]> +63 (2) 4342217
ICSM-F Development Team, UP Diliman +63 (917) 4458925
OpenPGP Key ID: 0x0E8CE481
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Storing an Integer on a stream
Date: Sun, 22 Oct 2000 10:18:43 GMT
Okay: You take your data plus padding, and you write down its length in
binary and count the bits. Then you use that many bits in the header to
show the data length. Simple, ne?
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (Rob Warnock)
Subject: Re: My comments on AES
Date: 22 Oct 2000 11:03:02 GMT
Tim Tyler <[EMAIL PROTECTED]> wrote:
+---------------
| Stephen M. Gardner <[EMAIL PROTECTED]> wrote:
| : Now what makes you think that he said it was breakable.
|
| How about the bit where he wrote (from the URL above):
|
| ``I believe that within the next five years someone will discover an
| academic attack against Rijndael.''
+---------------
You just *love* quoting stuff way out of context to twist its meaning,
don't you? Try quoting the whole paragraph (it's a short one), and see
just how serious an "academic attack" is, hmmmm? What he *really* said:
There is a significant difference between an academic break
of a cipher and a break that will allow someone to read
encrypted traffic. (Imagine an attack against Rijndael that
requires 2^100 steps. That is an academic break of the cipher,
even though it is a completely useless result to anyone trying
to read encrypted traffic.) I believe that within the next five
years someone will discover an academic attack against Rijndael.
I do not believe that anyone will ever discover an attack that
will allow someone to read Rijndael traffic. So while I have
serious academic reservations about Rijndael, I do not have
any engineering reservations about Rijndael.
-Rob
=====
Rob Warnock, 31-2-510 [EMAIL PROTECTED]
Network Engineering http://reality.sgi.com/rpw3/
Silicon Graphics, Inc. Phone: 650-933-1673
1600 Amphitheatre Pkwy. PP-ASEL-IA
Mountain View, CA 94043
------------------------------
** 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
******************************
