Warning; this is serious Unwired stuff. If you think hacking has too much minutiae, it might bore you.

Everything a hacker does in a node shows up on its access log. Access logs are updated every [System] rounds. Therefore, for my hacking to remain undetected for longer than that, I need to be able to Edit the log within 6 rounds.

Access logs can be encrypted. Strong encryption can require up 24 hours MINIMUM to break. Therefore, I cannot decrypt a strongly-encrypted access log before the spider sees my intrusion in the log.

Encrypting an access log requires a dedicated Encrypt program which cannot have IC or data bombs attached to it. Once that program is deactivated or crashes, the access log is unencrypted. Therefore, it's possible to crash or deactivate the Encrypt program to gain access to the access log rather than Decrypting it.

Since I will assume that any node paranoid enough to use strong encryption will also have a routine triggering an alert if an admin tries to deactivate the encryption without using the key, I assume the best way to gain access to the access log is to crash the Encrypt program. However, the security spider will undoubtedly check the Encrypt program every so often to see if it has crashed (although he will also be busy doing things like checking the access logs). Therefore, I must make sure that the security spider sees what he expects to see when he Analyzes the Encrypt program.

If I got a good look at the Encrypt program beforehand, I could Edit an Encrypt program of my own so that it appeared to be the same program [is this correct?] If I snuck a trojan into the target node, I could instruct the trojan to Analyze the Encrypt program and send me the details. Therefore, to fool the security spider, I must slip a trojan into the target node and Edit an Encrypt program so that he sees what he expects to see.

If I crash the access log's Encrypt program and, on the next action, run my own Edited Encrypt program, the security spider will have a very small chance of noticing the switch (he'll only notice if he A. can detect my faked Encrypt program or B. is actively watching the Encrypt program while I switch them). The access log will then be open to me to Edit, and I will remove all traces of the above trickery. Therefore, I will be in the node will access to the access log and able to do whatever I want.

Is this a viable model of how I would go about breaking into a node with a strongly encrypted access log and hiding my presence? Have I overlooked something, either a way to do this more easily or something which will prevent it from working?

Thank you for your time and help!

I'm not sure it's possible to be honest, you could presumably run a dummy program that appears tob e the encrption program but the moment the admin tries to read the log the jig is up seeing as you'd need to break the decription in the first place in order to properly simulate the encryption. Then aagian I can't find my copy of unwired right now and I've found the encryption rules to be wonky at best. Ecrption in shadowrun can be realistic or it can be playable, it can't do both.

You're right; my Encrypt program wouldn't actually be able to provide the same level of encryption that the original did. But it doesn't need to. What if I programmed it so that, no matter what password you gave it, it accepted it as if it were the right password?

Think of it this way. My laptop is encrypted, because in order to access my account I need to put in a password. Let's pretend the password is "shadowrun." If I type in "shadowrun" I get access, if I type in anything else I get rejected. Imagine if someone broke into my laptop, crashed the encryption, and replaced the screen where I entered my password with a graphically identical screen? The only difference is that, with this fake screen, no matter what password I enter, I'll get access. I would never notice unless, for some reason, I intentionally entered an incorrect password.

Besides, in the long term it would be unimportant how convincing the fake Encrypt program is, because as soon as I'm getting ready to leave the node, I'll erase all trace of my fake program and run the real one again. Break the lock to the basement, put a fake one on, open the fake one, get the goods, and put the real lock back on.

But thank you for reading my post and pointing out that challenge! And I agree; if encryption were realistic, it wouldn't be fun. That's why Unwired tried to present options like "strong" encryption that make it more challenging, but still possible. I'm not saying it was successful, but it sure tried.

That might work i'm not sure, i can't find my copy of unwired and it's infuriating myself and my technomancer player. I had presumed perhaps very incorrectly that an authorized user isn't decrypting it through the program but through the key they already have access to. Which is where i presumed the problem comes up.

I'm presuming your going from the point of doing a silent hack with no trace. if your only worried about the short term why not just tag the log with the evilest databomb you can get your hands on? Something with the blackout option.

