Cryptography-Digest Digest #155, Volume #14 Sun, 15 Apr 01 20:13:00 EDT
Contents:
Re: Announcing A New Rijndael Encryption Algorithm Implementation (Mok-Kong Shen)
Re: combiner? (newbie)
Re: Password tool! (=?Windows-1252?Q?Claus_N=E4veke?=)
Re: LFSR Security (David Wagner)
Re: Reusing A One Time Pad (newbie)
Re: C Encryption ("Anon")
Re: LFSR Security (Graywane)
Re: combiner? ("Tom St Denis")
DES Much Better Through Plaintext Entropy ? (Frank Gerlach)
Re: Reusing A One Time Pad ("Tom St Denis")
Re: Reusing A One Time Pad ("Tom St Denis")
Re: NSA is funding stegano detection (Niels Provos)
Re: There Is No Unbreakable Crypto - Off Topic ("John A. Malley")
Re: Lorentz attractor... (Mok-Kong Shen)
Re: There Is No Unbreakable Crypto - Off Topic (Mok-Kong Shen)
Re: C Encryption (Ben Cantrick)
Re: Why Not OTP ? (John Savard)
Re: There Is No Unbreakable Crypto (John Savard)
Re: Function other than xor? (John Savard)
Re: There Is No Unbreakable Crypto - Off Topic ("John A. Malley")
Re: Function other than xor? (newbie)
Re: Reusing A One Time Pad (Bryan Olson)
Re: LFSR Security (David Wagner)
Re: LFSR Security (Graywane)
Re: Note on combining PRNGs with the method of Wichmann and Hill (Bryan Olson)
----------------------------------------------------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Announcing A New Rijndael Encryption Algorithm Implementation
Date: Sun, 15 Apr 2001 23:07:12 +0200
Eric Lee Green wrote:
>
> It's permissible to export virtually anything from the United
> States nowdays -- my own employer exports 128-bit Rijndael and the
> export license was granted virtually instantaneously.
It is a pleasure to know that the nonsense (including
allowing codes in book form for export but not those on
magnetic medium) has finally stopped.
M. K. Shen
==========================
http://home.t-online.de/home/mok-kong.shen
------------------------------
From: newbie <[EMAIL PROTECTED]>
Subject: Re: combiner?
Date: Sun, 15 Apr 2001 17:10:37 -0300
You did not answer to my question.
What are the conditions that has to meet a combiner to be hard to
attack?
___________
> Your question makes no sense whatsoever. XOR is not an insecure operation,
> it's not secure either. In conjunction with other operations it could be
> made secure.
__________-
That is what I said before. It depends on how you use Xor.
I don't understand what it makes no sense in question. Enlight me
please.
What did you add to my question? Nothing.
You are just repeating what I said using another language more
"technical".
------------------------------
From: =?Windows-1252?Q?Claus_N=E4veke?= <[EMAIL PROTECTED]>
Subject: Re: Password tool!
Date: Sun, 15 Apr 2001 23:13:38 +0200
"Logan Raarup" <[EMAIL PROTECTED]> schrieb im Newsbeitrag
news:kZnC6.42792$[EMAIL PROTECTED]...
> Instead og entering like this:
> $ passwd
> Enter user's password:
> Enter user's password again:
> Enter user's new password:
>
> I want to enter it like this:
>
> $ program [user] [new password]
Write a Perl script which runs as root. It should be no Problem to
change the password then.
Claus
------------------------------
From: [EMAIL PROTECTED] (David Wagner)
Subject: Re: LFSR Security
Date: 15 Apr 2001 21:19:04 GMT
Graywane wrote:
>While we are on the subject, would the following be a suitable technique to
>generate "random" data for a true OTP: [Rc4, Mersenne Twisters, ...]
This is not a true OTP, so: No.
------------------------------
From: newbie <[EMAIL PROTECTED]>
Subject: Re: Reusing A One Time Pad
Date: Sun, 15 Apr 2001 17:14:46 -0300
What if I show you that you could reuse the same short random key to Xor
another plain-text?
And how to do that?
That is possible.
Tom St Denis wrote:
>
> "Mark G Wolf" <[EMAIL PROTECTED]> wrote in message
> news:9bd1d8$2pgu$[EMAIL PROTECTED]...
> > > Second re-using keystream has been tried before (Maurer....) and is
> often
> >
> >
> > Good for Maurer.
> >
> > > broken easily... Reason, chosen plaintexts or known plaintexts can be
> > very
> > > damaging... You can't reuse the bits and still claim it's secure
> >
> > I wasn't claiming anything. I asked a question.
>
> Ok, answer, you can't reuse otps....
>
> Tom
------------------------------
From: "Anon" <[EMAIL PROTECTED]>
Subject: Re: C Encryption
Date: Sun, 15 Apr 2001 22:21:48 -0000
To be slightly more helpful... see
http://www.esat.kuleuven.ac.be/~rijmen/rijndael/
"Logan Raarup" <[EMAIL PROTECTED]> wrote in message
news:hWlC6.42589$[EMAIL PROTECTED]...
> Anyone know how to encrypt a string in C?
>
> /logan
>
>
------------------------------
From: [EMAIL PROTECTED] (Graywane)
Subject: Re: LFSR Security
Date: Sun, 15 Apr 2001 21:26:45 GMT
In article <9bd388$ril$[EMAIL PROTECTED]>, David Wagner wrote:
> Graywane wrote:
> >While we are on the subject, would the following be a suitable technique to
> >generate "random" data for a true OTP: [Rc4, Mersenne Twisters, ...]
>
> This is not a true OTP, so: No.
I didn't figure it would be. I also wasn't trying to come up with something
that would be NSA proof (as I always assume they can read what they want
whenever they want.) However, how would someone like YOU fair against
techniques like this? -- i.e. people trying to generate data for a OTP
without access to anything truly random or without the time to collect
enough to be useful.
In other words, how would you go about breaking something like this?
Pointers to technical papers are welcome.
--
Note: There is no example in my hostname.
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: combiner?
Date: Sun, 15 Apr 2001 21:27:43 GMT
"newbie" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> You did not answer to my question.
> What are the conditions that has to meet a combiner to be hard to
> attack?
That depends on the attack.
Tom
------------------------------
From: Frank Gerlach <[EMAIL PROTECTED]>
Subject: DES Much Better Through Plaintext Entropy ?
Date: Sun, 15 Apr 2001 23:24:29 +0200
Isn't it prudent to assume the diffusion of plaintext entropy in (3)DES
contributes greatly to its security ? In my opinion XORed-stream ciphers more
or less throw away the inherent entropy of the plaintext, which could be
diffused (as done in block ciphers) in order to protect the *key*.
What do you think ?
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: Reusing A One Time Pad
Date: Sun, 15 Apr 2001 21:28:57 GMT
"newbie" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> What if I show you that you could reuse the same short random key to Xor
> another plain-text?
> And how to do that?
> That is possible.
You cannot reuse parts of an OTP. If you somehow did you must have went
back in time and re-invented the word
*************************ONE**************************
Remember that OTP = ONE TIME PAD... not "MAYBE MULTIPLE TIME PAD" or ....
Tom
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: Reusing A One Time Pad
Date: Sun, 15 Apr 2001 21:30:13 GMT
"Mark G Wolf" <[EMAIL PROTECTED]> wrote in message
news:9bd2ip$fd4$[EMAIL PROTECTED]...
> > > OK so the message is either aa, ab, ba, or bb.
> >
> > No, if I wanted 5 random bits I could use aaaaa or abbba or bbbbb or....
>
> You can't have 5 random bits since the pad you've given only consists of 2
> random bits.
I am reusing the bits though...
Anyways this is pointless you can't reuse OTP's it's impossible
>
>
>
------------------------------
From: [EMAIL PROTECTED] (Niels Provos)
Crossposted-To: comp.security.misc,talk.politics.crypto
Subject: Re: NSA is funding stegano detection
Date: 15 Apr 2001 21:39:18 GMT
On 15 Apr 2001 20:34:10 GMT, Walter Roberson wrote:
>Yes, but by the time you account statistically for all of those
>different models, the statistical measure is going to have to be
>very loose -- unable to detect anything but the most obvious
>hidden information.
That is not really true, read
http://wwwrn.inf.tu-dresden.de/~westfeld/attacks.html
for an example of a statistical measure that is capable
of detecting a particular scheme of steganography.
>Alternately, have *every* image contain a message, but make it very
>difficult to tell which messages are spurious. Perhaps even use
>a multi-level code in which the "outer" message was relatively
>innocuous and explicable/deniable. For example you could even give
OutGuess supports embedding of multiple messages for the purpose
of plaubsible deniability. Of course, you'd like to avoid detection
to begin with.
--
Niels Provos <[EMAIL PROTECTED]> finger [EMAIL PROTECTED] for pgp info
"Gravity is the soul of weight." - Anonymous.
------------------------------
From: "John A. Malley" <[EMAIL PROTECTED]>
Subject: Re: There Is No Unbreakable Crypto - Off Topic
Date: Sun, 15 Apr 2001 14:45:31 -0700
Mok-Kong Shen wrote:
> No airplane is built entirely free of
> possible technical problems. Even if the engineers could
> have done that and money were not an issue, there may be
> other unexpected factors that could cause a crash, e.g. a
> collision as we learned recently in newspapers.
Couldn't resist since this particular area (airplanes and aerospace
vehicles) and this particular systems engineering subject (preventing or
containing the effects of failures by system design) is my day job.
We do design aircraft systems such that no single failure, however
probable, results in catastrophic loss of the aircraft.
Any single failure includes random hardware failure, hardware design
error, software design error, software "bug", parts manufacturing error
and common mode errors due to temperature, HERF, birdstrikes, bomb
blast, uncontained engine failure, tire rupture, etc. (And catastrophic
loss is defined by the certification agencies in the US and EU and other
nations of the world.)
The "art" is designing and manufacturing to meet this stringent
requirement while also making a profit.
The analysis techniques used today advanced quite a bit since the
designs of the 1960s and 70s (like the Concorde.) I worked on the FBW
and autopilot system of the Boeing 777 where we rigorously applied these
analyses.
Combinations of failures over time can lead to catastrophe. We assess
the probability of the chains of events leading to catastrophe (with
fault trees, for example) and show the probability per flight hour of a
catastrophic event is on the order of 1e-9 per flight hour.
The certification agencies set the engineering integrity targets for
catastrophic events to < 1e-9 per flight hour (for things that could
happen anytime during a typical flight) or < 1e-9 per event (for things
that could happen during a takeoff or a landing). What this means, for
example, is that in a fleet of aircraft that fly individually thousands
of hours a year, cumulatively hundreds of thousands of hours per year,
after many years (when the total flight hours for all aircraft of the
same type reach > 1e9 flight hours) its an acceptable risk for society
that one out of all of those aircraft suffers a catastrophe.
Typically we make on the order of 1000 (large passenger carrying)
aircraft of a particular type. Assume each aircraft flies on the order
of 3000 hours a year - that 3e6 fleet hours a year. To reach 1e9
cumulative hours requires 1/3 e3 years or about 300 years. There's a lot
of "margin" built into these targets.
Many accidents today involve more "fuzzy" and complicated issues such as
cognitive errors on the flight deck (what *does* that light mean?) and
(I kid you not) flight deck management - how two human pilots cooperate
to control the aircraft as a team. Poor relationships between pilots
can lead to accidents. Poor choices (trying to land in borderline
conditions - "press-on-itis" ) can cause serious accidents.
John A. Malley
[EMAIL PROTECTED]
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Lorentz attractor...
Date: Mon, 16 Apr 2001 00:13:03 +0200
ClaudeVMS wrote:
>
> I read an article about the Lorentz attractor being used in a synchronized
> chaos transmitter-receiver setup a few
> years ago. I have since found only few reports on the use of attractors in
> encryption science. Obviously, one does
> not trust new technology until throughly reviewed - and then you still
> wonder. I am looking for a source of objective information on using
> attractors in a cryptographic algorithm. Also, does sci.crypt have an FAQ
> and what's its URL?
Sorry that I can't help you. That you have already found
some reports is not bad. There aren't much literatures,
I am afraid. You should check the journals on chaos
and non-linear sciences to find papers with eventual
further pointers.
It's my impression that mainstream crypto experts seldom
express concrete opinions on the use of chaos theory.
But that could just be due to my ignorance.
FAQ of this group was last posted on 14th Mar. You
probably wouldn't see it currently on your news server.
Wait for the next post or access: www.faqs.org.
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: There Is No Unbreakable Crypto - Off Topic
Date: Mon, 16 Apr 2001 00:26:56 +0200
"John A. Malley" wrote:
>
[snip]
> Combinations of failures over time can lead to catastrophe. We assess
> the probability of the chains of events leading to catastrophe (with
> fault trees, for example) and show the probability per flight hour of a
> catastrophic event is on the order of 1e-9 per flight hour.
Is it here that BDD technique is useful? I suppose there
is lots of computation done on an airplane. Do you
duplicate or triplicate at least some of the hardware
and use different software codes to check one another?
M. K. Shen
------------------------------
From: [EMAIL PROTECTED] (Ben Cantrick)
Subject: Re: C Encryption
Date: 15 Apr 2001 16:32:18 -0600
In article <hWlC6.42589$[EMAIL PROTECTED]>,
Logan Raarup <[EMAIL PROTECTED]> wrote:
>Anyone know how to encrypt a string in C?
#include <stdio.h>
void main(void)
{
char inStr[17]; /* Gratitous buffer overflow error part 1. */
printf("Enter the string to be encrypted: ");
gets(inStr); /* Gratitous buffer overflow error part 2. */
printf("The string encrypted is: ");
printf("djlkakjfdLI3nklFD9Fklklfasj(3jmklFD3#@23jklas;j(32lkjr*");
printf("\n");
return(0);
}
This encryption program has perfect security - the output is essentially
random and has no dependecy whatsover on the input.
But you're going to have to figure out the decryption routine on your own. ;]
-Ben
--
Ben Cantrick ([EMAIL PROTECTED]) | Yes, the AnimEigo BGC dubs still suck.
BGC Nukem: http://www.dim.com/~mackys/bgcnukem.html
The Spamdogs: http://www.dim.com/~mackys/spamdogs
"I don't think so," said Rene Descartes. And then he vanished.
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Why Not OTP ?
Date: Sun, 15 Apr 2001 22:57:38 GMT
On Sun, 15 Apr 2001 23:04:57 +0200, Frank Gerlach <[EMAIL PROTECTED]>
wrote, in part:
>Why is it that people do not like OTP ? It seems that some people do not like
>Public-Key crypto, so why not just exchanging a box of CDs ?
Well, it is cumbersome and expensive. Worse yet, it imposes a strict
limit on how many communications can be exchanged - and maybe it may
become important to communicate securely just when exchanging a new
box of CDs has suddenly become harder.
Plus, it's fragile. Accidentaly use the same pad twice, and your
security is toast. But that could be solved by combining the OTP with
conventional encryption - and the Soviets have actually done this with
one of their cipher machines, according to one web site.
John Savard
http://home.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: There Is No Unbreakable Crypto
Date: Sun, 15 Apr 2001 22:59:59 GMT
On Sun, 15 Apr 2001 18:17:47 +0200, Mok-Kong Shen
<[EMAIL PROTECTED]> wrote, in part:
>I think that it is also useful to keep in mind that, while
>theoretical issues can be extremely valuable/illuminating,
>all what the users need is 'practical' security to protect
>his privacy for a limited finite time. Barely anyone is
>planning on the scale of centuries.
Quite true.
But I am claiming that it is essentially trivial to do conventional
crypto that works 'on the scale of centuries', and this, to my mind,
is not important because we need to do it, it's important because that
means one less thing to worry about, so we can get on to the next
problem.
John Savard
http://home.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Function other than xor?
Date: Sun, 15 Apr 2001 23:05:15 GMT
On Sat, 14 Apr 2001 22:05:32 -0300, newbie <[EMAIL PROTECTED]>
wrote, in part:
>I'm newbie. I discovered crypto just 6 months ago.
>I'm reading some articles and the useful book of Menendez.
The book by Menezes et al is certainly a good resource. If you're
looking for something less technical, may I recommend my own web site,
as identified in my sig?
John Savard
http://home.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: "John A. Malley" <[EMAIL PROTECTED]>
Subject: Re: There Is No Unbreakable Crypto - Off Topic
Date: Sun, 15 Apr 2001 16:10:13 -0700
Mok-Kong Shen wrote:
>
[snip]
>
> Is it here that BDD technique is useful? I suppose there
> is lots of computation done on an airplane. Do you
> duplicate or triplicate at least some of the hardware
> and use different software codes to check one another?
Absolutely!
Redundancy and dissimilarity are the cornerstones of systems
architectures. Dissimilarity and redundancy allow us to identify and
contain failures.
Voting results produced by dissimilar hardware running identical
algorithms can detect and contain/isolate errors due to design errors in
the hardware, manufacturing mistakes introduced in production and random
failures of the parts.
Splitting functions across dissimilar hardware in dissimilar
software/algorithms also helps detect and contain/isolate errors due to
design errors in the software implementation, mistakes in the software
design, design errors in the hardware, manufacturing mistakes introduced
in production and random failures of the parts.
Personally I favor dissimilar, redundant systems - the 777 Fly-By-Wire
system merges a digital fly-by-wire system and an analog fly-by-wire
system into one overall system. Shut down the entire digital
fly-by-wire system and the aircraft continues on its analog FBW system
(called Direct Mode.)
John A. Malley
[EMAIL PROTECTED]
------------------------------
From: newbie <[EMAIL PROTECTED]>
Subject: Re: Function other than xor?
Date: Sun, 15 Apr 2001 19:24:23 -0300
I know your website. It is sincerely good reference.
I consult it regularly. Two or three times a week.
I have lot of ideas. I'm just trying to understand how things works in
crypto.
I still do not understand what DS add comparing to Vernam cipher.
If Ritter is trying to hide the keystream, it is easy. He does not need
DS as combiner.
Let keystream = 213526326419823415231 generated any PRNG (liner
congruential...) you have just to replace 2 or 4 or 6 etc... by 1 as
even number and 1,3,5,7,.. by 0. Or the inverse.
You obtain then new keystream 011100100011001010....
How any attacker could access to the cycle of the keystream?
If you use it with plain-text Xoring it, how it could be analyzed since
the attacker does not know the seed?
More. If you break randomly your plain-text
M = 12513521
M = M1 + M2
You may pick randomly r with 0.4 < r < 0.6 ( M1 = int(r*M))
Then M2 = M - M1
You encrypt separately M1 and M2
To decipher
D(M1) + D(M2) = M
Thank you.
John Savard wrote:
>
> On Sat, 14 Apr 2001 22:05:32 -0300, newbie <[EMAIL PROTECTED]>
> wrote, in part:
>
> >I'm newbie. I discovered crypto just 6 months ago.
> >I'm reading some articles and the useful book of Menendez.
>
> The book by Menezes et al is certainly a good resource. If you're
> looking for something less technical, may I recommend my own web site,
> as identified in my sig?
>
> John Savard
> http://home.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: Bryan Olson <[EMAIL PROTECTED]>
Subject: Re: Reusing A One Time Pad
Date: Sun, 15 Apr 2001 16:35:04 -0700
Mark G Wolf wrote:
> If I had a "large" one time pad and used random fixed size "chunks" of it to
> essentially generate other one time pads to encrypt the exact same message,
> what would be the relationship between the time (given a fixed speed of
> computation) to break the coded message and the size of the pad, the size of
> the chunks, and the number of times the pad is reused.
Even if the details were filled in, determination of time to
break is often beyond the state of the art. The point of
the OTP is that it's the one cryptosystem we can prove
secure against cryptanalysis. That doesn't mean we can
prove all others insecure.
If your method generates new pads such that all bitstrings
are equally probable and independent of previous pads, then
the perfect secrecy theorem still applies. Doing so will
require additional entropy (that is, entropy not taken from
the previous pads) sufficient to generate the new pad
directly, so I don't see the new pad as re-use of the old
one in any meaningful sense.
--Bryan
------------------------------
From: [EMAIL PROTECTED] (David Wagner)
Subject: Re: LFSR Security
Date: 15 Apr 2001 23:42:41 GMT
You asked if it would make a good OTP. The answer is no, it is not a OTP.
This may sound like just terminology, but it is an important distinction.
If you're designing a system that needs communications security, just use
IPSEC or TLS or some other well-studied standard. This stuff is so easy to
get wrong that I strongly recommend against trying to "roll your own" cipher.
------------------------------
From: [EMAIL PROTECTED] (Graywane)
Subject: Re: LFSR Security
Date: Sun, 15 Apr 2001 23:57:25 GMT
In article <9bdblh$sj8$[EMAIL PROTECTED]>, David Wagner wrote:
> You asked if it would make a good OTP. The answer is no, it is not a OTP.
> This may sound like just terminology, but it is an important distinction.
> If you're designing a system that needs communications security, just use
> IPSEC or TLS or some other well-studied standard. This stuff is so easy to
> get wrong that I strongly recommend against trying to "roll your own" cipher.
If my question was poorly worded then I apologize. Let me try again. I know
the method posted is bad because I have no experience designing a cipher and
I typed the description as it popped into my head. It should be obviously
bad. What seems odd to me is that everyone correctly says "its bad" but no
one posts a reason as to WHY it is bad. Even a reference to a technical
paper that I could find in my local library would be nice but no cigar.
Everyone just says "its bad."
What I was fishing for was a reason why. Perhaps I should have clearly
stated that in my previous posts. My bad.
--
Note: There is no example in my hostname.
------------------------------
From: Bryan Olson <[EMAIL PROTECTED]>
Crossposted-To: sci.crypt.random-numbers
Subject: Re: Note on combining PRNGs with the method of Wichmann and Hill
Date: Sun, 15 Apr 2001 16:50:55 -0700
Mok-Kong Shen wrote:
>
> The method of Wichmann and Hill (Appl. Statist. 31 (1982))
> for combining n arbitrary PRNGs with output in [0, 1) consists
> in forming their sum mod 1. For crypto purposes, one could
> introduce some 'variability' by employing a weighted sum
> instead, thus rendering the analysis more difficult. We could,
> for example, choose cofficients in some range (1.0-delta,
> 1.0+delta) to multiply the PRNG outputs before summing mod 1.
This note includes no justification for "thus rendering the
analysis more difficult".
The modification destroys an important property of the basic
combination method: as long as the streams are independent,
if any of the streams are uniform then the sum is uniform.
--Bryan
------------------------------
** 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 by posting to sci.crypt.
End of Cryptography-Digest Digest
******************************
