Cryptography-Digest Digest #564
Cryptography-Digest Digest #564, Volume #14 Fri, 8 Jun 01 07:13:00 EDT Contents: Re: Best, Strongest Algorithm (gone from any reasonable topic) (Vincent Quesnoit) Re: Algorithms (Tom St Denis) Re: MD5 for random number generation? (Tom St Denis) Re: Notion of perfect secrecy (Tom St Denis) 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) (Tom St Denis) 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: Simple C crypto (Tom St Denis) Re: Simple C crypto (Tom St Denis) Re: Simple C crypto (Tom St Denis) Re: Help with Comparison Of Complexity of Discrete Logs, Knapsack, and Large Primes (Tom St Denis) Re: RSA's new Factoring Challenges: $200,000 prize. (Michael Brown) Re: Simple C crypto (Michael Brown) From: Vincent Quesnoit [EMAIL PROTECTED] Subject: Re: Best, Strongest Algorithm (gone from any reasonable topic) Date: Fri, 08 Jun 2001 11:29:17 +0200 Reply-To: [EMAIL PROTECTED] Tim Tyler a écrit : Mok-Kong Shen [EMAIL PROTECTED] wrote: : I was referring to the following that you wrote previously: :Yes it is. Consider BICOM for example. It can map a :8 bit cyphertext to one of some 2^128 plaintexts - :considerably more than your figure of 2^8. : Does the 2^128 come from using a 128 bit key for the : AES in it and there are 2^128 possible keys for AES? Yes. I am puzzled, I thought AES was a block cypher which could not produce a cypher text smaller than its own blocksize. Do you mean that AES can decrypt one byte and produce a 16 byte output ? -- From: Tom St Denis [EMAIL PROTECTED] Subject: Re: Algorithms Date: Fri, 08 Jun 2001 10:37:25 GMT abhijeet [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED]... Hi, I am writing my thesis on cryptography in Digital signature. Can anyone suggest me of any book or paper where I can get the full C or C++ code for the algorithms. thanking you regards What algorithms? Get Applied Cryptography -- Bruce Schneier Handbook of Applied Crypto -- CRC Press A Course in Number Theory and Cryptography -- Neal Koblitz and you will be all set -- From: Tom St Denis [EMAIL PROTECTED] Subject: Re: MD5 for random number generation? Date: Fri, 08 Jun 2001 10:39:43 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: : : Tim Tyler [EMAIL PROTECTED] wrote in message : : Tom St Denis [EMAIL PROTECTED] wrote: : : : Toby Sharp wrote: : : : I've heard of people using MD5 for random number generation. But, : : : as far as I can tell, MD5 is a one-way hash algorithm. How is : : : this used for random numbers? [...] : : : : Yeah, you have to make sure though, that your PRNG is forward and : : : backwards safe. [...] : : : So you could just use : : : : : H[i] = HASH(SEED || i) : : : : : Which is essentially a CTR mode of operation. : : : : It looks like you're thinking of state compromises that don't affect : : SEED. : : : : If you think SEED might also be compromised, backward secrecy is : : hardly possible (without a source of entropy anyway) - and the : : second equation offers no forward secrecy. : : : Here's a tip. Give some thought to what you post. : : : No PRNG is ever secure if the initial seed is compromised. The seed is : : what determines the PRNG output... : : Security in the face of state compromise is a very important part of : what forward secrecy in RNGs is all about. : Yes. And my PRNG I proposed is forward secure. : H[i] = HASH(SEED || I) : Suppose you guess H[i], how do you get H[i+1] or H[i-1]? You don't. However, say someone breaks into your office and wanders out with i and SEED. With this information they have access to all the past outputs of the RNG. This is known as a backtracking attack - and can be of significance if the RNG is used for key generation - since you don't want numerous past keys to be compromised by a single lapse of security on some future date. Backtracking attacks can be prevented - they are not inherent in all PRNGs. Which is why (if you well I dunno, ... er ... um READ MY ENTIRE POST) would have found that I said you should reset the seed whenever you make a new key. That way wandering into the office to get SEED will be a useless venture. : As for backward secrecy - this is (as I mentioned) impossible in a PRNG : whose state has been compromised. However, the OP never mentioned PRNGs. : Are you sure? Read
Cryptography-Digest Digest #564
Cryptography-Digest Digest #564, Volume #13 Fri, 26 Jan 01 21:13:00 EST
Contents:
Last revision ("lemaymd")
Re: solving simultaneous equations in modulo arithmetic ("Matt Timmermans")
Re: RSA Source code ("Adam Smith")
Re: Decode Algorythim ("Yeah")
Re: Steak Stream Cipher (Bryan Olson)
Random Number Generator ([EMAIL PROTECTED])
Re: Dynamic Transposition Revisited (long) (Terry Ritter)
Re: Paranoia ("Douglas A. Gwyn")
Re: Dynamic Transposition Revisited (long) (Terry Ritter)
Re: Random Number Generator ("Douglas A. Gwyn")
Re: Dynamic Transposition Revisited (long) ("Douglas A. Gwyn")
From: "lemaymd" [EMAIL PROTECTED]
Subject: Last revision
Date: Fri, 26 Jan 2001 18:31:18 -0600
Thanks for those final pieces of advice! I've modified my algorithm for
hopefully the last time using your suggestion and Joseph Ashwood's. He said
as I understand it that having eight encryption rounds doesn't do much
except slow my algorithm down. So without further ado, here it is:(an
excerpt from my documentation)
3. Description of algorithm
a. Key mutation
Encryption using the Bermuda Triangle 2.1 algorithm consists of several
steps consisting of XOR, rotate and addition operations, involving three key
derived values. It operates with 32768-bit plaintext and ciphertext blocks
controlled by a 32768-bit key, referred to as K0. The principal advantage
of this algorithm is the requirement that the entire key be known before any
decipherment can take place. This is insured by two key mutations,
described here.
The first key derivative is created by loading the first byte of K0, storing
it in a register and to memory, loading the next byte and XORing it against
the register containing the first byte, storing the register contents to the
next memory location and loading each subsequent byte in this manner, XORing
it against this register and storing it to memory. This key derivative is
referred to as K1. The original key, once again, is referred to as K0.
To form the second key derivative the entire key is loaded one byte at a
time from the end of the key to its beginning, stored to a register, XORed
and stored to a memory location as for K1. Note: the last byte in this
memory area will always equal the original key data. This key is referred
to as K2. These keys are now ready to be used in the encryption and
decryption processes.
b. Encryption
The actual encryption process involves one round of twelve XOR, addition and
bitwise rotation operations involving the three key mutations described
earlier and the original plaintext. The identification tag described in
section 2 is placed in the first twelve bytes of this file.
The steps involved are illustrated in this pseudocode segment:
Variables:
C Ciphertext
Kx Key "x"
P Plaintext
X Current byte position
Y Current key offset
Z General purpose register
C[x] = ( ( ( ( ( ( ( ( ( ( ( (
^ K2[y] ) + K1[y] ) K0[y] )
^ K1[y] ) + K2[y] ) K1[y] )
P[x] ^ Z ) + Z ) Z{5lsbits} )
^ K0[y] ) + K0[y] ) K2[y] )
Z = (Z^P[x])
Legend:
^ XOR
+ addition
rotate left
rotate right
"Scott Fluhrer" [EMAIL PROTECTED] wrote in message
news:94lo0p$j71$[EMAIL PROTECTED]...
lemaymd [EMAIL PROTECTED] wrote in message
news:94l9ds$k2m$[EMAIL PROTECTED]...
Poncho,
From what you've written, it's looks as though simplicity is not
this
cipher's weakness. What path would you suggest to strengthen it? I
don't
truly understand how you would retrieve a completely random key (which
of
course it's not, but for simplicity let's say it is) when you have only
the
ciphertext. Theoretically, as is the case with the true stream cipher,
one
XOR operation between the key and data should be sufficient to make an
entirely impossible to crack piece of ciphertext. Because of the huge
size
of the key utilized by this algorithm, it almost qualifies as a stream
cipher itself. Thanks for your valuable input! : - )
If an attacker had only one block of unknown plaintext, that would likely
be
the case. It would appear to be difficult to retrieve either the key or
the
plaintext, and it would obviously be totally impossible for an XOR
operation. However, if the attacker has multiple blocks encrypted under
the
same key, that changes radically. If you look at my suggested attack, you
use one block to guess key bits, and another block (or more likely,
several
blocks) to verify the guess.
As for what this cipher's weakness, it would appear to me caused by
several
things:
- Lack of diffusion between plaintext bits -- the value of one byte never
affects the value of another byte. This means (for example) if the
attacker
leaves that a plaintext "W" at offset 27 encrypts into the byte 0xf3, then
he knows that, for any other block, a ciphertext byt
Cryptography-Digest Digest #564
Cryptography-Digest Digest #564, Volume #11 Mon, 17 Apr 00 14:13:01 EDT
Contents:
Re: Paper on easy entropy ([EMAIL PROTECTED])
Re: Letter frequencies ("Rob Kings")
Re: ? Backdoor in Microsoft web server ? [correction] (Jerry Coffin)
Re: Why encrypt email... ("Rob Kings")
Re: Q: NTRU's encryption algorithm (Mike Rosing)
Re: AND on encrypted data (Mok-Kong Shen)
Re: GOST idea (Mok-Kong Shen)
Re: Paper on easy entropy (Mok-Kong Shen)
Re: GOST idea (Mok-Kong Shen)
Re: Paper on easy entropy (Mok-Kong Shen)
Re: Biggest Public-key Cryptography Crack Ever (Mike Rosing)
Re: ? Backdoor in Microsoft web server ? [correction] (Mike Rosing)
Re: For Mike Rosing (by JOKER) (Mike Rosing)
Re: Prngxor with substitution? (Mok-Kong Shen)
Re: Help with Exponentiation Cipher (Mark Wooding)
Re: AND on encrypted data (Jim Reeds)
Re: My STRONG data encryption algorithm ("John E. Kuslich")
Re: Regulation of Investigatory Powers Bill ("Stou Sandalski")
Re: ? Backdoor in Microsoft web server ? [correction] (Mok-Kong Shen)
Sony's Playstation2 export-controlled (Mok-Kong Shen)
Re: ? Backdoor in Microsoft web server ? [correction] (Mok-Kong Shen)
Re: Paper on easy entropy (Francois Grieu)
From: [EMAIL PROTECTED]
Subject: Re: Paper on easy entropy
Date: Mon, 17 Apr 2000 16:25:38 GMT
Trevor L. Jackson, III [EMAIL PROTECTED] wrote:
... but the rest of us may consider it a hostile act. TMK there is no
mechanism whereby a macro virus can infect a ps or pdf file.
Actually, postscript can be used to do ugly things to your printer or
typesetter, although I suppose it's not so much of an issue for
software. Really though, if this is an attempt to spread a macro
virus, he's aiming at a really small target. :)
The warning is prudent though, I tend to forget I have macros diabled.
--
Matt Gauthier [EMAIL PROTECTED]
--
From: "Rob Kings" [EMAIL PROTECTED]
Subject: Re: Letter frequencies
Date: Mon, 17 Apr 2000 17:23:45 +0100
A book with this information (including digraphs and trigraphs) is
Cryptanalysis by Helen Fouche Gaines. you can get it from www.amazon.co.uk
(.com) if you want it new or www.bibliofind.com if you don't mind an old
one.
Cheers
Rob
--
From: Jerry Coffin [EMAIL PROTECTED]
Subject: Re: ? Backdoor in Microsoft web server ? [correction]
Date: Mon, 17 Apr 2000 10:31:04 -0600
In article [EMAIL PROTECTED], [EMAIL PROTECTED]
says...
[ ... ]
How about having software certification by some official bodies?
To my knowledge, compilers of some programming languages could be
certified at some centres.
I doubt this would work nearly as well with security products as with
compilers. The difference is fairly fundamental: with a compiler you
have a well defined set of inputs that should be accepted, another
(usually somewhat less defined) set that should be rejected, a
reasonable definition of what a particular program should do, and so
on.
With security, things are a lot more wide-open. If you start with a
VERY small part of it that's well-defined, you can at least get
somewhere. For example, certifying that a particular product has a
correct implementation of SSL 3.0 or L2TP is probably possible.
Likewise, it would be quite easy to certify that a particular
implementation of an algorithm correctly encrypted/decrypted some set
of test vectors.
By itself those doesn't mean much though: if you can bypass the
encryption, it doesn't make much difference whether it was
implemented correctly. A spec like SSL defines a framework within
which it might be possible to produce a secure product, but a correct
implementation doesn't gurantee anything of the sort -- e.g. see the
Counterpane writeup on their cryptanalysis of MS's VPN code. The
code met the spec. The spec is good enough that a product CAN
implement it and (at least AFAIK) be reasonably secure. For better
or worse, it's quite apparently also possible to implement the spec,
and still have a terribly insecure product.
I doubt this is going to change anytime soon either: it's simply
impossible for anybody writing a spec to foresee all the says in
which a weenie might screw things up.
--
Later,
Jerry.
The universe is a figment of its own imagination.
--
From: "Rob Kings" [EMAIL PROTECTED]
Subject: Re: Why encrypt email...
Date: Mon, 17 Apr 2000 17:35:19 +0100
I agree with what a lot of the others have been saying. Most people do not
know enough about computers to understand the question of whether or not
they should use encryption. Many of my users (the National Health Service in
the UK) are still struggling with their word processor or spreadsheet, let
alone worrying about encryption.
In addition, it's difficult, at the moment, to make strong encrypti
Cryptography-Digest Digest #564
Cryptography-Digest Digest #564, Volume #10 Sat, 13 Nov 99 20:13:03 EST
Contents:
Re: PALM PILOT PGP found here (Keith Monahan)
Re: Public Key w/o RSA? (Scott Nelson)
Re: McAfee Fortress (Tom McCune)
Re: Specific use of a hash function ? (Henri)
Re: PGP ("Markku J. Saarelainen")
Re: RC4 Hardware implementation (Paul Koning)
Re: Proposal: Inexpensive Method of "True Random Data" Generation (Coen Visser)
Re: Proposal: Inexpensive Method of "True Random Data" Generation (Coen Visser)
Re: Proposal: Inexpensive Method of "True Random Data" Generation ("karl malbrain")
Re: SCOTT16U SOLUTION ON THE WEB (Boaz Lopez)
Re: S/MIME plug-in for Eudora? Strong Encryption (amateur)
REVIEW - Vulnerability of "Password Protection" Applets (Michel Dalle)
Re: ENCRYPTOR 4.0 by Comotex USA Inc. CRACKED !! (JPeschel)
Re: Need technique for about 24 bytes (Caesar Valenti)
Re: New Way To Prevent Employees From Vandalizing Files ("John E. Kuslich")
Re: Specific use of a hash function ? (Nicol So)
From: Keith Monahan [EMAIL PROTECTED]
Crossposted-To: alt.security.pgp,comp.sys.palmtops.pilot
Subject: Re: PALM PILOT PGP found here
Date: Sat, 13 Nov 1999 16:55:34 GMT
The extension is ".tgz" which stands for tar gzipped.
So, to expand, first use gzip (gnu gzip), then use tar.
Under unix, commands are "gzip -d filename.tgz", then "tar -xvf filename.tar"
or under windows, most of the popular 'zip' packages support it directly,
Under my WinZip version 7.0, it automatically de-gzip's and de-tars it.
If you need additional help, feel free to email me.
Keith
Brian S. Jones wrote:
What can expand the ".tqz" archives?
TIA,
B
On 12 Nov 1999 16:05:07 GMT, [EMAIL PROTECTED] (Keith A Monahan) wrote:
I know a bunch of people (including myself) were looking for PGP
for their 3com Palm Pilots. You can find it at the following URL
which is at the North American Cryptography Archive, which is great
for everything, in addition to this. I have not tried this yet,
since I just found it.
http://cryptography.org/crypto/hnKpw9sv/pgp/palmopgp/
It looks like it's based on the SSLEAY crypto libs. If you download
the latest version (1.2?), it includes source, and the executable(
a .prc file)
Hopefully deja or someone will archive this message - because finding this
up to this point has been a pain.
Keith
--
From: [EMAIL PROTECTED] (Scott Nelson)
Subject: Re: Public Key w/o RSA?
Reply-To: [EMAIL PROTECTED]
Date: Sat, 13 Nov 1999 17:01:29 GMT
On Sat, 13 Nov 1999 "Trevor Jackson, III" [EMAIL PROTECTED] wrote:
John Kennedy wrote:
On 12 Nov 1999 23:48:03 GMT, David A Molnar [EMAIL PROTECTED]
wrote:
And if so, then why is RSA in
particular so popular?
Name recognition. Ease of explanation. Ease of prototype implementation.
PGP used RSA. There's an entire company dedicated to commercializing RSA.
That kind of thing, I'd expect.
Well also RSA has been used more extensively than any othe public key
system and thus has a proven track record that other systems can't
match yet. That's worth something.
In what sense does PGP have a proven track record? I'd expect the people with
the resources to actually dent PGP to keep their mouths shut no matter how far
they got against it. Do you have authoritative information that indicates
that no one has dented PGP, or are you make the assumption based on the fact
that no one has made a credible claim to have done so?
There are a lot of people who would publish the results of
any attacks they found against RSA. Whether those people
have more or less resources than those who'd keep their mouths
shut is an open question, but the fact remains that the
publishers form a non-trivial group. RSA has received their
attention for a while, whereas brand new algorithms have not.
In that sense, RSA has a proven track record.
Scott Nelson [EMAIL PROTECTED]
--
From: Tom McCune [EMAIL PROTECTED]
Subject: Re: McAfee Fortress
Date: Sat, 13 Nov 1999 17:10:05 GMT
In article [EMAIL PROTECTED], [EMAIL PROTECTED] (Rebus777)
wrote:
Does anyone have any comments about the McAfee Fortress program? It uses
Blowfish with up to 448 bits, also DES and Triple DES. You can enter a
password/passphrase of up to 32 characters. This seems like it would be a
good program but I never heard of it until recently. Has anyone used this
program or know if its good or not?
Kris Hendricks
Are you refering to Strong Hold that comes with Nuts and Bolts Utilities?
Fortress is the newer name for Strong Hold.
-Tom
I use PGP for Privacy and Authenticity:
http://www.Tom.McCune.net/PGP.htm
--
From: Henri [EMAIL PROTECTED]
Subject: Re: Specific use of a hash function ?
Date:
Cryptography-Digest Digest #564
Cryptography-Digest Digest #564, Volume #9 Wed, 19 May 99 11:13:02 EDT Contents: Re: Security (Patrick Juola) From: [EMAIL PROTECTED] (Patrick Juola) Subject: Re: Security Date: 19 May 1999 09:57:51 -0400 In article 7hu5j2$qda$[EMAIL PROTECTED], [EMAIL PROTECTED] wrote: I think you are correct in that any algorithm will (potentially) leak some information, as it is not a OTP, but in the case of a well designed algorithm it might only allow the shaving of a bit off the key( or potentially less) in an idealized attack protocol. Cryptanalisys is the art of pulling every bit (or fraction thereof) of information leakage out of a cypher. Yes for any algorithm there will be a faster than brute force attack, but in the case of most well designed algoritims your ability to break a 128bit cypher in (2^126.98) trials with a space usage of the same is a useless break. Ah, but a break none the less. What I am saying is that since encryption is a deterministic process there will always exist a counter deterministic process. Since the key is actually used it's presence is measurable (often not enough tough), etc... etc... A cipher is only provably secure if all outputs are possible (random distribution based on the key) given any input. This is a stronger condition than necessary; all that is necessary is that for all plaintext p, the set of possible cyphertexts is the same (over all keys), irrespective of whether or not this actually exhausts the set of possible cyphertexts. For example, I could produce an OTP-variant in which each output bit is tripled before transmission; this means that some outputs are not possible (01010101001) but the cypher is nontheless provably secure. How do you create this random distribution in one round? If there are any one round characteristics (or linear approximations) chances are the algorithm can be cracked in reduced-round variants (and possible full-round). One obvious way to do it would be to insert random padding of some sort in order to exhaust the set of possible outputs. As an example, suppose that we agree to use a symmetric block algorithm, but every block that I send will contain only one actual data byte and the rest of the bytes will be randomly generated noise that I put in just to fool the cryptanalysts. Of course, you just throw away all this noise when you get it. And by careful design of the cypher, I can ensure that the property I outline above holds. -kitten -- ** 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 **
