Cryptography-Digest Digest #534, Volume #12 Fri, 25 Aug 00 12:13:00 EDT
Contents:
Navigator and Internet Explorer SSL X.509 Profile (Klaus Schmeh)
Re: My encryption algorithm ([EMAIL PROTECTED])
Re: PGP Bug: IMPORTANT Personal test report (Steven Markowitz)
Re: "Warn when encrypting to keys with an ADK" (Phil Harrison)
Re: "Warn when encrypting to keys with an ADK" (S.R. Heller)
Re: "Warn when encrypting to keys with an ADK" (Ron B.)
Re: Bytes, octets, chars, and characters (Dan Pop)
Re: The DeCSS ruling ("Trevor L. Jackson, III")
Re: PGP Bug: IMPORTANT Personal test report ("Michel Bouissou")
Re: Asymmetric Encryption Algorithms ("Paul Montgomery")
Re: My encryption algorithm (jkauffman)
Re: Bytes, octets, chars, and characters (Guy Macon)
Re: need help! (John Myre)
Re: Steganography vs. Security through Obscurity (Guy Macon)
Re: UNIX Passwords ([EMAIL PROTECTED])
Re: Bytes, octets, chars, and characters ("Douglas A. Gwyn")
Re: Asymmetric Encryption Algorithms ([EMAIL PROTECTED])
Re: Bytes, octets, chars, and characters ("Douglas A. Gwyn")
Re: My unprovability madness. ("Douglas A. Gwyn")
Re: Serious PGP v5 & v6 bug! ("Douglas A. Gwyn")
challange ([EMAIL PROTECTED])
Re: UNIX Passwords ("Paul Montgomery")
Re: My encryption algorithm (Mack)
Re: Bytes, octets, chars, and characters ("Scott Fluhrer")
----------------------------------------------------------------------------
From: Klaus Schmeh <[EMAIL PROTECTED]>
Subject: Navigator and Internet Explorer SSL X.509 Profile
Date: Fri, 25 Aug 2000 15:19:33 +0200
Does anybody have detailed information about the X.509 profile the
Internet Explorer and the Netscape Navigator use for the SSL protocol?
Regards
Klaus
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: My encryption algorithm
Date: Fri, 25 Aug 2000 13:25:41 GMT
In article <8o4ij6$eub$[EMAIL PROTECTED]>,
"Slava K." <[EMAIL PROTECTED]> wrote:
> I have designed a new encryption algorithm, and would like comments
about
> it's security. The following is a specification of the algorithm in
general
> programming terms. Tell me what you think. EMail me your comments
> ([EMAIL PROTECTED]).
>
> · A password of any size is inputted (K). If K is the length of zero
or one,
> and error is reported.
> · A counter – N1 is set to the first character of the password. N2 is
set to
> the second.
> · The two password character (Respective to N1 and N2. They may be
converted
> to integers or bytes if required by the language) are XORed together
(X).
> · A character is read from the input file (P. This can again be
converted
> into an integer or a byte if required) and XORed with X.
> · The result is written to the output file.
> · If N1 equals the size of K, it is set to 1. Otherwise, N1 equals N1
+ 1.
> · If N2 equals the size of K, it is set to 1. Otherwise, N2 equals N2
+ 1.
> · The process is repeated if there are any characters left to encrypt.
>
Wow a modification of a Vinegere Cipher (I think). Righto.
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (Steven Markowitz)
Crossposted-To: alt.security.pgp,comp.security.pgp.discuss
Subject: Re: PGP Bug: IMPORTANT Personal test report
Date: 25 Aug 2000 13:36:12 GMT
In article <8o5kqk$mls$[EMAIL PROTECTED]> "Michel Bouissou" <[EMAIL PROTECTED]>
writes:
[ snip ]
>==> IMPORTANT NOTE:
>THIS IS MOST IMPORTANT. Reading carefully Ralf's paper, the ADK public key
>seems NOT to be actually included in public keys that mention mandatory use
>of this ADK. YOU MUST HAVE THE ADK public key as well. Only the ADK's key ID
>is included in the key that holds and ADK, which is not enough to allow
>encryption to the ADK by itself.
If the public key contains only the key id of the ADK, then isn't that a
serious security flaw? My understanding is that it is possible for an
attacker to create a new key having the same key id as an existing key,
although the fingerprints will differ. I have read that this can be done
for RSA keys; I'm not sure about DH/DSS keys. This would allow an
attacker to cause messages to be encrypted to himself, instead of to the
intended ADK, as long as the sender had the attacker's ADK on his
keyring.
This attack would apply even if the recipient's key had not been tampered
with. It seems to me that in order for the ADK mechanism to be secure,
the signed portion of a key would have to include the key id, length, and
key fingerprint of the ADK.
Am I misuderstanding something, or is the current ADK setup inherently
insecure?
---- Steven Markowitz
--
Any views expressed in this message are those of the individual
sender, except where the sender specifically states them to be the
views of D. E. Shaw & Co., L.P. or any of its affiliates.
------------------------------
From: Phil Harrison <[EMAIL PROTECTED]>
Crossposted-To: alt.security.pgp,comp.security.pgp.discuss
Subject: Re: "Warn when encrypting to keys with an ADK"
Date: Fri, 25 Aug 2000 14:23:13 +0100
In article <8o5nms$mom$[EMAIL PROTECTED]>, Michel Bouissou
<[EMAIL PROTECTED]> writes
>S.R. Heller <[EMAIL PROTECTED]> a écrit dans le message :
>8o5n05$kiv$[EMAIL PROTECTED]
>>
>> I think there is some (quite understandable) misunderstanding about
>> this option in NAI's PGP. Despite what the average English-speaker
>> might think, the phrase does not mean, "If I encrypt to a public key
>> with an ADK, warn me."
>
>Yes, there indeed is such a misunderstanding !!!
>
>I'm a frenchman and english is not my own language, and I was stupid enough
>to think that when selecting and option that says "Warn when encrypting to
>keys with an ADK" I probably would get warned "when encrypting to keys with
>an ADK"...
>
>How stupid!
>
The help file says the following:
========================================================
Warn When Encrypting Keys to keys with an ADK
Warns you if the key you are encrypting to is also encrypted to an
Additional Decryption Key (ADK).
========================================================
This was certainly enough to cause this native English speaker to
believe that I would get some kind of warning if the key I was
encrypting to had an ADK. However my own tests seem to verify what Steve
said. You don't get a warning even when this option is selected.
Admittedly the problem is perhaps not as bad as some people think, since
you actually need to have the ADK on your keyring as well as the
recipient's key. However, it does look as though this whole ADK feature
was implemented in a bit of a sloppy way.
--
Phil Harrison
------------------------------
From: S.R. Heller <[EMAIL PROTECTED]>
Crossposted-To: alt.security.pgp,comp.security.pgp.discuss
Subject: Re: "Warn when encrypting to keys with an ADK"
Date: Fri, 25 Aug 2000 06:57:23 -0700
Reply-To: [EMAIL PROTECTED]
=====BEGIN PGP SIGNED MESSAGE=====
On Fri, 25 Aug 2000 14:10:01 +0200, "Michel Bouissou"
<[EMAIL PROTECTED]> wrote:
>S.R. Heller <[EMAIL PROTECTED]> a écrit dans le message :
>8o5n05$kiv$[EMAIL PROTECTED]
>>
>> I think there is some (quite understandable) misunderstanding
>> about this option in NAI's PGP. Despite what the average
>> English-speaker might think, the phrase does not mean, "If I
>> encrypt to a public key with an ADK, warn me."
>
>Yes, there indeed is such a misunderstanding !!!
>
>I'm a frenchman and english is not my own language, and I was stupid
>enough to think that when selecting and option that says "Warn when
>encrypting to keys with an ADK" I probably would get warned "when
>encrypting to keys with an ADK"...
As you know (since you got a copy) someone from PGP has written with
a correction of my explanation of what the option means. For the
benefit of everyone else, the offered correction is that "Warn when
encrypting to keys with an ADK" means "make sure I see the recipient
dialog if there is an ADK being used," this being relevant in certain
plugins which might not otherwise display the dialog.
The point, however, is still that the option doesn't do what most
people expect it to. Be warned.
SH
=====BEGIN PGP SIGNATURE=====
Version: PGPfreeware 6.5.1 for non-commercial use <http://www.pgp.com>
iQCVAwUBOaZ7Gk/8MJkAFkZtAQFGOAQApvVtgQ+vm0Y/wq0P9XL7Y/uOqczineUe
CWIs7wBAuAqB7hJOP66ZICiyEppEHuSgQc4aEmBvMptiZfxB/Ug6jOGJGL1vdqy2
8b0r7NaGDBrLV6ynzJdkPkQhwyxd7T9oh48e9IAlI7iLIus/1iAr5qfkWYZ+k5bA
/uOAVJW3Evk=
=Uze+
=====END PGP SIGNATURE=====
------------------------------
From: Ron B. <[EMAIL PROTECTED]>
Crossposted-To: alt.security.pgp,comp.security.pgp.discuss
Subject: Re: "Warn when encrypting to keys with an ADK"
Date: Fri, 25 Aug 2000 13:58:56 GMT
=====BEGIN PGP SIGNED MESSAGE=====
Hash: SHA1
On Fri, 25 Aug 2000 04:56:48 -0700, S.R. Heller <[EMAIL PROTECTED]>
wrote:
>I think there is some (quite understandable) misunderstanding about
>this option in NAI's PGP. Despite what the average English-speaker
>might think, the phrase does not mean, "If I encrypt to a public key
>with an ADK, warn me." Those of you with a key with an ADK (called
>internally an Additional Recipient Request) on it can see that this
>doesn't happen. What the option means is, "If I encrypt to a public
>key with an ARR, and then try to remove the ADK from the recipient's
>list [i.e., from the lower pane in the select recipients dialog],
>warn me that this might be 'violating the policy' established for
>the key with the ARR." That's a mouthful, but you can test it
>yourself to see what I mean.
>
Important info deleted.
I followed through on your suggestion and verified that you are
correct. The warn label seems to apply to the enforced AAR only.
However, from the pgpwinusersguide.pdf documentation:
• Warn when encrypting to an ADK. Use this checkbox to specify
whether
to issue a warning whenever an encrypt-to key has an associated
Additional Decryption Key.
Is this an error in the documentation or a deliberately misleading
statement?
=====BEGIN PGP SIGNATURE=====
Version: PGPfreeware 6.5.3 for non-commercial use <http://www.pgp.com>
iQA/AwUBOaZ7igzUoy7OvTSOEQKTswCeLr4ac99gwUBg/nZvVRJvGFheHL0AoIpy
oOSRy8PmqD1PDjQj7A2T2Had
=E6co
=====END PGP SIGNATURE=====
------------------------------
From: [EMAIL PROTECTED] (Dan Pop)
Crossposted-To: comp.lang.c
Subject: Re: Bytes, octets, chars, and characters
Date: 25 Aug 2000 13:52:42 GMT
In <[EMAIL PROTECTED]> Benjamin Goldberg <[EMAIL PROTECTED]> writes:
>It's too bad that integers weren't initially called int8, int16, etc,
Yeah, and how would you *meaningfully* implement these types on a
machine with 9-bit bytes and 36-bit words? One of the first
implementations of the C language was done on such a machine (it's
mentioned in K&R1).
Dan
--
Dan Pop
CERN, IT Division
Email: [EMAIL PROTECTED]
Mail: CERN - IT, Bat. 31 1-014, CH-1211 Geneve 23, Switzerland
------------------------------
Date: Fri, 25 Aug 2000 10:16:50 -0400
From: "Trevor L. Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: The DeCSS ruling
[EMAIL PROTECTED] wrote:
> A. Melon <[EMAIL PROTECTED]> wrote:
> > If the New York Times published the source (a la Pentagon Papers)
> > would the judge have ruled against them? Another example would be
> > the magazine that published detailed directions to making atomic
> > bombs.
>
> Yes, because there's a law against reverse-engineering copy
> protection, not against publishing.
Does a security system that publishes the cipher key count as copy
protection? Calling it copy protection does not make it copy protection.
------------------------------
From: "Michel Bouissou" <[EMAIL PROTECTED]>
Crossposted-To: alt.security.pgp,comp.security.pgp.discuss
Subject: Re: PGP Bug: IMPORTANT Personal test report
Date: Fri, 25 Aug 2000 16:34:27 +0200
Steven Markowitz <[EMAIL PROTECTED]> a écrit dans le message :
8o5soc$rer$[EMAIL PROTECTED]
>
> If the public key contains only the key id of the ADK, then isn't that a
> serious security flaw?
By "ID of the key", I meant "Fingerprint of the key". Ralf Senderek clearly
states in his detailed study that it is the fingerprint of the ADK key (from
which the key ID can be easily derived) which is stored in the
self-signature of the key.
> My understanding is that it is possible for an
> attacker to create a new key having the same key id as an existing key,
> although the fingerprints will differ.
The full fingerprint being stored, this attack cannot be performed.
> Am I misuderstanding something, or is the current ADK setup inherently
> insecure?
Even with this attack eliminated, I would say that IMHO this ADK setup is
indeed inherently worrying :-\
--
Michel Bouissou <[EMAIL PROTECTED]> PGP DH/DSS ID 0x5C2BEE8F
------------------------------
From: "Paul Montgomery" <[EMAIL PROTECTED]>
Subject: Re: Asymmetric Encryption Algorithms
Date: Fri, 25 Aug 2000 10:39:33 -0400
> There is no reason why DSA doesn't use larger numbers other then
> because it says so in the specs. And DH is not an encryption
> algorithm, nor is DSA.
Thank you for your feedback. I did see where someone (was it Phil
Zimmerman in PGP maybe?) extended DSA to 2048 bits but I read an article
where the method he used apparently added very little extra security. In
the code I have for DSA I found a #define to set the max key size to 1024,
surely it is not as simple as just changing that value to whatever you
please? Can anyone cite a software project example where the key size was
extended properly so that I may study their methods? (I don't consider
myself anything but an amateur cryptographer if that and wouldn't feel
secure in producing my own version of DSA to be honest, I am a programmer at
heart but I'm trying to learn.)
I am sort of surprised at encryption key sizes in software these days.
It seems symmetric encryption schemes have long enough key lengths (256+) to
keep them fairly secure from attack for a few years but the asymmetric key
exchange key lengths in a lot of software projects seem to hover around 1024
which appears to be on the "iffy" side with current technology. Does it
seem like asymmetric key sizes are a bit small in comparison to symmetric
key sizes or am I totally off on this?
Thanks,
Paul
------------------------------
From: jkauffman <[EMAIL PROTECTED]>
Subject: Re: My encryption algorithm
Date: Fri, 25 Aug 2000 08:34:44 -0700
errr.... no.
* Sent from AltaVista http://www.altavista.com Where you can also find related Web
Pages, Images, Audios, Videos, News, and Shopping. Smart is Beautiful
------------------------------
From: [EMAIL PROTECTED] (Guy Macon)
Crossposted-To: comp.lang.c,alt.folklore.computers
Subject: Re: Bytes, octets, chars, and characters
Date: 25 Aug 2000 14:58:05 GMT
Joona I Palaste wrote:
>Processor trivia: The 6510 microprocessor includes the instruction
>JAM (code 0x02), which will completely hang (ie. jam) the computer.
>To be able to proceed, you must do a power-cycle. What the heck is the
>use of this instruction?
JAM, being an illegal opcode, has other names such as KIL or HLT.
The design of the 6510 was done with logic, not microcode, and most
of the illegal instructions turn out to act like wierd combinations
of a coupl of the legal ones.
------------------------------
From: John Myre <[EMAIL PROTECTED]>
Subject: Re: need help!
Date: Fri, 25 Aug 2000 08:57:13 -0600
On my news server, the original request came through at
10:44 PM yesterday, while Jim's answer arrived at 10:33.
Jim, I knew you were good, but I didn't realize the Karnak
attack was real...
JM
------------------------------
From: [EMAIL PROTECTED] (Guy Macon)
Subject: Re: Steganography vs. Security through Obscurity
Date: 25 Aug 2000 15:04:36 GMT
[EMAIL PROTECTED] wrote:
>
>Well, I was interested in the application of Traitor Tracing.
>If the message obviously includes encoded information, then the traitor
>won't pass it on.
Traitor Tracing - detecting which recipient is passing on info?
The classic method is to distribute about 16 different versions of the
document and to see which gets passed on, then to do it again until you
catch the leaker. Sometimes you can use a unique combination of " "
and " " characters (space and ASCII 255 - look the same on many
systems) between words.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: UNIX Passwords
Date: 25 Aug 2000 15:06:39 GMT
Martin 'SirDystic' Wolters wrote:
>
>Hi,
>
>Is there a description available,
>how UNIX encrypts (or hashes) its
>Passwords?
Yes, but if we told you that we would have to kill you.
------------------------------
Crossposted-To: comp.lang.c
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Bytes, octets, chars, and characters
Date: Fri, 25 Aug 2000 14:26:01 GMT
"Bruce G. Stewart" wrote:
> Hey, c could free up a key word by using "signed signed" instead of
> "unsigned".
If it weren't for the historical ambiguity about whether plain
"char" is signed or unsigned, we could dispense with "signed"
altogether, since it's the default for all other integer types.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Asymmetric Encryption Algorithms
Date: Fri, 25 Aug 2000 15:10:28 GMT
In article
<[EMAIL PROTECTED]>,
"Paul Montgomery" <[EMAIL PROTECTED]> wrote:
> > There is no reason why DSA doesn't use larger numbers other then
> > because it says so in the specs. And DH is not an encryption
> > algorithm, nor is DSA.
>
> Thank you for your feedback. I did see where someone (was it Phil
> Zimmerman in PGP maybe?) extended DSA to 2048 bits but I read an
article
> where the method he used apparently added very little extra
security. In
> the code I have for DSA I found a #define to set the max key size to
1024,
> surely it is not as simple as just changing that value to whatever you
> please? Can anyone cite a software project example where the key
size was
> extended properly so that I may study their methods? (I don't
consider
> myself anything but an amateur cryptographer if that and wouldn't feel
> secure in producing my own version of DSA to be honest, I am a
programmer at
> heart but I'm trying to learn.)
> I am sort of surprised at encryption key sizes in software these
days.
> It seems symmetric encryption schemes have long enough key lengths
(256+) to
> keep them fairly secure from attack for a few years but the
asymmetric key
> exchange key lengths in a lot of software projects seem to hover
around 1024
> which appears to be on the "iffy" side with current technology. Does
it
> seem like asymmetric key sizes are a bit small in comparison to
symmetric
> key sizes or am I totally off on this?
I would more then totally suggest that a 256 bit symmetric key is
secure iff brute force is the only method of attacking the cryptosystem.
As for DiscreteLogs and Factoring I think at least 768 bit fields or
composites should be sufficient. You don't need 8kbit DH keys to be
secure...
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
Crossposted-To: comp.lang.c
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Bytes, octets, chars, and characters
Date: Fri, 25 Aug 2000 14:47:17 GMT
Benjamin Goldberg wrote:
> It's too bad that integers weren't initially called int8, int16, etc,
> with no "short" or "long" types. If that had been done, we wouldn't
> have to worry about this type of problem now. Of course, we might then
> have wanted a type word, hword, and dword *in addition* to specifically
> refer to a machine register, half of a register, or two registers... but
> unless I misrecall, some compilers have these defined.
A conforming C implementation has to limit its definition of
additional types etc. to identifiers in the name space reserved
for such purposes (starting with underscore, etc.)
There are more ways to specify the desired integer type than
merely by width. There is also the issue of whether the width
must be exact or is just a minimum requirement. The new C99
standard header <stdint.h> has type names and limit macros for
a variety of types, e.g. int_least32_t specifies a signed
integer type with width at least 32 bits and uint12_t specifies
an unsigned integer type with width exactly 12 bits, no padding,
and twos-complement representation. (You can test whether that
type exists by testing whether the corresponding limit macro
UINT12_MAX is defined.) <inttypes.h> includes <stdint.h> and
also defines format-specifier macros for use with printf and
scanf. This mechanism is a step toward requirements-based
type specification. You can use this method in applications
even on non-C99 platforms; <inttypes.h> has been around for
many years. If your system doesn't provide it already, a
public-domain implementation is available at
http://kbs.cs.tu-berlin.de/~jutta/c/q8/
If we wanted to take the <stdint.h> types as fundamental
(which they are not), the standard integer types could be
defined in terms of them:
define "int" as "int_fast16_t"
define "unsigned char" as "uint_least8_t"
etc. It is possible that some future revision of the C
standard might take an approach like that, although probably
using some new syntax for requirements-based specification:
define "int" as "_integer(minwidth=16,signed,fast)"
and maybe there could be something like "_representation(int)"
which would expand to source characters like "twos-complement,
width=64,padding=15,31,47,byteorder=(1,0,3,2,5,4,7,6)" that
could be used in specifying other related types. Or perhaps
this whole idea is too radical for C even in the future, but
it might be useful in designing a new language.
------------------------------
Crossposted-To: sci.math,sci.physics
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: My unprovability madness.
Date: Fri, 25 Aug 2000 15:00:06 GMT
"Steven B. Harris" wrote:
> In <8o32h5$9vj$[EMAIL PROTECTED]> Nathan the Great
> <[EMAIL PROTECTED]> writes:
> >In article <V8Wo5.4848$[EMAIL PROTECTED]>,
> > "Adam Russell" <[EMAIL PROTECTED]> wrote:
> >> No, I wasn't speaking of Godel. I was referring to the
> >> suggestion of a system of logic where unprovable statements
> >> are deemed to be false.
> >Adam, WHEN USING CONSTRUCTIVE LOGIC, unprovable
> >statements _are_ false, not just deemed to be.
> The difference between statements in logic which ARE false, and
> statements which are "merely" DEEMED to be false, is nothing but a foot
> stomp. For all statements in logic which ARE false, are merely "false"
> by definition of your particular construction of "false." How else?
Presumably he meant that for any given well-formed statement,
either it or its negation, but never both, can be proven.
That provides an unambiguous classification into "true",
"false", and "not well-formed".
------------------------------
Crossposted-To: alt.security.pgp,comp.security.pgp.discuss
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Serious PGP v5 & v6 bug!
Date: Fri, 25 Aug 2000 14:51:20 GMT
Anders Thulin wrote:
> I think you are mistaken: there's nothing in that article that indicates
> that Thompson actually did so. There's a 'would' at the critical point in the
> text where there's a question him inserting a bug into a compiler. That
> seems to make it quite clear that the case discussed is only an example
> of what could be done.
The experiment was actually carried out, but not in any compiler
that was distributed to customers.
------------------------------
From: [EMAIL PROTECTED]
Subject: challange
Date: Fri, 25 Aug 2000 15:39:02 GMT
try out the challange at
www.bnd.de
what could that be ? instead of ascii or unicode
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: "Paul Montgomery" <[EMAIL PROTECTED]>
Subject: Re: UNIX Passwords
Date: Fri, 25 Aug 2000 11:53:55 -0400
> Is there a description available,
> how UNIX encrypts (or hashes) its
> Passwords?
I can't speak for all Unix "brands" but OpenBSD uses Blowfish (default)
or MD5 hashing (on my vesion at least which is 2.4). If I were you I'd
probably just download the source code for login and look at it (if you know
C). Otherwise you could look them up elsewhere on the web or in some books.
It also might be useful to check out SHA-1, it is a powerful hashing
algorithm that can be used for storing passwords.
Paul
------------------------------
From: [EMAIL PROTECTED] (Mack)
Subject: Re: My encryption algorithm
Date: 25 Aug 2000 15:56:39 GMT
>I have designed a new encryption algorithm, and would like comments about
>it's security. The following is a specification of the algorithm in general
>programming terms. Tell me what you think. EMail me your comments
>([EMAIL PROTECTED]).
>
>· A password of any size is inputted (K). If K is the length of zero or one,
>and error is reported.
>· A counter – N1 is set to the first character of the password. N2 is set
to
>the second.
>· The two password character (Respective to N1 and N2. They may be converted
>to integers or bytes if required by the language) are XORed together (X).
>· A character is read from the input file (P. This can again be converted
>into an integer or a byte if required) and XORed with X.
>· The result is written to the output file.
>· If N1 equals the size of K, it is set to 1. Otherwise, N1 equals N1 + 1.
>· If N2 equals the size of K, it is set to 1. Otherwise, N2 equals N2 + 1.
>· The process is repeated if there are any characters left to encrypt.
>
>
A very simple cipher. It is a stream cipher. Than means that
using the same key twice for two different plaintext allows
the attacker to retrieve the XOR of the plaintext from
the ciphertext.
C1=KS^P1
C2=KS^P2
C1^C2=P1^P2
so if the attacker can get a single plaintext of length N+1 where
N is the password length he can recover any plaintext under that
key.
It also doesn't mix the key material so the attack can guess bits
and use a statistical attack on the ciphertext. This is the classic
attack on Vigenere ciphers. So yes it is related to them.
Mack
Remove njunk123 from name to reply by e-mail
------------------------------
From: "Scott Fluhrer" <[EMAIL PROTECTED]>
Crossposted-To: comp.lang.c,alt.folklore.computers
Subject: Re: Bytes, octets, chars, and characters
Date: Fri, 25 Aug 2000 08:36:01 -0700
Joona I Palaste <[EMAIL PROTECTED]> wrote in message
news:8o5mhm$c49$[EMAIL PROTECTED]...
> AndyC <[EMAIL PROTECTED]> scribbled the following
> on comp.lang.c:
>
>
> : On Fri, 25 Aug 2000, G Swaine wrote:
>
> :> The '020 required instructions to be on even addresses, AFAICR
>
> : That was a requirement of all 68k chips, IIRC.
>
> Yes it was. When I was programming on my 68000-based Amiga 500, I was
> once searching for a method to intentionally crash the computer. I
> found that it could be done by modifying a 16-bit word on an odd
> address.
> Processor trivia: The 6510 microprocessor includes the instruction
> JAM (code 0x02), which will completely hang (ie. jam) the computer.
> To be able to proceed, you must do a power-cycle. What the heck is the
> use of this instruction?
(This is a big IIRC, because it's been a while) The JAM instruction would
also cycle the address bus as fast as possible. I believe it was used as an
initial sanity check during manufacture -- just after fabbing the chip, they
would forcefeed it a JAM instruction, and if it did anything other than
cycling the address lines, they knew not to bother with a full test of that
chip.
--
poncho
------------------------------
** 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
******************************