I just have to say, I love how crashing an encryption program in ShadowRun makes every file it's encrypting unencrypted.

It's like having a puzzle in a box and somehow dumping out all the pieces and burning the box solves the puzzle.

Yep ain't it grand?

Well, I'm not sure crashing the Encrypt program ALWAYS unencrypts the files in question; that rule might only apply to access logs, which need to be continuously encrypted.

That is indeed how I read the ruling. Mainly because it actually appears in the bit about encrypting the Access Log specifically IIRC. Plus I do not think any other Encrypt action actually requires the Encrypt to be working autonomously on the Node so I cannot see any other time it would come up. (i.e its not that killing the encrypt program kills the encryption, more like the Access Log needs to be re-encrypted ever few rounds because its constantly changing and the encryption program is no longer there to do it.)

Possibly. I could see it making sense, but I think there's still a way to keep the logs encrypted.

In any case, it was an amusing observation more than anything.

Exactly. And if I work fast enough, I can unencrypt the log, insert my own "Encrypt" and hide the bodies before they float downstream (i.e. before it shows up on the log).

In modern computing we already have automated monitoring of critical processes. There's services now (Nagios as an example) that can be setup to monitor the state of a process and send an alert out if it goes down. A spider would not be manually checking whether the process is up or down, but would rely on a monitoring software to do it for him, and then check to make sure that is running properly. Your 24 hour assessment to break strong encryption is VERY VERY generous.

If the access logs are being written to every X rounds, that must mean that the accesses made must be stored in memory somewhere prior to being written to log.

Data in motion is the hardest to protect.

Instead of trying to modify the logs themselves, why not locate and modify the memory housing the transactions that need to be made? Remove the transactions from the buffer where they are likely to be less protected. I don't know if this is actually doable, within the system, but that's how I would do it.

Now if you were to crash the encrypt program, that would make a transaction that the encrypt program crashed. Inserting your own encrypt program and running that would create a transaction. Now you could go back and edit those two, but once you close down the encrypt and re-run the original that will be two more transactions that you have no control over. Encrypting data is a fairly "dumb" process and it would be unusual to see the process going down/up.

Edit- This just came to mind. There's a few other problems with putting in a false program. If the entire log is encrypted that means the encryption program decrypts the log then adds the records, or adds the records using the proper key value. If you put a substitute program in there are problems with either method. If the transaction log is decrypted to allow writes to it, then your program will be unable to decrypt the log in order to write to it. If each transaction is written to log using the encryption key, then all the transactions that are written with your program will have a different encryption key than the rest of the log, which means there will be a huge block of transactions that cannot be decrypted. For your bait and switch method, you have to know the following things for it to be undetected. The first is what algorithm they're using for encryption. The second is whether their encryption program houses the encryption key, or if each application that writes to the log sends the key to use. Unfortunately for you, it's most likely the former. That would mean you have one software to change the key on rather than multiple pieces of software in case of key changes. However if each transaction contains a key to use for it, then as long as you know the algorithm, you're in a better position. The third part is whether their encryption program decrypts the log to write to it, or just writes each transaction encrypted to a log file. If it decrypts the log to write, you're SOL. So basically, you need to know the algorithm, every software that writes to log passes the key, and the individual transactions in the log are encrypted rather than the entire transaction log being encrypted.

Aside. You said you have [System] rounds before a transaction is written. I thought a higher system value was indicative of a better node. So if you have more rounds with a high system, that means that it takes longer for a better system to write it's logs than a worse system? I would say [System] - [Response] to be a better indicator of how long it takes a transaction to be written, since that would be indicative of the load of programs that would be generating log notes to be written and reflect system sluggishness in writing said log notes. So a System 6 node running 18 programs would have a response of 3, meaning it would take 3 rounds for the transactions to be written to file.

