Cryptography-Digest Digest #846, Volume #10 Wed, 5 Jan 00 21:13:01 EST
Contents:
Re: How about this for a "randomly" generated bitstream? (wtshaw)
Re: Change of number bases (wtshaw)
Re: Identifier anonymization (Paul Rubin)
Re: Cryptography in Tom Clancy (Shawn Willden)
Re: simple block ciphers (David A Molnar)
Re: meet-in-the-middle attack for triple DES (David Hopwood)
Re: Square root attacks against DSA? (David Hopwood)
Miller Rabin alg--which is the right one? ("Miryadi")
Re: RSA encrypt (Frank the root)
Re: Questions about message digest functions (Tim Tyler)
Re: Unsafe Advice in Cryptonomicon (Andrew Woodward)
Please Comment: Modified Enigma ([EMAIL PROTECTED])
Re: Please Comment: Modified Enigma (Paul Rubin)
Re: is signing a signature with RSA risky? (Tim Tyler)
Re: Square root attacks against DSA? (DJohn37050)
Re: RSA encrypt (DJohn37050)
Re: stupid question (Albert Yang)
Re: Thawte or Verisign SSL Certificate? (Albert Yang)
Re: Blowfish Question (Albert Yang)
Re: Please Comment: Modified Enigma (Albert Yang)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: How about this for a "randomly" generated bitstream?
Date: Wed, 05 Jan 2000 16:58:51 -0600
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (John McDonald, Jr.)
wrote:
> On Wed, 5 Jan 2000 03:52:54 GMT, Tim Tyler <[EMAIL PROTECTED]> wrote:
>
> >Nigel Fitchard <[EMAIL PROTECTED]> wrote:
> >
> >: I would like to get hold of a truly random bitstream - about 2^24 bits long
> >: should be plenty. Does anyone know if such a thing exists for download ?
> >
> >No such thing is known to exist anywhere on the planet.
> While not "truly" random, wouldn't the following be random
> enough?
>
> I puport that you take a record player and a record. Play the record
> and record the music digitally into your computer (via audio input,
> not microphone). Use the recorded .wav as your bitstream. (Record at
> the highest possible bitrate to ensure the quality of your recording.)
>
...
>
> Does anyone have thoughts on this? Problems with implementation?
Music has regularites that can be tracked, locked into to increase
predictability. You woud hav better luck listening to wind rattles, or
rain fall hitting something. Traffic noises tend to be variable. Just
plain static is good.
--
Considering that the best guess is that Jesus was born in 4 BC,
for the purists, fate worshipers, and absolute prognosticators,
you all missed your boat fome time ago, as hype mongers rejoice.
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: Change of number bases
Date: Wed, 05 Jan 2000 16:51:13 -0600
In article <[EMAIL PROTECTED]>, Mok-Kong Shen
<[EMAIL PROTECTED]> wrote:
> James Muir wrote:
> >
> > Interesting idea but utilimately the cipher blocks will be represented
> > in binary. Have you considered this?
Cipher blocks need not be in binary at all. If you mean that a computer
might handle them that way, it really does not matter how they are stored
but how they are used.
>
> In fact, in my humble opinion probably the most useful case of
> applying this scheme is to start with a bit sequence (initial base
> power of 2) and end with a bit sequence (final base power of 2).
> The intermediate bases serve simply to effect the transformation.
> The indisputable position of binary systems in contemporary
> computing leaves little room for other choices. (The characters
> one enters via keyboard are invariably turned into bytes. Thus
> one almost necessarily starts with a bit sequence.)
>
The method I use can end in the same base as it started out with in some
cases, but the results show some growth in length, not much but some.
Base Translation uses qpproximate equivalents, slop being accounted for so
that the process will handle a full range of inputs.
Naturally, intelligent selection of base relationships can minimize this
effect, but there tends to be more absolute information in results as
compared with input. Analysis will try to make advantage of the
differences, but they can be extremely marginal.
--
Considering that the best guess is that Jesus was born in 4 BC,
for the purists, fate worshipers, and absolute prognosticators,
you all missed your boat fome time ago, as hype mongers rejoice.
------------------------------
From: [EMAIL PROTECTED] (Paul Rubin)
Subject: Re: Identifier anonymization
Date: 5 Jan 2000 22:48:45 GMT
In article <[EMAIL PROTECTED]>, Al Wang <[EMAIL PROTECTED]> wrote:
>I'm looking for a process by which to take a set of 9-digit identifiers
>for a data set, and to anonymize them, so as to generate a new set of
>unique strings.
Social security numbers? Not that it matters.
>This should be deterministic, so that a given identifier will always
>be translated into the same string, but that it is not possible to
>determine the original identifier from the generated string.
>
>Is what I'm describing possible? Are there algorithms available? I'm
>quite naive in this field, but I read the FAQ, and I'm not sure i can do
>what I'm describing without either keeping the algorithm private, or
>keeping a key to the algorithm private. As I don't ever have any need
>to "decrypt" the string, I would prefer a method in which I don't need
>to secure any sort of key. The other requirement is that the generated
>string be of reasonable length (no more than twice the length of the
>identifier?).
You can't do this without a key. There are only 1 billion 9 digit
numbers. If the algorithm is public and there's no key, the attacker
can simply crunch all 1 billion of the possible numbers and store the
output in a database (a few dozen gigabytes, no big deal these days).
Then anytime he wants to uncrunch a crunched identifier, he just looks
it up in the database. The only thing you can do is make the function
very slow to execute (say, SHA-1 iterated a million times) but that's
not really a solution.
With a key, the simplest thing to do is just use a keyed, secure hash
function and keep enough bits of the hash to have acceptably low chance
of collision. E.g. if you keep 96 bits, you can encode them in 16 chars
with 6 bits/char (base-64 encoding). I don't know if that counts as
being no more than twice the length of the identifier. You could probably
make this 64 bits by trying different keys til you found one that gave
a collision free hash (as tested by hashing all 1 billion numbers and
checking for duplicates).
If you're willing to make the function invertible, then just pack the
number into a 64-bit block and encrypt with your favorite block cipher
(3DES or whatever).
Keep in mind that as long as the output is deterministic, you will be
vulnerable to codebook attacks; attackers will be able to tell if the
same identifier is used twice (e.g. in two transactions) even if the
attacker won't know the identifier, etc. Normally you want to attach
a random "salt" to each identifier before hashing it, to prevent this.
------------------------------
Date: Wed, 05 Jan 2000 16:11:34 -0700
From: Shawn Willden <[EMAIL PROTECTED]>
Subject: Re: Cryptography in Tom Clancy
John Savard wrote:
> A while back I commented on "ruthless.com" which seemed ostensibly
> opposed to cryptographic export, but which illustrated the hazards of
> key escrow.
>
> His latest novel, "Rainbow Six", has the Russians copying the STU-III:
> they used a less powerful speech compression/digitization algorithm,
> but they copied the encryption _exactly_...allowing the Americans to
> break it (they having gone on to the STU-IV).
I'm not sure which novel it was in (probably "Rainbow Six"), but there was
a section in one of Clancy's recent novels in which the NSA brute-forced a
128-bit key in a few hours. I don't mind some *minor* technical
inaccuracies, but I groaned aloud at that one.
Shawn.
------------------------------
From: David A Molnar <[EMAIL PROTECTED]>
Subject: Re: simple block ciphers
Date: 5 Jan 2000 23:07:21 GMT
Anton Stiglic <[EMAIL PROTECTED]> wrote:
> Thirdly, if in fact you realy want e to be prime, then you realy restrict
> the possible amount of e's, since you have to have gcd(e,p-1) =1
> and e is prime, e would have to be a factor of p-1. (If you know the
if a prime e is a factor of p-1, then isn't gcd(e, p-1) = e ?
------------------------------
Date: Wed, 05 Jan 2000 02:46:58 +0000
From: David Hopwood <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: meet-in-the-middle attack for triple DES
=====BEGIN PGP SIGNED MESSAGE=====
Bill Unruh wrote:
>
> In <84s453$ajm$[EMAIL PROTECTED]> Scott Fluhrer
> <[EMAIL PROTECTED]> writes:
> >but not totally out of the question for someone who wants to break your
> >code and has *lots* of money to spend on it. And, when the evil attacker
> >is done with your message, he can reuse the tapes to attack someone
> >else's.
>
> No he cannot since the data is specific to the message being encrypted.
Unless a chosen plaintext (or chosen ciphertext) attack is possible, or
there is a sufficiently long fixed part of messages (e.g. a header or
trailer).
- --
David Hopwood <[EMAIL PROTECTED]>
PGP public key: http://www.users.zetnet.co.uk/hopwood/public.asc
RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5 0F 69 8C D4 FA 66 15 01
"Attempts to control the use of encryption technology are wrong in principle,
unworkable in practice, and damaging to the long-term economic value of the
information networks." -- UK Labour Party pre-election policy document
=====BEGIN PGP SIGNATURE=====
Version: 2.6.3i
Charset: noconv
iQEVAwUBOHKwdTkCAxeYt5gVAQHL1Qf+PNCnR7HJOOBDb6ESGwsiwkGr8cU2AovG
DDNUq6xGPviR6P4+oDD7VsiNVEfvho2bygTuw0Kpy42MGQ2lFq3/zeu8BJNE8Mmb
QHepBp+ZvluZKEC2L3wL8nj5NXQHBjEBOQ+tXSkveQMBToOY0ADoOoTLXvJk7INY
ZcEjIJfWQ0BLbS4q69L9fmtzCacqRG2Y2F4lLV0diJe4NwMjyzr5eSyL51L9i3Sl
vONNS94pQ0xQ2XaDv4iWVRGn/nm/qI3+rsY0w8gMOSPhMmLGKsTG5Tv1y+b+bpL0
kI+BsXP3lGW9SyQZmJEYntR8mGIsFghiOwgwHb9iLdwmLnSlbKSoBw==
=hIeg
=====END PGP SIGNATURE=====
------------------------------
Date: Wed, 05 Jan 2000 06:09:35 +0000
From: David Hopwood <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: Square root attacks against DSA?
=====BEGIN PGP SIGNED MESSAGE=====
"Paulo S. L. M. Barreto" wrote:
[...]
> Suppose you setup a DSA-like signature scheme where p is reasonably large
> (1024 bits or more) but q is quite small (say, 80 bits or less). This
> unusual choice is made so that index calculus and brute force are unfeasible
> but "square root" discrete log attacks are possible (at least Pollard
> attacks, since Shanks may have too large storage requirements). Also,
> suppose all keys are short-lived and used only a few times to thwart
> birthday paradox attacks.
OK.
> The problem is that Pollard rho and lambda (as they are usually described in
> the literature) are useful to solve equation r = g^k mod q for k, but DSA
> uses r = (g^k mod p) mod q, hence the result won't in general be k but an
> unrelated quantity, seemingly useless to attack the s part of the signature.
If I understand correctly, because g has order q in Z_p*, the Pollard rho
and lambda algorithms working in Z_p* will find collisions with effort
dependent on the square root of this order, not the square root of p.
- --
David Hopwood <[EMAIL PROTECTED]>
PGP public key: http://www.users.zetnet.co.uk/hopwood/public.asc
RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5 0F 69 8C D4 FA 66 15 01
"Attempts to control the use of encryption technology are wrong in principle,
unworkable in practice, and damaging to the long-term economic value of the
information networks." -- UK Labour Party pre-election policy document
=====BEGIN PGP SIGNATURE=====
Version: 2.6.3i
Charset: noconv
iQEVAwUBOHLfxzkCAxeYt5gVAQHGewgAnlVxRcEuUsXCKyGge3otlhp7QU3VSuIs
lAbWfJ2HicxyqMg5kEps6465Wft4WJIZYlw3kk1FDKKm6QfSfk9pdDux3S1Ey0y6
L7I/LNBJ3elAeM+j0s4GZTqG7fL0OT70dkCp3kD+Ipl1D3KJmu3xlnUYRDIio6o8
QE3T+oVURYkxlanPtNdk3gSZciN0/zOOt+MawB5SruazJ7WXSkmfiEeltkN4Vbil
NEwTGxeBRvvQcjzpNrzvefkNpIBDCBZyN94s+xYenyWlDDW15OqNTQIvYkygpYqs
a1pH2SthubhlLviNQg4nrzU0/0kuClPpJHjNGN7af2OnwGMldh5ZcQ==
=r5JE
=====END PGP SIGNATURE=====
------------------------------
From: "Miryadi" <[EMAIL PROTECTED]>
Subject: Miller Rabin alg--which is the right one?
Date: Wed, 5 Jan 2000 22:22:09 +0700
Hello, all
Cormen's "Introduction To Algorithm" page 843 mention that:
for any odd integer n>2 and positif integer s, the probability that
Miller_Rabin (n,s) error is at most 2^-s, but
Menezes' "Handbook of Cryptography" page 140 mention that:
for any composite integer n, the probability that Miller_Rabin(n,t)
declares n to be prime is less than (1/4)^t.
Which is the right one?
Best Regards
-- Yadi --
------------------------------
From: Frank the root <[EMAIL PROTECTED]>
Subject: Re: RSA encrypt
Date: Thu, 06 Jan 2000 00:12:44 GMT
Paul Schlyter wrote:
> One practical problem: how would you store the full M^d ? If we assume
> M and d are both 512 bits (a minimum requrement -- 512-bit RSA can today
> be cracked with some effort), then M^d would be approx 512*(2^512) = 6.8E+156
> bits large. If you want to use M and d wihich each are 1024 bits, then
> the full M^d would be approx 1024*(2^1024) = 1.8E+311 bits large.
>
> The entire universe contains about 1E+80 atoms. Thus, you'd need to
> store 1E+77 (512-bit case) or 1E+231 (1024-bit case) in EACH ATOM OF
> THE ENTIRE UNIVERSE to have space enough to store M^d.
Hum... I'm a bit new to cryptography but I would like to know how RSA can encrypt
and decrypt a message ( in equations: c = m^e mod n and m = c^e mod n ) if there
is not enough atoms in the universe to complete the operation c^d?? It might
sound you like stupid question to you but it would fill my curiosity a lot, tank
you.
.
Frank
--
Ceux qui r�vent le jour, savent des choses qu'ignorent ceux qui
r�vent la nuit.
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Questions about message digest functions
Reply-To: [EMAIL PROTECTED]
Date: Thu, 6 Jan 2000 00:10:28 GMT
lordcow77 <[EMAIL PROTECTED]> wrote:
: Are you utterly unable to comprehend this simple and widely accepted
: concept that a hash should approximate a pseudo-random function?
I don't care *how* "simple" and "widely accepted" it is - it's dead wrong.
For /many/ applications hashes should make finding two messages which hash
to the same value as difficult as possible. Alternatively (and perhaps
more commonly) they should make finding a second message with the same
hash as a given message as difficult as possible.
A hash that has the distribution of an unbiased "pseudo random function"
demonstrably fails to get anywhere near the optimum collision resistance.
Consequently it fails to offer the property demanded by a good hash - that
of making finding multiple messages with the same hash as hard as
possible. Most obviously, it fails against a brute force search through
the space of possible messages for a matching hash.
For example, when the hash size is equal to the message size, use of a
hash that simulates a PRF will introduce totally unnecessary hash
collisions. Generally speaking - for most applications of a hash - this
is not good.
If collision resistance is why you are using a hash, you should ideally
avoid those that simulate pseudo random functions - *especially* if you
can't afford to use a large hash, and the information you are hashing is
not gigantic compared to the size of the hash.
[snip more references]
: You might also want to consult Knuth's TAOCP where he discusses
: noncryptographic hashing.
My comments apply equally to non-cryptographic hashing. If avoiding
hash collisions is important, a PRF is likely to be the wrong model for
the ideal that a hash function should approach.
My argument is /very/ simple. I have seen no coherent criticism of it.
If nobody can distill the wisdom of the literature references given into
some sort of reason why my argument is wrong - and in fact collision
resistance in the hash should be sacrificed for some currently-unspecified
higher goal - I will not be impressed.
If you have a large hash, failure to deviate from the distribution given
by a PRF in the correct manner as the messages become small will not be
terribly important.
However, if the hash size is small - as it will sometimes be practially
constrained to be - a PRF is simply completely the wrong model for an
ideal hash, if you care at all about avoiding hash collisions.
--
__________
|im |yler The Mandala Centre http://www.mandala.co.uk/ [EMAIL PROTECTED]
Enough research will tend to support your theory.
------------------------------
From: [EMAIL PROTECTED] (Andrew Woodward)
Subject: Re: Unsafe Advice in Cryptonomicon
Date: 06 Jan 2000 00:46:40 GMT
John Savard
wrote:
>Well, I finally finished the book.
That really was a great book, I spent most of my vacation reading it.
>
>At one point, the hero manages to avoid the villains reading what his
>computer is doing by not using the display on his laptop computer.
>
>However, although the display is the _easiest_ target, given a
>competent adversary, the actual computations the computer is
>performing, signals to and from the keyboard, signals to and from the
>hard drive, and so on, are also targets, and thus, TEMPEST-type
>precautions deal with *all* RF emissions from a computing device.
>
One problem with the VE phreak is that although ir can pick up the radio
emmisions from the computer itcan not always tell what type of data they
represent. The reason that the display is so easy to detect is because of the
noticable pauses in emmisions during horizontal and other rastorings. However,
no such pause or other distinguishing charecteristics should be present in the
morse code output. Certainly there would be a timing pattern but this could be
hidden by generating many different types of enternal morse code perhaps
reading false information. Another posibility would be too load a large
program while simultaniously outputting the morse code. It may create enough
disturbance to hide the morse output.
Andrew
Student
Baltimore MD
------------------------------
From: [EMAIL PROTECTED]
Subject: Please Comment: Modified Enigma
Date: Thu, 06 Jan 2000 00:54:17 GMT
Hello,
I wonder if someone can comment on the strength of the following simple
cipher: Extend the enigma algorithm by variable rotor permutations. Each
rotor permutation would be part of the key.
A simple physical implementation (assuming you are a spy in a hostile
land who must not import any suspicious electronic or mechanical
devices) would be a circle of paper for each rotor.
The idea is to remember the key, travel to the hostile land and then buy
pencil, paper and other simple mechanical engineering stuff (how do you
translate 'Zirkel' ? :-) ) to construct the encryption 'machine'.
What do you think about the cryptographic strength of this algorithm ?
(3 or 4 rotors, assuming an indicator system)
Do you know of other 'homemade' non-electronic crypto which is strong in
today's terms ?
(except one-time pads)
Thanks for your comments
Frank
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (Paul Rubin)
Subject: Re: Please Comment: Modified Enigma
Date: 6 Jan 2000 01:12:42 GMT
In article <850p3j$qe4$[EMAIL PROTECTED]>, <[EMAIL PROTECTED]> wrote:
>Hello,
>I wonder if someone can comment on the strength of the following simple
>cipher: Extend the enigma algorithm by variable rotor permutations. Each
>rotor permutation would be part of the key.
>
>A simple physical implementation (assuming you are a spy in a hostile
>land who must not import any suspicious electronic or mechanical
>devices) would be a circle of paper for each rotor.
>
>The idea is to remember the key, travel to the hostile land and then buy
>pencil, paper and other simple mechanical engineering stuff (how do you
>translate 'Zirkel' ? :-) ) to construct the encryption 'machine'.
>
>What do you think about the cryptographic strength of this algorithm ?
>(3 or 4 rotors, assuming an indicator system)
>
>Do you know of other 'homemade' non-electronic crypto which is strong
>in today's terms ? (except one-time pads)
>
>Thanks for your comments
The strength of this scheme isn't really relevant. Enigma was
designed to be implemented by an electromechanical machine, by
soldiers in the field with things on their mind. You'd go crazy
trying to operate it with pieces of paper under those conditions.
If you want a pencil and paper cipher, Enigma is a pretty bad starting
point. You could pretty easily do RC4 with pencil and paper (divide
the paper into little squares) or you could check out the Solitaire
cipher at www.counterpane.com which is done with a deck of cards.
This is a perennial topic here on sci.crypt and it's fun, but really,
electronic devices like pocket organizers (e.g. Palm Pilot) aren't
very suspicious by today's standards. And it's pretty easy to
implement good cryptography on them, even without "programming" tools.
For example it would be pretty simple to implement RC4 or Skipjack
using an organizer's built-in spreadsheet.
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: is signing a signature with RSA risky?
Reply-To: [EMAIL PROTECTED]
Date: Thu, 6 Jan 2000 00:35:51 GMT
Pascal Scheffers <[EMAIL PROTECTED]> wrote:
: With RSA, there is the risk that if you encrypt before signing the
: other can fake a message. This is described on p473 of Applied
: Cryptography 2nd.Ed.
BS says there that: "It makes sense to sign a message before encrypting
it".
Any users who follow this advice should be aware that if the signature may
be publicly validated, this can provide a concrete halting criterion -
which allows keys to be automatically rejected on every signed message
sent.
I believe you should normally sign outside at least one layer of strong
encryption, because of this (with different key bits being used on "either
side" of the signature).
This way, if an attack using the signature succeeds, at least the
message itself is not automatically compromised.
If you don't do this you should be aware there may be a security price
to authenticating your message.
I don't mean to advocate falling into the path of the RSA
encrypt-before-signing attack, of course.
--
__________
|im |yler The Mandala Centre http://www.mandala.co.uk/ [EMAIL PROTECTED]
How did a fool and his money get together in the first place?
------------------------------
From: [EMAIL PROTECTED] (DJohn37050)
Subject: Re: Square root attacks against DSA?
Date: 06 Jan 2000 01:27:16 GMT
Pollard rho works in ANY group, in particular the subgroup of order q.
Don Johnson
------------------------------
From: [EMAIL PROTECTED] (DJohn37050)
Subject: Re: RSA encrypt
Date: 06 Jan 2000 01:28:29 GMT
The way it is done is to always use modular reduction on the intermediate
results of the exponentiation calculation.
Don Johnson
------------------------------
From: Albert Yang <[EMAIL PROTECTED]>
Subject: Re: stupid question
Date: Thu, 06 Jan 2000 01:38:41 GMT
I think there are several other problems as well. First, I wrote a
little bigram program before. So I would probably run a bigram program
against Shakespeare's works, and calculate a commonality of letter
pairs. For example, if you are basing your keys off of "Jack and Jill"
JA and JI are fairly common pairs as is LL and CK. So it's easy to
guess. Things like "JZ" which don't exist in the common english are a
bit harder.
Also, rapid seed expansion does not make it any more secure. Let me
give you an example. Let's say I have a hash or PRNG program, that
takes 16bits and converts it to 168 bits. So what? If I know this,
then I won't be trying to crack 168bit key, I will be trying to crack a
16 bit key, which can be easily bruteforced.
Albert
------------------------------
From: Albert Yang <[EMAIL PROTECTED]>
Subject: Re: Thawte or Verisign SSL Certificate?
Date: Thu, 06 Jan 2000 01:43:38 GMT
<snip>
I hate to sound like a jerk, but this is what gets the industry and
crypto in general into trouble. You have no idea, but you'll buy a
certificate, put on a "eTrust" symbol, and open for business. There is
NO security in that, because the biggest threat to security isn't
hackers, or crackers, it's ignorance.
So you have SSL, and then you email yourself the info in plaintext,
where's the security in that? The sad part is I know a lot of
companies, (including my old one) that did that. That's not security,
that's a false sense of security, which is worse.
I highly suggest that you learn about security before an attempt to
implement it, I commend you for your efforts of asking first, I wish
more did.
Albert
------------------------------
From: Albert Yang <[EMAIL PROTECTED]>
Subject: Re: Blowfish Question
Date: Thu, 06 Jan 2000 01:47:07 GMT
I think the easiest method to doing this is finding out the key
schedule. Someone (I'm sure) will correct me if I'm wrong, but I think
Blowfish is a Feistal Round, so R-1=L and visa versa is the structure of
the rounds. So if you can guess the intermediate key values as they go
into the round, you've got it made. Then again, you would have cracked
blowfish as well.
In case you do crack blowfish, email Bruce and ask him for $10K. I'm
serious, I think he's more than willing to cough that up if you break
it.
Happy cracking.
Albert
------------------------------
From: Albert Yang <[EMAIL PROTECTED]>
Subject: Re: Please Comment: Modified Enigma
Date: Thu, 06 Jan 2000 01:53:11 GMT
[EMAIL PROTECTED] wrote:
>
> Hello,
> I wonder if someone can comment on the strength of the following simple
> cipher: Extend the enigma algorithm by variable rotor permutations. Each
> rotor permutation would be part of the key.
>
<snip>
The thing you have to remember though is, things are different. If you
are out in the field and don't have a computer, that doesn't mean
whoever intercepts your message doesn't have a computer either!!! So
such things are very weak. Enigma is a joke to crack for my desktop.
so if you want to go with pen+paper, I highly suggest something like
Solitaire, or RC4. A stream cipher as simple as RC4 would do really
well in the field.
Albert
------------------------------
** 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
******************************
