Cryptography-Digest Digest #988, Volume #13 Sat, 24 Mar 01 13:13:00 EST
Contents:
Re: Idiot Question -- Please Help a Crypto Moron (John Joseph Trammell)
Re: Passphrase Recovery (not a stupid Q) ("Thomas J. Boschloo")
Re: Idiot Question -- Please Help a Crypto Moron (Merrick)
decryprtion help please? ("rh")
Re: on-card key generation for smart card (Anne & Lynn Wheeler)
Re: What the Hell...Here's what my system can do at it's best... (Keill Randor)
Re: Idiot Question -- Please Help a Crypto Moron (John Savard)
Re: Crack it! (amateur)
Hello ("Tom St Denis")
Re: Crack it! (amateur)
Re: New PGP Flaw Verified By Phil Zimmerman, Allows Signatures to be Forged (Bill
Unruh)
Re: A new DES? ("Simon Johnson")
Re: Open Source Implementations of PGP (Bill Unruh)
Re: decryprtion help please? (Jim Gillogly)
Re: cryptography using the method of elliptic curve. ("Mauro")
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (John Joseph Trammell)
Subject: Re: Idiot Question -- Please Help a Crypto Moron
Date: Sat, 24 Mar 2001 14:12:59 GMT
On Sat, 24 Mar 2001 09:03:08 -0500, Og Johnson <[EMAIL PROTECTED]> wrote:
> I'm at work, and was just handed a word puzzle. If I don't answer it by
> noon today (it is 8:52 EST right now) I have to buy everyone in my office
> lunch. I'm too lazy to think, and I'm not feeling at all generous with my
> money, so could the Jim Gilloughys and the Bill Shaws of sci.crypt help a
> poor forty-niner out?
You're not lazy enough. :-)
http://www.google.com/search?q=send+more+money+puzzle
------------------------------
From: "Thomas J. Boschloo" <[EMAIL PROTECTED]>
Crossposted-To: alt.security.pgp
Subject: Re: Passphrase Recovery (not a stupid Q)
Date: Sat, 24 Mar 2001 15:32:21 +0100
"Ryan M. McConahy" wrote:
> No, this is not one of those "I lost my passphrase. How do I revoke
> my key?" questions.
>
> I had two keys, both RSA, both protected by the same passphrase. I
> lost that passphrase. I recovered one key from backup that had a pwd
> I remembered. Can I use this info to recover the key?
This is a hard question. Your secret key is protected by the hash of
your passphrase, maybe with some seeds included but let's be optimistic.
So you know the exact plain-text for a secret key encrypted with the
same passphrase. And you know of another key that is encrypted with
(maybe) the same passphrase and same resulting hash.
I just don't see how this would help you much, except for being able to
check if you hit the correct 'symetric' key pretty efficiently.
> If I can't, does anyone know of a program that would try all the
> uppercase/lowercase combinations, then try altering each char., and
> try the uppercase/lowercase thing on that.
I have heard of two, but they are mainly for RSA keys :-( You could
write one yourself though, as the source is 'open' source, but you would
need some programming experience. <ftp.zedz.net>
Thomas
--
Kittenbirds - You, me and Jesus: "I love your hair it's just so long"
------------------------------
From: [EMAIL PROTECTED] (Merrick)
Subject: Re: Idiot Question -- Please Help a Crypto Moron
Date: Sat, 24 Mar 2001 14:58:09 GMT
On Sat, 24 Mar 2001 09:03:08 -0500, "Og Johnson" <[EMAIL PROTECTED]> wrote:
>I'm at work, and was just handed a word puzzle. If I don't answer it by
>noon today (it is 8:52 EST right now) I have to buy everyone in my office
>lunch. I'm too lazy to think, and I'm not feeling at all generous with my
>money, so could the Jim Gilloughys and the Bill Shaws of sci.crypt help a
>poor forty-niner out? <SNIP>
As long as you cannot have 0 for a first character, the answer is
$10652
------------------------------
From: "rh" <[EMAIL PROTECTED]>
Subject: decryprtion help please?
Date: Sat, 24 Mar 2001 16:13:24 GMT
A buddy had asked me yesterday, if it would be possible to
migrate all of our pins from the current main system to the new test pin
vault. We have no decryption utility that could do this. Below I have
included some clear text
pins and then the encrypted version that is located in the SQL database.I do
know that the clear
text pins "are encrypted with themselves."
Pin Encrypted Pin in SQL DB
1234 9EE7964577447ADA
9999 1F1D2C2ED301B2A6
test 8A49D1CCB9AA5DBB
hello 7F85C0A9F3F86EC0
4567 60956233056154AC
123456 5155482C2078BF2C
voyager 73C63521A96FF1C9
ATLAS BFC44BCCC9ED5EE5
--
Robert Hawks
http://www.elitedaytraders.com
------------------------------
Subject: Re: on-card key generation for smart card
Reply-To: Anne & Lynn Wheeler <[EMAIL PROTECTED]>
From: Anne & Lynn Wheeler <[EMAIL PROTECTED]>
Date: Sat, 24 Mar 2001 16:23:32 GMT
Daniel James <[EMAIL PROTECTED]> writes:
> I have done APDU-level work with some of GemPlus's RSA smartcards. Their
> GPK4000 card generates a 1024-bit keyset in 160 seconds 90% of the time -
> the remaining 10% of the time you get an "operation not complete" error
> code and have to start again. Their newer GPK8000 cards - which are said
> to perform the keygen on-card - typically generate a keyset in less than
> 10 seconds using GemPKCS (I've not had occasion to perform a keygen
> operation at APDU level, but I have examined the access control
> attributes on the key files and I don't think this is "faked").
in general, key gen is characteristic of the chip used ... and
frequently it is hard to get the chip specifications from the card
vendor ... sometimes because they may source chips from a number of
different chip vendors for the same card ... and the chips may have
different characteristics.
typically the issues are 8bit chip or 16bit chip ... or in some cases
newer 32bit chips, the speed the chip is running at (although
frequently it is 3.?Mhz, although newer chips are sometimes 10-15mhz),
whether there is a crypto accelerator and what kind, and the quality
of the random number generator.
the vast majority of smartcards in the market are 8bit chips, 3.?mhz,
no crypto-accelerator, very poor random number quality and 8mins for
1024bit key-pair.
the circuit size of a 1024bit rsa crypto accelerator giving a 10*
speedup has been on the order or larger of many of the 8bit chips in
the market.
I don't believe i've seen any such accelerator in 8bit chips ... so it
is a higher end, more expensive chip. Furthermore, for keygen it
doesn't do much good unless there is a relatively decent random number
generator ... which also makes the chip more expensive.
Now, one of the interesting things in the arena of authentication with
public key digital signatures is the trade-off of RSA digital
signatures vis-a-vis DSS digital signatures.
Effectively, RSA digital signatures have relied on a random nonce in
the data being signed. Smartcards have tended towards RSA digital
signature implementations because the PC or other unit creating the
message can be relied on having a much better random number generator
... so that the random nonce is done as part of composing the message
(rather than in the card as part of generating the signature).
One of the reasons that you tend to see fewer DSS-based smartcard
implementations is that DSS requires the random number as part of the
digital signature process (in much the same way, oncard quality random
number is needed for oncard keygen, DSS also requires oncard quality
random number for signature ... aka ... rather than relying on outside
agency to insert random number in the body of the message, DSS
incorporates the random number into the actual digital signing
process). DSS signed messages can be 20bytes shorter (no random nonce)
but the resulting signature is 20bytes longer.
The 8bit chips with external keygen, no crypto accelerator, poor
quality random number, could implement digital signature
authentication functions ... relying on external agency to reliably
provide random number in the body of the message (and reliably offcard
do original keygen).
Given a quality number source on the card (needed in any case for
oncard keygen), DSS becomes much more practical and also reduces a
possible attack where a card is fed messages that don't have the
requisite random nonce.
Also, having a chip with a quality random number (sufficient for doing
on-card keygen) could also be used to shift from a RSA-based signature
to a DSS-based signature (minimizing card's integrity dependency on
external sources).
And finally, EC-DSS with eliptical curve keys ... doesn't need the huge
circuit area needed for 1024bit crypto-accelerator function i.e. if
you have quality on-card random number generator sufficient for
on-card keygen ... that also makes the card practical for DSS (&
possibly minimizing infrastucture dependency on having external source
provide card with messages incorporating random nonce), having quality
random number for DSS, also enables EC-DSS ... which can eliminate the
requirement for the large circuit area for the 1024bit crypto
accelerator.
random url:
http://www.garlic.com/~lynn/aadsm2.htm#straw
http://www.garlic.com/~lynn/99.html#224
http://lists.commerce.net/archives/ansi-epay/199912/jpg00000.jpg
--
Anne & Lynn Wheeler | [EMAIL PROTECTED] - http://www.garlic.com/~lynn/
------------------------------
From: Keill Randor <[EMAIL PROTECTED]>
Subject: Re: What the Hell...Here's what my system can do at it's best...
Date: Sat, 24 Mar 2001 15:47:43 +0000
John Wasser <[EMAIL PROTECTED]> wrote in article
<[EMAIL PROTECTED]> :
>I don't understand what someone would use this "encryption algorithm"
>for. From the description it sounds like each paragraph conveys one
>word of plaintext. Not very efficient.
>
>My guess is that if "computer" is the ciphertext and "actually" is the
>plain text then the key is probably "graphics" since that is the only
>other 8-character word in the paragraph.
>
>In article <[EMAIL PROTECTED]>, Keill Randor <
>[EMAIL PROTECTED]> wrote:
>
No....
The whole point, is to turn one peice of information into another, using another, when
none of them can be individually proven to be encrypted. As I said it's just a
demonstration. (A single paragraph or even sentence could contain all three peices -
it just depends on what they are, and how easy they are to fit together). (The first
example I gave, is the best I could come up with in 15 mins.).
(In the first example, the key is [ ati c]).
The parts to the puzzle don't necessarily have to be WHOLE words, they could be part
of them or a part of a larger sentence.
Also I gave EVERYTHING I had (at the time) - (I have slightly more now), to GCHQ.
(Far more than I have given here). I am waiting to hear from them, but they are
pretty busy at the moment.
So why do I post stuff here?
At the end of the day my friend is using what I have to test the system, (and the
Public Affairs Office) at GCHQ. I suppose I am also posting stuff here to test you
lot....
[EMAIL PROTECTED]
_______________________________________________
Submitted via WebNewsReader of http://www.interbulletin.com
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Idiot Question -- Please Help a Crypto Moron
Date: Sat, 24 Mar 2001 16:49:47 GMT
How does one solve a puzzle like:
SEND
+ MORE
=========
MONEY
The first thing one notes is that M=1 and S=9 are very likely.
Why?
MORE and MONEY both begin with the letters MO. So MONEY is
approximately equal to 10 times MORE. That means SEND must be roughly
equal to 9 times MORE, yet both numbers are four digits long.
E+O might have had one to carry, but since 1 is already assigned to M,
and 9 is already assigned to S, the letter O probably stands for zero.
So we have three letters tentatively solved.
SEND
9
+ MORE
10
-------
MONEY
10
Note that E and N are two different letters, so N+R must equal E with
one to carry. (D+E = Y could leave one to carry as well, of course.)
Let's try R=8, since N goes to E, and then E goes back to N, so R
needs to be as big as possible. We *will* need one to carry from D and
E.
N is one bigger than E. We know this.
D and E have to be big enough to leave something to carry, and Y can't
be either 0 or 1. So the smallest Y can be is 2.
12 is equal to 5 plus 7. Let D=7, E=5, N=6. Will this work?
SEND
9567
+ MORE
1085
-----
MONEY
10652
Well, we've found a solution - and just barely.
John Savard
http://home.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: amateur <[EMAIL PROTECTED]>
Subject: Re: Crack it!
Date: Sat, 24 Mar 2001 12:33:00 -0400
I read it.
I use size block constants.
You are talking about variable size-block.
That was the purpose of your paper.
My system is another form of OTP. With a great advantage. Using and
reusing the same key.
Mok-Kong Shen wrote:
>
> amateur wrote:
> >
> > Try to decrypt it if it is no new idea.
> > Give me explicit reference to substitution of bits not a group of bits.
> > Only one.
> > If it is not new.
> > Give me only one reference concerning send any message via network using
> > M=f(k)
> > You were talking about a group of bits not a single bit.
> > If you interpret the Bible or the Quran or the Vedas you will find the
> > idea of DES encryption.
> > I want a clear reference to be convinced.
> > There is no erroneous claiming.
> > I will send thousands of new ideas you don't even imagine.
>
> Mmmmm, how many times must I ask you to carefully re-read
> the copy of my article posted last year and that I sent
> to you via e-amil ?? The following are part of one paragraph
> and another whole paragraph from that article:
>
> Our substitution to be done on a given bit sequence is then
> performed according to an arbitrary invertible (in general
> one to many, not necessarily surjective) mapping of the
> symbol set of an alphabet of size u to the symbol set of
> another alphabet of size v, both being randomly constructed
> as above, with the constraint 2 <= u < v. .............
>
> Note that an interesting special case is one where u=2,
> while v is chosen arbitrarily large so as to have
> substantial number of homophones and further the mapping
> is also largely non-surjective such that quite a number
> of different dummy output symbols are available for
> arbitrary insertion into the output stream to confound
> the opponent.
>
> Do you understand what is meant by 'mapping of the symbol set
> of an alphabet of size u to the symbol set of another alphabet
> of size v'? Do you understand what is meant by 'the size of an
> alphabet'? Take '0' and '1' as the symbols of the first alphabet
> set, i.e. {0, 1}. So you have u=2. Right? Now for example, take
> {a, b, c, d, e, f, g, h} to be the smybosl of the second symbol
> set. You have thus v=8. One possibility of a homophone mapping
> is then to arbitrarily map symbol '0' of the symbol set of the
> first alphabet to any symbol of the subset {a, b, c} of the
> symbol set of the second alphabet and to map symbol '1' of the
> first symbol set arbitrarily to any symbol of the subset
> {d, e, f, g, h} of the symbol set of the second set. To
> summarize, you have now the mapping:
>
> '0' ---> {a, b, c}
> '1' ---> {d, e, f, g, h}
>
> Now please tell me what have you done up till now differently
> in a large number of posts repeatedly describing your 'idea' !!
>
> Note that I wrote in my article that there could be dummy
> symbols, for example {x, y, z}, in the symbol set of the second
> alphabet, so that you could arbitrarily insert any number of
> these symbols into your ciphertext stream to further confound
> the opponent. The recepient, when decrypting, simply discards
> such dummy symbols. Now doesn't the bit homophone scheme
> mentioned in my old article subsume your bit homophone scheme
> as a special case ??
>
> Now, coming back to what you wrote above: To the point of your
> challenging others to decrypt, I have commented in my follow-up
> of Fri, 23 Mar 2001 21:11:10 +0100. That you idea is NOT new
> should be entirely clear from what I explained above. In other
> words, your claim of novelty of your idea is erroneous. If you
> do have really new ideas, all people of this group, including my
> humble person, certainly should very appreciate to be able to
> know them. (And may therefore Jesus or Mohammed bless you and
> fulfill your above stated wish to acquire and send thousands
> of new ideas that we others of the group don't even imagine.)
> But please post everything succintly and clearly, avoid
> repeating the same stuff over and over, thus wasting bandwidth,
> and spend SOME concrete time and effort to read carefully
> comments and materials of others and try to understand these
> and ask concrete questions in case you don't understand the
> argumentations of others, giving exact pointers to the texts
> which you find difficult to understand or with which you don't
> agree (in that case provide clear counter-arguments).
>
> Hope that this helps.
>
> M. K. Shen
> ---------------------------
> http://home.t-online.de/home/mok-kong.shen
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Hello
Date: Sat, 24 Mar 2001 17:41:25 GMT
Um anyone home?
I posted a question 6hrs ago and no reply.
BTW the NSA broke PGP and B.S works for the commies (that should get a
reply, then while you are flaming me reply to my other question please...)
--
Tom St Denis
---
http://tomstdenis.home.dhs.org
------------------------------
From: amateur <[EMAIL PROTECTED]>
Subject: Re: Crack it!
Date: Sat, 24 Mar 2001 12:47:01 -0400
You have to read carefully what I described.
What is new is using two categories, not a set of symbols.
My idea is specific. I'm talking about bits not two symbols.
Why not choose a set of two like {x;y}? It could be anything.
I choose bits.
If you read carefully you will understand that my system is uncrackable.
It's another form of OTP.
You have to skip the step of Cesar. It was just to complicate the case.
Do you know any algo, if you use it you may assign to every character of
the plain-text a specific symbol and to retrieve it
easily?????????????????
Sample F
"what are you doing " convert to )+#$^&@!(P etc...
I have the way to retrieve all symbols even if every symbol is different
from others without DICTIONARY!!!!
It's a new idea or not?
It exist this algo or this way?
Mok-Kong Shen wrote:
>
> amateur wrote:
> >
> > Try to decrypt it if it is no new idea.
> > Give me explicit reference to substitution of bits not a group of bits.
> > Only one.
> > If it is not new.
> > Give me only one reference concerning send any message via network using
> > M=f(k)
> > You were talking about a group of bits not a single bit.
> > If you interpret the Bible or the Quran or the Vedas you will find the
> > idea of DES encryption.
> > I want a clear reference to be convinced.
> > There is no erroneous claiming.
> > I will send thousands of new ideas you don't even imagine.
>
> Mmmmm, how many times must I ask you to carefully re-read
> the copy of my article posted last year and that I sent
> to you via e-amil ?? The following are part of one paragraph
> and another whole paragraph from that article:
>
> Our substitution to be done on a given bit sequence is then
> performed according to an arbitrary invertible (in general
> one to many, not necessarily surjective) mapping of the
> symbol set of an alphabet of size u to the symbol set of
> another alphabet of size v, both being randomly constructed
> as above, with the constraint 2 <= u < v. .............
>
> Note that an interesting special case is one where u=2,
> while v is chosen arbitrarily large so as to have
> substantial number of homophones and further the mapping
> is also largely non-surjective such that quite a number
> of different dummy output symbols are available for
> arbitrary insertion into the output stream to confound
> the opponent.
>
> Do you understand what is meant by 'mapping of the symbol set
> of an alphabet of size u to the symbol set of another alphabet
> of size v'? Do you understand what is meant by 'the size of an
> alphabet'? Take '0' and '1' as the symbols of the first alphabet
> set, i.e. {0, 1}. So you have u=2. Right? Now for example, take
> {a, b, c, d, e, f, g, h} to be the smybosl of the second symbol
> set. You have thus v=8. One possibility of a homophone mapping
> is then to arbitrarily map symbol '0' of the symbol set of the
> first alphabet to any symbol of the subset {a, b, c} of the
> symbol set of the second alphabet and to map symbol '1' of the
> first symbol set arbitrarily to any symbol of the subset
> {d, e, f, g, h} of the symbol set of the second set. To
> summarize, you have now the mapping:
>
> '0' ---> {a, b, c}
> '1' ---> {d, e, f, g, h}
>
> Now please tell me what have you done up till now differently
> in a large number of posts repeatedly describing your 'idea' !!
>
> Note that I wrote in my article that there could be dummy
> symbols, for example {x, y, z}, in the symbol set of the second
> alphabet, so that you could arbitrarily insert any number of
> these symbols into your ciphertext stream to further confound
> the opponent. The recepient, when decrypting, simply discards
> such dummy symbols. Now doesn't the bit homophone scheme
> mentioned in my old article subsume your bit homophone scheme
> as a special case ??
>
> Now, coming back to what you wrote above: To the point of your
> challenging others to decrypt, I have commented in my follow-up
> of Fri, 23 Mar 2001 21:11:10 +0100. That you idea is NOT new
> should be entirely clear from what I explained above. In other
> words, your claim of novelty of your idea is erroneous. If you
> do have really new ideas, all people of this group, including my
> humble person, certainly should very appreciate to be able to
> know them. (And may therefore Jesus or Mohammed bless you and
> fulfill your above stated wish to acquire and send thousands
> of new ideas that we others of the group don't even imagine.)
> But please post everything succintly and clearly, avoid
> repeating the same stuff over and over, thus wasting bandwidth,
> and spend SOME concrete time and effort to read carefully
> comments and materials of others and try to understand these
> and ask concrete questions in case you don't understand the
> argumentations of others, giving exact pointers to the texts
> which you find difficult to understand or with which you don't
> agree (in that case provide clear counter-arguments).
>
> Hope that this helps.
>
> M. K. Shen
> ---------------------------
> http://home.t-online.de/home/mok-kong.shen
------------------------------
From: [EMAIL PROTECTED] (Bill Unruh)
Crossposted-To: alt.privacy.anon-server,alt.security.pgp
Subject: Re: New PGP Flaw Verified By Phil Zimmerman, Allows Signatures to be Forged
Date: 24 Mar 2001 17:53:57 GMT
In <99av4l$q67$[EMAIL PROTECTED]> Pawel Krawczyk <[EMAIL PROTECTED]> writes:
>In sci.crypt Bob C. <[EMAIL PROTECTED]> wrote:
>> The exploit works by attacking the Digital Signature Algorithm's
>> so-called discrete logarithm problem. DSA keys are typically stored in
>> a file called secring.skr, and Klima and Rosa found that they could
>> successfuly insert a replacement key in it.
>Every day new details leak painfully slow from the ICZ and it's
>still getting closer to another instance of what Bruce Schneier called
>`publicity attack'. First comments from ICZ suggested that the PGP has
>been broken, then that the secret key can be retrieved without knowing
>the passphrase, now we learn that you can substitute private key with
>your own, if you have access to the keyring. What an invention! ;-\
If this is right then the OpenPGP standard is broken. To break a
cryptosystem does not necessarily imply breaking just the algorithm. A
crypto system is the whole system, including the key storage. displaying
a weakness anywhere is a break of the cryptosystem. This is an inherent
weakness in the cryptosystem which allows the private key to be
recovered by an attacker. Itis true that the attacker requires a level
of access to the file holding the key which might be considered greater
than is likely, but certainly not impossible. That is why one encrypts
the private key, because access IS possible. If you contrast this with
the claims that it would take 10^9 years to break RSA, this attack is
one hell of a lot easier than that. So, the OpenPGP standard IS broken.
That it can be fixed I do not doubt, but at present it is broken, if
their claims are right.
PS-- they published their article-- first in Czech -- which it is your
problem if you cannot read-- and now in English. Where are the "details
leak painfully slowly'?
------------------------------
From: "Simon Johnson" <[EMAIL PROTECTED]>
Subject: Re: A new DES?
Date: Sat, 24 Mar 2001 18:04:48 -0800
Ryan M. McConahy <[EMAIL PROTECTED]> wrote in message
news:3abc0b7c$0$88185$[EMAIL PROTECTED]...
> Has anyone (like the people who make modified PGP builds) considered
> implementing DES with a 256 or 512 (paranoid mode) key? This might be
nice,as DES has been so well cryptanalised.
>
> Ryan M. McConahy
Well, yes in theory one could modify the algorithm like that... but even
with independent subkeys, with enough plain-text you can still break the
algorithm with a complexity under 2^56. All known attacks can be thwarted by
increasing the number of rounds to something like 22... leaving the only
solution as brute-force. But after all this modification, is the resultant
cipher still really DES?
Now, the key lengths you propose are a little over the top. A 256-bit key is
never likely to be solved by brute-force and I can say that a 512-bit key
will never be solved by brute-force.... simply because it is physically
impossible.
And after all this, DES is slow in software, although we can be confident
its reasonably secure, we have much faster ciphers which are probably just
as good anyway... Why use a slower cipher?
Simon.
------------------------------
From: [EMAIL PROTECTED] (Bill Unruh)
Subject: Re: Open Source Implementations of PGP
Date: 24 Mar 2001 18:03:56 GMT
In <[EMAIL PROTECTED]> [EMAIL PROTECTED] (Peter
Harrison) writes:
]On Fri, 23 Mar 2001 23:12:10 +0100, "Henrick Hellstrm"
]<[EMAIL PROTECTED]> wrote:
]>"Tony L. Svanstrom" <[EMAIL PROTECTED]> skrev i meddelandet
]>news:[EMAIL PROTECTED]...
]>> Peter Harrison <[EMAIL PROTECTED]> wrote:
]>> Took a look at your pages and... well... it's basically the same as I've
]>> been working on, and... well... messing with PGP will just slow you
]>> down. Do like me and create a good from scratch-solution (BTW, I'll
]>> release this as open source too, when I have the time).
]>
]>
]>I agree. Messing with other peoples code might be educational and perhaps an
]>evil bad if you want your software to be compatible with others. Otherwise
]>it is best to start from scratch.
]I have already written a working implementation of secure email -
]which is at Sourceforge. Its written in Delphi.
]The problem with PGP is that it isn't very well suited for 'dumb
]developers'. By dumb I mean developers like me who want to implement
]a solution incorporating secure email without having to become maths
]professors.
A prime example of someone unclear on the concept. Crypto is different
from other programs. Usually the user can look at the output and tell if
the program has done what it claims to do. In crypto this is most
definitely not the case. There is now way from the output (unless the
implimenter is totally incompetent) whether the implimentation is good
or incompetent and weak. This requires two things-- that the implimenter
be very well versed in the intricacies and potential attacks on a crypto
system (see for example the recent breaking of the OpenPGP standards
done by good people who should have known better), and that the
implimentation be open so it can be checked. To have you, who self
admittedly knows nothing of cryptography, writing a program which he
expects others to use should strike fear in the heart of any potential
user. It is like buying a car from someone who admits to knowing nothing
about stearing and tires, and strength of materials, and saying that the
whole field is much to complicated for someone who just wants to build a
car.
]PGP currently allows too many decisions - ie what algorithms to use,
]key sizes for the various algorithms, and suchlike. Thats nice if you
]know anything about security - but if you just want something to drop
]into your application this isn't so good.
------------------------------
From: Jim Gillogly <[EMAIL PROTECTED]>
Subject: Re: decryprtion help please?
Date: Sat, 24 Mar 2001 10:01:24 -0800
rh wrote:
> ...migrate all of our pins from the current main system to the new test pin
> vault. We have no decryption utility that could do this. Below I have
> Pin Encrypted Pin in SQL DB
>
> 1234 9EE7964577447ADA
> 9999 1F1D2C2ED301B2A6
> test 8A49D1CCB9AA5DBB
> hello 7F85C0A9F3F86EC0
> 4567 60956233056154AC
> 123456 5155482C2078BF2C
> voyager 73C63521A96FF1C9
> ATLAS BFC44BCCC9ED5EE5
If it's an easy transform, you'll have more luck if you pick similar
pins and try to correlate the outputs. For example, you could try
all the 1-character pins, then pins like "aaaaaaaa", "aaaaaaab", and
so on. If you see similarities in the encryption, you're on your way.
It'd be more straightforward to check the source code for the SQL
DB or check with the vendor if the source is unavailable.
--
Jim Gillogly
2 Astron S.R. 2001, 17:57
12.19.8.1.8, 2 Lamat 11 Cumku, First Lord of Night
------------------------------
From: "Mauro" <[EMAIL PROTECTED]>
Subject: Re: cryptography using the method of elliptic curve.
Date: Sat, 24 Mar 2001 18:00:36 +0100
"Sam Simpson" <[EMAIL PROTECTED]> ha scritto nel messaggio
news:X50v6.25411$[EMAIL PROTECTED]...
> With a search engine?
>
> --
> Regards,
>
> Sam
> http://www.scramdisk.clara.net/
>
>
thanks very much for this link.
i'm studing the methods of criptography for my graduation and i'm searching
information in particolary on the method of elliptic curves for example
using the Koblitz curves. I search some links on this argoments.
Bye
Mauro Pace
------------------------------
** 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 by posting to sci.crypt.
End of Cryptography-Digest Digest
******************************
