Cryptography-Digest Digest #470
Cryptography-Digest Digest #470, Volume #14 Tue, 29 May 01 10:13:01 EDT Contents: Re: Good crypto or just good enough? (Mark Wooding) Re: Medical data confidentiality on network comms (Larry Kilgallen) Re: Turbo Small Public Key Cryptosystem (Tony L. Svanstrom) Re: DES Crypto Myth?? (DJohn37050) Re: Turbo Small Public Key Cryptosystem (Tom St Denis) Re: Quantum Computers with relation to factoring and BBS (Bodo Moeller) Re: Good crypto or just good enough? (Mok-Kong Shen) NIST Rng Test Software (Brice) Re: Euroean commision will recommend all citizens to use encryption in email next week, because of echelon. (John Niven) Re: Euroean commision will recommend all citizens to use encryption in (Mok-Kong Shen) Re: NIST Rng Test Software (Mok-Kong Shen) Re: Cool Cryptography Website! (SCOTT19U.ZIP_GUY) Re: Discrete Log question (Lon Willett) Re: A new technology for internet security? (Mok-Kong Shen) Re: Cool Cryptography Website! (John Savard) Re: Good crypto or just good enough? (Eric Lee Green) Re: Good crypto or just good enough? (John Myre) Certicom's ECCp-109 Challenge (call for users) (Chris Monico) Re: A new technology for internet security? (Simon Josefsson) From: [EMAIL PROTECTED] (Mark Wooding) Subject: Re: Good crypto or just good enough? Date: 29 May 2001 09:18:57 GMT Scott Fluhrer [EMAIL PROTECTED] wrote: [1] Actually, that's obviously true of 3DES in EEE mode. It's almost certainly true of the more common EDE mode, although a proof of that eludes me at the moment. Hmm. Interesting. Of course, it'd be true of EDE with independent round keys (since the difference between encryption and decryption operations is the key-schedule only). -- [mdw] -- From: [EMAIL PROTECTED] (Larry Kilgallen) Crossposted-To: comp.security.misc Subject: Re: Medical data confidentiality on network comms Date: 29 May 2001 05:51:48 -0500 In article [EMAIL PROTECTED], Samuel Paik [EMAIL PROTECTED] writes: Larry Kilgallen wrote: But some of them are susceptible to cryptographic controls. Consider the issue of delegation. My doctor can see my medical records. My doctor should be able to delegate the ability to see those records to a specialist for a limited amount of time, but without delegating unlimited rights to further delegation. How? Isn't this yet another attempt at DRM or am I missing something? I have no idea what you mean by the abbreviation DRM, so let me try guessing what you may have been trying to say. Certainly anyone along the chain can photocopy a printout without control. The control to which I am referring is over _computer_ access to the records. When I visited my doctor last month she pulled up a graph of one of my medical statistics over time. She has no direct access to the data -- that access is only from the central computer when she logs in. She is not allowed in the computer room. I would prefer she logged in with a digital signature and released my records to a specialist only with a digital signature, but we are not there yet. As I said, n-out-of-m key splitting can be used for emergency room scenarios (with extensive alarming and notification to the patient and primary care physician). -- Subject: Re: Turbo Small Public Key Cryptosystem From: [EMAIL PROTECTED] (Tony L. Svanstrom) Date: Tue, 29 May 2001 10:53:54 GMT Tom St Denis [EMAIL PROTECTED] wrote: Tony L. Svanstrom wrote: Tom St Denis [EMAIL PROTECTED] wrote: I wrote a really super small PK system for *NIX today (in about 1.5 hrs) It uses DH and RC4 to encode/decode messages. It doesn't do signatures (what's the point?). It's very compact... in linux it builds to about 32kb in size and is very fast. You call that super small, wanna hear the size of the one I wrote in perl...?! hehe Um yes but recall that most of the 32kb is in fact library and object file overhead. My actual code is very small. I know, but real systems have perl installed, so... ;-) At anyrate I uploaded another copy that includes a readme :-) /Tony -- I'm sorry, I'm sorry; actually, what I said was: HOW WOULD YOU LIKE TO SUCK MY BALLS? - South Park - -- From: [EMAIL PROTECTED] (DJohn37050) Date: 29 May 2001 10:55:50 GMT Subject: Re: DES Crypto Myth?? Actually, among the real crypies that I know, he is not thought that highly of as a crypie. He is more of a collator and compiler. He does have access to some good crypies. Don Johnson -- From: Tom St Denis [EMAIL PROTECTED] Subject: Re: Turbo Small Public Key Cryptosystem Date: Tue, 29 May 2001 11:00:03 GMT Jack Lindso wrote: This isn't a solution, PGP
Cryptography-Digest Digest #470
Cryptography-Digest Digest #470, Volume #13 Mon, 15 Jan 01 03:13:01 EST
Contents:
Re: NSA and Linux Security (Rich W.)
Re: NSA and Linux Security (Rich W.)
Re: storing private keys ("Arnold Shore")
Failure discovered! (was Re: Security proof) (Benjamin Goldberg)
Re: The Word Problem and Group Isomorphism ("Ben Hopson")
Re: Security proof (Benjamin Goldberg)
Re: Security proof (David Wagner)
Re: Failure discovered! (was Re: Security proof) (David Wagner)
fun with solitaire ("r.e.s.")
Re: fun with solitaire (Mutt)
Re: fun with solitaire ("r.e.s.")
Re: Cavell Challenge #1 (Richard John Cavell)
Re: Cavell Challenge #1 ("John A. Malley")
Re: NSA and Linux Security (Shawn Willden)
Re: NSA and Linux Security ("Douglas A. Gwyn")
From: Rich W. [EMAIL PROTECTED]
Subject: Re: NSA and Linux Security
Date: Sun, 14 Jan 2001 17:27:05 -0500
The voices in my head tell me that
In article 93t4ch$7d5$[EMAIL PROTECTED],
[EMAIL PROTECTED] says...
Rich W. wrote:
Yes, be naive and say it can never happen here.
Actually, it already has happened here, to a limited extent.
SHAMROCK, MINARET, Watergate, and all that.
Read "The Puzzle Palace."
I read it. I'm on your side here.
Read http://www.wired.com/news/politics/0,1283,33026-2,00.html.
Read http://www.time.com/time/digital/daily/0,2822,12609,00.html.
(Some of these are about the NSA, some about the FBI. The point is
the same. If you think this couldn't possibly ever happen, think again.)
Legal procedures may be different now, but the general
reason for concern remains much the same, as far as I can see.
Agreed.
Rich...
--
From: Rich W. [EMAIL PROTECTED]
Subject: Re: NSA and Linux Security
Date: Sun, 14 Jan 2001 17:29:06 -0500
The voices in my head tell me that
In article [EMAIL PROTECTED], [EMAIL PROTECTED]
says...
Yes, but you're being naive in thinking that a person can have sole
control over these systems regardless of the structures built into the
agencies. Do you believe the presidents/PMs have total control of
governmental actions? Rubbish.
I suppose that the truth of your sentence, when applied
to any country, is conditioned on its status of democracy,
which, BTW, might vary with time, as history shows.
Exactly.
Who said we aren't going to get someone who's a little more ruthless
and grabs some power?
Have you learned nothing from history? I'm afraid I find you to be
more than frightening, and more than naive.
Rich...
--
From: "Arnold Shore" [EMAIL PROTECTED]
Subject: Re: storing private keys
Date: Sun, 14 Jan 2001 17:52:27 -0500
Do you really mean exactly what you say, "secure storage of private keys "?
FYI, I'm storing public keys on my server - the private key being a hash of
the userID and password, with the public key derived from that.
Arnold Shore
Annapolis, MD USA
--
From: Benjamin Goldberg [EMAIL PROTECTED]
Subject: Failure discovered! (was Re: Security proof)
Date: Sun, 14 Jan 2001 23:06:17 GMT
Sorry for the misleading subject line, David, but *you* didn't quite
discover a failure, but your post DID make me think of something which
led me to see a way in which the structure fails to be an SPRP.
David Wagner wrote:
Benjamin Goldberg wrote:
(t0, t1) = M(K0)(p0, p1)
(t2, t3) = M(K1)(p2, p3)
(t4, t5) = M(K2)(p4, p5)
(t6, t7) = M(K3)(p6, p7)
(u0, u2) = M(K4)(t0, t2)
(u1, u3) = M(K5)(t1, t3)
(u4, u6) = M(K6)(t4, t6)
(u5, u7) = M(K7)(t5, t7)
(c0, c4) = M(K8)(u0, u4)
(c1, c5) = M(K9)(u1, u5)
(c2, c6) = M(KA)(u2, u6)
(c3, c7) = M(KB)(u3, u7)
[Note: I changed your notation slightly.]
That's not a SPRP, either.
Let c0,..,c7 be the encryption of an arbitrary plaintext p0,..,p7.
Let c0',..,c7' be the encryption of a plaintext p0,..,p6,p7' differing
from the first plaintext only in the last word.
Right. Changing p7 changes t6..7, and u4..u7, and c0..c7. The complete
ciphertext changes if any one input word is changed.
Now, consider the decryption of the ciphertext
c0,c1',c2,c3',c4,c5',c6,c7'.
This deciphers to
(u0 , u4 ) = M(K8)^-1(c0 , c4 )
(u1', u5') = M(K9)^-1(c1', c5')
(u2 , u6 ) = M(KA)^-1(c2 , c6 )
(u3', u7') = M(KB)^-1(c3', c7')
(t0 , t2 ) = M(K4)^-1(u0 , u2 )
(t1', t3') = M(K5)^-1(u1', u3')
(t4 , t6 ) = M(K6)^-1(u4 , u6 )
(t5', t7') = M(K7)^-1(u5', u7')
(p0'', p1'') = M(K0)^-1(t0, t1')
(p2'', p3'') = M(K1)^-1(t2, t3')
(p4'', p5'') = M(K2)^-1(t4, t5')
(p6'', p7'') = M(K3)^-1(t6, t7')
This third plaintext will have the form p0,..,p5,?,?.
How do you figure that? You can't get p0 from
Cryptography-Digest Digest #470
Cryptography-Digest Digest #470, Volume #12 Thu, 17 Aug 00 19:13:01 EDT
Contents:
Re: blowfish problem (Gergo Barany)
Re: books (Ernest Dumenigo)
Re: 1-time pad is not secure... (Darren New)
Re: blowfish problem ("Michael Will")
Re: OT (Proposal of drafting rules of conduct of posting) (Mok-Kong Shen)
Re: Broadcast key Management (Jayant Shukla)
Re: blowfish problem ("Douglas A. Gwyn")
Re: DES: Say it or spell it? (Newbie question) ("Douglas A. Gwyn")
Re: blowfish problem (Gergo Barany)
Re: blowfish problem (Gergo Barany)
Re: 1-time pad is not secure... (Tim Tyler)
Re: DES: Say it or spell it? (Newbie question) (S. T. L.)
Re: Funny Observation (Tim Tyler)
From: [EMAIL PROTECTED] (Gergo Barany)
Crossposted-To: comp.lang.c
Subject: Re: blowfish problem
Date: 17 Aug 2000 20:12:38 GMT
Daniel Leonard [EMAIL PROTECTED] wrote:
I do not want to be rude, but there are some "errors" in your code.
I do not want to be rude, but your news software posts in some
funky "Quoted-Printable" encoding. It makes your posts hard to read
because it replaces many characters such as '=' with a code like
"=hex", where hex is a character's ASCII code in hexadecimal.
This stinks, please turn it off.
On 17 Aug 2000, John Hascall wrote:
=09out =3D malloc(inLen * 2 + 1);
shouldn't it be:
out =3D malloc((inLen * 2 + 1) * sizeof(char));
/* a char could be more than 1 byte */
No, a char is always one byte in C.
int hexDigit (
=09int=09fourBits
and here, shouldn't it be:
char hexdigit (
char fourBits
/* we use chars, we stay with chars */
If the poster of the code wants to use this broken algorithm, he
should probably use unsigned chars for fiddling with single bytes.
Otherwise, he should use printf() or a lookup table; see below.
) {
=09fourBits =3D 0x0f;=09=09=09=09/* safety first */
=20
=09return (fourBits 10) ? (fourBits + '0') : (fourBits - 10 + 'a');
}
Since you value portability highly, you should have jumped on this.
It relies on the assumption that the characters of the alphabet are
contiguous and in an ascending order in the execution character set.
This is not guaranteed by the standard, and by far not all C
programs run on ASCII machines.
Maybe something like this would be better:
char *hexits = "0123456789abcdef";
unsigned char hexdigit(unsigned char fourBits)
{
fourBits = 0xf;
return hexits[fourBits];
}
Gergo
--
Organic chemistry is the chemistry of carbon compounds. Biochemistry
is the study of carbon compounds that crawl.
-- Mike Adams
--
From: [EMAIL PROTECTED] (Ernest Dumenigo)
Subject: Re: books
Date: 17 Aug 2000 20:12:25 GMT
John A. Malley ([EMAIL PROTECTED]) wrote:
: Might I suggest
: "Cryptography, Theory and Practice" by Douglas R. Stinson,
: "Decrypted Secrets, Methods and Maxims of Cryptology" by F.L. Bauer,
: "Cryptanalysis, A Study of Ciphers and Their Solution" by Helen Fouche
: Gaines,
: "Applied Cryptography, Protocols Algorithms and Source Code in C" by
: Bruce Schneier,
: and either "Military Cryptanalysis Parts I, II, III and IV" by William
: F. Friedman
: or
: "Military Cryptanalytics, Part I, Vol. 1 and 2, and Part II, Vol. 1 and
: 2 " by
: William F. Friedman and L.D. Callimahos
: as a good start.
: (IMHO everything on cryptology from Aegean Park Press is worth reading,
: not just those last two entries in the list.)
: Any of these books are available from Barnes and Noble (bn.com) or
: Amazon.com.
: Aegean Park Press has its own web site at http://www.aegeanparkpress.com
: John A. Malley
: [EMAIL PROTECTED]
Thanks for the suggestions :-)
--
=
Ernest
--
From: Darren New [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
Subject: Re: 1-time pad is not secure...
Date: Thu, 17 Aug 2000 21:09:37 GMT
Tim Tyler wrote:
If following a MWI, there are many "me"s and many "post"s. All have
equal rights and status. By saying "this" post, you haven't uniquely
identified anything, since there are many posts which are all claiming
to be "this" post.
To be less silly (and to add something that should have been in the previous
post), if there's nothing random about MWI, what determines which
conciousness sees which pattern of random bits? Since the parallel worlds
cannot interact with each other once "collapsed", making a 2-bit random pad
gives you four worlds which do not communicate. Which one are "you" on, when
you look at the pad? Saying "all of them" doesn't help, because then you've
not only eliminated "random", you've eliminated "unpredictable", and since
everything now is predictable, you have eliminated "secr
Cryptography-Digest Digest #470
Cryptography-Digest Digest #470, Volume #11 Sun, 2 Apr 00 19:13:01 EDT
Contents:
Cryptography FAQ (05/10: Product Ciphers) ([EMAIL PROTECTED])
Crossposted-To: talk.politics.crypto,sci.answers,news.answers,talk.answers
Subject: Cryptography FAQ (05/10: Product Ciphers)
From: [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
Date: 02 Apr 2000 23:09:42 GMT
Archive-name: cryptography-faq/part05
Last-modified: 94/06/07
This is the fifth of ten parts of the sci.crypt FAQ. The parts are
mostly independent, but you should read the first part before the rest.
We don't have the time to send out missing parts by mail, so don't ask.
Notes such as ``[KAH67]'' refer to the reference list in the last part.
The sections of this FAQ are available via anonymous FTP to rtfm.mit.edu
as /pub/usenet/news.answers/cryptography-faq/part[xx]. The Cryptography
FAQ is posted to the newsgroups sci.crypt, talk.politics.crypto,
sci.answers, and news.answers every 21 days.
Contents:
5.1. What is a product cipher?
5.2. What makes a product cipher secure?
5.3. What are some group-theoretic properties of product ciphers?
5.4. What can be proven about the security of a product cipher?
5.5. How are block ciphers used to encrypt data longer than the block size?
5.6. Can symmetric block ciphers be used for message authentication?
5.7. What exactly is DES?
5.8. What is triple DES?
5.9. What is differential cryptanalysis?
5.10. How was NSA involved in the design of DES?
5.11. Is DES available in software?
5.12. Is DES available in hardware?
5.13. Can DES be used to protect classified information?
5.14. What are ECB, CBC, CFB, OFB, and PCBC encryption?
5.1. What is a product cipher?
A product cipher is a block cipher that iterates several weak
operations such as substitution, transposition, modular
addition/multiplication, and linear transformation. (A ``block
cipher'' just means a cipher that encrypts a block of data---8 bytes,
say---all at once, then goes on to the next block.) The notion of
product ciphers is due to Shannon [SHA49]. Examples of modern
product ciphers include LUCIFER [SOR84], DES [NBS77], SP-networks
[KAM78], LOKI [BRO90], FEAL [SHI84], PES [LAI90], Khufu and Khafre
[ME91a]. The so-called Feistel ciphers are a class of product
ciphers which operate on one half of the ciphertext at each round,
and then swap the ciphertext halves after each round. LUCIFER,
DES, LOKI, and FEAL are examples of Feistel ciphers.
The following table compares the main parameters of several product
ciphers:
cipher | block length | key bits | number of rounds
LUCIFER 128 12816
DES 645616
LOKI 646416
FEAL 64 1282^x, x = 5
PES 64 128 8
5.2. What makes a product cipher secure?
Nobody knows how to prove mathematically that a product cipher is
completely secure. So in practice one begins by demonstrating that the
cipher ``looks highly random''. For example, the cipher must be
nonlinear, and it must produce ciphertext which functionally depends
on every bit of the plaintext and the key. Meyer [MEY78] has shown
that at least 5 rounds of DES are required to guarantee such a
dependence. In this sense a product cipher should act as a ``mixing''
function which combines the plaintext, key, and ciphertext in a
complex nonlinear fashion.
The fixed per-round substitutions of the product cipher are
referred to as S-boxes. For example, LUCIFER has 2 S-boxes, and DES
has 8 S-boxes. The nonlinearity of a product cipher reduces to a
careful design of these S-boxes. A list of partial design criteria
for the S-boxes of DES, which apply to S-boxes in general, may be
found in Brown [BRO89] and Brickell et al. [BRI86].
5.3. What are some group-theoretic properties of product ciphers?
Let E be a product cipher that maps N-bit blocks to N-bit blocks.
Let E_K(X) be the encryption of X under key K. Then, for any fixed K,
the map sending X to E_K(X) is a permutation of the set of N-bit
blocks. Denote this permutation by P_K. The set of all N-bit
permutations is called the symmetric group and is written S_{2^N}.
The collection of all these permutations P_K, where K ranges over all
possible keys, is denoted E(S_{2^N}). If E were a random mapping from
plaintexts to ciphertexts then we would expect E(S_{2^N}) to generate
a large subset of S_{2^N}.
Coppersmith and Grossman [COP74] have shown that a very simple
product cipher can generate the alternating group A_{2^N} given a
sufficient number of rounds. (The alternating group is half of the
symmetric group: it consists of all ``even'' permutations, i.e., all
permutations which can be written as an even number
Cryptography-Digest Digest #470
Cryptography-Digest Digest #470, Volume #10 Sat, 30 Oct 99 02:13:03 EDT Contents: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Re: Preventing a User from Extracting information from an Executable Re: Bruce Schneier's Crypto Comments on Slashdot Re: Proposal: Inexpensive Method of "True Random Data" Generation (Boaz Lopez) Re: the ACM full of Dolts? (SCOTT19U.ZIP_GUY) Re: Build your own one-on-one compressor (SCOTT19U.ZIP_GUY) Re: Compression: A ? for David Scott (SCOTT19U.ZIP_GUY) Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column (David Wagner) From: [EMAIL PROTECTED] () Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: 30 Oct 99 03:00:08 GMT Terry Ritter ([EMAIL PROTECTED]) wrote: : On Tue, 26 Oct 1999 21:54:03 GMT, in : [EMAIL PROTECTED], in sci.crypt : [EMAIL PROTECTED] (John Savard) wrote: : (perhaps it is cumbersome : and impractical, : I suppose TCP/IP might be called "cumbersome and impractical" -- until : one starts to feel the advantages. Once a dynamically changing cipher : scheme is programmed, there should be little need for intrusion into : applications or users. : The dynamically changing cipher scheme may be complicated for some : people to think about, but that is mainly an issue for implementors. It will require the availability of hardware resources which are, in some contexts, nontrivial. : perhaps the effort involved is not worth it for the : security improvement it can bring - because the improvement in : security is not that badly needed, : If you could tell us what level of security you get from your favorite : cipher, then we could decide whether dynamically changing ciphers : improved things for you or not. : Alas, we cannot know how much security your cipher provides. Neither : can you, neither can anyone else. Well, the consensus in the academic community, wrong-headed or not, is that ciphers like the current AES finalists provide an *awful lot* of security. You're right: they can't prove that this is correct. Unfortunately, I can't prove them wrong either, not having an effective cryptanalytic attack against MARS or Twofish up my sleeve. So I can't reasonably argue that something like your multi-ciphering proposal *is* necessary - even if I have to admit, on the other hand, that, as far as I know, if *might* be. : By making the use of a "strong" cipher mandatory, : as I've advocated, if worst comes to worst the weak ciphers are still : adding to strength, by supplying whitening, at the least, for the : strong ciphers. : As there is no practical cipher which is known to be strong, this : hardly makes any sense at all. Translated for the uninitiated: this is based on considering the one-time-pad to be impractical, and even ciphers like Blum-Blum-Shub to not be *proven* strong. But actually, my proposal *does* make a lot of sense; however, I will reword it slightly to make it more valid from your viewpoint. Make mandatory the use of a cipher known _not to be trivially weak_; one cipher from a set that has recieved intensive analysis. Those ciphers are going to be in short supply for quite some time, as much as we might wish otherwise. : At worst - whitening. At best, an enormous increase in the difficulty : of analyzing the cipher stream. (Note that since our negotiation : occurs under a single cipher, not a variable one, quintuple encryption : under the five ciphers believed strongest would not be inappropriate.) : The idea _is_ a very promising one, even if it is not suitable for all : applications, and even though it does require that some caution be : taken when working out the basic design. : Yes, of course. I know that I can hardly claim to be on your side here - when it comes to the old guard and the mavericks, I have a foot in both camps. But I do hope to deal with those criticisms of your concept which I can easily, directly, and convincingly show to be unjustified. John Savard -- From: [EMAIL PROTECTED] () Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: 30 Oct 99 03:03:33 GMT David Wagner ([EMAIL PROTECTED]) wrote: : Hmm. I didn't realize that was what you meant by a non-cryptographic : negotiation. If it's encrypted, it sounds cryptographic to me. Although it was noted early on as being encrypted, I think the intent was to state that the protocol need not be an elaborate one with special properties; except for being enciphered, other special measures do not seem to be obviously required. John Savard -- From: [EMAIL PROTECTED] (
Cryptography-Digest Digest #470
Cryptography-Digest Digest #470, Volume #9 Tue, 27 Apr 99 10:13:03 EDT
Contents:
Re: True Randomness The Law Of Large Numbers (Herman Rubin)
Re: Amature information on cryptography? (CryptoBook)
Re: Obvious flaws in cipher design (Sandy Harris)
Re: Obvious flaws in cipher design (Sandy Harris)
Computing the run time for NFS. ("Steven Alexander")
Re: RSA-Myth (Anonymous)
S-Boxes ("Ruppert")
Re: scramdisk for AMAN ("Sam Simpson")
about analysis (let's see if I can explain this better...)
([EMAIL PROTECTED])
Re: Papers on RC4 key size (Nathan Kennedy)
Re: Papers on RC4 key size ([EMAIL PROTECTED])
Re: S-Boxes ("Douglas A. Gwyn")
Re: True Randomness The Law Of Large Numbers (R. Knauer)
Re: True Randomness The Law Of Large Numbers (R. Knauer)
Re: FSE-6 Report: Slide Attack (Patrick Juola)
From: [EMAIL PROTECTED] (Herman Rubin)
Subject: Re: True Randomness The Law Of Large Numbers
Date: 26 Apr 1999 20:06:43 -0500
In article [EMAIL PROTECTED],
R. Knauer [EMAIL PROTECTED] wrote:
On 25 Apr 1999 11:01:32 -0500, [EMAIL PROTECTED] (Herman
Rubin) wrote:
You have suggested taking approximations as exact.
When we were discussing the specification, we were talking about the
ideal. When we were talking about an actual TRNG, we were talking
about an approximation that was reasonably certain to be a
representation of the ideal.
The precision desired here is comparable to that for a wheel,
and the accuracy available from measurement is far less.
--
This address is for information only. I do not claim that these views
are those of the Statistics Department or of Purdue University.
Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907-1399
[EMAIL PROTECTED] Phone: (765)494-6054 FAX: (765)494-0558
--
From: [EMAIL PROTECTED] (CryptoBook)
Subject: Re: Amature information on cryptography?
Date: 27 Apr 1999 01:10:41 GMT
In article 9o5V2.12119$[EMAIL PROTECTED], "Dan"
[EMAIL PROTECTED] writes:
I am looking for information on encrypting text strings.
I would prefer to find some sample source code written in Visual Basic as I
haven't yet learned C or C++ As the subject suggests I am an amature at
cryptography, I have wrote some very simple character shifting code (I
hesitate to call it a cypher) but we all have to start somwhere right? What
I am doing is encrypting fields in a Microsoft Access database for use with
a program I am writing.
The following book from the CCB catalog may be of interest:
Learn Encryption Techniques with BASIC and C++
by Gilbert Held
The development of computer programs to encipher and decipher messages by
classical techniques is the primary focus of this book. A distinctive feature
is the use of two different programming languages, Microsoft QuickBasic and
Visual C++, for all program examples. In eight chapters, the author covers:
Technology and Terminology, Monoalphabetic Substitution Concepts, Keyword-Based
Monoalphabetic Substitution, Transposition-Based Monoalphabetic Substitution,
Polyalphabetic Substitution, Using Random Numbers, Developing Practical
Programs, Public Key Encryption. An appendix describes the contents of the
companion CD-ROM (i.e., source code listings and executables for all programs).
Wordware Publishing, 1999, xiv + 402 pp, CD-ROM.
Softbound: Pub. $39.95, ACA Member $30.95
Member prices are available to members of the American Cryptogram Association,
the US Naval Cryptologic Veterans Association, and full time students. A
shipping and handling charge applies to each order. Visa and MasterCard are
accepted. For complete ordering information, a free catalog of crypto books
stocked, or for information about membership in the American Cryptogram
Association, please send email to [EMAIL PROTECTED]
Best Wishes
Gary Rasmussen
Classical Crypto Books
E-Mail: [EMAIL PROTECTED]
Fax: (603) 432-4898
--
From: [EMAIL PROTECTED] (Sandy Harris)
Subject: Re: Obvious flaws in cipher design
Date: Tue, 27 Apr 1999 01:40:29 GMT
[EMAIL PROTECTED] (Jaime Suarez) writes:
Let's say that I am an amateur cryptographer and have written -just for the
fun of it- an algorithm. I would like the group to explain me their 'top ten'
reasons to see that it has obvious flaws. For example looking only at the
output it shouldn't compress very much, right?
It shouldn't compress at all. It should be indistinguishable from
random noise. Any pattern is a weakness.
or maybe change some bits of the input and see how the output comes out?
For a block cipher, change one bit of either input or key and about
half the output bits should change. This should be true after far
fewer rounds than the actual cipher uses.
For a stream cipher, changing one bit of key should change the
output a lot also.
And what should I avoid in the algorithm itself?
