Cryptography-Digest Digest #993
Cryptography-Digest Digest #993, Volume #10 Fri, 28 Jan 00 08:13:01 EST
Contents:
Re: RSA BSAFE Crypto-J Question (Paul Rubin)
Re: Best Encryption Software? (Johnny Bravo)
Re: Strong stream ciphers besides RC4? (Stefan Lucks)
Question : About mailing list ("±è½Â¼ö")
Re: NEC claims New Strongest Crypto Algor (John Savard)
Re: Pencil paper cipher question (Salvatore Sanfilippo)
Re: Best Encryption Software? (Bob Deblier)
Re: How much does it cost to share knowledge? ("Lassi Hippeläinen")
Shamir Secret Sharing ([EMAIL PROTECTED])
Re: Shamir Secret Sharing (Paul Rubin)
Re: How much does it cost to share knowledge? ("ink")
Re: Attack on elliptic curves over GF(2^m), m composite (Robert Harley)
Re: Attack on elliptic curves over GF(2^m), m composite (Robert Harley)
Re: Intel 810 chipset Random Number Generator (Guy Macon)
Re: Intel 810 chipset Random Number Generator (Guy Macon)
Re: Intel 810 chipset Random Number Generator (Guy Macon)
Re: Court cases on DVD hacking is a problem for all of us (Terje Elde)
Re: DVD: CSS comments?? (Terje Elde)
Re: Intel 810 chipset Random Number Generator (Guy Macon)
Re: DVD: CSS comments?? (Sandy Harris)
From: [EMAIL PROTECTED] (Paul Rubin)
Subject: Re: RSA BSAFE Crypto-J Question
Date: 28 Jan 2000 07:11:07 GMT
In article 86peh8$4v0$[EMAIL PROTECTED], [EMAIL PROTECTED] wrote:
We are currently using RSA BSAFE Crypto-J for
Java encryption, but we did not evaluate many
products before we purchased Crypto-J. Now that
our license is up, we are considering changing
products. Can anyone recommend a different
solution?
It depends entirely on what you're trying to do. I'm using C
implementations from www.openssl.org wrapped in a home-cooked JNI
layer. From a performance point of view this is probably the best
approach, but it's not pure Java and takes a bit more attention.
It could be that there's enough stuff in the Java 1.2 JCA/JCE to
do what you need.
You have to say more about your application to get a useful answer.
--
From: Johnny Bravo [EMAIL PROTECTED]
Subject: Re: Best Encryption Software?
Date: Fri, 28 Jan 2000 02:19:34 +
On Fri, 28 Jan 2000 01:07:05 -0500, "Trevor Jackson, III"
[EMAIL PROTECTED] wrote:
The copies of PGP can be supplied to the end users by the same mechanism their
use to receive the database. The original poster mentioned FTP, so that should
suffice for distribution. _Whatever_ encryption mechanism he uses, he'll need
to distribute the decryption mechanism in order for users to get at the
contents.
If RC4 would be sufficient to his needs, it would be trivial to write an
implementation that attaches to the front of a zip file and extracts it
when executed. I know it's trivial because I can do it. grin A benefit
is that it would be very easy to set the entire thing up with batch files
and run via command line, even to the point of assigning different
passwords and/or files to different users.
My version written with DJGPP there is roughly 33k of overhead per file
sent, while the program to encrypt the file and attach the header is only
60k. Someone willing to do the same job in assembler could probably fit
the header in 500 bytes or less and the encryption program in 1k.
Best Wishes,
Johnny Bravo
--
From: Stefan Lucks [EMAIL PROTECTED]
Subject: Re: Strong stream ciphers besides RC4?
Date: Fri, 28 Jan 2000 08:40:00 +0100
On Thu, 27 Jan 2000, Uri Blumenthal wrote:
Oh, Greg Rose designed a very cute stream cipher "SOBER".
It seems to be secure, and it's fast. Presented on 3rd
AustralAsian Crypto in 1998.
Daniel Bleichenbacher and Savar Patel have broken SOBER, see
Daniel Bleichenbacher and Savar Patel: "SOBER Cryptanalysis",
Fast Software Encryption ´99, Springer LNCS 1636.
--
Stefan Lucks Th. Informatik, Univ. Mannheim, 68131 Mannheim, Germany
e-mail: [EMAIL PROTECTED]
home: http://th.informatik.uni-mannheim.de/people/lucks/
= Wer einem Computer Unsinn erzaehlt, muss immer damit rechnen. =
--
From: "±è½Â¼ö" [EMAIL PROTECTED]
Subject: Question : About mailing list
Date: Fri, 28 Jan 2000 17:23:48 +0900
Hi! I am a student who have interested in cryptography.
I have one question about mailing list.
Is there anyone who knows address of some mailing list about cryptography?
(especially cryptanalysis...)
If you know that, please let me know that.
Thanks a lot.
--
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: NEC claims New Strongest Crypto Algor
Date: Fri, 28 Jan 2000 08:34:06 GMT
On Fri, 28 Jan 2000 05:44:32 GMT, "Douglas A. Gwyn" [EMAIL PROTECTED]
wrote, in part:
That's around 2^129.5 which maybe is supposed to be 2^128.
So the old cipher had a 128 bit key, and the new one can have a 256
bit key like the AES. It will be interesting
Cryptography-Digest Digest #994
Cryptography-Digest Digest #994, Volume #10 Fri, 28 Jan 00 13:13:01 EST
Contents:
Re: Court cases on DVD hacking is a problem for all of us (Troed)
Re: Shamir Secret Sharing ("Scott Fluhrer")
Re: Mac encryption algorithm? (Paul Schlyter)
Re: NEC claims New Strongest Crypto Algor (Volker Hetzer)
Re: NEC claims New Strongest Crypto Algor ([EMAIL PROTECTED])
Re: Why did SkipJack fail? (Greg)
Re: Strong stream ciphers besides RC4? (Uri Blumenthal)
Re: NEC claims New Strongest Crypto Algor (Greg)
Re: How much does it cost to share knowledge? (Paul Schlyter)
Re: WW2 Cypher Yet Unbroken ... (Tim Tyler)
Re: "Trusted" CA - Oxymoron? (Anne Lynn Wheeler)
Re: *** ECC Strong and Weak combined (Mike Rosing)
Re: Strong stream ciphers besides RC4? (Stefan Lucks)
From: [EMAIL PROTECTED] (Troed)
Subject: Re: Court cases on DVD hacking is a problem for all of us
Reply-To: [EMAIL PROTECTED]
Date: Fri, 28 Jan 2000 13:22:59 GMT
[EMAIL PROTECTED] (Terje Elde) wrote:
Please keep in mind they I might be wrong, as I'm working with second hand
info here.
Yes, and your info is wrong.
Not going into actual details, the CSS algorithm was reverse
engineered and re-implemented. Not necessarily from Xing's player, not
necessarily by Jon (actually, he did not do it).
Extracting a player key was done from Xing, and the subsequent finding
of flaws in the algorithm itself made it possible to in very short
time find all other DVD keys (there is a limited number of them).
There was really no need to get a key from Xing's player - just
brute-forcing it would have sufficed and would only had taken a few
hours.
Reverse engineering the CSS algorithm (both authentication and
decrypting the data) and then exploiting the flaws in them (they're
nowhere near reaching the 40 bit strength they _could_ have had)
involves more than just creating a GUI for things gotten from Xing ;)
It's a lot like black box reverse engineering, with some "white box"
help. (I would assume this is a lot like the finding of the GSM
comp128 algorithm ... a rumoured full card-readout helped there?)
Fact is, what MoRE did a lot of people posting here regulary do. The
difference is that exploits found this way, even when assembled into
ready-for-use programs, have never gotten so much attention before. My
guess is that DVD-CCA claimed that their algorithm prevented _copying_
(something it's never been able to do) and that they now have to face
serious accusations from their licensees and the members of the MPAA.
Don't let them take this out on a 16 year old Norwegian who's just
been doing what computer enthusiasts have been doing since the days of
the Altaire. Raise your voice, now.
___/
_/
--
From: "Scott Fluhrer" [EMAIL PROTECTED]
Subject: Re: Shamir Secret Sharing
Date: Fri, 28 Jan 2000 06:00:44 -0800
[EMAIL PROTECTED] wrote in message
news:86roiu$rag$[EMAIL PROTECTED]...
Hi all,
I have a question about Shamir Secret Sharing.
In this scheme, we produce a random prime number P S where S is the
secret key.
My question is what is the method to produce P, I talk in terme of
size, not in the method to find a random prime number.
You need P to be larger than the largest valid S. So, if S is a 56 bit DES
key,
then P needs to be a prime greater than 2**56.
Note that this is selecting P based on possible values of S, not the actual
value. Selecting P based on the actual S value is silly, because the
attacker will presumbly known your selection criteria for P, and so if P
depends on S, he will gain some knowledge of S, even if he doesn't have
enough shares. Selecting P based on potential values of S gives the
attacker no additional information, because we assume he knows the
potential values of S already.
The problem is that P is a public data in this scheme.
I explain, if we search the first next prime number after S, it's not
good for example, beacuse to get S, you test P, P-1, P-2, ... and
rapidly you get S.
Actually, with secret sharing, it's not possible to test P, P-1, P-2 in
any meaningful way. If you have enough shares,there's no reason.
If you don't have enough shares, then all potential S's are equally
possible with the information you have.
--
poncho
.
--
From: [EMAIL PROTECTED] (Paul Schlyter)
Subject: Re: Mac encryption algorithm?
Date: 28 Jan 2000 08:28:05 +0100
In article [EMAIL PROTECTED],
Paul Koning [EMAIL PROTECTED] wrote:
About the only hassle you may run into is that some want to do
arithmetic on multi-byte values in the wrong (Intel style) byte
order.
And why is this byte order "wrong" ? Little Endian and Big
Endian are merely two different byte orders, both of which have
their advantages and disadvantages.
Ever read Gulliver's travels? There Gulliver meets a people of
dwarves, who had a war with a neighbour dwarf people. What
Cryptography-Digest Digest #995
Cryptography-Digest Digest #995, Volume #10 Fri, 28 Jan 00 16:13:01 EST
Contents:
Re: designing secure backdoors into the system (Mike Rosing)
Re: "Trusted" CA - Oxymoron? (Anne Lynn Wheeler)
Re: Classical Crypto Books ("Melinda Harris")
CRYPTO-ECCENTRIC ("Melinda Harris")
Re: WW2 Cypher Yet Unbroken ... (Jim)
Re: Mac encryption algorithm? (wtshaw)
Re: NIST, AES at RSA conference ([EMAIL PROTECTED])
Re: CRYPTO-ECCENTRIC ("Trevor Jackson, III")
Re: Intel 810 chipset Random Number Generator (Scott Nelson)
Re: NIST, AES at RSA conference (CLSV)
Re: NEC claims New Strongest Crypto Algor (John Savard)
Re: CRYPTO-ECCENTRIC (John Savard)
Re: CRYPTO-ECCENTRIC (John Savard)
From: Mike Rosing [EMAIL PROTECTED]
Subject: Re: designing secure backdoors into the system
Date: Fri, 28 Jan 2000 12:28:17 -0600
Yusuf Motiwala wrote:
Infact, if any other front door solution exists for such problems, I would be
happy
to think in that direction. Any inputs?
When the sysadmin signs on, have the password (in encrypted form of
course!)
be sent to the manufacturer and stored in their database for that
customer.
If the customer needs to get the password, go thru some trusted
mechanism
to give them the password from the manufacturer's stored data. With a
new
sysadmin, just toss the old one out and nobody has to know what it was.
You're just moving the level of trust away from the user up the chain
tho,
what happens when the admin of the manufacturer gets run over by a
truck?
You may want to use a (k,n) scheme on the manufacturer's end, so that 5
people have to unlock the database for any customer, and up to 10 people
might have the ability to do so.
You might also build in a (k,n) scheme for the customer, so the CEO,
vice
presidents and janitor all have to know something and any 3 of them
could
regain access to the system. Then the sysadmin could create a new key
by themselves. That might be preferable to an attackable database
actually.
Patience, persistence, truth,
Dr. mike
--
Crossposted-To:
alt.privacy,alt.security.pgp,comp.security.pgp,comp.security.pgp.discuss
Subject: Re: "Trusted" CA - Oxymoron?
Reply-To: Anne Lynn Wheeler [EMAIL PROTECTED]
From: Anne Lynn Wheeler [EMAIL PROTECTED]
Date: Fri, 28 Jan 2000 18:42:10 GMT
... and an option ... the relying-party-only bank may determine that
it isn't even necessary to transmit a copy of the certificate back to
the individual. The individual goes thru the public key RA process
with their bank. The bank does the RA bit, then manufactors a
certificate by encoding the fields and signing them. The bank then
verifies the signature on the newly minted certificate, decodes it and
stores the decoded fields in the account record. If the bank decides
there is never a business scenerio requiring the individual to
transmit the relying-party-only certificate on a relying-party-only
transaction, the bank won't bother to transmit a copy of the
certificate to the individual. The bank just keeps the original on
file (in its unecoded form).
--
Anne Lynn Wheeler | [EMAIL PROTECTED], [EMAIL PROTECTED]
http://www.garlic.com/~lynn/ http://www.adcomsys.net/lynn/
--
From: "Melinda Harris" [EMAIL PROTECTED]
Subject: Re: Classical Crypto Books
Date: Fri, 28 Jan 2000 13:54:00 -0500
CryptoBook [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]...
Classical Crypto Books is pleased to announce the following recent
additions/updates to the CCB catalog.
CLASSICAL CRYPTO
THE AMERICAN BLACK CHAMBER
by Herbert O. Yardley
A BEST BUY! This high quality, hardbound reprint edition is printed on
acid
free paper and is published in a press run limited to 100 copies. For a
description, see the softbound edition listing (next). Published at
$23.95.
Amereon House, 268 pp.
HB, Nonmember $22.95, Member $20.95
THE AMERICAN BLACK CHAMBER
by Herbert O. Yardley
This thrilling and controversial 1931 bestseller exposed US cryptanalytic
methods and successes, spurring Japan and other embarrassed nations to
change
systems before WW2. Written by the colorful, talented, and broke ABC
leader
after it closed in 1929. Aegean Park Press C-52, 375 pp.
SB, Nonmember $28.80, Member $23.05
CRYPTANALYSIS OF THE SINGLE ROTOR CIPHER MACHINE
by Donald A. Dawson
This book grew out of the author's (eventually) successful attempt to
solve a
problem in the back of Solomon Kullback's Statistical Methods in
Cryptanalysis.
Includes QBasic program listings. See Cryptologia, Oct96. Aegean Park
Press
C-73, 217 pp.
SB, Nonmember $38.80, Member $31.05
ADVANCED MILITARY CRYPTOGRAPHY
by William F. Friedman
Continues Friedman's Elementary Military Cryptography, covering the same
general areas, but with more advanced subject matter. Includes sections on
repetitive and combined systems as well as cryptographs and cipher
Cryptography-Digest Digest #996
Cryptography-Digest Digest #996, Volume #10 Fri, 28 Jan 00 19:13:01 EST
Contents:
Help needed on peculiar use of cryptography (Sgwbutcher)
Read my messages in alt.politics.org.cia - you will be satisfied ! (Markku J.
Saarelainen)
Re: Mac encryption algorithm? ("Joseph Ashwood")
Re: Help needed on peculiar use of cryptography (John Savard)
Re: Help needed on peculiar use of cryptography (David A Molnar)
Re: Mac encryption algorithm? (Paul Koning)
Re: DES Hardare - chips/cores (Paul Koning)
Re: Pencil paper cipher question (r.e.s.)
Re: designing secure backdoors into the system ("Peter K. Boucher")
Re: designing secure backdoors into the system (Paul Koning)
Re: designing secure backdoors into the system (Samuel Paik)
Re: Intel 810 chipset Random Number Generator (Terry Ritter)
Crypto/Security/Cryptanalysis Papers ("Joseph Ashwood")
From: [EMAIL PROTECTED] (Sgwbutcher)
Subject: Help needed on peculiar use of cryptography
Date: 28 Jan 2000 21:27:34 GMT
Dear forum,
I am an economist and in the course of my work, I often have access to
sensitive information. For example, in a discrimination case, I may have access
to personnel records covering several years for all the employees of a company.
Because I often have to match records across different payperiods, months and
years, a unique identifier is required for each record, often the social
security number. Because of various laws and company policies about the use of
social security numbers or any other identifier, I always sign a
confidentiality agreement with regard to the disclosure of this information.
However, sometimes companies are unwilling to part with information even in the
case of confidentiality agreements.
My question is "is there a way that encryption or a specific use or kind of
encryption can be used so that, say, a social security number can be encrypted
so that the informational value of the cyphertext can be retained but the
plaintext cannot be recovered? and is the code for this method accessible as
the actual implementation may be, depending on the case, in Excel, SAS, C/C++,
Perl or Java?"
I think the most important points are (1) this is permanent encryption--is no
"legitimate" reason why the cyphertext would ever be decrypted and (2) the
domain of the plaintext is very small, 0-9 and short length cyphertext and (3)
the information value of the cyphertext should be the same as the plaintext,
that is, if plaintext A identifies a particular record over 5 years, then
cyphertext A should reference the same records and no others.
One obvious solution is to come up with a new identifier scheme, the problem is
that many IT/DP departments are unwilling to invest the effort and the
databases can be quite large and there may be multiple identifiers.
Additionally, in the case of employee numbers, a simple start at 1001 and go on
approach is how they got their employee numbers to begin with so although you
don't have necessarily the employee number you're looking for, you do have
someone's employee number. This is why I'm looking for something a little more
algorithmic.
Any possible help/suggestions you might be able to provide would be
appreciated.
Thanks,
Steve
==
==
Stephyn G. W. Butcher
Consultant in Labor Economics and Statistics
1760 Euclid St. NW Suite 306
Washington, DC 20009
(202) 745-0114 fax: (202) 745-0446
[EMAIL PROTECTED]
--
From: Markku J. Saarelainen [EMAIL PROTECTED]
Subject: Read my messages in alt.politics.org.cia - you will be satisfied !
Date: Fri, 28 Jan 2000 21:19:28 GMT
Read my messages in alt.politics.org.cia - you will be satisfied.
Sent via Deja.com http://www.deja.com/
Before you buy.
--
From: "Joseph Ashwood" [EMAIL PROTECTED]
Subject: Re: Mac encryption algorithm?
Date: Fri, 28 Jan 2000 13:35:49 -
And why is this byte order "wrong" ? Little Endian and
Big
Endian are merely two different byte orders, both of which
have
their advantages and disadvantages.
There are actually algorythms that require a specific
Endianness to be secure. I can't think of which one offhand,
but IIRC an AES candidate was one of these.
Joe
--
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Help needed on peculiar use of cryptography
Date: Fri, 28 Jan 2000 14:58:43 GMT
[EMAIL PROTECTED] (Sgwbutcher) wrote, in part:
a social security number can be encrypted
so that the informational value of the cyphertext can be retained but the
plaintext cannot be recovered?
It is not clear what this wording means. However, a one-way hash
function can allow a social security number to be encrypted so that,
althought the social security number itself cannot be recovered, its
hash is still usable as an identifier by which records can be
Cryptography-Digest Digest #997
Cryptography-Digest Digest #997, Volume #10 Fri, 28 Jan 00 22:13:01 EST
Contents:
Re: Intel 810 chipset Random Number Generator (Michael Kagalenko)
Re: Intel 810 chipset Random Number Generator (Michael Kagalenko)
Re: Intel 810 chipset Random Number Generator (Michael Kagalenko)
Re: Clock drift (was Intel 810 chipset Random Number Generator) (Michael Kagalenko)
How to password protect files on distribution CD ([EMAIL PROTECTED])
Re: Intel 810 chipset Random Number Generator (Michael Kagalenko)
Re: Clock drift (was Intel 810 chipset Random Number Generator) (Michael Kagalenko)
Re: Intel 810 chipset Random Number Generator (Michael Kagalenko)
Re: How to password protect files on distribution CD (Theo de Raadt)
Re: How much does it cost to share knowledge? (David A Molnar)
Re: How to password protect files on distribution CD (NFN NMI L.)
Re: Intel 810 chipset Random Number Generator ("james d. hunter")
Re: How to password protect files on distribution CD (GJJ)
Re: *** ECC Strong and Weak combined ("Harvey Rook")
Re: "Trusted" CA - Oxymoron? ("Brian Hetrick")
Re: Pencil paper cipher question (David Wagner)
Re: Pencil paper cipher question ("r.e.s.")
Re: designing secure backdoors into the system (Thierry Moreau)
From: [EMAIL PROTECTED] (Michael Kagalenko)
Crossposted-To: sci.physics
Subject: Re: Intel 810 chipset Random Number Generator
Date: 29 Jan 2000 00:02:29 GMT
Reply-To: [EMAIL PROTECTED]
Guy Macon ([EMAIL PROTECTED]) wrote
]In article 86qqvg$l1o$[EMAIL PROTECTED], [EMAIL PROTECTED]
](Michael Kagalenko) wrote:
]
] Again nope. This cycle-by-cycle period variation produces clock drift,
] which grows with time. Precisely how it does so can be evaluated using
] fluctuation-dissipation theorem. If I feel like it, I might even do
] the computation one day.
]
]This flies in the face of my 20 years of experience as an Electronics
]Engineer, including working with high precision time references at
]Odetics and CD/DVD jitter measuring circuits at Disc Manufacturing, Inc.
You did not see what I describe because you weren't looking for it.
The good place to look would be metrology publications.
]What causes clock drift (two clocks with diverging ansers as to what
]time it is) is simply the difference between the actual and desired
]frequency.
That is one reason. The other reason is the presense of dissipation
in resonant system, or, in other words, wide resonance curve. Atomic
clocks are more precise because they make use of very narrow resonance
curves.
] Easy to correct for.
Then why GPS satellites bother with atomic clocks ? Just get
some thermostabilized and recalibrated quartz clocks.
] What causes the frequency to drift
]is the physical aging of the crystal.
That's much slower process than thermal drift.
] If it was caused by a brownian
]style drift caused by jitter (what you call "cycle-by-cycle period
]variation"), the frequency would reset when I turned off the
]electronics overnight.
You don't understand the point I am making. The frequency doesn't
get "reset" if you turn off the circuit. In fact, average
frequency does not change. I estimate I said that 5 times or so already.
] Brownian motion of particles has memory (the
]position of the particle).
Precisely wrong. Brownian motion has no "memory" of any kind.
] Crystal clock frequency has no memory;
]the frequncy is derived on the spot from various electrical and
]mechanical factors.
]
--
From: [EMAIL PROTECTED] (Michael Kagalenko)
Crossposted-To: sci.physics
Subject: Re: Intel 810 chipset Random Number Generator
Date: 29 Jan 2000 00:07:06 GMT
Reply-To: [EMAIL PROTECTED]
Guy Macon ([EMAIL PROTECTED]) wrote
]In article 86qreo$mr7$[EMAIL PROTECTED], [EMAIL PROTECTED]
](Michael Kagalenko) wrote:
]
]Trevor Jackson, III ([EMAIL PROTECTED]) wrote
]
]]Further, you are assuming that clock drift is unpredictable.
]]This is simply invalid.
]
] No. You are wrong. Since quartz crystals have mechanical losses, they
] will have thermal noise, for the same mathematical reason that
] resistor has thermal noise.
]
]No one has disagreed with this.
No one showed any signs of having understood this.
] What the problem is is that this is
]a third or fourth order effect, completly swamped by predictable
]sources of variation.
We can discuss the magnitude of the thermal clock drift once there
is an agreement that the effect exists. So far, everyone opposing me
in this thread that it does not exist at all, not that it is small.
]] Given a small sample of measurements it is straightforward to
]]extrapolate the drift. That means it is predictable. That means it isn't
]]random. That means your argument fails.
]
] No, - it means that you a) did not read my post, where I said that
] systematic drift can and should be eliminated
] b) do not understand why random noise will
Cryptography-Digest Digest #998
Cryptography-Digest Digest #998, Volume #10 Sat, 29 Jan 00 01:13:02 EST
Contents:
Re: Pencil paper cipher question ("r.e.s.")
Re: can someone encrypt for me? (HeuyWorld)
Re: Pencil paper cipher question ("r.e.s.")
Re: Pencil paper cipher question (David Wagner)
Re: Crypto/Security/Cryptanalysis Papers (Tom St Denis)
Block chaining ("Adam Durana")
Re: Intel 810 chipset Random Number Generator ("Trevor Jackson, III")
Re: "Trusted" CA - Oxymoron? (John G. Otto)
Re: How to password protect files on distribution CD (Johnny Bravo)
Re: Block chaining (David Wagner)
Re: *** ECC Strong and Weak combined (David Hopwood)
Re: ECM Factoring and RSA Speed Ups (David Hopwood)
Re: How much does it cost to share knowledge? ("Douglas A. Gwyn")
Re: Mac encryption algorithm? ("Douglas A. Gwyn")
Re: How much does it cost to share knowledge? (David A Molnar)
Re: Classical Crypto Books ("Douglas A. Gwyn")
Re: NEC claims New Strongest Crypto Algor (wtshaw)
Re: "Trusted" CA - Oxymoron? (wtshaw)
From: "r.e.s." [EMAIL PROTECTED]
Subject: Re: Pencil paper cipher question
Date: Fri, 28 Jan 2000 18:50:50 -0800
[ apologies if this posting appears twice -- my server's misbehavin' ]
"Uri Blumenthal" [EMAIL PROTECTED] wrote ...
: John Savard wrote:
[...]
: The use of a straddling checkerboard, so that you can add digits
: instead of using a 26 x 26 Vigenere table is then advisable.
:
: You might get some ideas from my page. I'd recommend something
: involving fractionation. http://www.ecn.ab.ca/~jsavard/crypto.htm
:
: Yes, a very good advice. My vote goes for VIC. It's bloody hard
: to memorize the generation sequence, but once it's done, it's
: quite secure.
It was quite secure before the algorithm became well-known, but if
an opponent knows that VIC is the cipher you're using, then the
effective keyspace entropy is no more than ~36 bits. (I'm referring
to the VIC cipher as described on John Savard's website, mentioned
above.)
The VIC cipher uses a "passphrase" of 6 digits and 20 letters, but
processes it down to a critical string of 10 digits (i.e. 33 bits),
and this string completely specifies both a straddling checkerboard
and a double transposition, assuming the algorithm is known. Even
if we add another 3.3 bits for the one digit used to hide the
message key, that's still only ~36 bits.
So it seems to me that to be reasonably secure, the VIC cipher
needs to be modified, say to lengthen its "critical digit string"
to ~20 digits, for ~66 bits of entropy. (And correspondingly longer
passphrases should then be incorporated.)
But as for the main crypto components (the straddling checkerboard
double transposition) -- they represent well over 100 bits of
entropy to a brute-force attack. In fact, the checkerboard (even
assuming it's built around a known permutation of the alphabet)
has at least 10! keys -- 22 bits -- and the double transposition
with variable column widths has a number of keys equal to
sum(m!n!, m=lo..hi, n=lo..hi, m=/=n). With lo=11 and hi=20,
corresponding to VIC having a "personal id#" of 10, the latter
amount is ~119 bits. (A pid# of 8 would give ~102 bits.) If we
include the single digit used to hide the message key (3.3 bits),
this means the total entropy *potential* of the cipher is at least
~134 bits against a brute-force attack. But to take advantage of
that potential, these components would need to be "packaged" more
securely than in the published version.
(I wish I had a better idea of the difficulty of "breaking" the
sort of double transposition involved here -- it's esp. difficult
because although the first stage transposition uses a simple keyed
row-wise fill, the second one uses a keyed "serrated fill".
Considering also that the column widths are random, and that the
symbols are fractionated digits with a quite uniform frequency
distribution, it's hard to believe that this could be anywhere
close to breakable in practice, if properly "packaged" as
described above.)
--
r.e.s.
[EMAIL PROTECTED]
--
From: [EMAIL PROTECTED] (HeuyWorld)
Subject: Re: can someone encrypt for me?
Date: 29 Jan 2000 03:04:12 GMT
Subject: can someone encrypt for me?
From: [EMAIL PROTECTED] (Cutedoggy99)
Date: 1/16/00 3:48 AM Eastern Standard Time
Message-id: [EMAIL PROTECTED]
Could someone please encrypt this url address for me in crypto version 0:
http://www.cutedoggy.com/sponsors/
here it is in DDEZI .. hope this clears things up ... :
02106106133133715715701101101114704117106107121115132132126114704115137115
7001331151141001151351001157
--
From: "r.e.s." [EMAIL PROTECTED]
Subject: Re: Pencil paper cipher question
Date: Fri, 28 Jan 2000 19:03:46 -0800
"David Wagner" wrote ...
: Ok, so let's assume for the moment that the initial fill of the
: "shift register" with digits can be made sufficiently secure (hard to
guess).
