Cryptography-Digest Digest #804, Volume #10 Tue, 28 Dec 99 23:13:01 EST
Contents:
SSL And Certificate Verifications (Greg)
Re: Q: Cryptanalysis Shareware? (Glenn Larsson)
Re: Synchronised random number generation for one-time pads ("Joseph Ashwood")
Re: File format for CipheSaber-2? (Johnny Bravo)
____ Another ridiculous "new" patent - PC keyboards !! (Boogie)
Re: File format for CipheSaber-2? (Guy Macon)
Re: File format for CipheSaber-2? (Michael J. Fromberger)
Re: Homophones ([EMAIL PROTECTED])
Re: SSL And Certificate Verifications (Paul Rubin)
Re: Secure Delete Not Smart (Donald Haines)
----------------------------------------------------------------------------
From: Greg <[EMAIL PROTECTED]>
Subject: SSL And Certificate Verifications
Date: Tue, 28 Dec 1999 20:58:30 GMT
I am reading up on SSL and came across the certificate
verification process. It says that the certificate is
validated by several steps. At one point, the issuer
is verified, according to this document, by an
unspecified mechanism. So how does IE or Netscape
verify an issuer that it finds in a server's certificate?
Also, does the process of verifying the issuer dependent
upon the level of security that the browser is setup
to allow?
--
The only vote that you waste is the one you never wanted to make.
RICO- we were told it was a necessary surrender of our civil liberties.
Asset Forfeiture- the latest inevitable result of RICO.
http://www.ciphermax.com/book
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Glenn Larsson <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: Q: Cryptanalysis Shareware?
Date: Tue, 28 Dec 1999 22:16:02 +0100
modokon wrote:
>
> Hello,
> Is there any share/free ware that will enable me to play
> with encrypted messages (e.g. transposition etc). I'm
> reading Simon Singh's "The Code Book" and would like to scan
> it in & play a little without having to program in BASIC!
> Thank for any pointers,
> Joe
(Note: Source + wordlist at end of letter)
Hi.
1. In Nowhere Utillities, there is (if my memory serves me right)
a codebreaker that can (it says so) crack simple encryption, also
take a look at "Codebreakers Ttoolkit(or was it Workbench)" i'm
sure someone have a link/correct name for it. If not, Try altavista.
2. This is a little tool i wrote myself for generating a word-structure
representation out of (simple monofonic substitution ciphered)
"encrypted" data. (I say "Encrypted" in a loose manner as we all
know it is way easy to break.)
This us useful for getting a more precise letter frequency
analysis than normal letter frequency list would give.
It works in this way:
Take a word: "information" and run it through EnumerateWord().
Result = abcdefghadb. Now, run parts of the ciphertext the
size of the word "Information" or 11 through the same function
and compare as you go.
Example:
Ciphertext:
"FPC MZVKBRTFMKZ MZ FPMA VMSC TBC IKZVMQCZFMTS."
By running our comparison on the ciphertext, we find that:
EnumerateWord ("MZVKBRTFMKZ") = abcdefghadb
EnumerateWord ("INFORMATION") = abcdefghadb
So, now - we have found 8 characters, we try to decode:
"FPC MZVKBRTFMKZ MZ FPMA VMSC TBC IKZVMQCZFMTS."
=
"??? INFORMATION IN ??I? FI?? AR? ?ONFI??NTIA?."
(the information in this file are confidential."
Ironically - "Information" generate alot of good information,
like: "At,Am,If,It,If,On,-Tion" a.s.o. You can also use
phrases "how are you today blah blah bla" and so on.
There are probably better ideas on how to attack these kinds
of old ciphers, but this is _one_ way.
Have fun,
Glenn
Sweden
(P.S. Hopefully people will stop making these kinds of
ciphers and calling them "secure")
________________________________________________________
A short list of good words (with high structure):
ssibility, initialisation, communications, substitution,
effectiveness, negotiation, initiation, administrative
beginning, countermeasures, connection, ineffective,
insufficient, intellectual.
________________________________________________________
Function EnumerateWord(ByVal WTE As String) As String
Dim LA(64) As String
Dim CLA As Integer
Dim Found As Boolean
Dim Ary(256) As Integer
CLA = 1
AryVal = 1
For I = 1 To Len(WTE)
TestChar = Mid(WTE, I, 1)
Found = False
For K = 1 To 64
If TestChar = LA(K) Then
Found = True
Ch = Str(K)
End If
Next
If Found = False Then
LA(CLA) = TestChar
Ch = Str(CLA)
CLA = CLA + 1
End If
Ary(AryVal) = 96 + Val(Ch)
AryVal = AryVal + 1
Next
For K = 1 To 256
If Trim(Chr(Val(Ary(K)))) <> Chr(0) Then
EnumerateWord = EnumerateWord & Trim(Chr(Val(Ary(K))))
End If
Next K
End Function
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: Synchronised random number generation for one-time pads
Date: Tue, 28 Dec 1999 13:39:52 -0800
"Guy Macon" <[EMAIL PROTECTED]> wrote in message
news:847grb$[EMAIL PROTECTED]...
> I know that a fundamental property of XOR is that XORing anything
> to a true random (if such exists) message cannot reduce the randomness.
> is this also a known property of the way you are using DES? I sure can
> see the advantages iof it is.
I will not address DES in particular because it was simply an example of a
candidate, and at first blush it seems that any encryption method may stand
as a viable option. There is however a consideration that I did not mention
earlier which needs to be brought up that I believe is effectively
equivalent to a proof of not diminishing randomness. The main consideration
is that I am not aware of any duplicating keys (ie there does not exist a
key1 and key2 such that there exists a significant number of
inputs (input) f(key1, input)=f(key2, input) where key1 does not equal
key2).
While I do not have the compute power to verify it myself (as a matter of
fact, far from it), all that should be necessary is a brute force key search
given an input block and find any identical encrypted blocks. Given
associated blocks a search then needs to be done of the inputs to find the
outputs.
Given our (my) current knowledge of DES, and the fact that no significant
break has ever been verified (there are still people that claim there's a
back door of some kind), as a matter of fact there has been no significant
erosion of the key space of DES, it seems indicative of DES having few of
the correlations I mentioned earlier.
There are of course known identical keys in DES, this is a potentialy
significant erosion of security. I fully realize that for this reason DES is
not as secure for every purpose as XOR (which has no identical keys), in
fact for some purposes uses it could be self-defeating (ie the pad has
strong biases).
I see this as having a usefulness in stream ciphers, or in OTP situations
where there are locations in the plaintext that are a single bit whose
importance is of the utmost priority. I'm sure many of us have seen this
situation, one where a single bit determines whether or not a user is
required to change the password, or if a password is correct.
I don't see it making a significant difference in OTP, and in fact would
lower the security (in some cases critically, in some cases non-critically).
However in a stream cipher where it can be proven very simply that there is
a correlation between the key for one block and the next making it difficult
to find the key for any given block may be of use.
Joseph
ps. The establishment of no duplicate keys in XOR is simple to perform.
Which makes it an ideal candidate for a proof.
------------------------------
From: [EMAIL PROTECTED] (Johnny Bravo)
Subject: Re: File format for CipheSaber-2?
Date: Tue, 28 Dec 1999 19:10:58 GMT
On 28 Dec 1999 14:59:35 EST, [EMAIL PROTECTED] (Guy Macon) wrote:
>
>Is there a standard place to keep the "number of repeats" data? I would
>assume that it is desirable that when you run once the output should be
>bytet for byte compatable with CipherSaber-1. Is the number of repeats
>inserted in the keyphrase? in the initialization vector? What format
>would allow other folks who use CipherSaber-2 to decode my message?
Since you have to give the recipient your key beforehand, that is
when you give them the number of mixings to be used. It will vary per
person as hardware differs widely from one person to the next.
You could easily add something to the front of the file stating the
number of mixings used if it varies per message. Use of file
extensions .cs1 and .cs2 will let the program know if it should read
the front of the file and find this information. You don't have to
worry about CS-1 only programs reading this data as IV because they
can't handle multiple mixings anyway.
>Would limiting the number of repeats to 256 be good enough?
No repeats is secure as it is. If you are going to do it, you may
as well use whatever the shared hardware supports and whatever delay
you are willing to put up with. On my P200, my C implementation
without optimization gets about 4000 mixing rounds per second. 1.25
seconds is not much delay, so 5000N would be acceptable for my setup.
Your milage could vary.
Best Wishes,
Johnny Bravo
------------------------------
From: [EMAIL PROTECTED] (Boogie)
Subject: ____ Another ridiculous "new" patent - PC keyboards !!
Date: Wed, 29 Dec 1999 10:18:40 +1000
Some jerk has gotten a patent that essentially claims a monopoly on the PC
keyboard bus, the flimsy basis being that as a keypad with interactive
software, it prompts a user to enter his/her data into the patented
keyboard wedge i/o device. I am waiting for other people to "discover"
other generic classes of long standing, widely used PC bus interfaces,
such a "A Method And Apparatus to Display Information Using the SVGA
port".
I'm looking for military authentication i/o type devices (especially
keyboards) and figured this group would be a good place to start.
Can someone tell me the galactic co-ordinates of where the Patent Office
Examiners hang out thesedays ?
Sorry about the non de plume, but darn spammers...you can get me using the
No. 1 spam haven and totally disreputable service that everyone has at
least a dozen accounts [EMAIL PROTECTED]
Even Royalty can have a Hotmail account. Be sure to send HTML mail with
animated attachments such talking paper clips and helpful talking parrots
squarking to constantly interrupt my train of thought. Mail messages
under 100 mB will not be read as these might convey useful info :-)).
*******
The notion of a device known as a keyboard wedge is not new. Magtek Inc. and
others have been connecting credit card swipe units, bar code readers and
other external "add on keyboards" and peripherals for years. Another example
was an "add on" numeric keyboard Apple Computers Inc. offered in the mid
1980s, specifically designed for being added onto the keyboard bus in the Mac
Plus line of PC's, and can be seen illustrated in US Patent No. 0,286,047
(Roots, 1984). IBM, the inventor of the PC keyboard, also offered such a
device in US Patent 0,337,106 (Jasinski 1990), as well as US Patent 0,347,835
(Zarnowitz, 1982, Kensington Microware Limited), Macally (Mace Group Inc) and
others. In yet another example there has existed since the 1980s the "Bat"
device (one of over a dozen keyboard hardware items) made by Infogrip Inc.
which consists of a keypad with seven keys designed to emulate the specialised
keyboards used by Court Reporters and shorthand operaters. Most if not all
included specialised drivers and application software to take advantage of the
specialised keyboard hardware. Other hardware authentication PC add-ons
have been made and sold by companies such as Atalla and others.
Before leaving this topic, the 1980s saw a variety of PC keyboard "dongles"
designed to prevent pirated software, typically using encryption, that are
well known to anyone who reads the backpages of various computer magazines,
and finally Troll Technology Corporation that used a PC keyboard bus to
control and capture input from a touch screen layer. This does not begin to
touch the various military terminals and keyboards designed for secure logins,
cryptographic authentication and the prevention of electromagnetic leakage
(known as "Tempest" terminals) referred to in the US Department of Defense
Department of Defense "Trusted Computer System Evaluation Criteria" (1985) and
known to anyone skilled in the art.
------------------------------
From: [EMAIL PROTECTED] (Guy Macon)
Subject: Re: File format for CipheSaber-2?
Date: 28 Dec 1999 20:36:07 EST
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Johnny Bravo)
wrote:
>
>On 28 Dec 1999 14:59:35 EST, [EMAIL PROTECTED] (Guy Macon) wrote:
>
>>
>>Is there a standard place to keep the "number of repeats" data? I would
>>assume that it is desirable that when you run once the output should be
>>bytet for byte compatable with CipherSaber-1. Is the number of repeats
>>inserted in the keyphrase? in the initialization vector? What format
>>would allow other folks who use CipherSaber-2 to decode my message?
>
> Since you have to give the recipient your key beforehand, that is
>when you give them the number of mixings to be used. It will vary per
>person as hardware differs widely from one person to the next.
I would like to avoid having to tell the recipient a passprase and a
number. Doing so adds a large memorization burden for a small increase
in security.
> You could easily add something to the front of the file stating the
>number of mixings used if it varies per message. Use of file
>extensions .cs1 and .cs2 will let the program know if it should read
>the front of the file and find this information. You don't have to
>worry about CS-1 only programs reading this data as IV because they
>can't handle multiple mixings anyway.
Yes, but they CAN handle CipherSaber-2 encrypted messages if the number
of repeats is 1, and the format is proper. This is a desirable property.
>>Would limiting the number of repeats to 256 be good enough?
> No repeats is secure as it is. If you are going to do it, you may
>as well use whatever the shared hardware supports and whatever delay
>you are willing to put up with. On my P200, my C implementation
>without optimization gets about 4000 mixing rounds per second. 1.25
>seconds is not much delay, so 5000N would be acceptable for my setup.
>Your milage could vary.
So you would need to either have sender and recipient memorize a 5
digit number along with the passphrase, or you would have to send
the number along as part of the IV + ciphertext and you would need
two bytes to do it. Which did you decide to do in your program??
If the latter, did you put the iteration number at the start of
the file, at the end, or between IV and the ciphertext?
It sure would be nice if my CipherSaber-2 would work with a
CipherSaber-2 that someone else wrote from a description.
------------------------------
From: Michael J. Fromberger <[EMAIL PROTECTED]>
Subject: Re: File format for CipheSaber-2?
Date: 29 Dec 1999 01:52:09 GMT
In <84boi7$[EMAIL PROTECTED]> [EMAIL PROTECTED] (Guy Macon) writes:
>In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Johnny Bravo)
>wrote:
>>
>>On 28 Dec 1999 14:59:35 EST, [EMAIL PROTECTED] (Guy Macon) wrote:
>>
>>>
>>>Is there a standard place to keep the "number of repeats" data? I would
>>>assume that it is desirable that when you run once the output should be
>>>bytet for byte compatable with CipherSaber-1. Is the number of repeats
>>>inserted in the keyphrase? in the initialization vector? What format
>>>would allow other folks who use CipherSaber-2 to decode my message?
>>
>> Since you have to give the recipient your key beforehand, that is
>>when you give them the number of mixings to be used. It will vary per
>>person as hardware differs widely from one person to the next.
>I would like to avoid having to tell the recipient a passprase and a
>number. Doing so adds a large memorization burden for a small
>increase in security.
>From a cognitive perspective, I doubt it's a significant additional
memorization "burden". However, if you really don't like it, why
don't you make the number of key iterations a function of the
passphrase...for example, the number of words, or the number of
characters?
Using a simple rule like this is probably preferable to imposing
additional overhead on CS-2. Alternatively, you could define a new
encrypted message format which uses CS-2 as the encryption standard,
and includes other headers information as desired. Don't forget, the
point of CipherSaber is to be as simple as possible. If it isn't
broken, don't fix it -- just use CipherSaber as a component of a more
complex system, if you want more complexity.
That's my advice, at any rate.
Cheers,
-M
--
Michael J. Fromberger Software Engineer, Thayer School of Engineering
sting <at> linguist.dartmouth.edu http://www.dartmouth.edu/~sting/
iK+kT0M1Iscs+ELCy04z3dLa1XNPWKAS0bUbyZCzKbwdzdBZyQZDJ84VqfbN1q+iB3jY8B1C
Remove clothing if you want to reply to this message via e-mail.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Homophones
Date: Wed, 29 Dec 1999 02:44:21 GMT
Mok-Kong Shen wrote:
> I think it might be of value to point out that the utility of
> homophone appears to have been largely ignored nowadays.
There were three papers in Crypto 82 dealing with
homophonic ciphers; I often recommend the Rivest
and Sherman paper. The techniques did not catch
on, probably because ciphers seem to do so well
without them. Today public-key encryption is
done with homophonic blocks, but secret-key
systems typically use no more than an IV. The
major recent advance using homophones is Bellare
and Rogaway's use of randomness in RSA-style
signatures.
--Bryan
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (Paul Rubin)
Subject: Re: SSL And Certificate Verifications
Date: 29 Dec 1999 03:43:20 GMT
In article <84b7r4$g6j$[EMAIL PROTECTED]>, Greg <[EMAIL PROTECTED]> wrote:
>I am reading up on SSL and came across the certificate verification
>process. It says that the certificate is validated by several steps.
>At one point, the issuer is verified, according to this document, by
>an unspecified mechanism. So how does IE or Netscape verify an
>issuer that it finds in a server's certificate?
A list of trusted issuers is built into the browsers as distributed
by Microsoft and Netscape. You can see the list in in Netscape 4.x by
clicking the lock icon and selecting "signers" in the left hand menu
of the dialog that pops up. In IE, select View->Internet Options->Content
->Authorities.
>Also, does the process of verifying the issuer dependent upon the
>level of security that the browser is setup to allow?
Kind of sort of but not really. There are a bunch of different protocols
possible and some browsers support more of them than others.
------------------------------
From: Donald Haines <[EMAIL PROTECTED]>
Subject: Re: Secure Delete Not Smart
Date: Tue, 28 Dec 1999 22:52:56 -0500
Guy Macon wrote:
>
>
> Minor correction; modern drives do not depend on mechanical tolerances.
> They servo to the center of the track. Everything else you said is 100%
> correct, because servos can go bad and be off to one side of the track.
And there is a great side benefit of physical destruction..... Disassemble the drive,
grind
off the surface of the platters, and you get to keep the magnets to use to hold stuff
to your
fridge.
Don Haines
------------------------------
** 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
******************************
