Re: Encryption and authentication modes
> What's the current state of affairs regarding combined encryption and > authentication modes? > > I've implemented draft-mcgrew-aead-aes-cbc-hmac-sha1-01 (I think, I > couldn't find test vectors), but I later came across CCM and EAX. CCM > has the advantage of being NIST-reviewed. EAX can do streaming (but > that's less useful when doing authentication). Neither seems to be > widely implemented. But both offer a considerable reduction in > per-message overhead when compared to the HMAC-SHA1/AES combination. > > Are there any other alternatives to consider? Are there any traps I > should be aware of when implementing CCM? > > -- > Florian Weimer > BFK edv-consulting GmbH http://www.bfk.de/ > Kriegsstraße 100 tel: +49-721-96201-1 > D-76133 Karlsruhe fax: +49-721-96201-99 > > - > The Cryptography Mailing List > Unsubscribe by sending "unsubscribe cryptography" to > majord...@metzdowd.com > CCM is widely implemented. It's a matter of where you look. Down at the MAC layer, AES-CCM has proved popular in wireless packet communication because it is well adapted for separating the treatment of the header as plaintext AAD from the packet body as ciphertext. Also it is relatively efficient to implement in hardware since it relies only on a single AES encrypt block cipher and the birthday resistance of the ciphertext MAC reduces on-air per packet overhead. This is the why for example that you see AES-CCM in wireles USB, 802.11, 802.16 and WiMAX management protocols. A couple of years after 802 went for AES-CCM, AES-GCM became the 802.3/ethernet choice since it is more parallelizable and so can be implemented for 10Gbps+ links where CCM becomes trickier. The per packet overhead is higher, but bandwidth on wires is cheap. I don't think you can really implement CCM except in the context of a more detailed specification for a protocol. CCM is a flexible specification and protocols that use it must nail down a number of parameters and field sizes in order to be interoperable. It's not so easy to just plug it in which makes is less convenient for the more pluggable software based protocols higher up the stack. Some technically good candidates for standards adoption, E.G. OCB met resistance due to licensing issues. DJ - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
Re: questions about RNGs and FIPS 140
> > 3) Is determinism a good idea? > See Debian OpenSSL fiasco. I have heard Nevada gaming commission > regulations require non-determinism for obvious reasons. > The Nevada rules don't convincingly demand non determinism. They do say things that probably unintentionally exclude non determinism. "4. The random number generator and random selection process must be impervious to influences from outside the device, including, but not limited to, electro-magnetic interference, electro-static interference, and radio frequency interference. A gaming device must use appropriate communication protocols to protect the random number generator and random selection process from influence by associated equipment which is conducting data communications with the gaming device. (Adopted: 9/89. Amended: 11/05; 11/17/05.) " An impossible requirement for a TRNG based on physical processes. This requirement pretty much demands determinism and in practice is untestable. Some definitions.. "23. Randomness is the observed unpredictability and absence of pattern in a set of elements or events that have definite probabilities of occurrence." and "20. Random Number Generator is a hardware, software, or combination hardware and software device for generating number values that exhibit characteristics of randomness." Definitions that both a TRNG and a PRNG can meet. They don't get down to the nitty gritty of what the observer might know, like the internal state of a PRNG, that would impact whether the data has 'observed upredictability'. "14.040 Minimum standards for gaming devices.. [] 2. Must use a random selection process to determine the game outcome of each play of a game. The random selection process must meet 95 percent confidence limits using a standard chi-squared test for goodness of fit. (a) Each possible permutation or combination of game elements which produce winning or losing game outcomes must be available for random selection at the initiation of each play. (b) For gaming devices that are representative of live gambling games, the mathematical probability of a symbol or other element appearing in a game outcome must be equal to the mathematical probability of that symbol or element occurring in the live gambling game. For other gaming devices, the mathematical probability of a symbol appearing in a position in any game outcome must be constant. (c) The selection process must not produce detectable patterns of game elements or detectable dependency upon any previous game outcome, the amount wagered, or upon the style or method of play. " Again, a PRNG would meet these requirements. The only specific test proposed is the Chi-square GOF. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
[Cryptography] /dev/random is not robust
http://eprint.iacr.org/2013/338.pdf ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: Privacy Concerns for UWB technology?
Damien, The answer to the question "Is UWB secure" depends entirely on the assumptions you make. UWB is after all a physical layer radio/modulation technology that is only peripherally related to the layers above that may provide security in a number of forms, say link security, VPNs, SSL etc. Here are a couple of assumptions I am throwing in: 1) You are referring to one of the two significant adopters of UWB in a standardized context, namely IEEE 802.15.3a and Wireless USB. 2) The actual UWB technology being considered is the MBOA (Multi Band OFDM Alliance) flavor. 3) The UWB technology provides and underlying bit rate of 1 Gbps. This is realistic. As an 802.15.3a standard (when or if they finish it) there are two places that security specific to the technology will come from. The first is 802.1X/ae/af (EAP conduit, link ciphers and authenticated key exchange). These standards are works in progress (.1X is currently withdrawn awaiting necessary undercarriage work). The second is from native 802.15 link security that the 802.15 working group may choose to supply. Above the link layer, it is not the IEEE's problem. 802.15 is an IEEE link layer spec and upper layer methods that might apply are more generic E.G. those from the IETF. If we are talking about its application in Wireless USB then it is the job of the writers of the Wireless USB standard to provide the appropriate security mechanisms. They have a bigger problem to solve, since they are having to secure a set of higher layer functions that are outside the scope of IEEE 802. Beyond observing thats its not written yet, there's not much to go on other than low expectations set by a long and sorry history of wireless security mechanisms. Getting down to specifics, if its 1 Gbps, then the currently in vogue IEEE 802 link cipher (AES-CCM) will do fine in terms of implementation constraints. However 802.1ae has chosen GCM as its link cipher and this holds the promise of linearly scalable implementability up to much higher speeds. The short range of UWB technology may provide security from some attack models (the guy next door), but don't count on it and you can be sure that by the nature of networks, remote attacks will be possible unless anticipated and secured against. I remember reading recently about a succesful bluetooth fishing expedition at a trade show. The short range didn't help there. The pessimistic view of IEEE 802 link security mechanisms is that first time publications of standards will always come with broken security because they never get the attention they deserve from the crypto community until the flaws are identified and need fixing. In support of that allegation, I offer you 802.11 WEP, 802.16 PKM, The 802.16 link cipher, and 802.1X. All are broken and currently being overhauled. The optimistic view of IEEE 802 link security is that 802.1X/ae/af is the second go around, it is getting the attention it deserves and may deliver an appropriate result in terms of security. However its meeting the needs of wireline standards (802.3, 802.17) and is too high in the stack to support the needs of mobile wireless links. Just to complicate matters and to lower your expectations further, the use of UWB in media centric home networks leads to new usage models and unsophisticated users, tied in with the horrors of DRM on the media side. This presents problems that arguably are not solved in a practical, deployable sense today. Your example of the neighbour watching your TV is a fine example. Regards, DJ https://www.deadhat.com > Hi, > > I was at a talk last night on Ultra Wideband (UWB) technology which is > sometimes referred to as "Bluetooth on Steroids". > An example of what a UWB home might look like was given and it mainly > consisted of everything that a normal > home has today except without the wires. So you have your plasma TV > connected to your DVD player using > UWB and you can hook up a camcorder to it as well etc. > > UWB offers rates of about 100Mb/s which is comparable with the 802.11n > standard. I asked the speaker what > was the general thoughts on privacy concerns with this technology and he > basically said there wasn't any concerns > but I don't think it was something he had thought about before. UWB works > over a very large bandwidth (the FCC > allocated something like 7GHz of the spectrum for it) however it uses very > low power. Its range is very limited (about > 10m or so). I don't know much about the technology itself but he > mentioned > that is was something like spread > spectrum so I assume it uses some kind of pseudorandom code to allow > successful requisition of signals. > > I am curious about the privacy issue however. The speaker said that > encryption would be used and that that would > protect a persons privacy but at these high data rates would e
Re: AES Modes
On the IEEE 802 standards track, CCM and GCM have traction. CCM has been in 802.11 for a while and the 802.16-2004 was published last week, supplanting the broken DES-CBC mode with AES-CCM. For wireless systems, we know and like CCM and it's going to take a lot to oust it. I'm aware of a handful of other wireless protocols in development that appear to be all headed the CCM way. GCM proposed for 802.1ae linksec. This is the 'fast' mode for wired ethernet. For packetised traffic below 1Gbps, CCM works just great. The CTR and CBC parts of CCM run in parallel in hardware, making the basic latency = 1 AES (which is 11 clocks in a simple implementation). With a bit of HW loop unrolling and pipelining, I can do CCM upto several gigabits. CCM nicely matches the structure of packets. Namely 1) Get header -> Process additional authenticated data 2) Get payload -> Process MAC and encryption in parallel. So it is not a bear to implement in a typical communications datapath IC, where things are presented to you in this order. GCM allows block level parallelism up to a point. Hence enabling me to put lots of parallel AES blocks on a chip and go at multi gigabits without breaking a sweat. It does however have all that Galois arithmetic to do per block, which increases the path depth a bit. There is however a fundamental speed problem with packet oriented AES based modes. The parallelism you can achieve on things like GCM requires that you have multiple blocks to run in parallel. If I get a large number of small packets, each < 128 bits long, then there's nothing to do in parallel at the block level and so my speed limit is determined by how fast I can run 11 rounds of AES. This may come to bite us in the future and when we start having to protect data pushing the terabits, we either need larger packets or something different in the crypto. One way is to protect over large packet aggregates, but no 802 level protocol is set up to support it. Stream ciphers look attractive here, we can make them go *really* fast in hardware. Another frustrating aspect of the current crop of modes is frame expansion. Throwing in an 8 byte nonce and an 8 byte ICV per packet is a heavy overhead. Deriving nonces from the protocol state is generally not wise since the frame counts are either non existant (802.3, 802.11) or not secured (802.16). In the coming years, I would like to see link protocols (I.E. 802.*) move link security down to the PHY, to protect management and data traffic equally, to secure the protocol state as well as data and so to reduce packet overhead. I would also like to see the standardized crypto and protocols be structured to work over larger aggregates of packets, protecting the structure of transmission as well as the content and allowing much greater levels of parallelism in the HW implementations. Obviously, none of this is very relevant above layer 2. Regards, DJ >>From: Ian Grigg <[EMAIL PROTECTED]> >>Sent: Oct 10, 2004 11:11 AM >>To: Metzdowd Crypto <[EMAIL PROTECTED]> >>Subject: AES Modes > > >>I'm looking for basic mode to encrypt blocks (using AES) >>of about 1k in length, +/- an order of magnitude. Looking >>at the above table (2nd link) there are oodles of proposed >>ones. > >>It would be nice to have a mode that didn't also require >>a separate MAC operation - I get the impression that >>this is behind some of the proposals? > > I think CCM is just about perfect for this goal. The MAC isn't free, but > it's integrated into the chaining mode. There are also some patented > modes that provide a MAC for almost no extra computation(OCB, IACBC), and > some proposed modes that combine an efficient, parallelizeable MAC with > encryption in a secure way (CWC,GCM), though none of these are standards > yet. > >>iang > > --John > > - > The Cryptography Mailing List > Unsubscribe by sending "unsubscribe cryptography" to > [EMAIL PROTECTED] > - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
