Cryptography-Digest Digest #967, Volume #13 Thu, 22 Mar 01 03:13:00 EST
Contents:
Re: Is Evidence Eliminator at all useful ?? (Eric Lee Green)
Re: Fill-in-the-blank codes (similar to Error-correcting codes) (Eric Jacobsen)
Re: What the Hell...Here's what my system can do at it's best... (Eric Lee Green)
Re: Strong Primes (Peter Engehausen)
Re: Fill-in-the-blank codes (similar to Error-correcting codes) ("Brian McKeever")
Re: What the Hell...Here's what my system can do at it's best... (SCOTT19U.ZIP_GUY)
Re: Advice on storing private keys (Paul Rubin)
Re: Fill-in-the-blank codes (similar to Error-correcting codes) (Jyrki Lahtonen)
Re: Fill-in-the-blank codes (similar to Error-correcting codes) (Roy Hulen Stogner)
Re: I was so so right about PGP ... so right when I started writing (Frank
Gerlach)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Eric Lee Green)
Subject: Re: Is Evidence Eliminator at all useful ??
Reply-To: [EMAIL PROTECTED]
Date: 22 Mar 2001 00:08:35 -0600
On Wed, 21 Mar 2001 01:50:35 -0800, David Schwartz <[EMAIL PROTECTED]>
wrote:
>Tom St Denis wrote:
>> > Send me $125 and I'll send you my detailed report on the strengths and
>> > weaknesses of Evidence Eliminator.
>> Now why would I do that? :-?
> When I said "you", I didn't mean you. I meant those naive new users you
>were talking about. As many of them as possible.
Heheh. And even if it did work, I make it a point not to deal with
people with such dubious business policies (see my .sig).
--
Eric Lee Green [EMAIL PROTECTED] http://www.badtux.org
AVOID EVIDENCE ELIMINATOR -- for details, see
http://badtux.org/eric/editorial/scumbags.html
====== Posted via Newsfeeds.Com, Uncensored Usenet News ======
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
======= Over 80,000 Newsgroups = 16 Different Servers! ======
------------------------------
From: [EMAIL PROTECTED] (Eric Jacobsen)
Crossposted-To: sci.math,comp.dsp
Subject: Re: Fill-in-the-blank codes (similar to Error-correcting codes)
Date: Thu, 22 Mar 2001 06:22:22 GMT
Reply-To: [EMAIL PROTECTED]
On Wed, 21 Mar 2001 21:07:54 -0500, Bob Harris
<[EMAIL PROTECTED]> wrote:
>I'm looking for information on a topic similar to error-correcting codes,
>but I'm not sure if work has been done on this type of code, and if so, what
>it would be called in the literature.
>
>The idea is to have a code that includes two redundant bits, and be able to
>'correct' any two errors, with the additional knowledge of which two bits
>might be errant.
>
>For example, if I wanted to have a 7-bit code (2 of the bits are redundant),
>I might receive 0 0 x 0 x 1 0, where 'x' indicates missing bits. I need to
>be able to fill in the missing bits (which is why I called this 'fill in the
>blanks).
If the intent is to not even transmit (or store or convey, whatever)
the missing bits, then this is a "punctured code", where some of the
information has been intentionally deleted. If the idea is to always
transport all of the bits and be able to detect and correct errors,
then that is a slightly different situation.
It is indeed stretching things a bit to ask a system with only two
redundant bits to be able to detect and correct two errors. It is an
even bigger stretch to puncture two bits, add two bits of redundancy,
and expect *any* additional coverage in error detection or correction.
So, yes, you're asking a lot here.
Generally speaking, a block code like what you describe performs very
well if, with N redundancy bits added, it can detect and correct N/2
errored bits. This depends, of course, on the type of code, amount of
complexity you can tolerate, etc., but the point is that you are
having difficulty because you're asking a bit much.
>If only 1 bit can be missing then the problem is easy-- the single redundant
>bit is a parity bit (regardless of the number of message bits).
And a single parity bit only provides detection of single errors.
There is no correction capability, and if there are multiple errors
all bets are off.
> I've tried
>to solve the 2-bit problem, but have been unsuccessful.
I've always thought that one of the big problems with the world is
that there is entirely too much two-bit engineering being done
already.
> I can't even prove
>to myself whether it is possible or impossible. I understand the basics of
>algebraic codes, so I don't feel like I'm a total dimwit. On the other
>hadn, I feel like I oughta be able to crack this nut.
>
>Any help/pointers would be appreciated. I'm not looking for someone to
>solve the problem, just to point me in the right (or promising) direction.
This is a very difficult problem. You may want to look into such
topics as block codes (somebody mentioned Hamming codes, which is a
good start, and also look at things like BCH codes). If your intent
is to delete the bits in question, then compression algorithms are
relevant, and there is a lot of overlap in theory between compression
algorithms and error correction (or error control) codes.
Best of luck with this.
Cheers,
Eric Jacobsen
Minister of Algorithms, Intel Corp.
My opinions may not be Intel's opinions.
http://www.primenet.com/~ericj
------------------------------
From: [EMAIL PROTECTED] (Eric Lee Green)
Subject: Re: What the Hell...Here's what my system can do at it's best...
Reply-To: [EMAIL PROTECTED]
Date: 22 Mar 2001 00:22:34 -0600
On Wed, 21 Mar 2001 13:49:28 +0000, Keill Randor <donotreply@interbulletin.
bogus> wrote:
>>>"SCOTT19U.ZIP_GUY" wrote:
>>of an area. If they judge a person by the clothes they wear
>>or some certificate that says they know crypto. Then I guess
>>they don't desire to break real world crypto systems terroists
>>may use. Unless they think because of many terroist anti jew
[etc. etc. etc. it's all a conspiracy by crypto gods who don't
appreciate Scott's genius etc. etc. etc. same old same old]
>Hmmmm, sounds about right. Just wait and see if my system hits the
>'net. It's so simple at it's core, and inherantly uncrackable, so
>exactly what they'll make of it I'm not sure... I solved this problem
>from the ground up: I know that my last post was a little, well,
>convoluted, but as I said, that's what it does at it's best, which
>very few people will need, BUT it will always be possible that someone
>HAS worked out an alternative solution, and the one you have isn't the
>'real' one. It's ALL about trust, at the end of the day...
There is no shortage of unbreakable ciphers. Ciphers that are both secure
and which run in a reasonable amount of time, on the other hand, are
in shorter supply.
Unbreakable systems, on the other hand, do not exist except in very
limited circumstances. Every existing system has weak points. For
example, the security on Multics was for many years the strongest that
ever existed. By the time I'd been on the USL campus for six months
I'd already come up with three attacks on Multics that would gain
access to other people's files -- one "social attack" (i.e., treat a
sysop to a beer :-), one "email virus" attack which relied upon the
characteristics of the TVI-912 terminals that we used (specifically,
their ability to transmit data back to the mainframe when sent a
specific code sequence), and one "password harvester" which sat on a
terminal, spoofing the normal login screen, and harvested the password
of the next poor sod who attempted to log in. And remember: I was 17
years old at the time, and the first time I'd ever seen a computer had
been less than six months prior. I also came up with an attack which
allowed bypassing resource quotas by using the resources of another
account on the system, using a little widget I wrote that used a shared
segment, a semaphor, and a signal (alas, it has been far too many years
to remember the exact details).
Now, I'm not a master cracker. I'm not a master code breaker. I'm not
a "crypto god". I'm just a poor sod working guy engineer who spends
his days designing systems (and trying to figure out ways to break his
own systems). If I can find 3 1/2 cracks into an "unbreakable" system
that was largely designed by the Department of Defense within 6 months
of encountering a computer for the first time, I seriously doubt that
a system designed by a rank amateur is going to last any longer
against people who are REAL experts (which, as I said, is not me --
I'm quite painfully aware of my own limitations).
--
Eric Lee Green [EMAIL PROTECTED] http://www.badtux.org
AVOID EVIDENCE ELIMINATOR -- for details, see
http://badtux.org/eric/editorial/scumbags.html
====== Posted via Newsfeeds.Com, Uncensored Usenet News ======
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
======= Over 80,000 Newsgroups = 16 Different Servers! ======
------------------------------
From: Peter Engehausen <[EMAIL PROTECTED]>
Subject: Re: Strong Primes
Date: Thu, 22 Mar 2001 06:04:14 -0100
Reply-To: [EMAIL PROTECTED]
Dear Joseph,
Sorry, that you have to give me private lessons!
> Well it's actually fairly simple lambda(p)*k = lambda(N) where k depends on
> q, so proving it with respect to lambda(N) makes the use of lambda(p)
> unnecessary, because lambda(N) only supplies additional possibilities to
> build short cycles, the proof of cycles on lambda(N) also apply to those of
> lambda(p) (I would've thought that at least make that statement in the
> paper, but I didn't read it too carefully). This results in the proof with
> regard to lambda(p) being simply "by the proof on lambda(N)"
Okay. So we only have to look at ord (e) mod \lambda(N).
> The order of e mod p is relevant only in the selection of p and e, e must be
> prime relative to p (and p-1, both of which are easily confirmed), this
> makes the order maximal (by the original RSA proof of invertability) so
> there is no discussion that is necessary.
Yes. Surly e is coprime to p and p-1 (same with q). This is how e is choosen.
> It was basically a paper saving device, it was assumed that the reader would
> have a substantial basis in mathematics which would lead them to immediately
> see that lambda(N) implied lambda(p) implied p-1 implied several other
> things that weren't needed for understanding.
Seems I didn't made my homeworks! :) Well, if you have still time and nerves I
would like to ask you again: What does the order of e modulo p imply for the
order of e modulo p-1? Or for what reason does Mr. Silverman look at ord (e) mod
p at all?
> > PS: And I still don't understand this part:
> >
> > "Suppose r does not divide ord(e) mod \lambda(N). It follows immediately
> > that e must be an r-th power mod p. This follows form Lagrange's
> > Theorem: ord(e) must divide p-1, and we have assumed that r divides p-1
> > but r does not divide ord(e). Hence e must be an r-th power mod p."
> >
> > ord(e) mod \lambda(N) must divide p-1? I'm not sure if I remember
> > Lagrange's Theorem well... The order of a subgroup divides the order of
> > it's group. Hence for every e which is coprime to \lambda(N) the order
> > of e mod \lambda(N) must divide the order of (Z/\lambda(N)Z)^*. This is
> > \phi(\lambda(N)), isn't it? I can't see why ord(e) divides p-1...
> >
> > And further on: You say, if r and ord(e) divide both p-1 and r doesn't
> > divide ord(e) than e must be an r-th power.
> > Sounds obvious, but why? I'm still too blind to see through.
Thank you, Joseph!
Best regards,
Peter
------------------------------
Reply-To: "Brian McKeever" <[EMAIL PROTECTED]>
From: "Brian McKeever" <[EMAIL PROTECTED]>
Crossposted-To: sci.math,comp.dsp
Subject: Re: Fill-in-the-blank codes (similar to Error-correcting codes)
Date: Thu, 22 Mar 2001 07:08:30 GMT
"Bob Harris" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Howdy,
> I'm looking for information on a topic similar to error-correcting codes,
> but I'm not sure if work has been done on this type of code, and if so,
what
> it would be called in the literature.
>
> The idea is to have a code that includes two redundant bits, and be able
to
> 'correct' any two errors, with the additional knowledge of which two bits
> might be errant.
>
> For example, if I wanted to have a 7-bit code (2 of the bits are
redundant),
> I might receive 0 0 x 0 x 1 0, where 'x' indicates missing bits. I need
to
> be able to fill in the missing bits (which is why I called this 'fill in
the
> blanks).
>
> If only 1 bit can be missing then the problem is easy-- the single
redundant
> bit is a parity bit (regardless of the number of message bits). I've
tried
> to solve the 2-bit problem, but have been unsuccessful. I can't even
prove
> to myself whether it is possible or impossible. I understand the basics
of
> algebraic codes, so I don't feel like I'm a total dimwit. On the other
> hadn, I feel like I oughta be able to crack this nut.
>
> Any help/pointers would be appreciated. I'm not looking for someone to
> solve the problem, just to point me in the right (or promising) direction.
Hi Bob,
There is a fair amount of theory about what you are trying to do. The term
you are looking for is "erasures". The main theorem (whose name and author
escape me, as it's been quite a while) essentially states that erasures are
exactly half as hard to correct as errors. I take it that you are familiar
with the equation d >= 2t+1 that bounds the number of errors a particular
code is capable of correcting. Well, if s is the number of erasures, then
we have d >= 2t+s+1 (that is, errors count twice as much as erasures against
the total).
The hard part is designing a decoder that is able to take advantage of the
partial knowledge (that is, the position) that you get from erasures that
you don't get from errors. For this, I don't have any references, but what
you are trying is possible in theory (that is, at least a brute force search
over all possible codewords will work), and maybe you've got enough to go on
now?
Brian
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: What the Hell...Here's what my system can do at it's best...
Date: 22 Mar 2001 06:58:01 GMT
[EMAIL PROTECTED] (Eric Lee Green) wrote in
<[EMAIL PROTECTED]>:
>
>Unbreakable systems, on the other hand, do not exist except in very
>limited circumstances. Every existing system has weak points. For
>example, the security on Multics was for many years the strongest that
>ever existed. By the time I'd been on the USL campus for six months
>I'd already come up with three attacks on Multics that would gain
>access to other people's files -- one "social attack" (i.e., treat a
>sysop to a beer :-), one "email virus" attack which relied upon the
>characteristics of the TVI-912 terminals that we used (specifically,
>their ability to transmit data back to the mainframe when sent a
>specific code sequence), and one "password harvester" which sat on a
>terminal, spoofing the normal login screen, and harvested the password
>of the next poor sod who attempted to log in. And remember: I was 17
>years old at the time, and the first time I'd ever seen a computer had
>been less than six months prior. I also came up with an attack which
>allowed bypassing resource quotas by using the resources of another
>account on the system, using a little widget I wrote that used a shared
>segment, a semaphor, and a signal (alas, it has been far too many years
>to remember the exact details).
Every new engineer use to write password grabbers. But now adays
its considered bad form. I remmember some of the major weakness that
allowed access to the UNIVAC that could do much the same. Bad they
had to have specail names like ED I think any Univac system engineer
use to stumble on them. Especailly when you needed software to have
several seperated sessions open from same terminal.
>
>Now, I'm not a master cracker. I'm not a master code breaker. I'm not
>a "crypto god". I'm just a poor sod working guy engineer who spends
>his days designing systems (and trying to figure out ways to break his
>own systems). If I can find 3 1/2 cracks into an "unbreakable" system
>that was largely designed by the Department of Defense within 6 months
>of encountering a computer for the first time, I seriously doubt that
>a system designed by a rank amateur is going to last any longer
>against people who are REAL experts (which, as I said, is not me --
>I'm quite painfully aware of my own limitations).
>
Actually most so called systems desinged by the Department of
Defense where crap and secondly they were mostly put together
by over paid contractors taking Uncle Sam for a ride.
It really is how well you snow a manager as
to what gets put in so it no big deal to break or find such weaknesses
I use to find several breaks but the guy I worked with assured me
it only pissed management off when you show the errors and best to
let them dream there false dreams.
The sad fact is that to management any clown with a suit and
tie is an expert. Just charge a lot of money and act professional
then you can sell almost any crap you want to the FEDS.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
Scott famous encryption website **now all allowed**
http://members.xoom.com/ecil/index.htm
Scott LATEST UPDATED source for scott*u.zip
http://radiusnet.net/crypto/ then look for
sub directory scott after pressing CRYPTO
Scott famous Compression Page
http://members.xoom.com/ecil/compress.htm
**NOTE EMAIL address is for SPAMERS***
I leave you with this final thought from President Bill Clinton:
------------------------------
From: Paul Rubin <[EMAIL PROTECTED]>
Subject: Re: Advice on storing private keys
Date: 21 Mar 2001 23:19:58 -0800
Darryl Wagoner <[EMAIL PROTECTED]> writes:
> > I don't understand what you're asking. What needs to be special about
> > the certificates?
>
> The certs will carry unique information such as call sign and
> license class which may not fit well into normal certs.
This stuff fits just fine in normal certs.
> The other requirements is too have a format that will be easy for
> non-crypto types to add to their programs and to have a format that
> could easy be worked into text file formats. Standard certs maybe
> able to fit the bill, but I knew I could create my own format cert
> that would in less time.
Yes, but then anyone who wants to interoperate has to deal with your
weird format. Stick with standards.
> So far the only thing I don't like about the format is that it is
> hex strings. I wish I could find a good 64 bit encoding routines.
x509 already does this.
------------------------------
Date: Thu, 22 Mar 2001 09:24:13 +0200
From: Jyrki Lahtonen <[EMAIL PROTECTED]>
Crossposted-To: sci.math,comp.dsp
Subject: Re: Fill-in-the-blank codes (similar to Error-correcting codes)
Bob Harris wrote:
>
> Howdy,
>
> (I'm told it's good usenet ettiquet that when cross posting request replies
> be made only to one group; if you agree, please direct replies to sci.math
> only)
>
> I'm looking for information on a topic similar to error-correcting codes,
> but I'm not sure if work has been done on this type of code, and if so, what
> it would be called in the literature.
>
> The idea is to have a code that includes two redundant bits, and be able to
> 'correct' any two errors, with the additional knowledge of which two bits
> might be errant.
>
> For example, if I wanted to have a 7-bit code (2 of the bits are redundant),
> I might receive 0 0 x 0 x 1 0, where 'x' indicates missing bits. I need to
> be able to fill in the missing bits (which is why I called this 'fill in the
> blanks).
>
> If only 1 bit can be missing then the problem is easy-- the single redundant
> bit is a parity bit (regardless of the number of message bits). I've tried
> to solve the 2-bit problem, but have been unsuccessful. I can't even prove
> to myself whether it is possible or impossible. I understand the basics of
> algebraic codes, so I don't feel like I'm a total dimwit. On the other
> hadn, I feel like I oughta be able to crack this nut.
>
> Any help/pointers would be appreciated. I'm not looking for someone to
> solve the problem, just to point me in the right (or promising) direction.
>
> Thanks,
> Bob Harris
Sounds like you want to correct "erasures" as well as errors. Use that
keyword!
This can't be done with just two check bits (except in the trivial case,
where
your code is the repetition code of length 3). For a code to be able to
correct
t errors and e erasures, its minimum distance must be > 2*t+e.
Extending a decoding algorithm to correct erasures as well as errors is
not
trivial, but has been solved, e.g. for BCH-codes. If you don't mind
doubling
the time-complexity of the decoding algorithm then a trivial way to do
it is
to make two decoding attempts: for the first attempt replace all the
erasures
with zeros, for the second attempt replace all the erasures with ones.
In at least one of the attempts at least one half of the erasure were
"corrected"
by the replacement, and this is sufficient for the errors-only decoding
algorithm!
Hope this helps,
--
Jyrki Lahtonen, docent
Department of Mathematics,
University of Turku,
FIN-20014 Turku, Finland
http://users.utu.fi/lahtonen
tel: (02) 333 6014
------------------------------
From: [EMAIL PROTECTED] (Roy Hulen Stogner)
Crossposted-To: sci.math,comp.dsp
Subject: Re: Fill-in-the-blank codes (similar to Error-correcting codes)
Date: 22 Mar 2001 07:38:01 GMT
On Thu, 22 Mar 2001 06:22:22 GMT, Eric Jacobsen wrote:
>Generally speaking, a block code like what you describe performs very
>well if, with N redundancy bits added, it can detect and correct N/2
>errored bits.
This is true if you do not a priori know the locations of the errored
bits. If you know where some of the errors occur (call them erasures
in this case), then in the ideal case N redundancy bits let you
correct X errors and Y erasures where 2X+Y=N.
However, I don't think the ideal case occurs except for some special
block lengths. We used a 255 byte Reed Solomon block (being able to
use a 256 element finite field makes doing this stuff in software
relatively easy) which was such an "ideal" case. Anyway, the original
poster might want to add "Reed Solomon" to his list of search terms to
try.
---
Roy Stogner
------------------------------
From: Frank Gerlach <[EMAIL PROTECTED]>
Subject: Re: I was so so right about PGP ... so right when I started writing
Date: Thu, 22 Mar 2001 09:01:14 +0100
Mxsmanic wrote:
>
> "Frank Gerlach" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]...
>
> > Cryptographic devices and critical infrastructures
> > (routers, name servers, telephone switches, emergency
> > communications systems) should *not* be implemented
> > in a language, which defies runtime bounds checking.
>
> The choice of programming language used to develop cryptographic systems
> is irrelevant from a security standpoint.
Maybe from an academic point of view, but for all practical engineering
matters it is different.
If one can eliminate the possibility for one of the worst class of
security flaws, then it is a prudent engineering principle to go down
that path. Using a language with runtime bounds checking (e.g. Ada,
Java) is a way of doing that.
I basically do not care about somebody spying on sombody else, maybe
that is even good for international relations :-)
What I am concerned about is the fact that critical infrastructure could
be destroyed through software exploits. Eliminating one of the worst
class of flaws is definitely worth switching the programming language.
Check www.cert.org and search for "buffer overflow". Or read HP's
vulnerability warnings on comp.security.misc.
> You're half right: it's not sufficient. But it's hardly necessary,
> either.
Good academic statement; no practical relevance.
------------------------------
** 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
******************************