A higher system means that it can do more and inversely has more to do when starting up or writing a log. The way it's written basically acts as a slight failure to an otherwise clear advantage of having a more powerful system. Doesn't make clear real world sense, but then we've determined that the real world is boring or else we'd have more fun at work.

For the encryption issue, I see too many problems with trying to sub in your own encryption. For one thing it wouldn't be able to offer 24 hour encryption without taking the log down for 24 hours to re-encrypt it that way. Even if you have it start using normal encryption someone is going to find that out as soon as they check the logs at some point and know that they have been tampered with as surely as if someone changed every entry to list the Smiling Bandit as admin.

You really want to spoof the logs, as SealthSigma pointed out above, but you can't without knowing the encryption key. If you can get the key that was generated by the encryption program after running on the log for 24 hours, you can start making edits directly while the encryption does it's thing. Since you don't have 24 hours to run decrypt before the logs show that you've been there you have a few options.

The first one would be to find the key somewhere else and acquire it first. The admin that setup the encryption program would have that key, or else he wouldn't be able to interact with the log. He might have deleted it to keep it safe, but I doubt that considering that would mean he would have to decrypt his own system for 24 hours to check the log. So we can be reasonably sure that he has it, find him somewhere on the matrix and you can get it whatever way you want. Triggering a security event may bring him if he's the spider as well.

Second option along those same lines is the cheapest option available and requires you to be on good terms with your GM. Do a Resonance Realm search through the Archive and effectively pull the key out of your ass. Not as flashy, better saved for a last try/life or death situation, but I don't know your situation. The GM might out right resist this one and throw plot at you, and he's within his rights to. I know a Pc would have to bring me a pretty solid reason if he was planning on doing things this way.

Option 3 is a bit drawn out. Lets assume that unless a spider has a reason to check the logs, they only do so once every day. I know in my job that's how things work, I check the firewall logs once a day. Glance through, look for anything wierd and normally everything is fine. System admins are methodical people (so I'm accused of), and tend to do this in a certain order and at a certain time, but real life gets in the way. If you could find some way to get into a system just after the admin reads the logs, start a 24 hour decrypt and then the next day engineer some reason that the admin is an hour or so late checking the logs, you'll have bought yourself the time needed to get in and erase all signs of your presence over the last 25 hours. At that point the system is yours and no one is the wiser.

Wow. The degree to which you're more familiar than I am with real-life computing is kinda intimidating, but I appreciate your perspective.

There are a lot of differences between how real-world computer security works and how it works in Shadowrun. The reason for this, far as I can tell, is game balance; the players need to have a chance of succeeding at tasks appropriate for their power level, but still be challenged when doing so. I suspect that this is the reasoning behind the following:

Access logs are at most updated [System] rounds because (fluffy reason) a higher System rating indicates a higher volume of transactions, leading to a larger delay in processing them and (game balance reason) a higher System rating indicates that the node will be better protected, so an intruding hacker needs more time in order to crack it.

You can't attach data bombs or task IC (and your example, Nagios, would be a form of IC) onto a continually-encrypted access log. Fluff reason: too much changing data. Crunch reason: otherwise, you don't stand much of a chance of getting in quietly for more than a few rounds.

Now, with regards to your "alter the buffer" suggestion, I think that the term "access log" refers to two distinct but connected features; there's the buffer where raw data describing every action taken on the node is sent. Then, [System] rounds after that, the actions are processed and published in the log, where, among other things, the spider can read them. I agree that it's vital to make my alterations while the data is still in the buffer, but I think, for the purposes of breaking in, the buffer and the log it prints to are one and the same.

You're right that my 24 hour assessment of encryption is very generous; I'm just working off Unwired's "strong" encryption rules, which state that if the encryptor takes 24 hours to strengthen the encryption, then the interval for Decrypt tests becomes 24 hours, so even if I broke it on the first try it'd take 24 hours.

As for the paragraph that begins "Edit-" I'll be honest, a lot of that flew by me without my understanding it. Do you think there's some way you could summarize it a bit? Perhaps in the context of SR matrix rules, although I could never ask you to slog through Unwired. I don't hate you, after all.

