Cryptography-Digest Digest #261, Volume #13 Sat, 2 Dec 00 21:13:01 EST
Contents:
Re: Newbie ("Michael")
Re: Newbie ("Michael")
CanCrypt: Canadian cryptographic resources ("M.S. Bob")
Re: Newbie ("Michael")
Re: Newbie ("Michael")
Re: Newbie ("Michael")
Re: Newbie ("Michael")
Re: Newbie (David Schwartz)
Re: Public key encryption in Javascript? (Benjamin Goldberg)
Re: Newbie ("Michael")
Revised cipher (Benjamin Goldberg)
Re: Newbie (David Schwartz)
I need to crack a key ([EMAIL PROTECTED])
Re: Newbie ("Michael")
Re: Newbie (Tom St Denis)
Re: File Deleter/Nuker ? (Tom St Denis)
Re: I need to crack a key (Tom St Denis)
Which Method ("Michael")
Re: Newbie ("Scott Fluhrer")
Re: JOB: Software Engineer : Security - Ohio (Jeffrey Williams)
----------------------------------------------------------------------------
From: "Michael" <[EMAIL PROTECTED]>
Subject: Re: Newbie
Date: Sun, 03 Dec 2000 00:15:03 GMT
Well, I don't think mine will stand up to THAT test.
The reason I questioned giving out the algorithm is because, to me, it seems
a HUGE 'leg up' if you are give the algorithm.
However, without the key and without the algorithm, I feel it is secure
against non crypto professionals.
I am still way down on the bottom of the learning curve!
:)
Michael
"Scott Craver" <[EMAIL PROTECTED]> wrote in message
news:90c05s$4vi$[EMAIL PROTECTED]...
> Michael <[EMAIL PROTECTED]> wrote:
> >What do you mean by "describe the algorithm?"
>
> Permit me to explain. The algorithm is the actual
> encryption method, minus the specific key used.
>
> Consider keyword alphabets, for instance. Take any word or
> phrase without duplicate letters, and follow it with the
> remaining letters of the alphabet in order:
>
> PRECAUTIONbdfghjklmqsvwxyz
> abcdefghijklmnopqrstuvwxyz
>
> Now you have a simple substitution cipher, in which
> "`Hurrah me soul' says I, shillelagh I let fly" encrypts to
> "`Isllpi fa mhsd' mpym O, mioddadpti O daq udy," for instance.
>
> The algorithm represents the whole process of turning
> the keyword PRECAUTION into a cipher alphabet, and encrypting
> with that alphabet. The actual word PRECAUTION is the secret
> key. Note that the key can change while the algorithm
> remains the same. This allows you to use a good cipher over
> and over, by changing the secret parameter.
>
> This particular example is very simple, and easy to crack.
> In a challenge, you'd provide (a) the encrypted message
> and (b) a description of the cipher like I did above, but
> not (c) the secret key word. A cryptanalyst would have to
> determine the original message without being given the key.
>
> -S
>
>
>
------------------------------
From: "Michael" <[EMAIL PROTECTED]>
Subject: Re: Newbie
Date: Sun, 03 Dec 2000 00:15:51 GMT
See my reply just before this one to explain why I questioned it.
"Tom St Denis" <[EMAIL PROTECTED]> wrote in message
news:90c09s$u4a$[EMAIL PROTECTED]...
> In article <YdfW5.84969$[EMAIL PROTECTED]>,
> "Michael" <[EMAIL PROTECTED]> wrote:
> > What do you mean by "describe the algorithm?"
>
> Just that. Describe the algorithm you used to encrypt the data.
>
> Tom
>
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.
>
------------------------------
From: "M.S. Bob" <[EMAIL PROTECTED]>
Subject: CanCrypt: Canadian cryptographic resources
Date: Sun, 03 Dec 2000 00:16:56 +0000
I have been updating CanCrypt, a directory of Canadian cryptographic
resources. It is intended to be a clearing house of Canadian related
cryptographic resources.
Canada is very crypto-friendly compared to both the USA (re: export) and
UK (re: RIP).
http://www.privacy.nb.ca/cancrypt/
If you have additions, please me know.
--
M Taylor mctaylor@ / privacy.nb.ca
------------------------------
From: "Michael" <[EMAIL PROTECTED]>
Subject: Re: Newbie
Date: Sun, 03 Dec 2000 00:23:22 GMT
Well, this may have been intended to make me feel a little bad.
But, since even *I* knew about the one time pads, I feel kinda good.
You give it a password.
You give it text.
It spits out numbers.
If you use a different password,
The same text.
The output is different.
The password length determines the level of encryption.
Double the length of the password, double the length of the encrypted data.
Given that no one but me has the algorithm, I still feel it is secure (as
keep the algorithm to my self.)
Thanks to all of you for tolerating me!
:)
Michael
"Steve Portly" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
>
>
> Michael wrote:
>
> > What do you mean by "describe the algorithm?"
> >
>
> Well so far you told us that it is based on complimentary numbers. Could
> be a classic one time pad system? If so I don't need to see the algorithm
> I can say it could be unbreakable (one time pad systems are covered in the
> FAQ).
>
>
------------------------------
From: "Michael" <[EMAIL PROTECTED]>
Subject: Re: Newbie
Date: Sun, 03 Dec 2000 00:27:20 GMT
Where do they post the algorithm for DES and RSA?
(you have peeked my interest in this area)
Michael
"Tom St Denis" <[EMAIL PROTECTED]> wrote in message
news:90c0an$u4i$[EMAIL PROTECTED]...
> In article <iffW5.84970$[EMAIL PROTECTED]>,
> "Michael" <[EMAIL PROTECTED]> wrote:
> > I am confused. Isn't it paramount to keep the algorithm secret?
>
> Absolutely not.
>
> Tom
>
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.
>
------------------------------
From: "Michael" <[EMAIL PROTECTED]>
Subject: Re: Newbie
Date: Sun, 03 Dec 2000 00:28:46 GMT
Well, as it said in earlier replies, I don't think mine will stand THAT
test.
Michael
"David Schwartz" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
>
> Michael wrote:
>
> > I am confused. Isn't it paramount to keep the algorithm secret?
>
> I had damn well better not be! Otherwise, anyone who knows the
> algorithm can compromise the security of anyone who uses the algorithm.
>
> DS
>
------------------------------
From: "Michael" <[EMAIL PROTECTED]>
Subject: Re: Newbie
Date: Sun, 03 Dec 2000 00:29:48 GMT
OK, thanks.
Michael
"Scott Craver" <[EMAIL PROTECTED]> wrote in message
news:90c0hv$532$[EMAIL PROTECTED]...
> Michael <[EMAIL PROTECTED]> wrote:
>
> >I am confused. Isn't it paramount to keep the algorithm secret?
>
> It is the secret key that must be kept secret. The
> algorithm itself is not something you can change often,
> and it is very, very realistic to assume that an
> adversary will learn which algorithm is being used.
>
> -S
>
>
------------------------------
From: David Schwartz <[EMAIL PROTECTED]>
Subject: Re: Newbie
Date: Sat, 02 Dec 2000 16:24:46 -0800
Michael wrote:
> Given that no one but me has the algorithm, I still feel it is secure (as
> keep the algorithm to my self.)
Is there some utility in being able to send secure messages to oneself?
DS
------------------------------
From: Benjamin Goldberg <[EMAIL PROTECTED]>
Subject: Re: Public key encryption in Javascript?
Date: Sun, 03 Dec 2000 00:45:08 GMT
Paul Rubin wrote:
>
> If you're trying to do it in perl, just use the Math::BigInt module
> that's part of the standard perl distribution (Camel book 2nd ed. p.
> 460). Doing a 512-bit modexp in the obvious way with that library
> takes a few seconds on a current x86 workstation.
One thing I don't like about perl's BigInt is that it stores numbers as
very long decimal numbers. Is there any chance of ever seeing a kind of
BigInteger package whose representation is packed integers? Besides
being inefficient in terms of size, calculating with decimal is slow.
If the operators are all done right, it could automatically convert
normal scalars to BigIntegers when one argument of +, -, *, /, %, etc is
a BigInteger, and the other is a scalar. Operator "" would convert to a
string, etc.
I don't have perl on my computer (I'll install it eventually), but I
think that the builtin operator 'vec' would probably very useful for
this package.
--
There are three methods for writing code in which no bug can be found:
1) Make the code so straightforward that there are obviously no bugs.
2) Make the code so complicated that there are no obvious bugs.
3) Insist that any apparent bugs were really intentional features.
------------------------------
From: "Michael" <[EMAIL PROTECTED]>
Subject: Re: Newbie
Date: Sun, 03 Dec 2000 00:45:55 GMT
I will give the program that uses the algorithm to my friends. It is up to
them to keep the program secure.
Given none of us are spies, I don't think physical security will be
compromised.
I will keep working on it as to facilitate a public program. I am just not
comfortable with that at this time. I have a long way to go in my learning.
THAT is why I am here asking questions. That is why I purchased books like
applied cryptography. But, I do have to go to work and such, so it is a
'poco a poco' kinda thing.
Michael
"David Schwartz" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
>
> Michael wrote:
>
> > Given that no one but me has the algorithm, I still feel it is secure
(as
> > keep the algorithm to my self.)
>
> Is there some utility in being able to send secure messages to oneself?
>
> DS
>
------------------------------
From: Benjamin Goldberg <[EMAIL PROTECTED]>
Subject: Revised cipher
Date: Sun, 03 Dec 2000 00:54:08 GMT
This is a multi-part message in MIME format.
==============6A401992C0FD19D1E350AD5A
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
I've done a bit of rewriting on the cipher I recently sent to this NG.
I've added a key schedule, and written the decryption function.
I'd like some suggestions on how to do differential cryptanalysis,
though. I've chosen 3 rounds, arbitrarily, so that I can test it, and
so that analysis can be done, but I'm certain that that's not enough.
Also, I've no idea how strong the key schedule is; I think it's
reasonably strong, but I'm not certain how to analyse it.
--
There are three methods for writing code in which no bug can be found:
1) Make the code so straightforward that there are obviously no bugs.
2) Make the code so complicated that there are no obvious bugs.
3) Insist that any apparent bugs were really intentional features.
==============6A401992C0FD19D1E350AD5A
Content-Type: text/plain; charset=us-ascii; name="bg1.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline; filename="bg1.txt"
/*
* bg1.txt, the first cipher of mine that is almost wholly mine :)
* Actually, it borrows some of it's design from AES. AES uses
* a linear step, a nonlinear step, and a key addition step; so
* does mine. I also use AES's sbox.
*
* AES transforms each and every byte in a nonlinear manner by
* putting it through an sbox. It then shuffles each of the 4
* rows of bytes, then does some linear transformation on the
* 4 columns of bytes. That's followed by key addition.
*
* My cipher, instead of using 4 rows and 4 columns of 8 bit bytes,
* conceptually divides one row of 16 bytes into 8 rows which each
* have 16 columns (with one bit per intersection). Each row is
* transformed in a linear manner by using it as the seed of an LFSR,
* and taking 16 consecutive outputs with a known starting position as
* the new value for the row. The columns are then mixed using a
* nonlinear sbox (the same sbox as AES, in fact). Key addition follows.
*
* Since each column is, in fact, one byte, and since the transformation
* is linear, it is easy to do columnular operations in parallel,
* eight operations at once, using the SIMD concept.
*
* Unlike AES's linear transformation, which is identical for all
* four columns, my 16 bit row transformation uses a different
* polynomial for each of the 8 rows.
*
* The polys were chosen to be as dense as possible (14 bits are set in
* each), but I wonder if it would be better to use just slightly less
* dense polynomials (10 or 12 bits set in each) picked to heighten the
* differences between rows, and have less predictible diffusion than
* the maximally dense polys.
*
* Note that, although AES cannot enciper completely arbitrarily sized
* blocks, my cipher can be made to work with a block of any size,
* provided you can find 8 distinct primitive polynomials of that size.
*
* You want 17 byte blocks? No problem... just pick your polys, adjust
* a few constants, and you're all set. Because of the requirement that
* at least 8 polys exist, the minimum blocksize is 7 bytes.
*
* You want to change your Rijndael (AES) implementation from 16 bytes
* to 17 bytes? No can do. Maybe 20 bytes, certainly 24 or 32, but
* there's no way for you to encrypt a prime number of bytes.
*
* Of course, a software implementation of gb takes O(N**2) time to
* encrypt an N byte block, so doing *big* blocks with this isn't
* advised. A hardware impl can do all of the linear transformations in
* parallel, so there *is* hope -- but I would advise that big blocks
* be encrypted using a cipher designed for big blocks. Another idea
* for a hardware impl, which would be infeasable in software -- don't
* bother with 16 rows of 8 bits each, just use one 128 bit row, if you
* can find an order 128 polynomial. Also, this method allows you to
* encrypt truly small blocks -- *any* integral number of bytes.
*
* Does anyone have a better name than gb? (which was a typo of bg, my
* initals) I'd like a name which reflects the structure of the ciper.
*/
typedef unsigned char uint8;
typedef signed char sint8;
#define ROUNDS 3 // Until I need to set it higher :)
#define SCHSIZE (16 * (ROUNDS+1)) // size of key schedule
uint8 mask[16] = {0};
// sbox and its inverse are the rijndael sboxes
uint8 sbox0[256], sbox1[256];
// Note that gb_init sets up both the sboxes and the polys, which
// are needed for the setup, for encrypt, and for decrypt.
// One could stick a call to it into in each of encrypt, decrypt,
// and setup, but since we can expect to not be able to encrypt
// without first doing setup, it's reasonable to *only* put it into
// gb_setup, and not slow down the encrypt and decrypt with something
// which is only needed once ever.
void gb_init() {
static int initialized = 0;
const int polys[8] = {
0xfdbf, 0xf7ef, 0xeff7, 0xdfef, 0xd7ff, 0xb7ff,
0xfff6, 0xfff5 };
uint8 pow[256], log[256];
int i, j, k;
if( initialized ) return;
for( i = 0; i < 8; ++i ) {
int poly = polys[i], j;
for( j = 0; j < 16; ++j )
mask[15-j] |= ((poly>>j)&1) << i;
}
for( i = 0, j = 1; i < 256; ++i ) {
log[pow[i] = j] = i;
j ^= (j << 1) ^ ((j & 0x80) ? 0x1b : 0);
}
for( i = 0; i < 256; ++i ) {
j = i ? pow[255 - log[i]] : 0;
k = ((j >> 7) | (j << 1)) ^ ((j >> 6) | (j << 2));
j ^= 0x63 ^ k ^ ((k >> 6) | (k << 2));
sbox1[sbox0[i] = j] = i;
}
initialized = 1;
}
#if _EiC
gb_init();
#endif
#if 1
#define DEBUGgb(vec,start) \
for( i = 0; i < 16; ++i ) \
printf("%02x", vec[i+start]); \
printf("\n");
#else
#define DEBUGgb(vec,start)
#endif
// gotos are evil in general, but I don't want to add
// another level of indentation for the rounds loop,
// and in this case, it doesn't hurt understandability.
void gb_encrypt( uint8 * txt, uint8 * key ) {
uint8 buf[48], r, i, j, k;
DEBUGgb(txt,0)
// Ooh yeah, love that prewhitening.
for( i = 0; i < 16; ++i )
buf[i] = txt[i] ^ *key++;
DEBUGgb(buf,0)
r = 0; round:
// Discard first 16 LFSR outputs, keep next 16
for( i = 0; i < 32; ++i ) {
for( j = 1, k = buf[i]; j < 16; ++j )
k ^= mask[j] & buf[i+j];
buf[i+16] = k; }
DEBUGgb(buf,32)
// Nonlinear column mix, and key addition.
for( i = 0; i < 16; ++i )
buf[i] = sbox0[ buf[i+32] ] ^ *key++;
DEBUGgb(buf,0)
if( ++r < ROUNDS ) goto round;
memcpy( txt, buf, 16 );
}
void gb_decrypt( uint8 * txt, uint8 * key ) {
uint8 buf[48], k;
sint8 r, i, j;
key += SCHSIZE;
memcpy( buf, txt, 16 );
DEBUGgb(buf,0)
r = ROUNDS; round:
// Key addition and nonlinear column mixing.
for( i = 15; i >= 0; --i )
buf[i+32] = sbox1[ buf[i] ^ *--key ];
DEBUGgb(buf,32)
// Run the LFSRs backwards 32 steps, keep 16 bits.
for( i = 31; i >= 0; --i ) {
for( j = 15, k = buf[i+16]; j > 0; --j )
k ^= mask[j] & buf[i+j];
buf[i] = k; }
DEBUGgb(buf,0)
if( --r > 0 ) goto round;
// Undo prewhitening.
for( i = 15; i >= 0; --i )
txt[i] = buf[i] ^ *--key;
DEBUGgb(txt,0)
}
// And here, the goto makes things much easier
// to read, and helps make it a tad more efficient.
void gb_setup( uint8 * ukey, uint8 * schedule ) {
uint8 tmp[ 16 + SCHSIZE ];
int r, i, j, k;
gb_init();
memset( schedule, 0, SCHSIZE );
memcpy( tmp, ukey, 16 );
r = 0; round:
for( i = 0; i < SCHSIZE; ++i ) {
for( j = 1, k = tmp[i]; j < 16; ++j )
k ^= mask[j] & tmp[i+j];
tmp[i+16] = k; }
for( i = 0; i < SCHSIZE; ++i )
schedule[i] ^= sbox0[ tmp[i+16] ];
if( ++r >= ROUNDS ) return;
// don't do this in the last round, because
// it wouldn't get used.
for( i = 0; i < 16; ++i )
tmp[i] = sbox1[ tmp[i + SCHSIZE - 16] ];
goto round;
}
==============6A401992C0FD19D1E350AD5A==
------------------------------
From: David Schwartz <[EMAIL PROTECTED]>
Subject: Re: Newbie
Date: Sat, 02 Dec 2000 16:52:53 -0800
Michael wrote:
> I will give the program that uses the algorithm to my friends. It is up to
> them to keep the program secure.
> Given none of us are spies, I don't think physical security will be
> compromised.
Will you change the algorithm from time to time? Or does it not bother
you that a single compromise of a single use of your algorithm
compromises every single person who ever uses your algorithm? What if
one person using your algorithm accidentally encrypts nearly the same
data twice with the same key? Won't analyzing the resulting differences
in the ciphertext expose a lot about the structure of your algorithm? If
you are relying on the structure staying secret, you have to make sure
nobody ever uses your algorithm improperly even once -- ever. Otherwise
the whole system is compromised fatally.
DS
------------------------------
From: [EMAIL PROTECTED]
Subject: I need to crack a key
Date: Sun, 03 Dec 2000 00:59:10 GMT
Hi there,
Hope you can help:
I packed away som important stuff in a PGP-disk file (using Network
Associates PGP disk 6.0.2i).
Then I threw away my passphrase. Brilliant, I know.
So: Now I need help to hammer on my key (which in this case, luckily,
is tugged away inside the encrypted file) until at some future time, it
opens...
The passphrase is rather short, so I reckon it will probably not take a
brute force password cracker long to hammer all theoretical
combinations away..
To the point: Can anyone point me in the direction of a gui based brute
force cracker that will help me crack open my pgp-disk data?
Thanx!
Dryson
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: "Michael" <[EMAIL PROTECTED]>
Subject: Re: Newbie
Date: Sun, 03 Dec 2000 01:13:41 GMT
I will only change the program when I make improvements. At this point,
since I am learning the most, it will change often. Not for security
reasons, but for revisions reasons.
In your worst case scenario, someone has to be there waiting to take
advantage of it.
I don't think that is reality (in this real world scenario.)
I do understand what you are saying.
At this point, I am sending CLEAR text. What degree of cryptanalysis will
it take to compromise these messages?
Michael
"David Schwartz" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
>
> Michael wrote:
>
> > I will give the program that uses the algorithm to my friends. It is up
to
> > them to keep the program secure.
> > Given none of us are spies, I don't think physical security will be
> > compromised.
>
> Will you change the algorithm from time to time? Or does it not bother
> you that a single compromise of a single use of your algorithm
> compromises every single person who ever uses your algorithm? What if
> one person using your algorithm accidentally encrypts nearly the same
> data twice with the same key? Won't analyzing the resulting differences
> in the ciphertext expose a lot about the structure of your algorithm? If
> you are relying on the structure staying secret, you have to make sure
> nobody ever uses your algorithm improperly even once -- ever. Otherwise
> the whole system is compromised fatally.
>
> DS
>
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: Newbie
Date: Sun, 03 Dec 2000 01:16:43 GMT
In article <IrgW5.84992$[EMAIL PROTECTED]>,
"Michael" <[EMAIL PROTECTED]> wrote:
> Where do they post the algorithm for DES and RSA?
RSA was formally documented in a paper written quite a while ago. I
think the title was "A method of digital signatures" or something like
that. If you go to www.counterpane.com/labs.html you should be able to
look up the paper (Authors are R. Rivest, A. Shamir and L. Adleman).
DES was designed by IBM in the 70's and is well documented in Bruce
Schneier's Applied Crypto as well as quite a few websites.
DES is not particularly "good" to look at from a beginners point of
view, but structurally the cipher is rather simple.
>
> (you have peeked my interest in this area)
I would then strongly recommend you buy some books in the area first.
Instead of posting source code and "asking for analysis". Long time
readers of this group will know that I started just like you did, but I
learnt the most by trying to figure out for myself why things are not
good. I am not the best cryptographer but I have a better intuition
for "good designs" then I did a year ago. Often if you read the
cryptanalysis papers you can figure out how the attack works and if it
is applicable to new designs.
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: File Deleter/Nuker ?
Date: Sun, 03 Dec 2000 01:18:03 GMT
In article <UyfW5.84978$[EMAIL PROTECTED]>,
"Michael" <[EMAIL PROTECTED]> wrote:
> A company in Clearwater Florida claims they can recover data on a
hard drive
> that has been written over FOUR times. I called bullshit when my
friend
> signed up for the class. When my friend came back from the class I
gave him
> a disk that was ACCIDENTALLY overwritten by a friend of mine (once)
and he
> didn't recover ANYTHING.
Well diskettes are a bit different. Mis aligned drives may not
overwrite data completely. However, hard disks are always aligned with
a very little margin of error.
Recovering data from a disk that has been overwritten ONCE is very
unlikely.
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: I need to crack a key
Date: Sun, 03 Dec 2000 01:22:32 GMT
In article <90c5ss$24c$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> Hi there,
>
> Hope you can help:
>
> I packed away som important stuff in a PGP-disk file (using Network
> Associates PGP disk 6.0.2i).
>
> Then I threw away my passphrase. Brilliant, I know.
>
> So: Now I need help to hammer on my key (which in this case, luckily,
> is tugged away inside the encrypted file) until at some future time,
it
> opens...
>
> The passphrase is rather short, so I reckon it will probably not take
a
> brute force password cracker long to hammer all theoretical
> combinations away..
>
> To the point: Can anyone point me in the direction of a gui based
brute
> force cracker that will help me crack open my pgp-disk data?
>
> Thanx!
Sure ya. Well how long is your password? Given special constraints on
the choice of characters you used will determine if a special purpose
program may be better suited.
For example:
Only lower case chars:
1. Length of 7 chars, # of keys = 8,031,810,176 (2^33)
2. Length of 14 chars, # of keys = 64,509,974,703,297,150,976 (2^65)
Lower+Upper
1. Length of 7 chars, # of keys = 1,028,071,702,528 (2^40)
2. Length of 14 chars, # of keys = 1,056,931,425,538,820,521,590,784
(2^80)
If your password is say only lower case, and is under 10 chars you
could find it in under a day on a 500mhz athlon. Otherwise....
hahahahaha!
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: "Michael" <[EMAIL PROTECTED]>
Subject: Which Method
Date: Sun, 03 Dec 2000 01:31:48 GMT
I have a piece of hardware (with software inside.)
It has an option to save with a password.
When you go to work with the software inside, it gives you back the file
(and I must assume the password) THEN is asks you for the password (which
only 1 in 1000 people even use.) If you give it an incorrect password it
tells you so and doesn't show you what it retrieved. If you give it the
correct password your data instantly pops up on the screen.
So, I have the ability to save and retrieve over and over again with
different passwords to get examples of encrypted files. I also can control
the majority of the file going in (and then of course coming back out.) So
I can keep the file extremely short leaving more password and less file.
What method works best against this type of 'mined' data?
There is not money to be gained in figuring this out. But as far a passing
a cryptanalysis mile marker, I would be thrilled.
Thanks,
Michael
------------------------------
From: "Scott Fluhrer" <[EMAIL PROTECTED]>
Subject: Re: Newbie
Date: Sat, 2 Dec 2000 17:29:01 -0800
Michael <[EMAIL PROTECTED]> wrote in message
news:IrgW5.84992$[EMAIL PROTECTED]...
> Where do they post the algorithm for DES and RSA?
Well, for DES, a quick Web search pulled up:
http://raphael.math.uic.edu/~jeremy/crypt/des.html
which has a description of DES that doesn't look too bad (look under "How to
Implement the Data Encryption Standard").
And, for RSA, I can describe it quickly:
- At key generation time, you pick:
p, q -- two distinct primes
d, e -- two integers such that d*e = 1 mod lcm(p-1,q-1)
- The public key (the key that you can give to all and sundry) is the pair
(p*q, e)
- The private key (the key that you must keep for your self) is the pair
(p*q, d)
- To encrypt the message P (or to verify a signature), anyone who has the
public key can compute:
C = P**e mod p*q
- To decrpyt the message C (or to generate a signature), you (the one with
the secret key) can compute:
P = C**d mod p*q
Notes:
- If you are weak on number theory, this won't make much sense. Go study it
before trying to understand RSA (or any other public key cryptosystem, for
that matter).
- There are various considerations you need to make when you pick p, q, d,
e -- just any old set may not be secure. For example, p and q must be
chosen such that factoring p*q is infeasible.
--
poncho
------------------------------
From: Jeffrey Williams <[EMAIL PROTECTED]>
Subject: Re: JOB: Software Engineer : Security - Ohio
Date: Sat, 02 Dec 2000 19:38:07 -0600
Trevor,
you're probably correct, and if she was being obnoxious (say, posting lots of jobs
every day), I'd agree with your request.
This is the first such notice I've seen from Ms Kay. On the whole, there seem to be
no more than one such notice in toto on this NG each month. Far less of a
distraction than the porno or getrichquick spam that we see. It really doesn't
appear to be a problem.
And I can understand Ms Kay's perspective. She's looking for someone with fairly
unusual skills/knowledge/training/interests. Posting to a general jobs NG would
undoubtedly net her a lot of pointless responses. Posting here makes sense from her
perspective. And, as noted, she doesn't seem to be obnoxious about it. Actually, I
don't think I would have noticed her posting but for the subsequent postings it
generated.
Seems to me that we've better things to do than complain about some very infrequent
postings.
FWIW
Jeff
"Trevor L. Jackson, III" wrote:
> Mike Rosing wrote:
>
> > "Trevor L. Jackson, III" wrote:
> > >
> > > Plea to readers: Please call the toll-free number below and inform Ms. Kay
> > > that her post in sci.crypt is offensively off topic.
> >
> > Why? If you're not looking for work, ignore it. If you are looking, it's
> > mighty nice to see!
>
> Because such traffic belongs in the jobs ngs. I fail to see that it has anything
> to do with the purpose of this forum.
------------------------------
** 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
******************************
