Cryptography-Digest Digest #637, Volume #11 Wed, 26 Apr 00 14:13:01 EDT
Contents:
Re: Regulation of Investigatory Powers Bill (Richard Heathfield)
Re: Help: encrypting bit fields (Paul Rubin)
Re: new Echelon article (David A Molnar)
Re: Requested: update on aes contest (Jerry Coffin)
Re: Requested: update on aes contest (Jerry Coffin)
combine hashfunctions (Gregor Leander)
Re: sci.crypt think will be AES? (Jerry Coffin)
Re: Help: encrypting bit fields (Richard Parker)
Re: combine hashfunctions (Runu Knips)
Re: combine hashfunctions (Richard Parker)
Re: Looking for a *simple* C Twofish source (Runu Knips)
ECC's vulnerability to quantum computing ([EMAIL PROTECTED])
U-571 movie ("Don H")
Re: OAP-L3: Semester 1 / Class #1 All are invited. (David Formosa (aka ? the
Platypus))
Re: nss (Pavel Semjanov)
AEES 16 rounds ([EMAIL PROTECTED])
Re: factor large composite (Jeffrey Williams)
What came of it? (_Andy_)
Re: nss (Tom McCune)
GNUPG and BLOWFISH ([EMAIL PROTECTED])
Re: What came of it? (Gisle Sælensminde)
Re: combine hashfunctions (Mark Wooding)
----------------------------------------------------------------------------
Date: Wed, 26 Apr 2000 08:19:24 +0100
From: Richard Heathfield <[EMAIL PROTECTED]>
Crossposted-To: alt.security.scramdisk,alt.computer.security
Subject: Re: Regulation of Investigatory Powers Bill
Scotty wrote:
>
> Richard Heathfield wrote in message
> <[EMAIL PROTECTED]>...
> >Scotty wrote:
> >>
> >> >>
> >> >>But Bob is forbidden to tell Papinski that the police are involved.
> >> >
> >> >Who by? You're free to tell anyone that you are under investigation by
> >> >the police etc.
> >> >
> >>
> >> No not in this case, you are forbidden under penalty of 5 years
> imprisonment
> >> if you tell anyone except you lawyer.
> >
> >What if Papinski is Bob's lawyer? In other words, if your data is
> >encrypted using a public key, and your lawyer holds the private key,
> >then only your lawyer can decrypt the data, and you are free to tell him
> >whether you are under investigation, under which circumstance he is
> >presumably entitled to withhold the key as part of the lawyer/client
> >confidentiality deal.
> >
>
> No, it is a criminal offence not to disclose the key.
<...reluctant snippage of excellent explanation of this...>
<snip>
> >Furthermore, I don't suppose there's any way of arresting a computer. It
> >could be confiscated, of course, but what good will that do?
> >
> >
>
> The interpretation of the word 'key' in the bill is quite wide:
> "...means any key, code, password, algorithm or other data the use of which
> (with or without other keys)-
> (a) allows access to the electronic data, or
> (b) facilitates the putting of the data into an intelligible form; "
>
> If there is some algorithm that you can use to decrypt the data then you are
> required to reveal it. If you do something which causes the 'key' to be
> withheld or destroyed, *after* you have been served with a decryption
> notice, then you are guilty of non-disclosure [that's 2 years in prison].
Thank you for your explanation of those points.
It strikes me that this law will be completely useless against
well-organised criminals (who will not baulk at tipping off keyholders)
and in fact could not possibly be used except as an oppressive tool...
...which implies that every UK subject who has taken part in this
conversation, including me, is almost certainly going to be
investigated, at least in a 'background check' and possibly in more
detail than that.
Now, is that acceptable paranoia, or have I crossed the line? ;-)
(sigh) Time to start encrypting as many "Hello world" packets as I can
and flinging them to the four corners of the earth...
--
Richard Heathfield
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
34 K&R Answers: http://users.powernet.co.uk/eton/kandr2/index.html (63
to go)
------------------------------
From: [EMAIL PROTECTED] (Paul Rubin)
Subject: Re: Help: encrypting bit fields
Date: 26 Apr 2000 07:30:14 GMT
Richard Parker <[EMAIL PROTECTED]> wrote:
>Paul you might find the following paper by Bellare and Rogaway of interest.
>In this paper they show how to construct a secure variable-input-length
>cipher starting from any secure block cipher.
>
> M. Bellare and P. Rogaway, "On the Construction of Variable-Input-Length
> Ciphers," Proceedings of the 6th Workshop on Fast Software Encryption,
> FSE'99, Lecture Notes in Computer Science, v. 1636, Springer-Verlag, 1999.
> <http://www-cse.ucsd.edu/users/mihir/papers/lpe.html>
> <http://www.cs.ucdavis.edu/~rogaway/papers/lpe.html>
Thanks. It's an interesting paper. But it appears to be about
extending ciphers like DES to encrypt variable sized blocks that are
*larger* than the original 64-bit block. I need to encrypt something
*smaller*. I'll keep reading the paper and see if it says anything
about this. However, through the fancy math, it basically seems to
analyze the clever hack independently invented by Colin Plumb of
checksumming a partial large block to generate an IV to use with a
block cipher in CBC mode, then using the error recovery property of
CBC mode to recover the IV from the ciphertext, so it doesn't have to
be stored.
------------------------------
From: David A Molnar <[EMAIL PROTECTED]>
Subject: Re: new Echelon article
Date: 26 Apr 2000 07:04:08 GMT
Diet NSA <[EMAIL PROTECTED]> wrote:
> IBM's Watson Research Center, Celera,
> etc. However, many researchers at private
> universities & companies? receive
> funding from the federal gov't.
Silly idea #1 -- check to see if the index / search terms on the
CRYPTO proceedings CD includes OCR'd text of the
acknowledgements. Then count the NSF and DARPA
grants.
Silly idea #2 -- Find large list of cryptographers (Lipmaa's,
Counterpane, Wagner's, Crypto Research, whoever).
Build bot to crawl through all linked pages,
download all papers, OCR the acknowledgements,
and compile all NSF, DARPA, and other USG grants
listed.
Neither of these would be definitive; the CRYPTO proceedings aren't
the sum total of cryptology (far from it), and lots of cryptographers
don't have papers on their web pages if they even have web pages.
It might be a start.
Maybe you could model such a system on the NEC CiteSeer -- heck, maybe
it already does this (I haven't checked). Surely stats on which grants
for what fields and subfields give which kinds of papers are kept
someplace...
Thanks,
-David
------------------------------
From: Jerry Coffin <[EMAIL PROTECTED]>
Subject: Re: Requested: update on aes contest
Date: Wed, 26 Apr 2000 01:47:14 -0600
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
says...
[ ... ]
> Having one cipher will make interoperability easier. Right now,
> Blowfish is the de facto standard as far as our interaction with
> different companies is concerned. And having one cipher does help
> development: you don't need several ciphers in various libraries.
IOW, at the present time you ignore _all_ standards! Why should be
believe that what goes into the standard will really make ANY
difference to you (or anybody with a similar attitude) at all?
> > This, of course, is a good thing: it means there's less likelihood of
> > the cipher you use being broken before the information is useless
> > anyway.
>
> Interesting idea. Not a new one. I wouldn't think I'd encounter it
> again and again.
Of course you've encountered it again and again. It's a bit like
encountering the fact that 2+2 equals 4 repeatedly: it's a simple
truth, so no matter how hard you avoid it, you'll encounter it
anyway.
> So, lack of public scrutiny (because of lack of
> resources) in your opinion increases security?
I never said such a thing. You're trying to put words in my mouth;
I've never said that.
> Why don't you use
> obscure home-made ciphers then? Even if there are multiple winners,
> AES isn't for you: Even multiple AES winners will be examined more
> than Triple-Extended-Footux with modified S-boxes.
This is completely unrelated to anything I said. I suppose you've
provided still more unnecessary proof that straw men are flammable,
but until you argue against something I actually said or advocated,
you're not going to prove anything except that you're entirely
capable of missing or ignoring what was really said in favor of
arguing against something that nobody's said, simply so you can feel
like you've won an argument.
> The attacker needs to break one algorithm to get to your data.
> You need to trust all algorithms that you use to know that your
> data is secret. Choice of algorithms often isn't yours: software
> vendor or information supplier or some sort of ASP often makes
> the decision.
Even if we blindly assume that this is completely true, it has
nothing to do with what I said. Worse yet, it's not entirely true in
any case: just for one obvious example, it's pretty rare that you use
a product that has absolutely NO competitors. If it has competitors,
you can choose among them based, among other things, on the choices
of algorithms they made, if you consider that an important factor.
> > Whereas if you choose only one cipher and it's broken, instead of
> > simply learning SOME useful information, he learns absoulutely
> > everything you're trying to protect.
>
> Whereas if you have several ciphers, the probability of one of them
> being broken at one point increases.
If you want to claim this, you need to support it. Right now, it's
simply another piece of gas-doused cloth covering your straw man.
> > If you have multiple ciphers, you can reduce your risk by
> > partitioning the information so breaking one cipher causes relatively
> > little damage. Better yet, the chances of any of the ciphers being
> > broken is divided by the number of ciphers involved.
>
> The same data is likely to be transmitted at various times using
> various ciphers.
See above. You're making a LOT of completely unwarranted
assumptions, and providing no support for them whatsoever.
Furthermore, you've failed to prove that even if your assumptions are
correct that it would really mean anything anyway.
--
Later,
Jerry.
The universe is a figment of its own imagination.
------------------------------
From: Jerry Coffin <[EMAIL PROTECTED]>
Subject: Re: Requested: update on aes contest
Date: Wed, 26 Apr 2000 02:05:22 -0600
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] says...
[ ... ]
> IMHO, Rijndael appears to perform very well in the widest range
> of scenarios. I believe that if any of the ciphers get close to
> the ideal, then Rijndael does. Twofish I would place second in
> this respect.
> (Also to explicitly give an example in answer to one of your
> points, Rijndael has the best 64-bit performance on current,
> forthcoming and predicted platforms.)
"predicted platforms" ? You've GOT to be kidding! DES was in use a
FAR shorter time than AES might reasonably be (after all, people were
complaining about its small key even before it became a standard).
Despite this, how many people predicted the current HUGE use of DSPs,
just for one really obvious example? Even assuming there was some
tiny number of people who could have made such a prediction, they'd
have simply been written off as lunatics at the time, and NO decision
about DES (or much of anything else) would have been based on such
obvious idiocy.
Now, extend that period of time by a factor of three or so, and even
try to keep a straight face while you tell me that anybody has a
reasonable chance of predicting what will be in use before AES is
obsolete due to technology progressing to the point that exhausting
the key-space becomes practical.
The fact is, there's only one way AES will become obsolete within 50
years: that NIST makes a completely bone-headed decision about it
now. If you honestly think anybody can accurately predict computer
architecures 50 years for now, then I think the rest of the world (if
not necessarily you) will forgive me for dismssing your statements as
the ravings of a lunatic.
--
Later,
Jerry.
The universe is a figment of its own imagination.
------------------------------
From: Gregor Leander <[EMAIL PROTECTED]>
Subject: combine hashfunctions
Date: Wed, 26 Apr 2000 10:13:55 +0200
I have a document M and two hash-functions h1,h2. So, what I use now as
a hash value (for signing for example) is (h1(M),h2(M)). It is clear,
that this is at least as strong as the strongest of h1,h2, but what else
can be said about the strength of this combination ? I am looking for
some papers or other information about this idea and about problems with
this.
Thanks a lot,
Gregor Leander.
------------------------------
From: Jerry Coffin <[EMAIL PROTECTED]>
Subject: Re: sci.crypt think will be AES?
Date: Wed, 26 Apr 2000 02:14:44 -0600
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] says...
[ ... ]
> Nor does a patent holder necessarily *know* what infringes: A patent
> is a *legal* document, intended to "read on" as much technology as
> possible. The inventor may have a narrow personal interpretation
> which is only tiny subset of the owned technology. It may take a
> *patent* *lawyer* to understand that a particular patent actually
> covers something which seems distinct to the inventor.
In fact, it may take more than a patent attorney. Just for one
example, the courts have an execrable record WRT deciding what
patents do and don't cover. IIRC, one of the members of the Court of
Appeals for the Federal Circuit (devoted pretty much entirely to
patent cases) did a study a while back showing that the _majority_ of
lower-court decisions about patents that are appealed are overturned
to at least some degree.
> Patent holders sue for *damages*, not fun. Few if any damages will
> exist until production begins.
In fact, given the cost of a lawsuit, most patent holders won't even
THINK hard about pursuing a case until they're quite certain the
revenues from products they think infringe are at least into the tens
of millions of dollars (and quite a few would put the lower limit at
more like a hundred million dollars).
--
Later,
Jerry.
The universe is a figment of its own imagination.
------------------------------
From: Richard Parker <[EMAIL PROTECTED]>
Subject: Re: Help: encrypting bit fields
Date: Wed, 26 Apr 2000 01:11:52 -0700
[EMAIL PROTECTED] (Paul Rubin) wrote:
> Thanks. It's an interesting paper. But it appears to be about
> extending ciphers like DES to encrypt variable sized blocks that are
> *larger* than the original 64-bit block. I need to encrypt something
> *smaller*. I'll keep reading the paper and see if it says anything
> about this.
In order to produce something smaller than the the block size they suggest
using a r-round Feistel network such that if the smaller block length is 2i
then for the t-th round function use f(x) = F_K_i (x || 0^i) [1..i]. They
are not, however, able to derive provably-good security bounds for this
construction.
-Richard
------------------------------
Date: Wed, 26 Apr 2000 10:53:39 +0200
From: Runu Knips <[EMAIL PROTECTED]>
Subject: Re: combine hashfunctions
Gregor Leander wrote:
> I have a document M and two hash-functions h1,h2. So, what I use now as
> a hash value (for signing for example) is (h1(M),h2(M)). It is clear,
> that this is at least as strong as the strongest of h1,h2,
Why is that clear ? Maybe its possible to construct two h1, h2 where
h1 is easier to break, and breaking h1 gives informations about how
to break h2 easier ?
> but what else
> can be said about the strength of this combination ? I am looking for
> some papers or other information about this idea and about problems with
> this.
------------------------------
From: Richard Parker <[EMAIL PROTECTED]>
Subject: Re: combine hashfunctions
Date: Wed, 26 Apr 2000 01:50:12 -0700
Gregor Leander <[EMAIL PROTECTED]> wrote:
> I have a document M and two hash-functions h1,h2. So, what I use now as
> a hash value (for signing for example) is (h1(M),h2(M)). It is clear,
> that this is at least as strong as the strongest of h1,h2, but what else
> can be said about the strength of this combination ? I am looking for
> some papers or other information about this idea and about problems with
> this.
Gregor,
If either H1 or H2 is a collision-resistant hash function, then the hash
function constructed by cascading these two hash functions
H(M) = H1(M) || H2(M)
is also a collision-resistant hash function. Building a hash function from
smaller independent hash functions by cascading is a simple way to increase
strength.
The argument for this result goes as follows. If both H1 and H2 are n-bit
hash functions, then H produces 2n-bit outputs; mapping this back down to an
n-bit output by an n-bit collision-resistant hash function (H1 and H2 are
candidates) would leave the overall mapping collision-resistant. If H1 and
H2 are independent, then finding a collision for H requires finding a
collision for both simultaneously (i.e., on the same input), which one could
hope would require the product of the efforts to attack them individually.
Burt Preneel's thesis is the source of this argument:
B. Preneel, "Analysis and design of cryptographic hash functions,"
Doctoral Dissertation, Katholieke Universiteit Leuven (Belgium), 1993.
I lifted the language of the argument almost word for word from:
A. Menezes, P. van Oorschot, and S. Vanstone, "Handbook of Applied
Cryptography," CRC Press, 1996.
<http://www.cacr.math.uwaterloo.ca/hac/>
-Richard
------------------------------
Date: Wed, 26 Apr 2000 11:04:02 +0200
From: Runu Knips <[EMAIL PROTECTED]>
Subject: Re: Looking for a *simple* C Twofish source
[EMAIL PROTECTED] schrieb:
> Hello,
> I'll be happy to hear from anyone who knows of a
> freely available, simple, minimal C
> implementation of Twofish.
>
> By simple I mean: not using pointers, or long and
> complex one-line arithmetic expressions. I am
> trying to make it work on a limited and sometimes
> buggy embedded C compiler.
>
> It does not have to be optimized for anything.
>
> Thank you,
> -Al.
You can get an excellent twofish source from
(Starting page:)
http://www.btinternet.com/~brian.gladman/cryptography_technology/
(Load the .c and .h files from:)
http://www.btinternet.com/~brian.gladman/cryptography_technology/aes/
which can be parameterized to be very, very compact, even
working on a smartcard. Just comment all defines on the top.
However, it is AFAIK not tested for big endian systems, and
you might still have much trouble. All these '#ifdef' in
source doesn't make it more readable ;-).
------------------------------
From: [EMAIL PROTECTED]
Subject: ECC's vulnerability to quantum computing
Date: Wed, 26 Apr 2000 09:18:37 GMT
I've been reading as much as i could lately (and even understanding a
very small portion) regarding elliptic curve cryptography. However, I
have been unable to find any information regarding whether or not
advancements in quantum computing (which will necessarily debilitate
factoring based encryption ala RSA via Shor's algorithm), will have any
effect on ECC.
Bruce Schneier's Nov.1999 Crypto-Gram states that ECC's are based on
discrete logarithms, yet he mentions that most modern factoring
algorithms are nearly similar to discrete logarithms. Does this hold
true for reversible quantum algorithms?
Intuitively, I would assume that ECC does not hold up either, but it
seems that because of its relative strength at the same key size to RSA,
maybe if it doesn't, it would still last longer at least, although at
that point it might be like putting the milk back in the bottle. Or is
there some fundamental difference that prevents a quantum algorithm from
working in the group of elliptic curves?
I'm especially curious because I just turned in a paper to my Physical
Limits of Computing course regarding this, but had to end it with an "I
don't know..."
Slightly confused and grateful for help,
Jordan Wiens
http://jordan.wiens.com/
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: "Don H" <[EMAIL PROTECTED]>
Subject: U-571 movie
Date: Wed, 26 Apr 2000 19:46:55 +1000
This movie is a complete fiction, even though dramatically well acted --
about capturing an Enigma machine.
For controversy about it see Newsgroup >> "alt.movies"
===========================
------------------------------
From: [EMAIL PROTECTED] (David Formosa (aka ? the Platypus))
Crossposted-To: talk.politics.crypto
Subject: Re: OAP-L3: Semester 1 / Class #1 All are invited.
Date: 26 Apr 2000 10:10:21 GMT
Reply-To: dformosa@[202.7.69.25]
On Tue, 25 Apr 2000 21:40:48 -0700, Anthony Stephen Szopa
<[EMAIL PROTECTED]> wrote:
[...]
>If you do not follow the manufacturer's instructions, or don't
>follow the state driver's handbook you will most likely crash
>your car.
>
>If you don't follow the recipe your cake will fall.
>
>So what?
>
>What contribution have you made to this news group?
Good cars are built so that when they do crash they minimuse the
damige to the driver. Likewise a good cyper sould be built to
minimse the chance that they will be missused.
A few minor desine changes to your system would result in an
improvment in this mattor. If you dropped the sequence down to 12 and
instructed the user to shuffel a 1/4 deck of cards and use this as the
random imput. (You may do something on these lines but I can't find
reference to it in your help files).
I have anouther question about your system, how do you do key
distribution?
--
Please excuse my spelling as I suffer from agraphia. See
http://dformosa.zeta.org.au/~dformosa/Spelling.html to find out more.
Interested in drawing platypie for money? Email me.
------------------------------
From: Pavel Semjanov <[EMAIL PROTECTED]>
Subject: Re: nss
Date: Wed, 26 Apr 2000 15:47:18 +0400
Tom McCune wrote:
>
> In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (EP847)
>wrote:
> >At http://www.ssl.stu.neva.ru/psw/ there is a dos program that can decrypt
> >norton secret stuff. I have decrypted it in 10 days on a 400 mhz celeron.
>
> I know NSS is only weak 40 bit encryption,
32.
but what you used appears to have
> been just a password cracker.
No, it cracks keys, not passwords.
--
SY / C4acT/\uBo Pavel Semjanov
_ _ _ http://www.ssl.stu.neva.ru/psw/
| | |-| |_|_| |-| 2:5030/145.17@fidonet
------------------------------
From: [EMAIL PROTECTED]
Subject: AEES 16 rounds
Date: Wed, 26 Apr 2000 11:58:43 GMT
AEES is symmetric encryption algorithm, which is developed from the
DES architecture.
There are following features:
1. S-boxes are multiplication tables of finite groups
2. A key is used for
2.1. S-boxes generation
2.2. Sub-keys generation
One can see following advantages:
1. Algorithm architecture is scalable.
2. More security, while:
3.1 S-boxes are derived from sub-keys
3.2 Long key and sub-keys.
256-bit AEES 16 round block cipher implementation:
1. Key length 256 byte
2. 16 S-boxes: finite groups of the order 256
3. 16 sub-keys of 256 bytes length
Performance with my IP II,267 Mhz, 128 Mb is 101 Kb/sec.
Algorithm description and source code can be found
at <www.alex-encryption.de>
Have fan.
Best regards.
Alex.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Jeffrey Williams <[EMAIL PROTECTED]>
Subject: Re: factor large composite
Date: Wed, 26 Apr 2000 07:15:19 -0500
Your objection applies only to those for whom market economics apply
(ie: you, me, business, etc). It doesn't apply to government, which does
not aim to make a profit. A government may feel the need to have a
large computer (say a Beowulf cluster, for example) to break codes for
national security. That need may justify dropping <place insane quantity
of cash here> on such a computer.
Therefore, if you wish to keep your information secret from governments,
etc, 768 bit RSA may be inadequate.
Bottom line is that it really depends upon your adversary.
Dann Corbit wrote:
> So, suppose you can gain 10 million dollars by deciphering a transaction.
> It has to cost less than 10 million dollars to decipher it, or it's
> pointless. Consider the depreciation of the computers while the tasks are
> running, and you will find that it is rather expensive.
>
> Also, I think the computer network cooperation approach would not be
> terribly successful if the effort were focused to steal someone's money, so
> the bazillion computers on the net metaphor won't work to solve the problem.
>
> The RSA contests that appear to prove that a certain key is breakable really
> show the opposite. RSA is plenty secure for large key sizes.
> --
> C-FAQ: http://www.eskimo.com/~scs/C-faq/top.html
> "The C-FAQ Book" ISBN 0-201-84519-9
> C.A.P. Newsgroup http://www.dejanews.com/~c_a_p
> C.A.P. FAQ: ftp://38.168.214.175/pub/Chess%20Analysis%20Project%20FAQ.htm
--
Jeff Williams
Software Design Engineer
DNA Enterprise, Inc
1240 E Campbell Rd, Richardson, TX, 75081
972 671 1972 x265
[EMAIL PROTECTED]
Did you know that there is enough sand in
north Africa to cover the entire Sahara?
------------------------------
From: [EMAIL PROTECTED] (_Andy_)
Subject: What came of it?
Reply-To: [EMAIL PROTECTED]
Date: Wed, 26 Apr 2000 12:39:46 GMT
A few months ago, there was a report in the newspapers (followed by a
discussion in this group) about a Welsh (I think) teenage girl who may
or may not have invented a cypher algorithm... I think matrices were
mentioned.
I've looked back through the group history and can't find the relevant
threads.
Does anyone know if anything came of it?
------------------------------
From: Tom McCune <[EMAIL PROTECTED]>
Subject: Re: nss
Date: Wed, 26 Apr 2000 12:40:41 GMT
In article <[EMAIL PROTECTED]>, Pavel Semjanov <[EMAIL PROTECTED]>
wrote:
>> >At http://www.ssl.stu.neva.ru/psw/ there is a dos program that can decrypt
>> >norton secret stuff. I have decrypted it in 10 days on a 400 mhz celeron.
>>
>> I know NSS is only weak 40 bit encryption,
>
>32.
Thanks for the clarification. I have no idea how I mixed this up, but my NSS
download from 10/97 does indicate that it is 32 bit Blowfish. I've update my
web page reference.
>but what you used appears to have
>> been just a password cracker.
>
>No, it cracks keys, not passwords.
Thanks again. I was apparently confused by the web page being titled "Russian
Password Crackers," and the documentation title including "Norton Secret Stuff
Password Cracker," and the phrase "So, to crack ANY NSS password...." But
then it does go on to talk about testing key space and "...you only need to
test 2^32 possible keys."
-Tom
------------------------------
From: [EMAIL PROTECTED]
Subject: GNUPG and BLOWFISH
Date: Wed, 26 Apr 2000 12:53:48 GMT
I'm trying to decrypt a string that is blowfish encrypted. I have the
key. The string is passed to me in an HTTP URL. Can anyone recommend
a prewritten cgi/perl utility that I can then just pass that string/key
pair to in order to decrypt it? (unix)
I've installed gnuPG but when I copy the blowfish-encrypted string into
a datafile (userid.gpg) and use the key XXXX I get the following error:
gpg --cipher-algo BLOWFISH -d --default-key XXXX userid.gpg
gpg: Warning: using insecure memory!
gpg: no valid OpenPGP data found.
gpg: decrypt_message failed: eof
does anyone know of a better methodology for this?
-kevin
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (Gisle Sælensminde)
Subject: Re: What came of it?
Date: 26 Apr 2000 15:37:58 +0200
In article <[EMAIL PROTECTED]>, _Andy_ wrote:
>
>A few months ago, there was a report in the newspapers (followed by a
>discussion in this group) about a Welsh (I think) teenage girl who may
>or may not have invented a cypher algorithm... I think matrices were
>mentioned.
>
>I've looked back through the group history and can't find the relevant
>threads.
>
>Does anyone know if anything came of it?
>
>
You probably think of Sarah Flannery, who wrote a paper describing a new
public key algorithm. In the original paper she described it as secure,
but later she analysed and broke the algorithm herself. The paper can be
found at:
http://cryptome.org/flannery-cp.htm
A short review in the cryptogram newsletter of december 99
http://www.counterpane.com/crypto-gram-9912.html
#SarahFlannerysPublic-KeyAlgorithm
--
Gisle Sælensminde ( [EMAIL PROTECTED] )
ln -s /dev/null ~/.netscape/cookies
------------------------------
From: [EMAIL PROTECTED] (Mark Wooding)
Subject: Re: combine hashfunctions
Date: 26 Apr 2000 13:57:19 GMT
Gregor Leander <[EMAIL PROTECTED]> wrote:
> I have a document M and two hash-functions h1,h2. So, what I use now as
> a hash value (for signing for example) is (h1(M),h2(M)). It is clear,
> that this is at least as strong as the strongest of h1,h2, but what else
> can be said about the strength of this combination ? I am looking for
> some papers or other information about this idea and about problems with
> this.
This is true for strength properties such as collision-resistance and
second- preimage-resistance, which would make the combination useful for
digital signatures, or for authenticating previous plaintext messages to
ensure that they weren't tampered with (e.g., as SSL3 does on the cipher
choice negotiation). However, if either hash leaks information about
its preimage (e.g., whether it's a quadratic residue mod some prime, or
whatever) then the combination will also leak this information.
-- [mdw]
------------------------------
** 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
******************************
