Cryptography-Digest Digest #962
Cryptography-Digest Digest #962, Volume #13 Wed, 21 Mar 01 14:13:01 EST
Contents:
Re: Most secure way to add passphrase verification to "CipherSaber"
(SCOTT19U.ZIP_GUY)
Re: BBS ("Dobs")
Re: Advice on storing private keys (those who know me have no need of my name)
Re: I was so so right about PGP ... so right when I started writing (Frank Gerlach)
Re: redodancy ("Tom St Denis")
Re: Advice on storing private keys (those who know me have no need of my name)
Re: How to eliminate redondancy? (moving steadily towards being computer science
terminology) ("Tom St Denis")
Re: BBS ("Tom St Denis")
Re: RC4 test vectors after gigabyte output?. (those who know me have no need of my
name)
Re: I was so so right about PGP ... so right when I started writing about PGP and
about one author so right . ("Tom St Denis")
Re: RC4 test vectors after gigabyte output?. ("Tom St Denis")
Re: What do we mean when we say a cipher is broken? (David Wagner)
Re: What do we mean when we say a cipher is broken? (David Wagner)
Re: Fast and Easy crypt send (amateur)
Re: redodancy (amateur)
Re: What happens when RSA keys don't use primes? ("Kristopher Johnson")
Re: How to eliminate redondancy? (Benjamin Goldberg)
Re: What happens when RSA keys don't use primes? ("Tom St Denis")
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Most secure way to add passphrase verification to "CipherSaber"
Date: 21 Mar 2001 17:32:14 GMT
[EMAIL PROTECTED] (John L. Allen) wrote in
[EMAIL PROTECTED]:
I was thinking about adding some rudimentary passphrase (Key)
verification check capability to the CipherSaber protocol (see
http://ciphersaber.gurus.com/). So, among the following choices, Which
of these message streams is most secure as a means of providing a way
for the decryptor to verify the correctness of the decryption Key
without giving an attacker useful info:
0. IV, E(msg) # This is the current
CipherSaber protocol
1. IV, E(IV), E(msg) # bad: "known plaintext"
2. IV, E(E(IV)), E(msg)
3. IV, E(E(msg{1..10})), E(msg)# bad: "known plaintext"
4. IV, E(E(E(msg{1..10}))), E(msg)
5. IV, H(msg{1..64}), E(msg)
6. IV, E(H(msg{1..64})), E(msg)
7. IV, E(Key), E(msg)
8. IV, H(Key), E(msg)
9. IV, E(H(Key)), E(msg)
Where, IV is a random initialization vector.
E() is an encryption algorithm using key Key.
H() is a hash function.
msg is the message
msg{1..N} is the first N bytes of the message.
Also, if a hash function is not available, what is the best way then?
I lean toward #9 if a hash is available, otherwise, maybe #2 or #4.
Encrypting the key and sending that as in #7 doesn't _look_ too good at
first, but is it really that bad?
John.
There are other ways to add security that gives no information
to an attacker. I will post a way on the net in a few days. It
will be different than the method I posted at the gov AES site.
but will be of possible use by you. I can give you the basic flow
of it. Howeve it will increase the time to encrypt and decrypt
plus it makes it an 'ALL or Nothing type of encryption" Here is
basic flow. For one assume a message composed in only a subset
of characters.
You have a messeage composed of ony certain characters.
1) you compress it using my compress h2comaf.exe
this makes a special FOF file on output.
or alternatively. You have a file that is a binary file of any
number of 8-bit bytes or you convert to a file or that form and
then run my program hat converts it to a FOF file.
2)You know run my code to convert a FOF file to binary file
that has form where at least one field exists and is 6 bytes
long and rest of fields if they exist is 1 byte in length each.
3) this is phase where you add the authentication and identity
check. You as a user has a secrect auth code which is a series
of values 0-5 in value. For this example say 4 digits of 1 2 3 5
Now you call rotatan and apply the first rotation to the file
and then uses DSC to bind the number in the file.
You repeat above so it occurs 4 times with each of the values above.
4) at this point you still will have a file of at least 6 bytes
where every possible value is possible. run my code to map to
FOF files.
5) run h2uncaf.exe to uncompress the file. Where the condition
file is the set of all 256 bit possible valuses. The ouput
file is a normal byte type of file.
6) run reverse and then compress with h2com.exe you know have
a normal binary byte file of any possiable value.
*
here you need an encryption program that is fully bijective
from 8 bit binary files to 8 bit binary files
***
the resulting ouput can be any 8- bit byte type of file
Cryptography-Digest Digest #962
Cryptography-Digest Digest #962, Volume #12 Thu, 19 Oct 00 21:13:01 EDT
Contents:
Re: old factoring tricks (Tom St Denis)
Re: Enigma: Stolen German Code Machine Turns Up in BBC Mailroom (David Schwartz)
Re: Encrypting large blocks with Rijndael (John Myre)
Re: Encrypting large blocks with Rijndael (David Crick)
Re: Encrypting large blocks with Rijndael (Tom St Denis)
Re: old factoring tricks (Tom St Denis)
Re: BIOS password, will it protect PC with PGPDisk against tampering ? ("Jonathan")
Re: srp-1.6.0 released (Thomas Wu)
Re: Encrypting large blocks with Rijndael (John Myre)
Re: Encrypting large blocks with Rijndael (John Myre)
10/21/2000 4 pm Computer History Lecture: Anthony Sale on Computer Conservation
the Rebuild of Colossus (Eugene Miya)
Re: old factoring tricks ("bubba")
Re: Encrypting large blocks with Rijndael (Tom St Denis)
Re: What is desCDMF? (Tom St Denis)
Re: As I study Rinjdael... (Eric Lee Green)
Re: What is desCDMF? ([EMAIL PROTECTED])
Re: As I study Rinjdael... (Sundial Services)
From: Tom St Denis [EMAIL PROTECTED]
Subject: Re: old factoring tricks
Date: Thu, 19 Oct 2000 21:57:11 GMT
In article [EMAIL PROTECTED],
[EMAIL PROTECTED] wrote:
Pollard rho works on the cycles of N. If N=PQ then cycles mod P and
mod
Q are important. Roughly these are about Sqrt(P) or Sqrt(Q)
respectively
(with some constants), or approximately N**(1/4).
For 79 bits, you should need about 2^20 cycles.
Are you sure you meant 79 bits and not 79 digits?
Eerr.. ya 79 bits... on my Celeron 400 it took 251 seconds to factor...
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
--
From: David Schwartz [EMAIL PROTECTED]
Crossposted-To: talk.politics.crypto
Subject: Re: Enigma: Stolen German Code Machine Turns Up in BBC Mailroom
Date: Thu, 19 Oct 2000 15:05:47 -0700
David Schwartz wrote:
Try to brute force the machine. Remember, for each of the 26^4 possible
keys, you have (26!)^4 possible rotor hookups. Break, yes. Brute force,
no. As far as I know, the rotor wirings were never made public.
It has come to my attention that the rotor wirings of this machine have
in fact been made public in their entirety. So stealing the machine
would yield no information that would assist you in breaking any
messages encoded with it. With or without the machine, you could easily
brute force any key in under 2^19 operations.
DS
--
From: John Myre [EMAIL PROTECTED]
Subject: Re: Encrypting large blocks with Rijndael
Date: Thu, 19 Oct 2000 16:12:00 -0600
John Myre wrote:
Rijndael is defined (almost*) to work on blocks of any
snip
I meant to note that the ShiftRow constants would have
to be defined for larger sizes.
JM
--
From: David Crick [EMAIL PROTECTED]
Subject: Re: Encrypting large blocks with Rijndael
Date: Thu, 19 Oct 2000 23:27:17 +0100
John Myre wrote:
(Each round does work proportional to the block size,
which cancels out the advantage gained by encrypting
fewer blocks.)
[..]
Under what circumstances would one be willing to pay
this speed penalty?
Security.
If I remember correctly, the increase in number of rounds
in proportion to the key or block size is due to the fact
that with larger key/blocks the diffusion is slower.
Hence the increase in rounds - to increase the diffusion,
or at least, to maintain the same amount of diffusion at
larger sizes.
--
+---+
| David A. Crick [EMAIL PROTECTED] PGP: (OCT-2000 KEY) 0xE0F73D98 |
| Damon Hill Tribute Site: http://www.geocities.com/MotorCity/4236/ |
| M. Brundle Quotes: http://members.tripod.com/~vidcad/martin_b.htm |
+---+
--
From: Tom St Denis [EMAIL PROTECTED]
Subject: Re: Encrypting large blocks with Rijndael
Date: Thu, 19 Oct 2000 22:17:35 GMT
In article [EMAIL PROTECTED],
John Myre [EMAIL PROTECTED] wrote:
Rijndael is defined (almost*) to work on blocks of any
size that is a multiple of 32 bits. However, the rule
for the number of rounds based on the block size means
that encrypting a single large block is much slower than
encrypting it piecewise with one of the standard modes.
(Each round does work proportional to the block size,
which cancels out the advantage gained by encrypting
fewer blocks.)
For example, encrypting 256 bits at a time instead of
128 would require 14 rounds instead of 10, and so it
would be 40% slower.
It's not that easy. In the 14 rounds of 256-bit block Rijndael you are
handling more information... thus it's not 40% slower...
Similarly, (if I did my arithmetic right) encrypting a
512 byte block in a single call would be 13.4 times slower
than encrypting it with
Cryptography-Digest Digest #962
Cryptography-Digest Digest #962, Volume #8 Mon, 25 Jan 99 15:13:03 EST
Contents:
Re: Metaphysics Of Randomness (Patrick Juola)
Re: Sanity check on authentication protocol (Edward Keyes)
Re: Metaphysics Of Randomness (Patrick Juola)
Re: Help: Which secret key cipher? ("Trevor Jackson, III")
Re: [req]:Cryptanalysis tool - word pattern table ("Dave Smith")
Re: Metaphysics Of Randomness (Patrick Juola)
Re: Random numbers generator and Pentium III (Mok-Kong Shen)
Random numbers generator and Pentium III (student)
Re: Metaphysics Of Randomness (Alan DeKok)
Re: All 8 modes, was Re: 3DES in EDE mode versus EEE mode (Mok-Kong Shen)
Re: All 8 modes, was Re: 3DES in EDE mode versus EEE mode
([EMAIL PROTECTED])
Re: Random numbers from a sound card? (Mok-Kong Shen)
From: [EMAIL PROTECTED] (Patrick Juola)
Subject: Re: Metaphysics Of Randomness
Date: 25 Jan 1999 08:47:10 -0500
In article [EMAIL PROTECTED], Boson [EMAIL PROTECTED] wrote:
Your over-use of the adjective "true" is a gradeschool error. Next we
will need super-duper random number generators: SDRNG. Then Ultra-Pure
Random Number Generators: UPRNG.
If I gave you two sequences, could you clasify them as coming from a RNG
vs. a TRNG?
Possibly not. But, on the other hand, if you gave me a sequence, it
would be useless for cryptographic purposes -- for all I know, you give the
same sequence out to any yahoo that asks for it. The question is whether
or not I could reproduce that sequence by breaking into your office -- or
whether I could have five friends buy a sequence from you and then
as a result, I could enumerate your sequence space and figure out the
variety of sequences you have for sale.
You can't evaluate a sequence based only on the sequence. For crypto
purposes, you have to look at the generator as well.
No. A random number generator produces random sequences of
numbers.
Yes. But are they random *ENOUGH*? Unless you really know what you
are doing, then the answer is probably "no."
Or to put it another way, a linear congruential random number generator
also produces random sequences. But all the randomness is contained
in your choice of seeds
-kitten
--
From: [EMAIL PROTECTED] (Edward Keyes)
Subject: Re: Sanity check on authentication protocol
Date: Sun, 24 Jan 1999 14:38:26 -0500
In article [EMAIL PROTECTED], Antti Huima
[EMAIL PROTECTED] wrote:
This protocol can be summarized as follows:
A -- B:A, R_A
B -- A:{K, R_A, R_B}_S
A -- B:{R_B}_S
Here S = the shared secret key, R_A = Alice's random number, R_B =
Bob's random number, K = the new session key.
In principle this resembles much the Needham-Schroder public-key
protocol which was shown to be flawed by Gavin Lowe. However, the
usage of symmetric encryption adds in principle an implicit
authentication of the second message, assuming that `S' is known by
Alice and Bob alone. This seems to fix the problem with the NS
protocol.
The messages 2 and 3 must be accompanied with strong MACs based on the
shared secret. Without MACs the protocol is not trustworthy.
Thanks. Good point.
Observe also that Bob can be used as an oracle to generate an
unlimited number of known plaintext-ciphertext pairs (send A, R_A to
Bob and you get {*, R_A, *}_S). This is a bad thing.
How bad of a thing is this, since each message will contain a large
amount of unknown random data as well (the newly-generated session
key and R_B)? Can this be fixed by doing something stronger than
concatenation, like bit-interleaving? Or is it just a matter of
"leaking" a certain amount of info with every message?
There is also a possibility to lure Alice into believing that she is
communicating with Bob even if Bob has disappeared from the Universe.
Two protocol runs are interleaved; the protocol numbers are shown in
square brackets:
[1] A -- B: A, R_A
[2] I -- A: B, R_A
[2] A -- I: {K, R_A, R_A'}_S
[1] I -- A: {K, R_A, R_A'}_S
[1] A -- I: {R_A'}_S
Here Alice believes incorrectly that the fourth message comes from
Bob, when it is as a matter of fact generated by herself. This is a
problem caused by the use of symmetric cryptography. Of course, here I
does not still know K and is thus not able to continue with the
communications.
Ah... that is a good point. Thank you. The intended application was
to have the protocol be explicitly client-server, so only Bob generates
session keys. It's good to know that if this is not the case that
authentication problems arise.
I'm definitely glad I posted this... :)
+ Edward Keyes, [EMAIL PROTECTED] -+
| http://web.mit.edu/eakeyes/www/ |
| DaggerWare: "small, sharp, and with a heck of a point!" |
+- &
