Cryptography-Digest Digest #139, Volume #11 Thu, 17 Feb 00 05:13:00 EST
Contents:
Re: NTRU Speed Claims (100x faster, etc.), explained (David Wagner)
Re: UK publishes 'impossible' decryption law (reject)
Re: Hardware crypto device (Paul Rubin)
shorter key public algo? (Ori Dvir)
Re: code still unbroken ("r.e.s.")
Re: Question about OTPs - Newbie question added ("ink")
Re: Question about OTPs (Andru Luvisi)
Re: shorter key public algo? ([EMAIL PROTECTED])
Re: NTRU Speed Claims (100x faster, etc.), explained (Scott Contini)
Re: Outlook Express Sends Account password in the Clear (Francois Grieu)
Re: UK publishes 'impossible' decryption law (Runu Knips)
Re: OAP-L3 Encryption Software - Complete Help Files at web site ("Anthony Stephen
Szopa")
Re: Which compression is best? (Runu Knips)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (David Wagner)
Subject: Re: NTRU Speed Claims (100x faster, etc.), explained
Date: 16 Feb 2000 21:56:35 -0800
In article <88e7bl$26i$[EMAIL PROTECTED]>, <[EMAIL PROTECTED]> wrote:
> NTRU has posted an update to our FAQ which explains how our speed
> claims were derived. Please take a look at
> http://www.ntru.com/tech.learning.faq.htm#Why is NTRU fast
> (there is a link from the main page - www.ntru.com - at the bottom
> of the page) if you are interested.
Thanks for posting the information needed to make an independent
evaluation of NTRU's claims.
Nonetheless, I still feel -- even more so, now that I read the new
information -- that the "100 times faster" claim is exaggerated.
Also, the comments reveal what I consider a misunderstanding of some of
the work on RSA. The FAQ says: "Originally, encryption exponents as
low as k=3 were touted [...], but Don Coppersmith showed that this is
definitely not a good idea." This is reading too much into his results.
Coppersmith showed that e=3 is a very bad idea *if you don't use padding*.
But everyone who uses RSA uses padding (e.g., PKCS or OAEP), and padding
prevents his attack. Indeed, Coppersmith's paper itself advocates using
padding, especially for small exponents.
Coppersmith's work was great pioneering work, but the characterization of
it given in the NTRU FAQ is, IMHO, a misinterpretation. And, of course,
this is a mistake which makes NTRU look better. If one reinstates use
of RSA with low exponents (e=3), a large portion of the claimed speedup
of NTRU quickly evaporates.
NTRU looks intriguing. And there are some very interesting academic
papers on the subject. It might even be a better, faster, and
more secure public key cryptosystem. If it is, I want to use it!
What's disappointing is that, while NTRU may provide some interesting
performance improvements over existing cryptosystems, the over-exaggerated
performance claims confuse the situation and make it harder to accurately
assess just how much of a benefit NTRU truly provides.
(Nevertheless, kudos to NTRU for providing prompt and detailed information
on their performance measurements -- it is definitely a step forward,
and a step ahead of most other new entrants to the field.)
Just my opinion. Does anyone think I'm off base here?
------------------------------
Date: Thu, 17 Feb 2000 07:12:22 -0600
From: reject <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto
Subject: Re: UK publishes 'impossible' decryption law
>>>> the police *do* need to prove something: they need to show that I
>>>> did have the key. i.e., it would not (under the current proposal)
>>>> be a crime not to decrypt encrypted material when suitably told
>>> to do so unless the police could show that you once had the key.
>>> What if the accused has forgotten the key. Or mislaid the
>>> container of the key?
>>
>> According to the law, you get two years´ paid vacion, courtesy of Her
>> Majesty´s prisons. And if you happen to tell anybody about it, you
>> get a five-year bonus.
>
> Yes, thats the reason why english police is called the politest of europe
> (or even the whole world). You are not put into prison, you're just
> on vacation. Sad I'm not living in the kingdom...
>
> This law is idiotic. Why has anyone the right to read some data when,
> for example, they are my diary, or my poems ? I've the right to have
> some secrets ! And I've the right to store them electronically, if I
> want.
Citizens have rights.
People living under the Crown of England are not citizens, they are subjects.
Subjects don't have rights.
In the end, the only rights you have are the rights you're willing to fight
for. Anything else the government will gladly strip from you in the name of
"the public good" or "saving the children".
Crypto threatens a government's ability to control the masses. This is
intolerable to a government and so must be co-opted, subverted, or destroyed.
Mao said it best - "All power ultimately comes from the barrel of a gun."
Any firearm can be used as a weapon. The US govt considers crypto to be dangerous
enough that it is classified as a "munition". What does that tell you?
------------------------------
From: [EMAIL PROTECTED] (Paul Rubin)
Subject: Re: Hardware crypto device
Date: 17 Feb 2000 07:28:41 GMT
>[EMAIL PROTECTED] wrote:
>
>> Can anyone help me with this? (probably)
>> Where can i find info on PCI / ISA crypto cards?
>>
>> please reply by mail.
>>
>> best regards
>> thomas
http://www.ibm.com/security/cryptocards if you want programmable cards.
http://www.ncipher.com if you just want an accelerator / key management.
------------------------------
From: Ori Dvir <[EMAIL PROTECTED]>
Subject: shorter key public algo?
Date: Thu, 17 Feb 2000 09:26:42 +0200
I would like to find a public key algorithn as hard to crack as RSA
with 768 bit key, but with a shorter key. The thing is, i want the
cypher to be shorter, but still hard to crack, I dont mind so much the
speed of encryption / decryption.
Thanks.
------------------------------
From: "r.e.s." <[EMAIL PROTECTED]>
Subject: Re: code still unbroken
Date: Wed, 16 Feb 2000 23:33:30 -0800
"Chuck Davis" <[EMAIL PROTECTED]> wrote ...
:
: Most of the correspondence I get from cryptanalysis folk about the
: code I devised at discovervancouver.com sneers at its triviality.
[...]
: I think it's rather elegant, actually.
>From the puzzle's web page:
"No hints will be given, no correspondence will be entered into."
On the other hand, it seems strange that there is no assurance that
the solution will *ever* be revealed. (It's quite possible that the
puzzle is effectively unsolvable, just on cryptological grounds. In
addition, "coding" mistakes may even have unwittingly been made that
could prevent solution, in which case neither such mistakes nor the
intended solution would be revealed.)
--
r.e.s.
[EMAIL PROTECTED]
------------------------------
From: "ink" <[EMAIL PROTECTED]>
Subject: Re: Question about OTPs - Newbie question added
Date: Thu, 17 Feb 2000 08:46:57 +0100
Douglas A. Gwyn schrieb in Nachricht <[EMAIL PROTECTED]>...
>Arthur Dardia wrote:
>> So, my question is this: for one message, that I start at the
>> 30,567,890 byte and the next I start at the 30,567,889. ...
>
>That's horrible!
>
>It is well known that reusing (portions of) the key makes a
>one-time pad readily crackable. Here is a standard attack:
>
>Step 1: Determine the relative offsets of the overlapping CT.
>(This is easy with a so-called Kappa test, but in principle
>you could just try each possible alignment; there aren't all
>that many.)
Can you point me in a direction where I can find a description
of such a test?
>Step 2: Difference the aligned CTs to strip off all effect of
>the common key, leaving just the differenced PT ("delta stream").
>
>Step 3: Try adding some probable plaintext to various offsets
>within the delta stream; when the result is intelligible PT, you
>have found portions of both original PTs.
How do you determine "probable plaintext"?
TIA
Kurt
------------------------------
From: Andru Luvisi <[EMAIL PROTECTED]>
Subject: Re: Question about OTPs
Date: 16 Feb 2000 23:37:25 -0800
Tim Tyler <[EMAIL PROTECTED]> writes:
[snip]
> A OTP fails against a complete known plaintext attack - which immediately
> reveals the key.
[snip]
However, since that portion of the key should never be used to encrypt
anything else ever again, it doesn't matter. It shouldn't have any
relation to the random data used to encrypt any other plaintext, which
means it won't help you decrypt any other plaintext.
Andru
--
==========================================================================
| Andru Luvisi | http://libweb.sonoma.edu/ |
| Programmer/Analyst | Library Resources Online |
| Ruben Salazar Library |-----------------------------------------|
| Sonoma State University | http://www.belleprovence.com/ |
| [EMAIL PROTECTED] | Textile imports from Provence, France |
==========================================================================
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: shorter key public algo?
Date: Thu, 17 Feb 2000 07:45:59 GMT
=====BEGIN PGP SIGNED MESSAGE=====
Hash: SHA1
Ori Dvir wrote:
> I would like to find a public key algorithn as hard to crack as RSA
> with 768 bit key, but with a shorter key. The thing is, i want the
> cypher to be shorter, but still hard to crack, I dont mind so much the
> speed of encryption / decryption.
> Thanks.
elliptic curves maybe..
there is programs already using ec (Pegwit for example:
http://ds.dial.pipex.com/george.barwood/v8/pegwit.htm)
still there is a question how secure this realy is..
- --
Disastry
http://i.am/disastry/
=====BEGIN PGP SIGNATURE=====
Version: Netscape PGP half-Plugin 0.14 by Disastry / PGPsdk v1.7.1
Comment: get this Plugin at http://disastry.dhs.org/pgp.htm
iQA/AwUBOKuLEzBaTVEuJQxkEQJ4qQCgxALFbZA6HLfQT8I2Lss/OM4AhGkAnRBG
fVItNY4IByuA5XVZNItKfRX2
=wsr6
=====END PGP SIGNATURE=====
------------------------------
From: [EMAIL PROTECTED] (Scott Contini)
Subject: Re: NTRU Speed Claims (100x faster, etc.), explained
Date: 17 Feb 2000 08:32:35 GMT
In article <88g2ij$1f9$[EMAIL PROTECTED]>,
David Wagner <[EMAIL PROTECTED]> wrote:
>In article <88e7bl$26i$[EMAIL PROTECTED]>, <[EMAIL PROTECTED]> wrote:
>> NTRU has posted an update to our FAQ which explains how our speed
>> claims were derived. Please take a look at
>> http://www.ntru.com/tech.learning.faq.htm#Why is NTRU fast
>> (there is a link from the main page - www.ntru.com - at the bottom
>> of the page) if you are interested.
>
>Thanks for posting the information needed to make an independent
>evaluation of NTRU's claims.
>
>Nonetheless, I still feel -- even more so, now that I read the new
>information -- that the "100 times faster" claim is exaggerated.
>
>Also, the comments reveal what I consider a misunderstanding of some of
>the work on RSA. The FAQ says: "Originally, encryption exponents as
>low as k=3 were touted [...], but Don Coppersmith showed that this is
>definitely not a good idea." This is reading too much into his results.
>Coppersmith showed that e=3 is a very bad idea *if you don't use padding*.
>But everyone who uses RSA uses padding (e.g., PKCS or OAEP), and padding
>prevents his attack. Indeed, Coppersmith's paper itself advocates using
>padding, especially for small exponents.
>
>Coppersmith's work was great pioneering work, but the characterization of
>it given in the NTRU FAQ is, IMHO, a misinterpretation. And, of course,
>this is a mistake which makes NTRU look better. If one reinstates use
>of RSA with low exponents (e=3), a large portion of the claimed speedup
>of NTRU quickly evaporates.
>
>NTRU looks intriguing. And there are some very interesting academic
>papers on the subject. It might even be a better, faster, and
>more secure public key cryptosystem. If it is, I want to use it!
>What's disappointing is that, while NTRU may provide some interesting
>performance improvements over existing cryptosystems, the over-exaggerated
>performance claims confuse the situation and make it harder to accurately
>assess just how much of a benefit NTRU truly provides.
>
>(Nevertheless, kudos to NTRU for providing prompt and detailed information
>on their performance measurements -- it is definitely a step forward,
>and a step ahead of most other new entrants to the field.)
>
>Just my opinion. Does anyone think I'm off base here?
No, I think most of the scientific community would agree with you.
But that is marketing - hide the truth and only show what you want
other people to see. Certainly RSA and Certicom play these games
too.
Scott
------------------------------
From: [EMAIL PROTECTED] (Francois Grieu)
Subject: Re: Outlook Express Sends Account password in the Clear
Date: Thu, 17 Feb 2000 09:45:33 +0100
In article <QAKq4.289$[EMAIL PROTECTED]>,
"John E. Kuslich" <[EMAIL PROTECTED]> wrote :
> I was amazed to see that each request to the mial server was accompanied by
> my POP3 account user name and password IN THE CLEAR.
Try to activate the APOP protocol. The password will not be sent in clear,
but in a challenge-response protocol protected against replay using an
MD5 hash. Still it's vulnerable to password guessing, so choose a long
and/or complex password.
Francois Grieu
------------------------------
From: Runu Knips <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto
Subject: Re: UK publishes 'impossible' decryption law
Date: Thu, 17 Feb 2000 10:02:39 +0100
zapzing wrote:
> The perfect solution to Alzheimers disease:
> Outlaw it !
Cool idea.
Another good idea: a new law: death is not permitted.
I would state you even can reintroduce the capital punishment
for violations of that law !!
And guess what: even Amnesty wouldn't protest against that !!
------------------------------
From: "Anthony Stephen Szopa" <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto,alt.privacy
Subject: Re: OAP-L3 Encryption Software - Complete Help Files at web site
Date: Thu, 17 Feb 2000 01:53:20 -0800
All right, Emeritus Fool.
You are not intelligent enough to know the difference between describing
what you see (or in this case, what you read) in mathematical terms from the
actual origins of what you observe.
A musical score can be precisely described mathematically yet it came into
being from the creative mind of a composer. Or are you claiming that a
composer used a mathematical equation to compose the music?
Here is the quote:
"or with only 4600 data bytes you will be able to generate 2.3E17 random
numbers from 0 - 255 with a security level equivalent to 10,000 bits; "
Go to http://www.ciphile.com/ and go to Help Files in Table of Contents then
go to What's Ahead, and see for yourself.
Why are people using OAP-L3 encryption software with no complaints? Because
they are more than satisfied: that's why.
YOU do not know what you are talking about.
============================================================================
=========
"Joseph Ashwood" <[EMAIL PROTECTED]> wrote in message
news:uQImXiNe$GA.144@cpmsnbbsa05...
> I still think my favorite part is that it "Uses no
> mathematical equations" and yet still manages to perform
> operationcs that are inherently mathematic
> (encryption/decryption).
> And of course some more gems.
> on the page http://www.ciphile.com/soon.html
> "with a key of less than 2,500 bytes ... a security
> level equivalent to 10,000 bits"
> 5,000 bytes
> ..... 15,000 bits
> 10,000 bytes
> ..... 40,000 bits
> 50,000 bytes
> ...... 150,000 bits
> If that's the case you have a serious problem, at least half
> your bits are lost.
>
> The more I read about OAP-L3 the more I find it stupendously
> moronic.
>
>
> "Anthony Stephen Szopa" <[EMAIL PROTECTED]> wrote in
> message news:[EMAIL PROTECTED]...
> > OAP-L3: Original Absolute Privacy - Level3 Encryption
> Software -
> > Complete Help Files at web site
> >
> > Includes complete detailed explanation of entire
> encryption
> > software package: theory, operation, etc.
> >
> > http://www.ciphile.com
>
>
------------------------------
From: Runu Knips <[EMAIL PROTECTED]>
Subject: Re: Which compression is best?
Date: Thu, 17 Feb 2000 11:00:19 +0100
Tim Tyler schrieb:
> Runu Knips <[EMAIL PROTECTED]> wrote:
> : This is how ALL compressors work. No matter if simple RLE or
> : Huffman or ZiffDavis or whatever. Their output always follows rules.
> Their "output always follows rules" in the sense that it is
> deterministically derived from the input text.
> : [...]
> That does *not* mean you can write a program that identifies compressed
> files as such.
Well okay, I in fact didn't tried this in practice. For example, I know
that Huffman has to first dump the huffman tree, and then the huffman
codes follow. And because the input is not ideal random data (where each
character appears as often as the other), you will not get a balanced
tree (which would make compression by Huffman impossible anyway) as the
huffman tree, therefore some codes are not possible.
An easy example is the huffman alphabet for a file which contain 70%
nuls and 10% space plus 10% A plus 10% B (just to make calculation
easy). The resulting alphabet would be:
NUL = 0
SPACE = 100
A = 101
B = 110
The input file 111... is then not a possible input for this huffman
tree. And I don't consider Huffman a bad compression :)
> [...] the discussion here has covered the points you're
> raising in the past. More familiarity might have saved you your queries.
Yep, agreed.
> Most of the books about cryptography I've seen appear to be out of date in
> this area.
Yes, and the good ones say that by themselves.
> However, just because some compressors are less-than-ideal for
> cryptographic purposes, it does not follow that you can tar *all*
> compressors with the same brush.
Unfortunately, I don't know the details of all existing compressors.
The ones I know and understand can all be tested. I wonder how to
test ZivLempel, but I don't remember it exactly enough to state
anything about it.
> Yes - exercise caution when choosing a compressor - but don't say
> "never compress".
I never said "never compress". I said "don't try to improve a weak
cipher with compression", and "use compression for compression and
encryption for encryption".
With a good encryption, you can use compression, or let it be - it
should make no difference, at least no significant.
> Note also that you can only be sure of being able to do this this if you
> have the whole file decrypted. Without the whole file the attacker may
> not be able to begin to decompress.
Thats exactly what I said all the time ? If the decryption process
results in an invalid input for the decompressor, the decryption key
is the wrong one.
> This ability to delay plaintext analysis of the first blocks until the
> last ones have been decrypted is another securtity benefit of some
> compression schemes.
Yes, and in practice they reduce the total amount of available
ciphertext
for an attack.
> : In a simple brute force attack, this would make the
> : attack somewhat slower, but only by some small and fixed factor.
> Compression does often have this effect. However, it *can* have more
> significant effects. Look at the effect on partial plaintext attacks,
> for example.
Yep.
But using CBC mode would be a better and more trustable approach,
because CBC is made to do exactly that, while compression was
created to compress ;-)
> Where, with no compression, keys can be immediately rejected, with
> compression, they often cannot be. This can easily make the difference
> between the attacker being faced with millions of possible decrypts - or
> only one possibility.
>
> : You see, that is the simple problem like in the enigma - many
> : of the "improvements" of this machine actually helped the enemy
> : to break the enigma code.
>
> Adding "good" compression would be better compared to adding a rotor.
> You can be pretty damn sure that it will hinder the enemy a lot more than
> it will help him.
Adding rotors to enigma would still not remove some principial design
flaws which all where introduced as 'improvements'.
------------------------------
** 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
******************************
