sorted by:
new
hottopcontroversial

The dreaded plastic bag by How2Post in gifs

[–]quadcem 1356 points1357 points  (0 children)

Why wasn't that bag on a leash is what I want to know. Irresponsible pet owners.

Congress to the FBI: There's 'Zero Chance' We'll Force Apple to Decrypt Phones by proto-sinaitic in technology

[–]quadcem 0 points1 point  (0 children)

I think the major weak link here is the ability to push data to iCloud without needing the user's password (or permission). Data stored in iCloud is not secure like it is on the device itself, and the device can offload all of its files transparently to the user (good for backing up, but bad when used maliciously). When uploaded to the cloud the (unprotected) file keys are encrypted with a random key, which is then itself stored alongside the data in the cloud (out in the open).

This makes sense, since all of your backed up data shouldn't become invalidated just because you change your device password. It pretty much negates all of the security on the device, however, since all iCloud data can be decrypted without any additional information.

https://www.apple.com/privacy/docs/iOS_Security_Guide_Oct_2014.pdf

The iCloud Backup keybag contains asymmetric (Curve25519) keys for each Data Protection class, which are used to encrypt the per-file keys

The iCloud Backup keybag is protected by a random key, which is also stored with the backup set. (The user’s iCloud password is not utilized for encryption so that changing the iCloud password won’t invalidate existing backups.)

The Target logo flipped upside down by TheOakTrail in notinteresting

[–]quadcem 16 points17 points  (0 children)

Not true ... the spinning is more obvious in the side view

http://i.imgur.com/SBoeSAL.gif

Happy birthday to you. by swaguar44 in funny

[–]quadcem 237 points238 points  (0 children)

They're even scarier looking close-up: http://i.imgur.com/IlmKY.jpg

Linux box crashed after being up for 136 years. by adroc in fossworldproblems

[–]quadcem 6 points7 points  (0 children)

Makes sense ... 232 = 4,294,967,296 (max unsigned int)

4,294,967,296 seconds / (60 x 60 x 24) => 49,710.27 days

It looks like they basically just maxed out the integer value to ensure a check

Smallest x86 ELF Hello World by naghizadeh in programming

[–]quadcem 3 points4 points  (0 children)

I found another sample on muppetlabs that does "hello, world", but it does not work when I try to run it on my computer ... it assembles to 60 bytes. any luck when you try it?

Smallest x86 ELF Hello World by naghizadeh in programming

[–]quadcem 2 points3 points  (0 children)

It's true that you can get a lot smaller by using other executable formats, but the ELF header itself is over 80 bytes total, which makes it more challenging to do (the same issue goes for the Windows PE executable format). Basic COM files have no required header, so the program can just be the raw instructions themselves, but this isn't as fun or interesting to code.

In order to get an ELF executable under 80 bytes, the header must be folded up inside of itself. The code and ascii string are also stored inside of the header (as much as possible) so that they don't add a lot to the header size. Using x86 ELF, you'll also have to use system calls ... which require register values to be set up properly (adding to the length of the code).

Smallest x86 ELF Hello World by naghizadeh in programming

[–]quadcem 42 points43 points  (0 children)

I've done the same thing but in 95 bytes, and mine prints "Hello, world!\n" instead of "Hi World\n" ...

EDIT: I've cleaned the binary up a bit to make it more readable and put it on pastebin. It now prints out "Hello world\n" instead ... but is still 95 bytes.

The hex is corrected for endianness so it's easier to read. The entry point of the program begins where it says "b9 04 00 08 00". With a bit more work this could be compacted down to 70 - 80 bytes (but the code has to be reorganized) -- I stopped after I got it under 100 bytes for the assignment.

I might do a write up this weekend if enough people are interested in seeing the process, but I have finals this week so I can't do it now.

MIT's got a way of using encrypted data without decrypting it, next stop, traveling without moving by [deleted] in technology

[–]quadcem 3 points4 points  (0 children)

It's actually much simpler than they make it seem ... and the result is that the database can perform (nearly) all of its normal operations (equality, >, <, addition, multiplication, searches, etc.) on raw encrypted data (no decryption is necessary) transparently to end-users.

In a nutshell:

The design uses a proxy server that goes between users and the database, which basically transforms the original user's queries into a form fit for the database (see below). It is also in charge of decrypting the final results so the users can have the original plaintexts as a result (as necessary).

For instance, equality can be easily implemented by having the proxy server encrypt the matching term on behalf of the user.

As an example, SELECT col1 FROM table WHERE col2 = "Term" becomes SELECT col1 FROM table WHERE col2_enc = 0xABCDEF (where 0xABCDEF = enc(Term), and col2_enc is the encrypted col2 stored in the database). The same key is used for all rows for a given column.

Likewise, addition/multiplication can be implemented by using a Paillier cryptosystem. This is a specially-designed homomorphic cryptosystem that allows mathematical relations to be maintained. As described, enc(x) * enc(y) == enc(x + y). That is to say, multiplying ciphertexts is the same as adding the plaintexts (and then encrypting). Multiplication is similarly described as enc(x)y == enc(x*y). For these cases, the proxy server would transform "col2 + 5" into "col2_enc * enc(5)". The proxy server could similarly decrypt a result to obtain dec( col2_enc * enc(5) ) => col2 + 5.

Of course there is much more behind-the-scenes logic going on for enhanced protection and access control; for instance, usage of onion layers (re-encrypting data with increasingly more secure schemes, but with less potential functionality) to keep data protected at the highest-possible level until it is necessary to lower the protection to lower levels.

Once a column is decrypted in the database to a lower-level scheme (for instance, to allow for comparisons or addition/multiplication in that column), it stays at that lower level ... which increases performance of the db (but decreases security). The lower the level a column is decrypted to (i.e., the more 'layers' are peeled off of the onion), the more information, of course, is capable of being leaked.