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.

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.

Encryption and Decryption
Files, signals, and devices may all be encrypted with a Simple Action. If you have the proper key, decrypting takes only a Simple Action. Without a key, you must employ a battery of advanced sampling, pattern-matching, and brute force attacks to bypass the encryption. Make a Decrypt + Response (Encryption ratingx2, 1 Combat Turn) Extended Test to break the encryption.

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.

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.

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.

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.

Access logs can be encrypted. Strong encryption can require up 24 hours MINIMUM to break.

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).

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.

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.

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.