Cryptography-Digest Digest #996, Volume #9 Fri, 6 Aug 99 08:13:04 EDT
Contents:
Re: frequency of prime numbers? (Anti-Spam)
Re: Pencil-and-paper compression algorithms [Re: Between Silk and Cyanide]
("NewsUser.2436")
Re: beginner question re. MD5 and one-way hashes ("Antoine Joux")
Re: Need letter frequencies (wtshaw)
Re: NORTON Diskreet Decrypt Help me ("Vasiliy Khalak")
Re: Americans abroad/Encryption rules? (Shawn Willden)
Re: About Online Banking Security ("ME")
Re: Storing keys (Atle Sandvold)
Re: AES finalists to be announced (Volker Hetzer)
Re: Do Window Apps using CryptAPI exist? ("Sam Simpson")
Simple challenge for Stdenis ([EMAIL PROTECTED])
Re: CFB mode with same initialization vector ([EMAIL PROTECTED])
----------------------------------------------------------------------------
From: Anti-Spam <[EMAIL PROTECTED]>
Subject: Re: frequency of prime numbers?
Date: Thu, 05 Aug 1999 22:59:53 -0700
The original title of this thread is "frequency of prime numbers."
Many of us here addressed the infinite number of primes, but I think the
original question is yet to be answered. Someone mentioned zeta
functions.
A rule-of-thumb estimate ( from Gauss I think?) for the number of primes
less than or equal to x, call it pi(x), is given by approximately
/ x
pi(x)~= | dx'/ ln x'
/ 2
and I find that I can't draw the integral symbol very well in
alphanumeric text so I approximated it with that three hash thingy. And
I used a tilde in front of the equals sign to indicate it's
approximately equal to that integral.
Legendre provided a better approximation of the prime counting function
with this:
x
pi(x) ~= --------------------
ln x - 1.08366
which is a good fit up to x = 5 x 10^6.
Above that range it's best to use the Riemann zetafunction
approximation:
pi(x) ~= R(x)
where R(x) is the infinite sum of 1 + 1/2^x + 1/3^x + 1/4^x + 1/5^x +
.....
To estimate the number of prime numbers between two integers, evaluate
the pi(x) function (whichever approximation you choose) at the higher
integer and again at the lower integer, and then take the difference:
pi( HighX ) - pi ( LowX ) = #primes betwen HighX and LowX
So what's the estimated freqency of primes in that interval?
pi(x) pi( HighX ) - pi( LowX)
----- ~= -----------------------
x HighX - LowX
for the "average" interval between primes in that range.
This can come in handy in cryptanalysis if you need to know how many
possible primes you would need to look for given some facts about an
algorithm that uses primes for operations, key generation, etc.
Hope this is of some help,
[EMAIL PROTECTED]
------------------------------
From: "NewsUser.2436" <[EMAIL PROTECTED]>
Subject: Re: Pencil-and-paper compression algorithms [Re: Between Silk and Cyanide]
Date: Fri, 6 Aug 1999 07:20:27 +0100
Reply-To: Paul <[EMAIL PROTECTED]>
In article <[EMAIL PROTECTED]>, wtshaw
<[EMAIL PROTECTED]> writes
[on compression and morse code...]
>
>I will take the time to post the full list of characters with their
>variable trit values if asked, mostly given historic values.
In case no one else has done so (yet) please consider yourself asked!
It would nicely tie together two of my interests (hint: domain name)
--
Paul. newsuser.2436 @ G 4 I K J .demon.co.uk
Never argue with a fool, he may be doing the same.
------------------------------
From: "Antoine Joux" <[EMAIL PROTECTED]>
Subject: Re: beginner question re. MD5 and one-way hashes
Date: Fri, 6 Aug 1999 08:39:49 +0200
Muharem Hrnjadovic a écrit dans le message
<7oc6q3$[EMAIL PROTECTED]>...
>I need a one-way function in order to generate hash key values
>for a piece of software that is caching objects i.e. when I come
>across an object the second time the function should generate the
>same hash key so I know that I have seen that object already.
>
[... < Problem with collisions> ...]
As told in many previous answer, you can't avoid this problem when hashing
~200000 objects to 32 bits. You can either move to 64 or 128 bits, or use
collision resolution.
The issue of collision resolution is adressed in D. Knuth, The art of
computer programming, volume 3 : Sorting and searching, section 6.4 Hashing
(p 506-542)
Antoine Joux
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: Need letter frequencies
Date: Fri, 06 Aug 1999 01:12:16 -0600
In article <[EMAIL PROTECTED]>, Jim Gillogly <[EMAIL PROTECTED]> wrote:
> wtshaw wrote:
> > Amongst your compilations of information, do you have a good list of
> > diagraphs that never or virtually never appear in somewhat normal text?
>
> Here's a list (least frequent first) from a fairly large corpus that
> happens to include all the digraphs for one reason or another. In
> case you want the most frequent digraphs later, you'll find them
> at the end. I don't guarantee this list -- it's just from a large
> pile of text I happened to have lying around this evening.
>
> In general, q followed by another consonant is rare. Again, though,
> it's best to generate your own stats from the corpus you're attacking
> if possible.
>
The purpose is for pairs of letters to represent certain characters which
would otherwise be excluded. If the replacement are embedded in text, a
much more restricted set for ciphertext can be used. In recovery, the
unusuals are substituted with the original characters. This makes lots of
things possible. The obvious pairs to pick on are those most rare, and it
surely will mess up an attackers precious frequency crowbars.
--
Sometimes you have to punt, and hope for the best.
------------------------------
From: "Vasiliy Khalak" <[EMAIL PROTECTED]>
Subject: Re: NORTON Diskreet Decrypt Help me
Date: Fri, 6 Aug 1999 10:43:47 +0300
Oh-oh-oh ...
There are no decryption of disk (and need me program!)
Many time was spended before I send this post & news group is LAST attempt!!
I need "Compiled Program" !
Thanks for you time & I continue seeking !!!
Where are you? Can help me (see first post)? I'm waiting !...
JPeschel <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> >"Vasiliy Khalak" <[EMAIL PROTECTED]> writes:
>
> >I need decrypt of Diskreet's disk.
> >Can you help me? I search all information about this but I can't find the
> >compiled program which do it self.
> >
> >Thank for your time & your help.
>
> Try Pavel Semjanov's site.
>
> Joe
>
>
> __________________________________________
>
> Joe Peschel
> D.O.E. SysWorks
> http://members.aol.com/jpeschel/index.htm
> __________________________________________
>
------------------------------
Date: Thu, 05 Aug 1999 16:50:49 -0600
From: Shawn Willden <[EMAIL PROTECTED]>
Subject: Re: Americans abroad/Encryption rules?
wtshaw wrote:
> In article <[EMAIL PROTECTED]>,
> [EMAIL PROTECTED] wrote:
>
> The proper next question if ROT13 is controlled would be what about the
> ability to do all Caesar shifts, which includes the former.
In that case, most Linux distributions should be controlled, as they contain the
'caesar' program which performs arbitrary caesar shifts (as well as a relatively
good job of guessing the key given encoded english text).
Shawn.
------------------------------
From: "ME" <[EMAIL PROTECTED]>
Subject: Re: About Online Banking Security
Date: Fri, 6 Aug 1999 18:14:19 +1000
Losely described, the 2 situations are:
ATMs use a 56 bit DES key, and are run a reasonably resticted set of program
code in the embedded functions in a robust, restricted access housing.
Depending on the part of the world the ATM is in, these keys (I am focussing
on the PIN protecting keys) change every transaction, several times per
day, several times/year, or never ie the key stays the same. In many cases,
a double length DES key (3DES) is used for key management to it's host, and
or transactions keys are derived from master keys using 3DES or similar
processes. Some bank hosts use tamper-resistant encryption servers etc for
securely processing ATM transactions, others use software processes. Often,
some form of security assurance review has been performed.
40 bit SSL uses non-security assured code on machines stuffed full of other
code of unknown origin, with 40 bit keys in a uncontrolled environment,
communicating to machines running non-security assured code on machines
stuffed full of other running code of unknown origin with little/no physical
access control.
Think about the differences.
Make a choice.
It's not a hard process
Lyal
Greg wrote in message <7od3k4$2j1$[EMAIL PROTECTED]>...
>
>> ATMs are for the most part secure devices
>> now (???).
>
>Would you say that 40 bit SSL over the internet is more insecure than
>ATM machine comm lines? If not, then what's the difference?
>
>
>
>
>--
>The US is not a democracy - US Constitution Article IV Section 4.
>Democracy is the male majority legalizing rape.
>UN Security Council is a Democracy. NO APPEALS! Welcome to the NWO.
>Criminals=Crime. Armies=Tyranny. The 2nd amendment is about tyranny.
>
>
>Sent via Deja.com http://www.deja.com/
>Share what you know. Learn what you don't.
------------------------------
From: Atle Sandvold <[EMAIL PROTECTED]>
Subject: Re: Storing keys
Date: Fri, 06 Aug 1999 08:20:36 +0000
What if I were to use a different authentication scheme(which i will),
for instance smartcards or biometrics?
I would need something to hash, right? Something the user provides.
If the only thing I care about is whether the user is authenticated or
not, would using a master key be the best alternative?
Thanks
-Atle
[EMAIL PROTECTED] wrote:
>
> Atle Sandvold wrote:
>
> > What is the best way of storing keys for a symmetric algorithm?
> >
>
> A one way hash algorithm (such as SHA) would be what to use.
>
> > If for instance users homedirs should be encrypted, and all the
> > encryption keys should be stored in one safe place. The key to one
> > particular homedir should be released when the user logs in.
>
> Once again, a hash stored on the user's computer.
>
> > If the key database is encrypted, some sort of master key would have to
> > be used to decrypt them. How should one store the master key?
>
> Don't use a master key, have all the individual passwords hashed. Because
> if the master key was comprimised, the entire database would be
> compromised.
>
> > Are there some documents that describe how these keys should be stored?
>
> Not really. Hashing works like this:
> When an account is created, the user enters their username and password.
> The password is hashed and stored on the HD.
> To verify that the user entered the right password later, you would hash
> the password the user entered and verify that it is the same as what is in
> the password file. The only weakness is that it could be brute forced, but
> that is allways a problem with passwords. No big deal.
------------------------------
From: Volker Hetzer <[EMAIL PROTECTED]>
Subject: Re: AES finalists to be announced
Date: Fri, 06 Aug 1999 11:28:35 +0200
[EMAIL PROTECTED] wrote:
>
> I have been informed by NIST that the five or so AES finalists will be
> announced next Monday at 10 am. My Frog algorithm, as expected, will
> not be one of them.
What time zone?
(Sorry yours didn't make it. But, even getting an application in is a lot.)
Greetings!
Volker
--
Hi! I'm a signature virus! Copy me into your signature file to help me spread!
------------------------------
From: "Sam Simpson" <[EMAIL PROTECTED]>
Subject: Re: Do Window Apps using CryptAPI exist?
Date: Fri, 6 Aug 1999 09:09:29 +0100
PGP can use MS CryptAPI as an RSA provider....
--
Sam Simpson
Comms Analyst
http://www.scramdisk.clara.net/ for ScramDisk hard-drive encryption &
Delphi Crypto Components. PGP Keys available at the same site.
If you're wondering why I don't reply to Sternlight, it's because
he's kill filed. See http://www.openpgp.net/FUD for why!
wtshaw <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> In article <7od3qq$2ke$[EMAIL PROTECTED]>, Greg
<[EMAIL PROTECTED]> wrote:
>
> > Other than Microsoft Outlook Express, and probably other
Microsoft
> > products, I don't know of any applications that use Microsoft's
> > CryptAPI archictecture. Can anyone tell me of such apps by third
> > parties?
> >
> Considering their source, it might be hard to find even many second
parties.
> --
> Sometimes you have to punt, and hope for the best.
------------------------------
From: [EMAIL PROTECTED]
Subject: Simple challenge for Stdenis
Date: Fri, 06 Aug 1999 10:27:44 GMT
Why havent you cracked this message. Cant you?
begin 755 fortom.cpt
hA1ca75Ay70Bn70gbOGkY6KAj7m+b9qAV70ld7mgYQoNeTG3xRattTrEaJ03l
hMr2mOEMBOGkY6KAj7m+b9qAV70ld7mgYQmAYDbAY7XckA1ca75Ay73IqRbVi
h7a6YA4oxBkoB+YYA1UIAOKVq8bBkRnle7YdWTrpoNHsyPL-nNKIb947bQndz
hQqZcMKBlRaAiRKddQqJfP5BHPrFoTqpp74cf8WBnHLwb8ape12ZhMW-mT0NZ
h75Ua7qteA53xPWQYNrFoA5tXNm3bR5RnNKJyOKdhPGNw8G+bFXQVNqob7qZV
hQqRhPGRqPrVZN5xW717kM0AaRqtXF+NWQmNeOrYd+YYA1UIAOKVq8bBkRnle
h7YdWTrpoNHsyQL+qRmhZ65VnO1-e7qJzP0xoRqIzMWh9+GBVQ1-qTqdYSLJc
h8bAyI4gaRmQ8ErtlPmpaOKQbPaBbPK+g7rxg6KllSHgYPqskTrFZMLBdPLQv
h74cb9aJmN0ojRq3oT1FiRaVdN4BZDKFVPLBkPbwkQrJcQ1NkQ5-S1bliDKEY
hM4BdPalnOX2VRrkgN47WCa+YOXkYQb7pA4dbRm-dOr2r80ha7qUYQnNVOKZd
hO4BpP4ZdOKtnQqJhQXMYQb7WTqxVP3sIQqcbP0hn6KYYQW7WMW-rPX-mQqAv
hMmhb6KNZOXNr7bgkRbBeMLBdPLQv75xj90lrM0te7qBcMHRYObVdNbUY7qhV
hDXlqPrptTbhe8ZsII4gq74Fr95tZRGdUOG-VM12VMK6eRL7o7qdeSLBZO5sk
hR5xZRWdiQ4cxMmhiCWlkOGMjR43eObUVQ4Eg7qteA53xPWRhOLER4adoOn-v
hRr-nPLUb9rZeMXRaO4taMqwVR5saMrtbCapXDX7e7axySKhnMLBzOb+YMLYb
h94pbOKBvPapW6Is90EN+LaFlQq-ZQ5BVO5ZWOKdm716yMaczMGhZA0lZNGRa
hOKQbNXQVQ4BdQqBVQqxhPGQYN5JcA5Jc70RqMGAzMKpnF+NrO0Re7qxV9nRd
hMGkAOKVq8bBkRnle7YdWTrpoNHsyQqcxM4FkNmkYIH3eR5AbSmhY70s6MqwY
hAWBWRnxV81EyAXdYQGReOqpS1add9GlrN0xeN5EbSmhY74cUOqsY8allDWFZ
hO4skTqUaM03zMmAm74pi7KYYPX2jMKZfOX+VMbsaOWhZDKlkRXNq7aptTbtd
hQrBzOaRS1axp7bkYRGheOW-iMKBpP4ZdEaJb6LdoOXdfO1d+MbJVRX7n75Eu
hOaxcDW6Y6FdUQW-kNWxh75wgMWhkCqMYS1dcMndyQLRX90+r0EYmR5hW85sY
hO0ojQqVW9mxcRrVdNKFwTGAYJnIYTrJZA5tXNnduMGAeOrsb9KBe7XQjQ43d
hSqBpOmkgOKVq8bBkDX6YM5BwRHM91WdlQGAkNKIbCqZdPXJe7qZn9mJnOq3d
hQqBVQqxhPGQYN4AkMrxeMH-ePKoo747nOKpeNKBzRKJoT0djMmkxPqsYQIRV
hQXNkMlQOJbBeML2yNbMbQ4FdNk2C12Y4I4VWMKBsOrZiQKsY6rNkDX7cOXdY
hS5waMXdmML-nTKFmOLhZPnQjQqwbP0ljQaYvQmhhDGBkRXMYM5BwRHdePG-e
h8+tNQ57r90lxPXNx7r-aT1-qOrsh7q7e7qkYOXhV7adlMqZlOm3u746xM0hY
h7a7WO13WNbFiM0oVNaAlMbUeQmBRQGNq7adlMqZlOm3u0EYyQLVnOKtV6H-a
hTm-YNm7nNKwxMbZrQqdeDXxVO5pYS1ddRbBtRaMmQ4tpNGlZPmQjObJoSqBX
hMGkUMqte7qdbTnwYPrEkQbJmP3sINakfMLUdOGlHOGNV7rFjOX-Y74waOKxh
h7qdfQ0+YNqVpA5RXQ5wyNKor75xj95tV6G7xMW-VNWxYRmkUOGhkCqMYS1dc
hMndwSKZm83sIQ4gq70ZJD46a6G3uQrFcMKBqPK+Z7qZVA4ldSrBZQ5htT5hY
hO1Mk70A1RatoCWlhRKwjNatX9nRdMGkjPaRV60BhQ5BkPbwR4bNjRmQyQqcz
hO0hZ90lVPm-xTb-nOWQiM4YeRL7o7qNUDX7eMXdbSLNe71RrRq6XR4taCmlW
hQmlW7rFjOaBhPLwx8GgY4aIYOXhV0l-pTbZoTGBePKkx74pa64-r6GJURG-o
hM0tY75sgNbVfDGwYTrBdMqZXQLpX713lT0AbMKRf647X6HdUQW-nNmdm75gU
hOqQYAbBoSn7q0l-lTbsaQ1hv74omOKsbDaJcPKBxMapaNWoVOq7dQqBVQqxh
hPGQe0l+R4VB2TLBuMKImQKRnNGl-Pm-xTb-nNWlj73kvO4lqAasYTHhVNL3X
hA4td70-vMGAuMWhn6KYYNmdXMbAbRWlo74EcQKs7KKFhO1Ne7bBYA57bQXMy
hQ4gq74tzDKZeQWdUOG+ZP1Bp7W7d7o7WQrRgSmcYMbIwA4tiMLBkMLEzTGhY
h7a7mN13vMaEbOGdhME31Q47cDmBgTmJV7atsRHdpNHtv74omOKsbDaJkOKBv
hPqIb9G-lQ0tdRKtdD5JVSboY7ZBqA4tiMGcyM4kx6rwfOLVgN4AhN5-n9Is9
hMLExMaJrCaleDWFhObMkQbwaNHRuMKRx70hH6LZr9KBsPqJd9ndiQGkjPbZr
h7mBVQ1-qTqdYA5gaMXdmMGAuQ0hk64-c6G3e0UdXOX-cMq6cQqtUQq3xDWRg
hMncmQqdm7bBvT5QqObVi7a6c6G7VMm-kNmNj75IaQWhUBa-qNmBk7bgkAbZq
hQ52yMaczMGhn6KY70mlxPaRiMG7h74cUOqteAatVDWFhObMkQbwaRXNhQ4kV
hMKwdF+M70odCOrBc9m3s74UgMKdlDrQcDWRgMncmIKZh713vMakVMGhcDqZq
hRX3aQqZdO4BU74cUOqsaQq-gSn-j7bVzO1djRpsINqgqNq-W9G6Y6FFbMasb
hSmhY74YbN5Zx6rRhQHoYRaVzRqVbOLBgQKoU80hiDGlnO0xX7q3oN4BqP4Yx
hPqtqQrdfOrBnNrFYA4td0JZlQaMVQrZiDKYYM0pq7qNiMmNm75gVPaVgQrFh
hQXwYN5wkTqlXRWFgPLQbMKIb646YRGhe7r-pM0-YRrxb7mhBBGBxQGMYMbJy
hBqs91WFzObRnRrtY6GloQmlWRrFiMGEh75IaQWhbAaoYSXNrMrNpQqsaQ1hr
hRmAlQLxn7a6e6KB5O5RWSGNn80kkO5sYDbNrObBaMlQOQrhoMHJfO0AuMWhy
h7bYYNGko7rZcSX2VOq+h7qphDqNrDXtZTndmRHddQXNgQr2uQ5xW7mlnO1Rb
hO5Jn9ndiQLtdN4Fe64NeObo71-QO4IBdQLBxNKpnNqRi8aQYPWojQqVW9q32
hT4Ix7Gha7bRkQHoYQbIkMKxjQ5BeP4NnR5Zc9btZP4o01EoB+YYg8G3Y8WMd
hTWsdArsd8nQxDHQf8Lsn8Gty8GMeN02d94sW8Woe6asg8G3Y8WMdTWsdArsd
h8nQxDHQf8Lsn8Gty8GMeN02d94sW8Woe6Ys9FLYxPqFqR5+YQ1lkMm+R4VQA
h1FcyP4kXMGhy7bYYPGdYMW-nNmdm74+UQrxcBWBoP1lXR5hxDXcaHGQyQ4kw
hPmhe90lfPmxq7q2bMmdpQ4+g7rxhDaM730Rf7apWSKtX85BhOmAO75lc7mhk
h6G3UQqVWTKBsOrZdMKFqQqtfQ1Nx7bJWA5hcTGRqPKoo74Ri6aYYRGhiQmsb
h9kcVR4+cOGhkD+sCOm-V7bBYA5RzRnNmMWApOrYb9qJcN1+jMbVrM1-YM0kx
hO0hkCqMYJnpkMqVyRKsaNHpu74cxQ5Za7qZkQaB47qFcMKFp75gcOLw7KKlk
hRXNq7adpTqdeMLBeOmAVMKdXNmkYG1QcR0-VPX-p74obMmhrAaJVAbBZO5sk
hNbBoQ0NzO4we747eCLtVNWpiNKlW6Is90EN+HaoY8allDXhZQ5wkQLFz707f
hML+bPKFdCWlfQqBgO4peOWppRmkaRGhr7aFXSm-kPrJyMnMaR1xvNL+q74se
h74phPIs3OaIbPXQVNqwcRLZhDqx2S17r857lMalbRXQkMKQa8Wgb+0lUPWoc
hQm-UOXQVQ4BdN4BVA4UYQmcYOrhtT1dkMG3b74kpQ4tdNE2CMnNv7oYbTn3i
hOKIuMWhBR4xcDXFVQXdmQLZh70Rl75cwQGhaCWlrPWlV7q3o9kcVNK3dNaZc
hBWoYDVde7aVpQLNjQ0cyHGArOkMB9aZk6HRU7qJlOX3sOq6g8mhrD0BhS5Bx
hOKwkS5hkMLBzObcbP47d9WlkPaBwNbYbOGNYO0kjRKtVQrRfDW-VO5skTLwa
hNLBkOrQq8UMB+5UYNGleR4sUSqBpNKQg7qNlA4gYOXddMnMkMbxbO1xb8UtN
h0E2C0qYYNmlxMbRaTGpYM0-dQqBf7aFgA5AYHnpxA5FdQ5BgML+XOqJo64tc
hN4BaMG-yM1MVMK6eRL7o7ksCTHldOrhyR1FZOnsyNKor757cD5sYQXdwQqJe
h9mRiMLwb65wYAKlfObwYOKUkOLJn71NkNr2eR5wb846YO0tzO57nPWpp0EMh
hO4VlDaNeObBZO5skRbJoMnNe75QvMGhr85xrRWlxMmsb9kdb75UVPbUY6r3f
hSG3ZOndnQKxpMG+yNKoe74Fn6KZq12ZzRKxZMmNgRm-dNKsY7qhVNrBxOKxW
hA5lbQHxe74kV747nCWlfRWoX7oYUMaBmPK2UOqdqDrcYQ1lk7aVpMqddOW-r
hNawq8UMB24Bl6HNwMW-iSqBUQ0kkO5tqQqlnQ5BqPqZvDVQA0JYLGrQvMLYb
hDKFZPqBvPq3n9kcVP4ozMWheD5RgRnpX7bRZQr6aQ1kyRq6e8Wgb4apWN4Bi
hOKEbNm7lR5JdN4Fd6rNkRnpX0l-YTndzOmMk70AO74BcCKYYRGhaR0-rTGla
hRaoY7qVfDaNrDXde7b7lTbtz71dk75+wOKsbDapx9qAjHW-fNWVY75wUObhc
hBUsCPW3fMKVlTKYaTHlf74+mOWhU95UYNmlx7qNpOWMVNK6h7rtrBWBVTm-h
hOaAkN57bQ5BhOqwZMGhaOLxoN0-aMKZY9nBnOqsZMaMcLUZrTmJhO5okOLJn
h70RqMGAbPKNWOKBW6HFxPbFiMGEVRqAYMbxgCapXDWdfQqVXRLNU8bAyI4gm
hQ0loOLhgM1QjQqViT4BcRk31MqtrCaFeSnQYQbIkQbww716yO4cbQ4RWOLZk
hO0xaQrYbOGln75kgO5hcBWBnRXkYO5xpR1dUNG-e74MxNrZyCLVhPWoV0Ud+
hNXJYOW-dQqBV6KMYTm3V7bgkT5Jm71ls74MxNrZyCLVhPWojNalUM13cQ4EY
hR0hf7bQYOXhVR5wwA5hcM5BbOrNnNqFm7KU70m3uTW-aMHcVOqddNWhe7ata
hSm2YOLkkNKtjO1deTGAXNKVgCWlZPmQjM4Jn9m7j74ovRKdxQqlWDWRgMrQy
hA1d2QGQyQ4guRkMB65wYNn3eMWkbPWpZ74Ix65UYCqNqSroY7YxXRHdjQ5Br
hOWAoOqFXOKFVM0xvPms8-Is98IwVRK7r7qdZQ5B5NqVWSLNeOpsI74+kNLZp
h64-cEGJiR0tjPX3rNLsh8KtU7UsCArsd8nQxDHQf8Lsn8Gty8GMeN02d94sW
h8Woe6asg8G3Y8WMdTWsdArsd8nQxDHQf8Lsn8Gty8GMeN02d94sW8Woe6asg
88G3Y8WMdTWs73+
+
end
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: CFB mode with same initialization vector
Date: Fri, 06 Aug 1999 10:45:17 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (John Savard) wrote:
> [EMAIL PROTECTED] (Daniel Vogelheim) wrote, in
> part:
>
> >why is encryption in CFB mode insecure, if you use the same
> >initialization vector multiple times?
>
> Well, CFB mode takes the IV, encrypts it, and XORs it with the first
> block of your message.
>
> So, if you use the same initialization vector multiple times, you are
> sending multiple messages - which may have different beginnings - with
> the same thing XORed to their first blocks. This is like using a
> one-time pad twice, and can be solved by the same method, without
> having to break the DES (or other block cipher) encryption at all.
>
> John Savard ( teneerf<- )
> http://www.ecn.ab.ca/~jsavard/crypto.htm
>
In my TINY series of programs (TINYRC, TINYRIJN,
TINYSAFR and (soon) TINYSERP I have addressed this
problem by moving the filename from the DTA and putting
in (in caps) into the IV. So unless the file names are
the same, the IVs will be different.
--
Robert G. Durnal
Web pages at www.afn.org/~afn21533
and members.tripod.com/~afn21533
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
** 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
******************************
