Cryptography-Digest Digest #283, Volume #11 Thu, 9 Mar 00 00:13:01 EST
Contents:
Re: Pseudo-One Time pad here. Critiques? ("Steve A. Wagner Jr.")
Re: Pseudo-One Time pad here. Critiques? (Albert Yang)
Actually, I have a sign "Be Aware of Dog" on the garage door of the ("Markku J.
Saarelainen")
Concerning UK publishes "impossible" decryption law (Ian L. Romkey)
Re: Pseudo-One Time pad here. Critiques? (Bill Unruh)
Re: sci.crypt Cipher Contest ("Steve A. Wagner Jr.")
Re: Universal Language ([EMAIL PROTECTED])
Re: Passphrase Quality ? (Johnny Bravo)
Re: Actually, I have a sign "Be Aware of Dog" on the garage door of the (J)
Re: Your Recommended Choice On Std Crypto Parts (Benjamin Gittins)
Re: Your Recommended Choice On Std Crypto Parts (Benjamin Gittins)
Number 26 of a series (wtshaw)
Re: Differential Cryptanaylsis, Fiestel and PRNG ("Tom St Denis")
Re: sci.crypt Cipher Contest ("Adam Durana")
Big Float project (Mike Rosing)
----------------------------------------------------------------------------
From: "Steve A. Wagner Jr." <[EMAIL PROTECTED]>
Subject: Re: Pseudo-One Time pad here. Critiques?
Date: Wed, 08 Mar 2000 21:28:30 -0800
Be sure that you XOR the hash of the previous block's [_ciphertext_+key] with the
current block of plaintext. Sorry about that!
"Steve A. Wagner Jr." wrote:
> You can increase the security of this. OFB is not good for re-use with the
> same password unless you are using a secure random session key. I suggest
> using a CFB approach, where you begin with a 16byte RIV.
>
> XOR hash of [previous block+key] with the current block. You can make this act
> as a stream-cipher (CFB) by XOR'ing a byte at a time, cycling 1..16. It should
> be pretty secure, and this is not a new invention. It's certainly more secure
> than DES. Also, consider using a 20byte hash algorithm such as RIPEM160 or
> SHA-1.
>
>
------------------------------
From: Albert Yang <[EMAIL PROTECTED]>
Subject: Re: Pseudo-One Time pad here. Critiques?
Date: Thu, 09 Mar 2000 01:14:51 GMT
You are right, it does yield a 128 bit hash, but in php, it's coughed up
as 32 nibbles (presented in chars of 0-9,A-F) instead of 16 bytes.
I am not sure how all that adds to the strength of the algorithm
though... hmmm, that is a good suggestion though, I can key it so that
not just the derived hash is used for the next hash, but a concatination
of the original key and the resultant hash as the new hash. This will
guarantee that the key truely effects all parts of the algorithm, and
that you can do a block step-back XOR to attack it.
I wanted to try some sort of whitening in the beginning and in the end,
but I didn't see any difference between whitening and just adding
additional rounds to it.
I made the change so that hash_key = hask_key + key, that way, I can
guarantee that 1) The key effects every bit, and 2) You have to know
the original key in order to break it.
I'm actually shocked, this algorithm is relatively strong for something
that is 7-9 lines...
Thanks for the recommendations.
Albert
------------------------------
From: "Markku J. Saarelainen" <[EMAIL PROTECTED]>
Crossposted-To:
alt.politics.org.cia,soc.culture.russian,soc.culture.nordic,soc.culture.israel,soc.culture.europe
Subject: Actually, I have a sign "Be Aware of Dog" on the garage door of the
Date: Thu, 09 Mar 2000 01:17:57 GMT
Actually, I have a sign "Be Aware of Dog" on the garage door of the
house, where I am living until I take the world's longest love train
ride to Vladivostok, Russia.. The sign itself is a lie .. I have no dog
. actually it is just the deception .. you see often the security is
based on deception.
Yours,
Markku
------------------------------
From: [EMAIL PROTECTED] (Ian L. Romkey)
Crossposted-To:
alt.security.pgp,comp.security.pgp.discuss,alt.security.scramdisk,alt.privacy
Subject: Concerning UK publishes "impossible" decryption law
Date: Thu, 09 Mar 2000 01:32:33 GMT
Warning: Reluctantly crossposted to five groups. Use your own judgement.
I just read an article about new encryption legislation in the UK in Lauren
Weinstein's Privacy Forum newsletter. The article begins:
>Today Britain became the only country in the world to publish a law which
>could imprison users of encryption technology for forgetting or losing
>their keys.
See the newsletter here: <http://www.vortex.com/privacy/priv.09.10>
Background info is available here: <http://www.cyber-rights.org/crypto/>
I found this part particularly interesting:
>The Home Office have made limited changes that amount to window-dressing,
>but the essential human rights issue remains:
>
>(Clause 46): authorities must have "reasonable grounds to believe" the key
>is in possession of a person (previously it had to "appear" to authorities
>that person had a key). This replaces an subjective test with one requiring
>objective evidence, but leaves unaffected the presumption of guilt if
>reasonable grounds exist.
>
>(Clause 49): to prove non-compliance with notice to decrypt, the prosecution
>must prove person "has or has had" possession of the key. This satisfies the
>objection to the case where a person may never have had possession of the
>key ("encrypted e-mail out of the blue"), but leaves unchanged the essential
>reverse-burden-of-proof for someone who has forgotten or irreplaceably lost
>a key. It is logically impossible for the defence to show this reliably.
Logically impossible? Maybe not. I don't live in the UK myself, but for
British subjects, it might turn out that my password grid strategy
<http://www.5x5poker.com/grid/> could provide an effective escape from this
rather invasive and unfair law. Remember that an important feature of the
strategy is that in the event the password grid in use is destroyed, other
unused grids should be retained in order to demonstrate how the grids work.
Perhaps the ability to provide this demonstration could remove the
"reasonable grounds" mentioned above in Clause 46.
On the other hand, maybe it's a bad idea. What do you think?
--
"Ian L. Romkey" is actually 6078 219354 <[EMAIL PROTECTED]>.
012 3 456789 <- Use this key to decode my email address and name.
Play Five by Five Poker at http://www.5X5poker.com.
------------------------------
From: [EMAIL PROTECTED] (Bill Unruh)
Subject: Re: Pseudo-One Time pad here. Critiques?
Date: 9 Mar 2000 01:38:35 GMT
In <[EMAIL PROTECTED]> Albert Yang <[EMAIL PROTECTED]> writes:
>I'm actually shocked, this algorithm is relatively strong for something
>that is 7-9 lines...
Well, MD5 is more than 7 lines long. After all I can build a one line
crypto routine
out= Blowfish(key, in)
which is relatively strong. Given the right primatives all programs are
trivial.
But yes, this is an illustration of how stupid the US rules were--
allowing free export of cryptographic hash functions but not crypto
software since the one can be converted to the other trivially.
------------------------------
From: "Steve A. Wagner Jr." <[EMAIL PROTECTED]>
Subject: Re: sci.crypt Cipher Contest
Date: Wed, 08 Mar 2000 22:04:08 -0800
As fun as it sounds I fail to see the point. If this is an entry-level fun
algorithm design and cracking contest for ameatures, then why have the
categories for 64bit, 128bit etc keylengths and blocksizes. Why worry about
whether a key can be brute-forced? And what do block and keysize have to do
with experience? (Beginner, Intermediate, Experienced).
Why not specify a 32bit block and 32bit key and judge by clever design and
mathematics rather than whether large governments can break it.
Otherwise it's insane. Lots of people could throw together a semi-secure
algorithm if they want to take 20 minutes to encrypt a file or use 40 megs of
memory, but the algorithms you'll notice in publications fill many design
requirements yet still meet their purpose. Theres more to cryptography than
achieving secure ciphertext.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Universal Language
Date: Thu, 09 Mar 2000 01:35:41 GMT
In article <[EMAIL PROTECTED]>,
"Lassi Hippel�inen" <"lahippel$does-not-eat-canned-food"@ieee.org>
wrote:
> P.S. That still isn't a Universal language. Not even global. Due to
its
> vocabulary, Esperanto is easier for indoeuropeans that for any other
> people.
>
Not sure this is as clear, or useful, a statement as it would at first
appear. In my experience, fro example, I've found that some
Esperanto-learners from non-IE backgrounds (e.g. Finns, Hungarians,
Japnese, and Koreans) speak _better_ Esperanto than some French, German,
and English-sepakeing students I've met, because they understand from
the outset that Esperanto is an autonomous language and not simply a
kind of "code" for their birth-tongue. Some Romance-speakers import
polysyllabic Greco-Latin words from teh "common Science vocabulary",
simply making them conform to the sound-system of Esperanto, instead of
using the "native" Esperanto-forms, whcih more-or-less require one to
learn the agglutinative word-building strategies of Esperanto. In any
case, the motivation and native language-learning abilities of
individuals vary so much within speech communities, and the
relative importance of phonological difficulties, writing-system
difficulties, vocabulary difficulties, etc for the individual learner
vary so much, that I'm not sure your blanket statement is all that
useful. For example, Farsi is an Indo-European language, Suomi is not.
Yet I'd guess that you might be able to learn Esperanto more easily than
an Iranian peasant, because you already have a general European cultural
background, the sound system of Finnish isn't all that different from
that of Esperanto (a few more vowels), you're used to the idea of an
almost perfectly phonetic alphabet based on the Roman one, you come from
a country with perhaps the highest per capita access to the Internet,
etc.
I'm also not sure that vocabulary (i.e. the lexical base) of Esperanto
is the biggest stumbling block for, say, a Mandarin-speaker when trying
to learn Esperanto. Grammatical concepts such as obligatory tenses and
number might bother her more... (there's some anecdotal evidence for
this).
BTW, has anyone mentioned Lojban yet?
<http://xiron.pc.helsinki.fi/lojban/>
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Johnny Bravo <[EMAIL PROTECTED]>
Crossposted-To: alt.security.pgp,comp.security.pgp.discuss
Subject: Re: Passphrase Quality ?
Date: Wed, 08 Mar 2000 21:14:59 -0500
On Wed, 08 Mar 2000 23:29:20 GMT, [EMAIL PROTECTED] (Ian L.
Romkey) wrote:
>Seriously, all my system <http://www.5x5poker.com/grid/> does is give you
>the option of destroying your password so that not even you can ever
>recover it. In most real-world cases, there's no actual risk of torture
If someone is going to torture you for the password, they will torture
you anyway. They certainly have nothing to lose in trying, since your
chances of lying to them about the password to avoid torture approach
100%. When you are dead they can be reasonably sure you didn't know the
passphrase.
--
Best Wishes,
Johnny Bravo
"The most merciful thing in the world, I think, is the inability
of the human mind to correlate all it's contents." - HPL
------------------------------
From: J <[EMAIL PROTECTED]>
Crossposted-To:
alt.politics.org.cia,soc.culture.russian,soc.culture.nordic,soc.culture.israel,soc.culture.europe
Subject: Re: Actually, I have a sign "Be Aware of Dog" on the garage door of the
Date: Wed, 08 Mar 2000 21:17:52 -0600
"Markku J. Saarelainen" wrote:
> Actually, I have a sign "Be Aware of Dog" on the garage door of the
> house, where I am living until I take the world's longest love train
> ride to Vladivostok, Russia.. The sign itself is a lie .. I have no dog
> . actually it is just the deception .. you see often the security is
> based on deception.
>
> Yours,
>
> Markku
[EMAIL PROTECTED]
------------------------------
From: Benjamin Gittins <[EMAIL PROTECTED]>
Subject: Re: Your Recommended Choice On Std Crypto Parts
Date: Thu, 09 Mar 2000 03:31:10 GMT
In article <[EMAIL PROTECTED]>,
Mike Rosing <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] wrote:
> > If I want speed and good security for encrypting
> > a data stream, and I only want one choice of.... [bla bla bla]
>
> Check out http://www.terracom.net/~eresrch
> That's *my* choice, based on doing a lot of reading.
Am looking at your site, thanx.
I have not done very much reading on ECC, From what I gather they are
used in Public Key situations, but can you also use them for symetric
encryption? If so, how does it compare against something like two-fish,
setup speeds, etc. Setup speeds REALLY are critical in this application
unfortunatly.
I saw reference to your book.. Unfortunatly my visa card is somewhat in
a state of disrepair ;-)
What would you use in ECC land?
> > Is there an existing minimilistic style protocol
> > that meets the above requirements, otherwise My
> > initial preferences are listed, but seeking
> > consensus, alternatives.
> >
> > - Public Key? : D & H
>
> Lots more choices than that, but it'll do.
>
I have been reading up, since posting my first message, crypto papers
found on Mihir Bellare's website.
http://www-cse.ucsd.edu/users/mihir/
In particular one such document, Entity Key Authentication and Key
Exchange, talks about the need for mathematically proven protocols.
I am continuing to read it, and several other papers talking about
similar design constraints, but is there any public implementations
available of a key exchange protocol that that meets this strict
criteria?
The security model ( I think ) I should minimally meet are the ones
defined in 1.3 of said document.
I am also reading another document, Key Agreement Protocols, and their
Security Analasis, by Simon Blake-Wilson, Don Johnson, Alfred Menezes,
Sep 9,1997, that also talks about this need.
Their attack model for mallory seems to be a little bit more powerfull,
and I have yet to fully read/comprehend the need for such a yet more
powerfull adversary in design. ( other than maybe, future proof
security? need to read it a bit more ;-)
Again, if there is a standard exchange method written that complies to
this model, i won't say no to it ;-)
>
> > - Symetric? : TwoFish 128 bit key
>
> Can't go wrong with that.
> > - Key setup times is important % as may be
> > small sessions.
> > - Must be FPGA friendly
>
> Bang, hit the nail on the head with this one :-)
>
Thanx : Vote Of Confidence on Algo.Tally++
>
> > - Cryptographic Hash? : SHA-1???
> > - Is SHA1 $ free in all situations?
>
> Yup.
>
> > - Is there an acceptible hybrid (aware of SSH
> > crc-32 fiasco)
> > - Given data is not high sensitive, is a weaker
> > faster crypt hash acceptible.
>
> Your call. What's the threat model? How good are
> your "enemies"?
>
The Enemies, <Grin>, I want to be trully pessimistic about them.
Very powerfull, as per above mentioned models.
My thinking just now is as follows
1 - Use SHA-1 On all initial handshaking and the first N packets after.
- Logic being that this is the most 'fragile' point of
communications, where the need to establish a session secret needs to
be protected carefully, using full 160 bit hashs.
2 - Possibly Use md4/md5 using HMAC, after the n packets, as HMAC seems
to improve security of a hash function by sharing a secret or
something. I am also still reading up on that formal document for HMac.
I am aware the underlying hash must have some minimal level of
expectation for clash detection, but as said, still reading. Again, MD4
is fast (and not fully broken yet???), and data will not be vulnerable
to the style of attack conducted on the SSH???
Speed really is critical, and data is not ultra-sensitive.
Again, peoples thoughts?
> > - Is writting 'n' of the first bits of the key
> > in the encrypted stream an acceptable soloution
> > to reduce data expansion, or is this an
> > instrinsically bad practice [ as optionally
> > available in ssh ].
>
> "Bad Practice" (TM)
I was reading the HMAC paper ( not rfc ) and it talks about there
possibly being an upside to reducing the amount of bits ( by a little )
in the hash value to thwart attemtps at reverse engineering. It metions
of course, that it reduces the amount of combinations for a birthday
attack..
Any recent developments on this, beyond increasing a small chance on
birthday attacks? Papers, Documents, ??? Please indicate if you have
read the paper / his reference to other paper.
>
> > - PRNG : Yarrow-160 for wintel : and on unix?
> > - Any Ports in the pipe line ?? ;-)
>
> I got a hardware RNG for ya :-)
>
I saw it! It would be interesting to have a less alpha kit, like, a pci
board with logic on the pcb, with a cable that runs down to a plastic
cube with the magic radiation box wrapped up in foil, etc. Protecting
it from true random acts of malicous pet cats ;-)
Are there cheap 'acceptable' RNG ready to plug into a std pc / mac?
> > - Your Gut Feelings and Any other
> > recommendations.
>
> Sounds like you're already on the right track. Each of
> the compenents is straight forward. Putting the whole
> thing together and still staying somewhat secure is harder.
> You really ought to have a good threat model. Who's
> going to try to break in and what do they gain? Can you
> raise the price of attack to just over the gain, or can
> you make it 10 times? In the latter case, only a nut
> case will break the security, but what do you lose when
> they do?
>
In short, I don't want to have intrinsincly weak design, like what
happenened with SSH v1.x, nor do I want to use 'bad choice'
components.. Definitly the Key Exchange protocol should be bullet-proof.
But again, i'm not so concerened about data eventually being recovered
in 10 years, as it isn't govt secrets, so faster crypto components, as
opposed to a paranoid 9 pass DES implementation or what have you. ;-)
There will only be one level of security. Version revision if serious
flaw becomes apparent, n years down track, in the way the components
are used ;-)
> If you have an idea of what the threat model is, your already
> basic common sense will work quite well :-)
>
> Patience, persistence, truth,
> Dr. mike
Thanx for your constructive feed back.
More is truly welcome ;-)
Ben.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Benjamin Gittins <[EMAIL PROTECTED]>
Subject: Re: Your Recommended Choice On Std Crypto Parts
Date: Thu, 09 Mar 2000 04:02:16 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Doug Stell) wrote:
> On Tue, 07 Mar 2000 19:06:45 GMT, [EMAIL PROTECTED] wrote:
> >If I want speed and good security for encrypting
> >a data stream, and I only want one choice of
> >crypt algorithim for each part, with no patent $
> >issues, what should i choose, more importantly
> >what would You use.
>
> The cost comes in two parts; patent cost for the algorithm and cost of
> using someone's implementation. The algorithm patent cost depends in
> part on where you are and where you intend to use the algorithm.
>
Must have no patent pending issues regardless of geography.
No $ issues regarding the use of the algorithim.
And i am happy to massage somebody elses code parts.
> >I do not want to support N different algorithims,
> >or key length choices, etc..
> >The data is not ultra-sensitive, ie., not e-
> >commerce, or long-term secrets.
>
> Being able to gracefully transition between algorithms in the future
> is a good feature to consider in the protocol. By graceful I mean the
> ability to transition without having to render clients unable to
> communicate until all communicating clients are replaced.
>
My concern, is adding to complexity of the user understanding, and
implementation analasys for future security.
If its analysable, there should be a greater percentage of getting it
right first time, and not having to worry about minor protocol changes.
I agree, if a crypto part becomes broken, this is a problem. Ultimatly,
A Really Bad crypto part is good as no part, so people should either be
provided with a simple path to a newer version protocol, or if total
break, best move people quickly.
My intent was to use the version number to provide this feature..
[connect] [ version n ] ->
<- [ack]
-> [talk protocol / aglos of version n ] bla bla bla
rather than
[connect] [ version n, crypto parts a1, b1, c1 ]
<- [fail, crypto a1, b2, c1 ]
Too may permutations..
Is Hash X, safe when used in MAC method Y, with a Z public key
negotiation method.
It raises the question of Can the user be trusted to pick safe
combinations??
eg.,
My friends gut responses were to disable the 3DES implementation on PGP
because they heard DES was weak. Yet 3DES is highly trusted in crypto
circles? ;-)
This sort of demonstrates the need to take away options from users who
don't know any better ;-)
---
Its a phylisophical decision, maybe It would be better to provide 2
standard PRE-SET combinations, allowing for atleast a 2 step fail safe
protocol to be determined by server???
ie.,
MD4 - HMAC - TwoFish - D&H : speed happy default
SHA1 - HMAC - 3DES - D&H : safe fallback protocol
again, the undeducated user must not have to think about it.
>
> > - Public Key? : D & H
>
> For anonymous key agreement, D-H is fine.
> For authenticated key agreement, KEA (a dual D-H) is a good choice.
> Ouside the USA, RSA is available royalty free.
> Other choices involve ElGamal, DSA and hybrids, depending on what you
> want to do.
> Remember that many of these algorithms require that you have a
> authenticatable public key to avoid impersonation attacks.
>
My Specs requires User verified public key is used to avoid spoof
atacks, as I don't want a public certificate provider.
I want an algorithim that exchanges a secret, where the public key has
been trusted by the user. But I want one where it has been created
around a formal mathematical proof. No ad-hoc key exchanging.
Refer to my other just posted msg to Dr Mike for further details on
thoughts regarding key exchange.
Which of the above meet the criteria?
> > - Cryptographic Hash? : SHA-1???
> > - Is SHA1 $ free in all situations?
>
> I believe so.
good
>
> > - Given data is not high sensitive, is a weaker
> >faster crypt hash acceptible.
>
> MD4 is about the fastest hash you can get that isn't totally bad. MD4
> has been shown to have weaknesses and both MD5 and SHA are
> improvements on MD4. SHA-1 is a better improvement than MD5, it turns
> out. MD4 isn't use much any more, but it does offer a choice of high
> speed versus lower security, if that is the tradeoff you wish to make.
>
Thanx..
Does anybody know if MD4 is safe to use under the HMAC protocol??
More importantly, Would knowlegable critics say this system is not
secure enough because they chose to use MD4 in this way.
What problems can I expect if MD4 gets any weaker ???
How permuatationally weak would 'weaker' expect to be???
Thanx!
Ben
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Number 26 of a series
Date: Wed, 08 Mar 2000 21:21:33 -0600
Recently, I post information on a cipher called Kabongo, which used
plaintext in Base 25 and produced ciphertext in base 26. I decided to do
some more base 26 ouput ciphers to sort of tie the ribbons on that area.
The next two could be called Dumb and Dumber, but here we go with the Dumb
one:
Actually, it was suggested that if one case of the alphabet is omitted,
there would only be 68 characters left to deal with. I incorporated that
into Tonk, which has a dumb sounding name, which somehow fits. The bases
involved are 77 for plaintext and 26 for ciphertext. Spaces are assigned
one of nine random characters, with a double CR using two space
characters.
Tonk does not use an intermediate base, but does have a 99.9% efficiency
rating since 77^3=456,533 and 26^4=456,976, a nice fit. Three
transposition sizes are used 7, 14, and 21, which each is really two
simplistic keys for rearranging input and output groups. There is also a
substitution key for the 26 character alphabet. Like Naga Hills, the keys
can be trivial. Tonk still has some merit since anyone of many classic
schemes might be used to manipulate the alphabetic output.
The default keys for Tonk 21 are as follows:
Subs(Tk): abcdefghijklmnopqrstuvwxyz
Trans(Tk): abcdefghi jklmnopqrstu
Since the whole keyboard can be utilized, Tonk can convey most messages
with loss of UPPER CASE. It is at least worth $0.02 to see it work. This
paragraph encrypted with the above default key is as follows:
tcmjn rsstl dcxww drtst yvupv chxnb pyymc srnfv omodt lgipu rznwy xtlye
qnpnn bfdns vnucj byngw tdtwr bkmtb okokw kulot pmpzr uoayn mlzfs rsbso
xlupt bzbzv xjzvx ixujl yndnn btnzx mqsuy ryhwg eltpz fpryf efomn rtooq
rukte skxpk adywj gssuj ssusp mpsrj yovdx oojdy ulotp nfcpj ovmzu zucjn
oalqn bzdto lfoln xptym nbtzo tdoqt uftad c
Decrypted:
since the whole keyboard can be utilized, tonk can convey most messages
with loss of upper case. it is at least worth $0.02 to see it work. this
paragraph encrypted with the above default key is as follows:
OK then, done with Dumb....on to Dumber.....
--
Imagine an internet on an up and up basis, where there are no subversive techniques to
rob a person of their privacy or computer
functionality, no hidden schemes used to defraud anyone. :>)
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: Differential Cryptanaylsis, Fiestel and PRNG
Date: Thu, 09 Mar 2000 04:27:02 GMT
� <[EMAIL PROTECTED]> wrote in message
news:8a6bpg$5oc$[EMAIL PROTECTED]...
> This is a semi-newbie set of questions.....
>
> What is differential Cryptanylsis?
An itterative attack looking at differential patterns to find non-randomness
in an algorithm.
> When looking at the official documentation for TEA - i saw i refrence to a
> Fiestel Network. What is this, is it secure and more importantly have i
> spelt it right. :)
Feistel Networks generally have the property that they diffuse with a rate
of 1/2. Each round will modify 1/2 of the block. It's also very symmetric
so the round keys are used equally. They are a good way to start a cipher.
You can make modifications to the structure [as in RC5 or RC6, or Blowfish]
and still call it a feistel cipher for the most part.
>
> What is the PRNG implemented Mircosoft's Visual Studio range. Has any
> cryptanyalsis been on done it?
Dunno.
>
> (background: Working on a custom cipher to be reasonably secure to all
> methods of attack which is easily implementable in VB)
>
> Any answers to any of these questions would be welcome.
My suggestion: Stick with publcly known ciphers.
Tom
------------------------------
From: "Adam Durana" <[EMAIL PROTECTED]>
Subject: Re: sci.crypt Cipher Contest
Date: Wed, 8 Mar 2000 23:30:43 -0500
> Why not specify a 32bit block and 32bit key and judge by clever design and
> mathematics rather than whether large governments can break it.
If large governments can break it is not the issue. Designing a cipher is
more than just comming up with an clever and original idea. Part of
designing a cipher is being given requirements and applying your clever idea
in a way that meets those requirements. For example you could be asked to
design a cipher that would work with a specific type of database, and each
entry in the database is 128bits. Here you would have to design a cipher
that would be able to encrypt 128bit blocks. So being able to work with and
fullfil the things that are being asked of the cipher is an important part
of designing a cipher. By setting block size, key size and etc, its making
designing the cipher more of a challenge.
> Otherwise it's insane. Lots of people could throw together a semi-secure
> algorithm if they want to take 20 minutes to encrypt a file or use 40 megs
of
> memory, but the algorithms you'll notice in publications fill many design
> requirements yet still meet their purpose. Theres more to cryptography
than
> achieving secure ciphertext.
You are right the amount of memory and the speed at which the cipher runs
should be counted. If you look at my other post in the 'sci.crypt Cipher
Contest Web site', we where talking about a point system. Each cipher could
be allowed to use at most 100K of memory and anything over that would cause
the entry to loose points. We could do the same for the speed of the
cipher.
Thanks for the suggestions.
- Adam Durana
------------------------------
From: Mike Rosing <[EMAIL PROTECTED]>
Subject: Big Float project
Date: Thu, 09 Mar 2000 04:44:07 GMT
I tried to get Tom StDenis to host this, but his ISP said no. So you
can
find the Big Float project on my web page:
http://www.terracom.net/~eresrch/float
I promise the code has bugs :-)
The idea is to compute the number of points on an elliptic curve. With
luck
I'll have Kobliltz curves in a few weeks.
Patience, persistence, truth,
Dr. mike
------------------------------
** 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
******************************
