- cypherpunks-legacy - lists.cpunks.org

Re: Source Code NOT available for ViaCrypt PGP
by norm＠netcom.com 26 Aug '93

26 Aug '93

The proper paranoid must worry whether the licenced PGP does what it is supposed to do. One can compare the output of the ViaCrypt PGP with that of the current version. Discrepencies would merit great suspicion and perhaps disassembly. Improper paranoids might be comforted in the knowledge that many proper paranoids were comparing the two versions. I have not studied the format of the PGP output. Is it possible for the ViaCrypt PGP to interoperate with the current version unless it comforms completely? We must clearly worry about undocumented new formats. Incedently why do the code owners trust the customer to not illegitamitely copy the binary program, but not trust the customer to not illegitamitely copy the source program?

1 0

Re: blinding & PGP
by Karl Lui Barrus 26 Aug '93

26 Aug '93

It occured to me over lunch that PGP IDEA encrypts files; what is RSA encrypted are session keys, hashes, etc. So you never really digitally sign the file itself, you instead digitally sign the portion that contains the session key used, hashes and so forth. Again, I'm sure PGP doesn't blind the RSA portion, so I would say you can't bamboozle someone into signing a blinded document with PGP. Now, as for verifying a commercial version of PGP by comparing encrypts... it all depends on how exactly randseed.bin figures into the session key creation. Two files encrypted with the same public key could compare very differently if the random session keys are different, since the IDEA encryptions would differ and the so would the MD5 hashes, and so forth. I'm not sure if additional info besides the randseed.bin file goes into session key creation. -- /--------------------------------------------------\ | Karl L. Barrus | | klbarrus(a)owlnet.rice.edu | | D1 59 9D 48 72 E9 19 D5 3D F3 93 7E 81 B5 CC 32 | \--------------------------------------------------/

1 0

PROTOCOL: Encrypted open books
by Eric Hughes 26 Aug '93

26 Aug '93

Note: I started this reply last week; I've decided to post what I know, since I don't have a solution and I've run out of simple ideas for now. Hal' criticism that (real) money could leak out of the system is correct. The problem is that while the books would still balance, i.e. sum to zero, some fake depositor would have a negative balance, the net result of taking out more money than you put in. Negative numbers just aren't allowed in double-entry bookkeeping, but they were allowed in the first protocol set. The first part of the solution is to allow no private accounts on the left hand (asset) side of the ledger, in other words, no anonymous loans. A protocol for doing anonymous loans could be invented, but since the first problem is merely to run a money exchange and not more complicated financial services, this is acceptable. Most of the money that left the S&L's was by corrupt loan practices, so I don't consider this omission a particularly glaring one right now. Therefore all the private accounts must be on the right hand side, that is, they are all liabilities. In layman's terms, the bank owes you; should you ask for your money, they have to give it to you. If we can verify that each of these accounts never goes negative, then we can be certain that if the books balance, that the amounts of money in each account are accurate. Consider this. If money was transferred from your account to another one, that transaction shows up in the public encrypted transaction record. If you have due diligence over this record, you can assertain that no transaction was performed against your will. This case corresponds to a debit and credit against two customer accounts, decreasing one and increasing the other. Another way that money might end up in a fake account if it were credited with assets. A debit to an asset increase its value and the credit to the account increases that value. This is the case of a deposit; the bank gets cash (+asset) and credits someone's account (+account). Now if they want to give someone money this way, they have to do so by increasing the assets somehow; in other words, they money has to come from somewhere. It didn't come from any of the customers because they've already verified that. It didn't magically appear from one of the other asset accounts because these are all publically audited. In summary, we need to ensure that all accounts have positive balance. Public accounts can be revealed and seen to be positive. Private accounts need a cryptographic assurance. A private account starts off at zero. This can be publically revealed. Then to the encrypted transaction log and the public cyclic balances we add publication of the private balances in encrypted form that allows us to verify to the blinded balance is positive. This balance is verifiably linked to previous cyclic balances via the transaction log. It is therefore linked all the way back to the beginning balance which was zero. Consider all the transaction triples for which the first element is equal to the private account in question, since the account was opened. Take a product of all of the second elements and a product of all the third elements. It is clear that these products can be calculated inductively from the previous cyclic products and the activity in this cycle. The products on second and third elements are equal to g^( Sum x_i,j,t + Sum r_i,j,t ), h^( Sum r_i,j,t ) where I've added a time index by cycle which was implicit before. The notation for the inductive calculation is different, of course, and also obscures the underlying invariant. What we want is a certificate that Sum x_i,j,t is positive. Here it gets a bit hairy. There are likely other solutions to this technical requirement; here is the one I thought up yesterday and today. I thought I had an idea with promise on how to create such certificates using quadratic residuosity, but it doesn't work. I'm still thinking about it; this certificate doesn't seem impossible to create, but the standard ideas that I know about in algebraic protocol design don't seem to work. If anybody wants to work on this technical point off-line with me, send me mail. The math involved is advanced enough that I'd prefer to post summaries of work rather than all the detailed discussion. Another non-technical attack on the problem is to require periodic bank holidays, where all private balances will be revealed to be zero (preferably), or whatever is actually in the account. This doesn't prevent owner fraud, but does put an upper bound on the time in which to perpetrate it. Eric

