Cryptography-Digest Digest #623
Cryptography-Digest Digest #623, Volume #14 Sat, 16 Jun 01 06:13:00 EDT
Contents:
Re: Tell me could this one-way function be somewhat secure (Tim Tyler)
Re: IV (Tim Tyler)
Re: IV (David Wagner)
Re: Is ECB truly more secure than CBC? (Tim Tyler)
Re: Diffusion limits in block ciphers (Tim Tyler)
Re: Is ECB truly more secure than CBC? (Tim Tyler)
Re: IV (Tim Tyler)
Re: Is ECB truly more secure than CBC? (Nomen Nescio)
Re: Is ECB truly more secure than CBC? (David Wagner)
Re: IV (David Wagner)
Re: integration question (Paul Rubin)
Re: Simple Crypto II, the public key... (Fat Phil)
Re: Tell me could this one-way function be somewhat secure ("Marko Lavikainen")
Re: Simple Crypto II, the public key... (Fat Phil)
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Tell me could this one-way function be somewhat secure
Reply-To: [EMAIL PROTECTED]
Date: Sat, 16 Jun 2001 06:01:25 GMT
wtshaw <[EMAIL PROTECTED]> wrote:
: In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote:
:> Marko Lavikainen <[EMAIL PROTECTED]> wrote:
:> : I was wondering that when using hash-function, there is always a change for
:> : collision. So, could not one use, say, two hash functions with different
:> : properties. [...]
:>
:> That's much the same as increasing the size of the hash. You'll still get
:> collisions - but not so frequently.
: Actually, you might not... [...]
Well, you *will* if you hash material with more entropy that the width of
the combined hash. A scarcity of source material appears to be why
Marko's example failed to demonstrate this.
--
__
|im |yler [EMAIL PROTECTED] Home page: http://alife.co.uk/tim/
--
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: IV
Reply-To: [EMAIL PROTECTED]
Date: Sat, 16 Jun 2001 06:08:25 GMT
David Wagner <[EMAIL PROTECTED]> wrote:
: Mark Currie wrote:
:>how does CTR compare with CBC from a security perspective ?
: They're both secure for secrecy, if the underlying block cipher is secure.
: (Maybe I didn't understand the question.)
No.
Did you read my posts surrounding (mainly following) the comment by
Mark Wooding on this thread?
There I explain the problem with CTR mode, and why it is /not/ proven to
be as secure as the underlying block cypher.
The output from the cypher in CTR mode is proved to be secure (for
secrecy) on the assumption that the block cypher is secure. However that
is *not* the same proposition as CTR mode being secure (for secrecy) -
since the problem with CTR mode does not involve predicting the encrypted
output in the first place.
--
__
|im |yler [EMAIL PROTECTED] Home page: http://alife.co.uk/tim/
--
From: [EMAIL PROTECTED] (David Wagner)
Subject: Re: IV
Date: Sat, 16 Jun 2001 06:24:03 + (UTC)
Are you talking about the fact that CTR mode doesn't conceal the length
of the plaintext? Few modes do. If you need to conceal the length of
the plaintext, then you're going to need to add additional machinery.
This is true whether you're using CTR more or CBC mode: CBC mode also
leaks substantial information about plaintext lengths, too.
--
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Is ECB truly more secure than CBC?
Reply-To: [EMAIL PROTECTED]
Date: Sat, 16 Jun 2001 06:19:19 GMT
David Wagner <[EMAIL PROTECTED]> wrote:
: Joseph Ashwood wrote:
:>I could easily argue that the simple fact that no key recovery attack exists
:>on ECB mode (outside of brute force) makes for a very powerful argument in
:>the situations where the key is more valuable than the information.
: How can the key be more valuable than the information it is used to
: protect, in a properly designed system? The only reason I can see to
: introduce a key is to protect some information, and so exposure of a
: key is only problematic because it can defeat that protection [...]
I think it can be possible for the key to have significant value - perhaps
greater than the message.
This would be in a system where previous messages of greater value had
been sent, and where the transmitter cannot be certain that exposure of
keys does not leak information about previous keys.
You might argue that such a system was not "properly designed".
However, if you want to be /certain/ that no leakage of information from
keys occurs, then it may be that no "properly designed" systems exist,
for lack of a perfect RNG.
If the key is of too great a value, you should not send the message - but
instead hide the key under your bed. However it appears that there may be
cases where sending the message may be justified, if it is felt that the
chance of a key-recovery attack is low.
--
__
|im |yler [EMAIL PROTECTED] Home pag
Cryptography-Digest Digest #623
Cryptography-Digest Digest #623, Volume #13 Sat, 3 Feb 01 19:13:01 EST
Contents:
CipherText: A ROCK to stand on... ("Prichard, Chuck")
Re: Re: (Tom St Denis)
Re: On combining permutations and substitutions in encryption (David Wagner)
Do you like playing with numbers? (i-reza)
Re: Do you like playing with numbers? (Richard Heathfield)
Re: CipherText fools some (Richard Heathfield)
Re: Do you like playing with numbers? (Tom St Denis)
Re: Encrypting Predictable Files (Richard Heathfield)
Re: (David Schwartz)
Re: (David Schwartz)
Re: Very short redundant serial number ("Ben")
Re: ideas of D.Chaum about digital cash and whether tax offices are("Thomas J.
Boschloo")
From: "Prichard, Chuck" <[EMAIL PROTECTED]>
Subject: CipherText: A ROCK to stand on...
Date: Sat, 03 Feb 2001 19:58:35 GMT
To present the CipherText algorithm to a forum of cryptologists, I would
first describe it in terminology similar to that used in the patent
application.
Then I would provide a mathematical description hopefully illustrating
the possibillities introduced by the algorithm.
///
Given this verbal description of the algorithm:
1.) A root key is taken as the root keystring. It can be of any
reasonable length. The longer the stronger.
2.) A key attribute is taken as a checksum-like value that has been
derived from a computation that involved all root key elements. I use a
common method that XOR's each value after having started with zero. Using
a restricted domain, my result never exceeds 32. The asymmetric feature
of the algorithm is affected by a degree of shift or offset that is later
applied as a consequence of having generated an attribute larger than 32
in magnitude. (SEE OFFSET)
3.) A modified key is created from the root key. The patent application
stipulates that this can be any conceived modification that is
repeatable. This includes appending or truncating the result. In my
demonstrations I simply reverse the root string, taking an element from
either end depending on the even/odd condition of the attribute. The
result of having a different length for the modified key is a highly
desirable "staggered pattern" of the applied cipher (not easily
discernible after masking.) No pattern is repeated in a 100 character
message when a 10 character key is used. (The modified key has a matrix
of possible arrangements. This is what makes reverse engineering the
algorithm difficult, many possibilities are introduced, but only one
properly arranged of values will be correct.)
4.) The attribute is scaled and used to articulate rotation of this
modified key.
5.) The cipher OFFSET is derived by scaling the attribute. 0..32 = 0
offset; 33..64=1 offset; 65..96 = 2 offset.
6.) The attribute is used to articulate a slight shift of the root key
before the first cipher.
7.) The XOR cipher is applied to the message string recursively rotating
through all the root key elements. As the cipher is applied, both
elements are converted by taking their ordinates and subtracting "31."
After the XOR operation "31" and the OFFSET are added to the result which
is appended to the ciphered string.
8.) The attribute is used to articulate a slight shift of the modified
key before the first cipher.
9.) The same XOR cipher is applied to the ciphered string recursively
rotating through all the modified key elements. The resulting ciphertext
string is output or it can be "whitened" to improve randomness.
This is the encryption method.
Decryption differs ONLY on the polarity of the applied offset and the
sequence of the applied keys. Of course when no cipher offset is applied
(a ZERO value), the two methods are identical and one realizes that it
makes no difference whether the modified key is applied first, or second
in the decryption process. With an OFFSET, the two methods differ,
effecting the asymmetric cipher mode. (Of course the whitener would be
applied first in the decryption process.)
I would mathematically introduce CipherText with the following
explanation:
^ as XOR
% as modulus
elements are byte values
(Assume zero offset,, symmetric mode to derive the simplest possible
mathematical
explanation)
To encode a message M with eight elements: M(0..7):
Taking a root key R with four elements: R(0..3)
Determining its attribute: A = {0 ^ R(0) + A^R(1) + A^R(2)+A^R(3)}
A is importantly affected by each root key value so that a somewhat
unique key-dependent quantity or checksum is derived.
The Modified rootkey is first reversed and then truncated on one end.
So that: R' = R(3..1) or R' = R(2..0)
Then a rotation is applied to R'.
R'_SHIFT = A % length (R) so that R' then becomes either :
R' = R(2,1,0)
R'=R(0,2,1)
R'=R(1,0,2)
R'= R(3,2,1)
R'=R(1,3,2)
R'=R(2,1,3)
Creating a matr
Cryptography-Digest Digest #623
Cryptography-Digest Digest #623, Volume #12 Wed, 6 Sep 00 16:13:01 EDT
Contents:
Re: Carnivore article in October CACM _Inside_Risks (Paul Rubin)
Re: RSA in public domain (Bill Unruh)
Re: RSA in public domain (Doug Stell)
Re: RSA Patent Dead Today (Bill Unruh)
Re: question on book selection ("Douglas A. Gwyn")
Re: Carnivore article in October CACM _Inside_Risks (Barry Margolin)
Re: Carnivore article in October CACM _Inside_Risks (Mok-Kong Shen)
Re: Carnivore article in October CACM _Inside_Risks ("Douglas A. Gwyn")
Multiplicative inverse problem... ([EMAIL PROTECTED])
Re: RSA in public domain (David A Molnar)
Re: Carnivore article in October CACM _Inside_Risks ("Trevor L. Jackson, III")
Re: RSA in public domain (Future Beacon)
Re: Carnivore article in October CACM _Inside_Risks ("Trevor L. Jackson, III")
Re: yet another primitive polynomial search program ("bubba")
Re: RSA in public domain ("Joseph Ashwood")
Re: RSA in public domain ("Douglas A. Gwyn")
Re: Carnivore article in October CACM _Inside_Risks (Mok-Kong Shen)
Re: For those working on the next RSA factoring challenge... (Matthew Skala)
Re: RSA in public domain (Future Beacon)
Re: Carnivore article in October CACM _Inside_Risks (Peter Van Epp)
Re: Carnivore article in October CACM _Inside_Risks (Roger Schlafly)
infosec career [OT?!] (rot26)
From: [EMAIL PROTECTED] (Paul Rubin)
Crossposted-To: comp.security.misc,alt.security,talk.politics.crypto
Subject: Re: Carnivore article in October CACM _Inside_Risks
Date: 6 Sep 2000 17:08:04 GMT
In article <[EMAIL PROTECTED]>, -m- <[EMAIL PROTECTED]> wrote:
>If a system is compromised the data departing that system MUST be
>suspect. If there is a single soul here who can tell me how I can
>authenticate the identity of a server which has been compromised I
>will be surprised. You see a compromised OS holds NO secrets and can
>be manipulated in strange and mysterious ways by processes invisible
>to the admin. The very fact that the FBI chose an OS which is not
>certified as B2 trusted indicates the engineers who built the damn
>thing dropped the ball.
Put a hardware authentication token in the box?
--
From: [EMAIL PROTECTED] (Bill Unruh)
Subject: Re: RSA in public domain
Date: 6 Sep 2000 17:19:53 GMT
In "Dave Foulger"
<[EMAIL PROTECTED]> writes:
]BEDFORD, Mass., September 6, 2000 -- RSA Security Inc. (NASDAQ: RSAS) today
]announced it has released the RSA public key encryption algorithm into the
]public domain, allowing anyone to create products that incorporate their own
]implementation of the algorithm. This means that RSA Security has waived its
]rights to enforce the patent for any development activities that include the
]RSA algorithm occurring after September 6, 2000.
?? They do not own the patent. They cannot release it unless MIT agrees.
It is MIT that owns the patent, unless things have changed recently. I
suspect that MIT would agree, but doe it actually state that MIT has
released it? Or are they simply placing RSAREF into the public domain.
]Represented by the equation "c = me mod n," the RSA algorithm is widely
]considered the standard for encryption and the core technology that secures
]the vast majority of the e-business conducted on the Internet. The U.S.
]patent for the RSA algorithm (# 4,405,829, "Cryptographic Communications
]System And Method") was issued to the Massachusetts Institute of Technology
](MIT) on September 20, 1983, licensed exclusively to RSA Security and
]expires on September 20, 2000.
As they state here. While they may be the exclusive licensor, they still
do not own the patent and cannot unilaterally abrogate someone else's
rights.
--
From: [EMAIL PROTECTED] (Doug Stell)
Subject: Re: RSA in public domain
Date: Wed, 06 Sep 2000 17:02:53 GMT
On Wed, 6 Sep 2000 12:19:44 -0400, Future Beacon <[EMAIL PROTECTED]>
wrote:
>No need to apologize. If humor is too cryptic, it is hard to know
>whether it is intended.
Jean-Jacques' point of humor is simply that these guys didn't invent
public key cryptography. They just got the patent and the $$$.
A person who knows told me that the Brits were given the opportunity
to review the patent applications and challenge them. However, it was
decided that it was in the better interest of national security to be
silent. A challenge would have revealed that the technology is known
and trusted, whereas, it takes about a decade for a new technology to
become trusted in the commercial sector. Silence, on the other hand,
gave the governments a significant head start.
--
From: [EMAIL PROTECTED] (Bill Unruh)
Subject: Re: RSA Patent Dead Today
D
Cryptography-Digest Digest #623
Cryptography-Digest Digest #623, Volume #11 Tue, 25 Apr 00 11:13:01 EDT Contents: Cryptography FAQ (10/10: References) ([EMAIL PROTECTED]) Re: new Echelon article (Diet NSA) Re: Problems with NTRU (Mike Rosing) Re: help w/ math and using crypto (Mike Rosing) Re: factor large composite (Paul Schlyter) Re: factor large composite (Paul Schlyter) Re: sci.crypt think will be AES? (Tom St Denis) Crossposted-To: talk.politics.crypto,sci.answers,news.answers,talk.answers Subject: Cryptography FAQ (10/10: References) From: [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] Date: 24 Apr 2000 16:59:16 GMT Archive-name: cryptography-faq/part10 Last-modified: 94/06/13 This is the tenth of ten parts of the sci.crypt FAQ. The parts are mostly independent, but you should read the first part before the rest. We don't have the time to send out missing parts by mail, so don't ask. Notes such as ``[KAH67]'' refer to the reference list in this part. The sections of this FAQ are available via anonymous FTP to rtfm.mit.edu as /pub/usenet/news.answers/cryptography-faq/part[xx]. The Cryptography FAQ is posted to the newsgroups sci.crypt, talk.politics.crypto, sci.answers, and news.answers every 21 days. Contents 10.1. Books on history and classical methods 10.2. Books on modern methods 10.3. Survey articles 10.4. Reference articles 10.5. Journals, conference proceedings 10.6. Other 10.7. How may one obtain copies of FIPS and ANSI standards cited herein? 10.8. Electronic sources 10.9. RFCs (available from [FTPRF]) 10.10. Related newsgroups 10.1. Books on history and classical methods [FRIE1] Lambros D. Callimahos, William F. Friedman, Military Cryptanalytics. Aegean Park Press, ?. [DEA85] Cipher A. Deavours & Louis Kruh, Machine Cryptography and Modern Cryptanalysis. Artech House, 610 Washington St., Dedham, MA 02026, 1985. [FRIE2] William F. Friedman, Solving German Codes in World War I. Aegean Park Press, ?. [GAI44] H. Gaines, Cryptanalysis, a study of ciphers and their solution. Dover Publications, 1944. [HIN00] F.H.Hinsley, et al., British Intelligence in the Second World War. Cambridge University Press. (vol's 1, 2, 3a, 3b & 4, so far). XXX Years and authors, fix XXX [HOD83] Andrew Hodges, Alan Turing: The Enigma. Burnett Books Ltd., 1983 [KAH91] David Kahn, Seizing the Enigma. Houghton Mifflin, 1991. [KAH67] D. Kahn, The Codebreakers. Macmillan Publishing, 1967. [history] [The abridged paperback edition left out most technical details; the original hardcover edition is recommended.] [KOZ84] W. Kozaczuk, Enigma. University Publications of America, 1984 [KUL76] S. Kullback, Statistical Methods in Cryptanalysis. Aegean Park Press, 1976. [SIN66] A. Sinkov, Elementary Cryptanalysis. Math. Assoc. Am. 1966. [WEL82] Gordon Welchman, The Hut Six Story. McGraw-Hill, 1982. [YARDL] Herbert O. Yardley, The American Black Chamber. Aegean Park Press, ?. 10.2. Books on modern methods [BEK82] H. Beker, F. Piper, Cipher Systems. Wiley, 1982. [BRA88] G. Brassard, Modern Cryptology: a tutorial. Spinger-Verlag, 1988. [DEN82] D. Denning, Cryptography and Data Security. Addison-Wesley Publishing Company, 1982. [KOB89] N. Koblitz, A course in number theory and cryptography. Springer-Verlag, 1987. [KON81] A. Konheim, Cryptography: a primer. Wiley, 1981. [MEY82] C. Meyer and S. Matyas, Cryptography: A new dimension in computer security. Wiley, 1982. [PAT87] Wayne Patterson, Mathematical Cryptology for Computer Scientists and Mathematicians. Rowman & Littlefield, 1987. [PFL89] C. Pfleeger, Security in Computing. Prentice-Hall, 1989. [PRI84] W. Price, D. Davies, Security for computer networks. Wiley, 1984. [RUE86] R. Rueppel, Design and Analysis of Stream Ciphers. Springer-Verlag, 1986. [SAL90] A. Saloma, Public-key cryptography. Springer-Verlag, 1990. [SCH94] B. Schneier, Applied Cryptography. John Wiley & Sons, 1994. [errata avbl from [EMAIL PROTECTED]] [WEL88] D. Welsh, Codes and Cryptography. Claredon Press, 1988. 10.3. Survey articles [ANG83] D. Angluin, D. Lichtenstein, Provable Security in Crypto- systems: a survey. Yale University, Department of Computer Science, #288, 1983. [BET90] T. Beth, Algorithm engineering for public key algorithms. IEEE Selected Areas of Communication, 1(4), 458--466, 1990. [DAV83] M. Davio, J. Goethals, Elements of cryptology. in Secure Digital Communications, G. Longo ed., 1--57, 1983. [DIF79] W. Diffie, M. Hellman, Privacy and Authentication: An introduction to cryptography. IEEE proceedings, 67(3), 397--427, 1979. [DIF88] W. Diffie, The f
Cryptography-Digest Digest #623
Cryptography-Digest Digest #623, Volume #10 Wed, 24 Nov 99 15:13:01 EST
Contents:
For snake oil collectors :-) (Cedomir Igaly)
Re: Signals From Intelligent Space Aliens? Forget About It. (Bill McGonigle)
Re: What part of 'You need the key to know' don't you people get? (Tom St Denis)
Re: bits of diffiehellman private key (Tom St Denis)
Re: Applet containing symmetric key to send to client ("Gary")
Re: New U.S. Crypto Regulations (advance copy: do not distribute) (Medical
Electronics Lab)
Re: Random Noise Encryption Buffs (Look Here) (Medical Electronics Lab)
Re: Applet containing symmetric key to send to client (Medical Electronics Lab)
Re: Prime Numbers Question (Johnny Bravo)
Re: Prime Numbers Question (Johnny Bravo)
Re: US stupidity ([radiant matrix])
Re: Free weekly science cartoon by email ("Kasper Pedersen")
Re: What part of 'You need the key to know' don't you people get? (Tim Tyler)
Re: bits of diffiehellman private key ("Michael Scott")
Re: AES cyphers leak information like sieves (Tim Tyler)
Re: AES cyphers leak information like sieves (Tim Tyler)
Re: Applet containing symmetric key to send to client (Tim Tyler)
Re: US stupidity (Tim Tyler)
From: Cedomir Igaly <[EMAIL PROTECTED]>
Subject: For snake oil collectors :-)
Date: Wed, 24 Nov 1999 17:28:46 +
> Return-path: <[EMAIL PROTECTED]>
> To: 'Cedomir Igaly' <[EMAIL PROTECTED]>
> Subject: RE: Question about Tesco Online Banking
> Date: Wed, 24 Nov 1999 16:01:57 -
>
> Dear Mr Iqaly,
>
> Thank you for your reply to my e-mail.
>
> I have checked this with our technical support and the reason we keep the
> security details that we display to a minimum is due to the sensitive nature
> of this topic.
>
> You are correct in stating that many off-the-shelf 3-DES packages do result
> in a lower bit encryption.
>
> Our security protocols were written in-house and we can assure you that they
> do give 168-bit encryption.
>
> We hope this helps answer your question.
>
> Regards
> Hazel Dickson
> Tesco Personal Finance
>
> > -Original Message-
> > From: Cedomir Igaly [SMTP:[EMAIL PROTECTED]]
> > Sent: 23 November 1999 18:40
> > To: ~ TOLB Support
> > Cc: [EMAIL PROTECTED]
> > Subject: Re: Question about Tesco Online Banking
> >
> >
> > *** Warning : this message originates from the Internet
> >
> > Hi there!
> >
> > > Thank you for your e-mail to Tesco Online Banking.
> > >
> > > The Tesco Online Banking service runs on 168 triple Des inscription the
> > > highest used by any UK Bank.
> > >
> > > If you have any further enquiries please feel free to contact us again.
> >
> > Thank your for your reply. Just for your information, because of so-called
> > "meet-in-the-middle" attacks, strength of 3-DES is not 168 bits but 112
> > bits (if properly implemented and much less if not) which is assumed to
> > be quite enough but still less than 128 bits used by some other banks in
> > UK. Since I do understand that you are not expert in area of computer
> > security and cryptograhy, I will be thankful if you can point me to some
> > document on your WWW site where I can get little bit more relevant
> > information. I hope that there is such information and that I was only
> > unable to locate it. Unfortunately, I've seen so many "snake oil" in
> > area of computer secrutiy that I have to be very careful before using any
> > new service.
> >
> > Best regards,
> > Cedomir Igaly
> The Royal Bank of Scotland plc is registered in Scotland No 90312. Registered Of
> fice: 36 St Andrew Square, Edinburgh EH2 2YB.
>
> The Royal Bank of Scotland plc is regulated by IMRO, SFA and Personal Investment
> Authority.
>
> This e-mail message is confidential and for use by the addressee only. If the m
> essage is received by anyone other than the addressee, please return the message
> to the sender by replying to it and then delete the message from your computer.
>
> 'Internet e-mails are not necessarily secure. The Royal Bank of Scotland plc doe
> s not accept responsibility for changes made to this message after it was sent.'
>
--
From: [EMAIL PROTECTED] (Bill McGonigle)
Crossposted-To: talk.politics.crypto
Subject: Re: Signals From Intelligent Space Aliens? Forget About It.
Date: Wed, 24 Nov 1999 12:06:30 -0500
Anthony Stephen Szopa <[EMAIL PROTECTED]> wrote:
> Any space alien signals will not be recognized by us because of space
> alien
Cryptography-Digest Digest #623
Cryptography-Digest Digest #623, Volume #9 Sun, 30 May 99 19:13:03 EDT
Contents:
Re: Review of Scottu19 (on-topic) (SCOTT19U.ZIP_GUY)
Win95 - Screen saver password ([EMAIL PROTECTED])
Re: Using symmetric encryption for hashing (Bill Unruh)
Re: OTP Problems (Jim Dunnett)
Re: HushMail -- Free Secure Email (Tim Smith)
Re: Scramdisk cracked (Jim Dunnett)
Re: HushMail -- Free Secure Email (fungus)
Re: Win95 - Screen saver password (JPeschel)
Re: OTP Problems (wtshaw)
Re: i have an encrypted password file that i want to decrypt, can anyone tell me any
ways of going about it? (Jim Dunnett)
Re: Using symmetric encryption for hashing (wtshaw)
Re: OTP Problems (Matthias Bruestle)
Re: SHA-1 output random? ("Roger Schlafly")
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Review of Scottu19 (on-topic)
Date: Sun, 30 May 1999 20:05:46 GMT
In article <7irh4k$qfc$[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote:
>Well I first posted what I read about it. No questions have been
>answered. Hmm. Well here are some additional questions
>
>1. Is there a way to pack the data differently to increase speed?
Well if you use scott16u all the fields line up on byte boudaries.
>2. Is there a way to reduce the s-tables to under 8kb?
yes all you needd to do to calculate storage is that N be
the number of bits then they S table is N*(2**N) bits in size
I have listed the size before for various N bits but don't wish
to recalulate them
>3. Is there a way to break scottu19, say if something were to be
>changed slightly.
Well if you drop the rotations and the Paul routine and used just
XOR's you could use Paul Onions attack using a choosen plain text
file.
>4. What is tbe benefit of 19-bit words?
THe benefit of 19 words is that no one likes to use 19 bit words.
and and 19 bit key that represens any possible S table fits on a 1.44 meg
floppy while one that is 20 by 20 doesn't.
>
>My previous questions
>
>1. What is the actual mixing. A complete description please. Maybe a
>diagram if it's hard to explain.
I can not explain this better than what Horace wrote give it up. I have
wrritten the description 20 times and am no writting it again.
However I am writting a subroutine in C for those who want to do it with
IDEA or what ever.
>2. What is the effective key size (not the actual key size)?
I have the number somewher but noy with be but is is over 1 million bytes
and if you look in deja news you can find the disscuusion on this. I see
no reason to recalulate this since most people assume any thing over 1000
is unthinkable.
>3. What is the clear advantage of scottu19 over something like
>Blowfish (RC5, IDEA, XTEA or CAST for that matter).
The clear adavantage is many. It is more secure. It is not subject to partial
plain text attacks. Since every bit in the input file affects the total output
file. It use all or nothing encryption. For long files if one wants to
preserve the length of file it can do that while with the others one can not
to this as easily one most use specail chainning modes that weaken them.
you can see my contest which is something that can not be done with the
others in offical chainning modes since the modes are designed so that the
.. need only look at a few blocks of a long file to break it. Yes the blessed
AES methods with the blessed chainning modes are all designed to have
the information about breaking them in every few blocks. This is not the
case with scott19u and like I have said before this is not that hard to test.
>
>Please try to answer the questions including as much detail as
>possible. Avoid vague statements like 'its in the code' or 'I have
>tested it myself' I would like to actually see something (Cause I am
>into reading other cipher designs). So far none of those questions
>have clearly been answered.
>
>Scott: I know this must be annoying but please try to be patient and
>answer the questions clearly. You always make reference to your code
>or change the topic. (I don't care about the NSA or china).
>
Tom if your to lazy to do the test I told you about I see no reason to go
farther I have been down this road before.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
http://members.xoom.com/ecil/index.htm
NOTE EMAIL address is for SPAMERS
--
From: [EMAIL PROTECTED]
Subject: Win95 - Screen saver password
Date: 30 May 1999 19:06:23 GMT
Hi,
does someone of you know what algo is used to enc. the win95 password in
HKEY_CURRENT_USER\Control Panel\Desktop\ScreenSave_Data?
CIAOii & so on...
Thomas Scholz
--
RUM - Computing
