Encryption for Mere Mortals

Welcome to the Precious Metals Bug Forums

Welcome to the PMBug forums - a watering hole for folks interested in gold, silver, precious metals, sound money, investing, market and economic news, central bank monetary policies, politics and more. You can visit the forum page to see the list of forum nodes (categories/rooms) for topics.

Please have a look around and if you like what you see, please consider registering an account and joining the discussions. When you register an account and log in, you may enjoy additional benefits including no ads, market data/charts, access to trade/barter with the community and much more. Registering an account is free - you have nothing to lose!

DoChenRollingBearing

Yellow Jacket
Messages
1,271
Reaction score
3
Points
0
Location
SE USA
...

OK, DCFusor will not be impressed, but there are LOTS of fairly tricky ways of encrypting data (emails and sales data for example) that would stand up to almost anything except skilled cryptologists with good computers. Here is some SQL coding (for MS Access, oh, sorry again DCFusor (does not like Access)), your SQL will vary if you use other SQL databases (like Oracle, MySQL, etc.):

SELECT DISTINCTROW (((Right(([df_2].RUC),2) Mod 2) + 1) * 10) & (Right(Left((([df_2].RUC) * 599),11),10)) AS Cust_ID, (Right(Left(([df_2].Cliente),4),1)) & (Left(Right(([df_2].Cliente),3),1)) & (Left(Right(([df_2].Cliente),2),1)) & (Right(Left(([df_2].Cliente),4),1)) AS Customer, Sum([df_2].Cant) AS Sum_of_Qty, Sum(CCur([Cant]*[VUnit]*((100-[Dscto])/100))) AS Expr9
FROM df_2
WHERE RIGHT(([df_2].Fecha),2) = "13"
GROUP BY [df_2].Cliente, [df_2].RUC;

That nasty-looking coding cannot be explained very easily, but there are some cool functions (prime number 599 (although that is NOT the real number), a Modular function and manipulating text around to hide customer names (this last is rather weak though) in there that I use to protect the real data.

Here are two rows of output (ahh, well that did not format well in my Cut & Paste...), first are the field names, then the columns. Note that customer "DEMA S.A." is identified here (and so has six items of text here, that period/dot in "position two" is derived from the above SQL and is deliberate).

Cust_ID
Customer
Expr9
RUC
Cliente
Expr9

201149974507
T E
$3,408.61

100347361191
.
$3,306.45
20101177042
DEMA S.A.
$3,306.45


More details at my new blog piece (as I know the above is "Pure Greek"):

http://tinyurl.com/kkdath3
 
Assuming all you want is a list of amounts of sales and attached client IDs:

If you have 'n' clients, randomly assign a unique integer, perhaps called client #, between 1 and 'n' to each client.

Next, only display the client # and amount of sales.
:cheers:
 
or simply written in a hurry using a quill pen and ink ......

no government decoding machine or spotty techie could unravel it :pffftt:
 
More details at my new blog piece (as I know the above is "Pure Greek"):

Not Greek to me since I have been programming computers for over 30 years, years before IBM invented the PC and years before Bill Gates invented his DOS and Windows trash.

That said, I have done many "impossible" things that others said could not be done with a computer. One that comes to mind is that I wrote a complete database program (in Basic) where the whole program resided in 16k of memory (no paging code in and out of memory) while the data resided on dozens and dozens of 5-1/4" discs. I ran my business for years using it and published dozens of in-house books using the same program. Still works, but having the data scattered over dozens of 5-1/4" discs is a real pain to work with, so for the last ten years I have been slowly migrating everything to more modern machines.
 
Back
Top Bottom