83

You have at least two options, depending on what problem you want to solve. If you want innocent readers of your code to not get the answers inadvertently, or you at least want to make it a bit difficult so that users are not tempted, you can encrypt the solutions and store the key as part of your code, perhaps a result of some computation (to make it even ...


31

The title and the body of your question ask two different questions: how the OS creates entropy (this should really be obtains entropy), and how it generates pseudo-randomness from this entropy. I'll start by explaining the difference. Where does randomness come from? Random number generators (RNG) come in two types: Pseudo-random number generators (PRNG),...


28

You have two three options: Keep the answers separate from the rest of the source code If you want your code to be open source, however don't want the answers to be open source, then you open source the code for the application without the questions & answers, with the questions & answers being a separate closed source "plugin" or data file. Your ...


12

There is a subarea of computer security called Computer Virology. The Journal of Computer Virology is devoted to the topic. Studying how anti-virus software works only scratches the surface of what the area is about. For instance, there is even some work applying logic to malware: A General Definition of Malware by S. Kramer and J.C. Bradfield. Journal of ...


10

Oblivious RAM is an interface between a program and the physical RAM that when you perform a read or write, does both at the same time on the physical RAM to hide if you are reading or writing. Plus, it shuffles the memory from time to time so that an adversary seeing only accesses to the physical RAM cannot know whetever you accessed the same data twice or ...


10

Can the man in the middle not just take the keys swapped by the opponents, change the keys and then decrypt and encrypt the message again? Yes, they can. A key exchange protocol like (the "textbook" version of) DH is secure against eavesdropping (i.e., simply observing what is being transmitted on the channel), but completely breaks down against man-in-the-...


9

Viruses and antivirus technology have a lot to do with CS. Your question reminded me of something I recently read. Here's an excerpt from the book by Williamson & Shmoys, The Design of Approximation Algorithms, page 6. It's justifying the (practical) importance of approximation algorithms, and uses the well-known set cover problem as an example in the ...


9

In the crypto community, this task is known as delegated computation, or verifiable delegation. You wish to let the server (the "cloud") to do the work for you, but you also want the cloud to give you some proof that it actually performed the computation (and didn't just output a random output, and ran away with your money). A pointer, off the top of my ...


8

WEP uses the stream cipher $RC4$ for confidentiality and the CRC-32 checksum for integrity. All data frames sent by a router in a WEP protected network are encrypted. When a router sends a packet, the following steps are executed. The router picks a $24$-bit value called the initialization vector $IV$. A new $IV$ is used for every packet. The $IV$ is ...


7

Since you asked on a computer science site, I'll give you a computer science answer. This might not be the most directly helpful from a programmer's point of view, though understanding this will definitely make you a better programmer. The first argument to the printf function is a char *, i.e. a pointer to a byte¹. However, not all pointers to bytes are ...


7

You should be careful when using theoretical result to argue something cannot be done in practice. There are several dangers that one can fall in: the theoretical result has assumptions that doesn't apply, the problem in practice is not modeled well by the theoretical model, in practice a solution doesn't need to be perfect to be useful. You haven't ...


7

See "Understanding Java Stack Inspection" by D. S. Wallach and E. W. Felten (1998) From the paper: ... The stack inspection algorithm used in current Java systems can be thought of as a generalization of the following simple stack inspection model: In this model, the only principals are “system” and “untrusted”. Likewise, the only privilege available is ...


7

I suppose it would be possible in theory, but computer malware (viruses, worms, etc.) typically don't work this way today, and there are good reasons why they're written the way they are. You might be interested in polymorphic code, which changes itself to evade detection. It changes the sequence of instructions to some other sequence of instructions that ...


7

I believe this is done to illustrate two things. (i) The small probability, that $P$eggy ($P$rover) might be lying. If she really does not know the magic word and $V$ictor ($V$erifier) sees her taking Path $A$, he would always ask her to come back via path $B$, thus the probability of $P$ succeeding when cheating is $0$. However, $ZKP$s usually involve a ...


7

If you want a practical answer: with Intel SGX, the answer seems to be a qualified yes, but software development is likely to be more painful. (Similar with a TPM, though that will be even more annoying.) See, e.g., https://security.stackexchange.com/q/2459/971. If you want a theoretical answer: in theory, you could use various cryptographic schemes for ...


6

In authentication you often come accross zero-knowledge password proof (ZKPP). EAP itself is a rather generic framework and it might involve revealing the identity of the client for instance to transfer it to the next layer of authentication such as RADIUS. PACE (BSI TR-03110) is one example of ZKPP protocols used for authentication. EAP-SPEKE is another. ...


6

Stack inspection is necessary because programs on the JVM and CLR have default access to dangerous operations, so something must be done to prevent disasters. For example an untrusted program can reference an I/O library and call it: using IO; ... IO.DeleteFile("/home/foo/bla"); So on each dangerous operation made, we need to check whether it is allowed. ...


6

To answer your question in the most concise way - yes, this bug could have potentially been caught by formal verification tools. Indeed, the property "never send a block which is bigger than the size of the hearbeat that was sent" is fairly simple to formalize in most specification languages (e.g. LTL). The problem (which is a common criticism against ...


5

The malicious user has to first get the malicious code into kernel space somehow. User and kernel address spaces often look contiguous under linux and various unixes, but user space isn't mapped into kernel space, and vice versa. Some variations of Unix (the Masscomp system, as I recall) made this more explicit by having user space and kernel space start at ...


5

Do you mean "that cannot be affected" or "that was never affected"? Then, under what conditions? Do you mean malware in general or a more restrictive notion of virus? And then, what is virus or malware? Is code for automatic update of your OS considered malware or not? Maybe you do not want to update your OS. Maybe someone has taken control of the updating ...


5

Commercial program checkers like Klocwork or Coverity might have been able to find Heartbleed since it is a relatively simple "forgot to do a bounds check error," which is one of the main problems they are designed to check for. But there is a much simpler way: use opaque abstract data types that are well tested to be free from buffer overrun. There are a ...


5

One limitation of stack inspection as traditionally implemented is that it breaks proper tail calls. In particular, typical implementations need to keep the entire "stack" around at all times. Clements and Felleisen show how this problem can be remedied using a technique called "continuation marks" in their paper A Tail-Recursive Semantics for Stack ...


5

The distinction you want to make between the key and the algorithm proper is not based on whether most of the operation is contained in one or the other, but on where the complexity lies. I am not talking about algorithmic complexity here, but complexity in its everyday meaning: difficulty to understand and reason about. The algorithm proper is complex and ...


5

TL;DR: computers are not autonomous entities like organisms, with any survival instinct. They just run instructions, and sometimes they run instructions we don't like, so we run other instructions to find the bad ones. I started to say this in the comments, but I think there's a lot more to be said. The virus metaphor is outdated and too widely used by ...


5

What you're looking for is Rice's Theorem, which is a generalized version of Halting Undecidability. It basically says that any property of a Turing Machine (i.e. any computer program) is undecidable, if it's a property of the behavior of the program (i.e. a property of the language it accepts/produces), as opposed to a particular syntactic feature of the ...


5

In a man-in-the-middle attack, you ask Bob for his key but Eve intercepts the message and sends you her key instead. She asks Bob for his key and then passes messages between you and Bob, decrypting them, reading and/or changing them in the process. The problem is that you don't know whether or not you really have Bob's key. Certificates get around this ...


4

Problem Definition The goal of cryptography is to approximate a process whereby crypt(x) conveys no information about x but there exists a function decrypt such that decrypt(crypt(x)) == x If decrypt and crypt were only done in the same run of the same program, you could implement this perfectly using hidden state: var map = {}; // A hidden hashmap. ...


4

The way to view the lattice is by taking the two pieces one at a time. Firstly, you have the lattice: $$ \begin{array}{c} Clean \\ | \\ Dirty \end{array} $$ to capture that Clean data has higher integrity than Dirty data. Similarly, $$ \begin{array}{c} DataEntry \\ | \\ Website \end{array} $$ captures that DataEntry data has higher integrity ...


4

If you count as a " program verification technique " the combination of runtime bound-checking and fuzzing, yes this particular bug could have been caught. Proper fuzzing will cause the now infamous memcpy(bp, pl, payload); to read across the limit of the memory block pl belongs to. Runtime bound-checking can in principle catch any such access, ...


4

Using a tighter language doesn't just move goal posts around from getting implementation correct to getting the spec right. It is hard to make something that is very wrong yet consistent logically; which is why compilers catch so many bugs. Pointer Arithmetic as it is normally formulated is unsound because the type system doesn't actually mean what it is ...


Only top voted, non community-wiki answers of a minimum length are eligible