Cryptography-Digest Digest #558
Cryptography-Digest Digest #558, Volume #14 Thu, 7 Jun 01 21:13:01 EDT Contents: Re: Best, Strongest Algorithm (gone from any reasonable topic) (Tom St Denis) Re: Best, Strongest Algorithm (gone from any reasonable topic) (Tom St Denis) Re: Best, Strongest Algorithm (gone from any reasonable topic) (Mok-Kong Shen) Re: Simple C crypto (Dirk Bruere) Re: Notion of perfect secrecy (Jeffrey Walton) Re: Notion of perfect secrecy (Boyd Roberts) Re: Simple C crypto (Tom St Denis) Re: Notion of perfect secrecy (John Savard) Re: Help with Comparison Of Complexity of Discrete Logs, Knapsack, and Large Primes (David Wagner) Re: PRP = PRF (TRUNCATE) (David Wagner) Re: Any Informed Opinions? (Jeffrey Walton) Re: Medical data confidentiality on network comms (David Wagner) Re: PRP = PRF (TRUNCATE) (Tom St Denis) Re: Some questions on GSM and 3G (David Wagner) Re: Simple C crypto (Dirk Bruere) Re: DES not a group proof (David Wagner) Re: MD5 for random number generation? (David Wagner) Re: CBC variant (David Wagner) Re: DES not a group proof (Patrick Aland) Re: Simple C crypto (Joseph Ashwood) Re: Alice and Bob Speak MooJoo (Robert J. Kolker) From: Tom St Denis [EMAIL PROTECTED] Subject: Re: Best, Strongest Algorithm (gone from any reasonable topic) Date: Thu, 07 Jun 2001 22:27:12 GMT SCOTT19U.ZIP_GUY [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED]... [EMAIL PROTECTED] (JPeschel) wrote in [EMAIL PROTECTED]: Tim Tyler [EMAIL PROTECTED] writes, in part: If you nitpick the examples without actually attacking the basic point, we will only find other ones. Tim, we appears to only you and maybe Dave. :-) You posted an example where you thought it was obvious that a two-character encrypted response meant no, and three letters meant yes. I pointed out that it isn't neccesarily so. You might as well flip a coin. Off hand I would say you have not seen many proofs or tests of theorms. You don't understand that it perfectly valid to define a system that contains 2 messages 'YES and NO. To reject it saying you want to do somthing else is irrelivent. I gave a model and showed zero security. I don't care if you have other models since it only takes one failure to prove something is wrong. By your logic RSA is an insecure system completely since it is possible to make and use 32-bit primes. Just because you mis-used an OTP doesn't make the OTP non-secure. Typically if your situation calls for a boolean you dont send the ascii YES or ascii NO. If you had a three letter call code you would use 3 ascii bytes. Tom -- From: Tom St Denis [EMAIL PROTECTED] Subject: Re: Best, Strongest Algorithm (gone from any reasonable topic) Date: Thu, 07 Jun 2001 22:29:33 GMT Tim Tyler [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED]... Tom St Denis [EMAIL PROTECTED] wrote: : Tim Tyler [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED]... : Tom St Denis [EMAIL PROTECTED] wrote: : : Perhaps if you defined your threat model this would make sense. Why in : : your world is knowing the length of the message a threat? : : See David's Yes/No example. : What 1/0? [...] No. Where the attacker has a priori knowledge that the message is going to be either yes or no - but doesn't know which. That's just a contrived example of how to not use an OTP. Obviously in this case the two messages are vastly different. If your system calls for sending booleans send bits not ASCII words. I mean seriously, outside of a contrived example an OTP is perfectly secure. By this logic RSA is insecure because a naive user can make 32-bit primes, or RC6 is insecure because you can supply 16-bit keys, or CTR mode is insecure because you could have THEANSWERISYES and NO as texts, or BICOM is insecure because the user could just forget to supply a key at all... or... Making contrived ways to break something is not only pointless but futile. It proves nothing. Tom -- From: Mok-Kong Shen [EMAIL PROTECTED] Subject: Re: Best, Strongest Algorithm (gone from any reasonable topic) Date: Fri, 08 Jun 2001 00:26:38 +0200 SCOTT19U.ZIP_GUY wrote: [EMAIL PROTECTED] (Mok-Kong Shen) wrote in 3B1FBAF6.1DD02E47@t- online.de: SCOTT19U.ZIP_GUY wrote: [EMAIL PROTECTED] (Tim Tyler) wrote in [EMAIL PROTECTED]: Mok-Kong Shen [EMAIL PROTECTED] wrote: snap... To see how a particular 8 bit cyphertext could map to more than 256 different plaintexts, just get an 8 bit cyphertext, decrypt it with BICOM under a number of keys. You will see *many* different plaintexts come out - not just 256. Mok likes to talk but getting him to actually do anthing is quite impossible. He would rather say its impossible than actually check it out. A lot like TOMMY. Sometimes I think He and Tommy are not real people
Cryptography-Digest Digest #558
Cryptography-Digest Digest #558, Volume #13 Fri, 26 Jan 01 15:13:01 EST Contents: Re: Windows encryption: API and file system (Ray Dillinger) Re: Dynamic Transposition Revisited (long) (Mok-Kong Shen) Re: Dynamic Transposition Revisited (long) (AllanW) Re: Why Microsoft's Product Activation Stinks (Anthony Stephen Szopa) Re: Dynamic Transposition Revisited (long) (AllanW) Re: Why Microsoft's Product Activation Stinks (Anthony Stephen Szopa) Re: Dynamic Transposition Revisited (long) (Mok-Kong Shen) From: Ray Dillinger [EMAIL PROTECTED] Subject: Re: Windows encryption: API and file system Date: Fri, 26 Jan 2001 19:13:22 GMT It's not merely sloppy engineering... Think about it. It would have been just as easy to create the temporary file as an encrypted file in the first place, then copy it back over the file being encrypted, and *then* delete it. To call this "sloppy" is to believe that the engineer selected these operations and then didn't think *at all* about what order to apply them in. Which, I guess, you may believe if you care to, but I don't think anyone that flatout stupid can be an engineer in the first place. I don't think Microsoft is in the security business at all. I think that they are in the business of providing the *illusion* of security while still selling out ^H^H^H^H^H^H^H^H uh, "providing for the legitimate needs of law enforcement and data theives". Real security scares the bejabbers out of them and they're fighting it every step of the way. Bear Ben Newman [EMAIL PROTECTED] wrote: : This is an excellent start. I was hoping for a more detailed discussion of : how an OS can secure files, and how Windows has implemented their encryption : protocol. : This bug is just plain sloppy engineering! : --ben : "Bryan Mongeau" [EMAIL PROTECTED] wrote in message : news:VUYb6.6219$[EMAIL PROTECTED]... : Ben Newman wrote: : : I'd like to learn more about criticisms of the Windows cryptography : implementation. In response to an earlier post, someone characterized it : as "practically useless." This seems like a particularly important issue : given the amount of knowledge your average Windows user has about : crypto. : : --ben : : : : I don't know if this what you mean but I saw this on Bugtraq : a few days ago: : : -- : BugTraq: EFS Win 2000 flaw : From: Rickard Berglind [EMAIL PROTECTED] : To: [EMAIL PROTECTED] : Date: Fri, 19 Jan 2001 12:29:50 +0100 : : : I have found a major problem with the encrypted filesystem : ( EFS ) in Windows 2000 which shows that encrypted files : are still very available for a thief or attacker. : : : The problem comes from how EFS works when the encryption : is done. When a user marks a file for encryption a : backup-file, called efs0.tmp, will be created. When : the copy is in place the orginal file will be deleted : and then recreated, now encrypted, from the efs0.tmp- : file. : And finally, when the new encrypted file is succesfully : created, the temporary-file ( which will never be shown : in the user interface ) will be deleted as well. : : So far, so good. The only file remaining is the one : which is encrypted. : : : But the flaw is this: the temporary-file is deleted : in the same way any other file is "deleted" - i.e. : the entry in the $mft is marked as empty and the clusters : where the file was stored will be marked in the $Bitmap : as available, but the psysical file and the information it : contains will NOT be deleted. The information in the : file which the user have encrypted will be left in the backup : file efs0.tmp in total plaintext on the surface of the disk. : : When new files are added to the partition will they : gradually overwrite the secret information, but if : the encrypted file was large - the information could : be left for months. : : So how can this be exploited ? If someone steals : a laptop or have psysical access to the disk it will : be easy to use any low level disk editor to search : for the information. For example, the Microsoft : Support Tool "dskprobe.exe" works fine for locating : old efs0.tmp-files and read information, in plain-text, : that the user thought was safe. : : In my opinion there should be a function in the EFS : which physically overwrites the efs0.tmp at least once : to make it a lot harder for an attacker to gain control : over secret information. : : : : Here is a description how to test this : : : Use any version of Windows 2000. : Install the Support Tools from the Win2000 CD. : : For demonstrating purposes - create a new partition with : the size of 7 MB. : Choose to format with NTFS. : Create a new small file ( easier to find ) with Notepad : and put some text in it. Save this file in the root of the : new partition. : : Do not encrypt
Cryptography-Digest Digest #558
Cryptography-Digest Digest #558, Volume #12 Mon, 28 Aug 00 18:13:01 EDT
Contents:
Re: Bytes, octets, chars, and characters (Eric Fischer)
Re: R: R: Test on pseudorandom number generator. (Terry Ritter)
Future computing power (Mok-Kong Shen)
Re: SHA-1 program, wrongo ! (S. T. L.)
Re: Future computing power (S. T. L.)
Re: Future computing power ([EMAIL PROTECTED])
Re: Future computing power (Ichinin)
Re: Future computing power (Ichinin)
Re: DeCSS ruling -- More ("David C. Barber")
Re: Future computing power ([EMAIL PROTECTED])
Re: NEWBIE!!! Zodiac killer's encryption... (John C. King)
Re: Steganography vs. Security through Obscurity (zapzing)
Re: R: R: Test on pseudorandom number generator. ("Douglas A. Gwyn")
Re: ZixIt Mail (Steve)
Re: Bytes, octets, chars, and characters ("Douglas A. Gwyn")
Re: could someone post public key that is tempered ? ("Douglas A. Gwyn")
Re: PRNG Test Theory ("Douglas A. Gwyn")
Re: Blowfish question (and others) ("Jeffrey Walton")
Re: NEWBIE!!! Zodiac killer's encryption... ("Douglas A. Gwyn")
Re: PGP 6.5.8 test: That's NOT enough !!! (Nick Andriash)
Re: Blowfish question (and others) (Mike Tulley)
From: Eric Fischer [EMAIL PROTECTED]
Crossposted-To: comp.lang.c,alt.folklore.computers
Subject: Re: Bytes, octets, chars, and characters
Date: 28 Aug 2000 19:14:41 GMT
Johnny Billquist [EMAIL PROTECTED] wrote:
ASCII is not an international standard, although there are several
for character codes based on and intentionally similar to ASCII.
I think there is some ISO standard which matches ASCII, but I have
no idea what it is called.
ISO 646 is the international 7-bit character code standard. It allows
national variations for several characters, but there is an "international
reference version" that specifies what characters should be assigned if
there are no particular national needs, and in recent years this has been
aligned with ASCII. (Earlier versions of the IRV specified a Pound sign
instead of the Number sign, an international currency symbol instead of
the Dollar sign, and an overline instead of the tilde.)
Another international standard for the same code is the ITU-T (formerly
CCITT) International Reference Alphabet (formerly International Alphabet
No. 5).
eric
--
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: R: R: Test on pseudorandom number generator.
Date: Mon, 28 Aug 2000 19:25:57 GMT
On Mon, 28 Aug 2000 13:18:24 +0200, in 8odge9$7tl$[EMAIL PROTECTED],
in sci.crypt "Cristiano" [EMAIL PROTECTED] wrote:
The normal way to use a LCG is to convert the entire internal state
into a float, or even to use the state itself as an integer. Since
using the entire state is "normal," that is the way statistical tests
must be applied to get the "normal" results.
OK this is the best way, but if I need only 8 bits? I think the best is take
the 8 msb.
If you are going to use only 8 bits, you need test only 8 bits, not an
accumulation of 5 such values taken as a single large 40-bit value.
Only when I apply my test to PRNG I need to consider only the 8 msb, but
when I run FIPS PUB 140-2, Maurer and Diehard I take the whole integer as is
without any modification.
Taking 5 chunks of 8-bits each is not the same as taking a single
40-bit value from an RNG.
One might as well argue that one could take 1 bit from each RNG step,
and that would be OK, or 1 bit every 100th RNG step and that would be
OK as well. It is not. We might make a complex RNG that way, but we
would not expect common statistical tests to be designed to pick up
problems which might occur in such a design.
For most conventional tests, the value being interpreted must
correspond to the single step of the RNG. If not, the test will be
confused by given a single meaning to a value which really has no
relationship to any one internal RNG state. Then it is the confusion
of the test which is being demonstrated, but nobody cares if we can
confuse a test.
Similarly, Diehard expects to see 32-bit integers, not 40 (unless it
has been modified). If we expect tests to have some meaning, we must
give the test the data in a format it expects. Then each test can
tell us about the particular characteristics it detects.
Diehard read a (big) file. If I generate a file n bytes length, I think is
not a problem how I generate the same n bytes, the problem is how generate
each byte (as you say in the first paragraph).
You are confused. If you want to test bytes, you need to have tests
which are designed to work on bytes. If you want to use tests
designed to work on 32-bit integers, you need to supply 32-bit
integers, not 4 bytes. And in fact you supply 5 bytes.
It is not a surprise that one can confuse a statistical test by havin
Cryptography-Digest Digest #558
Cryptography-Digest Digest #558, Volume #11 Sun, 16 Apr 00 15:13:01 EDT Contents: Re: Why is this algorithm insecure? (Newbie flamefodder) (stanislav shalunov) Re: My STRONG data encryption algorithm (stanislav shalunov) Re: ? Backdoor in Microsoft web server ? [correction] (Francois Grieu) Why encrypt email... ([EMAIL PROTECTED]) Re: Open Public Key (Tom St Denis) Re: ? Backdoor in Microsoft web server ? [correction] (Jim Gillogly) Re: Why is this algorithm insecure? (Newbie flamefodder) (Boris Kazak) Re: Open Public Key (Mark Wooding) Re: GOST idea (Mok-Kong Shen) Re: General principles of design (Mok-Kong Shen) Re: AND on encrypted data (Mok-Kong Shen) Subject: Re: Why is this algorithm insecure? (Newbie flamefodder) From: stanislav shalunov [EMAIL PROTECTED] Date: Sun, 16 Apr 2000 17:12:45 GMT Richard Heathfield [EMAIL PROTECTED] writes: Thank you. I'm not sure, however, that I have understood you correctly. You seem to be saying that Eve can decrypt any message she likes, provided she has first done a chosen plaintext attack on a message that length and using the same key as Alice. Okay, yes, that's a problem. But how would she do such an attack? I was a bit careless: known plaintext is enough. What I have meant is that if Alice sends to Bob a stream of messages of the same length encrypted with the same key (e.g., network packets), and if Eve knows plaintext of one of the packets, Eve immediately can decrypt all the other packets. (Eve could guess the first packet, which might be part of a higher-level protocol or make Alice send some chosen plaintext). More than that, Eve can simply XOR any two packets and get rid of key material completely. If data has enough redundancy (e.g., is natural language text) both packets can be recovered. All further and previous packets of the same length with the same key are compromised. If a key can never be reused the cryptosystem is useless. (One could simply use OTP then.) Also, you seem to be mentioning overly long keys (4K, etc.) all the time. If symmetric cryptosystem needs such long keys you know it's worthless. A secure algorithm doesn't need keys longer than 128 bits. The task of brute-forcing 2^128 different keys is out of reach for any known adversary. For extra safety sometimes one might want even longer key, such as 256 bits, but keys longer than that in a symmetric system are a sure sign that the designer didn't understand what he's doing. -- stanislav shalunov | Speaking only for myself. My address in From: is correct; if yours isn't, I don't want to hear from you. Try to reply in newsgroup. I don't need courtesy copies. -- Subject: Re: My STRONG data encryption algorithm From: stanislav shalunov [EMAIL PROTECTED] Date: Sun, 16 Apr 2000 17:19:18 GMT No, it's not strong. If you wish to receive further comments, post a short pseudo-code (or English) description of the algorithm. -- stanislav shalunov | Speaking only for myself. My address in From: is correct; if yours isn't, I don't want to hear from you. Try to reply in newsgroup. I don't need courtesy copies. -- From: Francois Grieu [EMAIL PROTECTED] Subject: Re: ? Backdoor in Microsoft web server ? [correction] Date: Sun, 16 Apr 2000 19:53:57 +0200 I'm glad I started the thread with a disclaimer. The text "Nescape engineers are weenies!" is indeed embedded [reversed] in the file dvwssr.dll coming with some Microsoft web server software for Windows 95/98 and NT 4 [not Windows 2000], and reportedly in file mtd2lv.dll coming with some corresponding web authoring tool. But contrary to some early press reports, evidence is this string is NOT a universal password, nor part of such a deliberate mechanism. My analysis of Microsoft's statements is - this string is "an obfuscation key to obscure the names of files being requested by the client from the server" while gathering information used to draw a site map. - knowledge of this algorithm and key only "allows a user who has privileges on a web server to read certain files from other web sites hosted on the same computer", and therefore the vulnerability only affects "customers who host more than one web site on a server". Still, it looks like Microsoft has distributed a product [reportedly acquired from another company] relying deliberately on obscurity for some of it's security features, a bad professional practice. Microsoft statements on dvwssr.dll issues are at http://www.microsoft.com/technet/security/bulletin/ms00-025.asp and http://www.microsoft.com/technet/security/bulletin/fq00-025.asp Understandably, the focus is on another vulnerability: a subsequently discovered potential for a buffer overrun, which can lead to a denial of service attack, or