And otakusensei: I also appreciate your comments, but I'm on my way out the door. I'll try to address them when I get home.

I don't understand what you mean by attaching task IC in this case. You can have an agent (same thing) operating in the node that you instruct to notify you if the encryption program goes down. That isn't attaching anything to anything, just another level of protection that you as a hacker need to be aware of.

The "Edit-" section of StealthSigna's post is mostly real world encryption stuff that is sort of consumed and regurgitated by Shadowrun matrix rules. The business with keys are basically handled in a straight forward manner. The program knows it, the target of the encryption know s it, the user that started the program knows the key and can share it with who ever they want. Otherwise Decrypt wouldn't be a hacker program. In this case things are pretty simple, but diverge from real world tech and encryption best practices almost completely. The only reasoning I can give is that in SR all methods of encoding are equal to all methods of decoding, so on the whole humanity has given up on the more arcane aspects of protection; finding them relatively fruitless if the hackers find a way around it just as fast. Perhaps I have it wrong and the cat and mouse game is going on constantly, the game summing it up by having the hackers meet the security specialists at every turn. Maybe that's just too depressing for me as an admin and in that situation I'd rather sit back and say "Have the damn file, it's 11 hours old anyway."

Bits about buffers are pretty easy to work with. It's all Spoof, don't let it get too complicated or your GM will give you that look and the hack will be over before it starts.

You're on the right track about going off strong encryption being serious business. It would be used to protect the really important long term stuff. But in the same vein it has to be used sparingly and only on the little used information because it takes so long to setup. It takes a node offline for 24 hours to encrypt it with 24 hour encryption, and another 24 hours to do the log (unless you want to run with an unencrypted log during that time, I suppose). You can;t do that for your small offcie security node because one lucky hacker with a Crash utility will bring you down for 24 hours. You also take away one of your security teams best options in case of trouble, restarting the system. It's a trade off that you can work around, but it is not the end all be all of security if you see security as a multilayer thing and not just a matrix action.

Course that's a system admin talking. I fully expect my users to be the worst thing that will ever happen to my systems. Your GM can run it anyway they think it works for the feel of their game.

I understand that, but I also think it silly that a System 6 node running NOTHING on it still takes 18 seconds to write to the log. That's why I believe [System] - [Response] is more accurate. It's going to be harder to crack a dedicated system than a system that handles multiple tasks.



I haven't studied the Matrix rules at all, I'm just expressing the logical method of how the system would work in a real example, not one for a balance, however I will try to simplify it.

Encryption is a combination of key and algorithm. There are multiple different encryption algorithms, though some are considered better than others. The key is used to prime the algorithm to encrypt/decrypt the data.

So the first thing I listed was that you need to know the algorithm to substitute an encryption program. If you use a different algorithm their real program will be unable to decrypt the data.

The second thing I listed was that you need to know if the encryption program is passed the key or not. If it's not passed the key, that means the program has the key hardcoded into it. If the key is passed, and you know the algorithm they use, then you can spoof the encryption program with your own that is designed to either drop your transactions, or go back later and remove them. If the key isn't passed, the best thing you could do is set up two sniffers to record transactions that are passed to the encryption program, and the results that come out of the program and run those sniffers for awhile. You may be able to reverse engineer the key with that data.

The third thing I listed was how the transaction log is stored. There's going to be two basic methods, the first is that the entire transaction log is encrypted, meaning it must be decrypted each time it's written to. The second option is that the log is a plain text file and each transaction is an encrypted line. If the entire log file is encrypted, then you MUST know the original key in order to spoof the encryption program, otherwise your spoof won't be able to write to the transaction log. If each record is encrypted then written, you would be better off since your program can write to the log, but when the spider goes to look at the log all the transactions made during the time your program was running cannot be decrypted by the key the spider will use.