1 0

Re: Commercial PGP: Verifying Trustworthiness
by peter honeyman 26 Aug '93

26 Aug '93

> Basically, if both commercial PGP and freeware PGP produce exactly the > same encrypted files as output based on the same keys, and if you have > the source code and can trust freeware PGP, then it can be stated that > commercial PGP is secure. pgp and viacrypt will always generate differnt outputs: pgp adds some pseudo-random stuff to the start of the file it is encrypting to ensure that a file encrypts differently each time. peter

1 0

Commercial PGP: Verifying Trustworthiness
by thug＠phantom.com 26 Aug '93

26 Aug '93

Here's a real simple way to verify the trustworthiness of the commercial version of PGP. It's a bidirectional comparison of outputs. 1) Have freeware PGP generate a set of keys. 2) Using keys from (1) encrypt several files using both conventional and public key encryption using freeware PGP _and_ commercial PGP, then compare the output byte-for-byte of both to see if they match up. 3) Have commercial PGP generate a set of keys. 4) Using keys from (3) encrypt several files using both conventional and public key encryption using freeware PGP _and_ commercial PGP, then compare the output byte-for-byte of both to see if they match up. Basically, if both commercial PGP and freeware PGP produce exactly the same encrypted files as output based on the same keys, and if you have the source code and can trust freeware PGP, then it can be stated that commercial PGP is secure. I'm no expert on mathematical proofs, but the above seems very logical to me. I'm assuming the NSA will pressure ViaCrypt to put in a backdoor. One possible backdoor that can be placed inside the commercial PGP and still allow it to pass the above test is if commericial PGP secretly writes all keys and pass phrases to a block on your hard disk, and marks that block as used to the file system. In order to prevent you from scanning your hard disk and finding that block, the information stored there could be encrypted by a key which the NSA has in it's possession. I would never use commercial PGP because I do not place inherent trust in programs which come with no source code, and commercial PGP doesn't come with source code. Thug

1 0

No Subject
by bryan＠fegmania.wustl.edu 26 Aug '93

26 Aug '93

subscribe bryan@fegmania

1 0

Re: blinding message & newbie questions
by Karl Lui Barrus 26 Aug '93

26 Aug '93

-----BEGIN PGP SIGNED MESSAGE----- [I think I messed up when I responded originally ... KLB] Sure, I'll take questions :-) I may be a little slow in responding at the moment. >> Conceptually, when you blind a message, nobody else can read it. >So "blinding" is a synonym for encryption with your own public >key, aka multiplication by a very-hard-to-factor number? Not exactly. Blinding/Unblinding is multiplication; Encryption/Decryption is exponentiation. While I can unblind a document without knowing phi(n), I cannot decrypt a message without knowing phi(n). Knowing phi(n) is equivalent to knowing how n factors, so this is intractable. phi(n) = Euler totient function. >> under the right circumstances if another >> party digitally signs a blinded message, the unblinded message will >> contain a valid digital signature. >In other words if Alice encrypts and Bob signs, Da(Db(Ea(M))) = Db(M)? >Under what conditions? Does RSA (in PGP) satisfy those conditions? The conditions are usually satisfied. Offhand, the only one I can think of is that x and n must be relatively prime, otherwise there is no inverse of x mod n. With really huge numbers, the chances of guessing x such that gcd(x,n) != 1 are very small. If this does happen, then you've guessed x such that x is a multiple of one of the factors of n! Time for somebody to pick a new p,q, and n :-) As far as PGP, I think the only messages PGP produces are exponentiated. I mean, PGP doesn't produces messages obscured only by a muliplication factor; the ascii snow messages PGP generates are encrypted, signed, compressed, or all of the above. So this doesn't arise. >> If someone asks >> you to digitally sign a random stream of symbols, remember that what you >> sign may be unblinded to reveal a contract, etc. >For what applications would Bob want to sign an encrypted contract >instead of a plaintext? Let me get back on this. I beleive the general name these sorts of protocols go under is "embassy protocols". They are useful in things such a digital cash: blind a message, and get the bank to sign it. Then unblind and you have a valid, digitally signed piece of cash. The bank is unable to track it since it couldn't read it (message was blinded when the bank signed), but the bank can verify that the cash is digitally signed by them. It also arises in automatic protocols: say in computer security. If the computer sends a challenge string which you decrypt and send back, the computer can encrypt with your public key to verify you. If the challenge string is random, you may have unwittingly digitally signed a blinded document that is not in your favor... The cut-and-choose protocol allows a person to sign a blinded document and be sure they aren't signing something else. I'll get back on this as well. /--------------------------------------------------\ | Karl L. Barrus | | klbarrus(a)owlnet.rice.edu | | D1 59 9D 48 72 E9 19 D5 3D F3 93 7E 81 B5 CC 32 | \--------------------------------------------------/ -----BEGIN PGP SIGNATURE----- Version: 2.3a iQCVAgUBLHzwP4OA7OpLWtYzAQEyuQP/Vrc5tB5TfbDc0/FRWN9uALdSZk/JZNwX UYmFfKHQzhYdqJkoOrDE+MMHbJaGuZkuSnYUbIEAFvos6SRPI9doRAvyWnKjQKfp 9h04BMGrB3IoHPBqK59CbH+jNtNc3hYgWw4zSpaFo3+1aEPM+WUHQ2plO2KjJSJg 2M272Y2Y3IE= =tHuX -----END PGP SIGNATURE-----

