Encryption

[MT]

I need to send some sensitive data back to a browser client to return with the next form they submit - why not use sessions, and store it local side? I dont want it remembered - either they use that data there and then, or we forget about it.

Actually the data itself isnt at all important - I just dont want anyone to be able to forge the data.

As such, as a mini "challenge", I've come up with an an algorithm I'd like to test to see how useful it is.

All of these are SQL queries.

9HfqGFgSr2eIovkO/P5KiEAkbMSNB9uXjMdJTS4gC2zY3y9HzhI5BdqNpzdzreWA

6qg1QRTq+j06YumK4O8Me0UNSeG2ypsqqVDX1fUDIeKa4GrVqkL+wA==

lPRxCP2h3VBQGCR/KxQ6xc5ePtYn4YM6A7WB9vMf7450uTBDQXAbfA==

s2IDJ33uUjTrTcRxgfEQxSAqDfnYD+5O6Sf9bjqOXKw=

(As a hint, those are encrypted first, then base64 encoded)

[Gayle29uk]

My immediate thought is why not set up a GPG CGI interface and have someone else worry about the encryption if it's that sensitive?

[MT]

user does something.
server generates form, sticks in encrypted "what to do after submit" information

user either cancels (what to do disappears) or clicks proceed (what to do is decrypted, and done)

[queball]

I'm guessing the attacker would not only have this encrypted data, but information about what it might represent, and the ability to generate lots and lots of string.

What stops them being duplicated? Or is the action one-time like digital cash?

Seems better to sign a hash of the message and the time than use encryption, if you just want trusted messages to yourself from the past.

[pablissimo]

When you say 'these are all SQL queries' do you mean that they are complete and valid SQL queries that haven't been compressed or had atoms represented in a shorter way or that keywords may have been replaced by short codes?

Or would that be 'too much information'?

Edit:
To be fair, more examples/access to script output would be required imo, if only for the sake of time...

Edit Edit:
Have you got an example/cut down version of the script/algorithm available online so we can 'probe' it?

[Gayle29uk]

Originally posted by MT
user does something.
server generates form, sticks in encrypted "what to do after submit" information

user either cancels (what to do disappears) or clicks proceed (what to do is decrypted, and done)

'View Source' gives them the encrypted return data, doing it a few times will give them a statistical universe to work from in breaking the encryption. If you use GPG you don't care if they see the encrypted data or not, it's not gonna get decrypted any time soon

Downside to this is having to write a CGI interface though and given the number of people interested/capable of breaking it is small that's probably not worth the effort

Why not use session cookies? They disappear when the browser window is closed and are only stored in memory so that fits your criteria 'use it now or lose it'. I'm sure you know this though so I'm curious why they won't do.

[queball]

Originally posted by Gayle29uk


Why not use session cookies? They disappear when the browser window is closed and are only stored in memory so that fits your criteria 'use it now or lose it'. I'm sure you know this though so I'm curious why they won't do.

No; the server-side session data is kept until it times out.

[pablissimo]

Originally posted by queball
No; the server-side session data is kept until it times out.

Out of interest, what would be the purpose of such an endevour?

And what would stop someone getting to a page where the encrypted 'instruction' has been stored (say in a hidden input field), leaving it a week, then submitting form data and being able to perform the instruction?

Or is that the point?

[MT]

Originally posted by queball
I'm guessing the attacker would not only have this encrypted data, but information about what it might represent, and the ability to generate lots and lots of string.

Yes

What stops them being duplicated? Or is the action one-time like digital cash?

To duplicate them, they would first need to steal a session. With a stolen session, they can do * anyways. Withstanding that, sending the information 100 times simply results in the afflicted account oweing a fkload of money.

Seems better to sign a hash of the message and the time than use encryption, if you just want trusted messages to yourself from the past.

Thats an option, wheres the benefit over this?

Originally posted by Gayle29uk
[b]'View Source' gives them the encrypted return data, doing it a few times will give them a statistical universe to work from in breaking the encryption. If you use GPG you don't care if they see the encrypted data or not, it's not gonna get decrypted any time soon

Hmm, when I said "come up with", I actually mean "acquired". The algorithm is TEA.

How secure is TEA?

Very. There have been no known successful cryptanalyses of TEA. It's believed (by James Massey) to be as secure as the IDEA algorithm, designed by Massey and Xuejia Lai. It uses the same mixed algebraic groups technique as IDEA, but it's very much simpler, hence faster.

[Gayle29uk]

Originally posted by MT
Hmm, when I said "come up with", I actually mean "acquired". The algorithm is TEA.

Tiny Encryption Algorithm (TEA)
TEA is a cryptographic algorithm designed to minimize memory footprint, and maximize speed. However, the cryptographers from Counterpane Systems have discovered three related-key attacks on TEA, the best of which requires only 223 chosen plaintexts and one related key query. The problems arise from the overly simple key schedule. Each TEA key can be found to have three other equivalent keys, as described in a paper by David Wagner, John Kelsey, and Bruce Schneier. This precludes the possibility of using TEA as a hash function. Roger Needham and David Wheeler have proposed extensions to TEA that counter the above attacks.

Original source (with links to details of the breaks) is here.

[queball]

You have sessions anyway?

You've posted TEA encrypted data (how many iterations?), and are asking people to decrypt it without the key?

Originally posted by MT

Thats an option, wheres the benefit over this?

Transparency, debugging, the usual. Might not be an advantage if you have dumb customers.

Gayle, that doesn't affect how MT is using it. And that should say 2^23.

[MT]

Ah, I get you - send a hash of the data to the client, and tie the hash to a particular timeframe, storing everything else in sessions.

32 iterations btw.

[queball]

That wasn't what I meant by signing, but yeah a hash would do, or a transaction ID, or anything.

By signing I meant the client gets the text of their transaction, SQL with a timestamp or whatever, along with the hash of that, encrypted. Then you get transparency of the transaction for the user, which probably isn't useful.

You'll be doing some sort of signing anyway, otherwise a client could pass a random string and it would get decrypted to something horrible. If you check if it's ok to run you are (approximately) signing/authenticating, so you might as well do it properly.

BUT if you've got sessions use them, it's simpler and easier to model.

[W]

How about simply encrypting a hash of the commands and a secret key, and send it with the commands in plaintext? If the hash matches a command when returned by the form, you execute them, othervise don't.

Nothing stored on the server, apart from the secret key.