Cryptography-Digest Digest #155, Volume #11 Fri, 18 Feb 00 21:13:01 EST
Contents:
Re: EOF in cipher??? (lordcow77)
Re: NTRU Speed Claims (100x faster, etc.), explained (John Myre)
Re: Does the NSA have ALL Possible PGP keys? (B Poulton)
Re: Keys & Passwords. (fvw)
Re: OAP-L3 Encryption Software - Complete Help Files at web site
([EMAIL PROTECTED])
Re: EOF in cipher??? (Jerry Coffin)
Re: Does the NSA have ALL Possible PGP keys? ([EMAIL PROTECTED])
Re: Question about OTPs ("r.e.s.")
Re: Does the NSA have ALL Possible PGP keys? (W A Collier)
----------------------------------------------------------------------------
Subject: Re: EOF in cipher???
From: lordcow77 <[EMAIL PROTECTED]>
Date: Fri, 18 Feb 2000 16:14:52 -0800
A compiler that does not obey the ISO C Standard is *not* a C
compiler in any real sense of the word. It is a program that
happens to compile a language that resembles C in many ways, but
which is most assuredly not (a comment that can be said about
many of Schildt's books, but that is a matter for another
thread). If you cannot depend on your compiler to uphold the
requirements of the C Standard in this one nonambigious, non
implementation-defined area, how can you rely upon it to compile
any code the way that you intended it to? For all you know, a
noncompliant compiler could easily have a function that
scribbles over your disk and call it printf().
* Sent from RemarQ http://www.remarq.com The Internet's Discussion Network *
The fastest and easiest way to search and participate in Usenet - Free!
------------------------------
From: John Myre <[EMAIL PROTECTED]>
Subject: Re: NTRU Speed Claims (100x faster, etc.), explained
Date: Fri, 18 Feb 2000 17:21:13 -0700
Mike Rosing wrote:
>
> John Myre wrote:
> > <snip>
> > In their example parameter sets, we have:
> >
> > (expansion) plain cipher
> > security N q p log(q)/log(p) bits bits
> > ----------------------------------------------------
> > moderate 107 64 3 3.8 170 642
> > high 167 128 3 4.4 265 1169
> > highest 503 256 3 5.0 797 4024
> >
> > (approximately)
>
> I think that's a bit too high. After asking Joe Silverman lots
> of dumb questions, he explained that you can get it down to 3:4
> plain:cipher ratio. Still, there's definitly expansion.
Where does my reasoning fail?
I.e., is it true, or not true, that the plaintext is a set of N
values modulo p? (If true, the plaintext has at most N * log(p)
information in it).
Is it true, or not true, that the ciphertext is a set of N values
modulo q? (If true, the ciphertext takes N * log(q) bits to
represent).
Is N different between plaintext and ciphertext? Or the same?
If the statements above are right, then the expansion is in
fact log(q)/log(p). Did I do the arithmetic wrong?
Did I use poor values for p and q? That is, maybe p can be a
lot bigger (closer in size to q) and the system still works?
(Maybe I even copied the numbers wrong from their web page?)
John M.
------------------------------
From: [EMAIL PROTECTED] (B Poulton)
Crossposted-To: comp.security.pgp,misc.survivalism
Subject: Re: Does the NSA have ALL Possible PGP keys?
Date: 18 Feb 2000 16:35:28 -0800
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Steve K) wrote:
>I just read most of this thread, and it's a very silly thread.
>
Agreed. I've been following it because I know little about it. Yet. In
conjunction with the original post I don't think this article is off topic.
(Note: This is *not* a slam against Americans. It's just that the study
groups were primarily American).
Incompetent people rarely know they are
By Deborah Zabarenko
WASHINGTON, Jan 20 (Reuters) - The truly incompetent may never know the
depths of their own incompetence, a pair of social psychologists said on
Thursday.
"We found again and again that people who perform poorly relative to
their peers tended to think that they did rather well," Justin Kruger,
co-author of a study on the subject, said in a telephone interview.
Kruger and co-author David Dunning found that when it came to a variety
of skills -- logical reasoning, grammar, even sense of humor -- people who
essentially were inept never realized it, while those who had some ability
were more self-critical.
It had little to do with innate modesty, Kruger said, but rather with a
central paradox: Incompetents lack the basic skills to evaluate their
performance realistically. Once they get those skills, they know where they
stand, even if that is at the bottom.
Americans and Western Europeans especially had an unrealistically sunny
assessment of their own capabilities, Dunning said by telephone in a
separate interview, while Japanese and Koreans tended to give a reasonable
assessment of their performance.
In certain areas, such as athletic performance, that can be easily
quantified, there is less self-delusion, the researchers said.
IGNORANCE IS BLISS
But even in some cases in which the failure should seem obvious, the
perpetrator is blithely unaware of the problem. This was especially true
in the area of logical reasoning, where research subjects -- students at
Cornell University, where the two researchers were based -- often rated
themselves highly even when they flubbed all questions in a reasoning test.
Later, when the students were instructed in logical reasoning, they
scored better on a test but rated themselves lower, having learned what
constituted competence in this area.
Grammar was another area in which where objective knowledge was helpful
in determining competence, but the more subjective area of humor posed
different challenges, the researchers said.
Participants were asked to rate how funny certain jokes were, and
compare their responses with what an expert panel of comedians thought. On
average, participants overestimated their sense of humor by about 16
percentage points.
This might be thought of as the "above-average effect" -- the notion
that most Americans would rate themselves as above average, a statistical
impossibility.
The researchers also conducted pilot studies of doctors and gun
enthusiasts. The doctors overestimated how well they had performed on a
test of medical diagnoses and the gun fanciers thought they knew more than
they actually did about gun safety.
So who should be trusted: The person who admits incompetence or the one
who shows confidence? Neither, according to Dunning. " You can't take them
at their word. You've got to take a look at performance," Dunning added.
--
bpoulton at vcn.bc.ca (Bob Poulton) Remove the 'trythis.' to reply.
(for Usenet only) (if I remember to stick it in)
And Lao-tse said: Those who know don't tell; those who tell don't know.
--
x
------------------------------
From: [EMAIL PROTECTED] (fvw)
Subject: Re: Keys & Passwords.
Reply-To: [EMAIL PROTECTED]
Date: Fri, 18 Feb 2000 19:56:07 GMT
In <[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote:
>Does someone happen to know a simple but not bad hashing program
>that converts a normal passphrase to {a-z, 0-9} or another set with
>elements that are human-friendly for input (and memory)?
Try md5sum, from the gnu textutils package. it can read your pw from stdin,
and spit out the md5 hash. (You'd probably still want to convert the hash
from hex to most of the ascii set...)
--
Frank v Waveren
[EMAIL PROTECTED]
ICQ# 10074100
------------------------------
From: [EMAIL PROTECTED]
Crossposted-To: talk.politics.crypto,alt.privacy
Subject: Re: OAP-L3 Encryption Software - Complete Help Files at web site
Date: Sat, 19 Feb 2000 00:53:47 GMT
> Prove to us your opinions are to be considered seriously.
>
> Considering the theory and operation of the software, prove to us
> why it is "garbage."
>
> Otherwise we will just have to consider you unprofessional,
> irresponsible, ignorant, and possibly stupid.
Serious cryptanalysis is a time- and resource-consuming task. Serious
cryptographers won't bother to spend so much effort on you program
because it doesn't even fullfill the simplest criteria of good encryption
software. Here are some reasons:
1.) The documentation is inprecise and confusing. So probably is your
algorithm and implementation.
2.) You have not published the source code of your encryption algorithm.
3.) Your documentation reveals that you are incapable of formulating an
algorithm in the usual way this is done in computational science. Even
basic programmers can formulate an algorithm in a simple pseudo-code or
PASCAL. Post your algorithm in the usual, comprehensible manner, and
people will take a look at it.
4.) In your recent posts you have only defended yourself without really
listening to the arguments of other posters. If you were confident and
sure about the security of your algorithm, there would be no reason to
act so.
5.) The "security levels" you're talking about in the documentation are
invented by you and do not comply to any standard that has been
established by the community of serious cryptographers.
6.) Your encryption algorithm and your implementation of it, as known,
has never been attacked in public cryptanalysis.
7.) You yourself have not described any attack on your algorithm, nor are
you known to have published any attacks on other encryption algorithms,
and therefore you cannot prove that you have any cryptanalytic skills.
8.) In the documentation, you do not even reveal which PRNG you use or
have invented.
That's why people consider you program to be crap.
Greetings,
Erich Steinmann
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Jerry Coffin <[EMAIL PROTECTED]>
Subject: Re: EOF in cipher???
Date: Fri, 18 Feb 2000 18:16:25 -0700
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] says...
[ ... ]
> However, there exist machines with C compilers that were once standard, but are
> no longer. Certainly, if you buy a new compiler you should expect to find it
> in conformance with recent changes to the standard (C99 may be a little young
> though).
This is true but irrelevant to the discussion at hand -- this part of
C hasn't changed at all between standards. I can't say my memory's
good enough anymore to say with certainty that there was never ANY
pre-standard compiler that produced negative numbers for real inputs
(as opposed to EOF or other error indicators), but if there ever was
such a thing, it was certainly EXTREMELY obscure -- if you're doing
ongoing development and have ANY choice at all, you're almost
certainly better off finding a reasonably up-to-date compiler rather
than deal with such an ancient monstrosity.
> However, the fact that standards change does not mandate changes to existing
> software or software tools. Indeed, such changes are anathema to a mature
> system. So once-conforming software may be deprecated or worse. But the
> programmer is still responsible for getting the machine to behave correctly.
> That means programming defensively.
To some extent true. It's easy to got overboard though: in some
cases, the benefits of updating the compiler are too large to ignore.
Replacing something as ancient and poorly designed as you're
postulating will provide pay for the work of a switch-over very
quickly.
> Making any kind of unnecessary assumptions about the platform, hardware or
> compiler, is the opposite of defensive programming. Advising programmers that
> they can rely up compiler to adhere to standards is to advise them that
> defensive programming is unnecessary. This is "bad C advice".
Nonsense. Relying on strange and obscure parts of the standard that
very few people understand is one thing. Relying on parts that are
very clear and everybody who knows C reasonably well at all has been
aware of for a decade or more is a whole different story. If you're
going to try to defend against a compiler this bad, you might as well
also advocate that nobody use "short" because BSD didn't support it,
that no floating point be used at all since quite a few early
compilers eschewed it, that type-casting shouldn't be used because it
wasn't supported until the compiler that came with UNIX V7, and so on.
> This distinction only applies reliably at the level of the standard, and not at
> the level of the compiler. The compiler you are given is what it is.
> Expecting it to be what you want it to be is to indulge in fantasy. Relying
> upon that fantasy is foolish.
>
> Now we have to rely upon most features of our tools. But we need not place
> unnecessary reliance on features of the tools that are reasonably subject to
> doubt. Kernigan & Pike address this in their recent book "The Practice of
> Programming". They use the phrase "programming in the mainstream" as a way to
> improve the reliability of software. A small quote:
>
> "Use only those features for which the language definition is unambiguous and
> well understood. Such features are more likely to be widely available and to
> behave the same way everywhere. We call this the mainstream of the language."
An irrelevant observation: the minor detail that YOU are ignorant
enough of the language that weren't aware of this requirement has
nothing to do with the fact that the world at large has known it for a
decade, and you'd be hard-put to find anything approaching a modern
compiler that did this wrong.
If you really do have to support such a monstrosity, allow me to
recommend Comeau Computing and/or Dave Dunfield as excellent sources
of C compilers that will be SUCH tremendous upgrades that they'll pay
for themselves in less time than it's likely to take to order them.
Comeau produces a VERY minimal version of C as its output, so if you
can write anything for your compiler and call it C at all, chances are
the compiler will also digest what Comeau produces. If you're working
with tiny machines (mostly 8-bit micro-controllers) Dave Dunfield
produces what he calls Micro-C. As the name implies it's not a full-
standard C compiler, but it's clearly a lot closer than the garbage
you're postulating.
> But a strict reading of 7.9.7 indicates that the following is valid:
>
> int c;
> while ( (c=getchar() ) < 0 )
> putchar( /* something about c */ );
Well, no, I don't think so. I think you intended that to be a ">"
instead of a "<" in the comparison. Once this is corrected, even the
most casual reading makes it _extremely_ obvious that the code is
correct.
> But IM(NS)HO this is quite far from the "mainstream" of C. Not only because it
> is a marginal interpretation of the standard, but also because it replaces a
> very strong C idiom regarding character input and EOF.
This is NOT a marginal interpretation of the standard at all. It's a
clear and obvious statement in the standard that requires not a single
bit of "interpretation." Both Doug Gwyn and I (as well as Nick
McClaren) spend a fair amount of time and effort in comp.std.c
pointing out areas of the standard that are open to interpretation and
may lead to surprises. Those same parts are likely to be wrong in
quite a few implementations. This just isn't one of those parts.
--
Later,
Jerry.
The universe is a figment of its own imagination.
------------------------------
From: [EMAIL PROTECTED]
Crossposted-To: comp.security.pgp,misc.survivalism
Subject: Re: Does the NSA have ALL Possible PGP keys?
Date: Sat, 19 Feb 2000 01:25:11 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> On Thu, 17 Feb 2000 12:01:12 GMT, [EMAIL PROTECTED] wrote:
>
> >> >- It is reasonable to assume that the NSA is able to run very fast and
> >> >exhaustive dictionary attacks against the passwords that secure the
> >> >private key.
> >>
> >> That's not quite the same thing as breaking the cipher, is it?
> >> If they wanted to do that, why would they bother generating
> >> and storing all the keys.
> >
> >Well, I'm not sure if you've read my answer carefully. I was pointing out
> >to the original poster, that it's quite senseless for the NSA to generate
> >and store all keys (even if it was possible), just because they can
> >obtain *used* keys easily by side-channel attacks.
>
> Yes, of course. Very much more cost-effective than trying either to
> break the cipher or discover the key by technical means.
No, it's actually cheaper. Trying to break the cipher is more cost-
effective than obtaining the keys actively in use. Creating viruses and
trojan horses is cheaper than cryptanalysis.
> >> >- It is reasonable to assume that the NSA is able to obtain any private
> >> >key stored on the harddisk of any individual at home, if he/she is the
> >> >specific target of an attack.
> >
> >> Only by forcing a weak passphrase, or getting the suspect to reveal
> >> it.
> >
> >No, this is absolutely wrong. It is easy to obtain the passphrase by
> >installing a keystroke logger or by using Van Eck devices, and it's easy
> >to obtain the private key by all different kind of means from physical
> >access to the harddisk to Trojan horses / viruses.
>
> Well no. Not 'only by forcing etc.' as you pointed out.
I didn't speak about "only by forcing", it was you who said that. Just to
be picky...
> So they're going to plant one of these on the computers of 'most PGP
> users' ? Ambitious project!
As I've made clear, this is not an ambitious project. If for some reason
'social engineering' wasn't appropriate, I'd consider an attack by
viruses/Trojan horses, because it's easier and cheaper than
cryptanalysis.
Regards,
John Stone
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: "r.e.s." <[EMAIL PROTECTED]>
Subject: Re: Question about OTPs
Date: Fri, 18 Feb 2000 17:45:39 -0800
There must be more to it than that, surely,
else just about any homophonic cipher would
be "ideal".
?
--
r.e.s.
[EMAIL PROTECTED]
"Bryan Olson" <[EMAIL PROTECTED]> wrote ...
[...]
: In fact that's Shannon's distinction between
: "ideal" and "perfect" secrecy. Ideal means that
: the plaintext does not uniquely determine the
: the ciphertext, while perfect means the ciphertext
: carries zero information about the plaintext.
------------------------------
From: W A Collier <[EMAIL PROTECTED]>
Crossposted-To: comp.security.pgp,misc.survivalism
Subject: Re: Does the NSA have ALL Possible PGP keys?
Reply-To: [EMAIL PROTECTED]
Date: Sat, 19 Feb 2000 01:51:00 -0700
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
says...
> Considering recent reports indicate that we destroyed every museum piece the
> Yugo army had and what were essentially card board cutouts ( or inflated
> tank mockups?) of tanks and armor our forward observes did a great job and
> JSTARS was worth every penny. Talk about smart bombs.
Actually, we had better intel in the Gulf - simply because we were not as
worried about politically sensitive collateral damage. Also, we did have
FO's on the ground for weeks before the air campaign in the Gulf. We had
few if any in former Yugo. THere are other notable differences as well
if you weren't so close minded as to be ignoring them. There is a thing
call the Fortress of Ignorance postulated in the middle ages - perhaps
St. Thomas Aquinas. You appear to be a practitioner.
You still don't get it do you? You have been called for talking out your
ass and cant squirm loose- because you are quite simply wrong, the facts
do not support your arguments, despite the lame attempts at invoking
faith as being equal to reason (it isn't its inferior - all the faith in
to world didn't make the world the center of the solar system, despite
Christianity's proclamations and heretic burnings. And then theres the
classic evasion technique most people losing an argument attempt: trying
to change contexts without accounting for the differences (Gulf war
crypto intel vs Yugo). You dont even know what traffic analysis is do
you? Yet its one of the fundamental techniques used to assist
cryptographers and intelligence efforts.
In other words Tiwolf, go back to church and pray your for a crypto
break, then bring it out to show the world. Otherwise, you are making as
much sense depending on a god for this as you would be the Tooth fairy.
> W A Collier wrote in message ...
> >In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
> >says...
> >> As a follow up to this, there have been occasional mentions in the
> >> press both throughout the Gulf conflict (not the Desert Storm one but
> >> the later missile launches...) and during the Nato bombing of Kosovo
> >> referring to interception and decryption of `bad guy' communications
> >> by the allies. In some cases specific mention has been made of
> >> `decryption' ...
> >>
> >> [Sorry I can't provide citations right now...]
> >>
> >> I'm curious, if PGP and similar widely available freeware and
> >> commercial packages are so secure why aren't the Iraqis, Serbs, etc
> >> etc using them?
> >>
> >> Of are they using them and we are still cracking them?
> >
> >They were using what they wre trained on and had paid for: Good used
> >(compromised) Russian crypto gear from the early 1970's. They spent
> >their modernization on planes and tanks, not on logistics and commo
> >(C3I). Consequently, thats where we attacked and crushed them: C3I and
> >logistics. Aside from that, traffic analysis (somethein that famous
> >agency is quite good at) combined with Radio DF and satellite and JSTARS
> >imagery, and adding in decent HUMINT (Special forces and cavaly scout and
> >Marien Recon forward sections) can paint a very good picture of an enemy,
> >his forces, their dsiposition and probable intent - without much or any
> >crypto breaks.
> >
------------------------------
** 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
******************************