Basically, encryption pretty much halts any instantaneous access for a hacker. They have to spend a lot of time cracking the encryption. So if you need to do something on the fly and encryption is in your way, you're better off working around it, either by attacking the buffer as I suggested, or planting a sniffer between the buffer and encryption program that specifically drops the transactions you cause while passing the normal transactions to the encryption program. There may be other solutions you could use, but I can't think of any off hand.

Side Note: Cryptography/Computer Forensics is the field I've been trying to get into, in fact I had intended to try to join the FBI as a special agent to get access to working in their forensics department. Gave that up since I don't have the physical ability to become an agent. This doesn't mean I'm an expert, it just means it's something I've taken a hobby interest in understanding.

Otaku: I've covered this in another thread, but encryption is one of the areas where the defense is not catching up to the offense. In most real world examples it's the other way around. It's just physically impossible to brute force encryption, the amount of computing resources necessary to do so is tremendous. If I have a 256bit encrypted file that you find, the odds that you would be able to crack it are near 0. The way you crack the encryption is by exploiting flaws in the algorithm to find the key. This is what I'm assuming Shadowrun means when you have a 24 hour interval to crack strong encryption.

I'm with you on real world encryption, that's just not how it works in the game. If it did we'd all be street sams.

Nah, I think the usage of the term break and exploit are too diluted. You can't break encryption, nor can you exploit an encrypted file. What you can do is take the algorithm and attempt to find an exploit in it that will allow you to decrypt a file you don't know the key to, or finding an exploit that allows you to determine the key quicker than brute forcing.

To be honest, Sensei, I don't understand it either, so I'll quote it at you.

How do you bundle something with IC? I've never heard that before. All I can think of it meaning is "alterations of the Encrypt program cannot be used as a trigger to activate/alert IC," because what else would it mean? I guess you can have an Analyze program running on it constantly, but it's possible to slip something by an Analyze program. Right?

And as far as That Look goes, I know it's important to balance how awesome I find cracking into high-security nodes and how many people will throw things at me 'cause they're bored.

Wouldn't 24-hour strong encryption on the access node mean that every entry takes a full 24 hours to encrypt as well? That's a pretty glaring security hole in regards to an access log valuable enough to bother encrypting.

Let me put my thoughts on hacking in Shadowrun this way.

I think the game designers crafted a system that is meant to be easier for a non-admin level of real life computer user to play/use. Even though the rules themselves are unnecessarily complicated. Basically, you're trying to condense a knowledge which is rare in the real world into a fashion that those who have no exposure to it can understand. People have their conceptions of hacking based on movies and literature, which are frequently just made up BS. Take the movie Swordfish for example. Hugh Jackson's character is some super hacker, all they need to do is put in some techy sounding lines and bam, hacker. I have to shut down my comp admin mind while listening to those parts otherwise my brain starts to hurt as the stuff stops making sense. Anyway, I don't think the rules are the way they are for balance as much as opening up the hacker archetype to more potential players by trying to simplify what is a complex skill and knowledge into terms they comprehend.




Encrypting/decrypting is a very fast process if you have the key. My work laptop has a 5GB file on it's drive that I mount as new disk drive when I decrypt it for access. It takes virtually no time to copy a file from my main hard disk to the encrypted drive. That 24 hour interval would be used for a hacker attempting to discover what my key is using various methods.

Thank you for your thoughts, both of you.

Can I say that, so far, we've arrived at the following conclusions?

1. SR hacking is not only simpler than RL hacking, but has changed several fundamental factors to facilitate play.

2. Matrix rules are sufficiently abstract that the level of difficulty and (especially) detail involved has to be decided between (the) hacker(s) and his/her/their GM on the basis of what's dramatically appropriate and what the rest of the group will tolerate.

3. My example given above is ONE viable way a break-in could work, but it could be changed to work faster, more detailed or even just differently.

You can embed a program with a data bomb or IC, I think that's what it's referring to. Because that action changes the file to include the data bomb or the IC program it's incompatible with with a file ungoing constant change and encryption. At least, it makes sense if you think of it that way.

