Live data from Hacker News

Viewing profile — kelson

kelson

HN member
Joined
Tue, Apr 14, 2015, 4:04 PM UTC
HN karma
27
Public activity
13 items

About kelson

No profile information was provided.

Recent public activity

  1. comment
    Comment #15540961

    Prior art https://www.shysecurity.com/post/20120401-PingFS

  2. comment
    Comment #12256040

    The flaw may be assuming everything else can be equal in the real world. Obscuring the algorithm has downstream consequences that may/will reduce overall security. For example, hid…

  3. comment
    Comment #12255951

    We measure password and cryptographic key security based on their entropy (keyspace) and speed (key tests / second). Given current attacks (GNFS), a 2048-bit RSA key has ~112 bits …

  4. comment
    Comment #12110656

    > "In return for the hollow credits, ConocoPhillips paid Green Diesel $18 million, according to court documents. Shell got stung for $14.4 million, BP for $13.6 million, Marathon O…

  5. comment
    Comment #11899103

    > just autoincrement nonce=123 and revoke it any time. Does that revoke all tokens (shared "nonce") or update the token on next authentication? Would this "nonce" be stored in the …

  6. comment
    Comment #11899041

    Salt is random data used to cryptographically sign or encrypt data. It sounds like your JWT consists of a userID and a sessionID (stored in Redis). Why not just store your sessionI…

  7. comment
    Comment #9846865

    Prior Implementation: http://shysecurity.com/posts/PingFS

  8. comment
    Comment #9376637

    > Thus the remote access to the RPi wouldn't pose a risk for using the protocol beside the obvious risks that you always get in such a scenario. That risk didn't exist without the …

  9. comment
    Comment #9376233

    Was CC and KC both performed on the Pi? That introduces side channel attacks. Does CC include implementation flaws enabling remote access? An attacker may use the Pi to enhance att…

  10. comment
    Comment #9375824

    > I just wanted to show the common idea of "cryptography is black magic, you should never touch it, you can only do bad things" wrong. Per the other thread, this is overwhelmingly …

  11. comment
    Comment #9375637

    > Thanks for agreeing that we don't lose security when using my construct. I don't agree. The construct may not degrade security under several caveats. Most implementations are ext…

  12. comment
    Comment #9375445

    You're right; I misread your construct as KC(CC(P)). Your construct [CC(KC(P))] shouldn't be weaker than KC, unless information or resources are shared by CC and KC (such as keys).…

  13. comment
    Comment #9375278

    This is almost always less secure than KC alone, when KC is a well-known secure cipher. A simple example would be a CC that hex-encodes the plaintext before applying some transform…