1 0

Re: Source Code NOT available for ViaCrypt PGP
by James Still 26 Aug '93

26 Aug '93

Carl wrote: >> I think he's trying to run ahead of Clipper and the resulting encryption >ban. >> Make a lot of $$$ from people by selling them soon-to-be-"useless" software. >> What a scam... > >Is anyone taking bets on encryption bans? [...] >If each user of RIPEM or PGP would get one newcomer to start using it >every month, for example, it would take less than 18 months to get the >whole US covered. Are there any volunteers among the Windows guru/programmer's here to kick out a shell that supports PGP? 2.3a is *much* more stable than 2.2 (and runs great from within PGPShell .PIF'd from Windows.) IMHO only a fraction of Carl's newcomers will even take a second look at PGP unless there's an interface for it. Our privacy shtick falls short on the masses that don't understand our zealotry or the need to protect their own privacy. They want it to be *fun* and could care less about the conspiracies involved. First you get the teeming millions to enjoy what they're doing (see? encryption is fun kids!) and more importantly, feel very comfortable using encryption tools. That way if the fateful day of encryption bans does come, these tools will be as hard to take away from them as from a Texan who first learns to shoot his father's gun. ---- still(a)kailua.colorado.edu -------------------------------------

1 0

Re: Source Code NOT available for ViaCrypt PGP
by mbriceno＠aol.com 26 Aug '93

26 Aug '93

Simon Trask writes: > A) No source code will be available, due to the nature of the > agreement between PKP and ViaCrypt. So we are supposed to trust it sight unseen? Why in the world would anyone buy an encryption program of questionable security --which any program for we can not get the source is-- when we can get a supposedy virtually identical program that we know is secure for free? > B) He is under 'a lot' of pressure to have a product 'on the shelves > in under two months', and therefore the first release will be a > MS-DOS version, then Macintosh, SVR4, SUN OS, and all of those unix > versions, and that they will eventualy put out a windows product and > start makeing improvements to the actual product. I can't help but wonder if the guy is feeling other pressures besides time pressures. Just thinking. I don't think that ViaCrypt will make much money of the people on this list. --Marc

3 2

Source Code NOT available for ViaCrypt PGP
by Christian D. Odhner 26 Aug '93

26 Aug '93

I talked once again with Dave Barnheart at ViaCrypt, and he told me: A) No source code will be available, due to the nature of the agreement between PKP and ViaCrypt. B) He is under 'a lot' of pressure to have a product 'on the shelves in under two months', and therefore the first release will be a MS-DOS version, then Macintosh, SVR4, SUN OS, and all of those unix versions, and that they will eventualy put out a windows product and start makeing improvements to the actual product. So in answer to (Paul Goggin's?) questions about verification of changes, "We'll Just Have To Trust Them(tm)" <g> But look on the bright side... This will blow David Sternlight out of the water! Happy Hunting, -Simon Trask <cdodhner(a)indirect.com> PGP public key available upon request.

3 2