It also means that while you can't have attack IC jump out of the log like a can of worms, you can have already active IC alert someone if Encrypt crashes. The difference is that running the IC takes up resources all the time.

Toobox - It means that if you want to exploit your way into the node you need to run a sucessful Decrypt with an interval of 24 hours before hand. It's a stalling method, not a show stopper. It also doesn;t hit the logs neccessarily because you aren't making an Exploit test so the firewall doesn't roll. A lesson to all Shadowrun admins, 24 hour encryption on a node only means you have to make yourself ready for the most stalwart of hackers.

StealthSigma - Check the rules, you're right that you can't break encryption or exploit it. The Exploit action and it's program are for finding holes in firewalls and gaining access to nodes you aren't normally allowed in. The Decrypt program is basically a Cryptomonicon and Crytoanalyst in a box with a skill up to it's rating. You sort of point it where it needs to go and direct it as best you can tell and it uses the latest tricks to try to over come the protections on files. Shadowrun is assuming that the art of code breaking has reached step with the art of finding ways to obfuscate things. It's hard to swallow in the real world, but it makes for some fun gaming.

1. Absolutely

2. Matrix rules are representational, not absolute. Gms should be careful to allow player too much flexiblity in coming up with matrix tricks, as many of the tricks are assumed to be integrated into the mechanics and simply not stated. However, yes, you should do whatever makes the game fun for you and your players.

3. It would work, to a point. If you're happy with that point then rock out.

I'm not arguing with you on real-world encryption, but remember that the whole encryption/decryption dynamic is vastly different in the sixth world, largely due to playability requirements. It's to be assumed that strong encryption is not the type of encryption we're familiar with irl, or everyone would always use it. According to RAW:

Emphasis mine. Strong encryption takes a hell of a long time to use as well as to break. If encrypting an access log requires an Encrypt program dedicated to the purpose, it's obviously not just a one-shot deal. Therefore, every time it encrypts something new in the log - presumably every entry - it should take 24 hours (or whatever interval the admin has set) to do so.

A generous GM would interpret that as just a constant 24-hour window where any given log entry is stored as plaintext (so the last 24 hours of activity are unencrypted but everything older is secure), but a stricter GM could say that each individual entry demands the Encrypt program's full attention for 24 hours. Under this reading, if the access log gets more than one new entry per day it's quickly going to fall behind and accumulate a huge backlog of unencrypted entries.

Not quite sure what you're getting at here. My posts are strictly addressing the OP's proposed scenario of strong encryption on the access log itself. I know how strong encryption works in terms of breaking it; my point is just that the time requirement applies to using it as well.

According to page 224...



What you read is decrypting with the key. I think I could probably encrypt Mirage in about 24 hours....

I was referring to your mention of 24 hour encryption at the node level and how that effects accessing said node.

As for encryption of the log in real time, I believe that having the dedicated Encrypt program running on the log means that the log is encrypted in real time. If a GM wanted to have the logs in plain text for 24 hours then the Encrypt would only have to run once for each peroid they wanted the log encrypted for. Think of it more like signal encryption, where it's running constantly encrypting on the fly. The only difference is that you can't use 24 hour encryption with signals, the fluff reason most likely because you are communicating between two nodes. Game reason because you'd never be able to spoof or break communications without taking a node offline.

Nrr. No. What you just quoted is the rules for standard encryption, not strong. Re-read my quote and keep in mind what it is that actually determines the interval for decryption of strong encryption - it's the time taken to encrypt the thing in the first place. This is shown in the second bit I bolded in my Unwired quote above.

Oh, whoops. My bad - I mistyped "access log" as "access node." I meant to be talking about the log itself.


That sounds reasonable, but I still think my reading does as well.

Agreed. Depends on how much of a bastard the GM wants to be.

Yeah, but also which side suffers - you could easily say that allowing realtime strong encryption for access logs is a higher level of bastardry than not, from the hacker's perspective. From the POV of someone trying to protect their data, though...

It serves both sides equally, since the hacker can use the same strong encryption to protect his node/data.

