Cryptography-Digest Digest #298, Volume #10 Wed, 22 Sep 99 21:13:03 EDT
Contents:
Re: Securing Executables ("Trevor Jackson, III")
Re: Homophones (Matt Gibson)
Re: frequency of prime numbers? ("Trevor Jackson, III")
Re: (US) Administration Updates Encryption Export Policy ("Trevor Jackson, III")
Factoring arbitrary numbers ([EMAIL PROTECTED])
Re: msg for Dave Scott ("Rick Braddam")
Re: signature help with s/mime ([EMAIL PROTECTED])
Re: RSA 640 bits keys factored, French banking smart card system craked! ("Laurent
PELE")
Re: RSA 640 bits keys factored, French banking smart card system (Ted Kaliszewski)
Re: Factoring arbitrary numbers (Ted Kaliszewski)
International crypto restrictions (Scott Hardy)
Re: some information theory (very long plus 72K attchmt) (James Felling)
Re: RSA 640 bits keys factored, French banking smart card system craked! ("Laurent
PELE")
Re: Second "_NSAKey" (Greg)
Re: EAR Relaxed? Really? (Greg)
Re: EAR Relaxed? Really? (Greg)
peekboo 1.5 is out (fixes and such) (Tom St Denis)
----------------------------------------------------------------------------
Date: Wed, 22 Sep 1999 17:24:18 -0400
From: "Trevor Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: Securing Executables
jerome wrote:
> it depends the level of security you want.
> if the attackers can run the application (through a debugger or not)
> it mean it can read the code and modify it to do whatever they want.
>
> i dont understand what you try to do. explain clearly your aim
>
> >1. Use something like SHA-1 to check the exe at load time for tampering.
> >2. Check with SHA-1 periodically as the client is running.
>
> how to do prevent the attacker from simply recomputing the message digest ?
>
> >3. Can we check we're running inside a debugging environment and crash out?
>
> even if you can, you don't prevent any offline modification
>
> >4. Compress and encrypt local data files
>
> where do you store the key ? on the local drive ? not hard to find :)
>
> all that looks a lot like the tricks used by game coders a long time ago
> to prevent the crackers to copy or modify their softwares.
> Each time the gamecoders loosed badly because it is easy to modify the
> executable just to avoid to do the test.
Some lost, some won. Like all defensive measures you have to assess the threat
and the economic justification for the strength of the defenses. Some threats
are easy to defeat (cat >lpr), while others are extremely hard to defeat. Any
given set of defenses can be overcome eventually. But there's easily
justification for useful non-trivial defenses.
------------------------------
From: [EMAIL PROTECTED] (Matt Gibson)
Subject: Re: Homophones
Date: Wed, 22 Sep 1999 21:51:22 +0100
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
says...
> Hey there!
>
> Does anyone have any information/can point me in the direction of some
> good information, regarding the decryption of a monoalphabetic cipher
> with homophones?
Oooh, someone else is reading The Code Book. Are you planning on sharing
the money as well as the work?
M
--
"It's the gaps between the rain that count,
and learning how to live amongst them"
-- Jeff Noon, _Pixel Juice_
Matt Gibson http://www.gothick.dial.pipex.com
------------------------------
Date: Wed, 22 Sep 1999 17:01:42 -0400
From: "Trevor Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: frequency of prime numbers?
Patrick Juola wrote:
> In article <[EMAIL PROTECTED]>,
> Trevor Jackson, III <[EMAIL PROTECTED]> wrote:
> >Boris Kolar wrote:
> >
> >> Bob was right. There are true statements that can't be proved. One of such
> >> statements is "This axiomatic system is consistent" (for some axiomatic
> >> systems). Obviously it can be either true or false. But if the axiomatic
> >> system is rich enough, the statement can't be proved.
> >
> >In what sense is the statement true then?
>
> Well, the system either *is* consistent, or it isn't. It's just
> not possible to prove the consistency within the system. It may
> be possible to prove (or disprove) consistency using a large
> system.
>
> First-Order-Logic has, for instance, been *proved* consistant (Godel's
> first significant theorem). But he didn't restrict himself to
> FOL in performing the proof.
So truth is context-dependent. The issue that started this line of throught was
whether there can be unprovable false statements within a system. Now a trivial
line of thought is that the inverse of an unprovable true statement must be
unprovably false.
Here I'm using the slippery context-dependence by which provability is evaluated
within an axiomatic system (intrinsic property) while truth value is known from
outside the system (extrinsic property).
Is there a fundamental inequality that asserts unprovable true statements cannot
be negated?
------------------------------
Date: Wed, 22 Sep 1999 17:16:41 -0400
From: "Trevor Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: (US) Administration Updates Encryption Export Policy
Patrick Juola wrote:
> In article <7s8h7v$9i1$[EMAIL PROTECTED]>,
> Bill Unruh <[EMAIL PROTECTED]> wrote:
> >In <[EMAIL PROTECTED]> [EMAIL PROTECTED] (Jerry
>Coffin) writes:
> >
> >]Third, the primary reason for finding the regulations unconstitutional
> >]was the lack of ability to appeal a decision. The same basic
> >]regulations on export itself could apparently be made constitutional
> >]simply by providing a better process for appealing a decision.
> >
> >]Finally, note that the Bernstein case revolved around the use of
> >]source code as a method of communication between people, so there was
> >]a restriction on the right to free speech. If, for example, you write
> >]source code like Dave Scott's, which nobody can read, that argument
> >]obviously goes out the window. To export source code in accordance
> >]with this decision, you could be called upon to prove that the
> >]_primary_ reason for using source code was simply to provide an
> >]unambiguous method of communicating with another person. If the
> >]primary reason for the source code is to provide for a computer to
> >]take certain actions, it's unlikely that this decision would apply.
> >
> >No. Your speech does not become less protected just because people find
> >difficulty in understanding you.
>
> Legally speaking, it's not a quesiton of ease of understanding, it's a
> question of communicative intent. That's why, for example, there
> are certain restrictions on "commercial speech" (such as advertising)
> that would not be allowed on "political speech." This particular
> distinction is well-accepted in (U.S.) case law and you're unlikely
> to get it overturned no matter how many lawyers you paid.
>
> Dr. Bernstein is in a rather unusual position in that he is researching
> new cryptographic techniques which he then wants to communicate *to other
> researchers* (publish or perish, what fun!) So his intention is
> human-to-human communication, not human-to-computer.
>
> In general, publishing source code for a software package can easily
> be argued not to be "communicating" with other humans; I don't know
> *how* many programs I've compiled without ever looking at the source.
> The law is capable of recognizing the distinction and acting upon it,
> as much as we might wish to the contrary.
But if A is inside the US and B is outside, A does not send his source code to B's
computer. His
object code, perhaps but not his source code. His source code is aimed at B; who will
be the
intended recipient of the message.
This can be made arbitrarily inarguable by damaging compilable source code in a
systematic way
until no existing compiler could do anything useful to it.
Of course B could do something useful with it. Correct it, understand it, modify it,
even
compile it. In fact Djikstra made the point over 20 years ago that we do not write
programs for
computer/compilers. The proper target for a software developer is other software
developers.
Yes, you can compile source without looking at it. And you can eat food without
looking at it.
But the appearance of food is a critical property (we just don't have pretty printers
for it);
ask any chef. The point is that because a receiver _can_ compile it is not
presumptive that it
is the intent of the trasmitter that the receiver do so.
The receiver could also hash it and use it as a key for 3DES. Should we ban all
international
file transfers because they can be used in (objectionable) manner? Hardly.
------------------------------
From: [EMAIL PROTECTED]
Subject: Factoring arbitrary numbers
Date: Wed, 22 Sep 1999 22:24:19 GMT
Hi,
I'm writing a program that factors arbitrary numbers. I've heard of
the following algorithms:
Brent-Pollard method
Pollard's (p-1) method
William's (p+1) method
Lenstra's elliptic curve method
Pomerance-Silverman-Montgomery multiple polynomial quadratic sieve
Can someone refer me to a website or some good math textbooks that
contain these formulas and theories?
Thanks in advance,
Dennis
=-=-=-
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: "Rick Braddam" <[EMAIL PROTECTED]>
Subject: Re: msg for Dave Scott
Date: Wed, 22 Sep 1999 15:02:41 -0500
Tom St Denis <[EMAIL PROTECTED]> wrote in message
news:7sagud$4ad$[EMAIL PROTECTED]...
> Well you say you can break all encryption methods and systems. Prove it.
>
> And if you can't break peekboo, then I think you shut up, cuz I am just a
> kid, and if I could make peekboo imagine what wonder Comp sci majors and
> crypto 'gods' could do....
>
> (btw if anyone else reads this thread and thinks I am a jerk now can you do
> something usefull and makesure that the dh generator is actually a proper
> one. I was told by some people in this group it's ok....)
>
> Tom
I don't know that you _are_ a jerk, but you sure sound like one. Reminds me of when I
was 17 years old and knew everything, had all
the answers, and everything I made was of earth-shattering importance. Now I don't
know anything, don't have any answers, and my
most important accomplishments are my three sons; the youngest of which is 5 years
older than you are.
Now I'll go back to doing something useful and ignoring your flaming. It just got
really tiresome.
Rick
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: signature help with s/mime
Date: 22 Sep 1999 19:53:55 GMT
>Given an S/MIME clearsigned message, I know this: I need to:
>
>1) Run the message through a MIME parser
>2) base64decode the result
>3) extract the signature and the message from the result
>Now - let's say I've done that already. How do I verify the signature
>(PKCS#7)?
In a clearsigned S/MIME message, the message cleartext is not part of the
PKCS7 SignedData blob, it's in a separate MIME part (by clearsigned, I
assume you mean MIME multipart/signed).
Here's the process to check the signature on a clearsigned message:
* Decrypt the signature part of the signature block, yielding a digest.
* Compute a digest on the DER of the authenticated attributes block (of
the PKCS7 SignedData). (warning! the attibutes are usually DER, but it is
not required. You may have decode/recode the authenticated attributes in
DER) This must match the digest produced by decrypting the signature
block.
* Digest the cleartext message. (This can be tricky since you must get
the message string bit-for-bit exact)
* The authenticated attributes contain an attribute for the digest of the
cleartext message. Compare your digest of the cleartext message with the
one found in the authenticated attributes.
* If all has gone well, the signature is cryptographically valid. (Now
you have to affirm trust in the public key...)
The proceedure is slightly different if you've got an opaque signature.
Here's where you can get some specs..
http://www.imc.org/ietf-smime/
------------------------------
From: "Laurent PELE" <[EMAIL PROTECTED]>
Crossposted-To: alt.security.pgp
Subject: Re: RSA 640 bits keys factored, French banking smart card system craked!
Date: Thu, 23 Sep 1999 01:51:24 +0200
Paul Rubin <[EMAIL PROTECTED]> a �crit dans le message :
7s9gp0$[EMAIL PROTECTED]
> In article <7s9esj$g33$[EMAIL PROTECTED]>,
> Laurent PELE <[EMAIL PROTECTED]> wrote:
> >A French engineer has cracked the French
> >banking credit card system based on smart card last year, he has achieve
> >that by factoring a RSA public key of 640 bits that is a factor of two
> >prime numbers of 320 bits.
> >
> >As far as we know, this is the largest number factored in the world.
> >
> >According to him, the 640 bits factor had special properties and used
that
> >properties to factor the number.
> >see at http://www.pele.org/smartcard.htm
>
> This page and the links from it that I looked at are very vague about
> what Humpich did. At one place he said that the number had special
> properties that are hard to find. I'm skeptical of the whole claim
> that the French banking system used a 640 bit RSA key that anyone
> could factor by mathematical means. I wonder if the factors were
> embedded in the smart card, and Humpich got them out with a hardware
> or protocol attack.
No because, Humpich can make different false smartcards and change them as
he like.
He didn't find any leak in the protocol, he didn't have any other choice to
factor the key, it is said in the 2 pages interview in PirateMag September
magazine in French.
He did factored a 640 bits number, he sent me an email to confirm it.
But the french smartcard was originally designed in 1983 with 320 bits RSA
keys but have been improved after before the use in practice of the chip on
the card in 1993. I've got articles of researchers involved in smartcard
design dated of 1988 and 1991 saying that the 320 bit key was not more
secured so banks increased the key size.
In 1993, merchants started to use point of sales terminals. So the 640 bits
RSA key is about 10 years old, and it cannot be change unless you change all
the point of sales terminals (cost about 5 billions dollars).
According to Jean-Jacques Quisquater, belgian researcher in math and
cryptography (that participate to such study in smartcards), it is quite a
challenge to have numbers that are strong to all elliptic curves after 10
years.
In fact, points of sale terminals will be changed, to comply with the new
currency - the euro - that will be used by everyp eople in 2002 (now we can
both use French Franc or the Euro). The euro version of smartcard is said to
be more secured and it is said of the web site of GIE Cartes Bancaires, the
increase in security is absolutely needed !
Of course they know since one year that somebody cracked their system (but
we only know it in june, all the whole details are still secret because of
the suit and because of banks that don't want anybody to talk about it and
Serge Humpich that was suppose to sell his secrets).
But the 640 bits number had special properties, as Humpich told it.
It means probably that there is a special modulo, and it can be attacked
with method based on elliptic curves.
It is a factor of two numbers of 320 bits exactly, each of them are not far
of the square root.
He said that he used latest methods to factor the number with a japanese
software.
He setup the software to take account of the properties of the 640 bit
number.
He also entered probabilities about the prime numbers (for example maybe he
tried the prime number around the factor/3 because he think maybe the banks
chose a prime number that is about twice more than the first one and didn't
use a random number generator).
I mean that generally researchers are not involved in the prime numbers
choice. The litterature at that time only said that the factor should be
like (8A+3)x(8B+7) where 8A+3 and 8B+7 are two prime numbers.
He also said that prime numbers of 320 bits long are quite rare,
maybe there are even less numbers with this special properties around the
scale he tried.
Humpich is not a researcher in cryptography and do not know all the theory
about it but the fact is that an individual can crack difficult
cryptographic system and keys by setting up correctly dedicated softwares.
He's an engineer, I'm also an engineer, and I learnt at school the orginal
cryptographic scheme used in smartcard, so some of the information was
publicly available. it evoluate a bit since (key evoluate from 320 bits to
640 bits). He reverse engineered the system to understand the identification
scheme and factored the public key.
So the fact is that some individuals can attack some cryptographic systems,
maybe with some chance, maybe also with a leak in the prime number
generation but also after much work (4 years !)
French banks has done a fault, because, instead of increasing the size of
the key, they should have change the protocol. Because zero-knowledge
protocols (like the Fiat-Shamir scheme) was available in 1991 and smartcards
should be based on such protocol before massively use smartcard in point of
sale terminals since 1993.
--
Laurent PELE 13 rue Lantiez 75017 PARIS
T�l/Fax +33 1 40 25 08 50 mob + 33 6 08 21 96 69
mailto:[EMAIL PROTECTED] http://www.pele.org
Online currency converter on http://195583.com
------------------------------
From: Ted Kaliszewski <[EMAIL PROTECTED]>
Subject: Re: RSA 640 bits keys factored, French banking smart card system
Date: Wed, 22 Sep 99 19:50:41 -0500
Allow me a modicum of inmodesty but I posted in this forum factorization
of a RSA-like moduli of 640 and 782-bit size. Both were of a special
construction, one a psp and the other having a large gcd(p-1, q-1). Thus,
factoring such numbers is especially hard provided that some clue as to
their "specialty" can be found.
------------------------------
From: Ted Kaliszewski <[EMAIL PROTECTED]>
Subject: Re: Factoring arbitrary numbers
Date: Wed, 22 Sep 99 19:35:28 -0500
Good and simple accounts of the principal factoring methods are not readily
found, except in scattered journal articles. Your best bet is to look up
Riesel's book, perhaps the new edition, on Prime Numbers and Computer
Methods for Factorization. The version that I know was published in 1985.
------------------------------
From: Scott Hardy <[EMAIL PROTECTED]>
Subject: International crypto restrictions
Date: Wed, 22 Sep 1999 23:23:55 GMT
I was thinking of writing an algorithm using
a 64-bit key which took a LOT of CPU time
(probably a couple hundred mS on a fast PC)
generating several KB of sboxes and subkeys
from that 64-bit key, thinking that it would
give a modicum of security to those who had to
make do with short keys.
I was then informed that Blowfish was only allowed
to be exported from the US with a 32-bit, rather
than 40-bit key, presumably because of its
behaviour along these lines. So, my question is
this: since I can code it outside of the US, is
this a viable idea, or are there many other
countries which limit algorithms based on subkey
generation time?
Thanks,
Scott
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: James Felling <[EMAIL PROTECTED]>
Subject: Re: some information theory (very long plus 72K attchmt)
Date: Wed, 22 Sep 1999 16:26:48 -0500
"SCOTT19U.ZIP_GUY" wrote:
> In article <[EMAIL PROTECTED]>, James Felling
><[EMAIL PROTECTED]> wrote:
> >
> >Rick Braddam wrote:
> >...
>
> >>
> >> David Scott promotes using compression before encryption, and several
> > responses have agreed with him. If I understand correctly,
> >> compression doesn't increase security, but it increases the work factor
> > needed to break the encryption. Why isn't that the same as
> >> increasing security? "Increase the work factor" should be the same as "makes
> > it harder" to break the encryption... isn't that what
> >> increasing security means?
> >
> >Not really. Lets say I want to conduct an attack on your encryption. I know
> > that you use compression method X. Further I know that
> >your messages have some common starting feature(enough after compression to be
> What if you don't know the starting text.
In that case, you are correct. But what I was pointing out is that there are cases
where compression before
encryption does NOT increase the work factor and therefore compression cannot be said
to universally benefit its
users.
> The problem with non "one to
> one" comp is that they are weak even if the starting portion of the FILE
> is not KNOWN. You sir seem to think one always has the start of the
> file encrypted that is not necessarily true. What I showed is that non "one to
> one" compression weakens the compression followed by encryption even if
> there is no information about the input file.
Where is this demonstrated?
I have seen no such proof. All I have seen is you claiming that this is so.
>
> > a block or two of encyphered text, or can submit a
> >limited amount of known plaintext.
> >I can then use the compressed feature / compressed known text as the plaintext
> > recognise decoded plaintext -- thus the work factor for
> >some attacks is NOT increased. An increase in security means under any
>
> Your worng the WORK FACTOR Is increased.
Not in all cases. Assume that I send a message M with this method. What is sent is
C=Encrypt(Compress(M),with
key K), now if I find out that the message C that I intercepted was the out put from
message M, I will know that
decrypt(C, with key K)= Compress(M) if K is the actual key used.
Thus I precompute Compress(M) and use that as the plaintext to be recognized.
The amount of added work in this case is trivial.
> Also your assuming weak
> encryption methods like AES where if the key is the same the front of
> file the same the encrypted text is the same. This is common in crypto systems
> since it helps the NSA break systems.
I disagree, but you are welcome to beleive what you want
> You can't do the same if an "all or
> nothing" type of encryption like scott16u or scott19u.
Or any one of several other all or nothing algorithims. Just one question. Why is
your method superior to other
all or nothing algorithims that instead of using your code use AES or related routines?
> But if you do use
> weak AES methods you could take my advice at
> (http://members.xoom.com/ecil/compress.htm) site for using
> a reverse huffman pass through the file and a common front of
> a the starting file will mean very little
>
>
> > circumstance the work factor goes up. The big benefit of
> >compression is that instead of 1 meg of raw encoded cypher text the adversary
> > gets 100K of encyphered text -- much less material to
> >analyze and draw conclusions from.
> >
> >Similarly by creating apropriately massaged plaintexts known plaintext attacks
> > may still be carried out -- it just takes a little
> >precomputation on the adversary's part.
> So I guess that means you would rather use a compression method
> where the attacker does not need to slip in plain text for an attack.
> I personnel think that giving some the info to break an encryption
> for free is a big mistake. But you think that it is ok.
That is a misstatement of my position. All I am saying is that in some scenarios the
compression will NOT
improve the security. In many cases it will work to add security, but it does not
DIRECTLY increase security.
It is a good thing to do. It makes it more difficult to break in a unknown plaintext
scenario, and reduces the
amount of data available to the analyst. However, it in and of itself adds no
security versus some modes of
threat.
>
> >
> >> Maybe it's relative, in that it doesn't make it substantially harder like
> > adding one bit to the key
> >> would.
>
<Big lup of technical info SNIPed>
------------------------------
From: "Laurent PELE" <[EMAIL PROTECTED]>
Crossposted-To: alt.security.pgp
Subject: Re: RSA 640 bits keys factored, French banking smart card system craked!
Date: Thu, 23 Sep 1999 02:01:36 +0200
Mok-Kong Shen <[EMAIL PROTECTED]> a �crit dans le message :
[EMAIL PROTECTED]
> It may be of interest to note that sometime ago in this group
> someone asked whether it could be dangerous to his life if he
> succeeded and announced the factoring of a very huge number.
> (Whereupon I replied that I would venture to do the announcement
> for him in my name, though I see some difficulty of handing over
> the prize which is paid out to me to him.)
Now, Serge Humpich is continuously followed by people from the secret
agencies.
In fact, he didn't negociate directly with the banks last year, he was
represented by his lawyer, and his name has been found by comparing the
telephone bills of the lawyer and the list of people that has deposit a
patent in that period.
Now there are very big pressure on him not to reveal the secret, some TV
programs have been censored...
But there is nothing in the French law that forbid to reveal that secret (it
is just forbidden to use false card, he just did it after the banks ask him
to do it and prove what he said).
--
Laurent PELE 13 rue Lantiez 75017 PARIS
T�l/Fax +33 1 40 25 08 50 mob + 33 6 08 21 96 69
mailto:[EMAIL PROTECTED] http://www.pele.org
Convertisseur euro et multi-devises sur http://655957.com
------------------------------
From: Greg <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto
Subject: Re: Second "_NSAKey"
Date: Thu, 23 Sep 1999 00:34:11 GMT
> > > Occam's razor indicates that we need not invoke any dark
> > > agencies in order to explain the facts available.
> > Uh Hmmmm.. I would disagree here. The NSA is the MOST viable
> > suspect to consider since it must sign off on any export license.
> > This would be far too convenient NOT to ask for a key of their own.
> If you want to speculate on the motives of the NSA go ahead.
> But if you want to explain the _NSAKEY variable in
> Microsoft(tm)'s software there is no need to invoke the NSA,
> little green men, or Elvis.
> lease do not misinterpret this statement. It is entirely
> possible that the NSA had a hand is whatever nefarious
> activities are being hidden.
> But we have no evidence of that. Nor do we need to assume
> their participation. Microsoft(tm) is perfectly capable
> of concocting this mess all by their lonesome.
First, we have no evidence of ANY explanation. So we are left
to look at all possible explanations and then pick the one that
fits all the evidence with the least amount of effort. The only
conclusion I can find in why that key is there in every 32 bit
OS is because someone wants it there. It certainly makes no
sense to say Microsoft wants it there given its functionality,
atleast not in every one of those OS's, so who do you have
left to choose from?
Picking anyone else from the field of players stretches the
evidence a lot. The key was named after NSA. NSA has the
greates motive (project Echelon) the greatest means (BXA license
as a club over Bill Gates) and the greatest opportunity (current
EAR enforcement). Take any one of those away and I might agree
with you. But it is the most compelling conclusion I can find.
And finally, there is no explanation that can refute this one
scenario. Not one.
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: Greg <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto
Subject: Re: EAR Relaxed? Really?
Date: Thu, 23 Sep 1999 00:11:22 GMT
> Still, people ARE setting up foreign subsidiaries.
But you have to agree that those who are are not big enough to
establish a new standard across America. The government would
stop them dead in their tracks if they attempted such a campaign.
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: Greg <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto
Subject: Re: EAR Relaxed? Really?
Date: Thu, 23 Sep 1999 00:14:28 GMT
In article
<[EMAIL PROTECTED]>,
Eric Lee Green <[EMAIL PROTECTED]> wrote:
> Greg wrote:
> > I have also heard that there are non disclosure agreements between
> > NSA and the vendor. This is fine, except it can prevent the vendor
> > from telling all about the negotiations with NSA. For example, if
> > the NSA says, "We need two back doors into your software to examine
> > the plain text before it is encrypted," then we would never hear of
> > it.
>
> Oh poop. You'd hear of it alright, because we would never
> agree to put two back doors into our software....
So you mean you would violate an NDA with the federal government
that would expose their true intentions that they would desire
to keep close to their chest? Do you really think they would
let you do this without hell to pay? I don't.
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: peekboo 1.5 is out (fixes and such)
Date: Thu, 23 Sep 1999 00:46:13 GMT
Peekboo 1.5 (yes a new improvement each week :)) is out
http://www.cell2000.net/security/peekboo/
New to this copy:
- larger private dh keys (keys are inter-compatible)
- can read 1.4 messages
- fixed many tiny bugs (stack leaks etc...)
- cleaned up the source code
- can read deja-news messed up messages :)
Tom
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
** 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
******************************
