Cryptography-Digest Digest #914, Volume #12 Fri, 13 Oct 00 22:13:00 EDT
Contents:
Re: FTL Computation ("Douglas A. Gwyn")
Re: Rijndael implementations ("Kasper Pedersen")
Re: Rijndael implementations ("Kasper Pedersen")
Re: random number sequences ("Douglas A. Gwyn")
Re: Is it trivial for NSA to crack these ciphers? ("Douglas A. Gwyn")
Re: A5/1 (David Wagner)
Re: Sending the same messgae twice -- why is this a weakness? ("Douglas A. Gwyn")
Re: A journal about crypto history (Jim Reeds)
Re: Is it trivial for NSA to crack these ciphers? (CiPHER)
Re: Why trust root CAs ? (Paul Rubin)
Re: algo to generate permutations ([EMAIL PROTECTED])
Bestcrypt technical difficulty question (Patrick O'Reilly)
Re: Crypto technology recommendations? ("Will Newland")
Re: Problem with SHA256 implementation (Daniel Leonard)
Re: Rijndael implementations (Roger Schlafly)
Re: Why trust root CAs ? (JD)
Re: Why trust root CAs ? (Larry Kilgallen)
Re: Problem with SHA256 implementation (Tom St Denis)
----------------------------------------------------------------------------
Crossposted-To: sci.astro,sci.physics.relativity,sci.math
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: FTL Computation
Date: Fri, 13 Oct 2000 21:08:26 GMT
ca314159 wrote:
> "Paul Lutus" <[EMAIL PROTECTED]> wrote:
> > and the spot does not move at FTL.
> If _it_ doesn't, then what does _it_ do ?
> Does _it_ exist at all ?
> The spot, is a symbol.
> It, moves FTL.
Nuts! One can focus one's attention on an object here on
Earth, then within a second or so move the focus of his attention
to something on Mars. Has anything actually travelled faster
than light in this thought experiment? If you think so, then
your notion of FTL is utterly useless.
> Here's someone who's exploited FTL shutters to holograph
> the actual motion of light. He's basically done what Einstein
> asked: what's it like to ride on a beam of light ?
> http://www.matpr.kth.se/personal/nilsa/
> If _it_ was an illusion, Nils Abramson would not have been
> able to exploit _it_, now would he ?
Nothing in his apparatus moves faster than light.
The patterns are Moire effect, i.e. standing waves.
> Ideas (correlations) can be communicated
> instantaneously, deterministic (new) information
> must be communicated less than the speed of light.
The concept of "communication" requires that information
be conveyed.
------------------------------
From: "Kasper Pedersen" <[EMAIL PROTECTED]>
Subject: Re: Rijndael implementations
Date: Sat, 14 Oct 2000 00:27:27 -0700
"Roger Schlafly" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> What are you guys programming? When I was in school, they still had
> a CDC 6600 humming in the basement. But it's been a long time since
> I heard of anyone building a machine with a byte being anything
> other than 8 bits.
Microcontrollers and digital signal processors.
The microcontroller manufacturers try every conceivable trick to minimize
cost. The result is something like the very common
first-timer-microcontroller PIC12/16 series:
Being a harvard architecture, the family uses 12-, 13-, 14-, or (I'm not
sure) 15-bit code memory in the different variants. Data memory is 8 bits
wide, and is a 'byte'.
I've programmed 4 bit micros. 12-bit once (where a byte was defined as 12
bits and a nybble 6).
Modern DSPs are less hairy, but I've used some that were 20 wide in code and
16 in data.
/Kasper
------------------------------
From: "Kasper Pedersen" <[EMAIL PROTECTED]>
Subject: Re: Rijndael implementations
Date: Sat, 14 Oct 2000 00:27:27 -0700
"Roger Schlafly" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> What are you guys programming? When I was in school, they still had
> a CDC 6600 humming in the basement. But it's been a long time since
> I heard of anyone building a machine with a byte being anything
> other than 8 bits.
Microcontrollers and digital signal processors.
The microcontroller manufacturers try every conceivable trick to minimize
cost. The result is something like the very common
first-timer-microcontroller PIC12/16 series:
Being a harvard architecture, the family uses 12-, 13-, 14-, or (I'm not
sure) 15-bit code memory in the different variants. Data memory is 8 bits
wide, and is a 'byte'.
I've programmed 4 bit micros. 12-bit once (where a byte was defined as 12
bits and a nybble 6).
Modern DSPs are less hairy, but I've used some that were 20 wide in code and
16 in data.
/Kasper
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: random number sequences
Date: Fri, 13 Oct 2000 21:39:49 GMT
Pete wrote:
> say i generate a keystream using say, RC4. i presume this could be
> viewed as a stream of bytes(or a vector space over B ??). how would i
> got about converting this number stream to a different base ?
Most modern applications require an integral number of bits,
so you just take as many as necessary. E.g. if you need 12
bits (which can be thought of as a binary representation of
a value from 0 through 4095), and you can generate an array
of 8-bit flat-random values stored in an array of type
"unsigned char" in a C program:
unsigned char random_bits[MAX];
unsigned int random_12bit;
generate_random_octets(random_bits, MAX);
random_12bit = (unsigned int)random_bits[0]
| (((unsigned int)random_bits[1] & 0xF) <<8);
> if i were wanting to have a random stream of numbers in say base 27 for
> example, could i just 'mod 27' the original keystream or would that
> mangle the statistical properties of the keystream ?
If you merely take at least ceil(lg(base)) random bits and
use the remainder mod base, it will usually be biased.
Consider: 000 mod 3 = 0
001 mod 3 = 1
010 mod 3 = 2
011 mod 3 = 0
100 mod 3 = 1
101 mod 3 = 2
110 mod 3 = 0
111 mod 3 = 1
You'll get "2" 1/4 the time and get "0" 3/8 the time.
If you don't mind wasting some fraction of the bits,
you can get around this by skipping pre-mod values
past the last full cycle:
while ((input = get_random_3bits()) >= 6)
; // don't use partial cycle
output = input % 3;
or
while ((input = get_random_octet()) >= 27*(256/27))
; // don't use partial cycle
output = input % 27;
If you need to use the random bits with 100% asymptotic
efficiency, there are ways -- see the paper I've cited
a few times recently.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Is it trivial for NSA to crack these ciphers?
Date: Fri, 13 Oct 2000 21:43:07 GMT
"Stephen M. Gardner" wrote:
> With modern cryptography the NSA is no better off than anyone else.
That's quite a claim. What supporting evidence do you have?
> There is no such thing as wizardry, only misdirected attention.
Apparently you have never met real wizards.
------------------------------
From: [EMAIL PROTECTED] (David Wagner)
Subject: Re: A5/1
Date: 13 Oct 2000 18:21:53 GMT
Reply-To: [EMAIL PROTECTED] (David Wagner)
Actually, it would be more accurate to report the complexity of the
FSE 2000 attack on A5/1 in two separate categories:
o There is a one-time pre-processing step, with complexity 2^48.
o Then, each subsequent key you want to break takes 2^24 work.
This is faster than what the previous post suggested, I think.
The above is still not the whole story, because there are many possible
tradeoffs between precomputation time, storage size, workfactor per key
broken, and amount of known plaintext needed. However, this already shows
that the cost of the precomputation can be amortized if you break many
keys, and the cost per key can be much lower than 2^{2n/3} steps of
computation.
In practice, I think the cost of the one-time 2^48 computation can be
ignored. This suggests that, if the required known plaintext is available,
it is likely to be feasible to break GSM traffic in real time without
too much hard work.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Sending the same messgae twice -- why is this a weakness?
Date: Fri, 13 Oct 2000 22:09:13 GMT
"David C. Barber" wrote:
> Quoting from: http://www.eclipse.net/~dhamer/lorenz.htm
> > The first real break into Tunny traffic occurred on August 30, 1941 when a
> > cipher clerk in Vienna sent a long message - four thousand or so
> > characters - to his opposite number in Athens. When he had finished this
> > formidable typing effort he received a reply which was the German equivalent
> > of "I didn't get all that. Please send it again..!". So he did - using,
> > against all established principles of cipher security, the same machine
> > settings that he had used for the first transmission. He also used a number
> > of abbreviations [e.g. 'Spruchnummer' became 'Spruchnr' , etc.]. This
> > egregious error was the chance for which BP was waiting and a team headed by
> > Colonel John Tiltman deciphered the message in short order.
Tony Sale, former curator at the Bletchley Park museum, has
reconstructed Colossus, and information about that is at URL
http://www.codesandciphers.org.uk/lorenz/rebuild.htm
He gave a nice talk about this at NSA yesterday.
> This may be really dumb, but why was this a weakness? If the operator sent
> the same message twice using the same settings each time, the second message
> should have been a duplicate of the first message, and offered no additional
> information any more than if someone had written the message twice. Was the
> problem that the second message was only similar, not identical?
Read the quotation more carefully. In the first message
SPRUCHNUMMER was spelled out in full; in the second one,
it was abbreviated SPRUCHNR. The subsequent text was
identical (for a ways -- further on there were more instances
of abbreviating words or phrases in the second message only).
As a result, Tiltman was able to construct what in the
trade is known as a "delta stream" that allowed analysis
of the structure of the key stream. It was still far from
an easy task, because the Lorenz system had a rather complex
structure -- it combined a more or less straight bank of
rotors with an irregularly stepping bank. (So did SIGABA,
but for reasons I don't want to get into SIGABA's method
is much harder to cryptanalyze.)
------------------------------
From: [EMAIL PROTECTED] (Jim Reeds)
Subject: Re: A journal about crypto history
Date: Fri, 13 Oct 2000 23:12:29 GMT
In article <[EMAIL PROTECTED]>, Mok-Kong Shen <[EMAIL PROTECTED]>
writes:
|>
|> I just saw in the library one issue of a journal that was
|> new to me but that is already in its vol.15. From the content
|> of that issue, I deduce that the journal could be of value
|> to those interested in crypto history:
|>
|> Intelligence and National Security.
|>
|> URL of its producer is www.frankass.com
Yes, a very interesting journal, but as its title indicates,
not exclusively about the history of cryptography. In fact
none of the articles I've seen have very much in the way of
technical details of the sort often seen in the historical
articles in Cryptologia.
--
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: CiPHER <[EMAIL PROTECTED]>
Subject: Re: Is it trivial for NSA to crack these ciphers?
Date: Fri, 13 Oct 2000 23:21:05 GMT
In article <[EMAIL PROTECTED]>,
Anonymous <[EMAIL PROTECTED]> wrote:
> I'm more interested to know what people think about NSA's ability to
> break messages encrypted with these ciphers.
"If you code it... they will come... and break the shit out of it."
I have no doubts in my mind that every (applicable) cipher out there
has already been easily broken by the top intelligence agencies. Any
others that exist (most likely researched by them themselves) aren't
likely to be known of till they themselves have been able to devise a
realistic deciphering system.
You see, otherwise, they'd really be shitting it and export laws would
be tougher than you could possible imagine...
...and everyone acts suprised when flaws are found in the 'best'
systems. *tut-tut*
--
Marcus
---
[ www.cybergoth.cjb.net ] [ alt.gothic.cybergoth ]
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Paul Rubin <[EMAIL PROTECTED]>
Subject: Re: Why trust root CAs ?
Date: 13 Oct 2000 17:12:15 -0700
[EMAIL PROTECTED] (Vernon Schryver) writes:
> Common HTTP servers come with all of the stuff needed for a small CA.
> For Apache, you need only following the easy instructions to run some
> programs to create some files, put them where they belong (including secure
> backups and so forth), and you're off and certificate authenticating.
Actually not true, if you count downloading the certificates as part
of the function of a CA. I've been trying to make client certificates
with OpenSSL (no problem) and install them into my IE browser with the
xenroll.dll control, and I'm having a heck of a time getting it to
work. The web server does *not* come with the javascript needed
to operate xenroll, but I've written some that looks like it should
work but doesn't. Any advice would be much appreciated.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: algo to generate permutations
Date: Sat, 14 Oct 2000 00:06:58 GMT
Sounds fun! Here's another:
/* print a permutation of the string */
void report( int *state, int maxdepth, char *string) {
int i;
for (i=0; i<maxdepth; ++i) {
printf("%c", string[state[i]]);
}
printf("\n");
}
int swap( int *x, int *y) { int temp = *x; *x = *y; *y = temp;}
/* decide the next level in permutation and recurse */
void recurse( int *state, int maxdepth, int depth, char *string) {
int i;
if (depth == maxdepth) {
report(state, depth, string); /* print permutation */
}
else {
for (i=depth; i<maxdepth; ++i) {
swap( state+depth, state+i); /* choose */
recurse( state, maxdepth, depth+1, string); /* recurse */
swap( state+depth, state+i); /* restore */
}
}
}
/* find all permutations of first argument */
int main( int argc, char **argv) {
if (argc == 2) {
int i, maxdepth, state[1000];
maxdepth = strlen(argv[1]); /* how big is it? */
for (i=0; i<maxdepth; ++i) { /* set up state */
state[i] = i;
}
recurse(state, maxdepth, 0, argv[1]); /* do the work */
}
else {
printf("Use 'permute xxx': it permutes the string xxx\n");
}
return 0;
}
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
Subject: Bestcrypt technical difficulty question
From: [EMAIL PROTECTED] (Patrick O'Reilly)
Date: 14 Oct 2000 01:59:35 GMT
Hi,
I recently installed BestCrypt 6.06.3 on my Windows2000 machine.
When I start windows, I get a message saying
"BCRESIDENT.exe-No Disk
There is no disk in the drive. Please insert a disk into drive A:"
I Press continue and things are alright, or sometimes it gives another
error message that says something like " \disk2\hard2 disk does not exist",
or something like that (sorry, trouble reproducing it tonight)
Finally, every time I open a container, the A: drive gets "pinged", as in a
disk is looked for, but then the container opens without any error
messages.
I've looked in the Bestcrypt control panel, can't see where the problem is,
and also have searched the registry for Bcresident, and can't see what is
causing the problem. Any ideas?? Thanks in advance,
Pat
System: AMDK-6-3-400, 128 mb ram, 8 mb ati video, zip250i, HP CD-RW 9100i.,
etc.
______________________________________________________________________
Posted Via Uncensored-News.Com - Still Only $9.95 - http://www.uncensored-news.com
With Servers In California, Texas And Virginia - The Worlds Uncensored News Source
------------------------------
From: "Will Newland" <[EMAIL PROTECTED]>
Subject: Re: Crypto technology recommendations?
Date: Sat, 14 Oct 2000 01:05:48 GMT
"DJohn37050" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> I think there are many many ways to go wrong by trying to do it yourself.
> Consider getting a toolkit from a crypto provider...
Thanks for the input. We're looking at that, too. I've spoken with a few
vendors,
and pretty much laughed right in the RSA rep's face (over the phone) when
he reviewed the royalty-based licensing. "Buh bye!"
How about technologies used for delivery, any ideas about that? I'm leaning
toward Java for its cross-platform beauty, but some in the shop like the
C-based
libs. I'm not certain if their pick is because of some techincal
superiority or just
their Borg-like adherence to all things M$. I'm willing to listen, though.
Let me know
what you think.
--Will
------------------------------
From: Daniel Leonard <[EMAIL PROTECTED]>
Subject: Re: Problem with SHA256 implementation
Date: Sat, 14 Oct 2000 01:17:23 GMT
On Fri, 13 Oct 2000, Tom St Denis wrote:
> > 'abc' works, as well as 1000000 x 'a' on a Sun Ultra 5. Anybody
> tested my
> > Java code ?
>=20
> Did you test my code on the Sun, Is the Sun a high endian? Where is
> your java code?
>=20
> Tom
I think so, it worked fine.
My code was posted as a zip archive in one of my post (from
[EMAIL PROTECTED]) - I know about posting binaries on non-binaries group.
Now I am trying to implement a less naive implementation.
==========
Daniel L=E9onard
OGMP Informatics Division E-Mail: [EMAIL PROTECTED]
D=E9partement de Biochimie Tel : (514) 343-6111 ext 5149
Universit=E9 de Montr=E9al Fax : (514) 343-2210
Montr=E9al, Quebec Office: Pavillon Principal G-312
Canada H3C 3J7 WWW : http://megasun.bch.umontreal.ca/~leonard
------------------------------
From: Roger Schlafly <[EMAIL PROTECTED]>
Subject: Re: Rijndael implementations
Date: Fri, 13 Oct 2000 18:25:07 -0700
Kasper Pedersen wrote:
> > What are you guys programming? When I was in school, they still had
> > a CDC 6600 humming in the basement. But it's been a long time since
> > I heard of anyone building a machine with a byte being anything
> > other than 8 bits.
>
> Microcontrollers and digital signal processors.
>
> The microcontroller manufacturers try every conceivable trick to minimize
> cost. The result is something like the very common
> first-timer-microcontroller PIC12/16 series:
> Being a harvard architecture, the family uses 12-, 13-, 14-, or (I'm not
> sure) 15-bit code memory in the different variants. Data memory is 8 bits
> wide, and is a 'byte'.
But odd-sized opcodes don't present big problems. As long as the
data is in 8-bit bytes.
> I've programmed 4 bit micros. 12-bit once (where a byte was defined as 12
> bits and a nybble 6).
>
> Modern DSPs are less hairy, but I've used some that were 20 wide in code and
> 16 in data.
Old machines? I worked for a defense contractor once that used
18-bit processors. But I think they wanted something oddball.
Any recent processors?
------------------------------
From: JD <[EMAIL PROTECTED]>
Subject: Re: Why trust root CAs ?
Date: Sat, 14 Oct 2000 01:30:26 GMT
> It was not until I heard a talk in Cambridge a few years ago by
> Steve Kent that I understood "self-signed" certificates. The signing
> does not convey any trust -- it is just an artifact to get
certificates
> into a form with which relying software is accustomed to dealing.
It's more important than that; in fact, I would say that the signature
is actually half of the trust equation.
It proves that the self-signer actually controls the private key that
corresponds with the public key contained within the certificate. A CA
verifies this fact as well, by checking the applicant's signature on
his Certificate Signing Request. This prevents person A from borrowing
person B's public key and passing it off in his own certificate, thus
tricking you into using the wrong person's public key for encryption or
signature verification.
Of course, the other half of the validation that needs to be done
before you assign trust to a certificate is that you must verify that
the certificate's subject matches the actual identity of the person
claimed. You either do this directly, by asking the subject for his
public key fingerprint through an authenticated channel (like voice or
in person, assuming you already know the person and can reliably
authenticate him through this method), or you trust that the CA has
done this for you.
--JJ
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (Larry Kilgallen)
Subject: Re: Why trust root CAs ?
Date: 13 Oct 2000 22:54:32 -0500
In article <8s8cvj$m04$[EMAIL PROTECTED]>, JD <[EMAIL PROTECTED]> writes:
>
>> It was not until I heard a talk in Cambridge a few years ago by
>> Steve Kent that I understood "self-signed" certificates. The signing
>> does not convey any trust -- it is just an artifact to get
> certificates
>> into a form with which relying software is accustomed to dealing.
>
> It's more important than that; in fact, I would say that the signature
> is actually half of the trust equation.
>
> It proves that the self-signer actually controls the private key that
> corresponds with the public key contained within the certificate.
So the trickster merely must replace the public key and use their
own private key. Nothing is proven by self-signing.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: Problem with SHA256 implementation
Date: Sat, 14 Oct 2000 01:46:32 GMT
In article <Pine.GSO.4.21.0010132113250.27606-
[EMAIL PROTECTED]>,
Daniel Leonard <[EMAIL PROTECTED]> wrote:
> On Fri, 13 Oct 2000, Tom St Denis wrote:
>
> > > 'abc' works, as well as 1000000 x 'a' on a Sun Ultra 5. Anybody
> > tested my
> > > Java code ?
> >=20
> > Did you test my code on the Sun, Is the Sun a high endian? Where is
> > your java code?
> >=20
> > Tom
>
> I think so, it worked fine.
>
> My code was posted as a zip archive in one of my post (from
> [EMAIL PROTECTED]) - I know about posting binaries on non-binaries
group.
>
> Now I am trying to implement a less naive implementation.
Your code was in Java or C?
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
** 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
******************************