I honestly have no idea why they are referring to cryptanalysis as a method of encryption. That literally defies the basic construction of the word, regardless of any specific definition in the English language.

I've come to the conclusion that their hacking is significantly abstracted to make it a low barrier to players playing it, while still allowing it to "feel" right to non-technical players.

Oh, I know. I meant that depending on what the PCs happen to be doing at the time, either allowing or disallowing realtime strong encryption on access logs could result in the GM being called a bastard.


Agreed. Cryptography:encryption::cryptanalysis:decryption. The terms aren't interchangeable.

One possible interpertation: Strong Encryption is not allowed for Signals Encrpytion, presumably because encrypting a signal involves real-time data processing. Access logs have their own restrictions (no bundling IC or Data Bombs) explicitly because the data is changing in real time. While the book never specifically states it, at my table, I've treated Access Log Encryption as a special case of Signals Encryption.

I mean, the methods presented by you wond'rous people make perfect sense. I'm only going to share how I initially saw strong encryption working on an access log.

What I figured would be that it would take 24 hours to generate the algorithm (or what-have-you) for the access log, after which all of the information entering the log would be encrypted in real-time.

I figure giving hackers 24 hours before the access log updates is really too generous.

Logically they way you do an encrypted access log is by having the process write blocks of encrypted data to a text file. All records are the same size, with zero fill to the block size, with a time stamp and serial number to pick up deletion of records.

However if you own the box you own the log crypto process, which includes the crypto variables it needs to start up again. So you edit the last 20 seconds out of the log and forge your own records with serial numbers and time stamps, as the process has to keep track of these internally and you can pull them out the process space. This works even if it's writing the log as a one-way function (the host can't decode the logs).

Having full system rights on a box is really powerful, though you'd have to have experimented to build the scripts to do this kind of stuff fast and reliably.

Having the host write the logs in real time to a logging system is the best defense against this.

No, if each record is written as an encrypted block to a plain text file you do not want to make each record an identical length. That's -very- bad because it establishes patterns that make cryptanalysis much easier.



The startup variables only help you if the cryptokey isn't embedded within the crypto program and "passed" to it in the startup process.


I was reading through Unwired about encryption and I discovered the handwaivery that made encryption as a speed bump so that it didn't completely defeat hackers. It's a BS mathematical algorithm that magically cracks any encryption algorithm.

I'm sorry, but do you really think a game with real world accurate cryptography rules would play well with all the magic and guns? It's hand waving, but it's necessary. Parts of this thread are getting way too real world technical when there's enough to talk about as far as how the game mechanics work.

No, you pad the block prior to encryption. Block ciphers just work on uniform sized chunks of text.


In that case you can attack it offline, as every copy of the program has the same internal crypto settings.

It doesn't matter if you pad before, after, or randomly within the block. It makes it easier to attack the algorithm to figure out the key. The randomized padding only helps deter on small numbers of records. However a transaction log contains a large number of records, which patterns will emerge that will allow you to determine what the block length is and consequently be able to determine what part of the encrypted text indicates the time stamp.




Actually, the most competent option would be to store the crypto-key in a secured data store which the application accesses to get the key while its running. So first you would have to lift a copy of the crypto program, then reverse engineer it to discover the location of the key, then crack into the data store that houses the key value or be able to sniff the key value while it's transmitted to the crypto program.

Pads are an essential part of block ciphers. If it encrypts 128 bytes per cycle it needs 128 bytes, not 127 or 129. And for a loggin function it would be designed such that every record is contained in one block. This prevents having to decrypt a a huge log file in order to add a record on the end using some sort of stream cypher, and simplifies it centralizing a large number of different logging subsystems. Since a well designed encryption algorithm using effective keys puts out essentially random noise that is not susceptible to analysis it really doesn't matter that you know the time stamp is in the front of the record. There isn't a 1:1 correlation between the plain text and crypto output, so changing one bit doesn't change one character on decryption, it mangles the entire block.