Cryptography-Digest Digest #663
Cryptography-Digest Digest #663, Volume #13 Fri, 9 Feb 01 14:13:00 EST
Contents:
Re: Bill Payne and Philippine RSA "break" (Mok-Kong Shen)
Re: Scramdisk, CDR and Win-NT ([EMAIL PROTECTED])
Re: Bill Payne and Philippine RSA "break" (Tom St Denis)
Re: Phillo's alg is faster than index calculus (Tom St Denis)
Re: OverWrite freeware completely removes unwanted files from hard drive (Richard
Herring)
Re: Bill Payne and Philippine RSA "break" (Mok-Kong Shen)
Re: Bill Payne and Philippine RSA "break" (Tom St Denis)
Re: crack my enkryption (neXussT)
Re: relative key strength private vs public key (Bob Silverman)
Re: UNIX Crypt for DOS (Bob Silverman)
Shortened signatures (Matt J)
Re: Factoring (and not the Philippino :) (DJohn37050)
Re: relative key strength private vs public key (DJohn37050)
Re: Bill Payne and Philippine RSA "break" (Mok-Kong Shen)
Re: Bill Payne and Philippine RSA "break" (John Myre)
Re: Disk Overwriting (Peter Gutmann)
Re: Phillo's alg is faster than index calculus ("Douglas A. Gwyn")
Re: Mod function ("Douglas A. Gwyn")
Re: CipherText patent still pending (John Myre)
Re: CipherText patent still pending ("Douglas A. Gwyn")
Re: CipherText: JavaScript final implementation ("Douglas A. Gwyn")
Re: NPC ("Douglas A. Gwyn")
Re: ECDSA certs (Mike Rosing)
Re: stateful modran: uniform distribution over [0,n) (Mike Rosing)
Re: Different cipher type ("Douglas A. Gwyn")
Re: Bill Payne and Philippine RSA "break" ("Douglas A. Gwyn")
Re: Factoring (and not the Philippino :) ("Douglas A. Gwyn")
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Bill Payne and Philippine RSA "break"
Date: Fri, 09 Feb 2001 13:28:12 +0100
lcs Mixmaster Remailer wrote:
>
> Ironically, the Philippine RSA "break" is a retread of an old bogus
> algorithm which was torn to shreds in the mists of sci.crypt's past.
[snip]
Analogously, bogus 'elementary proofs' of FLT continue to
prop up in sci.math. Perhaps the 'story' would have been
shorter or not have occured, had Rivest answered the person
very tersely or not at all.
M. K. Shen
--
Date: 9 Feb 2001 12:20:01 -
Subject: Re: Scramdisk, CDR and Win-NT
Crossposted-To: alt.security.scramdisk
From: [EMAIL PROTECTED]
"Sam Simpson" <[EMAIL PROTECTED]> wrote:
>As long as you accept that you can't 'write on the fly' to the disk, then
>'no', everything should work just fine.
>
>Basically you still need to create the SD container file on a hard drive,
>fill it full of files etc and then write the container to a CD-RW...But at
>this point the container is totally read-only. If you want to change files
>then you need to copy the .SVL back to a hard drive, change the files, then
>write the .SVL file back to a CD.
>
I have created a SD container directly on a CD-RW (utilizing all
available space), and it is NOT read-only. When the container is
mounted, I can add files to it, modify files on it, etc. I don't
know whether I could run a program from it, since I've never tried
that.
I am using Win ME, btw and not NT/2000, if that makes a difference.
--
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: Bill Payne and Philippine RSA "break"
Date: Fri, 09 Feb 2001 12:30:08 GMT
In article <[EMAIL PROTECTED]>,
lcs Mixmaster Remailer <[EMAIL PROTECTED]> wrote:
> Ironically, the Philippine RSA "break" is a retread of an old bogus
> algorithm which was torn to shreds in the mists of sci.crypt's past.
>
> Bill Payne, now bothering cypherpunks regularly with his nutty self-filed
> legal case, first gained notoriety with his own algorithm to break RSA,
> available from:
>
> http://www.l0pht.com/pub/blackcrwl/encrypt/RSAISBRO.TXT
>
> It's the same basic algorithm: shift and xor N until you get a value of
> all 1's. And it doesn't work any better today than it did back then.
> As David Wagner wrote back in 1999 on sci.crypt,
>
> > Bill Payne's method was 100% bogus. (So bogus that I'm a bit embarassed
> > to even admit to having read it.) It had exponential time complexity,
> > and would probably perform even worse than trial division. In no way
> > does his "attack" justify the statement `RSA is broken'.
>
> Plus ca change...
>
So not only is it bogus, but it's not even new bogus? That's low.
Tom
Sent via Deja.com
http://www.deja.com/
--
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re
Cryptography-Digest Digest #663
Cryptography-Digest Digest #663, Volume #12 Tue, 12 Sep 00 16:13:01 EDT
Contents:
Re: Known Plain Text Attack (Mark Wooding)
security of SKID based msg authentication. (Roger Gammans)
Need Tiger hash results for sample test data ([EMAIL PROTECTED])
Re: nice simple function (Mike Rosing)
Re: Steganography and secret sorting (Matthew Skala)
Re: Steganography and secret sorting (Matthew Skala)
Re: Scottu19 Broken (Mok-Kong Shen)
Re: sac fullfilling decorelated functions (Mike Rosing)
Re: Bytes, octets, chars, and characters ("Douglas A. Gwyn")
Re: Steganography and secret sorting (Mok-Kong Shen)
Re: nice simple function (Bryan Olson)
Re: Need Tiger hash results for sample test data (John Myre)
Re: OutLook Express & SMIME ("Michael Scott")
Re: security warning -- "www.etradebank.com" (Ian Goldberg)
Dickman's function (Francois Grieu)
Re: ExCSS Source Code (Ichinin)
Re: Problem with Tiger hash algorithm and binary files (Daniel Leonard)
Re: Scottu19 Broken ("Douglas A. Gwyn")
Re: nice simple function ("Douglas A. Gwyn")
Re: Intel's 1.13 MHZ chip (Mok-Kong Shen)
From: [EMAIL PROTECTED] (Mark Wooding)
Subject: Re: Known Plain Text Attack
Date: 12 Sep 2000 17:22:17 GMT
Terry Ritter <[EMAIL PROTECTED]> wrote:
> First of all, my US patents apply only in the US,
Clearly. Do you hold patents in other countries, though?
> Next, if the issue is *understanding* cryptographic techniques,
> avoiding patented concepts is an explicit choice for ignorance.
Agreed.
Terry's put together a great deal of really useful information. He also
explains clearly which techniques he's patented, which lets you avoid
them. His site is well worth a look.
-- [mdw]
--
From: [EMAIL PROTECTED] (Roger Gammans)
Subject: security of SKID based msg authentication.
Date: Tue, 12 Sep 2000 17:31:04 GMT
I was looking for a `simple' msg auth schema, and found the following
in a quick persual of Schneier + some of my thoughts as I coudn't find
quite what I wanted:-
So based on SKID we get:-
Alice needs message M from Bob, and be sure it came from Bob.
0) Alice & Bob have a pre-arranged long-lived secret K,
identity token B (for Bob ), and a cryptographic
hash function H().
1) Alice choses a random number (Ra) and sends it to Bob.
with a request for message M.
2) Bob choses a random number (Rb) , He then sends Alice:-
Rb,M,H(K,Ra,Rb,M,B)
3) Alice can then also compute H(K,Ra,Rb,M,B) to
verify the message came from Bob.
So are there any _really_ glaring errors in this? - Beyond of
course the security of H().
Interestingly Schneier claims[1] that SKID is not secure against
man-in-the-middle attacks , implying in the next sentence that it
doesn't have a shared-secret - but he previously cliamed it did.
Am I mis-reading the book here?
TTFN
[1] Applied Crytography 2e, p 56.
--
Roger
Think of the mess on the carpet. Sensible people do all their
demon-summoning in the garage, which you can just hose down afterwards.
-- [EMAIL PROTECTED]
--
From: [EMAIL PROTECTED]
Subject: Need Tiger hash results for sample test data
Date: Tue, 12 Sep 2000 17:27:36 GMT
Does anyone have hash results, using Tiger, for one or more files(binary
also)? Yes, the authors did provide a 'testtiger.c' program, but this
only performs hashes for sample strings (e.g. "abc"), not files. A hash
on a string SHOULD not be the same as hash on a file containing said
string, so I can't very well use this method to validate my routine (See
below).
I wrote a C routine to create a hash on an arbitrary file using the
Tiger hash algorith
(http://www.cs.technion.ac.il/~biham/Reports/Tiger/). I am now looking
for some test data to validate my routine against. It would be nice to
know I am computing the correct hash.
Thanks.
George
Sent via Deja.com http://www.deja.com/
Before you buy.
--
From: Mike Rosing <[EMAIL PROTECTED]>
Subject: Re: nice simple function
Date: Tue, 12 Sep 2000 12:49:01 -0500
Tom St Denis wrote:
> f''(x) = f'(x ++ f(x)) where '++' represents modular integer addition.
> We now get f''(x) = f'(x ++ (a.x + b)) = c.(x ++ (a.x + b)) + d = c.x
> ++ c.(a.x + b) + d = c.x ++ (c.a.x + c.b) + d
>
> From what I can tell c.x cannot be grouped with c.a.x, which means we
> have an output that is a function of 'c' and 'a'. Also that c.b cannot
> be grouped with 'd', but since they are not a function of the input can
> we let 'b' be zero and just have
Cryptography-Digest Digest #663
Cryptography-Digest Digest #663, Volume #11 Sat, 29 Apr 00 17:13:02 EDT Contents: Re: factor large composite (Jerry Coffin) Re: Intel drops serial number (Bill Unruh) Re: Help In encryption!!! (Andru Luvisi) Re: Help with Encryption Algorithm (Andru Luvisi) Re: factor large composite ([EMAIL PROTECTED]) Request for attacks on slightly less naive algorithm than last time (Richard Heathfield) Re: U-571 movie (OT) (Darren New) Re: Speaking of HD Overwriting... (Jerry Coffin) Re: sci.crypt think will be AES? (Terry Ritter) Re: sboxes for the bored... (Terry Ritter) From: Jerry Coffin <[EMAIL PROTECTED]> Subject: Re: factor large composite Date: Sat, 29 Apr 2000 11:58:27 -0600 In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] says... > Johnny Bravo wrote: > > The cost is nothing, ... > > Wrong. If your CPU is idle, it will execute a HLT and waste far > less power. That depends -- there are some laptops and such that halt at least parts of the processor when they're not in use, but most desktop machines do nothing of the sort. > If you always have some low priority task running > which uses every bit of time he can get, you will waste far more > power than without it. "far more"? Again, you seem to be stretching things a bit -- some of the big RISC CPUs draw quite a bit of power (the highest of which I'm aware is the Fujitsu SPARC V, at 100 watts) but most CPUs don't draw narly that kind of power -- 8 to 10 watts is fairly typical for many CPUs, and something like an ARM or SuperH can run on well under one watt. > Plus, no matter how low the priority of such a program is, it > will always fill the CPU cache with its instructions and drop > other peoples stuff out of it. This effect is real; you can > experience it in practice. This is pure nonsense -- it will have instructions in the cache while it's running, and typically for a _very_ short period of time afterwards. Depending on the size of the program involved, and the OS in use, this often has little effect: a typical OS has an idle process that runs when nothing else needs CPU time, and something like an ECDL progam may end up using almost no more memory than the system idle process. In any case, as long as the process isn't scheduled and running (i.e. when you're doing anything else) it will NOT have any instructions in the cache AT ALL, at least under any reasonably ordinary OS and CPU -- it's barely possible that somebody has designed something to work differently, but if so, it's definitely VERY rare. -- Later, Jerry. The universe is a figment of its own imagination. -- From: [EMAIL PROTECTED] (Bill Unruh) Crossposted-To: talk.politics.crypto Subject: Re: Intel drops serial number Date: 29 Apr 2000 18:07:09 GMT In <8ef2a9$92n$[EMAIL PROTECTED]> [EMAIL PROTECTED] (Vernon Schryver) writes: >nothing to do with the PIII ID. By implying that some privacy was >threatened by the PIII ID and protected by its disappearance, you are >aiding and abetting those who can and do violate the privacy of anyone >who doesn't take precautions. By spreading the "big lie" that a battle >has been won, you fool the ignorant into not seeking and implementing >defenses. A battle has been won. This of course does not mean that the war is over, but each beachhead won is an advance. That other means of privacy intrusion are also used it true. That this would not have been a danger until widly implimented is also true, but after it is widely implimented is not the time to fight the battle. -- From: Andru Luvisi <[EMAIL PROTECTED]> Subject: Re: Help In encryption!!! Date: 29 Apr 2000 11:17:07 -0700 [EMAIL PROTECTED] writes: > Hi: > > I was wondering which would be the best and > easiest encryption algorithm to code using C++, > such that it could be implemented for a class > project. Also can someone point me to some > encryption algorithms where there is a full > description of the process. Here's two: Ciphersaber: http://www.ciphersaber.gurus.com/ TEA/XTEA: http://vader.brad.ac.uk/tea/tea.shtml 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: Andru Luvisi <[EMAIL PROTECTED]> Su
Cryptography-Digest Digest #663
Cryptography-Digest Digest #663, Volume #10 Thu, 2 Dec 99 09:13:01 EST Contents: Avoiding bogus encryption products: Snake Oil FAQ (C Matthew Curtin) From: C Matthew Curtin <[EMAIL PROTECTED]> Crossposted-To: alt.security,comp.security,comp.infosystems,comp.answers,sci.answers,alt.answers,news.answers Subject: Avoiding bogus encryption products: Snake Oil FAQ Date: 2 Dec 1999 13:41:38 GMT URL: http://www.interhack.net/people/cmcurtin/snake-oil-faq.html Version: 1.9 Archive-name: cryptography-faq/snake-oil Posting-Frequency: monthly Snake Oil Warning Signs: Encryption Software to Avoid Copyright © 1996-1998 Matt Curtin <[EMAIL PROTECTED]> April 10, 1998 Contents * Contents * Introduction * Basic Concepts o Symmetric vs. Asymmetric Cryptography o Secrecy vs. Integrity: What are you trying to protect? o Key Sizes o Keys vs. Passphrases o Implementation Environment * Snake Oil Warning Signs o ``Trust Us, We Know What We're Doing'' o Technobabble o Secret Algorithms o Revolutionary Breakthroughs o Experienced Security Experts, Rave Reviews, and Other Useless Certificates o Unbreakability o One-Time-Pads o Algorithm or product X is insecure o Recoverable Keys o Exportable from the USA o ``Military Grade'' * Other Considerations * Glossary * Index * References Administrativia Distribution Distribution of this document is unlimited. We're specifically trying to reach people who are not experts in cryptography or security but find themselves making decisions about what sorts of crypto (if any) to use, both for their organizations and for themselves. The Snake Oil FAQ is posted monthly to sci.crypt, alt.security, comp.security, comp.answers, and comp.infosystems. It is available in PostScript and PDF form (ideal for printing) via the web at http://www.interhack.net/people/cmcurtin/snake-oil-faq.ps http://www.interhack.net/people/cmcurtin/snake-oil-faq.pdf and HTML at http://www.interhack.net/people/cmcurtin/snake-oil-faq.html Disclaimer All contributors' employers will no doubt disown any statements herein. We're not speaking for anyone but ourselves. This is a compilation of common habits of snake oil vendors. It cannot be the sole method of rating a security product, since there can be exceptions to most of these rules. From time to time, a reputable vendor will produce something that is actually quite good, but will promote it with braindead marketing techniques. But if you're looking at something that exhibits several warning signs, you're probably dealing with snake oil. Every effort has been made to produce an accurate and useful document, but the information herein is completely without warranty. This is a work-in-progress; feedback is greatly appreciated. If you find any errors or otherwise wish to contribute, please contact the document keeper, Matt Curtin <[EMAIL PROTECTED]> Document History With the rise in the number of crypto products came a rise in the number of ineffective or outright bogus products. After some discussion about this on the cypherpunks list, Robert Rothenburg <[EMAIL PROTECTED]> wrote the first iteration of the Snake Oil FAQ. Matt Curtin took the early text and munged it into its current state with the help of the listed contributors (and probably some others whose names have inadvertently missed. Sorry in advance, if this is the case.) Contributors The following folks have contributed to this FAQ. Jeremey Barrett <[EMAIL PROTECTED]> Steven M. Bellovin <[EMAIL PROTECTED]> Matt Blaze <[EMAIL PROTECTED]> Bo Dvmstedt <[EMAIL PROTECTED]> Gary Ellison <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> Larry Kilgallen <[EMAIL PROTECTED]> Dutra Lacerda <[EMAIL PROTECTED]> Felix Lee <[EMAIL PROTECTED]> Colin Plumb <[EMAIL PROTECTED]> Jim Ray <[EMAIL PROTECTED]> Terry Ritter <[EMAIL PROTECTED]> Robert Rothenburg <[EMAIL PROTECTED]> Adam Shostack <[EMAIL PROTECTED]> Rick Smith <[EMAIL PROTECTED]> Randall Williams <[EMAIL PROTECTED]> Introduction Good cryptography is an excellent and necessary tool for almost anyone. Many good cryptographic products are available commercially, as shareware, or free. However, there are also extremely bad cryptographic products which not only fail to provide security, but also contribute to the many misconceptions and misunderstandings surrounding cryptography and security. Why ``snake oil''? The term is used in many fields to denote something sold without consideration of
Cryptography-Digest Digest #663
Cryptography-Digest Digest #663, Volume #9Sat, 5 Jun 99 09:13:01 EDT
Contents:
Re: Challenge to SCOTT19U.ZIP_GUY (Phillip Dawson)
Re: random numbers in ml ([EMAIL PROTECTED])
Re: CRC32 (D. J. Bernstein)
Re: OTP Problems (Frank Gifford)
Re: Is SSL CPU intensive? (Eric Young)
Re: Challenge to SCOTT19U.ZIP_GUY (Thomas Pornin)
Re: Viability of encrypted flash cards? (Matthias Bruestle)
Re: New Computer & Printer for Dave Scott ([EMAIL PROTECTED])
Re: evolving round keys ([EMAIL PROTECTED])
Re: Finding a 192 bit hash (Was: Using symmetric encryption for hashing) (Paul
Onions)
Re: Finding a 192 bit hash (Was: Using symmetric encryption for hashing) (Paul
Onions)
Re: PGP probability of choosing primes? (Johnny Bravo)
Re: Challenge to SCOTT19U.ZIP_GUY (Tim Redburn)
Re: Challenge to SCOTT19U.ZIP_GUY (Tim Redburn)
Re: Finding a 192 bit hash (Was: Using symmetric encryption for hashing) (Paul
Onions)
Re: evolving round keys ([EMAIL PROTECTED])
From: [EMAIL PROTECTED] (Phillip Dawson)
Subject: Re: Challenge to SCOTT19U.ZIP_GUY
Date: 5 Jun 1999 01:28:50 -0400
Tim Redburn ([EMAIL PROTECTED]) wrote:
: On Fri, 04 Jun 1999 14:13:40 GMT, [EMAIL PROTECTED]
: (SCOTT19U.ZIP_GUY) wrote:
: > I have been a programmer for over 30 years. I could give a dam what
: >they say about style. Style is just a tem used so that programmers
: >who can' program waste a lot of paper and then management is under
: >the illusion that they porduces something. Style is used to force creative
: >programs in a mold that they don't need.
: Or in other cases, they clearly do need !
: - Tim.
Sorry folks, I just couldn't resist this one:
Scott, just because no one understands you(your code), doesn't mean you're
an artist.
-Phillip Dawson
[EMAIL PROTECTED]
--
From: [EMAIL PROTECTED]
Crossposted-To: comp.sys.cbm,comp.sys.apple2.programmer
Subject: Re: random numbers in ml
Date: 5 Jun 1999 06:06:55 GMT
Reply-To: [EMAIL PROTECTED] (Matthew Montchalin)
In a previous article, [EMAIL PROTECTED] ("Douglas A. Gwyn") says:
>However, in many cases, reasonable results can be obtained by using
>a wider type (so that the "carry" remains within the accessible
>representation) and suitable bit operations.
Then variables should be established in the first few lines that are 16
bits wide, instead of 8 bits wide? And then shave off the excess bits with
an AND operation? Certainly feasible, but how to go about doing that... ?
>I.e. the algorithm can be coded in C, but it may use methods that
>are different from those that you would use in assembly language.
Okay, and some 'C' implementations might produce very interesting
variations along the same line of reasoning that produced the first
algorithm...
--
--
From: [EMAIL PROTECTED] (D. J. Bernstein)
Subject: Re: CRC32
Date: 5 Jun 1999 06:19:05 GMT
> are there any ways to speed crc32 up a bit? or are there any
> faster (yet as "secure") algorithms as crc32?
http://pobox.com/~djb/hash127.html is almost as fast as an optimized
CRC-32, but produces a 127-bit hash, using a 128-bit key.
As explained in http://pobox.com/~djb/papers/hash127.dvi, if you feed
any set of N inputs to hash127, each at most 4L bytes long, then there
are at most N(N-1)(L+2) possible keys that will produce a collision.
---Dan
--
From: [EMAIL PROTECTED] (Frank Gifford)
Subject: Re: OTP Problems
Date: 4 Jun 1999 12:07:39 -0400
In article <1JG53.580$[EMAIL PROTECTED]>,
TTK Ciar <[EMAIL PROTECTED]> wrote:
> Something just occured to me while reading this thread -- could
>you "stretch" your OTP ...
>
> Clarification: say you have 1,001,024 bits of securely transported
>data (your "pad" -- no longer an OTP in this context) and you're
>using a symmetric 1024-bit block encryption algorithm to transmit
>your secret messages. The proposed method would use bits 0..1023
>to construct the first block, 1..1024 to construct the second,
>2..1025 to construct the third, etc. This would seem to allow you
>to transmit 1,000,000 blocks (1,024,000,000 bits' worth) of data
>before running out of pad data.
The drawback is that if any portion of the key is discovered, then the
blocks on either side of it only require 2 keys to be checked. The bit
stream can be extended on either side very quickly. So the security of
this is only as strong as the security of every block remaining unknown.
-Giff
--
Too busy for a .sig
--
From: Eric Young <[EMAIL PROTECTED]>
Subject: Re: Is SSL CPU intensive?
Date: Sat, 05 Jun 1999 17:51:16 +1000
Paul Rubin wrote:
> Thierry Moreau <[EMAIL PROTECTED]> wrote:
> >Establi
